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

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

Персоны, раскадровка (Story boarding), путешествие клиента или любые другие техники визуализации отображают требования в более ясной и доступной манере, чем текстовые документы. Арена Инноваций использует этот механизм.

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

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

Возможна и другая комбинация:

• Текст: cпецификация эпика, включая рациональную и коммерческую ценность для пользователя или заинтересованного лица.
• Business Model Canvas [9]: методология, используемая для вычисления бизнес-модели. Эпик представляет собой что-то вроде коммерческой ценности предоставления мини-бизнес-модели.
• Отдельные раскадровки или их набор демонстрируют наиболее важные сценарии, которые будут использованы для получения пользовательских историй.

Арена Инноваций рекомендует Agile командам использовать согласованный формат для такого языка визуализации. В качестве первого выбора мы советуем использовать физическую демонстрационную доску, но флипчарт или даже виртуальная демонстрационная доска тоже подойдут. У физической демонстрационной доски есть свои преимущества, которые заключаются в быстром выполнении доработок, мобильности, представлении физического месторасположения и центральной точки фокусировки для общения и проведения дискуссий. Использование физической демонстрационной доски, несомненно, требует совместного размещения. Видеоконференция или виртуальные демонстрационные доски являются соответствующими средствами в распределенной среде.

Важные требования для выбора форматов визуализации:

• Визуализация сравнима в представлении, т.е. требования представляются в одинаковой манере с тем, чтобы человек мог сравнить такие атрибуты требования, как размер, уровень сложности, коммерческую ценность и зрелость.
• Визуализированные требования могут быть также визуализированы, т.е. элементы могут быть расположены на одной линии, что позволит заинтересованным лицам и команде просматривать (физически или виртуально) и сравнивать требования (темы, эпики, фичи, …).

Эта методология следует идее, указанной на обратной стороне карточек пользовательских историй, которые прикреплены к демонстрационной доске, и «CCC принципу» (карточка - обсуждение – подтверждение) [10]. Все зрелые Agile команды применяют эту методологию при сравнении элементов; это обычный пересмотр баклога [11].

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

--

Автор: Rainer Grau

http://re-magazine.ireb.org/issues/2014-1-learning-to-fly/innovation-arena/

Литература

[9] Alexander Osterwalder, Yves Pigneur; Business Model Generation: A Handbook for Visionaries, Game Changers, and Challangers, Wihley Aug 2010, ISBN 978-0-470-87641-1

[10] Three C’s; Ron Jeffries; Aug 30, 2001; card, conversation, confirmation; see: http://xprogramming.com/articles/expcardconversationconfirmation/ .

[11] Download area of the official Scrum Guide on scrum.org ; https://www.scrum.org/Scrum-Guide .

[12] The Agile Manifesto; http://Agilemanifesto.org/ 2001

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

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