Co to jest Priorytetyzacja MoSCoW?
Priorytetyzacja MoSCoW, znana również jako metoda MoSCoW lub analiza MoSCoW, jest popularną techniką ustalania ważności zadań. Metodę stosuje się, w celu zrozumienia zrozumieć znaczenie zadań w ramach konkretnej wersji oprogramowania. W Squares wykorzystujemy tę metodę podczas planowania sprintów oraz przygotowywania wycen. Często razem tablicą Kanban.
Akronim MoSCoW, oznacza 4 różne kategorie inicjatyw: Must Have (musi się wydarzyć), Should be (powinno się wydarzyć), Could be (może się wydarzyć) oraz Won’t be (nie wydarzy się).
M – Must Have (musi się wydarzyć)
Jak sama nazwa wskazuje, ta kategoria składa się z inicjatyw, które są „obowiązkowe” dla Twojego zespołu. Reprezentują one niezbywalne potrzeby dotyczące projektu, produktu lub wydania. Na przykład, jeśli wypuszczasz aplikację opieki zdrowotnej, konieczną inicjatywą mogą być funkcje bezpieczeństwa, które pomagają zachować zgodność.
Wszystko w kategorii „must have” jest uważane za obowiązkowe dla zespołu. Jeśli nie masz pewności, czy coś należy do tej kategorii, zadaj sobie następujące pytania.
- Co się stanie, jeśli wydamy bez tego?
- Czy istnieje obejście lub prostszy sposób na osiągnięcie tego?
- Czy wydanie / projekt / produkt będzie działać bez tej inicjatywy?
- Jeśli produkt nie będzie działał bez inicjatywy lub wydanie stanie się bez niego bezużyteczne, inicjatywa jest najprawdopodobniej „obowiązkowa”.
S – Should be (powininno się wydarzyć)
Inicjatywy, które należy mieć, to tylko krok poniżej tych, które należy mieć. Są ważne dla produktu, projektu lub wydania, ale nie są niezbędne. W przypadku pominięcia produkt lub projekt nadal działa. Jeśli jednak zostaną uwzględnione, stanowią znaczną wartość dodaną.
Inicjatywy „Should be” różnią się od inicjatyw „must have”, ponieważ można je zaplanować na przyszłe wydanie aplikacji, bez wpływu na obecną. Na przykład ulepszenia wydajności, drobne poprawki błędów lub nowa funkcjonalność mogą być inicjatywami, które powinny mieć. Bez nich produkt nadal działa.
C – Could be (może się wydarzyć, ale nie musi)
Could be to wymagania, które nie są krytyczne, ani bardzo ważne. Często postrzegano jako takie, które fajnie, gdyby się pojawiły, np. w sytuacji dodatkowego zapasu godzin lub funkcjonalności, która jest możliwa do wdrożenia 'przy okazji’. Natomiast jeżeli ich nie będzie, nie spowoduje to większego impaktu na projekt.
W – Won’t be (Nie wydarzy się)
Won’t be to inicjatywy, których nie chcemy wdrażać w najbliższym wydaniu, ale mogą zostać wdrożone w nieokreślonej przyszłości.
Źródła:
