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

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

Хорошие пользовательские истории следуют правилам, описанным Биллом Вейком (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-го года от Ричарда Лоуренса

Как разделять истории пользоватей — четкий и понятный алгоритм действий

Share

Leave a Reply