Artykuł “Scrum, czyli zwinny sposób wytwarzania” oryginalnie został opublikowany na łamach listopadowego magazynu TIMM. Sprawdź wydanie online >>
Słowo “scrum” wielu może kojarzyć się z futbolem amerykańskim i słusznie! W przypadku kontekstu zarządzania procesami, to jak mogliście przeczytać już w samym tytule artykułu, Scrum jest jednym ze zwinnych (ang. agile) podejść do pracy. Ten schemat wykorzystuje się głównie przy wytwarzaniu oprogramowania, ale nie tylko. Jego rosnąca popularność w sektorze edukacji sugeruje, że można z sukcesem przenieść ten styl działania na inne dziedziny niż IT. Scrum nie jest metodologią, metodą czy procesem, definiuje jedynie pewne ramy (ang. framework) postępowania, w obrębie których można stosować różne procesy czy techniki. Opiera się na trzech filarach: inspekcji, adaptacji i transparentności, a jego istotą jest niewielki zespół i empiryczne podejście do pracy.
Teoria Scruma w pigułce
Całość świata agile osadzona jest w teorii empiryzmu, czyli bazuje na zdobywaniu wiedzy z doświadczenia. W tym wypadku wynika ono z iteracyjnego podejścia do wytwarzania przyrostu. Wg. Przewodnika po Scrumie, transparentność ma zapewnić dostępność informacji na takim samym poziomie wśród wszystkich odpowiedzialnych za osiągane rezultaty. Sprowadza się to do wspólnego dbania o artefakty Scruma, wartości, a także o przejrzysty przepływ wszystkich istotnych informacji.
O artefaktach i wartościach opowiem poniżej, więc nie martwcie się jeżeli te pojęcia są jeszcze dla Was obce. Wracając do filarów – inspekcja ma wspomagać wyciąganie wniosków z tego co dzieje się w zespole, w organizacji, czy w produkcie. W taki sposób aby maksymalnie wspomagać realizacją celu Sprintu czy przejrzystość artefaktów. Przykładem może być sytuacja, gdy w trakcie trwania iteracji (określonego odcinka czasu nazywanego Sprintem) okazuje się, że jakaś funkcjonalność nie ma sensu. W obliczu takiej informacji nie należy czekać do końca Sprintu lub co gorsza do końca wytwarzania produktu by wspomnieć o tym odkryciu zainteresowanym osobom. Ostatnim z filarów jest adaptacja, której zadaniem jest wprowadzenie usprawnień do spraw, w stosunku których wyciągnęliśmy odpowiednie wnioski i chcemy wprowadzić zmiany. Wracając do funkcjonalności, której sens został zakwestionowany w przykładzie powyżej, możemy w myśl adaptacji do okoliczności, zaproponować inne rozwiązanie.
Wartości i role w Scrumie
W poprzednim akapicie opisałam to, co stanowi elementarny fundament, czas przejść do szczegółów. Jak w każdym miejscu, tak i w Scrumie ludzie pełnią określone role, które pomagają całości funkcjonować sprawnie i szybko. W opisywanym frameworku wyróżniamy trzy role: Scrum Master (SM), Właściciel Produktu (Product Owner – PO) i Zespół Developerski (Development Team – DT). Razem tworzą oni nierozerwalny Zespół Scrumowy (Scrum Team).
Współpracują ze sobą opierając się na wartościach: zaangażowaniu, odwadze, skupieniu, otwartości i poszanowaniu. Te pięć zasad stanowi podstawę współpracy Zespołu Scrumowego i m.in. od ich wykorzystania zależy powodzenie w stosowaniu frameworku. Każdy członek zespołu Scrumowego powinien być zaangażowany w realizację wyznaczonego celu, powinien być skupiony w dążeniu do jego osiągnięcia. Otwarcie powinien mówić o problemach czy nieprawidłowościach jakie zaobserwował i nie bać się powiedzieć, że np. nie wie jak rozwiązać dane zagadnienie. Dzięki pracy zespołowej i wzajemnemu poszanowaniu zarówno do wykonywanej pracy jak i ludzi, budujemy silny zespół, który pracuje w atmosferze zaufania. I choć może brzmieć to pompatycznie i dla części z nas być czymś oczywistym i łatwym, w praktyce nastręcza to najwięcej trudności.
Odpowiedzialności
Czas powiedzieć więcej o samych aktorach. Scrum Master jest osobą, która wspiera stosowania Scruma. Dba o jego poprawne zrozumienie począwszy od reguł poprzez zadania poszczególnych członków i wspólnie wyznawanych wartości. Wspomaga również ciągły proces inspekcji i adaptacji nie tylko w zespole Scrumowym, ale i w całej organizacji. Jego zadania i codziennie wykonywane czynności zależą od tego w jakim obszarze i z jakim zespołem pracuje. Z kolei Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Developerskiego. Jest on jedyną osobą odpowiedzialną za zarządzanie Backlogiem Produktu (Product Backlog). Czyli za klaryfikowanie tego, co tak naprawdę ma być zrealizowane w procesie wytwarzania produktu.
Backlog Produktu jest jednym z artefaktów Scruma i może przybierać różną formę. Scrum jednak nie definiuje jasno jak ma on wyglądać. Wiele zespołów buduje go wykorzystując User Stories, czyli historyjki widziane okiem użytkownika. Taka wizualizacja pozwala lepiej zrozumieć cel budowanych funkcjonalności. Właściciel Produktu jest osobą, która dba o priorytetyzację i zrozumienie zawartości Backlogu Produktu przez wszystkich zaangażowanych.
Wymagania przekute w poszczególne elementu Backlogu Produktu, czyli w Product Backlog Items (PBI) realizowane są przez Zespół Deweloperski. Cechuje go samoorganizacja, samowystarczalność i brak hierarchii czy określania bardzo specyficznych ról. Oznacza to, że nikt nie może powiedzieć zespołowi jak ma przekuć poszczególne PBI w Increment (Przyrost) gotowy do potencjalnego wydania. W swoim składzie zespoły posiadają wszystkie umiejętności potrzebne do zbudowania wspomnianego Przyrostu. Zwykle są to grupy specjalistów i ekspertów w potrzebnych dziedzinach, wśród których nie wyróżnia się nazw ról ze względu na charakter wykonywanej pracy. Przewodnik po Scrumie sugeruje, że Zespół Deweloperski powinien być niewielki. Liczba jego członków powinna mieścić się w przedziale 3-9 osób. Ma to pozwolić na zminimalizowanie wielkości luki komunikacyjnej, braku konieczności zaawansowanej koordynacji pracy i zbilansowanie kompetencji w zespole.
Zdarzenia w Scrumie
Wiedząc już, jakie role pełnią osoby pracujące w Scrumie, możemy poznać jak wyglądają kolejne etapy pracy i spotkania. Zespół Scrumowy pracuje w określonych iteracjach, czyli w tzw. Sprintach. Sprint powinien trwać od 1 do 4 tygodni, jednak nie dłużej, tak by wspierać możliwość dokonywania inspekcji i adaptacji w możliwie krótkich odstępach czasu. W iteracjach odbywają się cykliczne spotkania, mające określone ramy czasowe i schemat przebiegu.
Sprint Planning służy wyznaczeniu elementów jakie zostaną podjęte do pracy w kolejnym odcinku czasu. Podczas tego spotkania ustalamy co jest dla nas najważniejsze określając Cel Sprintu i planujemy w jaki sposób praca zostanie wykonana. Wszystkie wyznaczone zadania wypełniają na koniec planowania Backlog Sprintu, który jest kolejnym po Backlogu Produktu artefaktem Scruma. W budowanie planu zaangażowany jest cały Zespół Scrumowy, zgodnie ze swoimi odpowiedzialnościami.
Po wyznaczeniu planu i rozpoczęciu Sprintu Zespół Developerski spotyka się na Daily Scrum (Codziennym Scrumie), żeby zaplanować swoją współpracę na kolejne 24 godziny. Spotkanie, zgodnie z nazwą, odbywa się codziennie, ze skupieniem na realizację Celu Sprintu i zbudowanie Przyrostu potencjalnie gotowego do wydania.
Na koniec każdej iteracji odbywa się Sprint Review (Przegląd Sprintu) mający na celu dokonanie inspekcji zbudowanego Przyrostu (ostatniego z artefaktów) i dokonania dostosowania Backlogu Produktu. Oznacza to, że jeżeli pojawi się jakiś nowy pomysł na usprawnienie produktu, powinien znaleźć się na liście rzeczy do wykonania. Najlepiej z odpowiednim priorytetem. Na takim spotkaniu oprócz Zespołu Scrumowego powinni pojawić się wszyscy interesariusze. Daje to możliwość wspólnej dyskusji na temat tego co mogłoby zostać wykonane w następnej kolejności tak aby zoptymalizować wartość produktu.
Następnie Zespół Scrumowy dokonuje inspekcji i adaptacji wykonanej pracy w ramach Retrospektywy Sprintu. Wspólnie zastanawiając się jakie obszary ich współpracy wymagają usprawnień i jak można ich dokonać.
I taki cykl powtarzany jest cały czas, aż do zakończenia pracy nad produktem.
Podsumowanie
W skrócie opisałam podstawowe założenia frameworku, pomijając wiele detali, o których więcej możecie poczytać m.in. na blogu agilehunters.com. Powyższe ramy nie są zbyt skomplikowane, to tylko kilka prostych zasad. Jednak jak mówią sami twórcy, Ken Schwaber i Jeff Sutherland:
Scrum jest lekki i łatwy do zrozumienia ale niezmiernie trudny opanowania.
Ideą przyświecającą Scrumowi, jak zresztą innym zwinnym procesom, jest nakierowanie na odbiorcę końcowego i na zmieniające się środowisko. Z pewnością dlatego Scrum jest stosowany tak powszechnie w branży IT, gdzie wytwarzanie produktów jest procesem dynamicznych, a wymagania użytkownika, są coraz większe. Budując np. aplikacje mobilne opieramy się bardzo często na możliwie krótkich Sprintach. Często 1-tygodniowych, a zbudowanie średniej wielkości produktu zajmuje nawet 3 miesiące. Po każdym Sprincie mamy nasz Przyrost potencjalnie gotowy do wydania, który może, a nawet powinien trafić do użytkowników. Dzięki takiemu podejściu możemy szybciej zebrać feedback i szybciej wprowadzić odpowiednie usprawnienia. Scruma stosują tzw giganci na rynku m.in. IBM, Microsoft, czy Giphy ale też wiele małych firm. Rynek IT nie jest jednak dla Scruma wystarczający. Po wielu sukcesach tego podejścia coraz częściej spotykamy się z jego zastosowaniem w różnych innych dziedzinach. O tym innym razem!
Sprawdź czy jesteś gotowy żeby przystąpić do egzaminu PSMI, PSPOI oraz CSM.
Sprawdź nasze ostatnie wpisy:
