Атрибуты Scrum

8.3. Определение приоритетов пользователей

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

На сегодня существует множество различных техник расстановки приоритетов. Лишь небольшая их часть может быть применена для приоритизации пользовательских историй как единицы инкремента для разрабатываемого продукта в Scrum.

Рассмотрим наиболее эффективные из них:

• Принцип Эйзенхауэра. Принцип, или, как еще называют в литературе, "матрица Эйзенхауэра" - техника тайм-менеджмента для определения приоритетов задач. Выглядит матрица как четыре квадрата, которые получаются при пересечении осей "Важно - не важно" по вертикали и "Срочно - не срочно" по горизонтали ( рис. 8.2). При использовании этой матрицы по ее "частям" распределяются задачи в соответствии с их важностью и срочностью.

  1. Важные и срочные задачи. Это те задачи, которые важны, и выполнить их необходимо срочно. Без них все порушится, ничего работать не будет, и сделать их завтра - будет уже поздно.
  2. Важные, но не срочные задачи. Это те, которые срочными станут в скором времени. Успешные команды и сотрудники в первую очередь обращают свое внимание именно на этот тип задач, чтобы они постепенно не перешли в разряд "Важные и срочные задачи".
  3. Не важные, но срочные. Это тип задач, которые никак не приближают к достижению необходимого результата, которые надо делать, но исключительно для того, чтобы их делать.
     

     
     Рис. 8.2. Матрица Эйзенхауэра
  4. Не важные и не срочные. Эти задачи не важны, они не срочны, но именно их хочется делать. Это пожиратели времени, и от них необходимо избавляться.
  В момент усталости многие разработчики начинают заниматься сторонними делами, чтобы отдохнуть. Это неправильно. Правильно -запланировать качественный отдых в соответствии с индивидуальными особенностями каждого разработчика. Это задача из категории "Важно и не срочно".

  Принцип Эйзенхауэра - очень эффективная техника расстановки приоритетов. Но ее особенности больше направлены на расстановку приоритетов отдельного сотрудника, а не команды в целом.

• Методика "АБВ". В соответствии с этой методикой задачи делятся на три категории: жизненно важное, важное, приятное. Эта методика является логическим (более "глубинным") продолжением принципа Эйзенхауэра.

  Применение принципа Парето конкретизируется, если все задачи проанализировать в соответствии с их долей в итоговом результате и затем распределить по категориям важности. АБВ основывается на следующих трех закономерностях, подтвержденных опытом:

  • Самые критичные задачи (категория "А") составляют ~ 20% всех задач, которыми занят руководитель. Значимость этих задач, вклада в достижение конечного результата составляет ~ 60%.
  • Менее важные задачи (категория "Б") составляют ~ 20 % от общего числа. Их значимость - также 20% значимости задач и дел руководителя.

  • Неважные и несущественные задачи (категория "В") составляют 60% от общего числа задач. Они имеют незначительную долю - 15% в общей ценности всех задач.

  Методику "АБВ" можно применять для оценки приоритетов задач, необходимых для разработки продукта, но для того, чтобы грамотно ее использовать, владелец продукта и команда должны иметь определенный опыт и навыки по расстановке приоритетов.

• Метод MoSCoW (Oracle). Один из консультантов Oracle (Dai Clegg) предложил однозначный, логичный и понятный метод приоритизации требований для анализа и задач разработки программного обеспечения - MoSCoW. Этот метод используется при фиксированных сроках на реализацию функциональности, когда всё внимание должно быть обращено на самые приоритетные требования. Приоритизация задач методом MoSCoW позволяет сосредоточить фокус внимания как владельца продукта, так и Scrum-команды на задачах конкретного спринта.

  Все имеющиеся задачи в бэклоге продукта следует сгруппировать в четыре приоритетные корзины по следующим правилам:

  • M (must) - задачи должно быть реализованы в первую очередь, без них программный продукт не имеет смысла. От этих задач нельзя отказаться. В них заключен залог успеха. Задачи, отмеченные как must, должны быть включены в текущий спринт.
  • S (should) - следовало бы иметь, но можно отложить на более позднее время. Задачи этого типа также критичны для успеха разрабатываемого продукта, но не необходимы в ближайшее время. Такие задачи, как правило, имеют альтернативные пути решения.
  • C (could) - можно было бы иметь, но если нет возможности их разработать сейчас, то можно и отложить. Задачи этого типа менее критичны. Они обычно относятся к типу "хотелось бы иметь".
  • W (would) - в этот раз стоит отказаться от этих задач, но в следующий раз можно их сделать. Наименее критичные. Задачи данной категории не планируются к разработке в ближайшие спринты, но при будущих поставках их статус может быть пересмотрен.

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