Technika MoSCoW: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Dodanie TL;DR) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 13 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
==TL;DR== | ==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 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. | ||
| Linia 22: | Linia 6: | ||
==Charakterystyka techniki MoSCoW== | ==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. | 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 | * 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. | * 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ą | * 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. | * 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. | ||
<google> | <google>n</google> | ||
==Priorytetyzacja wymagań techniki MoSCoW== | ==Priorytetyzacja wymagań techniki MoSCoW== | ||
Ważnym czynnikiem sukcesu każdego [[projekt|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: | Ważnym czynnikiem sukcesu każdego [[projekt|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, | * 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, | * 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, | * 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. | * 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== | ==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. | 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 [[harmonogram|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". | Wstępne priorytety pracy MoSCoW w ramach Timebox, oraz ciągła, ponowna [[ocena]] tego co można osiągnąć w uzgodnionym [[harmonogram|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". | ||
{{infobox5|list1={{i5link|a=[[Metody kontroli zasobów]]}} — {{i5link|a=[[Ogólna charakterystyka metodyki Prince 2]]}} — {{i5link|a=[[Testowanie w projekcie]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Zarządzanie zmianą w projekcie]]}} — {{i5link|a=[[Kamień milowy]]}} — {{i5link|a=[[Zasady zarządzania projektem wg PRINCE2]]}} — {{i5link|a=[[Plan projektu]]}} — {{i5link|a=[[Czarna lista]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | |||
* Bittner K., Spence I. (2003), ''Use Case Modeling'', Addison Wesley, New York | * Bittner K., Spence I. (2003), ''Use Case Modeling'', Addison Wesley, New York | ||
* Chrapko M. (2015), '' | * Chrapko M. (2015), ''Scrum: o zwinnym zarządzaniu projektami'', Wydawnictwo Helion, Gliwice | ||
* Harleen K | * Harleen K. (2014), ''A Systematic Study on Agile Software Development Methodologies and Practices'', vol.5, IJCSIT, India | ||
* Kaczor K. ( | * Kaczor K. (2018), ''Scrum i nie tylko. Teoria i praktyka w metodach Agile'', Wydawnictwo naukowe PWN, Warszawa | ||
*Łabuda W. (2015), [ | * Łabuda W. (2015), ''[https://zeszyty-naukowe.wwsi.edu.pl/zeszyty/zeszyt13/Podejscie_zwinne_a_tradycyjne_do_projektow_wytwarzania_oprogramowania.pdf Podejście zwinne a tradycyjne do projektów wytwarzania oprogramowania]'', Zeszyty Naukowe WWSI, No 13, Vol. 9, Warszawa | ||
* Ma Q. (2009), | * 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), | * PMI (2021), ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management'' | ||
* Richards K. (2012), ''Agile Project Managemen: Integrating DSDM into an existing PRINCE2 environment'', Chief Executive, KRC | |||
* Voight J. | * Voight J. (2004), ''Dynamic System Development Method'', Zurich | ||
*'' | * Wysocki R. (2013), ''Efektywne zarządzanie projektami. Tradycyjne, zwinne, ekstremalne'', Helion, Gliwice | ||
</noautolinks> | |||
{{a|Sylwia Świgut}} | {{a|Sylwia Świgut}} | ||
[[Kategoria: | [[Kategoria:Planowanie w projekcie]] | ||
[[en:MoSCoW technique]] | [[en:MoSCoW technique]] | ||
{{#metamaster:description|Technika MoSCoW to metoda priorytetyzacji zadań w projektach, która pomaga określić, które wymagania są niezbędne, a które można odłożyć. Pozwala efektywnie zarządzać czasem i zasobami.}} | |||
Aktualna wersja na dzień 21:33, 5 sty 2024
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
- 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. (2014), A Systematic Study on Agile Software Development Methodologies and Practices, vol.5, IJCSIT, India
- Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach 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
- PMI (2021), A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management
- Richards K. (2012), Agile Project Managemen: Integrating DSDM into an existing PRINCE2 environment, Chief Executive, KRC
- Voight J. (2004), Dynamic System Development Method, Zurich
- Wysocki R. (2013), Efektywne zarządzanie projektami. Tradycyjne, zwinne, ekstremalne, Helion, Gliwice
Autor: Sylwia Świgut
