В данной статье я кратко рассматриваю как основы agile-подхода, поясняю как процесс бизнес-анализа работает в гибких методах, ставлю под вопрос некоторые догмы, связанные с документированием, показываю, почему гибкие практики более эффективны, чем традиционные подходы и в конце рассказываю о стратегиях спецификации требований в гибком проекте.
Управление требованиями в Agile: что это значит?
Ключевая особенность всех Agile-подходов – возможность регулярного пересмотра содержания проекта и внесения изменений в разработку. Это необходимо при разработке продуктов, которые должны постоянно изменяться под влиянием требования рынка.
Артефакты в управлении требованиями в Agile:
- backlog (беклог) – список требований, которым должен соответствовать продукт
- user story (пользовательская история) – требование, которое написал Product Owner или его представитель
- task (задача, необязательный элемент) – результат декомпозиции UserStory на более мелкие части.
Принципы управления требованиями в Agile
Есть несколько принципов управления требования в Agile:
- Разработка от общего к частному (от общего vision к конкретным фичам).
- Инкрементальность vs итеративность (каждый этап реализации дает прирост ценности для клиента/заказчика).
- Итеративная реализация (реализация/поставка осуществляется короткими итерациями).
- Коммуникации лицом к лицу.
- Передача бизнес-контекста команде важнее идеально написанных требований.
Бизнес-анализ в управлении требованиями
Бизнес-анализ настолько важен в проектах с гибкой разработкой, что мы делаем это каждый день в течение всего цикла разработки, а не только на начальной фазе проекта. Разработка по гибкой модели (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 |
Гибкие методы работают лучше
Мы провели опрос людей, работавших в софтверных проектах с использованием различных методик разработки. Результаты оказались любопытными. В тех командах, кто работал по итеративным методологиям, таким как 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 зависит от ситуации, и порой трудно определить, какого уровня детализации достаточен для той или иной ситуации.
Документируйте поздно. Пишите документацию так поздно как возможно. Другими словами ранние инвестиции в документацию скорее всего не оправдаются.
Выполняемые спецификации. Если требования должны быть тестируемыми, почему бы не выкинуть промежуточное звено документации и не специфицировать требования в виде выполняемых “тестов-историй”? Почему не отобразить детали дизайна (здесь, скорее всего, речь идет об архитектуре – прим. пер.) в виде выполняемых тестов, вместо статической документации?
Кроме того методология Agile рассматривает несколько шкал измерений (scaling factors) проектов. Ниже описано, как значения на каждой из этих шкал могут повлиять на ваш подход к выявлению и спецификации требований.
Размер команды (Team size)
Большие команды работают с большими проектами. Часто большие команды состоят из более мелких команд, каждая из которых имеет своего владельца продукта. Для координации работы различных подкоманд с общими требованиями проекта необходимо использовать такие инструменты как обзорную документацию требований, различные виды трассировки для установления связи между требованиями.
Геораспределенность (Geographical distribution)
Многие agile-команды распределены. В геораспределенных командах нужна чуть большая чем обычно степень детализации в электронном виде.
Соблюдение установленных нормативов (Regulatory compliance)
Просмотрите внимательно различные нормативы и законодательные акты, которые могут повлиять на создаваемый продукт. Вряд ли учет того, что действительно необходимо учесть потребует тонн документации. Просто задокументируйте (или сошлитесь на) то, что необходимо учесть в продукте без дополнительных бюрократических процедур.
Дисциплина (внутренние правила) предприятия (Enterprise discipline)
Внутренние правила предприятия, такие как бизнес-моделирование могут как увеличить, так и уменьшить потребность в спецификации требований. Более вероятно (при строгой политике бизнес-моделирования) вам потребуется поддерживать трассировочные связи требвоаний с моделями предприятия. В то же время менее вероятно, что вам придется тратить сколь-нибудь значительные усилия на выявление общей терминологии, бизнес-сущностей и т.п. Более того бизнес-аналитики предприятия – важные стэйкхолдеры, которые могут оказаться полезным ресурсом для владельцев продукта.
Организационная некомпактность (Organization distribution)
Иногда в проектную команду входят участники из других подразделений, из различных компаний-партнеров, из внешних обслуживающих компаний. Подобная потеря организационной компактности повышает проектные риски. Традиционная стратегия – использовать больше документации для решения подобных проблем. В то же время гибкие технологии предлагают большую степень коммуникации, более короткие циклы разработки, меньшую зависимость от документации. В зависимости от контракта между организациями, чьи сотрудники работают в одном проекте, в зависимости от исповедуемых ими методологий разработки может потребоваться больше или меньше документации. В идеале необходимо убедить и помочь всем командам перейти на гибкие методы разработки.
Сложность системы (Application complexity)
Некоторые приложения более сложные, чем другие, особенно когда создаваемая система призвана объединять уже существующее ПО, платформы, источники данных. Традиционный подход говорит, что в таком случае необходимо (если таковая документация отсутствует) задокументировать все системы, с которыми предстоит работать будущему продукту. Т.е. создать документацию, отображающую ситуацию “как есть”. Этот подход верен лишь частично. Гораздо лучше будет документировать то “как есть”, используя стратегию “по требованию” и “JBGE” (см. выше).
