понедельник, 29 июля 2013 г.

Как писать пользовательские истории (User Stories)

Вы "вляпались" в Scrum и начали описывать требования к продукту в виде User Stories. Есть Шаблон - он понятен, но жутко не удобен. Но это же Scrum - просто делай, и будет магия.



Но проблема в том, что без понимания эта магия не работает. В результате вы "тяните эту баржу" что есть сил. Но никакой полезности от историй вы не получаете.

Приходите на планирование. РО читает название истории. Все делают удивленные лица. РО рассказывает, что нужно сделать в рамках этой историй. Все кивают. Оценивают. И далее нужно лишь запомнить, что под этим большим, непонятным названием истории с оценкой "5" скрывается задача на добавление нового поля на форму и в БД.

Зачем нужны User Stories?
Про это написано куча статей. Не верите в User story - не используйте.

Мои правила на написание User Story


  1. Есть один actor 
  2. Есть одно действие
  3. Есть одна ценность / value / impact. Я выделяю ее ЗАГЛАВНЫМИ БУКВАМИ при написании User story.  

Actor 

C актером все более-менее просто. Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в  начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла - значит эта часть бесполезна.
Вы определили роли в Системе и поняли что их не очень много - Пользователь, Оператор и Админ. И креативите по 100 историй, которые начинаются как "Как Пользователь Я ...". У вас закрываются  несколько спринтов, истории которых начинаются одинаково. Зачем вам это нужно?  Да, это бесполезно.
Джеф Паттон предлагает следующее:

  1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп. 
  2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли "Пользователя системы"
  3. Пишите истории с точки зрения этих актеров указывая их уникальные названия. 
  4. В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие - для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны.

Действие


Наверное здесь сложно ошибиться - это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное "КАК"-решение.

Ценность

Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите "чтобы ..." и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?

Отказаться от формулировки "чтобы". Это корень зла. ДА, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.

Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.

Представим что вы создали историю - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение".
У меня Аcceptance Сriteria - это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ". То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.

Но в чем ценность того, что аналитик стал получать отчет быстрее?
Здесь можно перейти к общей постановке Цели для продукта. Чтобы прийти к такой истории вы:

  1. Вы построили Impact mapping
  2. Вы определили Цель и метрику на нее. Например, "ускорение сроков согласования инвестиционных бюджетов". 
  3. Вы определили что "инвестиционный аналитик" может вам помочь в достижении этой цели.
  4. Вы сделали предположение что если аналитик будет получить отчет №17 быстрее, то это приведет вам к вашей цели.  
  5. Потому данная история - это проверка данного предположения достижения цели.  
То есть смысл Impact map - это трассировка от User story к общей Цели продукта. Если такой связи нет и вы не можете ее найти - значит вы делаете что-то бесполезное.

То же самое можно сделать в любой момент времени на любом этапе создания продукта. Вы знаете что нужно сделать и это будет полезно, но вот ценность определить однозначно не можете. Вы видите десятки вариантов то, что нужно написать в "чтобы ...". Постройте путь до цели в Impact map. Найти то влияние что вы должны оказать на актера в результате. Не пишите всякую чушь, в которую сами не верите.    

Удачи! 

Комментариев нет:

Отправить комментарий