Итеративные подходы к разработке продуктов требуют декомпозиции и работы с маленькими частями. Это улучшает производительность и управляемость. Несмотря на то, что выгода от такого подхода кажется очевидной, команды раз за разом стараются решить все проблемы в одной задаче, а заказчики пытаются впихнуть все требования в один спринт. Аджайл коуч Дуайт Кингдон, в своей статье собрал основные аргументы в пользу разумного уменьшения размера пользовательских историй, с которыми работают команды, и изложил свой подход к уменьшению размера этих историй.

Я часто сталкиваюсь с командами, которые любят большие пользовательские истории. Зачем тратить время на написание, планирование и оценку множества маленьких историй, когда вы можете написать, спланировать и оценить только одну большую историю? Большие истории повышают эффективность, не так ли? Не обязательно.

Почему стоит уменьшать пользовательские истории?

Фокус: Маленькие истории помогают нам сосредоточиться на доведении до конца. Когда мы работаем над большими историями, так легко оказаться заваленным деталями. Небольшие истории также способствуют повышению удовлетворенности команды, люди получают прилив дофамина, когда они что-то заканчивают.

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

Предсказуемость: По результатам реализации небольших историй можно построить более точный тренд скорости. Это снижает изменчивость и улучшает предсказуемость. Относительные исходные оценки, использующие последовательность Фибоначчи, по своей сути все менее точны для больших значений. Этот эффект называется «конус неопределенности». Таким образом, история из 13 или 20 сторипойнтов, вероятно, гораздо менее предсказуема, чем несколько историй из 2, 3 или 5 сторипойнтов.

Гибкость: Небольшие истории дают возможность чаще получать обратную связь и корректировать курс. Они обеспечивают большую гибкость и дают нам возможность лучше адаптироваться и подстраиваться. Когда обстоятельства меняются или истории теряют актуальность, затраты на реконструкцию или удаление маленькой истории существенно ниже.

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

Снижение риска: большие истории увеличивают риск того, что команда не выдаст ничего в конце спринта, который завершен на 100%. Командная емкость подобна воронке. Когда мы пытаемся протолкнуть через неё большой объект (большие истории), воронка забивается. Например, разработчик, работающий над большой историей, также может быть единственным, у кого есть навыки, необходимые для завершения другой критической истории.

Как мне создавать небольшие истории?

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

• Если в одной пользовательской истории есть несколько результатов, все ли они необходимы прямо сейчас? Есть ли разделение 80/20, обеспечивающее большую часть ценности? Можете ли вы реализовать то, что дает оставшиеся 20% в другой истории?
• Есть ли в истории пользователя несколько бизнес-сценариев или персон? Могут ли сценарии быть построены отдельно, есть ли возможность рассмотреть разных персонажей в отдельных историях? Можно ли упростить сценарий?
• Можно ли реализовать «позитивный сценарий» первым без каких-либо исключительных условий? Условия исключения часто могут быть помещены в дополнительные истории.
• Есть ли несколько платформ или интерфейсов (входов или выходов), связанных с этой пользовательской историей? Можем ли мы развивать их отдельно?
• Есть ли в пользовательской истории несколько операций, например, CRUD? Можем ли мы реализовать одну операцию за раз?
• Какие тестовые сценарии применяются? Являются ли некоторые сценарии сложными и не очень актуальными? Можно ли разработать более простую первую итерацию, чтобы подтвердить работоспособность сценария?
• Большая часть сложности истории связана с нефункциональными требованиями, такими, как безопасность или производительность? Если это так, можно ли отделить историю, чтобы сначала заставить функциональность работать, а затем доработать ее, чтобы выполнить нефункциональные требования?

Насколько маленькой должна быть «маленькая история»?

Это очень субъективный вопрос, и он зависит от нескольких факторов, включая возможности команды, продолжительность спринта и другие. Хорошей отправной точкой для определения размера истории, является использование критериев I.N.V.E.S.T.

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