MoSCoW method

Визначення пріоритетів MoSCoW або аналіз MoSCoW - це метод визначення пріоритетів, який використовується в управлінні, бізнес-аналізі, управлінні проектами та розробці програмного забезпечення для досягнення спільного розуміння із зацікавленими сторонами щодо важливості, яку вони надають виконанню кожної вимоги.

Термін "Москва" є абревіатурою, утвореною з першої літери кожної з чотирьох категорій пріоритетності: M - Must have, S - Should have, C - Could have, W - Won't have.

Метод MoSCoW визначення пріоритетів був розроблений Даєм Клеггом (Dai Clegg) у 1994 році для використання у швидкій розробці додатків (rapid application development - RAD). Вперше він був широко використаний з методом розробки динамічних систем (dynamic systems development method - DSDM) з 2002 року.

Визначення пріоритетності вимог

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

Просте англійське значення категорій пріоритетності має цінність для того, щоб допомогти замовникам краще зрозуміти вплив встановлення пріоритету порівняно з такими альтернативами, як високий (High), середній (Medium) та низький (Low).

Під категоріями зазвичай розуміють:[3]

Must have
Вимоги, позначені як Must have, є критично важливими для дотримання поточних термінів поставки для того, щоб вона була успішною. Якщо хоча б одна вимога Must have не включена, виконання проекту слід вважати невдалим. MUST також може розглядатися як абревіатура для мінімально придатної підмножини (Minimum Usable Subset).

Should have
Вимоги, позначені як Should have, є важливими, але не обов'язковими для виконання в поточні терміни. Хоча вимоги, які слід виконати, можуть бути настільки ж важливими, як і вимоги, які необхідно виконати, вони часто не є настільки критичними за часом, або може існувати інший спосіб задовольнити вимогу, щоб її можна було відкласти до майбутнього терміну виконання.

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

Won't have (this time)
Вимоги, позначені як Won't have, були узгоджені зацікавленими сторонами як найменш критичні, з найнижчою окупністю, або як такі, що не є доцільними на даний момент. Як наслідок, Won't have, не включаються до графіка на наступний період поставки. Потреби, які не будуть задоволені, або відміняються, або переглядаються для включення в більш пізні терміни. (Примітка: іноді використовується термін "Would like to have"; однак, таке використання є некоректним, оскільки цей останній пріоритет чітко вказує на те, що щось виходить за межі обсягу поставки). (BCS Business Analysis Book у виданні 3 та 4 описує "W" як "Want to have but not this time around").

Варіанти
Іноді W використовується для позначення бажання wish (або хотіли б - would), тобто все ще можливо, але навряд чи буде включено (і менш ймовірно, ніж могло б). Тоді це відрізняється від X, що означає "виключено" для елементів, які явно не включені.

Використання при розробці нових продуктів

При розробці нового продукту, особливо при використанні Agile підходів до розробки програмного забезпечення, завжди потрібно зробити більше, ніж дозволяє час або фінансування - виникає необхідність у визначенні пріоритетів.

Якщо команда має занадто багато потенційних epics (тобто історій високого рівня) для наступного випуску свого продукту, вони можуть використовувати метод MoSCoW, щоб вибрати, які epics є Must have, які Should have і т.д.;

Мінімально життєздатним продуктом (або MVP) будуть всі ті epics, які позначені як Must have.

Мінімальними ринковими функціями (або MMF) будуть всі ті, що позначені як Must have. Якщо після вибору MVP або MMF є достатня потужність, команда може планувати включити елементи Should have і навіть Could have.

Критика методу MoSCoW:

• Не допомагає прийняти рішення між декількома вимогами в межах одного пріоритету.
• Відсутність обґрунтування того, як ранжувати конкуруючі вимоги: чому щось є must, а не should.
• Невизначеність щодо термінів, особливо щодо категорії "Won't have": чи не буде її в цій версії, чи не буде взагалі.
• Потенціал для політичного фокусу на створенні нових функцій, а не на технічних вдосконаленнях (таких як рефакторинг)[8].

Інші методи визначення пріоритетів продукту (Prioritization Frameworks):

• Kano
• MoSCoW method
• Цінність vs. Складність (Value vs. Complexity)
• RICE scoring model
• Групування спорідненості (Affinity Grouping)
• Opportunity scoring
• WSJF
• Buy-a-feature і схожий The 100 Point Method
• Story mapping
• ICE Scoring
• Зважена оцінка (Weighted Scoring)
• PriX
• Value vs. effort
• The product tree
• Cost of delay

Що ще треба допрацювати в ст

Що ще треба допрацювати в статті:
- Посилання на терміни управління, бізнес аналіза та керування проектами;
- Agile, MVP, RAD, DSDM (посилання на статтю);