Все о SCRUM. Изучение, разработка, интеграция

2. Изучить те, что находятся на доработке, чтобы выявить epics и разложить их на части. (Р).

3. Проанализировать песочницу и kanban-таблицу функциональностей с целью обновления списка историй к доработке. (О).

4. Выбрать, что можно удалить. (В).

5. Единогласно решить, что остается на этот сезон, а что уйдет в следующий. (Е).

6. Рассмотреть новые или разложенные элементы (Р).

7. Классифицировать истории в лотке доработки. (К).

Рисунок 7.5 – Доработка

Из описанной последовательности получается акроним ПРОВЕРКа. На практике действия не последовательны: иногда образуются петли и появляются дополнительные пункты.

7.5.1 Подготовка новых историй

Есть ли необходимость в заранее готовых историях? Если да, команда рассматривает наиболее приоритетные истории в лотке доработки.

Разговор с РО должен снабдить команду знаниями. Решение о готовности истории принимается, когда команда считает, что риски не закончить ее во время спринта уменьшены. Участники опираются на критерии готовности.

Если применить паттерн 6К, обсуждение будет сфокусировано на К, которых не хватает в истории, чтобы счесть ее готовой – в частности, на возможности краткого обзора во время демо и определения и обсуждении рисков, стоящих перед командой.

• Возможность краткого обзора на демо с условиями приемки

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

Пример истории запись на выставку». Можно определить условие успеха:

✓ Заявка принята – запись собаки на выставку прошла успешно.

Другое условие – условие неудачи.

✓ Заявка отклонена – запись не удалась, достигнут предел допустимых заявок.

Второе условие может соотноситься с той же историей или входить в другую, новую. Это искусство декомпозиции истории.

• А дальше – BDD

Условие приемки относится к исполнению истории. Поведение истории во время ее реализации зависит от начального состояния и параметров исполнения. Практика BDD (Behaviour Driven Development) позволяет описать это поведение на примере программируемого устройства.

Каждый тест формально состоит из трех элементов:

✓ состояние перед исполнением теста (речь о контексте теста);

✓ событие, которое запускает исполнение истории;

✓ состояние после реализации (речь об ожидаемом результате).

Формально, текстовая структура BDD выглядит следующим образом:

✓ Дано – контекст и последствие контекста.

✓ Когда – событие.

✓ Тогда – результат и другой результат.

На английском это Given When Then.

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

Пример истории заявка на оформление регистровой родословной для собаки

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

Можно использовать BDD для условия принятия:

Дано: хозяин породистой собаки и событие оформления регистровой родословной для данной породы.

Когда: хозяин записывает собаку соответствующего возраста на оформление регистровой родословной.

Тогда: он проинформирован о своей заявке и количество заявок увеличено.

Советую прописывать пункт дано в прошлом, когда в настоящем и тогда в будущем времени.

• Риски сведены к минимуму

Обсуждение рисков может иметь технический характер.

Часто команда задумывается над концепцией истории, чтобы снизить риски ее реализации.

И продолжает в таком духе, пока не будет достаточно готовых историй.

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

7.5.2 Разложение на части

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