Agile Mindset

Микросервисы, архитектура, devops и agile

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

Posted on Author SergeyPosted in AgileLeave a Reply

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

Хорошие пользовательские истории следуют правилам, описанным Биллом Вейком (William C. Wake), которые мы все знаем как аббревиатуру INVEST:

Для ответа на главный вопрос статьи следует копнуть в компактность и полезность. Требование к компактности заставляет нас декомпозировать крупные истории. Получившиеся в результате декомпозиции истории точно так же должны удовлетворять требованиям 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

Добавить комментарий