Из Википедии, бесплатной энциклопедии
  (Перенаправлено из метода MoSCoW )
Перейти к навигации Перейти к поиску
Для использования в других целях, см Московские правила и Москва (значения) .

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

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

Добавляются межстраничные символы O , чтобы слово стало произносимым. В то время как O обычно пишутся строчными буквами, чтобы указать, что они ничего не означают, MOSCOW также используется заглавными буквами .

Фон [ править ]

Этот метод определения приоритетов был разработан Даем Клеггом [1] в 1994 году для использования в быстрой разработке приложений (RAD). Впервые он широко использовался с 2002 года в рамках гибкой среды разработки проектов Dynamic Systems Development Method (DSDM) [2] .

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

Приоритезация требований [ править ]

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

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

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

Должны быть
Требования, помеченные как обязательные, имеют решающее значение для текущего графика доставки, чтобы она была успешной. Если даже одно обязательное требование не включено, выполнение проекта следует считать неудачным (примечание: требования могут быть понижены с обязательного требования по согласованию со всеми соответствующими заинтересованными сторонами; например, когда новые требования считаются более важными). ДОЛЖЕН также рассматриваться как аббревиатура от Minimum Usable Subset.
Должен иметь
Требования, помеченные как « Должны быть» , важны, но не обязательны для доставки в текущем временном интервале. В то время как должны иметь требование может быть столь же важно , как и должна иметь , они часто не как критичные по времени или может быть другим способом , чтобы удовлетворить требование , чтобы он мог быть задержан до доставки в будущем timebox.
Мог бы иметь
Требования, помеченные как « Могут быть» , желательны, но не обязательны и могут улучшить пользовательский опыт или удовлетворенность клиентов за небольшую стоимость разработки. Обычно они включаются, если позволяют время и ресурсы.
Не будет (на этот раз)
Требования, помеченные как « Не будет» , были согласованы заинтересованными сторонами как наименее критичные, с наименьшей окупаемостью или неприемлемые в то время. В результате, не буду иметь требование не планируется в расписание на следующую доставке timebox. Не будет иметь требования отбрасываются или пересмотрены для включения в более позднем timebox. (Примечание: иногда используется термин « Хотел бы иметь ; однако это использование неверно, поскольку этот последний приоритет явно указывает на то, что что-то выходит за рамки поставки»). (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. ^ Wernham, Brian (2012). Гибкое управление проектами для правительства . Мейтленд и Стронг. ISBN 978-0957223400.
  5. ^ Дэвис, Барби (2012). Гибкие практики для водопадных проектов: изменение процессов ради конкурентного преимущества . Профессиональная серия по управлению проектами. Издательство Дж. Росс. ISBN 978-1604270839.
  6. ^ Клайн, Алан (2015). Гибкая разработка в реальном мире . Апресс. ISBN 978-1484216798.
  7. ^ а б Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению . Вашингтон, США: Microsoft Press. С. 320–321. ISBN 978-0-7356-7966-5.
  8. ^ a b Макинтайр, Джон (20 октября 2016 г.). «Москва или Кано - как вы расставляете приоритеты?» . HotPMO! . Проверено 23 октября 2016 года .
  9. ^ «Пошаговая приоритезация для стартапов: создайте свою дорожную карту с помощью метода PriX» . Блог Pixelfield . 2020-04-02 . Проверено 24 октября 2020 .

Внешние ссылки [ править ]

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