в облаке
Попробовать

Приоритезация требований: свежий взгляд

31.03.2014 13:13

Приоритезация требований считается основополагающей деятельностью для любого типа разработок: водопада или Agile. Целью приоритезации требований является:

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

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

Это хорошо известная и глубоко обсуждаемая тема в инженерии технических требований; см. [1] , [2] и [5]. Существуют различные подходы и предложения, которые определяют "наиболее важные" требования и предлагают методики по обращению с этими "наиболее важными" требованиями с тем, чтобы они были выражены в количественной и измеряемой форме.

Например, [2] предлагает набор из 12 критериев, которые влияют на приоритет инженерии технических требований. Предоставленный алгоритм позволяет рассчитать упорядоченный приоритет для требований, основанных на этих критериях. Это тщательно разработанный и количественно выраженный подход. К недостаткам такого подхода можно отнести объем усилий, необходимых для согласования и установки всех ценностей по двенадцати критериям. Кроме того, всякий раз, когда потребуется повторная приоритезация, шаги по согласованию ценностей также придется выполнять заново. Применение настоящего алгоритма в Agile проекте при длительности итерации от двух до четырех недель может оказаться непростой задачей по двум основным причинам:

  1. Усилия, требуемые для приоритезации: при каждой итерации команда должна устанавливать ценность критериев, с учетом значительных усилий, потраченных на приоритезацию, в результате чего снижается эффективность.
  2. Командное мышление: кКоманды по гибким разработкам не используют особо формальные методики приоритезации, как это указано в [2]. Владелец продукта, как правило, определяет приоритеты бизнес-ценности и рисков, полученные из непосредственного общения с заинтересованными сторонами.

Четко обозначена необходимость регулярного пересчета приоритета требований. Изменение приоритезации требований обсуждается в [2], указывая, что “Приоритеты будут изменяться вследствие общения с вашим клиентом и приобретения более четкого понимания его потребностей … с усовершенствованием системы развивается и ее архитектура, а, следовательно, разрешаются и неопределенные вопросы; поэтому, приоритеты всех фичей должны меняться со временем [7]”.

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

Итак, преуспевают ли команды по гибким разработкам в процессе приоритезации? В среде гибкой разработки эту ответственность берет на себя владелец продукта. Гибкая приоритезация невыполненных работ или обязательств, как правило, использует очень ограниченный набор ценностей и затратных критериев [3]:

  • воспринимаемые заказчиком бизнес-ценность,
  • риски,
  • размер и сложность продукта.

Не существует явно применяемого алгоритма, вместо этого приоритет обсуждается во время процесса пересмотра баклога продукта его владельцем, заказчиками и пользователями. Стратегии в гибкой приоритезации следуют за принципом “быстрейшего результата” (высокой ценности) и “низко висящих плодов” (малых усилий) [3] на уровне “здравого смысла”. Результаты реализуются в том же порядке, в котором расположены требования в бэклоге. Гибкий подход якобы считается успешным. Тем не менее, при исследовании конкретной ситуации с восемью организациями, авторы приходят к другому выводу [3]: “…три явных и основополагающих допущения гибкой приоритезации требований, согласно литературе по передовым практикам гибких разработок, не поддерживаются всеми исследуемыми рабочими командами. К этим допущениям относятся: (i) движущая роль клиента в процессе создания ценности, (ii) доминирующее положение бизнес-ценности в качестве основного критерия определения приоритетов, и (iii) роль процесса приоритезации в достижении цели проекта”. Основываясь на данном исследовании конкретной ситуации, можно отметить, что принципы гибкой приоритезации значимы, но, к несчастью, не хватает их применения в реальных ситуациях. Читайте далее: Приоритезация требований в Agile проектах

--

Автор: Rainer Grau

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

 

Литература

[1] Karl E. Wiegers; “First Things First: Prioritizing Requirements”; http://www.processimpact.com/articles/prioritizing.html originally published in Software Development, September 1999

[2] Rick Botta (BAE Systems), A. Terry Bahill, PE (University of Arizona); “A Prioritization Process”; Engineering Management Journal Vol. 19 No. 4 December 2007

[3] Zornitza Racheva, Maya Daneva, Klaas Sikkel, Roel Wieringa (University of Twente Enschede Netherlands), Andrea Herrmann (University Braunschweig); “Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study”; 18th IEEE International Requirements Engineering Conference (RE) 2010; ISBN 978-1-4244-8022-7

[5] Muhammad Ramzan, M. Arfan Jaffar and Arshad Ali Shahid; “Value Based Intelligent Requirement Prioritization (Virp): Expert Driven Fuzzy Logic Based Prioritization Technique”; International Journal of Innovative Computing, Information and Control ICIC International, Volume 7, Number 3, March 2011

[7] Gilb, Tom, and Mark W. Maier, “Managing Priorities: a Key to Systematic Decision-making,” Proceedings of 15th Annual; International Symposium of INCOSE, Rochester, NY, (July 2005).

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