Metodyka SCRUM: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Infobox update)
 
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 16 wersji utworzonych przez 3 użytkowników)
Linia 1: Linia 1:
{{infobox4
'''[[Metodyka]] Scrum''' to jedna z najpopularniejszych metodyk zwinnych w zarządzaniu projektami IT, oparta na zasadach [[Agile Project Management|Agile]]. To metodyka, która daje możliwość rozwiązywania złożonych problemów, adaptacji produktu, do wymagań klienta. Scrum umożliwia wydajne i innowacyjne kreowanie produktu, o możliwie jak najwyższej jakości dla klienta, ze względu na iteracyjny (przyrostowy) [[proces]] kontroli<ref>M. Ćwiklicki, Scrum - nowa [[metoda]] zarządzania złożonymi projektam, "[[Przegląd]] Organizacji", 2010 nr 4</ref>
|list1=
<ul>
<li>[[Testowanie w projekcie]]</li>
<li>[[Cykl Deminga]]</li>
<li>[[Procesy planowania wg PMBOK]]</li>
<li>[[Ogólna charakterystyka metodyki Prince 2]]</li>
<li>[[Sprint review]]</li>
<li>[[Wdrażanie systemu zarządzania projektami]]</li>
<li>[[Metodyka MSF]]</li>
<li>[[DMAIC]]</li>
<li>[[Six sigma]]</li>
</ul>
}}


Meotdyka Scrum przez twórców metody definiowana jest, jako ramy procesu ''(z ang. framework)'', w którym można wdrożyć różnorone podprocesy oraz techniki w celu zarządzania złożonym rozwojem produktu. Dzięki metodyce Scrum rozpoczęcie pracy wymaga określenia "wizji" produktu, bez konieczności dokładnego wyznaczenia szczegółowych cech formy, w jakiej ma zostać dostarczony klientowi<ref name="K. Schwaber, 2013">K. Schwaber, J. Sutherland, (2013),"The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"</ref>


==TL;DR==
Metodyka Scrum to popularna metoda zarządzania projektami IT oparta na zasadach Agile Project Management. Scrum umożliwia adaptację produktu do wymagań klienta poprzez iteracyjny proces kontroli. Metoda ta opiera się na trzech filarach: przejrzystości, adaptacji i inspekcji. Zespół Scrum składa się z właściciela produktu, zespołu odpowiedzialnego za rozwój i mistrza Scrum. Proces Scrum składa się z planowania sprintu, sprintu, codziennego scrum, przeglądu sprintu i retrospektywy sprintu.


'''Metodyka Scrum''' to jedna z najpopularniejszych metodyk zwinnych w zarządzaniu projektami IT, oparta na zasadach [[Agile Project Management|Agile]]. To metodyka, która daje możliwość rozwiązywania złożonych problemów, adaptacji produktu, do wymagań klienta. Scrum umożliwia wydajne i innowacyjne kreowanie produktu, o możliwie jak najwyższej jakości dla klienta, ze względu na iteracyjny (przyrostowy) proces kontroli.<ref>M. Ćwiklicki, Scrum - nowa metoda zarządzania złożonymi projektam, "Przegląd Organizacji", 2010 nr 4</ref>
==Historia==
Po raz pierwszy ogólne założenia metodyki Scrum opublikowano w 1986 roku, w artykule ''"The New New Product Development Game"'', w czasopiśmie Harward Bussines Review, którego autorami byli: Hirotaka Takeuchi i Ikujiro Nonaka. Artykuł opisywał wyniki badań nad sposobami tworzenia nowego produktu przeprowadzonych w firmach: Canon, Honda, Fuit-Xerox, Brother,3M, Epson, HP, Xeror. Firmy te były obserwowane w trakcie wdrażania metody Lean Management oraz teorii złożonych systemów adaptacyjnych, stąd też fundamenty Scrum nawiązują do doświadczeń zebranych w tym czasie<ref> J. Sutherland, (2004),"Agile Development: Lessons Learned from the First Scrum"</ref>


Meotdyka Scrum przez twórców metody definiowana jest, jako ramy procesu ''(z ang. framework)'', w którym można wdrożyć różnorone podprocesy oraz techniki w celu zarządzania złożonym rozwojem produktu. Dzięki metodyce Scrum rozpoczęcie pracy wymaga określenia "wizji” produktu, bez konieczności dokładnego wyznaczenia szczegółowych cech formy, w jakiej ma zostać dostarczony klientowi. <ref name="K. Schwaber, 2013">K. Schwaber, J. Sutherland, (2013),"The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"</ref>
Pierwszy [[zespół]] Scrum zarejestrowano w firmie Eeasel Corporation w 1993 roku. Na podstawie tego doświadczenia powstał artykuł: "''Agile Development: Lessons Learned from the First Scrum"'' autorstwa Kena Schwebera, który przedstawił ujednolicony tok zastosowania Scrum, a także przyczynił się do propagowania tej metodyki na skalę światową.


==Historia==
<google>n</google>
Po raz pierwszy ogólne założenia metodyki Scrum opublikowano w 1986 roku, w artykule ''"The New New Product Development Game”'', w czasopiśmie Harward Bussines Review, którego autorami byli: Hirotaka Takeuchi i Ikujiro Nonaka. Artykuł opisywał wyniki badań nad sposobami tworzenia nowego produktu przeprowadzonych w firmach: Canon, Honda, Fuit-Xerox, Brother,3M, Epson, HP, Xeror. Firmy te były obserwowane w trakcie wdrażania metody Lean Management oraz teorii złożonych systemów adaptacyjnych, stąd też fundamenty Scrum nawiązują do doświadczeń zebranych w tym czasie.<ref> J. Sutherland, (2004),"Agile Development: Lessons Learned from the First Scrum”</ref>


Pierwszy zespół Scrum zarejestrowano w firmie Eeasel Corporation w 1993 roku. Na podstawie tego doświadczenia powstał artykuł: "''Agile Development: Lessons Learned from the First Scrum”'' autorstwa Kena Schwebera, który przedstawił ujednolicony tok zastosowania Scrum, a także przyczynił się do propagowania tej metodyki na skalę światową.
<google>ban728t</google>
==Teoria - Scrum==
==Teoria - Scrum==
{{#ev:youtube|BTT1d2H9ZaM|480|right|Scrum krok po kroku (Sławomir Wawak)|frame}}
Scrum opiera się na empirycznej teorii sterowania procesem. Empiryzm zakłada, że [[wiedza]] pochodzi z doświadczenia i podejmowania decyzji opartych na tym, co jest już znane. Scrum stosuje podejście iteracyjne (przyrostowe) w celu optymalizacji przewidywalności i kontroli ryzyka. Zdefiniowano trzy filary, które podtrzymują każdą implementację kontroli procesu: przejrzystości ''(ang. transparency)'', adaptacji ''(ang. adaptation)'' oraz inspekcji ''(ang. inspection)''.
Scrum opiera się na empirycznej teorii sterowania procesem. Empiryzm zakłada, że wiedza pochodzi z doświadczenia i podejmowania decyzji opartych na tym, co jest już znane. Scrum stosuje podejście iteracyjne (przyrostowe) w celu optymalizacji przewidywalności i kontroli ryzyka. Zdefiniowano trzy filary, które podtrzymują każdą implementację kontroli procesu: przejrzystości ''(ang. transparency)'', adaptacji ''(ang. adaptation)'' oraz inspekcji ''(ang. inspection)''.
* '''filar przejrzystości''' - istotne aspekty procesu muszą być zaprezentowane oraz zrozumiałe dla osób odpowiedzialnych za wyniki, ponadto muszą być określone wspólnym standardem oceny. Dzięki temu cały proces, jego [[kontrola]] oraz cel końcowy są "przejrzyste".
* '''filar przejrzystości''' - istotne aspekty procesu muszą być zaprezentowane oraz zrozumiałe dla osób odpowiedzialnych za wyniki, ponadto muszą być określone wspólnym standardem oceny. Dzięki temu cały proces, jego kontrola oraz cel końcowy są "przejrzyste”.
* '''filar adaptacji''' - w przypadku zarejestrowania podczas rutynowych kontroli, jakiegokolwiek czynnika, który zaburza proces, filar adaptacji pozwala zespołowi na zmianę podejścia do sposobu pracy z dnia na dzień.
* '''filar adaptacji''' - w przypadku zarejestrowania podczas rutynowych kontroli, jakiegokolwiek czynnika, który zaburza proces, filar adaptacji pozwala zespołowi na zmianę podejścia do sposobu pracy z dnia na dzień.
* '''filar inspekcji''' - zakłada, że kontrole postępu prac, powinny być częste na tyle, by wykryć możliwość ulepszenia lub też zapobiec błędom jak najwcześniej. Aczkolwiek nie mogą być na tyle częste, by przeszkadzać w pracy zespołowi. Filar inspekcji zakłada również, że kontrola powinna być przeprowadzana przez wysoko wykwalifikowanego inspektora.<ref name="K. Schwaber, 2013"></ref>
* '''filar inspekcji''' - zakłada, że kontrole postępu prac, powinny być częste na tyle, by wykryć możliwość ulepszenia lub też zapobiec błędom jak najwcześniej. Aczkolwiek nie mogą być na tyle częste, by przeszkadzać w pracy zespołowi. Filar inspekcji zakłada również, że kontrola powinna być przeprowadzana przez wysoko wykwalifikowanego inspektora<ref name="K. Schwaber, 2013"></ref>


==Zespół Scrum==
==Zespół Scrum==
 
Zespoły Scrum są autonomiczne i wielofunkcyjne, jednostki zespołu pracując razem, mają wszystkie [[kompetencje]] niezbędne do wykonania danego zakresu pracy. Ma to na celu optymalizację wydajności, elastyczności i kreatywności.J. Werewka, M. Turek, T. Włodarek, Systematyczny opis metodyki Scrum dla zespołów projektowcyh, "Studia Informatica", 2012 nr 1
Zespoły Scrum są autonomiczne i wielofunkcyjne, jednostki zespołu pracując razem, mają wszystkie kompetencje niezbędne do wykonania danego zakresu pracy. Ma to na celu optymalizację wydajności, elastyczności i kreatywności.J. Werewka, M. Turek, T. Włodarek, Systematyczny opis metodyki Scrum dla zespołów projektowcyh, "Studia Informatica", 2012 nr 1


'''Zespół składa się z:'''
'''Zespół składa się z:'''
*'''Właściciela produktu''' ''(ang. Product Owner)'' - Właściciel produktu odpowiada za maksymalizację wartości produktu. Jego zadaniem jest konsultacja z klientem oraz opracowanie wizji produktu. W trakcie procesu tworzenia Właściel odpowiada za kontrolę każdego etapu jego powstawania, tak by spełnić wszystkie oczekiwania postawione przez klienta. Właściciel produktu koordynuje również pracę Zespołu odpowiedzialnego za rozwój oraz ściśle z nim współpracuje.
* '''Właściciela produktu''' ''(ang. Product Owner)'' - [[Właściciel]] produktu odpowiada za maksymalizację wartości produktu. Jego zadaniem jest konsultacja z klientem oraz opracowanie wizji produktu. W trakcie procesu tworzenia Właściel odpowiada za kontrolę każdego etapu jego powstawania, tak by spełnić wszystkie oczekiwania postawione przez klienta. [[Właściciel produktu]] koordynuje również pracę Zespołu odpowiedzialnego za [[rozwój]] oraz ściśle z nim współpracuje.
*'''Zespołu odpowiedzialnego za rozwój''' ''(ang. Development Team)'' - Zespół odpowiedzialny za rozwój składa się z profesjonalistów, specjalizujących się w konkretnych dziedzinach, których zakres wiedzy pokrywa wszystkie aspekty tworzenia produktu. Zespół ten upoważniony jest przez pracodawcę do organizacji i zarządzania czasem oraz wyznaczonymi zadaniami, oczywiście pod warunkiem, że dane etapy zostaną ukończone w odpowiednim czasie.
* '''Zespołu odpowiedzialnego za rozwój''' ''(ang. Development Team)'' - Zespół odpowiedzialny za rozwój składa się z profesjonalistów, specjalizujących się w konkretnych dziedzinach, których [[zakres]] wiedzy pokrywa wszystkie aspekty tworzenia produktu. Zespół ten upoważniony jest przez pracodawcę do organizacji i zarządzania czasem oraz wyznaczonymi zadaniami, oczywiście pod warunkiem, że [[dane]] etapy zostaną ukończone w odpowiednim czasie.
*'''Mistrza Scrum''' ''(ang. Scrum Master)'' - Mistrz Scrum odpowiada, za wyjaśnienie w jasny sposób zastosowania metodyki Scrum w konkretnym projekcie. kontroluje proces tworzenia produktu oraz tryb pracy Zespołu odpowiedzialnego za rozwój. Mistrz Scrum odpowiada za to, by wyznaczona metodyka była kontynuowana w trakcie procesu.
* '''Mistrza Scrum''' ''(ang. Scrum Master)'' - Mistrz Scrum odpowiada, za wyjaśnienie w jasny sposób zastosowania metodyki Scrum w konkretnym projekcie. kontroluje proces tworzenia produktu oraz tryb pracy Zespołu odpowiedzialnego za rozwój. Mistrz Scrum odpowiada za to, by wyznaczona metodyka była kontynuowana w trakcie procesu.


==Tok postępowania w metodzie Scrum==
==Tok postępowania w metodzie Scrum==
Został oparty na idei z ang, Time Boxes, czyli oparcia planu pracy na sprecyzowanych przedziałach czasu. Ze względu na powyższe założenia, można wydzielić następujące zdarzenia, które tworzą ramy tej metodyki.
Został oparty na idei z ang, Time Boxes, czyli oparcia planu pracy na sprecyzowanych przedziałach czasu. Ze względu na powyższe założenia, można wydzielić następujące zdarzenia, które tworzą ramy tej metodyki.


====Planowanie Sprintu====  
====Planowanie Sprintu====
Planowanie Sprintu ''(ang. Sprint Planning)'' z reguły podzielone jest na dwie części:
Planowanie Sprintu ''(ang. [[Sprint]] Planning)'' z reguły podzielone jest na dwie części:
* Określenie rejestru produktowego
* Określenie rejestru produktowego
* Określenie rejestru zadaniowego
* Określenie rejestru zadaniowego
Linia 54: Linia 37:
Jest to etap określany jako opcjonalny, jednak ma on na celu zminimalizowanie wkładu pracy w ustalenie zakresu projektu w późniejszych jego fazach. To etap, w którym Właściciel Produktu (ang. Product Owner) na podstawie wizji klienta określa funkcjonalne i niefunkcjonalne cechy produktu, który ma zostać stworzony w trakcie trwania projektu. Spis ten nie jest jednak sztywny, gdyż może on ulegać modyfikacji, w kolejnych etapach tworzenia. Po określeniu rejestru produktowego, definiowany jest rejestr zadaniowy. Na tym etapie Właściciel Produktu określa priorytety prac, a Zespół odpowiedzialny za rozwój zadaje pytania, które pomogą w organizacji pracy.
Jest to etap określany jako opcjonalny, jednak ma on na celu zminimalizowanie wkładu pracy w ustalenie zakresu projektu w późniejszych jego fazach. To etap, w którym Właściciel Produktu (ang. Product Owner) na podstawie wizji klienta określa funkcjonalne i niefunkcjonalne cechy produktu, który ma zostać stworzony w trakcie trwania projektu. Spis ten nie jest jednak sztywny, gdyż może on ulegać modyfikacji, w kolejnych etapach tworzenia. Po określeniu rejestru produktowego, definiowany jest rejestr zadaniowy. Na tym etapie Właściciel Produktu określa priorytety prac, a Zespół odpowiedzialny za rozwój zadaje pytania, które pomogą w organizacji pracy.


====Sprint====  
====Sprint====
Sprint to etap, w którym według uprzednio jasno określonych zadań, następuje ich realizacja. Podczas trwania Sprintu, żadne z ustaleń nie podlega zmianie. Praca zespołu opiera się na wzajemnym wsparciu, przekazywaniu sobie informacji oraz doradzaniu. Zespół bowiem sam odpowiada za to, jak będzie wyglądał ich dzienny rytm pracy, a Właścicielowi Produktu oraz Mistrzowi Scrum przedstawi efekty pracy i uwagi odnośnie zrealizowanego zakresu zadań. Czas trwania Sprintu jest ustalony jednoznacznie w fazie planowania, na dzień dzisiejszy okres trwania Sprintu przyjmuje się na ok. 30 dni, z możliwością modyfikacji.
Sprint to etap, w którym według uprzednio jasno określonych zadań, następuje ich realizacja. Podczas trwania Sprintu, żadne z ustaleń nie podlega zmianie. [[Praca]] zespołu opiera się na wzajemnym wsparciu, przekazywaniu sobie informacji oraz doradzaniu. Zespół bowiem sam odpowiada za to, jak będzie wyglądał ich dzienny rytm pracy, a Właścicielowi Produktu oraz Mistrzowi Scrum przedstawi efekty pracy i uwagi odnośnie zrealizowanego zakresu zadań. Czas trwania Sprintu jest ustalony jednoznacznie w fazie planowania, na dzień dzisiejszy okres trwania Sprintu przyjmuje się na ok. 30 dni, z możliwością modyfikacji.


====Codzienny Scrum====  
====Codzienny Scrum====
Codzienny Scrum ''(ang. Daily Scrum)'' jest to krótkie spotkanie, które odbywa się każdego dnia Sprintu, na którym Mistrz Scrum zadaje 3 pytania, na które Zespół odpowiedzialny za rozwój odpowiada:
Codzienny Scrum ''(ang. Daily Scrum)'' jest to krótkie spotkanie, które odbywa się każdego dnia Sprintu, na którym Mistrz Scrum zadaje 3 pytania, na które Zespół odpowiedzialny za rozwój odpowiada:
* Co zrobiłeś dla realizacji celu Sprintu?
* Co zrobiłeś dla realizacji celu Sprintu?
Linia 65: Linia 48:
Spotkanie ma ściśle określoną agendę, by mogło odbyć się w jak najkrótszym czasie i z pożądaną efektywnością.
Spotkanie ma ściśle określoną agendę, by mogło odbyć się w jak najkrótszym czasie i z pożądaną efektywnością.


====Przegląd Sprintu====  
====Przegląd Sprintu====
Przegląd Sprintu ''(ang. Sprint Review)'' to spotkanie po każdym Sprincie, które ma na celu omówienie funkcjonalności oraz cech produktu, a także przebiegu prac tylko i wyłącznie dla fragmentu stworzonego produktu.  
Przegląd Sprintu ''(ang. Sprint Review)'' to spotkanie po każdym Sprincie, które ma na celu omówienie funkcjonalności oraz cech produktu, a także przebiegu prac tylko i wyłącznie dla fragmentu stworzonego produktu.
 
====Retrospektywa Sprintu====
Retrospektywa Sprintu ''(ang. Sprint Retrospective)'' jest to etap refleksji po każdym Sprincie. Wszyscy członkowie zespołu Scrum spotykają się umawiają dominujące kwestie zarówno dotyczące produktu, jak i organizacji pracy. Po tym spotkaniu definiowane są wnioski, jak dane aspekty projektu można ulepszyć oraz [[plan]] wprowadzenia ulepszeń. <ref>K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A.</ref>
 
{{infobox5|list1={{i5link|a=[[Testowanie w projekcie]]}} &mdash; {{i5link|a=[[Cykl Deminga]]}} &mdash; {{i5link|a=[[Procesy planowania wg PMBOK]]}} &mdash; {{i5link|a=[[Ogólna charakterystyka metodyki Prince 2]]}} &mdash; {{i5link|a=[[Sprint review]]}} &mdash; {{i5link|a=[[Wdrażanie systemu zarządzania projektami]]}} &mdash; {{i5link|a=[[Metodyka MSF]]}} &mdash; {{i5link|a=[[DMAIC]]}} &mdash; {{i5link|a=[[Six sigma]]}} }}
 
==Przypisy==
<references />


====Retrospektywa Sprintu====
Retrospektywa Sprintu ''(ang. Sprint Retrospective)'' jest to etap refleksji po każdym Sprincie. Wszyscy członkowie zespołu Scrum spotykają się umawiają dominujące kwestie zarówno dotyczące produktu, jak i organizacji pracy. Po tym spotkaniu definiowane są wnioski, jak dane aspekty projektu można ulepszyć oraz plan wprowadzenia ulepszeń. <ref>K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A.</ref>
==Bibliografia==
==Bibliografia==
* K. Schwaber, J. Sutherland, (2013), ''[http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf"The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game" ]''
<noautolinks>
* M. Ćwiklicki, Scrum - nowa metoda zarządzania złożonymi projektam, "Przegląd Organizacji", 2010 nr 4
* Ćwiklicki M. (2010), ''Scrum - nowa metoda zarządzania złożonymi projektami'', Przegląd Organizacji, nr 4
* K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A.
* Ćwiklicki M., Włodarek T. (2010), ''Metodyka Scrum w Polsce w świetle badań'', Nauka i Gospodarka, nr 3
* J. Sutherland, (2004), ''[http://csis.pace.edu/~marchese/CS616/Agile/Scrum/FirstScrum2004.pdf"Agile Development: Lessons Learned from the First Scrum”]''
* Rubin S. (2013), ''Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile'', Helion, Gliwice
* M. Ćwiklicki, T. Włodarek, ''[http://www.poddrzewem.pl/do-pobrania/doc_details/38-metodyka-scrum-w-swietle-badan Metodyka Scrum w świetle badań]'', "Nauka i Gospodarka", 2010, nr 3
* Strona internetowa: ''[https://www.scrumguides.org Scrum guides]'', podręczniki Scrum, Sutherland J., Schwaber K.
* J. Werewka, M. Turek, T. Włodarek,''[http://studiainformatica.polsl.pl/index.php/SI/article/view/97/94 Systematyczny opis metodyki Scrum dla zespołów projektowcyh]'', "Studia Informatica", 2012 nr 1
* Sutherland J. (2004), ''[https://csis.pace.edu/~marchese/CS616/Agile/Scrum/FirstScrum2004.pdf Agile Development: Lessons Learned from the First Scrum]''
* B. Wachnik, (2016), ''[https://yadda.icm.edu.pl/baztech/element/bwmeta1.element.baztech-0aae4534-8919-4c22-b07a-f504e7946636?q=71b986bf-d98b-4f5d-a49c-074b3980b9bf$4&qt=IN_PAGE Agile Methodology as a tool for reducing information asymmetry in the implementation of it projects completed on the basis of the outsourcing strategy]'', "Information Systems in Management", 2016 nr 3
* Wachnik B. (2016), ''[https://yadda.icm.edu.pl/baztech/element/bwmeta1.element.baztech-0aae4534-8919-4c22-b07a-f504e7946636?q=71b986bf-d98b-4f5d-a49c-074b3980b9bf$4 Agile Methodology as a tool for reducing information asymmetry in the implementation of it projects completed on the basis of the outsourcing strategy]'', Information Systems in Management, nr 3
* Werewka J., Turek M., Włodarek T. (2012), ''Systematyczny opis metodyki Scrum dla zespołów projektowcyh'', Studia Informatica, nr 1
== Przypisy ==
</noautolinks>
<references />


{{a|Marta Nawrot}}
{{a|Marta Nawrot}}
[[Kategoria:Metodyki zarządzania projektami]]


[[Kategoria:Metodyki zarządzania projektami]]
{{#metamaster:description|Scrum - popularna metoda Agile w zarządzaniu projektami IT. Adaptacja produktu do wymagań klienta i kreowanie wysokiej jakości rezultatów.}}

Aktualna wersja na dzień 22:48, 7 gru 2023

Metodyka Scrum to jedna z najpopularniejszych metodyk zwinnych w zarządzaniu projektami IT, oparta na zasadach Agile. To metodyka, która daje możliwość rozwiązywania złożonych problemów, adaptacji produktu, do wymagań klienta. Scrum umożliwia wydajne i innowacyjne kreowanie produktu, o możliwie jak najwyższej jakości dla klienta, ze względu na iteracyjny (przyrostowy) proces kontroli[1]

Meotdyka Scrum przez twórców metody definiowana jest, jako ramy procesu (z ang. framework), w którym można wdrożyć różnorone podprocesy oraz techniki w celu zarządzania złożonym rozwojem produktu. Dzięki metodyce Scrum rozpoczęcie pracy wymaga określenia "wizji" produktu, bez konieczności dokładnego wyznaczenia szczegółowych cech formy, w jakiej ma zostać dostarczony klientowi[2]

TL;DR

Metodyka Scrum to popularna metoda zarządzania projektami IT oparta na zasadach Agile Project Management. Scrum umożliwia adaptację produktu do wymagań klienta poprzez iteracyjny proces kontroli. Metoda ta opiera się na trzech filarach: przejrzystości, adaptacji i inspekcji. Zespół Scrum składa się z właściciela produktu, zespołu odpowiedzialnego za rozwój i mistrza Scrum. Proces Scrum składa się z planowania sprintu, sprintu, codziennego scrum, przeglądu sprintu i retrospektywy sprintu.

Historia

Po raz pierwszy ogólne założenia metodyki Scrum opublikowano w 1986 roku, w artykule "The New New Product Development Game", w czasopiśmie Harward Bussines Review, którego autorami byli: Hirotaka Takeuchi i Ikujiro Nonaka. Artykuł opisywał wyniki badań nad sposobami tworzenia nowego produktu przeprowadzonych w firmach: Canon, Honda, Fuit-Xerox, Brother,3M, Epson, HP, Xeror. Firmy te były obserwowane w trakcie wdrażania metody Lean Management oraz teorii złożonych systemów adaptacyjnych, stąd też fundamenty Scrum nawiązują do doświadczeń zebranych w tym czasie[3]

Pierwszy zespół Scrum zarejestrowano w firmie Eeasel Corporation w 1993 roku. Na podstawie tego doświadczenia powstał artykuł: "Agile Development: Lessons Learned from the First Scrum" autorstwa Kena Schwebera, który przedstawił ujednolicony tok zastosowania Scrum, a także przyczynił się do propagowania tej metodyki na skalę światową.

Teoria - Scrum

Scrum opiera się na empirycznej teorii sterowania procesem. Empiryzm zakłada, że wiedza pochodzi z doświadczenia i podejmowania decyzji opartych na tym, co jest już znane. Scrum stosuje podejście iteracyjne (przyrostowe) w celu optymalizacji przewidywalności i kontroli ryzyka. Zdefiniowano trzy filary, które podtrzymują każdą implementację kontroli procesu: przejrzystości (ang. transparency), adaptacji (ang. adaptation) oraz inspekcji (ang. inspection).

  • filar przejrzystości - istotne aspekty procesu muszą być zaprezentowane oraz zrozumiałe dla osób odpowiedzialnych za wyniki, ponadto muszą być określone wspólnym standardem oceny. Dzięki temu cały proces, jego kontrola oraz cel końcowy są "przejrzyste".
  • filar adaptacji - w przypadku zarejestrowania podczas rutynowych kontroli, jakiegokolwiek czynnika, który zaburza proces, filar adaptacji pozwala zespołowi na zmianę podejścia do sposobu pracy z dnia na dzień.
  • filar inspekcji - zakłada, że kontrole postępu prac, powinny być częste na tyle, by wykryć możliwość ulepszenia lub też zapobiec błędom jak najwcześniej. Aczkolwiek nie mogą być na tyle częste, by przeszkadzać w pracy zespołowi. Filar inspekcji zakłada również, że kontrola powinna być przeprowadzana przez wysoko wykwalifikowanego inspektora[2]

Zespół Scrum

Zespoły Scrum są autonomiczne i wielofunkcyjne, jednostki zespołu pracując razem, mają wszystkie kompetencje niezbędne do wykonania danego zakresu pracy. Ma to na celu optymalizację wydajności, elastyczności i kreatywności.J. Werewka, M. Turek, T. Włodarek, Systematyczny opis metodyki Scrum dla zespołów projektowcyh, "Studia Informatica", 2012 nr 1

Zespół składa się z:

  • Właściciela produktu (ang. Product Owner) - Właściciel produktu odpowiada za maksymalizację wartości produktu. Jego zadaniem jest konsultacja z klientem oraz opracowanie wizji produktu. W trakcie procesu tworzenia Właściel odpowiada za kontrolę każdego etapu jego powstawania, tak by spełnić wszystkie oczekiwania postawione przez klienta. Właściciel produktu koordynuje również pracę Zespołu odpowiedzialnego za rozwój oraz ściśle z nim współpracuje.
  • Zespołu odpowiedzialnego za rozwój (ang. Development Team) - Zespół odpowiedzialny za rozwój składa się z profesjonalistów, specjalizujących się w konkretnych dziedzinach, których zakres wiedzy pokrywa wszystkie aspekty tworzenia produktu. Zespół ten upoważniony jest przez pracodawcę do organizacji i zarządzania czasem oraz wyznaczonymi zadaniami, oczywiście pod warunkiem, że dane etapy zostaną ukończone w odpowiednim czasie.
  • Mistrza Scrum (ang. Scrum Master) - Mistrz Scrum odpowiada, za wyjaśnienie w jasny sposób zastosowania metodyki Scrum w konkretnym projekcie. kontroluje proces tworzenia produktu oraz tryb pracy Zespołu odpowiedzialnego za rozwój. Mistrz Scrum odpowiada za to, by wyznaczona metodyka była kontynuowana w trakcie procesu.

Tok postępowania w metodzie Scrum

Został oparty na idei z ang, Time Boxes, czyli oparcia planu pracy na sprecyzowanych przedziałach czasu. Ze względu na powyższe założenia, można wydzielić następujące zdarzenia, które tworzą ramy tej metodyki.

Planowanie Sprintu

Planowanie Sprintu (ang. Sprint Planning) z reguły podzielone jest na dwie części:

  • Określenie rejestru produktowego
  • Określenie rejestru zadaniowego

Jest to etap określany jako opcjonalny, jednak ma on na celu zminimalizowanie wkładu pracy w ustalenie zakresu projektu w późniejszych jego fazach. To etap, w którym Właściciel Produktu (ang. Product Owner) na podstawie wizji klienta określa funkcjonalne i niefunkcjonalne cechy produktu, który ma zostać stworzony w trakcie trwania projektu. Spis ten nie jest jednak sztywny, gdyż może on ulegać modyfikacji, w kolejnych etapach tworzenia. Po określeniu rejestru produktowego, definiowany jest rejestr zadaniowy. Na tym etapie Właściciel Produktu określa priorytety prac, a Zespół odpowiedzialny za rozwój zadaje pytania, które pomogą w organizacji pracy.

Sprint

Sprint to etap, w którym według uprzednio jasno określonych zadań, następuje ich realizacja. Podczas trwania Sprintu, żadne z ustaleń nie podlega zmianie. Praca zespołu opiera się na wzajemnym wsparciu, przekazywaniu sobie informacji oraz doradzaniu. Zespół bowiem sam odpowiada za to, jak będzie wyglądał ich dzienny rytm pracy, a Właścicielowi Produktu oraz Mistrzowi Scrum przedstawi efekty pracy i uwagi odnośnie zrealizowanego zakresu zadań. Czas trwania Sprintu jest ustalony jednoznacznie w fazie planowania, na dzień dzisiejszy okres trwania Sprintu przyjmuje się na ok. 30 dni, z możliwością modyfikacji.

Codzienny Scrum

Codzienny Scrum (ang. Daily Scrum) jest to krótkie spotkanie, które odbywa się każdego dnia Sprintu, na którym Mistrz Scrum zadaje 3 pytania, na które Zespół odpowiedzialny za rozwój odpowiada:

  • Co zrobiłeś dla realizacji celu Sprintu?
  • Co zrobisz dla realizacji celu Sprintu?
  • Jakie napotkałeś przeszkody w celu osiągnięcia celu?

Spotkanie ma ściśle określoną agendę, by mogło odbyć się w jak najkrótszym czasie i z pożądaną efektywnością.

Przegląd Sprintu

Przegląd Sprintu (ang. Sprint Review) to spotkanie po każdym Sprincie, które ma na celu omówienie funkcjonalności oraz cech produktu, a także przebiegu prac tylko i wyłącznie dla fragmentu stworzonego produktu.

Retrospektywa Sprintu

Retrospektywa Sprintu (ang. Sprint Retrospective) jest to etap refleksji po każdym Sprincie. Wszyscy członkowie zespołu Scrum spotykają się umawiają dominujące kwestie zarówno dotyczące produktu, jak i organizacji pracy. Po tym spotkaniu definiowane są wnioski, jak dane aspekty projektu można ulepszyć oraz plan wprowadzenia ulepszeń. [4]


Metodyka SCRUMartykuły polecane
Testowanie w projekcieCykl DemingaProcesy planowania wg PMBOKOgólna charakterystyka metodyki Prince 2Sprint reviewWdrażanie systemu zarządzania projektamiMetodyka MSFDMAICSix sigma

Przypisy

  1. M. Ćwiklicki, Scrum - nowa metoda zarządzania złożonymi projektam, "Przegląd Organizacji", 2010 nr 4
  2. 2,0 2,1 K. Schwaber, J. Sutherland, (2013),"The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"
  3. J. Sutherland, (2004),"Agile Development: Lessons Learned from the First Scrum"
  4. K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A.

Bibliografia


Autor: Marta Nawrot