В гибкой разработке мы используем пользовательские истории. Они представляют собой задачу — создать одну обособленную функциональность, которая имеет ценность для пользователя.
Большинство историй можно разделить для удобной работы, даже если критерий не очевиден. Нечасто, но в разработке встречаются комплексные истории — те истории, которые нельзя разделить на несколько более мелких, нельзя выделить подчасти.
Из-за большого размера история будет занимать несколько спринтов. Это мешает работе. Майк Кон в статье про работу со сложными историями говорит, что их вред в следующем:
- скорость менее предсказуема от спринта к спринту,
- есть риск сбиться с пути и потратить много времени на неверный результат,
- развивается плохая привычка оставлять незавершенную работу в конце итерации.
Техники разделения неделимых историй
Разделение на шаги
Несмотря на то, что история сложная, команда не сможет сделать её в один момент. Нужно престать думать о ней как об одной вещи. Для этого предложите команде взять стикеры и написать шаги, которые нужны для выполнения этой истории.
Этот способ позволяет выделить важные детали в одной истории. На этом этапе шаги будут абстрактными, и это нормально. Некоторые шаги пока могут отсутствовать.
Ценность
Когда выделены важные детали, можно группировать разные шаги по ценности. Это происходит на планировании в совместной беседе между владельцем продукта и командой.
Группировка происходит по разным признакам, например, это может быть деление на задачи, связанные с интерфейсом, конфигурацией, тестированием. Менее значимые детали, которые дополняют эту задачу, могут оформляться как отдельные истории и реализовываться позже. В результате группировки формируется несколько конкретных задач.
В этом подходе используется другой взгляд на ценность. В сложной истории её части не будут готовыми к выпуску, но её деление помогает продвигаться и сотрудничать с клиентами в процессе создания.
Схема: прописываем разные шаги, группируем их по одному основанию
Точки прогресса
Другой способ — искать точки прогресса для неделимой истории.
Точка прогресса — это этап в разработке, когда достигается какой-либо промежуточный результат.
Точки определяются на планировании. Scrum-мастер может задать простой вопрос: «На каких этапах реализации истории вы бы сказали своим коллегам, что пора проверить ваш код?»
Пример, который приводит Кон:
Предположим, что разработчик пишет сложный код для взаимодействия с удаленной системой. Разработчик предполагает, что на это потребуется две или три итерации. Прогресс может быть в том, что первая транзакция отправляется (или получается) из другой системы. Никакой проверки ошибок или обработки пока не выполняется, но первый обмен с другой системой будет точкой, о которой можно рассказать команде.
Следующей точкой прогресса станет увеличение удачных транзакций, обнаруженных ошибок или повторных попыток.
Многие из этих точек можно записать как истории пользователей. Такой взгляд помогает определить естественные вехи, которые появятся во время реализации большой истории.
А вы часто сталкиваетесь с историями, которые сложно разделить? Как работаете в таком случае и какие техники можете порекомендовать?
