Аннотация

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

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

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

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

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

Отзыв

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

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

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

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