Управление требованиями в Agile. Бизнес-анализ в гибких проектах

управление требованиями в Agile

В данной статье я кратко рассматриваю как основы agile-подхода, поясняю как процесс бизнес-анализа работает в гибких методах, ставлю под вопрос некоторые догмы, связанные с документированием, показываю, почему гибкие практики более эффективны, чем традиционные подходы и в конце рассказываю о стратегиях спецификации требований в гибком проекте.

Управление требованиями в Agile: что это значит?

управление требованиями в AgileКлючевая особенность всех Agile-подходов — возможность регулярного пересмотра содержания проекта и внесения изменений в разработку. Это необходимо при разработке продуктов, которые должны постоянно изменяться под влиянием требования рынка.

Например, разработка нового сервиса «Гертруда» — облачной платформы для управления строительством, выполняется итерациями, чтобы учесть пожелания пользователей и самой компании. Также банковские продукты, выходя на рынок, могут получать обратную связь от клиентов, что сразу необходимо внести в содержание проекта.

Артефакты в управлении требованиями в Agile:

  • backlog (беклог) — список требований, которым должен соответствовать продукт
  • user story (пользовательская история) — требование, которое написал Product Owner или его представитель
  • task (задача, необязательный элемент) — результат декомпозиции UserStory на более мелкие части.

Подробнее о том, что такое Agile.

Принципы управления требованиями в Agile

Есть несколько принципов управления требования в Agile:

  1. Разработка от общего к частному (от общего vision к конкретным фичам).
  2. Инкрементальность vs итеративность (каждый этап реализации дает прирост ценности для клиента/заказчика).
  3. Итеративная реализация (реализация/поставка осуществляется короткими итерациями).
  4. Коммуникации лицом к лицу.
  5. Передача бизнес-контекста команде важнее идеально написанных требований.
    Далее фокус тренинга смещается на рассмотрение различных типов и способов коммуникации, которые можно использовать в команде, их эффективности, временных затрат на организацию того или иного способа.

Бизнес-анализ в управлении требованиями

Бизнес-анализ настолько важен в проектах с гибкой разработкой, что мы делаем это каждый день в течение всего цикла разработки, а не только на начальной фазе проекта. Разработка по гибкой модели (Agile Model Driven Development — AMDD) предполагает использование нескольких лучших практик, которые отражают место бизнес анализа в гибких проектах. Это следующие практики:

Активное участие заинтересованных лиц (stakeholders). Заинтересованные лица своевременно обеспечивают разработчиков информацией, своевременно принимают решения, активно вовлечены в процесс разработки посредством использования интегрирующих инструментов и методик.

Приоритезация требований. Гибкие команды реализуют требования в порядке их важности. Требования приоритезируются по важности при активном участии заинтересованных лиц. Таким образом раньше всего реализуются требования, приносящие наибольший ROI (Return Of Investments) для заинтересованных лиц.

Моделировать немного вперед. Иногда требования, которые по приоритету находятся “недалеко” от самых приоритетных достаточно сложны. Это побуждает вас инвестировать определенные усилия для того, чтобы их исследовать до момента, когда они попадут в разработку. Данное исследование снижает риск при разработке. Подобное явление достаточно редко, но иногда случается.

Предварительный анализ требований. В начале гибкого проекта вам необходимо потратить часть времени для идентификации границ проекта и для создания начального набора приоритезированных требований. Еще один результат — идентификация всех заинтересованных лиц со стороны заказчика. Данный процесс занимает от нескольких дней до нескольких недель.

Итерационное моделирование. В начале каждой итерации при планировании вы должны сделать несколько шагов, моделируя систему.

Моделирование при помощи штурма (Model storming). На протяжении итерации вы будете регулярно, в одно и то же, время заниматься моделированием системы в течение нескольких минут. ДЛя этого вы будете использовать подход штурма (мозшгового). Тем самым вы будете регулярно исследовать детали требований или архитектуры.

Разработка через тестирование (Test-driven development — TDD). Напишите тест (или набор тестов — прим. пер.), для требований или архитектуры, а затем просто напишите ровно столько кода, чтобы данный набор тестов выполнялся. TDD — признанный хороший подход к своевременной спецификации требований.

AMDD (Agile Model Driven Development) предлагает высокоитеративный, очень гибкий и с высокой степенью сотрудничества подход к анализу, который учитывает в то же время риски, неотъемлемо связанные с требованиями. Замечательной стороной agile-философии является то, что запрос на изменение требований на поздних стадиях разработки может быть превращен в конкурентное преимущество продукта, если только вы готовы с ним работать. Гибкие методы работы с требованиями могут сильно отличаться и казаться достаточно некомфортными поначалу для людей, привыкших с традиционным прошлым в разработке ПО.

Догма документирования

Годами накопленный тяжелый опыт позволяет агилистам поставить под сомнение традиционную догму о ценности документации.

Первое. Агилисты обнаружили, что подход, при котором детальные требования разрабатываются на ранних стадиях проекта, ведет к увеличению проектных рисков и существенных затрат на практике. Существует несколько причин этого. Одна из них — людям (заказчику — прим. пер.) трудно определить то, что им по-настоящему нужно. Еще причины — документация очень плохой способ общения, а также традиционное “избегание изменений” ведет к тому, что заинтересованные лица диктуют фиктивные требования для заполнения документа.

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

Второе, агилисты понимают, что общение через документацию — худший способ передачи информации между людьми. Об этом также говорит Media Richness Theory (MRT). В свое время мы провели опрос среди различных групп разработчиков внутри нашей компании. Мы попросили их оценить Эффективность различных коммуникационных стратегий. Ниже — результаты этого опроса:

Таблица-1. Эффективность коммуникационных стратегий в agile-командах

Коммуникационная стратегия Внутри команды С заказчиком (заинтересованными лицами)
Лицом к лицу (ЛкЛ) 4.25 4.06
ЛкЛ у доски 4.24 3.46
Обзорные диаграммы 2.54 1.89
Чат онлайн 2.10 0.15
Обзорная документация 1.84 1.86
Телеконференции 1.42 1.51
Видеоконференции 1.34 1.62
Электронная почта 1.08 1.32
Детальная документация -0.34 0.16

Гибкие методы работают лучше

В декабре 2008 мы провели опрос людей, работавших в софтверных проектах с использованием различных методик разработки. Результаты оказались любопытными. В тех командах, кто работал по итеративным методологиям, таким как RUP количество успешных проектов составило 71%. На втором месте оказались команды, исповедовавшие методики Scrum или Экстремального Программирования (Extreme Programming — XP) — 70% успешных проектов. Традиционные команды с водопадными моделями разработки заняли третье место — 66% успешных проектов. И, наконец, команды, работавшие по методам ad-hoc (как придется, по ситуации, по наитию) имели в своем багаже лишь 62% успехов.

Представляет интерес еще одно исследование. В нем — попытка отразить вероятность того, что команда исповедующая ту или иную методику разработки поставит заказчику действительно важный функционал и обеспечит поставленным продуктом хорошую степень возврата инвестиций (ROI). Вероятность оценивалась по шкале от -10 (очень невероятно) до +10 (очень вероятно). Ниже — результаты данного исследования.

Насколько подробной должна быть спецификация?

Модель зрелости гибких процессов (Agile Process Maturity Model — APMM) дает некоторые рекомендации относительно спецификации требований в гибких процессах.

Достаточные, но минимальные артефакты (Just barely good enough (JBGE) artifacts). Модель или документ должны быть достаточными для удовлетворения потребностей в конкретной ситуации, но не более того. Этот принцип служит важным фильтром большинства некотролируемой бюрократической детализации. Однако, принцип JBGE зависит от ситуации, и порой трудно определить, какого уровня детализации достаточен для той или иной ситуации.

Документируйте поздно. Пишите документацию так поздно как возможно. Другими словами ранние инвестиции в документацию скорее всего не оправдаются.

Выполняемые спецификации. Если требования должны быть тестируемыми, почему бы не выкинуть промежуточное звено документации и не специфицировать требования в виде выполняемых “тестов-историй”? Почему не отобразить детали дизайна (здесь, скорее всего, речь идет об архитектуре — прим. пер.) в виде выполняемых тестов, вместо статической докум