Scrum

Z Wikipedii, wolnej encyklopedii

Scrum – iteracyjne i przyrostowe ramy zarządzania procesem produkcyjnym (ang. framework) zgodne ze Scrum Guide[1]. Może mieć zastosowanie w realizacji procesów produkcyjnych w oparciu o metodyki zwinne zgodne z manifestem Agile.

Rozwój produktu, a więc proces produkcyjny podzielony jest na trwające maksymalnie jeden miesiąc iteracje, zwane sprintami czyli cyklami produkcyjnymi. Po każdym sprincie zespół powinien być w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany w procesie tworzenia i rozwoju oprogramowania - Agile Software Development. Nie jest on jednak ograniczony tylko do tej dziedziny.

Historia[edytuj | edytuj kod]

Hirotaka Takeuchi i Ikujiro Nonaka wprowadzili termin Scrum w kontekście rozwoju produktu w artykule Harvard Business Review z 1986 r. pt. „Nowa gra rozwoju nowych produktów” (ang. „The New New Product Development Game”)[2]. Takeuchi i Nonaka uzasadniali później w The Knowledge Creating Company[3], że jest to forma „tworzenia wiedzy organizacyjnej, [...] szczególnie dobra we wprowadzaniu innowacji w sposób ciągły, przyrostowy i spiralny” (ang. „organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally”).

Autorzy opisali nowe podejście do rozwoju produktu komercyjnego, którego celem jest zwiększenie szybkości i elastyczności. Koncepcja powstała w oparciu o studia przypadków z firm produkujących samochody, kserokopiarki i drukarki[2]. Autorzy nazywali to podejściem holistycznym lub rugby, ponieważ cały proces jest wykonywany przez jeden wielofunkcyjny zespół w wielu nakładających się fazach, podczas których zespół „próbuje pokonać dystans jako jednostka, podając piłkę tam i z powrotem” (ang. „tries to go the distance as a unit, passing the ball back and forth”)[2] (W rugby scrum jest metodą wznowienia gry i polega to na tym, że gracze pakują się ściśle razem z opuszczonymi głowami, a następnie próbują zdobyć piłkę[4].)

Na początku lat 90. Ken Schwaber wykorzystywał to, co w przyszłości stało się Scrumem w swojej firmie Advanced Development Methods. W tym samym czasie Jeff Sutherland, John Scumniotales i Jeff McKenna opracowali podobne podejście w Easel Corporation, odnosząc się do niego za pomocą pojedynczego słowa Scrum.

W 1995 roku Sutherland i Schwaber wspólnie przedstawili artykuł opisujący ramy postępowania zgodnego z metodyką Scrum (ang. the scrum framework). Miało to miejsce podczas warsztatów projektowania i wdrażania obiektów biznesowych (ang. Business Object Design and Implementation Workshop) odbywających się w ramach OOPSLA '95 (Object-Oriented Programming, Systems, Languages & Applications '95) w Austin w Teksasie[5]. W ciągu następnych lat Schwaber i Sutherland współpracowali, aby połączyć ten materiał zarówno ze swoim doświadczeniem, jak i z rozwijającymi się dobrymi praktykami – w celu opracowania tego, co stało się znane jako Scrum[6].

W 2001 roku Schwaber współpracował z Mikiem Beedlem, w celu opisania metodyki Scrum w książce pt. „Agile Software Development with Scrum”[7]. Podejście Scrum do planowania i zarządzania rozwojem produktów polega na wprowadzeniu uprawnień decyzyjnych na poziom operacyjny[8].

W 2002 roku Schwaber wraz z innymi założył Scrum Alliance[9] i ustanowił serię akredytacji „Certified Scrum”. Schwaber opuścił Scrum Alliance pod koniec 2009 roku i założył Scrum.org, która nadzoruje równoległą serię akredytacji „Professional Scrum”[10].

Od 2009 roku metodyka Scrum jest oficjalnie zdefiniowana w publicznym dokumencie o nazwie „The Scrum Guide”[1]. Dokument ten był aktualizowany 5 razy. Obecnie najnowsza wersja pochodzi z listopada 2020 roku.

W 2018 roku Schwaber i społeczność Scrum.org wraz z liderami społeczności Kanban opublikowali przewodnik Kanban dla zespołów Scrum.

Opis ogólny[edytuj | edytuj kod]

Zespół pracuje w określonych przedziałach czasowych zwanych przebiegami lub sprintami (ang. sprint). Zmiany wprowadzane w każdym przebiegu powinny wnosić zauważalną dla użytkowników nową wartość funkcjonalną. Przebieg nie może trwać dłużej niż jeden miesiąc. W praktyce sprinty trwają od 1 do 4 tygodni. Zaleca się stosowanie przebiegów o stałych długościach.

Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci historyjek (ang. User Stories). Każda historyjka opisuje jedną cechę systemu. Właściciel produktu (ang. Product Owner) jest też zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego przebiegu. Po tym formułowany jest rejestr wymagań (ang. Product Backlog). Cel przebiegu jest zapisywany w widocznym miejscu w pokoju członków zespołu.

Następnie podczas planowania przebiegu (ang. Sprint Planning) wybierane są zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu przebiegu. Szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (ang. Sprint Backlog).

Po planowaniu zespół przechodzi do realizacji przebiegu. W jego trakcie Właściciel Produktu powinien cały czas pracować z zespołem nad jak najlepszym zrozumieniem wymagań, nie ingerując jednocześnie w sposób ich implementacji. Nie powinno się także zmieniać zakresu Sprintu.

Zespół z założenia jest ciałem samoorganizującym się, nie ma mowy o odgórnym przypisywaniu zadań poszczególnym członkom zespołu. Dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji.

Naczelną zasadą metody jest przeprowadzanie codziennych (maksymalnie 15-minutowych) spotkań (ang. Daily Scrum), na których omawiane są zadania zrealizowane poprzedniego dnia, problemy występujące przy ich realizacji oraz zadania do wykonania w dniu spotkania.

Każdy Sprint kończy się spotkaniem (ang. Sprint Review), na którym prezentowany jest produkt wykonany podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani projektem. Na spotkaniu każdy członek zespołu może zabrać głos i wyrazić opinię o produkcie. Na zakończenie ustalany jest termin spotkania planistycznego do następnego przebiegu.

Realizacja projektu według Scrum skupia się na:

  • dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu,
  • włączaniu się przyszłych użytkowników w proces wytwórczy,
  • samoorganizacji zespołu projektowego.

Zespół i odpowiedzialności[edytuj | edytuj kod]

Zazwyczaj zespół Scrum składa się z mniej niż 10 osób. Dobrze, gdy ma charakter interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Główne role w projekcie grają: Scrum Master, Właściciel Produktu (ang. Product Owner) i Deweloperzy (ang. Developers)[1].

Odpowiedzialności główne[edytuj | edytuj kod]

  • Deweloperzy (ang. Developers) – grupa osób, składająca się od trzech do dziewięciu osób, odpowiedzialna za dostarczenie produktu
  • Właściciel produktu (ang. Product Owner) – osoba reprezentująca klienta. Właściciel produktu może być członkiem zespołu, jednak nie jest zalecane, aby jednocześnie był Scrum Masterem.
  • Scrum Master – osoba odpowiedzialna za usuwanie wszelkich przeszkód uniemożliwiających zespołowi wykonanie zadania oraz za poprawną implementację procesu i metod.

Zobacz też[edytuj | edytuj kod]

Przypisy[edytuj | edytuj kod]

  1. ↑ a b c https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf.
  2. ↑ a b c The new new product development game, „Journal of Product Innovation Management”, 3 (3), 1986, s. 205–206, DOI: 10.1016/0737-6782(86)90053-6 [dostęp 2019-06-09].
  3. ↑ Laurence Prusak, Thomas H. Davenport, Knowledge after the Knowledge Creating Company, Palgrave Macmillan, DOI: 10.1057/9781137024961.0022, ISBN 978-1-137-02496-1 [dostęp 2019-06-09].
  4. ↑ Scrum, abbreviated form of scrummage, Oxford English Dictionary Online.
  5. ↑ Jeffrey Victor. Sutherland, Business object design and implementation: OOPSLA '95 workshop proceedings,16 October 1995, Austin, Texas, London: Springer, 1997, ISBN 3-540-76096-2, OCLC 35694527 [dostęp 2019-06-09].
  6. ↑ Dubinsky i inni, Agile 2009 Conference. Proceedings: 24-28 August, 2009, Chicago, Illinois, Los Alamitos, Calif.: IEEE.Computer Society, 2009, ISBN 978-1-4244-4745-9, OCLC 505549446 [dostęp 2019-06-09].
  7. ↑ Mike. Beedle, Agile software development with Scrum, Upper Saddle River, NJ: Prentice Hall, 2002, ISBN 0-13-067634-9, OCLC 48241360 [dostęp 2019-06-09].
  8. ↑ Ken. Schwaber, Agile project management with Scrum, Redmond, Wash.: Microsoft Press, 2004, ISBN 0-7356-1993-X, OCLC 53099100 [dostęp 2019-06-09].
  9. ↑ Dominik Maximini, The scrum culture. Introducing agile methods in organizations, Cham, ISBN 978-3-319-11827-7, OCLC 900158036 [dostęp 2019-06-09].
  10. ↑ leanagile.in [online], blog.leanagile.in [dostęp 2019-06-09].

Linki zewnętrzne[edytuj | edytuj kod]

Źródło: „https://pl.wikipedia.org/w/index.php?title=Scrum&oldid=71552314”