Technika MoSCoW

TL;DR

Technika MoSCoW to metoda priorytetyzacji wymagań w zarządzaniu projektami, która dzieli je na cztery kategorie: Must, Should, Could, Won’t. Must to wymagania niezbędne, Should to ważne, Could to pożądane, a Won’t to nieplanowane. Technika ta jest użyteczna w ustalaniu priorytetów i planowaniu czasu w projekcie. MoSCoW można również zastosować w ramach timeboxów, czyli określonych czasowych ram pracy, aby zapewnić terminowe ukończenie projektu.

Technika MoSCoW

Technika MoSCoW jest metodą uniwersalną, wykorzystywaną na przykład w zarządzaniu projektami pozwalającą na zrozumienie i określanie priorytetów, która ma na celu dostarczenie zespołowi projektowemu wyraźnych wskazówek dotyczących znaczenia kolejności wymagań. Jest to jedna z technik szeregowania, mająca istotne znaczenie w procesie decyzyjnym. Pojedyncze litery metody wywodzą się od angielskich wyrażeń Must have (niezbędne), Should have (zalecane), Could have (przydatne) oraz Wouldn’t it be nice to have (mile widziane) lub Won’t have. Każda pozycja może być dopasowana do jednej kategorii. Techniką MoSCoW trzeba więc posługiwać się rozważnie, gdyż zawsze występuje ochota przydzielania wszystkich funkcji jako niezbędne. Aby powstrzymać taki niekorzystny efekt, można zastosować zasadę, zgodnie z która w każdej kategorii powinno być nie mniej niż 20 procent wszystkich funkcji. Technika MoSCoW obecna jest w Metodzie tworzenia systemów dynamicznych DSDM (Dynamic System Development Method).

Charakterystyka techniki MoSCoW

Jak podaje A Guide to the Business Analysis Body of Knowledge, technika MoSCoW wyodrębnia cztery kategorie - Must, Should, Could, Won’t.

• Must - opisuje wymagania, które muszą być spełnione w finalnym rozwiązaniu, aby było ono uznane za skuteczne
• Should - reprezentuje pozycję o wysokim priorytecie, która powinna być uwzględniona w rozwiązaniu, jeśli jest to tylko możliwe. Często jest to krytyczny wymóg, ale również taki, który może być spełniony w inny sposób, jeśli jest to bezwzględnie konieczne.
• Could - opisuje wymóg uznany za pożądany, ale nie konieczny. Zostanie uwzględniony jeśli czas i zasoby na to pozwolą
• Won’t - przedstawia wymaganie, które jeśli interesariusze wyrażą zgodę, nie zostanie wdrożone w danym wydaniu, ale można je rozważyć w przyszłości.

Priorytetyzacja wymagań techniki MoSCoW

Ważnym czynnikiem sukcesu każdego projektu jest zapewnienie, że wymagania są priorytetowe. Technika MoSCoW jest najprostszą metodą priorytetyzacji. Jej przedstawienie zajmuje najmniej czasu i prowadzi do wysokiej pewności jej użyteczności. Umiejętne stosowanie priorytetów w zarządzaniu zadaniami, potrafi przesądzić o naszym sukcesie lub porażce. Priorytety wskazują nam, które zadania powinniśmy realizować w pierwszej kolejności, a które mogą zwyczajnie być odłożone na późniejszy termin:

• Must have - opisuje najmniejszy z możliwych zbiór wymagań, które projekt zapewnia doręczyć w produkcie końcowym. Jeżeli brakowałoby chociaż jednego wymagania z priorytetem MUST, oznaczałoby to porażkę projektu. opisują najbardziej niekorzystny z punktu widzenia biznesowego, ale dopuszczalny przypadek,
• Should have - są to wymagania istotne z biznesowego punktu widzenia, lecz nie niezbędne dla prawidłowego funkcjonowania produktu końcowego projektu. Mogą więc być pominięte, bez szkodliwego na niego wpływu, oraz mogą być przyłączone do obszaru projektu dla podtrzymania go na ścieżce planu bazowego. Ich pominięcie może być skomplikowany oraz kosztowne,
• Could have - oczekiwane z biznesowego punktu widzenia, lecz mniej istotne dla funkcjonalności produktu końcowego projektu. Ich przeoczenie ma mniejszy wpływ na funkcjonalność produktu końcowego, niż zlekceważenie wymagań mających priorytet Should Have. Mogą być przyłączone do zakresu projektu bez negatywnych skutków. Ich obejście jest tanie i łatwe,
• Won’t have - zgodnie z ustaleniami zespołu projektowego z przedstawicielami biznesu, nie będą zastosowane w produkcie końcowym projektu (mogą być dostarczone w innym czasie). istnieją zatem poza zakresem projektu w określonych, sztywnych ramach czasowych jego wykonania. Usprawniają zarządzanie oczekiwaniami biznesowymi, choć nie znajdą się w doręczonym przez zespół projektowy produkcie końcowym projektu.

Zastosowanie MoSCoW w ramach timeboxów

Timeboxing, określa priorytety dotyczące badań i wdrażania w oparciu o przydział środków trwałych. Jest stosowany, gdy podejście do rozwiązania było ustalone. Wyraża priorytety wymagań w oparciu o ilość pracy, którą zespół projektowy jest w stanie dostarczyć w określonym czasie. Podejście to jest najczęściej używane, gdy trzeba dotrzymać ustalonego terminu lub dla rozwiązań, które są poprawiane często i regularnie. Wstępne priorytety pracy MoSCoW w ramach Timebox, oraz ciągła, ponowna ocena tego co można osiągnąć w uzgodnionym harmonogramie, gwarantuje że dzięki Timeboxom wszystko zostanie ukończone na czas za każdym razem. Zastosowanie MoSCoW w ramach Timeboxów jest również pomocne w praktycznym użyciu, gdyż uskutecznia pracę nad danym projektem. Timeboxy mogą zawierać kilka zadań i na końcu muszą dostarczyc produkt. Mogą ulec zmianie skoro zadania są zdefiniowane, ale niekoniecznie dostarczone. Mogą się zmienić, jeśli zmiana priorytetyzacji podczas iteracji Timeboxów, pozwoli na szybką odpowiedź na potrzeby biznesowe. Krótko mówiąc DSDM raczej ogranicza funkcjonalność na rzecz ukończenia zadania na czas. Timeboxy nie są jednak lekarstwem na wszystkie poślizgi czasowe. W niektórych przypadkach może zaważyć sytuacja, że koszt nadmiernego czasu jest mniejszy niż spadek niektórych funkcji i jest to prawdopodobnie przypadek, gdy pojawia się nowa funkcja "Must have".

Technika MoSCoW — artykuły polecane

Metody kontroli zasobów — Ogólna charakterystyka metodyki Prince 2 — Testowanie w projekcie — Backlog produktu — Feature-Driven Development — Zarządzanie zmianą w projekcie — Kamień milowy — Zasady zarządzania projektem wg PRINCE2 — Plan projektu — Czarna lista

Bibliografia

• A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, version 2.0, IIBA-200911231134-455082, Canada 2009
• Bittner K., Spence I. (2003), Use Case Modeling, Addison Wesley, New York
• Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
• Harleen K. F. (2014), A Systematic Study on Agile Software Development Methodologies and Practices, vol.5, IJCSIT, India
• Kaczor K. (2016), Scrum i nie tylko. Teoria i praktyka w mwtodach Agile, Wydawnictwo Naukowe PWN, Warszawa
• Łabuda W. (2015), Podejście zwinne a tradycyjne do projektów wytwarzania oprogramowania, Zeszyty Naukowe WWSI, No 13, Vol. 9, Warszawa
• Ma Q. (2009), The Effectiveness of Requirements Prioritization Techniques for a Medium to Large Number of Requirements: A Systematic Literature Review, Auckland University of Technology
• Richards K. (2012), Agile Project Managemen: Integrating DSDM into an existing PRINCE2 environment, Chief Executive, KRC
• Voight J. J. B, (2004), Dynamic System Development Method, Zurich
• Wysocki R. (2013), Efektywne zarządzanie projektami. Tradycyjne, zwinne, ekstremalne, Helion, Gliwice

Autor: Sylwia Świgut