Первая история. Найти предков моей собаки.
Вторая история. Ограничить поиск только для авторизованных лиц.
Оптимизация, отличная от производительности
В случае, если история слишком большая, команда не сможет ее завершить за один спринт и при этом ничем особо не рискует – можно попробовать сделать ее за первый спринт, не беспокоясь о производительности. Затем, уже в следующем спринте, заняться другой историей о нефункциональных требованиях.
Пример. Первая история касается поиска. Ее цель – сначала предоставить результаты. Затем другая – цель уже в оптимизации поиска, например, чтобы результаты отображались менее чем за две секунды.
Spike
Если разработчики отмечают, что для создания истории есть несколько технических решений, есть смысл разложить ее на две части: первая – для изучения решений и выбора одного из них, вторая – для реализации с выбранным решением.
Исследование под названием spike, или шип [28], помогает снизить риски при ее реализации.
Начиная с этапа песочницы, Владелец продукта и команда обсуждают, что делать с предложениями. Варианты следующие:
1. переместить идею на этап доработки, чтобы включить в текущий сезон;
2. удалить ее;
3. решить, что это предложение больше истории, а то и epic истории, и переместить ее в kanban-таблицу функциональностей.
Рисунок 7.7 – Выход из песочницы
Нужно регулярно чистить бэклог.
Идеи того, какие задачи еще можно включить в бэклог, обычно идут потоком и предполагают куда больше работы, чем может позволить себе команда.
Новые идеи представляют собой цикл обратной связи. Если ничего не делать, бэклог будет постоянно увеличиваться.
Элементы, которые застаиваются в конце списка, являются первыми кандидатами на удаление.
Удаление элементов, находящихся на этапе доработки, также возможно. Владелец продукта вносит их в список в качестве возможных вариантов, на этом уровне обязательств нет. Удаление уже готовых историй должно быть исключительным, но, опять-таки, возможно. Лучше сразу отбросить то, что тратит время команды и не несет никакой ценности.
Принцип паттерна ледяного лотка состоит во временной очистке историй, чтобы во время доработки более четко увидеть текущую ситуацию. Паттерн позволяет визуально уменьшить количество историй на этапе доработки.
Паттерн касается команд, у которых темп сезона задается благодаря вводу в эксплуатацию. В конце каждого сезона безусловно остаются истории, которые уходят в разработку на следующий сезон. Их можно заморозить в ледяном лотке до нужного момента, чтобы не тратить на них время сейчас.
Истории, находящиеся в ледяном лотке, заморожены до следующего сезона. Когда он начнется, эти истории будут разморожены и вернутся на этап доработки.
Суть паттерна не в том, чтобы поместить в ледяной лоток все запросы, которые не были приняты РО. Ледяной лоток – не мусорка. По решению Владельца продукта ненужные запросы безжалостно удаляются. Только те истории, что представляют интерес для следующего сезона, будут заморожены в ледяном лотке. Период заморозки длится несколько недель. Ледяной лоток необходимо очищать в начале каждого нового сезона.
Этот лоток позволяет ограничить количество историй в доработке, оставляя в стороне истории, которые не имеют краткосрочного интереса для команды, но которые участники не хотят удалять, потому что они имеют ценность для продукта.
Распределение историй между доработкой и ледяным лотком помогает команде лучше ориентироваться в задачах на сезон.
Это действие опционально и касается добавленных или разложенных историй со времени последней сессии доработки. Команда должна решить, не слишком ли история большая и стоит ли ее разбить на части.
Оценка помогает команде сделать прогноз на сезон.
Этот вид деятельности наиболее часто реализуется при помощи покера планирования. Эта игра служит предлогом для разговоров между РО и командой. Она полезна во время первых спринтов, когда команда еще недостаточно владеет навыками и техниками доработки.
Рисунок 7.8 – Оценка усилий
Другие проблемы и способы оценки мы рассмотрим в главах 16 «Планирование на среднесрочную перспективу» и 18 «Наглядность при помощи индикаторов».
При добавлении элементов к доработке можно их сразу упорядочивать в списке. Новые элементы не всегда помещаются в конец списка.
Владелец продукта самостоятельно изучает порядок и представляет его команде для обсуждения, которое будет включать стоимость и зависимости.
Иногда участники настаивают на высокой приоритизации технической работы, которая кажется им наиболее важной. Вся команда участвует в приоритизации, но в случае разногласий окончательное решение – за Владельцем продукта.
Количество историй в доработке не должно увеличиваться (не более двадцати-тридцати элементов). Их порядок обновляется на каждом совещании, благодаря этому сам процесс упорядочивания не занимает много времени.
Порядок (или порядковый приоритет) соответствует последовательности реализации историй. Порядок историй основан на порядке функциональностей. Так как мы стремимся быстро закончить функциональность, составляющие ее истории остаются связанными.
Между историями могут быть зависимости, которые влияют:
✓ на другие истории,
✓ на людей, которые могут реализовать историю,
✓ на сроки.
7.6 Доработка бэклога поставки
Во время рассмотрения паттерна поставки/работы мы поняли, насколько важно общение с заинтересованными сторонами. Их следует вовлекать в процесс доработки бэклога поставки.
Рисунок 7.9 – Доработка бэклога поставки
Этот процесс в целом похож на доработку рабочего бэклога, за исключением некоторых нюансов в организации и содержании.
Необходимо пересмотреть время доработки (когда?) и участников процесса (с кем?).
Это можно делать во время доработки историй в начале регулярных командных сессий. Однако лучше иметь отдельные сессии, посвященные непосредственно доработке бэклога поставки, так как в процессе активное участие принимают заинтересованные стороны. О проведении специальных сессий и приглашении нужных людей должен позаботиться Владелец продукта.
Нужные люди – в данном случае, это привилегированные собеседники Владельца продукта (см. главу 4).
Говоря о команде. Если при доработке рабочего бэклога необходима вовлеченность всех участников, то при доработке бэклога поставки их участие опционально. Достаточно одного или двух человек. Идеально иметь группу из 3–5 человек: РО, как минимум один участник от заинтересованных сторон и один участник от команды разработки.
Как и для рабочего бэклога, доработка бэклога поставки состоит в ПРОВЕРКе: подготовка новых элементов, разложение их на части, обновление списка к доработке, выбор элементов к удалению, единогласное распределение, рассмотрение и классифицирование элементов.
В работе с функциональностями особенно важен последний этап. Он влияет на порядок в рабочем бэклоге: если функциональность стоит в приоритете, команда работает над составляющими ее историями.
Как правило, при приоритизации используются следующие критерии: – коммерческая ценность (будет предоставлена при вводе в эксплуатацию), ценность обучения (будет получена в результате обучения), риски, стоимость (ожидаемые ресурсы для реализации) и развитие во времени (заставляющее задуматься о цене задержек).
Мы подробнее поговорим об этих критериях в главе 15: они особенно важны для первой сессии доработки первоначального бэклога.
Между жизненными циклами функциональности и составляющих ее историй есть зависимости. Интересно в них разобраться, но не стоит из них делать свод правил, определяющий подход к работе над бэклогом.
Когда изучаешь эти зависимости и закономерности, стоит задать себе несколько вопросов.
✓ Во время какого этапа развития функциональности мы начинаем создавать соответствующие ей истории (первое время epics)?
✓ Какие истории нужно определить и завершить, чтобы можно было считать функциональность готовой?
✓ Если все истории, составляющие функциональность, завершены, что нужно сделать, чтобы завершить функциональность?
✓ Если команда проводит оценку, есть ли корреляция между историями и функциональностями?
7.7 Антипаттерны
Ситуация. Покер планирования – это способ коллективной оценки историй. Так как он способствует общению внутри команды и с Владельцем продукта, его практика систематизирована, но команда занимается им исключительно во время сессии доработки и тратит на это очень много времени.
Последствия. Существует риск пренебречь самым важным – не оценкой, но обсуждением того, как подготовить и завершить историю за один спринт.
Как сделать лучше? Оценка – это одно из (опциональных) действий этапа доработки. Использовать акроним ПРОВЕРКа, чтобы во время доработки сделать все необходимое.
Прочитать главу 16, посвященную основной цели покера планирования.