Scrum — czym jest, skąd pomysł i czym nie jest

utworzone przez | Mar 14, 2017 | Blog, Scrumpedia | 0 komentarzy

Czym jest Scrum?

Scrum jako pojęcie jest często używany zamiennie ze słowem Agile i nie do końca jest to błąd. Dlaczego? Dobrze stosowany Scrum może być drogą do osiągnięcia założeń podejścia zwinnego do wytwarzania oprogramowania, czyli Agile. Oznacza to, że jeżeli prawidłowo go stosujesz, to spełniasz cztery podstawowe założenia Agile Manifesto12 zasad Agile. Są inne sposoby na realizację Agile Manifesto, takie jak Extreme Programming (XP), Kanban, DSDM, Crystal czy Lean Startup. Zatem można powiedzieć, że została opracowana cała rodzina metod zwinnych, Agile. Jednak raporty takie jak State of Agile z Version One, czy listy osób, które uzyskały certyfikaty pokazują jednoznacznie, że to właśnie Scrum zdominował świat Agile.

Zasadniczo zgodnie z wolą twórców Scrum, nie powinniśmy określać go jako metoda. Lepszym określenim będzie, struktura lub szkielet (ang. framework) w ramach, w ramach którego możemy wytwarzać wartościowe produkty poprzez zarządzanie procesami. Scrum nie narzuca konkretnych praktyk lub technik rozwoju oprogramowania tak jak robi to na przykład bliźniaczo podobne podejście, Extreme Programming (XP).  W kolejnych wersjach framework został odchudzony tak, żeby narzucać jak najmniej i pasować do różnych kontekstów użycia. Nie znajdziesz tutaj opisu konkretnego sposobu postępowania, żeby osiągnąć zbudować dobry produkt. Dlatego nie można powiedzieć, że jest to metoda, a tym bardziej metodyka czy metodologia.

Oprócz stworzenia wyraźnych ram, framework oferuje bardzo jasne pokazanie efektywności Twoich praktyk rozwijania oprogramowania. Możesz o tym myśleć, jak o lustrze, w którym codziennie przeglądasz efekty działań. Co możesz zrobić, jeśli nie podoba Ci się to, co widzisz? Możesz zmienić sposób postępowania i przejrzeć się ponownie. A teraz, jak jest? Czy korzystanie ze Scrum jest łatwe? Wręcz przeciwnie. Scrum jest lekkim prosty do zrozumienia, ale trudny do opanowania.

Framework Scrum został zbudowany z minimalnego zestawu ról, wydarzeń i artefaktów. Zależności między tymi elementami określają proste zasady. Od 2009 roku autorzy opisują kolejne wersje w Przewodniku po Scrum (ang. Scrum Guide). Ten dokument zawiera pełny opis, zatem to, rzeczy tam opisane stanowią nierozerwane elementy i niezbędne minimum. Wszystko ponadto jest dodatkiem, lepszą lub gorszą praktyką. W czasie pisania tego artykułu najnowszą wersją Scrum Guide jest July 2016. Zmiany w prowadzone w tej wersji możesz przejrzeć w poście Zmiany w Scrum Guide 2016, czyli wartości Scrum.

Framework Scrum w pigułce

© Scrum.org

Role w Scrum

  • Product Owner odpowiada za podejmowanie decyzji co do rozwoju produktu i wykorzystaniu czasu Development Team tak, żeby zbudować jak największą wartość.
  • Development Team odpowiada za zaplanowanie, organizację i wykonanie pracy.
  • Scrum Master odpowiada za wprowadzenie Scrum w życie,  zrozumienie i przestrzeganie zasad frameworka. Wspiera zespół poprzez facylitację i usuwanie przeszkód (ang. impediments).

Wydarzenia w Scrum

  • Sprint — iteracja nie dłuższa niż jeden miesiąc, w ramach której zwarte są pozostałe wydarzenia;
  • Sprint Planning — na początku każdego Sprintu patrzymy co jest najbardziej wartościową rzeczą do zrobienia przez Development Team i prognozujemy jak będzie wyglądała praca w tej iteracji;
  • Daily Scrum — codziennie Development Team spotyka się, żeby sprawdzić stan pracy i wspólnie zdecydować co należy dalej zrobić;
  • Sprint Review — pod koniec Sprintu sprawdzamy jak wygląda przyrost produktu i zbieramy feedback, żeby interesariusze mieli jasny obraz faktycznego postępu i dostosować wymagania do ich oczekiwań;
  • Sprint Retrospective — na koniec Sprintu zatrzymujemy się na chwilę, przyglądamy się procesowi, narzędziom, interakcjom, żeby zdecydować jak usprawnić proces;

Artefakty w Scrum

  • Product Backlog — lista rzeczy do zrobienia dla produktu, jedyne miejsce, z którego Development Team bierze pracę. Product Backlog powinien być zawsze aktualny, żeby jasno pokazywać ile jeszcze jest rzeczy do zrobienia dla produktu;
  • Sprint Backlog — lista rzeczy do zrobienia w tym Sprincie. Sprint Backlog powinien być zawsze aktualny, żeby jasno pokazywać jaki jest postęp pracy.
  • Product Increment — ukończony, przetestowany i zintegrowany przyrost funkcjonalności i właściwości produktu, który pokazuje co jest faktycznie zrobione i jak to wygląda.

Cały framework Scrum i szczegóły możesz przejrzeć w wizualizacji Scrum Guide 2016 jako mapa myśli.

Skąd pomysł na Scrum?

Scrum powstał przed stworzeniem pojęcia Agile Software Development. We wczesnych latach dziewięćdziesiątych Jeff Sutherland szukał sposobu na lepsze zarządzanie wytwarzaniem innowacyjnych produktów. Jeff Sutherland w tym czasie pracował w firmie Easel Corporation. Zamiast wymyślać modele teoretyczne, Jeff Sutherland zaczął szukać źródeł inspiracji tam, gdzie pojawiał się sukces.

Kamieniem węgielnym pod budowę frameworka Scrum stał się artykuł The New New Product Development Game opublikowany w Harvard Business Review, w którym Hirotaka Takeuchi i Ikujiro Nonaka opisywali podejście do wytwarzania innowacyjnych produktów w takich firmach jak Xerox, Canon , Honda, NEC. Głównym przesłaniem, które autorzy artykułu przekazują mówi, że trzeba zmienić podejście z biegu sztafetowego na rugby. Jak to odnieść do wytwarzania produktów? Zespoły muszą składać się ze specjalistów różnych dziedzin, fazy rozwoju powinny się nakładać, a nawet zachodzić równocześnie oraz zespół musi wspólnie reagować na to co się dzieje. Kolejne założenia i praktyki Jeff Sutherland zaczerpnął z projektu Pasteur w ATT Bell Labs z praktyk wypracowanych przez Toyota (tak zwany Toyota Production System), które są implementacją Lean Management.

Wizja w oczach Jeffa nie pozostawiała żadnych złudzeń:

Celem Scrum jest osiągnąć “efekt Toyoty”, dostarczając czterokrotnie więcej oprogramowania, dwunastokrotnie lepszej jakości, w szeregu krótkich ram czasowych nazwanych “Sprintami”, które trwają 30 dni lub krócej.

Jeff Sutherland przekonał swojego szefa i zaczął eksperymentować. Nowy sposób pracy udoskonalany w ciągłej pętli zwrotnej okazał się strzałem w dziesiątkę. Zupełnym przypadkiem (podobno w życiu nie ma przypadków) Ken Schawber zaprezentował Scrum szerszej publiczności w 1995 roku na konferencji OOPSLA. I tak rozpoczęła się rewolucja w świecie opanowanym do tej pory przez waterfall. Kolejne zakładane przez Kena Schwabera organizacje, Agile Alliance, Scrum Alliance i w reszcie scrum.org, zaczęły oferować szkolenia i certyfikaty takie jak Certified Scrum Master i Professional Scrum Master. Do tej pory sam Scrum.org od 2009 roku certyfikował ponad 180.000 osób.

Nazwa pochodzi od elementu gry w Rugby, kiedy zespół zbiera się razem, żeby zrestartować rozgrywkę. W ten sposób Jeff oddał hołd Takeuchi i Nonaka.

Podstawowe mechanizmy Scrum

Wszystkie elementy frameworku zostały wprowadzone wraz z kolejnymi wersjami w pewnym konkretnym celu. Wydarzenia są pętlami zwrotnymi sprawdź i dostosuj. Artefakty służą przejrzystości postępu prac. Role zapewniają pokrycie niezbędnych odpowiedzialności. Nie znajdziesz tutaj zbędnych elementów. Jednak najbardziej istotne jest to, że całość została oparta na podstawowych mechanizmach:

  • Empiryzm — jedynym sposobem na okiełznanie rozwiązywania złożonych problemów jest sprawdzanie skuteczności podjętych działań. Robimy coś i sprawdzamy jakie są efekty. Sprawdź i dostosuj.
  • Self-organizing — czyli samo-organizujące się zespoły. Powierzasz pracę w ręce profesjonalistów, którzy posiadają potrzebne umiejętności. Żeby najlepiej skorzystać z ich wiedzy i umożliwić kreatywność, pozwól im na samodzielną organizację pracy. Product Owner mówi co po ma być zrobione, a Zespól Developerski wymyśli jak to zrobić.
  • Retrospekcja — lub jak niektórzy wolą Retrospektywa. Scrum zapewnia jedynie framework. Sam musisz dojść do tego jakie procesy i praktyki działają dla Ciebie najlepiej. Jak do tego dojść? Co Sprint musisz się zatrzymać na chwilę i sprawdzić efektywność tego co robisz. Znajdź co można poprawić i zmień to w kolejnym Sprincie.
  • Ukończony Przyrost Produktu — żeby działała pętla sprawdź i dostosuj musimy wiedzieć jak jest (transparentność) i mieć co sprawdzać. Najlepszym mierzalnym odzwierciedleniem postępu jest działające oprogramowanie. Dlatego przynajmniej na koniec Sprintu potrzebujemy ukończony (ang. done) przyrost produktu. Przyrost produktu stanowią nowe funkcjonalności wykonanie w Sprincie zintegrowane z poprzednią wersją produktu.

Czym Scrum nie jest?

W brew krążącym opiniom nie jest metodą zarządzania projektami. Przez projekt można tutaj rozumieć jedynie pojedynczy Sprint. Sprint nie może się nie udać, bo zawsze pokazuje jak jest.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Scrum nie jest także nowym narzędziem do poganiania ludzi, żeby pracowali szybciej i dostarczali więcej w tym samym czasie. Wprawdzie Jeff Sutherland obiecuje wzrost produktywności, ale to wymaga zmian w procesach i usunięcia przeszkód. Samo wprowadzenie frameworka nie przyniesie takiego efektu.

Framework nie jest sposobem na dowożenie wymagań na czas, ani techniką nieomylnego oszacowania pracy. Skupiamy się na dostarczaniu wartości biznesowej i działającego, użytecznego produktu. Nie oznacza to zaimplementowania wszystkich wymagań w niezmienionej formie.

Scrum nie jest przepisem na sukces, ani srebrną kulą rozwiązującą wszystkie problemy. Framework sprawi, ze wszystkie problemy będą bardziej widoczne. Ale to organizacja musi je rozwiązać.

Framework nie jest kolejnym cyklem życia oprogramowania dotyczącym tylko działu IT i inżynierii oprogramowania. Ludzie z IT i z biznesu musza pracować codziennie razem, żeby odnieść sukces. Wprowadzenie i korzystanie z tego frameworka często wymaga zmian w HR, budżetowaniu, zarządzaniu projektami, współpracy z klientem itd. Ludzie wykorzystują ten framework z powodzeniem poza IT, na przykład w wojsku, szkołach, a nawet w rolnictwie.

Jeżeli interesuje Cię więcej mitów na temat Scrum, możesz zajrzeć do prezentacji Krystiana Kaczora

Po co Scrum? Jakie korzyści daje Scrum?

  • jest drogą do zwinności organizacji (Agile);
  • pozwala na innowacje;
  • pozwala zwiększyć szybkość i jakość powstawania produktów takich jak oprogramowanie;
  • dostarcza większą wartość biznesową przy tych samych nakładach.

Jak powinien wyglądać idealnie zaimplementowany Scrum dowiesz się z artykułu Idealny Świat Scrum.

Jeśli chcesz wiedzieć więcej, przeczytaj Scrum Guide, i sięgnij po książkę Scrum i nie tylko. Teoria i praktyka metod Agile.
Lista  literatury zalecanej dla Scrum Mastera
Lista  literatury zalecanej dla Product Ownera.
Lista  literatury zalecanej dla Developera

keep calm and scrum on

Certyfikowane Szkolenia Scrum

DataWydarzenieMiasto
19-Gru-2017Professional Scrum Master — PSMWarszawa
Share This