Co to jest technika MoSCoW?
Metoda MoSCoW jest techniką priorytetyzacji stosowaną w zarządzaniu, analizie biznesowej, zarządzaniu projektami i tworzeniu oprogramowania w celu osiągnięcia wspólnego porozumienia z interesariuszami na temat wagi, jaką przywiązują oni do dostarczenia każdego wymagania; jest ona również znana jako priorytetyzacja MoSCoW lub analiza MoSCoW. Technika priorytetyzacji MoSCow odgrywa kluczową rolę w zwinnym zarządzaniu projektami. W projekcie Agile istotne jest, aby zrozumieć znaczenie różnych rzeczy. Dzieje się tak dlatego, że czas jest zasobem stałym, więc priorytetyzacja jest stosowana do wymagań, zadań, produktów, przypadków użytkowników, itd. Bądź bardzo ostrożny, to nie jest technika Agile (włączając Scrum, Kanban, XP i tak dalej), ale ta technika jest szeroko stosowana w Agile. W prawie wszystkich certyfikatach pojawiają się pytania dotyczące techniki MoSCoW.
Sam termin MoSCoW jest akronimem pochodzącym od pierwszej litery każdej z czterech kategorii priorytetyzacji (Must have, Should have, Could have, and Won’t have), z międzywyrazowym Os dodanym, aby słowo było wymawialne. Podczas gdy Os są zwykle pisane małymi literami, aby wskazać, że nic nie oznaczają, MOSCOW jest również używany z dużych liter.
Priorytetyzacja wymagań MoSCoW
Wszystkie wymagania są ważne, ale są one priorytetyzowane, aby dostarczyć największe i najbardziej bezpośrednie korzyści biznesowe na początku. Deweloperzy będą początkowo próbowali dostarczyć wszystkie wymagania Must have, Should have i Could have, ale wymagania Should i Could będą pierwszymi, które zostaną usunięte, jeśli czas dostarczenia będzie zagrożony.
Must Have
Zapewniają one minimalny użyteczny podzbiór (MUS) wymagań, które projekt gwarantuje dostarczyć. Może to być zdefiniowane przy użyciu niektórych z poniższych:
Bez tego nie można dostarczyć w terminie docelowym
Bez tego nie ma sensu dostarczać w terminie docelowym; gdyby nie zostało dostarczone, nie byłoby sensu wdrażać rozwiązania w zamierzonym terminie
Bez tego nie jest legalne
Bez tego nie jest bezpieczne
Bez tego nie można dostarczyć Uzasadnienia Biznesowego
Zadaj pytanie: „co się stanie, jeśli to wymaganie nie zostanie spełnione?” Jeśli odpowiedź brzmi „anuluj projekt – nie ma sensu wdrażać rozwiązania, które nie spełnia tego wymagania”, to jest to wymaganie Must Have. Jeśli jest jakiś sposób na obejście tego wymagania, nawet jeśli jest to ręczne obejście, to będzie to wymaganie typu „Powinienem mieć” lub „Mógłbym mieć”. Obniżenie rangi wymagania do Powinno Mieć lub Mogłoby Mieć nie oznacza, że nie zostanie ono dostarczone, po prostu, że dostarczenie nie jest gwarantowane.
Powinno Mieć
Istotne, ale nie kluczowe
Może być bolesne do pominięcia, ale rozwiązanie jest nadal wykonalne
Może wymagać jakiegoś obejścia, np. zarządzanie oczekiwaniami, jakaś nieefektywność, istniejące rozwiązanie, papierkowa robota, itp.
Powinien być odróżniony od Mógłby być poprzez ocenę stopnia bólu spowodowanego jego niespełnieniem, w kategoriach wartości biznesowej lub liczby osób, których dotyczy.
Could Have
Chciane lub pożądane, ale mniej ważne
Mniejszy wpływ w przypadku pominięcia (w porównaniu z Should Have)
Won’t Have this time
Jedną z korzyści metody MoSCoW jest to, że umieszcza ona kilka inicjatyw w kategorii „won’t-not-have”. Pomaga to zarządzać oczekiwaniami co do tego, co nie zostanie uwzględnione w konkretnym wydaniu (lub w innym przedziale czasowym, dla którego ustalasz priorytety).
Umieszczenie inicjatyw w kategorii „won’t-not-have” jest jednym ze sposobów zapobiegania rozrostowi zakresu. Jeśli inicjatywy znajdują się w tej kategorii, zespół wie, że nie powinny być priorytetem w tym konkretnym przedziale czasowym. Niektóre inicjatywy z grupy „won’t-not-have” otrzymają priorytet w przyszłości, podczas gdy inne prawdopodobnie w ogóle nie zostaną zrealizowane. Niektóre zespoły decydują się na rozróżnienie pomiędzy nimi poprzez stworzenie podkategorii w ramach tej grupy.
Podsumowanie
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) jest głównie używane do priorytetyzacji wymagań, chociaż technika ta jest również przydatna w wielu innych obszarach. Atern zaleca nie więcej niż 60% wysiłku dla Must Haves dla projektu, z 40% Shoulds i Coulds. Wszystko powyżej 60% stanowi ryzyko dla powodzenia i przewidywalności projektu, chyba że środowisko jest dobrze zrozumiane, zespół jest powołany, a ryzyka zewnętrzne są minimalne.