MoSCoW – metoda priorytetyzacji

Metoda MoSCoW jest jedną z metod nadawania priorytetów i określenia ważności prac. Myśląc o MoSCoW, bardzo często skupiamy się na wytwarzaniu oprogramowania (a przynajmniej na tym zapewne skupiają się moi czytelnicy 😉 ). Trzeba przy tym pamiętać, że sam proces wytwórczy to nie tylko pisanie linijek kodu, ale również inne aspekty.

W kontekście podejścia zwinnego, MoSCoW sprawdzi się zarówno do priorytetyzacji całego projektu, zadań, historyjek użytkownika, testów, czy też kryteriów akceptacji.

Tutaj warto zaznaczyć, że bardzo często (w zderzeniu z realiami), wystarczająco dobrym rozwiązaniem będzie określenie MoSCoW na poziomie historyjek użytkownika. Wskaże to nam w bardzo łatwy sposób ważność danego zagadnienia, nad którym pracuje zespół…

Przechodząc do meritum, skrót MoSCoW pochodzi od angielskich słów:

Rozwinięcia tych skrótów bardzo jasno wskazują nam, który element w jakim stopniu jest istotny dla całego projektu.

Rozróżnienie priorytetów

Podczas określania priorytetów na pewno pojawi się burzliwa dyskusja, który element powinien posiadać dany priorytet. Każde wymaganie ma jakiś wpływ na użytkownika końcowego, pracę ludzi wewnątrz organizacji, czy też realny wpływ na zysk firmy. Również brak dostarczenia wymagania może mieć negatywny wpływ na różne obszary. Zwrócenie uwagi na ten aspekt może pomóc w poprawnym określeniu priorytetów.

W przypadku MUST sprawa powinna być prostsza, ale w dzisiejszych czasach regulaminów, ustaw, RODO, zapewnienia bezpieczeństwa danych, trzeba bardzo szeroko spoglądać na wymagania związane z priorytetem MUSI BYĆ. Poza samymi usprawnieniami dla użytkownika końcowego, rozwiązanie powinno zapewniać legalność, bezpieczeństwo, stabilność itd. Warto mieć to na uwadze.

W przypadku priorytetu SHOULD, dostarczenie rozwiązania jest ważne, ale nie jest kluczowe. Bez tego dany projekt / historyjka użytkownika może istnieć, ale skutki tego mogą być odczuwalne.

COULD z kolei, to wymagania mniej ważne, ale nadal oczekiwane. Pominięcie wymagania nie wpływa znacząco na całość rozwiązania. Wymaganie COULD jest również pierwszym, które odrzuca się w sytuacji zagrożenia dostarczenia wymagań z zakresu MUST.

Ostatni, najniższy priorytet to WON’T HAVE THIS TIME. W tym przypadku, akceptujemy, że dane wymagania nie będą dostarczone i zespół jest co do tego zgodny. Wymaganie to, może być dostarczone w kolejnych etapach lub znaleźć się na liście wymagań, w celu nakreślenia wizji i zakresu projektu.

W tym rozdziale warto wspomnieć, że bardzo często priorytet MUST jest mylony z priorytetem SHOULD i przydzielanie tego priorytetu jest nadużywane. MUST jest na tyle silny, że niespełnienie wymagania przekreśla projekt i wdrożenie go bez danego zagadnienia, nie ma sensu.

MoSCow i dobre praktyki

Zaleca się, aby zadania związane z priorytetem MUST nie przekraczały 60% wszystkich wymagań. Inne zalecenie mówi nam również, aby nasze wymagania określone jako COULD zajmowały około 20%.

W przypadku, gdy procent oszacowanych wymagań jako MUST przekracza 60%, istnieje duże ryzyko niepowodzenia projektu. Tylko w bardzo dojrzałych zespołach, w dobrze znanym środowisku pracy, gdy nie występuje duża liczba zagrożeń, można podjąć ryzyko oszacowania większej ilości zadań określonych jako priorytet MUST.

Zapewne w głowie niektórych rodzi się pytanie, związane z początkowymi fazami projektu, ciągłym dowożeniem na czas i chronicznym brakiem zasobów… Przecież będąc na początku projektu często będziemy zmagać się z problemem braku czasu, więc większość z naszych wymagań będzie miało priorytet MUST? Gdzie zatem miejsce na 20% COULD?

Wyobraźmy sobie, że musimy zaimplementować wyszukiwarkę produktów w naszym sklepie. Oczywiście wyszukiwarka sama w sobie będzie miała priorytet MUST, jednak schodząc do niższego poziomu, możemy podzielić wyszukiwarkę na odrębne elementy i taki sposobem:

• wyszukiwanie po nazwie będzie MUST,
• szukanie po kategorii może mieć priorytet SHOULD,
• szukanie po cechach produktów może mieć priorytet COULD.

Mam nadzieję, że powyższy przykład pomoże podjąć decyzję, że warto zejść do niższego poziomu, aby bardziej precyzyjnie wskazać ścieżki rozwoju naszego projektu.

Reagowanie na zagrożenia, zmiana priorytetów, rezygnacja z realizacji

Istnieją sytuacje, gdy pewne zagadnienia zostały poddane błędnej estymacji, w trakcie realizowania zagadnienia powstały nieprzewidziane problemy, nastąpiły problemy kadrowe lub na naszej liście „TODO” powstały nowe, ważniejsze zagadnienia. Powodów może być mnóstwo…

W takiej sytuacji, bardzo często należy ponownie ustalić priorytety zadań lub nawet zrezygnować z realizacji pewnych historyjek. Dobrą metodą jest zastanowienie się, które elementy funkcjonalne są niezbędne użytkownikowi, aby przejść główne ścieżki potrzebne w procesie.

Żeby bardziej zobrazować sytuację, główną ścieżką może być zakup produktu w sklepie. Samego zakupu możemy dokonać poprzez wybór z listy czy wybór przez wyszukiwarkę. Następnie możemy dodać produkt do koszyka, opłacić poprzez płatności online itd. Czy w pierwszej fazie zrezygnowanie z płatności online na rzecz standardowego przelewu przekreśla proces? Najprawdopodobniej nie, zatem rezygnacja z tego elementu jest odpowiedzią na powstałe zagrożenie.

Inną metodą, jest określenie częstotliwości używania danego rozwiązania przez użytkownika końcowego, a w przypadku braku dostarczenia historyjki – wpływu na produkt końcowy. Podczas takiej analizy może okazać się, że część z wymagań to tylko usprawnienia, które można pominąć. Można też zdekomponować historyjkę użytkownika na mniejsze elementy i ponownie nadać priorytety.

MoSCoW i przykład z życia

Dla odmiany, aby nie było mocno technicznie, naszym projektem będzie wykonanie urodzinowego tortu…
Naszym MUST musi być przygotowanie biszkoptu oraz owoce w środku.
I na tym w sumie można by zakończyć, produkt byłby wystarczająco dobry, aby podać go przynajmniej w gronie swojej rodziny i tłumaczyć się brakiem czasu… 😉
Pójdźmy krok dalej…
SHOULD – masa z bitej śmietany na górze i po bokach tortu.
Fajnie też, aby była jakaś dekoracja.
SHOULD – owocowa dekoracja na górze tortu.
COULD mógłby być czekoladowy napis z dedykacją.
WONT to z kolei zimne ognie, ale z racji jedzenia tortu w zamkniętym pomieszczeniu, rezygnujemy z tego elementu. Mamy jednak na uwadze, że w przyszłości taki element mógłby być dołączony.

Jak widzicie bez MUST cały projekt nie ma sensu, SHOULD z kolei jest ważną rzeczą, ale nie dyskwalifikuje naszego tortu jako coś, czego nie da się zjeść… COULD to już tylko dodatki, które w zasadzie nie wpłyną na walory smakowe, a jedynie wpłyną na wartość wizualną.

Źródła:
Obraz: https://unsplash.com/photos/5fNmWej4tAA