Метод MoSCoW

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

Заглавные буквы в акрониме MoSCoW означают:

• M — должен сделать это (англ. — «MUST have this.»)
• S — должен сделать это, если это вообще возможно (англ. — «SHOULD have this if at all possible.»)
• C — мог бы сделать это, если это не повлияет отрицательно на что-то другое (англ. — «COULD have this if it does not affect anything else.»)
• W — не будет достаточно времени на это, но в будущем хотелось бы. Или хочу. (англ. — «WON’T have this time but WOULD like in the future. Alternatively WANT.»)

Буквы «о» добавлены в акроним MoSCoW для удобства произношения. Часто их оставляют строчными, чтобы показать, что они ничего не означают. Некоторые считают, что акроним должен выглядеть так: MuSCoW, чтобы точнее отображать слова из которых он состоит. Но MoSCoW предпочтительнее, так как легче запоминается из-за созвучности со столицей Российской Федерации.

Основа

Такое использование метода MoSCoW было впервые разработано Даем Клегом из Oracle UK Consulting; при ускорении метода CASE: подход RAD; хотя позже он передал права интеллектуальной собственности консорциуму методов разработки с помощью динамических систем (Dynamic Systems Development Method (DSDM)).

Метод MoSCoW часто используется с таблицами расписания, где срок выполнения поставлен так, чтобы можно было сосредоточиться лишь на самых важных требованиях. С этой точки зрения, он рассматривается как ядро мгновенной разработки приложений (Rapid application development (RAD)) в процессах разработки программного обеспечения, например, в разработке с помощью динамических систем и методах динамической разработки программного обеспечения.

Объяснение

Все требования важны, но среди них производят расстановку приоритетов для отбора тех, которые в наименьший срок принесут наибольшие выгоды. Сначала, разработчики попытаются выполнить требования M, S и C, но если временная шкала не соответствует темпам выполнения задачи, то наиболее приоритетным становится выполнение требований S и C. Назначение слов, из которых состоит акроним MoSCoW состоит в том, чтобы объяснить тем, кто использует этот метод, как надо расставлять приоритеты не так, как это делают обычно, например, деля задачи на высокий, средний и низкий уровни приоритета.

Должен сделать

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

Должен сделать это, если возможно

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

Мог бы сделать, если не повлияет отрицательно на что-то другое

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

Вряд ли удастся (но хотелось бы)

такие требования и не обязательны и от них меньше всего отдачи, или просто не нужны в данный момент. В итоге, эти требования не вносятся в расписание для выполнения. Они откладываются до рассмотрения их возможного включения в последующие пункты расписания. Это, тем не менее, не делает их менее значимыми. Часто про них можно сказать: «Хотелось бы иметь» в будущем. Это вкладывает в категорию WON’T неоднозначность в плане ее сравнения с приоритетностью других категорий.

Источники