метод МОСКОВА

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

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

Межстраничные буквы O добавляются, чтобы сделать слово произносимым. Хотя буквы O заглавная МОСКВА . обычно пишутся строчными буквами, чтобы указать, что они ничего не обозначают, также используется ^{[ нужна ссылка ]}

Фон

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

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

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

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

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

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

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

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

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

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

Варианты

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

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

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

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

Критика

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

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

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

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

Метод приоритезации модели Кано

Ссылки

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

Внешние ссылки

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

[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 978-0957223400 .

[5] Дэвис, Барби (2012). Гибкие практики для каскадных проектов: изменение процессов ради конкурентного преимущества . Профессиональная серия по управлению проектами. Издательство Дж. Росс. ISBN 978-1604270839 .

[6] Клайн, Алан (2015). Гибкая разработка в реальном мире . Апресс. ISBN 978-1484216798 .

[:0-7] Перейти обратно: ^а ^б Вигерс, Карл; Битти, Джой (2013). Требования к программному обеспечению . Вашингтон, США: Microsoft Press. стр. 320–321. ISBN 978-0-7356-7966-5 .

[:1-8] Перейти обратно: ^а ^б Макинтайр, Джон (20 октября 2016 г.). «Москва или Кано – как вы расставляете приоритеты?» . ГорячийПМО! . Проверено 23 октября 2016 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]