Изображение при помощи kanban-таблицы
Бэклог поставки, содержащий функциональности, обычно изображается при помощи таблицы. Каждая колонка означает определенный этап. Визуальный менеджмент позволяет отслеживать работу над элементами (в данном случае, это функциональности) в течение времени.
Такая таблица называется kanban (не следует путать с методом Kanban, о котором мы поговорим в главе 20).
Рисунок 6.5 – kanban-таблица для работы с функциональностями
Бэклог поставки является основным инструментом коммуникации с заинтересованными сторонами.
• Жизненный цикл истории
Этапы готово и завершено разбивают жизнь истории на два вида деятельности: доработка и реализация. Этот подход очень прост и, как мне кажется, подходит для всех ситуаций, где применяется Scrum.
Далее в контексте рабочего бэклога может применяться двухфазный паттерн. Команда может столкнуться с большим списком историй на стадии доработки. Чтобы уменьшить его, существует паттерн лотков[25]: наглядно изображаются пять этапов жизни истории (два действия, период ожидания между ними, до и после).
Суть этого паттерна – в распределении историй в соответствии с их текущим состоянием.
Во французском употребляется слово bacs (лотки) – как бы фонетическая отсылка к бэклогу.
• Изображение при помощи лотков
Песочница идей
Лоток, заполненный песком, то есть, песочница – это в некотором роде прихожая бэклога. Отправная точка, где каждый, включая разработчиков и заинтересованных лиц, может предлагать истории. Точнее, в песочницу помещаются идеи разных фишек, которые можно добавить в продукт – а они, в свою очередь, могут стать историей (или функциональностью).
Продолжительность их пребывания в песочнице, как правило, небольшая. Это время, за которое Владелец продукта должен понять и обработать внесенную идею.
Песочница изнутри никак не организована. У истории в песочнице мало атрибутов. Отделение песочницы от остальной части бэклога позволяет каждому вносить предложения, а PO обрабатывает их, не мешая работе команды.
Обратная связь имеет большое значение в Аgile-методах, и первоначальным хранилищем для нее является песочница.
Лоток доработки
На этом этапе команда дорабатывает истории текущего сезона, прежде чем реализовать их в спринте. Истории здесь, как сыры, вызревающие в погребе: они требуют тщательного, умелого ухода, внимания и постоянного участия.
Этот лоток выглядит, как обычная воронка.
✓ Приоритетная история уже почти готова. Она небольшого размера.
✓ В середине воронки то, что перейдет к этапу разработки через несколько спринтов. Здесь находятся epics среднего размера.
✓ Наименее приоритетные истории будут разрабатываться еще позднее. Это большие, громоздкие epics, которые впоследствии будут разложены на части.
Рисунок 6.6 – Воронка
Поскольку лоток доработки – воронка, большие истории через нее не просочатся. В следующий лоток попадут только самые маленькие и доработанные.
Стартовый лоток для готовых историй
Scrum использует метафору гонки (спринт), и я предлагаю ее развить.
До спринтерских забегов готовые истории находятся в стартовых блоках. Назовем их стартовым лотком.
Во время спринта выбранные истории начинают забег. Как и в случае спринта с определенным количеством дорожек, число историй, одновременно участвующих в забеге, ограничено.
Это похоже на очередь, в которой история не развивается или развивается понемногу – пока ее не реализуют.
Истории участвуют в спринте. Это гонка, за которой мы внимательно следим. Мы вернемся к ней, когда будем говорить о событиях спринта.
Финишный лоток для завершенных историй
Здесь хранятся законченные истории. Не нужно дожидаться конца спринта, чтобы перенести историю в этот лоток. Это можно сделать прямо в процессе.
Можно считать, что финишный лоток – место, где истории дожидаются окончания спринта и демонстрации. Потом он очищается. Но лучше оставить завершенные истории здесь, пока они не будут введены в эксплуатацию. В этом случае можно распределить истории по спринтам. Это также отличный способ сохранить историю и хронологию.
Семантическая ремарка: при том, что бэклог по определению есть список задач, завершенные истории теоретически в него уже не входят.
Преимущества паттерна лотков
Применение этого паттерна означает для команды (и особенно для Владельца продукта) следующее:
✓ четко видеть, что у каждой части в изображении своя цель, отличная от других;
✓ работать над каждой частью в соответствии с этапом, на котором она находится;
✓ не быть заваленными огромным количеством историй.
Рисунок 6.7 – Структура рабочего бэклога на основе этапов жизни
В этой главе мы рассмотрели бэклог в статике. Следующая будет посвящена бэклогу в динамике и процессу циркулирования историй и функциональностей в потоке.
6.5 Типология историй
Какую работу заносить в бэклог? Бывает, команда тратит время на технические аспекты или на исправление ошибок. Паттерн сториотип [26]может помочь команде разобраться, что стоит записывать в бэклог, а что вносить не нужно.
Этот паттерн основан на идее Филиппа Крухтена: визуализация элемента бэклога по двум основным направлениям [27]:
✓ Ценность – в зависимости от того, добавляет элемент новую или восполняет отсутствующую;
✓ Значимость – в зависимости от того, кому продукт предназначен.
Рисунок 6.8 – Четыре основных типа историй
Эта классификация помогает не забыть внести работу в бэклог. Она будет полезна вкупе с более детальной классификацией критериев завершенности (Definition of Done, DoD).
Это история, которая имеет значение и ценность для заинтересованных сторон.
Большинство из этих элементов адресованы и обещают ценность отдельным группам заинтересованных сторон, в частности, пользователям.
Пример пользовательской истории для команды Peetic.
Для нашего сайта встреч и знакомств для животных – это добавить фотографию своего питомца.
Эта история реализована при помощи кода. Он может включать и другие истории, не содержащие кода и имеющие значение для заинтересованных сторон.
Пример: команда создала видеоинструкцию, показывающую пользователям, как добавить фотографию своего животного.
Баги уменьшают ценность продукта: история, которая к нему относится, больше не выполняет все, что было обещано пользователю. Соответственно, устранение багов поможет восстановить ценность продукта.
Подход к багам в Scrum довольно хитрый. Не надо думать, что все баги хранятся в бэклоге. В первую очередь, нужно постараться выявить и исправить ошибки как можно быстрее, прямо во время спринта. Их не нужно заносить в бэклог. Добавление нового критерия приемки также не считается багом: это новая история.
Какие же баги входят в бэклог? Если по завершении истории, уже в следующем спринте обнаруживается несовершенство, препятствующее ее использованию, такой баг может быть внесен в бэклог. Для команды, освоившей инженерные практики, это лишь незначительные ошибки.
Пример устранения бага: Добавить автоматический разрыв строки в текст заголовка фотографии питомца, который переместится на следующий столбец.
Это работа, которая приносит ценность команде, но не видна заинтересованным сторонам.
Внимание
В пользовательских историях всегда есть техническая работа (дизайн, код), и это очень хорошо. Речь идет о работе, которая не связана с пользовательскими историями, но настолько значительна, что хотелось бы, чтобы она была более видима заинтересованным сторонам.
Внесение технической работы в бэклог оправдано в следующих ситуациях:
✓ необходимо провести техническое исследование, чтобы принять решение о том, как реализовать пользовательскую историю;
✓ есть технические риски, которые надо устранить до реализации пользовательской истории;
✓ необходимо улучшить качество или способ работы команды: инфраструктуру, логистику, новые инструменты, обучение, и т. д.
Пример технической работы. Изучить решение для хранения фото и видео с питомцами (в случае, если эта работа не включена в историю добавить фото или видео).
Когда команда только начинает разработку, реализация историй и техническая работа в рамках первых спринтов направлены на снижение и устранение рисков, а затем, в последующих спринтах – на добавление ценности для бизнеса.
Технический долг – это кошмар любого разработчика ПО. Он есть у всех, но мало кто о нем знает. Его нельзя увидеть, если не находишься в команде. Объяснить его заинтересованным сторонам, да и Владельцу продукта, весьма сложно.
Рисунок 6.9 – Попытка объяснить Владельцу продукта, что нужно сократить задолженность
Технический долг может быть добровольным, если необходима быстрая обратная связь. Тогда в бэклог вносится пометка, чтобы не забыть вернуться к незавершенной части.
В Scrum-подходе команда пытается его избегать, а если он уже есть – погасить как можно скорее: иначе накапливаются проценты, прямо как в случае финансового долга.