Aktualności

MoSCoW to metoda priorytetyzowania zakresu projektu, którą poznałam stosunkowo niedawno – jakieś dwa, trzy lata temu – i od razu pożałowałam, że nie znałam jej wcześniej. Odkąd zaczęłam stosować MoSCoW życie moje i klientów mych stało się relatywnie o parę ciężkich westchnień lżejsze.

MoSCoW to narzędzie pierwotnie stosowane przy priorytetyzacji wymagań do oprogramowania. Swoje korzenie ma w metodyce DSDM (Dynamic Software Development Method). To jedna z pierwszych (jeśli nie pierwsza) metod Agile. Powstała w 1994 roku kiedy to jeszcze iteracyjne podejście do wytwarzania produktu brzmiało jak pomysł polecenia klientowi by wykąpał się zimą w przeręblu w Wiśle, a sama nazwa Agile po prostu nie istniała. Ale o tej metodyce bardzo chętnie, innym razem 😉 Skupmy się na narzędziu.

MoSCoW daje nam przepis na posortowanie wymagań projektu odpowiednio co do istotności.

Kategorie istotności wymagania

MUST haves (muszą być) – zbiór wymagań inaczej nazywany Minimum Usable SubseT. Mówimy zatem o wymaganiach, bez których projekt nie ma sensu. W przypadku oprogramowania będą to funkcjonalności bez których nowa aplikacja nie ma szans zaistnieć, a bynajmniej nie może spełnić swojej podstawowej użyteczności. Dla przykładu, w projekcie bankowości mobilnej byłaby to możliwość logowania na konto przez klienta.

SHOULD haves (powinny być) – zbiór wymagań, które nie są krytyczne dla projektu, jednak są istotne, wartościowe z punktu widzenia użytkownika. Na przykład, w naszym projekcie bankowości mobilnej mogłaby to być możliwość zapisywania odbiorców. Bez tej funkcji nadal mogę robić przelewy z każdego urządzenia na całym świecie. Jednak opcja tworzenia listy odbiorców to standard, którego oczekuje każdy użytkownik.

COULD haves (mogłyby być) – zbiór wymagań, które są mile widziane i mogłyby zostać zapewnione bez większego wysiłku, czy kosztu. Jeśli pojawi się zagrożenie nie skończenia projektu na czas, te wymagania jako pierwsze nie zostaną zrealizowane. W przypadku naszego przykładu bankowości mobilnej mogłaby to być dodatkowa funkcja kalkulatora na rachunku mobilnym.

WON’T haves (nie będzie) – zbiór wymagań, które chcemy mieć zrealizowane, jednak nie w tej fazie, nie w tym projekcie, nie w tym sprincie. Inaczej klasyczne out of scope.

Kiedy stosować MoSCoW?

MoSCoW można zastosować zarówno do zakresu całego projektu, jak i do zakresu kolejnych faz, czy sprintów. Narzędzie to jest obecnie bardzo popularne wśród zespołów działających zwinnie, choćby scrumowo. Dzięki niemu, możemy tworzyć elastyczne plany z naturalnie wbudowanym buforem. Takim zapasem stają się wszystkie wymagania z kategorii Could haves i Should haves. Zatem MoSCoW to narzędzie idealne dla projektów, w których działa timeboxing.

Z kim klasyfikować istotność wymagania?

Dla praktyków zarządzania projektami to pytanie z kategorii pytań „co się kręci: słońce, czy ziemia”.  Jednak by potraktować temat holistycznie, powiedzmy sobie wprost. Wymagania biorą się od interesariuszy, a zatem od: klientów, użytkowników, zespołów realizacyjnych, instytucji regulujących rynek, na którym funkcjonuje nasz produkt, konkurencji itd. Pamiętajcie więc, by nie tylko zebrać od nich wymagania, ale i zapytać, przeanalizować istotność wymagań z ich punktu widzenia.

Skąd wiedzieć co jest SHOULD, a co COULD?

Przychodzę na spotkanie i mówię: słuchajcie, tu jest taka metoda MoSCoW, które z Waszych wymagań to Must haves? STOP, nie do końca to tak wygląda. W dojrzałym zespole scrumowym na pewno tak. Ale u klienta, dla którego prowadzę projekt po raz pierwszy lub u klienta spoza branży IT takie rozpoczęcie miałoby dwa skutki:

• Kompletna konsternacja,

po chwili otrząśnięcia:

• Wszystkie wymagania sklasyfikowane jako MUST haves.

W myśl zasady „dostosuj swój komunikat do odbiorcy”, czasem nawet nie wymieniam nazwy narzędzia. Jeśli zapytam, które z wymagań jest najważniejsze, zazwyczaj dowiaduję się, że wszystkie są krytyczne dla projektu. Klientom bardzo często wydaje się, że wszystko jest ważne i pilne.

Pamiętajcie: takie odpowiedzi dostajecie, jakie zadajecie pytania.

Oto przykłady pytań, które można zadać:

MUST haves

Bez czego ten produkt nie zadziała?

Kiedy ten produkt nie będzie miał sensu?

Które funkcjonalności są krytyczne z punktu widzenia użytkownika?

Które wymagania bezpośrednio spełniają cel użytkowy produktu?

Które wymagania realizują korzyść biznesową?

Bez których wymagań produkt nie będzie spełniał zasad bezpieczeństwa?

Bez których wymagań produkt nie będzie zgodny z przepisami?

SHOULD haves i COULD haves

Aby uzyskać te dwie kategorie, najlepiej jest przejrzeć listę MUST haves i do każdego (czasem ponownie) zadać pytanie:

Czy bez tej funkcjonalności produkt będzie działał?

Kolejna metoda to uszczegółowienie MUST haves, a dokładnie: rozpisanie ich na mniejsze wymagania. W ten sposób, w myśl zasady granulacji, otrzymamy również SHOULD haves i COULD haves.

Różnica między tymi dwoma kategoriami jest taka, że brak realizacji SHOULD haves jest bolesny w skutkach. Zazwyczaj niesie ze sobą jakieś konsekwencje, np. musimy napisać procedurę, zrobić dodatkowe testy, naprawić coś innego. Pominięcie COULD haves nie wiąże się z poważniejszymi konsekwencjami (poza nieco niezadowolonym zamawiającym, który chciał wszystko).

WON’T haves:

Czego nie zrobimy tym razem?

Co możemy zaadresować w kolejnej fazie projektu?

Ile MUST, a ile reszty?

Dobre praktyki mówią, że powinniśmy dążyć do podzielenia listy wymagań na:

60% MUST haves

20% SHOULD haves

20% COULD haves

W ten sposób tworzymy sobie wspomniany wcześniej bufor. Jesteśmy w stanie zobowiązać się do ukończenia np. sprintu w danym terminie wiedząc, że w razie niedoszacowań, problemów, będziemy mogli zrezygnować z części COULD haves, a w najbardziej czarnym scenariuszu dowieziemy jedynie MUST haves. Skąd te proporcje? Otóż statystyki mówią, że minimum, które realizujemy w większości projektów, to właśnie 60-65% pierwotnego planu.

Konieczność aktualizacji

Oczywiście Wasz MoSCoW nigdy nie będzie wykuty w skale. Będzie się zmieniał tak często, jak często klient zmienia zdanie, jak często zmienia się otoczenie projektowe. Już na początku projektu warto ustalić cykle, w których będziecie przeglądać listę wymagań celem aktualizacji priorytetów.

Korzyści ze stosowania MoSCoW

MoSCoW to narzędzie szczególnie przydatne w metodykach zwinnych, w których mamy do czynienia z timeboxami. Chroni czas realizacji projektu i jakość produktu. Najpierw skupiamy się na tym, co krytyczne, bez konieczności obniżania jakości wykonania by zdążyć również z pozostałymi funkcjonalnościami. MoSCoW idealnie sprawdzi się w projektach regulowanych, w których termin końcowy projektu jest z góry określony. Można też go zastosować wobec budżetu, w projektach, w których koszty stanowią nieelastyczne ograniczenie.

——————————

Pisząc ten artykuł też miałam swoje wymagania:

Must – ma być opisane narzędzie, mają być przykłady, narzędzie praktyczne w rzeczywistości, nie w teorii, narzędzie uniwersalne, poprawna polszczyzna

Should – załączony fajny obrazek do tekstu

Could – nie powinno być dłużej niż 2 strony w Wordzie

Won’t – tym razem nie ma być o zarządzaniu zespołami, strategią, ani o komunikacji

Mój timebox to był wieczór. Zaczęłam po północy i jest prawie 5 rano, więc wyszło trochę dłużej, ale w ostatecznym terminie – przed wyjazdem na urlop – się zmieściłam 😉

Jedno mnie teraz martwi – moje wymagania, spisałam je chybcikiem, fragmentarycznie i (nazwijmy to po imieniu) flejtuchowato. Przy takim wyimaginowanym projekcie można sobie na to pozwolić. W rzeczywistości nigdy nie mogłabym sobie pozwolić na niedbale spisane wymagania (komu się to zdarzyło, ten wie jakie piekło to oznacza). Ale o tym może następnym razem…