- Czy nadgodziny dowiozą na czas? — 01/10/2020
- Przewodnik po EBM po polsku — 21/07/2020
- Kolejny raport o Agile. I co z tego? — 02/06/2020
Czym jest Scrum?
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 Manifesto i 12 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śleniem będzie struktura lub szkielet (ang. framework), 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 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 lekki, 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 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 ta z listopada 2020 roku.
© Scrum.org
Role i odpowiedzialności w Scrum
- Product Owner odpowiada za podejmowanie decyzji co do rozwoju produktu i wykorzystaniu czasu Developerów tak, żeby zbudować jak największą wartość.
- Developerzy odpowiadają za zaplanowanie, organizację i wykonanie pracy.
- Scrum Master odpowiada za wprowadzenie Scrum w życie, zrozumienie i przestrzeganie zasad frameworku. Wspiera zespół poprzez facylitację i usuwanie przeszkód (ang. impediments).
W najnowszej wersji przewodnika po Scrumie termin “rola” został zamieniony na “odpowiedzialność”, żeby podkreślić, że nie chodzi o stanowisko, które się piastuje w firmie, a o wzięcie odpowiedzialności za konkretne aspekty pracy w Scrumie. W nowym Scrum Guide podkreślona została odpowiedzialność całego Zespołu Scrumowego za dostarczenie działającego Przyrostu produktu. Na poszczególnych osobach w Zespole spoczywa część tej odpowiedzialności i dlatego nacisk na termin “accountability” (ang. odpowiedzialność).
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 i prognozujemy jak będzie wyglądała praca w tej iteracji;
- Daily Scrum — codziennie Developerzy spotykają 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 Developerzy biorą 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.
Aktualizacja Scrum Guide z 2020 roku wprowadziła tzw. zobowiązania dla każdego z artefaktów Scruma. Zobowiązania w czytelny sposób opisują kluczowe aspekty każdego artefaktu, poprawiają jego przejrzystość i wspierają empiryzm.
- Cel Produktu — Zobowiązanie dla Product Backlog. Cel Produktu buduje kontekst dla całego Backlogu Produktu. Odpowiada na pytanie “czemu” tworzymy i rozwijamy dany produkt. Jak przystało na cel, element ten określa w jasny sposób, do czego dąży Zespół Scrumowy oraz po czym pozna, że to osiągnął.
- Cel Sprintu — Zobowiązanie dla Sprint Backlogu. Cel Sprintu zapewnia spójność (jest jeden), wzmacnia skupienie i zachęca do współpracy Developerów. Jest zobowiązaniem Developerów, ale pozwala na elastyczność w kwestii realizacji elementów ze Sprint Backlogu (nie wszystkie z nich muszą zostać ukończone, żeby udało się osiągnąć Cel Sprintu).
- Definition of Done — Zobowiązanie dla Product Incrementu. Przyrost powstaje w momencie, w którym element Backlogu Produktu zostaje Ukończony. Żeby wszystkie zaangażowane strony wiedziały, kiedy taka sytuacja ma miejsce, kluczowe jest stworzenie oraz przestrzeganie Definicji Ukończenia.
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. 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.
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 Schwaber 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 wreszcie 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ł prawie pół miliona 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 Takeuchiemu i Nonace.
Czym jest Scrum — Podstawowe mechanizmy
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.
- Samozarządzanie — czyli samozarządzają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ę swojej pracy w ramach wyznaczonych przez organizację i framework reguł. Product Owner mówi, co ma być zrobione, a Developerzy wymyślają, jak to zrobić.
- Retrospekcja — lub jak niektórzy wolą Retrospektywa. Scrum zapewnia jedynie ramy postępowania. 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 jest Scrum w 15 minut
Czym Scrum nie jest?
Wbrew 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ą likwidującą wszystkie problemy. Framework sprawi, że 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 muszą 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.
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
Trackbacks/Pingbacks