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

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

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

• Явное ограничение

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

На схеме мы видим ситуацию, когда команда добавила две истории во время спринта.

Процесс планирования спринта выглядит следующим образом: собрание заканчивается, когда достигается предел, и команда пополняет список, когда истории заканчиваются.

Рисунок 20.4 – Ограничение незавершенных задач

Этот паттерн дополняет роение. Ограничение соответствует количеству одновременно находящихся в процессе историй.

Следуя принципу приверженности и вовлечения, команда не ставит под сомнение концепцию цели спринта. Это означает, что первые истории среди тех, что не вошли в спринт, также будут реализованы.

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

Рисунок 20.5 – Повтор событий спринта

• Преимущества

Основное преимущество заключается в том, что команда лучше реагирует на изменения.

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

Индикаторы спринта, как, например, burndown-график, становятся ненужными.

Упрощается создание доски спринта. Для историй и задач в процессе необходимо меньше места, и их количество стабильно от спринта к спринту (введенное ограничение меняется нечасто).

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

Команда Peetic установила ограничение в три истории. Это значит, что в бэклоге всего три позиции для историй в текущем спринте, одна из которых отведена для технической работы.

• Риски

Этот паттерн требует быть осторожным в отношении следующих пунктов:

✓ Поэтапное планирование затрудняет определение цели спринта и ее достижение.

✓ Добавление историй во время спринта требует хорошего понимания критериев готовности.

✓ Простота процесса может сподвигнуть Владельца продукта запросить еще больше изменений во время спринта.

20.3.2 Ограничение в рабочем бэклоге

Для лучшего понимания паттерна ограничение с самого начала необходимо сначала ознакомиться с главами 6 и 7.

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

Паттерн лотков состоит в визуализации рабочего процесса, что совпадает с первым принципом Kanban. Ограничение лотков позволит еще сильнее сократить список задач.

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

• Ограничение в стартовом лотке

Верхний предел позволяет ограничить количество готовых историй.

Нижний предел для готовых историй позволяет перейти к сессии доработки для дальнейшего пополнения списка.

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

Рисунок 20.6 – Ограничение в стартовом лотке

• Ограничение в лотке доработки

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

Ограничение имеет смысл, если лоток доработки еще не ограничен рамками сезона.

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

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

20.4 Ограничение функциональностей

Ограничивать истории хорошо, ограничивать функциональности еще лучше. Верно ли это утверждение? Давайте проверим.

20.4.1 Ограничение столбцов