Metoda MoSCoW

Metoda MoSCoW jest techniką ustalania priorytetów stosowaną w zarządzaniu, analizie biznesowej , zarządzaniu projektami i tworzeniu oprogramowania w celu osiągnięcia wspólnego zrozumienia z interesariuszami co do wagi, jaką przywiązują do realizacji każdego wymagania ; jest również znany jako ustalanie priorytetów MoSCoW lub analiza MoSCoW .

termin MOSKWA jest akronimem pochodzącym od pierwszej litery każdej z czterech kategorii priorytetów: M — musi mieć , S — powinien mieć , C — mógłby mieć , W — nie będzie miał .

Śródmiąższowe O są dodawane, aby słowo można było wymówić. Podczas gdy O s są zwykle pisane małymi literami, aby wskazać, że nie oznaczają niczego, używa się również MOSKWY pisanej dużymi literami. ^{[ potrzebne źródło ]}

Tło

Ta metoda ustalania priorytetów została opracowana przez Dai Clegga w 1994 roku do użytku w szybkim opracowywaniu aplikacji (RAD). Po raz pierwszy był szeroko stosowany w metodzie dynamicznego rozwoju systemów (DSDM) od 2002 roku.

MoSCoW jest często używany z ramami czasowymi , gdzie termin jest ustalony, tak aby skupić się na najważniejszych wymaganiach, i jest powszechnie stosowany w zwinnych podejściach do tworzenia oprogramowania, takich jak Scrum , szybkie tworzenie aplikacji (RAD) i DSDM .

Priorytetyzacja wymagań

Wszystkie wymagania są ważne, jednak aby zapewnić jak największe i najbardziej natychmiastowe korzyści biznesowe, wymagania muszą być uszeregowane pod względem ważności. Deweloperzy będą początkowo próbowali dostarczyć wszystkie „Must have” , „Powinien mieć ” i „Może mieć” , ale wymagania „ Powinien ” i „ Może” zostaną usunięte jako pierwsze, jeśli harmonogram dostawy będzie wyglądał na zagrożony.

Proste angielskie znaczenie kategorii ustalania priorytetów ma znaczenie dla lepszego zrozumienia przez klientów wpływu ustawienia priorytetu w porównaniu z alternatywami, takimi jak Wysoka , Średnia i Niska .

Kategorie są zazwyczaj rozumiane jako:

Musi mieć: Wymagania oznaczone jako Musi mieć są krytyczne dla bieżącego przedziału czasowego dostawy, aby odnieść sukces. Jeśli choć jedno musi mieć nie jest uwzględnione, dostarczenie projektu należy uznać za niepowodzenie (uwaga: wymagania mogą zostać obniżone z wymaganej , w porozumieniu ze wszystkimi odpowiednimi interesariuszami; na przykład, gdy nowe wymagania zostaną uznane za ważniejsze). MUST można również uznać za akronim dla minimalnego użytecznego podzbioru.

Powinien mieć: Wymagania oznaczone jako Powinien mieć są ważne, ale niekonieczne do dostarczenia w bieżącym terminie dostawy. Chociaż wymagania „Powinny mieć ” mogą być równie ważne jak „ Must have ”, często nie są tak krytyczne pod względem czasu lub może istnieć inny sposób spełnienia wymagania, aby można go było wstrzymać do przyszłego przedziału czasowego dostawy.

Może mieć: Wymagania oznaczone jako Może mieć są pożądane, ale niekonieczne i mogą poprawić wrażenia użytkownika lub zadowolenie klienta za niewielki koszt rozwoju. Zostaną one zazwyczaj uwzględnione, jeśli czas i zasoby na to pozwolą.

nie będzie (tym razem): Wymagania oznaczone jako Nie będą miały , zostały uzgodnione przez interesariuszy jako elementy najmniej krytyczne, o najniższym koszcie zwrotu lub nieodpowiednie w danym momencie. W rezultacie wymagania, których nie będzie, nie są planowane w harmonogramie dla następnego przedziału czasowego dostawy. Wymagania, które nie będą miały , zostaną odrzucone lub ponownie rozpatrzone w celu uwzględnienia w późniejszym przedziale czasowym. (Uwaga: czasami termin Chciałbym mieć Jest używane; jednak to użycie jest nieprawidłowe, ponieważ ten ostatni priorytet wyraźnie wskazuje, że coś jest poza zakresem dostawy). (BCS w wydaniu 3 i 4 Business Analysis Book opisują „W” jako „Chcesz mieć, ale nie tym razem”)

Warianty

Czasami W jest używane w znaczeniu życzenia (lub byłoby ), tj. nadal możliwe, ale mało prawdopodobne, aby zostało uwzględnione (i mniej prawdopodobne niż mogłoby ). Jest to następnie odróżniane od X dla wykluczonych dla pozycji, które wyraźnie nie są uwzględnione.

Zastosowanie w opracowywaniu nowych produktów

W opracowywaniu nowych produktów , szczególnie tych, które stosują zwinne podejście do tworzenia oprogramowania, zawsze jest więcej do zrobienia, niż pozwala na to czas lub fundusze (stąd potrzeba ustalania priorytetów).

opowieści na wysokim poziomie ) do następnej wersji swojego produktu, może użyć metody MoSCoW , aby wybrać, które eposy to Must have , które powinny mieć itd.; minimalny opłacalny produkt (lub MVP) to wszystkie eposy oznaczone jako „Muszę mieć” . Często zdarza się, że zespół stwierdza, że nawet po określeniu MVP ma zbyt dużo pracy w stosunku do oczekiwanych możliwości. W takich przypadkach zespół mógłby następnie zastosować metodę MoSCoW aby wybrać, które funkcje (lub historie, jeśli jest to podzbiór eposów w ich organizacji) to Musi mieć , Powinien mieć i tak dalej; minimalne funkcje rynkowe (lub MMF) to wszystkie te, które są oznaczone jako „Muszę mieć” . Jeśli po wybraniu MVP lub MMF jest wystarczająca pojemność, zespół może następnie zaplanować uwzględnienie Powinien mieć , a nawet Mógł mieć .

Krytyka

Krytyka metody MoSCoW obejmuje:

Nie pomaga w podejmowaniu decyzji między wieloma wymaganiami w ramach tego samego priorytetu.
Brak racjonalnego uzasadnienia, jak uszeregować konkurencyjne wymagania: dlaczego coś jest raczej koniecznością niż powinno .
Niejednoznaczność co do czasu, zwłaszcza w kategorii Nie będzie : czy nie ma jej w tym wydaniu, czy nigdy.
Potencjał politycznego skupienia się na tworzeniu nowych funkcji zamiast ulepszeń technicznych (takich jak refaktoryzacja).

Inne metody

Inne metody stosowane do ustalania priorytetów produktów obejmują:

Model punktacji RICE
Metoda priorytetyzacji metody PriX
Metoda priorytetyzacji mapowania historii
Metoda ustalania priorytetów wartość vs. wysiłek
Metoda priorytetyzacji modelu Kano
Metoda ustalania priorytetów szans
Metoda priorytetyzacji drzewa produktów
Koszt metody priorytetyzacji opóźnień
Kup metodę ustalania priorytetów funkcji

Linki zewnętrzne

RFC 2119 (Poziomy wymagań) Ten dokument RFC definiuje poziomy wymagań, które mają być używane w dokumentacji formalnej. Jest powszechnie stosowany w umowach i innych dokumentach prawnych. Odnotowano tutaj, ponieważ sformułowanie jest podobne, ale niekoniecznie takie samo.
Buforowane reguły MoSCoW Ten esej proponuje zastosowanie zmodyfikowanego zestawu reguł MoSCoW, które realizują cele polegające na uszeregowaniu wyników pod względem ważności i zapewnieniu stopnia pewności jako funkcji niepewności bazowych szacunków.
Priorytety MoSCoW Kroki i wskazówki dotyczące ustalania priorytetów zgodnie z zasadami DSDM MoSCoW.