MoSCoW, co jest Mustem a co nie

Metoda MoSCoW to technika priorytetyzacji używana w zarządzaniu, analityce, zarządzaniu projektami, dostarczaniu oprogramowania aby osiągnąć wspólne zrozumienie z interesariuszami w kwestii ważności kolejności wymagań. Powstała na potrzeby przedsięwzięć typu Fix Time.


MoSCoW to akronim gdzie każda litera określa kategorię ważności:

Must have,
Should have,
Could have,
Won’t have.

Litera “o” to łącznik, zazwyczaj pisany małą literą, w celu ułatwienia w wymowie nazwy techniki.

Wg zasady MoSCoW wszystkie wymagania pochodzące od interesariuszy są znaczące, ale część z nich, szybko dostarczona, powinna wcześniej przynieść znaczącą wartość biznesową.

Z punktu widzenia dostarczania oprogramowania, zespoły developerskie powinny spróbować dostarczyć wszystkie wymagania z grupy M,S i C, lecz w przypadku nieoczekiwanych problemów, te oznaczone najpierw C, a potem S, powinny zostać odrzucone, aby skupić się na tych najważniejszych.

moscow

 

Dostarczenie wymagań z priorytetem MUST jest krytyczne aby przyrost (timebox, czy sprint) zakończył się sukcesem. Niedostarczenie przynajmniej jednego wymagania z priorytetem Must oznacza porażkę przyrostu.

Wymagania oznaczone SHOULD trzeba traktować jako ważne, ale nie krytyczne dla dostarczanego przyrostu. Niedostarczenie ich będzie “bolesne”, ale nie powinno spowodować porażki projektu.

Wymagania oznaczone COULD są pożądane, ale nie krytyczne. Powinny być dostarczane na końcu, jeśli czas na to pozwala.

Wymagania WON’T zostały oznaczone przez interesariusza jako najmniej krytyczne wymagania. Ich dostarczenie da najmniejszą wartość dla interesariusza i ewentualnego użytkownika.

Funkcjonalności Won’t mogą jednak być przydatne aby:
– wyjaśnić zakres projektu,
– porównać je z wymaganiami o wyższych priorytetach.
Umieszcza się je więc w product backlogu, lecz nie ujmuje się ich w planie przyrostu.

TIPS and TRICKS:
– Każde wymaganie może zmienić priorytet jeśli interesariusz dostarczy nowe ważniejsze wymagania.

– Priorytety się zmienią – to prawie pewne 🙂 Dam przykład: w wybranym przyroście wymaganie miało znacznik S. Nie zostało dowiezione. W kolejnym przyroście może być już M, bo nie dowieziono go poprzednio. Może być też C lub W bo nie zostało dostarczone na wyznaczony czas, a teraz jego priorytet dla usera jest mniejszy.

– Rozważ nadawanie priorytetów od Won’t aby później nadawać wymaganiom wyższe priorytety.

– Pracując z Mustami, można zadać sobie pytanie co się stanie gdy jedno z takich zadań nie zostanie dowiezione. Jeśli odpowiedź będzie zbliżona do “projekt / przyrost się nie uda” to znaczy, że trafnie dobraliśmy priorytet. Analogicznie, jeśli w noc poprzedzającą deploy okaże się, że jest problem z dowiezieniem lub jakością Must’a, zadajmy sobie pytanie czy powinniśmy nadal realizować wdrożenie. Jeśli odpowiedź jest zbliżona do “Przerwijmy wdrożenie” to znaczy, że trafnie dobraliśmy priorytet.

– Dostarczenie wymagania Must nie może być zależne od innych wymagań. O tym mówi też zasada INVEST. Zwłaszcza wymaganie typu Must nie może być zależne od wymagań o niższym priorytecie.

– Ciekawy przykład mówi o określaniu procedury odzyskiwania systemu IT. Dobrze napisana potrzeba mówi: System musi (Must) „wstać” w czasie 1h, ale idealnie byłoby (should) gdyby zajęło to mniej niż 15 minut.

– MoSCoW można użyć nie tylko developowaniu – użyj jej także do tworzenia ToDoListy lub w testowaniu, zarządzaniu błędami.

 

Metoda MoSCoW nie jest doskonała:
– nie dostarcza skali aby określić priorytet danego wymogu w stosunku do innych (np. który Must jest bardziej Must pośród innych Mustów)

– wymaganie Won’t nie określa czy wymaganie nie będzie realizowane w ogóle, czy tylko w tym przyroście – znaczenie Won’t należy więc dopracować z interesariuszem.

Reklamy