Метод MoSCoW - MoSCoW method

Для использования в других целях см. Московские правила и Москва (значения).

В Метод MoSCoW метод приоритезации, используемый в управлении, бизнес-анализ, управление проектом, и разработка программного обеспечения прийти к общему пониманию с заинтересованные стороны по важности, которую они придают доставке каждого требование; он также известен как Приоритезация MoSCoW или же Анализ MoSCoW.

Период, термин Москва сам по себе акроним получается из первой буквы каждой из четырех категорий приоритетов (Должны быть, Должен иметь, Мог бы иметь, и Не будет) с межстраничным Оs добавлен, чтобы слово стало произносимым. В то время как Оs обычно в нижнем регистре, чтобы указать, что они ничего не означают, заглавные буквы МОСКВА также используется.

Фон

Этот метод приоритезации был разработан Даем Клеггом.[1] в 1994 году для использования в Быстрая разработка приложений (РАД). Впервые он широко использовался с гибкий рамки реализации проекта Метод разработки динамических систем (DSDM)[2] с 2002 г.

MoSCoW часто используется с таймбоксинг, где установлен крайний срок, поэтому основное внимание следует уделять наиболее важным требованиям, и поэтому этот метод обычно используется в гибкая разработка программного обеспечения такие подходы, как Scrum, быстрая разработка приложений (RAD) и DSDM.

Приоритезация требований

Все требования важны, но они расставлены по приоритетам, чтобы обеспечить максимальную и немедленную выгоду для бизнеса на раннем этапе. Первоначально разработчики постараются предоставить все Должны быть, Должен иметь и Мог бы иметь требования, но Должен и Мог требования будут удалены в первую очередь, если сроки доставки выглядят угрожающими.

Простое английское значение категорий приоритезации имеет важное значение для того, чтобы клиенты лучше понимали влияние установки приоритета по сравнению с такими альтернативами, как Высоко, Середина и Низкий.

Под категориями обычно понимают:[3]

Должны быть
Требования помечены как Должны быть критически важны для текущего графика доставки, чтобы она была успешной. Если хоть один Должны быть требование не включено, выполнение проекта следует считать неудачным (примечание: требования могут быть понижены с Должны бытьпо согласованию со всеми соответствующими заинтересованными сторонами; например, когда новые требования считаются более важными). ДОЛЖЕН также можно считать акроним для минимального используемого подмножества.
Должен иметь
Требования помечены как Должен иметь важны, но не обязательны для доставки в текущие сроки. Пока Должен иметь требования могут быть такими же важными, как Должны быть, они часто не так критичны по времени, или может быть другой способ удовлетворить требование, чтобы его можно было отложить до будущего графика доставки.
Мог бы иметь
Требования помечены как Мог бы иметь желательны, но не обязательны и могут улучшить пользовательский опыт или удовлетворенность клиентов за небольшую стоимость разработки. Обычно они включаются, если позволяют время и ресурсы.
Не будет (на этот раз)
Требования помечены как Не будет, были согласованы заинтересованными сторонами как наименее критичные, с наименьшей окупаемостью или не подходящие в то время. Как результат, Не будет потребности не включены в график следующей поставки. Не будет требования либо отменяются, либо пересматриваются для включения в более позднее время. (Примечание: иногда термин Хотел бы иметь используется; однако это использование неверно, поскольку последний приоритет явно указывает на то, что что-то выходит за рамки поставки). (BCS в издании 3 и 4 Книги бизнес-анализа описывает «W» как «хочу иметь, но не в этот раз»)

Варианты

Иногда W используется для обозначения желания (или желания), т.е. все еще возможно, но вряд ли будет включено (и менее вероятно, чем может). Затем он отличается от X для исключенных для элементов, которые явно не включены.

Использование в разработке новых продуктов

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

Например, если в команде слишком много потенциальных эпиков (т. Е. Высокоуровневых рассказы ) для следующего выпуска своего продукта они могли бы использовать Метод MoSCoW выбрать, какие эпосы Должны быть, который Должен иметь, и так далее; то минимально жизнеспособный продукт (или MVP) будут все эпики, отмеченные как Должны быть.[4] Часто команда обнаруживает, что даже после определения своего MVP у нее слишком много работы для ожидаемой производительности. В таких случаях команда могла бы использовать Метод MoSCoW чтобы выбрать, какие функции (или истории, если это подмножество эпосов в их организации) Должны быть, Должен иметь, и так далее; то минимум товарных характеристик (или MMF) будут все отмеченные как Должны быть.[5] Если после выбора MVP или MMF будет достаточно возможностей, команда может запланировать включение Должен иметь и даже Мог бы иметь предметы тоже.[6]

Критика

Критика метода MoSCoW включает:

  • Не помогает выбрать между несколькими требованиями с одинаковым рангом.
  • Отсутствие обоснования того, как ранжировать конкурирующие требования: почему что-то должен скорее, чем должен.[7][8]
  • Неопределенность в сроках, особенно Не будет категория: нет ли этого в этом выпуске или никогда.[7]
  • Возможность политической ориентации на создание новых функций вместо технических улучшений (таких как рефакторинг).[8]

Другие методы

Другие методы, используемые для приоритезации продуктов, включают:[9]

  • RICE метод
  • Стоимость задержки
  • PriX метод
  • Картографирование историй

Рекомендации

  1. ^ Клегг, Дай; Баркер, Ричард (1994). Ускоренный метод кейса: подход RAD. Эддисон-Уэсли. ISBN  978-0-201-62432-8.
  2. ^ Биттнер, Курт; Спенс, Ян (30 августа 2002). Моделирование вариантов использования. Эддисон-Уэсли Профессионал. ISBN  978-0-201-70913-1.
  3. ^ «Анализ MoSCoW (6.1.5.2)». Руководство к своду знаний по бизнес-анализу (2-е изд.). Международный институт бизнес-анализа. 2009 г. ISBN  978-0-9811292-1-1.
  4. ^ Вернем, Брайан (2012). Гибкое управление проектами для правительства. Мейтленд и Стронг. ISBN  0957223404.
  5. ^ Дэвис, Барби (2012). Гибкие методы реализации проектов Waterfall: изменение процессов ради конкурентных преимуществ. Профессиональная серия по управлению проектами. Издательство Дж. Росс. ISBN  1604270837.
  6. ^ Клайн, Алан (2015). Гибкая разработка в реальном мире. Апресс. ISBN  1484216792.
  7. ^ а б Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению. Вашингтон, США: Microsoft Press. С. 320–321. ISBN  978-0-7356-7966-5.
  8. ^ а б Макинтайр, Джон (20 октября 2016 г.). «Москва или Кано - как вы расставляете приоритеты?». HotPMO!. Получено 23 октября, 2016.
  9. ^ «Пошаговая приоритезация стартапов: построение дорожной карты с помощью метода PriX». Блог Pixelfield. 2020-04-02. Получено 2020-10-24.

внешняя ссылка

  • RFC 2119 (уровни требований) Этот RFC определяет уровни требований, которые будут использоваться в официальной документации. Он обычно используется в контрактах и ​​другой юридической документации. Отмечено здесь, поскольку формулировка аналогична, но не обязательно по значению.
  • Буферизованные московские правила В этом эссе предлагается использовать модифицированный набор московских правил, который позволяет достичь целей определения приоритетности результатов и обеспечить определенную степень уверенности в зависимости от неопределенности базовых оценок.
  • Приоритезация MoSCoW Шаги и советы по приоритизации в соответствии с правилами DSDM MoSCoW.
  • Метод ToToTo Метод, основанный на методе определения приоритетов MoSCoW.