Zarządzanie priorytetami za pomocą MoSCoW

Zarządzanie priorytetami za pomocą MoSCoW

1 2219
priorytetyzacja zadań za pomocą narzędzia moscow

Pracując w projektach spotykamy się z ogromną ilością wątków. Każdy z nich wydaje się równie istotny i dopóki nie zastosujemy jakiegoś mechanizmu do ich priorytetyzacji będziemy odczuwali duży dyskomfort z tytułu przeciążenia informacjami. W tym artykule chcemy pokazać Wam bardzo proste narzędzie, które możecie zastosować praktycznie w każdej dziedzinie życia i to nie tylko w stosunku do elementów Waszej listy To do.

POZIOM TRUDNOŚCI:  1 gwiazdka

Jak pracować z priorytetami MoSCoW?

MoSCoW to technika priorytetyzacji wymyślona przez Dai Clegga z Oracle UK Consulting. Została następnie włączona przez konsorcjum DSDM do podstaw metodyki Agile PM. Jest podstawą planowania prac w projektach podzielonych na tzw. timeboxy (np. SCRUMowe sprinty).

W skrócie polega na podziale listy wymagań (ale również dowolnego innego zestawu tematów – np. maili, na które musicie odpowiedzieć, czy zadań, które musicie wykonać) według następujących kryteriów:

  • M – Must – Czyli coś, co się musi wydarzyć. Na liście wymagań jest to ten punkt, bez którego realizacji projekt nie może wystartować. Z mustów nie da się zrezygnować, są po prostu zbyt ważne. Nadając czemuś taki priorytet zadaj sobie pytanie – czy to naprawdę jest coś, bez czego nie możemy wystartować?
  • S – Should – Shouldy to tematy bardzo pilne, których odpuszczenie będzie miało bolesne konekwencje, ale nie jest niemożliwe. Shouldami są często wymagania, które pozornie wydają się mustami, ale można je zaspokoić w jakiś inny, zastępczy sposób, jeśli będzie to konieczne.
  • C – Could – Do couldów wpadają wszystkie wymagania/tematy/zadania, które mogłyby się wydarzyć, ale nie są niezbędne.
  • W – Won’t – Te sprawy po prostu odpuszczamy.

W swoim pierwotnym zastosowaniu MoSCoW określał priorytety wymagań w projekcie. Z czasem narzędzie rozpowszechniło się i zaczęło być również w innych obszarach procesu produkcji oprogramowania, np. przy testach (do określania priorytetów na liście błędów).

Przyjrzyjmy się teraz przykładowi wykorzystania MoSCoW przy projekcie budowy samochodu : – ) Poniżej wypisałem kilkanaście składowych samochodu i nadałem im priorytety. Dajcie znać w komentarzach, czy się ze mną zgadzacie!

MUST (bez tego nie pojedziemy)

  • Koła.
  • Kierownica.
  • Silnik.
  • Hamulce.
  • Skrzynia biegów.

SHOULD

  • Siedzenia (w najgorszym wypadku wstawimy do środka 4 taborety :).
  • Wycieraczki.
  • Nawiew.
  • Lusterka.

COULD

  • Radio.
  • Elektrycznie opuszczane szyby.
  • Autoalarm.

WON’T

  • Skórzana tapicerka.
  • Automatyczne wykrywanie zmiany pasa ruchu.
  • Czujnik deszczu.
  • Podgrzewane siedzenia.

 

Praca w ramach timeboxów – Praktyczne zastosowanie

MoSCoW ma bardzo istotne praktyczne zastosowanie – pozwala w dosyć precyzyjny i skuteczny sposób planować prace zespołu projektowego. Zasada pracy z tym narzędziem jest taka, że w ramach timeboxa 60% czasu może zostać poświęcone na wymagania z priorytetem MUST, 20% na wymagania z priorytetem SHOULD i 20% na wymagania z priorytetem COULD. Zachowanie tych proporcji pozwala na dużą elastyczność w trakcie trwania prac. Jeśli pojawi się jakaś zmiana (np. poprzez zmaterializowanie się jednego z ryzyk), możemy w spokoju podjąć prace nad jej obsługą, rezygnując z wymagań Should i Could. W ten sposób uda nam się wypracować niezbędne minium w ramach zaplanowanego okresu prac i nie będziemy musieli reorganizować prac ani inicjować niepotrzebnej komunikacji.

Oczywiście w ramach timeboxa możemy poświęcić więcej czasu na zadania z priorytetem MUST. Jeśli dysponujemy doświadczonym i zgranym zespołem, albo realizujemy któryś z etapów prac z kolei, wiemy, że możemy te proporcje naginać. Zawsze jednak powinniśmy zostawić sobie przynajmniej 20% czasu trwania sprintu na nieoczekiwane wydarzenia i zadania z mniejszym priorytetem.

 

Zmiana priorytetów w czasie

Na koniec naszych rozważań warto wspomnieć o tym, że priorytety (nie tylko te opisywane za pomocą szablonu MoSCoW) zmieniają się w czasie. Coś, co mogło być COULDem na początku projektu w trakcie 3-ego, ostatniego sprintu, może już być MUSTem. Wyższy priorytet nadaje w tym wypadku po prostu zbliżający się deadline na daną funkcjonalność. Pamiętajcie o tym planując prace. Warto w tym kontekście nadać danej sprawie dwa priorytety – jeden pod kątem projektu jako całości, a drugi pod kątem obecnie prowadzonego sprintu.

Paweł Kałkus i Jarek Łojko

Użytkownicy trafili do nas po frazach:

  • moscow scrum
“Any Scrum without working product at the end of a sprint is a failed Scrum.” - Jeff Sutherland

1 KOMENTARZ

  1. Myślę, że trzeba wziąć pod uwagę wymagania prawne oraz realne wymagania użytkowania produktu. Samochód bez wycieraczek i bez jednego zewnętrznego lusterka nie zostanie dopuszczony do ruchu, a poza tym byłby po prostu niebezpieczny. :) Dla mnie to są dwa wymagania są definitywnie MUST. Fajnie, że piszesz o MoSCWie :)

Odpowiedz

seven − two =