Разбиваем требования для успеха Agile проекта
| August 15, 2012 | Posted by admin under Практики, Статьи |
Авторы: Ellen Gottesdiener/Mary Gorman
http://www.stickyminds.com , Slicing Requirements for Agile Success
Если вы боретесь за то, чтобы ваша команда и заказчики сообща подходили к пониманию эволюционирующих нужд продукта, и при этом постоянно шла поставка ценности, вы не одни. Приходится решать множество задач, включая: аккуратную оценку работ, определение условий удовлетворенности (критерии “готовности”) для требований, изменение требований после того, как вы начали разработку, невозможность поставить в срок из-за появления новых требований в середине разработки, неспособность протащить новые требования, когда работа уже движется, из-за слишком большой загрузки, а также неспособность удовлетворить условиям поставки.
Типичная проблема – это “крупные” требования. Они слишком велики, плохо приоритезированы, или команда не понимает всех деталей, которые требуются для эффективной реализации.
Мы использовали множество методик “деления”, чтобы способствовать эффективной работе agile команд над пользовательскими историями. [1] Популярные подходы – деление по бизнес процессам, операциям с базами данных (например, создать, прочитать, изменить, удалить), группам данных, низкая точность и высокая точность, и т.д. [2, 3, 4]
Некоторым командам трудно последовательно применять стратегии разбиения историй. Некоторые фокусируются скорее на техническом аспекте этих стратегий, вместо того чтобы основывать свою работу на твердом понимании нужд пользователей. Некоторые упускают из виду нефункциональные требования, уделяя внимание только функциональным.
Если что-то из этого относится к вашей команде, вам стоит прочитать то, что написано далее. Мы надеемся, что наш опыт поможет вам улучшить свою работу.
Выделение опций пользовательской истории по ценности
Наша методика разбивки требований основывается на следующем допущении – у команды и заказчика есть общее видение продукта и целей, и есть согласие в том, что составляет ценность и как ее измерить. Наша цель – дать практический способ извлечения требований из высокоуровневых потребностей, чтобы команда и заказчик могли постепенно и небольшими частями поставить работающее ПО.
Для этого команда и бизнес заказчики должны вместе просмотреть опции требований, определить наиболее важные и разделить крупные истории на управляемые части. Оптимальную методику разбивки можно было бы использовать во всех предметных областях, усилить дисциплину анализа требований, быстро изучить и эффективно использовать, привлечь product owner-ов, вернуть “пользователя” в пользовательские истории, короткие истории можно было бы напрямую использовать для создания приемочных тестов, и углубить знание требований у всей команды.
Мы определили следующий простой способ разбивки пользовательских историй. Мы основываемся на собственном опыте того, насколько мощными оказываются небольшие, тестируемые пользовательские истории. Кроме того, нас вдохновили работы Chris Matts и Olav Maasen по реальным опциям и введению фич [5, 6], Bill Wake и других по разбивке историй [1, 2, 3, 4], Jeff Sutherland и других по готовым требованиям [7, 8, 9, 10], Dean Leffingwell по lean баклогу [11], и Mike Cohn по минимизации передач в команде[12].
Что такое готовая пользовательская история?
Готовые истории – небольшие, понятные и имеющие ценность пользовательские истории. Другие названия историй в этом состоянии – «правильного размера», «разбитые на части», «уровня итерации», «поставленные в очередь для разработки» и «проанализированные» истории.
Готовая пользовательская история имеет большую ценность с точки зрения product owner-а, ее нужно поставить в следующем релизе или итерации, она хорошо понятна команде разработки, чтобы ее можно было оценить, запланировать, взять обязательство по реализации и поставить.
Когда вы делаете пользовательские истории готовыми?
Вы хотите, чтобы пользовательские истории стали готовыми как раз перед планированием, как часть предварительного анализа или чистки баклога. Вы чистите баклог постоянно, чтобы его элементы были готовы до оценки и планирования — используете ли вы ограниченные по времени итерации или механизм постоянного потока, такой как канбан. Команда должна быть готова, хорошо знать требования, чтобы определить критерии приемки, сделать надежную оценку работ, и выполнить договоренности, связанные с поставкой. Команда проводит регулярные, неформальные встречи посвященные требованиям, взаимодействует с product owner-ом, чтобы чистить баклог, вносить изменения в требования и готовить пользовательские истории к предстоящим циклам поставки.
Расширить-затем-сократить
Чтобы пользовательские истории стали готовыми, наша методика разбивки историй следует шаблону расширить-затем-сократить (expand–then–contract). Сначала в фазе расширения для каждой пользовательской истории product owner прорабатывает всевозможные опции. Затем в фазе сокращения команда и product owner проходятся по опциям и быстро сокращают их, основываясь на их ценности; это занимает считанные минуты. В результате мы получаем небольшую, сжатую историю, готовую к разработке.
Давайте рассмотрим этот шаблон более детально.
В фазе расширения вы начинаете с одной крупной истории и разбираете опции. Во время анализа вы смотрите на шесть элементов пользовательской истории:
- Кто действует в роли пользователя? Каковы типы и состояния этой роли?
- Какие действия нужны для достижения целей пользователя?
- Над какими объектами данных производятся действия? Каковы типы и состояния этих объектов данных?
- Каких бизнес правил нужно придерживаться для этих действий и объектов данных?
- Какие интерфейсы нужны? Каковы типы интерфейсов — ручной ввод, физические устройства, межсистемные интерфейсы, или пользовательский интерфейс?
- Какие атрибуты качества ограничивают и контролируют пользовательскую историю?
В фазе сокращения product owner взаимодействует с командой, чтобы выбрать нужные опции, используя прозрачные, рациональные критерии. Например, возврат инвестиций, рычаги и события рынка, снижение риска. Используются методики приоритезации, такие как ранжироваие, ценность для заинтересованных лиц, голос заказчика и т.п..
Во время этого процесса, «расширить-затем-сократить», команда и product owner вместе получают важные знания. Когда product owner определяет ценность для каждой опции, он просит команду оценить усилия и риски для ее реализации, что повышает его понимание технических проблем и процесса разработки. Когда члены команды обсуждают опции, они изучают требования. Члены команды выясняют критерии фильтрации опций, которыми пользуется product owner, и это помогает им глубже разобраться в предметной области и в том, какие требования представляют ценность.
Обратите внимание, что эта методика полезна для работы с требованиями к продукту, а не для “технических” историй. И запомните: во время фазы расширения, если какой-нибудь из шести элементов пользовательской истории не имеет опций, просто переходите к следующему элементу.
Разбивка историй с помощью анализа опций: пример
Рассмотрим эту методику на примере.
Вы начинаете с того, что выбираете историю с высокой ценностью в баклоге. Она могла произойти из высокоуровневой фичи или минимальной фичи имеющей рыночную ценность (minimal marketable feature, MMF). [13] Или это может быть результат декомпозиции более крупных требований, которые называют эпиками.
В agile командах эти истории обычно записываются в следующей форме:
Как [пользовательская роль]
Мне нужно [поведение или действие]
чтобы [бизнес ценность]
Следующим шагом нужно определить, является ли история кандидатом для разбивки.
Что делает историю “слишком большой”? Это отличается от команды к команде. Влияют размер команды, длина итерации или релиза. Некоторые команды стараются сделать свои истории такими, чтобы одну историю можно было реализовать за несколько часов или задень. Другие используют более длинный временной интервал — от двух до трех дней.
Ваша цель – получить набор имеющих высокую ценность, готовых историй, примерно одинакового размера, которые достаточно проанализированы для того, чтобы вы могли оценить, спланировать и поставить их тогда, когда обещаете.
Книги и не только
Рисунок 1 иллюстрирует шесть элементов пользовательской истории.
В нашем примере мы строим приложение для бизнеса, которое предназначено для продажи продуктов, таких как книги, фильмы, музыка и поздравительные карточки. Вы выбираете крупную историю: “Как клиент, я хочу купить продукт который бы мне понравился.” Далее мы рассматриваем опции и определяем ценность для каждой.
Шаг 1: Опции пользовательской роли: типы и состояния
Для анализа пользовательской роли мы рассматриваем опции для типов и состояний. Роль инициирует пользовательскую историю, и у нее есть цель для получения ценности. Имя роли основывается на пользовательском намерении или цели. В пользовательской истории клиент имеет намерение «купить», поэтому мы назвали пользовательскую роль «покупатель».
Работая с product owner-ом, мы определяем типы покупателей:
Типы пользовательской роли
- Частный Покупатель
- Корпоративный Покупатель
- Покупатель – член клуба
- Покупатель – сотрудник
Эти типы, также как и остальные термины, должны быть определены в глоссарии продукта, что позволит добиться общего понимания предметной области (и также является базисом для моделирования предметной области).
Определяем ценность
Теперь попросим product owner-а приоритезировать опции для разных типов роли. Какая имеет наивысшую бизнес ценность для следующей итерации? Наш product owner хочет сфокусироваться на доходе, и не замедлять поставку в связи с более сложными типами покупателей. И поэтому он выбрал частного покупателя.
Здесь мы впервые использовали шаблон «расширить-затем-сократить», но определенно не в последний раз.
Для выбранного типа роли рассмотрим ее возможные состояния, или этапы жизненного цикла, через который она проходит.
Состояния пользовательской роли (для частного покупателя)
- Новый
- Существующий
- Анонимный (можно делать покупку без предоставления имени)
- Архивный
Определяем ценность
Теперь, когда мы расширили множество вариантов – состояний покупателя, пришло время сокращения. Опять же, нашему product owner-у нужно сузить набор опций до одной, которая даст наибольшую ценность. Он выбрал Частного, Анонимного Покупателя.
Шаг 2: Опции действий
Чтобы определить все возможные действия, которые удовлетворяют цели выбранной роли, начнем с глагола в тексте пользовательской истории: “Я хочу купить продукт. . .”
Спросим product owner-а, что типично происходит (или, если действие новое, что потенциально произойдет), и какие решения должны быть приняты. Для частного, анонимного покупателя, опции для действия «купить» следующие:
Опции действия Купить
- Проверить цену продукта
- Посчитать налог
- Посчитать общую сумму покупки
- Применить скидку
- Добавить наценку на упаковку
- Организовать доставку
- Сделать безопасный платеж
- Сделать инвентаризацию
- Создать чек
- Отправить платеж в «Счета к Получению»
Мы советуем написать все опции на листочке для заметок, чтобы product owner мог пройтись по ним. На данном этапе порядок опций не критичен.
Определяем ценность
Product owner просматривает опции и определяет минимальный набор, который нужно реализовать в следующем цикле поставки. Поощряйте его к тому, чтобы отложить опции с меньшей ценностью, выполняются нечасто, требуют данных, которых еще нет в базе или сложны, и их лучше оставить на потом.
Не забудьте проанализировать взаимозависимые опции, те, которые должны быть выбраны вместе. В то же время, посмотрите на независимые действия. Например, спросите вашего product owner-а: “Нужно ли предлагать скидки в следующей итерации или релизе, или это может подождать?”
Чтобы сделать выбор, рассмотрите контекст действия. Например, покупка происходит в реальном магазине «из кирпича и цемента» или online? В нашем случае оказалось, что прежде всего нужно сделать поддержку покупок в магазине. Наш product owner выбрал четыре опции (те, что отмечены):
Опции действия Купить:
- + Проверить цену продукта
- + Посчитать общую сумму покупки
- Применить скидку
- Добавить наценку на упаковку
- Организовать доставку
- + Сделать безопасный платеж
- Сделать инвентаризацию
- + Создать чек
- Отправить платеж в «Счета к Получению»
Шаг 3: Опции объектов данных: Типы и состояния
Затем, мы фокусируемся на объектах данных. Ваш product owner должен определить опции для объектов, основываясь на тех опциях, которые он уже выбрал для роли и действия. В нашем примере объекты – это Продукт, Платеж и Чек.
Для каждого объекта определим типы или варианты. Например, типы Продуктов включают Книгу, CD, DVD, и т.д.
Определяем ценность
Команда проанализировала объекты и расширила свое понимание их типов. Product owner оценил бизнес ценность опций и определил правильные комбинации. Product owner выбирает типы объектов с самой большой ценностью (пункты, отмеченные в таблице 1):
Более того, также как и с ролью, вам нужно рассмотреть возможные этапы жизненного цикла объектов для вашей истории. В нашем примере, объект Книга имеет два состояния: Новая и Старая.
Определяем ценность
Также как и раньше, product owner сужает набор опций. Его выбор – Новая Книга.
Состояния Книги
- + Новая
- Старая
Что мы уже выделили
Мы начали с пользовательской истории: “Как клиент, я хочу купить продукт …” Мы использовали шаблон «расширить-затем-сократить», чтобы выделить три элемента: пользовательская роль (типы и состояния), действия и объекты данных (типы и состояния). Выделенная история выглядит так:
“Как частный анонимный покупатель, я хочу купить новую книгу … сделать оплату наличными и получить чек об оплате наличными.”
В историю входят четыре опции действий: проверить цену продукта, посчитать общую стоимость, сделать безопасный платеж и создать чек.
На этом шаге, у вас есть частично выделенная пользовательская история. Ваша команда может решить отложить анализ трех других элементов истории (бизнес правил, интерфейсов и атрибутов качества) до разработки. Но наш опыт показывает, что те дополнительные минуты, которые вы на это потратите до того, как примите обязательства по поставке, могут значительно помочь в создании готовой истории, и расширят знания команды о требованиях к продукту. Давайте посмотрим.
Шаг 4: Опции бизнес правил
Бизнес правила определяют ограничения и условия, которые должны быть удовлетворены. Поскольку частично история уже выделена, заданы объекты и действия с высокой бизнес ценностью, вам нужно определить бизнес правила, которых нужно придерживаться. Ограничение бизнес правил для уже определенных роли, действий и объектов направляет аналитическую работу и обеспечивает выявление «свежих» правил.
Определяем ценность
Product owner опять же взвешивает бизнес ценность каждой опции для следующей итерации. Она выбирает следующие (те, что отмечены):
Опции бизнес правил
- + Валюта платежа определяется местом платежа
- Сумма платежа наличными должна быть не выше чем …
- + Сдача рассчитывается как …
- Бар-код на чеке реализуется с помощью …
Шаг 5: Опции типов интерфейсов
Чтобы получить высокоуровневое представление об интерфейсах истории нарисуйте контекстную диаграмму пользовательской истории или связанной с ней минимальной фичи, имеющей рыночную ценность.
Сконцентрируйтесь на тех опциях интерфейсов, которые соответствуют выбранным опциям пользовательской роли, действий и объектов. Затем определите типы интерфейсов (ручной ввод, физические устройства, межсистемный, пользовательский).
Для истории из нашего примера нужны интерфейсы для информации о книге (чтобы проверить цену), для оплаты наличными (для безопасного платежа) и для создания чека.
Определяем ценность
Product owner вместе с командой обсуждает опции. Основываясь на ценности для бизнеса и технических факторах, они договариваются о следующих опциях:
Опции для интерфейса Книги
- Сканнер (физическое устройство)
- + Ввод данных (UI)
Опции для оплаты наличными
- Кассовый аппарат (физическое устройство)
- + Ввод данных (UI)
Опции для создания чека
- + Отпечатан в магазине (отчет)
- Отправлен по факсу (межсистемный интерфейс)
- Отправлен по почте (межсистемный интерфейс)
Шаг 6: Опции атрибутов качества
Атрибуты качества – это “подмножество нефункциональных требований, которые описывают свойства работы ПО, разработки и установки.” [14] Иногда команды не обращают внимания на эти важные требования до разработки. Но наш опыт показывает, что командам нужно рассматривать опции для производительности, надежности, безопасности, масштабируемости, юзабильности и т.п., если они собираются создать готовую историю и улучшить качество постоянно расширяющейся архитектуры продукта.
Есть несколько способов для определения атрибутов качества. Например, вы можете написать их как пользовательские истории, использовать Planguage (язык спецификации) [15], определить список атрибутов качества как критерий приемки для пользовательской истории, или ввести их в текст пользовательской истории.
Один атрибут качества, который нужен в нашем примере, это время ответа при печати чека. Используя тэги Planguage, вы можете определить требования по времени ответа следующим образом:
Тэг: ВремяОтвета.ВызовПечатиЧека
Размерность: Секунды
Измерение: Время между нажатием на «Чек» и началом печати
Минимум: Не более 7 секунд
План: 4 секунды
Желание: 2 секунды
Кроме того, вы можете написать атрибуты качества вашей пользовательской истории на оборотной стороне карточки пользовательской истории (или с помощью вашего инструмента управления баклогом). Например, “Чек начинает печататься в течение 4 секунд после нажатия на кнопку «Чек».”
Готовая история
Вот краткий отчет. Мы начали с крупной истории: “Как клиент, я хочу купить продукт …” Используя методику разбивки историй, мы успешно выделили следующие опции с высокой ценностью:
Статус и тип пользовательской роли: Частный анонимный покупатель
Действия: Проверить цену продукта, посчитать общую стоимость покупки, сделать безопасный платеж, создать чек
Объекты (тип и статус): Новая книга, платеж наличными, чек для оплаты наличными
Бизнес правила: Валюта платежа определяется местом платежа, cдача рассчитывается как …
Интерфейсы:
Интерфейс для книги: Ввод данных (UI)
Интерфейс для оплаты наличными: Ввод данных (UI)
Интерфейс для чека: Отпечатан в магазине (отчет)
Атрибуты качества:
Тэг: ВремяОтвета.ВызовПечатиЧека …
Наша готовая история соответствует INVEST критерию – независимая, согласованная, ценная, готовая к оценке, подходящего размера, тестируемая (independent, negotiable, valuable, estimable, sized appropriately, testable). [16]
Во время разработки команда детализирует выбранные для истории опции. Это включает создание приемочных тестов, независимо от метода и инструментов тестирования —конструкция Дано-Когда-Тогда (Given-When-Then) (например, jBehave, easyB, Cucumber), таблицы данных (например, FIT или FitNesse), или другой инструмент. Тем временем, предварительный анализ продолжается для менее приоритетных опций для последующих циклов поставки.
Эта техника разбивки требований оправдала себя не только для пользовательских историй, она оказалась полезной и для других форм требований, таких как use case-ы и текстовые описания фич.
Разбивка историй для достижения успеха
Работая с бизнесом над опциями требований, просматривая их и выбирая ценные, команда постоянно чистит баклог и постоянно создает понятные, ценные требования. Кроме того, все выигрывают от углубления знаний по требованиям.
Этот метод поставки “только нужного и вовремя” – достаточно быстрый и эффективный, он упрощает планирование и поощряет заказчика и команду к оптимизации ценности — то, что необходимо для успеха agile команд.
Ссылки:
[1] Wake, Bill. “Twenty Ways to Split Stories.” XP123: Exploring Extreme Programming, December 2005.
[2] Lawrence, Richard. “Patterns for Splitting User Stories.” October 2009.
[3] Rainsberger, J.B. “Splitting Stories: An Example.” June 2007.
[4] Koskela, Lasse. “Ways to Split User Stories.” Blurts on the Art of Software Development, blog, June 2008.
[5] Matts, Chris, and Olav Maassen. “Real Options Underlie Agile Practices.” InfoQ, June 2007.
[6] Matts, Chris. Feature Injection Episodes 1 through 4. LimitedWIPSociety.org, May 2009.
[7] Sutherland, Jeff. “Practical Roadmap to Great Scrum: Systematically Achieving Hyperactivity.” Agile Bazaar, Boston, November 2009.
[8] Jakobsen, Carsten, and Jeff Sutherland, “Scrum and CMMI–Going from Good to Great: are you ready-ready to be done-done?” Agile 2009, Chicago, 2009.
[9] Harvey, Jack. “The Product Owner Ready Board.” Agile Product Owner Blog, November 2009.
[10] Beaumont, Serge. “Flow to READY, Iterate to DONE.” Xebia, July, 2009.
[11] Leffingwell, Dean. “More on Lean, Backlog and Little’s Law.” Scaling Software Agility, January 2010.
[12] Cohn, Mike. Agile Teamwork: 3 Ways to Minimize Handoffs. Better Software, March/April 2010.
[13] Denne, Mark, and Jane Cleland-Huang. Software by Numbers: Low-Risk, High-Return Development. Prentice Hall, 2003.
[14] Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.
[15] Gilb, Tom. Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Addison-Wesley, 2005.
[16] Wake, Bill, op. cit.
-
Pavel Safin
-
Sergey
