Для чего мы нарезаем крупные пользовательские истории на более мелкие? С виду может показаться, что мы выполняем лишнюю и никому не нужную работу, но так ли это? В этой статье я постараюсь дать ответ на этот в одном из множества контекстов — контексте ценности, поставляемой клиенту и бизнесу.
Хорошие пользовательские истории следуют правилам, описанным Биллом Вейком (William C. Wake), которые мы все знаем как аббревиатуру INVEST:
- Independent (независимая)
Историю можно реализовать отдельно от других историй и она при этом будет нести ценность. Приятный бонус — независимые истории проще планировать. - Negotiable (обсуждаемая)
История — не детальное, подписанное ТЗ. Все детали в начале не нужны и могут быть добавлены позже, как результат сотрудничества с Клиентами и заинтересованными лицами. - Valuable (полезная, несущая ценность)
Истории должны быть полезны для бизнеса и для клиента. Не для разработчиков, тестировщиков и админов. - Estimable (поддающаяся оценке)
Истории используются для планирования спринтов и релизов. Свойство оцениваемости можно рассматривать как функцию от понятности, появляющейся в процессе обсуждения и от компактности, ведь меньший объем работы проще понять и оценить. - Small (компактная)
Не более, чем на спринт. Хорошо, если в 2-недельный спринт можно взять 5-10 историй. И динамику видно и, если не успеем последнюю (с самым низким приоритетом), то 9 в продукт все равно войдут. Если же в спринте одна история и команда не смогла, то команда не смогла спринт целиком. - Testable (можно проверить)
Если историю можно проверить, значит можно сказать, что история выполнена.
Для ответа на главный вопрос статьи следует копнуть в компактность и полезность. Требование к компактности заставляет нас декомпозировать крупные истории. Получившиеся в результате декомпозиции истории точно так же должны удовлетворять требованиям INVEST, то есть ценностность для них никто не отменяет.
Новички нередко начинают нарезать истории по слоям: интерфейс, база данных, шина, компонент авторизации, журналирование. Такие истории действительно компактные, но не независимые и их ценность вызывает серьезные сомнения. Иногда на первых сессиях по составлению историй члены команды впервые узнают, кто их настоящие клиенты, что им нужно и что добавление в таблицу новой колонки «номер купона», реализация сервиса и добавление текстового поля на страницу не то же самое, что «получение скидки на участие в конференции» 🙂
И раз речь зашла про ценность, пусть у вас есть история на три спринта с высокой ценностью. Начинаем нарезать и в обсуждении выясняем, что основную ценность несет совсем небольшая, INVEST-like часть. Бинго! Мы сократили сроки, оставив уровень ценности для бизнеса и клиента на высоком уровне.
Теперь на примере. Дано:
- Большая история «Я, как клиент банка, могу перевести средства со своего счета другому клиенту Банка…»
- Какие-то еще истории с приоритетом пониже
- Скорость команды примем 100 Story Point’ов (SP) в спринт
- Критериями оценки ценности можно пренебречь
Если мы будем выполнять задачи в указанном порядке, то в первый спринт, если не случится неожиданностей, мы поставим 100 единиц ценности, во второй еще 100. Но история нам видится большой и мы решаем нарезать ее на более мелкие:
Выходит, что мы заложили много всего разного, что можно разнести по независимым историям и основную ценность сейчас нам принесет перевод по номеру счета. Остальное важно и нужно, но можно отложить. Перетряхиваем бэклог и получаем:
Теперь в первый спринт мы поставим 190 единиц ценности, во второй еще сколько-то, но суть в том, что мы за счет только лишь декомпозиции истории в первый спринт принесем ценности столько же, сколько нам принесли бы два спринта, следуй мы первоначальному плану. Поэтому, старайтесь нарезать, держите INVEST в уме и сокращайте время вывода изменений на рынок, увеличивая при этом ценность.
Ниже несколько полезных ссылок по теме:
INVEST in Good Stories, and SMART Tasks — описание INVEST
Patterns for Splitting User Stories — не потерявшая своей актуальности статья 2009-го года от Ричарда Лоуренса
Как разделять истории пользоватей — четкий и понятный алгоритм действий