Metodyka SCRUM: Różnice pomiędzy wersjami
m (cleanup bibliografii i rotten links) |
m (cleanup bibliografii i rotten links) |
||
Linia 65: | Linia 65: | ||
* Ćwiklicki M., Włodarek T. (2010), ''Metodyka Scrum w Polsce w świetle badań'', Nauka i Gospodarka, nr 3 | * Ćwiklicki M., Włodarek T. (2010), ''Metodyka Scrum w Polsce w świetle badań'', Nauka i Gospodarka, nr 3 | ||
* J. Sutherland, (2004), ''[https://csis.pace.edu/~marchese/CS616/Agile/Scrum/FirstScrum2004.pdf"Agile Development: Lessons Learned from the First Scrum"]'' | * J. Sutherland, (2004), ''[https://csis.pace.edu/~marchese/CS616/Agile/Scrum/FirstScrum2004.pdf"Agile Development: Lessons Learned from the First Scrum"]'' | ||
* K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A | * K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A | ||
* K. Schwaber, J. Sutherland, (2013), ''Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game" '' | * K. Schwaber, J. Sutherland, (2013), ''Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game" '' | ||
* Werewka J., Turek M., Włodarek T. (2012), ''Systematyczny opis metodyki Scrum dla zespołów projektowcyh'', Studia Informatica, nr 1 | |||
</noautolinks> | </noautolinks> | ||
Wersja z 01:05, 22 lis 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 SCRUM — artykuły polecane |
Testowanie w projekcie — Cykl Deminga — Procesy planowania wg PMBOK — Ogólna charakterystyka metodyki Prince 2 — Sprint review — Wdrażanie systemu zarządzania projektami — Metodyka MSF — DMAIC — Six sigma |
Przypisy
- ↑ M. Ćwiklicki, Scrum - nowa metoda zarządzania złożonymi projektam, "Przegląd Organizacji", 2010 nr 4
- ↑ 2,0 2,1 K. Schwaber, J. Sutherland, (2013),"The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"
- ↑ J. Sutherland, (2004),"Agile Development: Lessons Learned from the First Scrum"
- ↑ K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A.
Bibliografia
- B. Wachnik, (2016), 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
- Ćwiklicki M. (2010), Scrum - nowa metoda zarządzania złożonymi projektami, Przegląd Organizacji, nr 4
- Ćwiklicki M., Włodarek T. (2010), Metodyka Scrum w Polsce w świetle badań, Nauka i Gospodarka, nr 3
- J. Sutherland, (2004), "Agile Development: Lessons Learned from the First Scrum"
- K. S. Rubin, (2013), "Scrum Praktyczny przewodnik po najpopularniejszej metodyce Agile", Helion S.A
- K. Schwaber, J. Sutherland, (2013), Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game"
- Werewka J., Turek M., Włodarek T. (2012), Systematyczny opis metodyki Scrum dla zespołów projektowcyh, Studia Informatica, nr 1
Autor: Marta Nawrot