В последнее время все больше людей интересуют методологией гибкой разработки ПО (agile). Многие люди или работают в такой среде, или хотели бы попробовать. Кто-то думает в стиле гибкой разработки, кто-то считает себя гибким. Гибкость - это то, что ценят люди при взаимодействии с процессами и инструментами. Но во многих «гибких» ситуациях люди все же хотят работать по набору правил, заданных стандартным фреймворком. Самый популярный такой фреймворк на данный момент - это Scrum.

Скрам очень мощен благодаря своей простоте: он дает членам команды свободу самим определять, как разрабатывать продукт. На практике, однако, люди часто находят очень сложным постоянное размышление о том, как делать их работу (например, понимать требования, делать дизайн, программировать, тестировать, разворачивать) и как эту работу улучшить. Очень часто они просто повторяют то, что положено (или то, что наиболее популярно на рынке). «Гибким» быть совсем не просто, и справиться со свободой, которую дает скрам, тоже нелегко: нужна соответствующая квалификация. Инженерия требований - это сфера, равно применимая к самым разным ситуациям и процессам. Полезна она и для гибкой разработки - она может многое привнести в скрам-фреймворк. Кто именно, однако, должен привносить - это предмет дискуссий. В скраме существует так называемый Product Backlog - приоритезированная очередь задач, то есть динамический набор требований, за которые отвечает владелец продукта (Product Owner). Создавать его нужно непрерывно при сотрудничестве заинтересованных лиц с командой разработки. На практике в ответственной роли владельца продукта выступают люди с самой разной подготовкой и специализацией. И в зависимости от своего опыта они предъявляют к поддержке со стороны команды разработчиков или бизнес-аналитиков самые разные требования. Помимо того, люди, которые оказывают владельцу продукта помощь в разработке требований, сами не всегда обладают достаточным опытом в этой сфере.

Строить или не строить

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

Сходства в целях и мышлении

Классическое заблуждение относительно инженерии требований заключается в том, что она касается лишь документирования. На самом деле конечная цель сбора требований в том, чтобы облегчить и разделить общее понимание требований для всех тех, кто вовлечен в процесс разработки. Эти требования могут различаться - от бизнес-требований до детальных требований к ПО - и принимать самые разные формы, такие, как потребности заказчика или ожидаемое поведение системы как в функциональных, так и в нефункциональных аспектах. Для получения общего представления о требованиях полезно иметь какую-нибудь форму документации, будь то спецификация или коллекция пользовательских историй. Какой бы ни была форма, хорошо при этом, если документация конкретна и придерживается определенных правил изложения. Опыт показывает, что важно как минимум проговорить требования, чтобы убедиться, что все понимают их одинаково. Личная коммуникация - это то, что тяжело осуществимо в agile-сообществе, где это общее понимание особенно важно. И хотя пути инженерии требований могут различаться при традиционном и гибком подходе, конечная цель остается той же, и важно держать ее в уме, дабы не запутаться, применяя конкретные технологии. Кроме того, полезно осознавать и способ мышления. В целом способы мышления в инженерии требований очень схожи при традиционной и гибкой работе, как можно увидеть на следующих примерах:

• от проблемы - к решению;
• от общего - к частному;
• учет многих перспектив с целью улучшения качества;
• учет и технических, и финансовых последствий при определении области применения и приоритетов в требованиях.

Различия во времени и техниках

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

Разное время

Если все требования указаны разом во всех деталях - это не agile. В спринтах (одна итерация в проекте) команда разработки работает лишь с ограниченным набором требованием за раз. При гибкой разработке вам необходимо убедиться, что все понимают, что именно должно быть разработано, непосредственно перед переходом к следующей версии продукта. В гибкой разработке вы реализуете лишь необходимые, лишь краткосрочные требования. Детально эти требования рассматриваются или во время спринта, или прямо перед ним, во время установочных сессий. Выбирая небольшой набор требований и воплощая его в рабочее решение, вы, таким образом, получаете быструю обратную связь. Частая обратная связь позволяет больше узнать о требованиях и соответствующим образом адаптировать процесс. Поскольку работа с требованиями получается «размазанной» во времени, то согласование технических и финансовых забот становится текущей задачей, а не проводится отдельно в начальной стадии разработки.

Другие техники

Техники agile в отношении требований основаны на идее совместных усилий относительно ограниченного набора требований, в отличие от традиционного подхода, при котором специалист работает сразу над исчерпывающим описанием требований. Команды гибкой разработки предпочитают собирать требования способом, который поддерживает взаимодействие и подвижность. Известные примеры: пользовательские истории на стикерах или в виде картотеки, карты историй или наглядные доски. Пользовательские истории пишутся таким образом, что главным субъектом в них выступает пользователь. При традиционном подходе главным субъектом является система. Кроме того, традиционный подход часто делит функциональные и нефункциональные требования, обычно разделяя их на разные главы спецификации. Это деление предназначено обеспечить полноту сбора требований. В гибком подходе и функциональные, и нефункциональные аспекты собираются вместе путем анализа каждого отдельного требования (как правило, в различных пользовательских историях), например, при помощи методики «7 измерений продукта» (авторы: Эллен Готтесдинер и Мэри Горман). Это ведет к лучшему пониманию всеми вовлеченными сторонами, выявлению новых деталей - таких, как критерии приемки, - и зачастую к новым обнаруженным требованиям среди пользовательских историй. В традиционной среде готовый набор требований оценивается с точки зрения целесообразности и стоимости; в agile главный упор идет на добавленную стоимость и риски по каждому требованию.

Командные усилия

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

Об авторе:

Свен - консультант-тренер, более 20 лет он помогает бизнесу и IT находить общий язык. Он помогал командам и отдельным специалистам как в коммерческих, так и в некоммерческих организациях существенно улучшать свои результаты при помощи технологий и фреймворков agile. Он знает и применяет разные методики и техники и любит делиться своим опытом.

Источник: http://re-magazine.ireb.org/issues/2015-[...]ing-complexity/requirements-engineering/

Перевод: Александра Родсет

Еще интересные статьи на эту тему:

• Wiki для управления требованиями
• Лучше не писать техническое задание в Google Docs
• Нефункциональные пользовательские истории
• Критерии приёмки для требований в Agile
• Проектная документация в Agile