Хабрахабр

[Из песочницы] Паттон Джефф. Пользовательские истории. Искусство гибкой разработки ПО

Аннотация

Книга это рассказанный алгоритм проведения процесса разработки от идеи до внедрения с применением техник agile. Процесс раскладывается по шагам и на каждом шаге указываются методы для шага процесса. Автор указывает, что большая часть методов не оригинальна, не претендуя на оригинальность. Но хороший стиль изложения и некоторая целостность процесса делают книгу очень полезной.

Ключевая техника карты пользовательских историй — это структуризация идей и постановки по ходу прохождения процесса пользователем.

Можно выстроить шаги по мере достижения ключевой ценности, а можно просто взять и представить рабочий день пользователей, как он проходит с использованием системы. При этом излагать прохождение процесса можно по-разному. Автор фокусируется на то, что процессы нужно излагать, проговаривать в виде истории пользователя на карте процесса, что и послужило названием карта пользовательских историй.

Кому это нужно

Для ИТ-аналитиков и руководителей проектов. Обязательно к прочтению. Читается легко и приятно, книга средняя по размеру.

Отзыв

В самом простом виде, как это работает.

Посетитель приходит в кафе, выбирает блюда, делает заказ, получает еду, ест, расплачивается.

Можно писать требования, что мы хотим от системы на каждом этапе.

Почему мы уверены в этих требований? Система должна показывать список блюд, у каждого блюда состав, вес и цену и иметь возможность добавить в корзину. В “стандартном” описании требований это не описано и это порождает риски.

Исполнители не вовлеченные в процесс создания идеи, не вовлечены и в результат. Исполнители, не понимающие зачем это нужно, обычно делают не то что нужно. Agile говорит, так давайте фокусироваться прежде всего не на системе, а на людях, на потребителях, их задачах и целях.

Делаем персоны, для эмпатии придаем им детали и со стороны персон начинаем излагать истории.

Что ему нужно? Офисный сотрудник Захар пошел на обед и хочет быстро перекусить. Еще идея он хочет чтобы система помнила его предпочтения, потому что он сидит на диете. Идея — наверное он хочет бизнес ланч. Он хочет, чтобы ему сразу принесли кофе, потому что он привык пить кофе перед обедом. Еще идея.

Бизнес хочет увеличить средний чек, увеличить частоту покупки, увеличить прибыль. А есть еще бизнес (оргсонаж — персонаж, представляющий интересы какой-то организации). Еще идея — а давайте введем завтраки. Идея — а давайте предлагать необычные блюда какой-то кухни.

Как сотрудник бизнес-центра Захар, я хочу, чтобы система опознала меня, чтобы я получал меню с учетом моих предпочтений. Идеи можно и нужно конкретизировать, преобразовывать и оформить в виде user story. И так далее. Как официант я хочу, чтобы система уведомляла меня когда подойти к столику, чтобы клиент был доволен быстрым обслуживанием.

Дальше приоритизация и беклог? Десятки историй. Джефф указывает на возникающие проблемы: увязание в мелких деталях и утрата концептуального понимания плюс приоритизация функционала создает рваную картину из-за несогласованности целям.

Путь автора: Приоритезируем не функционал, а результат = то, что пользователь получает в итоге.

Первый отвечает за бизнес, второй за пользовательский опыт и третий за реализацию. Очевидный неочевидный пункт: сессия приоритизации проходит не всей командой, ибо неэффективно, а тремя людьми.

Выделим минимум для решения одной задачи пользователя (минимальное жизнеспособное решение),.

Остальные идеи оставляем не разобранными, в беклоге возможностей. Детализируем идеи первого приоритета с помощью user story, набросков дизайна, ограничений и бизнес правил на карте пользовательских историй путем рассказа и обсуждения с командой что нужно персонам и стейкхолдерам на каждом шаге процесса.

Обязательно путь прохождения всей истории нужно проговаривать вместе с сотрудниками команды для появления взаимопонимания. Процесс пишется в виде карточек слева направо, а идеи на карточках под шагами процесса.

Проработка таким способом создает целостность соответствия процессам.

Не член команды надевает шляпу персоны и проживает в голове день персоны, решая его задачу. Полученные идеи нужно проверить. Возможен вариант, когда он не видит наработок, создавая карточки заново, а команда открывает для себя альтернативы.

Для этого достаточно трех людей. Затем происходит детализация для оценки. Ответственный за пользовательский опыт, разработчик, тестировщик с любимым вопросом: “А что если…”.

На каждом этапе, обсуждение идет по карте процессов истории пользователя, что позволяет держа в голове задачу пользователя создавать целостность понимания.

Да, нужна. Нужна ли документация по мнению автора? Вовлечение человека со стороны опять требует обсуждения. Но как заметки, позволяющие вспомнить о чем договорились.

(Да, документация нужна, как бы это не утверждали люди, неглубокие в понимании agile). Автор не углубляется в тему достаточности документации, делая основной упор на необходимости обсуждений. Автор указывает на риск излишней проработки в случае когда не угадали с идеей. Так же проработка только части возможностей может привести к необходимости полной переделки всей системы.

Сделали набросок идеи — валидировали у пользователя, набросок прототипов интерфейса — валидировали у пользователя и т.п. Для снятия рисков необходимо быстро получать обратную связь по создаваемому продукту для минимизации ущерба создания “не того” продукта. Цели создания ПО, особенно на начальной стадии — обучение через получение быстрой обратной связи, соответственно первый созданный продукт это наброски которые в состоянии доказать или опровергнуть гипотезу. (Отдельно немного указывается как валидировать прототипы программ). (Автор опирается на работу Эрика Райса “Стартап по методологии Lean”).

Что должно быть на карте? Карта историй помогает наладить коммуникации, если реализация обеспечивается несколькими командами. Не только user story (кто, что, почему), а идеи, факты, наброски интерфейсов и пр… То, что нужно для поддержки беседы.

Разделяя карточки на карте истории на несколько горизонтальных линий можно разделить работы на релизы — выделить самый минимум, слой наращивания функционала и бантики.

Проговариваем истории на карте процесса.

Сотрудник пришел на обед.

Скорости обслуживания. Что он хочет? Опа — пропущенный шаг: сотрудник захотел поесть. Чтобы его обед уже ждал его на столе или хотя бы на подносе. Он увидел калорийность и соответствие питательной ценности, чтобы соблюдать диету и не толстеть. Он зашел в систему и выбрал вариант бизнес-ланча. Он увидел картинки блюда, чтобы принять решение будет ли он есть в этом месте или нет.

А может быть ему доставят ланч в офис? Далее он пойдет получать ланч и обедать? Он хочет видеть срок когда ему доставят и сколько это будет стоить, чтобы выбрать куда потратить время и силы — на спуск вниз либо на работу. Тогда шаг процесса — выбор места еды. Он хочет видеть загруженность кафе, чтобы не толкаться в очередях.

Он хочет увидеть свой поднос, чтобы взять его и сразу пойти обедать. Далее сотрудник пришел в кафе. Сотрудник хочет потерять минимум времени на расчетах с кафе, чтобы не тратить драгоценное время без пользы. Кафе хочет принять деньги, чтобы заработать на обслуживании. Оплачивать заранее или наоборот после обслуживания удаленно. Как это сделать? Что из этого самое основное? Или оплачивать в момент с помощью киоска. Как много людей доверят хранение номера карты для повторных оплат этой столовой? Как много людей готовы оплачивать банковской картой обед? Без полевого исследования неясно, нужно тестирование.

Прошли историю до конца = сделали жизнеспособное решение. На каждом шаге процесса нужно хоть как-то обеспечить функционал, для этого нужно взять за основу какую то персону и выбрать что важнее ему (та самая тройка выбиральщиков).

Клиент хочет видеть загруженность кафе, чтобы не толкаться в очередях. Далее идет детализация. Что конкретно он хочет?

Смотреть прогноз сколько будет людей через 15 минут, когда он туда подойдет

Смотреть среднее время обслуживания в кафе и его динамику на полчаса вперед

Смотреть ситуацию и динамику занятости столиков

А что если система прогнозирования дает непонятный результат или перестанет работать?

Хм, а почему бы не сделать это в первую очередь?! Смотреть через видео очереди в кафе, а также занятость столиков.

Одна карточка = одно действие. Автор указывает на небольшое упражнение для отработки практики: попробуйте представить себе что вы делаете утром после пробуждения. Укрупните карточки (вместо намолоть кофе — выпить взбадривающий напиток), чтобы убрать индивидуальные детали, беря в фокус не способ реализации, а цель.

Обязательно к прочтению. Для кого эта книга — для ИТ-аналитиков и руководителей проектов.

Приложения

Дискуссия и принятие решений эффективны в группах от 3-х до 5 человек.

Напиши на первой карточке то, что нужно разрабатывать, на второй — исправить то, что сделали в первой, в третьей — исправить то, что сделано в первой и второй.

Если разбивать реализацию, то не на изготовление коржей, крема и т.п., а на изготовление маленьких готовых тортиков. Готовьте истории, как торты — не выписывая рецепт изготовления, а узнавая кому, по какому поводу, на сколько человек торт.

Разработка ПО похожа на создание фильма, когда нужно тщательно разработать и вылизать сценарий, организовать сцену, актеров и пр перед началом съемок.

Ресурсов всегда будет не хватать.

20% усилий дают ощутимый результат, 60% дают непонятно что, 20% усилий идут во вред — вот почему важно сфокусироваться на обучении и не отчаиваться в случае негативного результата.

Фокусируйтесь на некоторых проблемах. Общайтесь с пользователем напрямую, почувствуйте себя в его шкуре.

Детализация и проработка истории для оценки — самая муторная часть scrum, сделайте обсуждения стоячими в режиме аквариум (у доски обсуждают 3-4 человека, если кто то хочет участвовать, он заменяет кого-то).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть