Приоритезация требований: свежий взгляд
Приоритезация требований считается основополагающей деятельностью для любого типа разработок: водопада или Agile. Целью приоритезации требований является:
При достижении целей сложнее всего определиться с тем, что именно считать “наиболее важным”. Многие критерии оказывают влияние на смысловую наполненность выражения "наиболее важный". Эти критерии зависят от контекста проекта и могут меняться со временем. Даже сама система критериев может периодически меняться, в зависимости от контекста. Это хорошо известная и глубоко обсуждаемая тема в инженерии технических требований; см. [1] , [2] и [5]. Существуют различные подходы и предложения, которые определяют "наиболее важные" требования и предлагают методики по обращению с этими "наиболее важными" требованиями с тем, чтобы они были выражены в количественной и измеряемой форме. Например, [2] предлагает набор из 12 критериев, которые влияют на приоритет инженерии технических требований. Предоставленный алгоритм позволяет рассчитать упорядоченный приоритет для требований, основанных на этих критериях. Это тщательно разработанный и количественно выраженный подход. К недостаткам такого подхода можно отнести объем усилий, необходимых для согласования и установки всех ценностей по двенадцати критериям. Кроме того, всякий раз, когда потребуется повторная приоритезация, шаги по согласованию ценностей также придется выполнять заново. Применение настоящего алгоритма в Agile проекте при длительности итерации от двух до четырех недель может оказаться непростой задачей по двум основным причинам:
Четко обозначена необходимость регулярного пересчета приоритета требований. Изменение приоритезации требований обсуждается в [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). |
Еще интересные статьи на эту тему:
|
