Заинтересованные стороны приглашаются по мере необходимости. Команда призывает к участию и экспертов, когда приступает к обсуждению моментов, по которым нужна консультация.
В процессе доработки бэклога поставки Владелец продукта привлекает больше заинтересованных сторон. У него может быть привилегированный собеседник.
Желательно, чтобы доработка носила постоянный характер и проходила в рамках командной работы – например, во время собрания по доработке бэклога.
Таким образом, доработка связана со Scrum-подходом, как и события спринтов, и нет необходимости в ее специальном включении в бэклог.
Есть два возможных варианта проведения собрания по доработке:
✓ Регулярное. Например, по средам. Это самый простой вариант для новичков в Scrum.
✓ По запросу. Scrum-мастер следит за готовностью историй, и в случае их недостатка организует собрание по доработке бэклога (см. главу 20 «Применение Kanban в Scrum»).
Разумно поступает команда, которая посвящает 2 часа в неделю коллективной доработке, что составляет чуть более 5 % ее рабочего времени. В оставшейся части главы мы подробнее рассмотрим случай, когда доработка проводится в рамках заранее запланированных собраний.
Собрание по доработке проходит по крайней мере один раз за спринт. Количество сессий зависит от длины спринта.
Для начала, и даже для двухнедельных спринтов, я рекомендую планировать два собрания. В таком случае во время второго собрания можно сфокусироваться на основной цели, чтобы было достаточно готовых историй к следующему спринту.
Наличие структурированного бэклога облегчает работу по его доработке.
✓ Учитывая, что цель состоит в своевременном наличии готовых историй, выделение этих историй в бэклоге облегчает их отслеживание.
✓ Идеи, запросы, обратная связь, которые Владелец продукта еще не обработал, находятся в песочнице.
Другие истории находят свое место в доработке естественным образом. Итак, у нас есть одно место для доработки и еще два для ожидающих задач, до и после доработки.
Рисунок 7.3 – Доработка рабочего бэклога
Доработка бэклога поставки происходит на более высоком уровне.
7.4 Результат доработки
Доработка является причиной перемещений историй и функциональностей внутри бэклога. Некоторые переходят в статус готово. Другие, которые были в песочнице, передвигаются на этап доработки. Какие-то убираются, делятся на части и т. д.
Готовая история должна быть маленькой и предельно понятной – такой, чтобы была возможность быстро ее закончить и получить обратную связь.
Готовая функциональность должна иметь минимальные риски или не иметь их вовсе.
Команда лучше всех знает, что запланировано на следующие спринты. Благодаря коллективному обсуждению, она укрепляет доверительные отношения с Владельцем продукта и заинтересованными сторонами. Она вовлекается в работу после изучения доступных вариантов.
Рисунок 7.4 – Поток в рабочем бэклоге
Владелец продукта уверен в способности команды разрабатывать элементы, которые были доработаны вместе с ним.
Заинтересованные стороны видят – в частности, благодаря бэклогу поставки – что команда планирует к разработке.
Планирование следующего спринта (глава 9) будет проще и быстрее. Разработка среднесрочного плана (глава 16) также значительно облегчается.
7.5 Доработка рабочего бэклога
Детали и порядок работы, выполняемой во время доработки, зависят от ситуации. Вот возможная последовательность действий и паттернов:
1. Просмотреть список готовых историй. Если их недостаточно, подготовка новых историй – первоочередная задача. (П).
2. Изучить те, что находятся на доработке, чтобы выявить epics и разложить их на части. (Р).
3. Проанализировать песочницу и kanban-таблицу функциональностей с целью обновления списка историй к доработке. (О).
4. Выбрать, что можно удалить. (В).
5. Единогласно решить, что остается на этот сезон, а что уйдет в следующий. (Е).
6. Рассмотреть новые или разложенные элементы (Р).
7. Классифицировать истории в лотке доработки. (К).
Рисунок 7.5 – Доработка
Из описанной последовательности получается акроним ПРОВЕРКа. На практике действия не последовательны: иногда образуются петли и появляются дополнительные пункты.
Есть ли необходимость в заранее готовых историях? Если да, команда рассматривает наиболее приоритетные истории в лотке доработки.
Разговор с РО должен снабдить команду знаниями. Решение о готовности истории принимается, когда команда считает, что риски не закончить ее во время спринта уменьшены. Участники опираются на критерии готовности.
Если применить паттерн 6К, обсуждение будет сфокусировано на К, которых не хватает в истории, чтобы счесть ее готовой – в частности, на возможности краткого обзора во время демо и определения и обсуждении рисков, стоящих перед командой.
• Возможность краткого обзора на демо с условиями приемки
Первое, о чем стоит подумать: как провести демо? того, что команда собирается показать во время демонстрации этой истории. Можно представить сценарий и продумать условия приемки.
Пример истории запись на выставку». Можно определить условие успеха:
✓ Заявка принята – запись собаки на выставку прошла успешно.
Другое условие – условие неудачи.
✓ Заявка отклонена – запись не удалась, достигнут предел допустимых заявок.
Второе условие может соотноситься с той же историей или входить в другую, новую. Это искусство декомпозиции истории.
• А дальше – BDD
Условие приемки относится к исполнению истории. Поведение истории во время ее реализации зависит от начального состояния и параметров исполнения. Практика BDD (Behaviour Driven Development) позволяет описать это поведение на примере программируемого устройства.
Каждый тест формально состоит из трех элементов:
✓ состояние перед исполнением теста (речь о контексте теста);
✓ событие, которое запускает исполнение истории;
✓ состояние после реализации (речь об ожидаемом результате).
Формально, текстовая структура BDD выглядит следующим образом:
✓ Дано – контекст и последствие контекста.
✓ Когда – событие.
✓ Тогда – результат и другой результат.
На английском это Given When Then.
Такой способ работы особенно подходит для интерактивных приложений. Он делает возможными короткие и быстрые тесты, так как описывается реакция только на одно событие – то, что запускает историю.
Пример истории заявка на оформление регистровой родословной для собаки
Как хозяин породистой собаки, я оформляю для своего щенка регистровую родословную, чтобы получить документ о его происхождении.
Можно использовать BDD для условия принятия:
Дано: хозяин породистой собаки и событие оформления регистровой родословной для данной породы.
Когда: хозяин записывает собаку соответствующего возраста на оформление регистровой родословной.
Тогда: он проинформирован о своей заявке и количество заявок увеличено.
Советую прописывать пункт дано в прошлом, когда в настоящем и тогда в будущем времени.
• Риски сведены к минимуму
Обсуждение рисков может иметь технический характер.
Часто команда задумывается над концепцией истории, чтобы снизить риски ее реализации.
И продолжает в таком духе, пока не будет достаточно готовых историй.
Это очень важно: в случае, если к следующему спринту не будет достаточно готовых историй, команда потратит на это столько времени, сколько ей потребуется.
Истории, которые должны быть разложены на части в первую очередь – это истории, которые пойдут в работу во время следующего спринта или спринта за ним.
Понимание, насколько необходимо разбить данную историю и как именно это сделать, требует опыта. Команде в этом поможет паттерн разделение.
• Паттерн «Разделение»
Этот паттерн предлагает 9 возможных путей для размышлений о декомпозиции истории.
Рисунок 7.6 – Паттерн «разделение истории»
Ниже примеры основных направлений.
Вариации на тему Данных
Пример истории добавить питомца в мой профиль
Если система предполагает разных питомцев и возможность создания истории различна для каждого вида, то создется так много историй, сколько питомцев есть в системе: добавить собаку, добавить кошку (не надо выгуливать), добавить хамелеона (без фото) и т. д.
Разработчики рискуют переделывать всю работу, если с самого начала не задумываются об универсальном дизайне. Ничто не мешает подумать об этом с самой первой истории.
Разложение на части по бизнес-правилам
В случае, если правила ограничивают доступ к функции, можно определить историю, которая игнорирует эти правила, а затем другие истории, чтобы их принять. Первая история позволяет обучиться, она приносит ценность знаний.
Пример. Можно предложить поиск предков породистой собаки, но зарезервировать эту услугу за владельцами собак, которые приобрели корм для питомца за 100 € и являются членами клуба Peetic более одного года.