Большинство User Stories могут быть декомпозированы. Иногда сложно найти лучший способ декомпозиции в конкретном случае, однако чаще всего это возможно. Если User Story можно декомпозировать на несколько более мелких, то ее называют составной.
Другой тип историй – несоставные истории. Такие User Stories нельзя декомпозировать. Есть ряд причин, почему большие/несоставные истории, перетекающие из спринта в спринт, плохо влияют на работу команды и продукт в целом. Вот лишь некоторые из этих причин:
- Скорость команды становится менее предсказуемой с каждым спринтом
- Увеличивается риск того, что разработчик запутается в ожиданиях стейкхолдеров, не имея возможности получать своевременную обратную связь
- У команды появляется плохая привычка оставлять незаконченную работу в конце итерации
Использование точек прогресса (Progress Points) для отслеживания достижений
Итак, что же в такой ситуации должна делать Agile-команда?
Когда нельзя найти подходящего способа декомпозировать User Story, нужно искать точки прогресса.
Точка прогресса — это любая точка в процессе разработки функционала (обычно непосредственно во время написания кода), в которой разработчик может оценить проделанную работу.
Чтобы определить точки прогресса, спросите у разработчика, который занимается недекомпозируемой историей, в какой момент во время работы над задачей ему захочется поделиться результатом или попросить своего коллегу с техническим бэкграундом проверить то, что он сделал.
На свете нет такого разработчика, который хотел бы два месяца работать над историей без возможности поделиться каким-то хотя бы промежуточным результатом с коллегами и получить удовлетворение от результата.
Примеры точек прогресса
В качестве примера предположим, что разработчик работает над сложным кодом для взаимодействия с удаленной системой. Он ожидает, что потребуется две или три итерации.
Первой точкой прогресса будет то, что первая транзакция передаётся из одной системы в другую. Никакую проверку ошибок или обработку на этом этапе мы не выполняем, но первый обмен с другой системой будет точкой, в которой разработчик может поделиться своим достижением.
Второй точкой выполнения может быть увеличение типов транзакций, которыми обмениваются системы.
После того, как определены точки прогресса, некоторые из них могут быть довольно легко выражены в виде пользовательских историй. Таким образом, точки прогресса помогают разработчикам определить естественные вехи, которые они достигнут во время реализации большой истории.
Использование точек прогресса в Scrum
Определив одну или несколько точек прогресса в рамках недекомпозируемой User Story, используйте их в качестве вех. Попросите разработчика определить, сколько точек прогресса можно достичь в ходе предстоящей итерации, а затем используйте это для отслеживания хода выполнения.
А как вы решаете проблему сложных User Stories?
Сталкивались ли вы с подобной проблемой в вашей команде? Как вы решали эту проблему? Что еще вы пробовали, чтобы сделать более предсказуемой и управляемой работу со сложными историями? Пожалуйста, поделитесь своими мыслями в комментариях ниже.