Московский метод
Другие способы использования см. в правилах Москвы и Москвы. 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.
Критика[править]
Критика московского метода включает:
- Не помогает выбрать между несколькими требованиями с одинаковым приоритетом.
- Отсутствие обоснования того, как ранжировать конкурирующие требования: почему что-то должно, а не должно.[7][8]
- Неоднозначность во времени, особенно в отношении категории Won't have: независимо от того, есть ли она в этом выпуске или нет никогда.[7]
- Потенциал политического фокуса на создании новых функций вместо технических улучшений (таких как рефакторинг).[8]
ЧМО[править]
Человек Московской Области.
Другие методы[править]
Другие методы, используемые для определения приоритетов продуктов, включают:
- Скоринговая модель РАЙСА
- Метод PriX метод приоритизации
- Метод расстановки приоритетов сюжетных карт
- Метод приоритизации ценности и усилий
- Метод приоритизации модели Кано
- Метод определения приоритетов оценки возможностей
- Метод приоритизации дерева продуктов
- Стоимость метода приоритизации задержек
- Купить метод определения приоритетов функций