Требования в Agile: что тут такого?

Agile Requirements: What’s the Big Deal?
 Joy Beatty and Karl Wiegers
Перевод: Тимофеев А.Н.
переведено и опубликовано с разрешения авторов
впервые опубликовано на ModernAnalyst.com

Скачать pdf-версию статьи
Agile подходы к разработке ныне используются в большинстве организаций, разрабатывающих ПО, по крайней мере, хоть какую то часть времени. С ростом популярности методов Agile бизнес-аналитики и владельцы продуктов стали часто использовать термин «Agile требования», чтобы обозначить свою работу.

Нам не нравится термин «Agile требования» поскольку это подразумевает, что требования для Agile проекта как-то качественно отличаются от требований для проектов, использующих другие жизненные циклы. Чтобы правильно реализовать функциональность, разработчик должен знать одну и ту же  информацию независимо от используемого жизненного цикла. Agile и традиционные проекты в ряде аспектов работают с требованиями по-разному, особенно это касается времени, глубины и детализации записи. Тем не менее, большинство хорошо известных методов для разработки и управления требованиями полезны и для Agile проектов, когда они вдумчиво применяются, как это описано в третьем издании нашей книги Software Requirements (Microsoft Press, 2013) [1]. Именно поэтому мы предпочитаем термин «требования для Agile проектов» вместо «Agile требования».

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

Agile подходы разработаны, чтобы приспособиться и адаптироваться к неизбежным изменениям, которые происходят во многих проектах. Они также хорошо подходят для проектов с высокой неопределённостью и изменчивостью требований. Тем не менее, Agile проекты нуждаются  принципиально в тех же видах деятельности с требованиями, что и  традиционные проекты разработки. Кто-то по-прежнему должен определить классы пользователей и других заинтересованных сторон, выявить требования, поработав с соответствующими представителями пользователей, проанализировать и задокументировать требования различных видов на соответствующих уровнях детализации, и проверить, что требования соответствуют бизнес-целям проекта. Однако все детализированные требования не документируются одновременно в начале Agile проекта. Вместо этого выявляются требования высокого уровня (как правило, в виде пользовательских историй), чтобы заполнить Product Backlog и выполнить планирование и определение приоритетов.

Отличия существуют

Основные отличия между тем, как идет работа с требованиями в Agile и в  традиционных проектах можно разделить на следующие категории.

Роли и обязанности

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

В Agile проекте владелец продукта (Product Owner), как правило, отвечает за Product Backlog и за поставку пользовательских историй, готовых для реализации. Разработчики отвечают за достаточность информации в пользовательских историях, прежде чем те будут приняты в разработку. Иногда роль владельца продукта выполняется кем-то, кто ранее был известен как бизнес-аналитик, поскольку этот человек хорошо понимает бизнес и может эффективно представлять различные сообщества пользователей. Другие проекты имеют выделенного бизнес-аналитика, который работает в тесном сотрудничестве с владельцем продукта над тем, чтобы пользовательские истории были  достаточно хорошо проработаны и приоритезированы для разработки.

Распределение во времени задач по работе с требованиями

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

Однако,  подход  «точно в срок» (“just-in-time”) затрудняет распознавание зависимостей требований и архитектурных последствий, для которых должны быть найдены решения еще в самом начале. Чтобы снизить риск создания порочной архитектуры, Agile-команды довольно часто используют начальные итерации для того, чтобы охватить взглядом широкий спектр требований и обсудить, какие основные архитектурные решения могли бы быть необходимы.

Как показано на рисунке 1,  пользовательские истории распределяются для реализации по конкретным итерациям и детали для каждой истории дополнительно выясняются «точно в срок», или в ходе итерации.

standard-requirements-activities-agile

Функциональные требования могут разрабатываться небольшими порциями на протяжении всего проекта и даже незадолго до того, как продукт будет выпущен. Однако, как и в случае с архитектурой, важно на ранней стадии изучить нефункциональные требования до такой степени, чтобы система могла быть спроектирована для достижения критичных показателей производительности, удобства, доступности и других целей в области качества. Решение этих вопросов в конце проекта может потребовать обширной и дорогостоящей переделки. Так же как и традиционные подходы, Agile методы ориентируются на то, чтобы достаточно сократить риски перед тем как продвинуться вперед. Существенное отличие заключается в том, что Agile проекты заранее принимают то, что будет некоторое количество рефакторинга и переделок, поэтому их команды готовы согласиться на несколько бОльшую неопределенность требований в начале.

Формы поставки

На верхнем уровне пользовательские истории сопоставимы с Use Cases, которые часто используются в традиционных проектах. Опять же, различие в том, насколько тщательно вы детализируете их и записываете ли то, что узнали. Пользовательские истории часто соответствуют отдельным потокам внутри варианта использования. Бизнес-аналитик на традиционном проекте может работать с вариантами использования и разрабатывать более богатый набор функциональных требований. В отличие от этого в Agile проекте команда обычно конкретизирует детали пользовательской истории через описание приёмочных тестов, которые будут показывать, была ли история правильно реализована.

Карл выступал за разработку тестов совместно с требованиями почти 25 лет назад — задолго до того, как родился Agile Manifesto [П1]! Но в действительности, функциональные требования и соответствующие им гранулярные тесты — это два способа представления одной и той же информации, один из которых описывает, что строить, а другой определяет, как понять, что  вы это построили корректно. Большим преимуществом мышления в терминах тестов является то, что оно имеет больше шансов выявить исключения, которые часто упускают при определении требований.  Однако недостаток использования только одного из подходов в том, что он оставляет вас лишь с одним представлением знаний о требованиях. Если представление одно, то вы должны быть уверены в том, что оно корректно.

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

Терминология

Различные формы, используемые для представления требований, приводят к интересной, но не к ужасаемо значимой разнице в терминологии, используемой в традиционных и в Agile проектах. Большинство Agile проектов опираются на пользовательские истории и критерии приёмки, в то время как сценарии использования и функциональные требования чаще используются в традиционных проектах. Но на самом деле это одни и те же  знания! Не имеет большого значения, как вы это называете или как именно это представляете, лишь бы вы производили и сообщали эти знания таким образом, который позволяет разработчикам и тестировщикам выполнять свою работу эффективно и рационально.

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

Иногда люди думают, что проектные команды, работающие по Agile, не должны писать требования. Это неверно. В качестве альтернативы Agile методы выбирают принцип облегченной документации. Тесное сотрудничество клиентов с разработчиками на Agile проектах, как правило, означает, что требования могут быть документированы менее подробно, чем на традиционных проектах. Взамен бизнес-аналитики или другие лица, ответственные за требования, будут обеспечивать необходимую точность требований через обсуждения и документацию, когда это необходимо. Любая документация сверх того, что нужно командам разработки и тестирования (или которая требуется для удовлетворения правил или стандартов) потенциально представляет собой напрасные усилия, если в ней нет конкретной потребности в будущем. Некоторые пользовательские истории могут иметь невысокую детализацию –  отражая лишь самые рискованные или сильно влияющие на функциональность детали, которые описываются, как правило, в форме критериев приёмки и моделей, предназначенных для визуального анализа.

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

Когда определять приоритеты

Определение приоритетов в Product Backlog — непрерывная деятельность в Agile проекте по выбору рабочих элементов, которые попадут в предстоящие итерации и элементов,  которые удаляются из Product Backlog. Назначенные элементам в Product Backlog приоритеты не должны всегда оставаться постоянными — они действительны только в  период, когда элементы находятся в разработке. Команды постоянно задают себе вопрос: «Что является наиболее важным и над чем мы должны работать дальше?».

В отличие от этого в большинстве традиционных проектов стараются рано определить приоритеты требований и редко оглядываются назад. Но на самом деле, все проекты, а не только Agile, должны динамически управлять приоритетами работ, остающимися в их Product Backlog как его пульсом.

А есть ли разница на самом деле?

Недавно мы ознакомились со списком «Принципы бизнес-анализа» от IIBA® Agile Extension to the  BABOK® Guide где в нескольких разделах перечисляются многочисленные практики. Мы приложили все усилия к тому, чтобы увидеть там нечто, что не было бы потенциально  пригодным в любом программном проекте. Не должна ли всякая команда применять методы, чтобы увидеть все в целом, думать как клиент, стимулировать сотрудничество, а также избегать бесполезных расходов? Все проекты должны определить в чем их коммерческая ценность, убедиться, что проектная деятельность и стадии бизнес процессов увеличивают ценность, а также использовать практические методы определения приоритетов. Такие методы как personas, управление backlog, относительная оценка и ретроспектива — ценные методы, которые пойдут на пользу практически любому проекту. Так что же делает эти принципы и практики бизнес-анализа характерными именно для Agile проектов?

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

Литература

  1. Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2.

[П1] Примечание переводчика.  Подход к разработке ПО, в котором  тесты разрабатывались параллельно со спецификациям описан Гербертом Бенингтоном ещё в 1956 году. В 1979 году идея с параллельной разработкой тестов и тестированием нашла отражение в широко используемой в промышленности V-модели  Бари Боэма.

Хотите сослаться на эту статью? Используйте правильную ссылку:

Битти Д., Вигерс К.. Требования в Agile: что тут такого?//Практика проектирования систем.-2016. [электронный ресурс] — Режим доступа: http://reqcenter.pro/agile-requirements/, свободный. — Загл. с экрана