Московский метод

Материал из wikixw
Версия от 19:36, 10 августа 2022; Cc82737 viki (обсуждение | вклад) (→‎Критика)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Перейти к навигации Перейти к поиску

Другие способы использования см. в правилах Москвы и Москвы. MoSCoW method

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

Сам термин "Москва" является аббревиатурой, производной от первой буквы каждой из четырех категорий приоритизации: M - Должен иметь, S - Должен иметь, C - Мог иметь, W - Не будет иметь.

Чтобы сделать слово произносимым, добавляются междоузлия. В то время как O s обычно в нижнем регистре, чтобы указать, что они ничего не стоят, также используется заглавная МОСКВА.

Предыстория[править]

Этот метод приоритизации был разработан Дэем Клеггом в 1994 году для использования в быстрой разработке приложений (RAD). Впервые он широко использовался с методом разработки динамических систем (DSDM) с 2002 года.

Московский метод часто используется с timeboxing, где крайний срок фиксируется так, что фокус должен быть на наиболее важных требованиях, и обычно используется в гибких подходах к разработке программного обеспечения, таких как Scrum, rapid application development (RAD) и DSDM. Приоритизация требований

Все требования важны, однако для получения наибольших и наиболее непосредственных выгод для бизнеса на ранней стадии требования должны быть приоритетными. Разработчики сначала попытаются выполнить все требования Must have, Should have и Could have, но требования Should и Could будут удалены в первую очередь, если сроки доставки окажутся под угрозой.

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

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

Должен иметь

Требования, обозначенные как Must have, имеют решающее значение для текущего ящика времени доставки, чтобы он был успешным. Если даже одно требование Must have не включено, выполнение проекта следует считать неудачным (примечание: требования могут быть понижены с Must have по согласованию со всеми заинтересованными сторонами; например, когда новые требования считаются более важными). MUST также можно считать аббревиатурой для минимального полезного подмножества.

Должен иметь

Требования, обозначенные как должны быть, важны, но не необходимы для доставки в текущем ящике времени доставки. Хотя требования должны быть такими же важными, как и требования должны быть, они часто не так критичны по времени, или может быть другой способ удовлетворить требование, чтобы его можно было отложить до будущего времени доставки.

Мог бы

Требования, обозначенные как "Могли бы быть", желательны, но не необходимы и могут улучшить пользовательский опыт или удовлетворенность клиентов при небольших затратах на разработку. Они обычно включаются, если позволяют время и ресурсы.

Не будет (на этот раз)

Требования, обозначенные как "Не будут иметь", были согласованы заинтересованными сторонами как наименее критичные, с наименьшей окупаемостью или неуместные в то время. В результате не будет требований, не запланированных в расписании для следующей доставки timebox. Не будут иметь требования либо отброшены, либо пересмотрены для включения в более поздний временной интервал. (Примечание: иногда используется термин "Хотел бы иметь"; однако это использование неверно, так как этот последний приоритет явно указывает на то, что что-то выходит за рамки поставки). (BCS в изданиях 3 и 4 книги "Бизнес-анализ" описывает "W" как "Хочу иметь, но не в этот раз")

Варианты[править]

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

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

Например, если у команды слишком много потенциальных эпиков (т. Е. историй высокого уровня) для следующего выпуска своего продукта, они могут использовать московский метод для выбора того, какие эпики должны иметь, какие должны иметь и так далее; минимальный жизнеспособный продукт (или MVP) будет всемэти эпики отмечены как Must have. Часто команда обнаруживает, что даже после определения своего MVP у нее слишком много работы для ожидаемой мощности. В таких случаях команда может использовать московский метод, чтобы выбрать, какие функции (или истории, если это подмножество эпосов в их организации) должны иметь, Должны иметь и так далее; минимальными рыночными функциями (или MMF) будут все те, которые помечены как Must have. Если после выбора MVP или MMF есть достаточная емкость, команда может затем запланировать включить элементы Should have и даже Could have.

Критика[править]

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

  1. Не помогает выбрать между несколькими требованиями с одинаковым приоритетом.
  2. Отсутствие обоснования того, как ранжировать конкурирующие требования: почему что-то должно, а не должно.[7][8]
  3. Неоднозначность во времени, особенно в отношении категории Won't have: независимо от того, есть ли она в этом выпуске или нет никогда.[7]
  4. Потенциал политического фокуса на создании новых функций вместо технических улучшений (таких как рефакторинг).[8]

ЧМО[править]

Человек Московской Области.

Другие методы[править]

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

Пруф[править]

ietf.org/rfc/rfc2119.txt