Scrum – prawdopodobnie jedno z najbardziej chwytliwych haseł w IT w ostatnich kilku latach. Obecnie jest to najpopularniejszy framework w nurcie zwinnym wytwarzania oprogramowania. Na czym dokładnie polega Scrum i jak wygląda przeciętny dzień pracy zespołu deweloperskiego?
Scrum to sposób organizacji pracy w projekcie, ramy postępowania (ang. framework). Nazwa została zainspirowana futbolem amerykańskim, w którym scrum to jeden z elementów gry, w tłumaczeniu na polski – młyn. Zasady Scruma jako frameworka do organizacji pracy zostały opisane w dokumencie o nazwie Scrum Guide autorstwa Kena Schwabera i Jeffa Sutherlanda (przewodnik dostępny jest za darmo w internecie, również polskie tłumaczenie). Przewodnik ów opisuje zadania zespołu i role występujące w nim, określa typy i tryb spotkań potrzebnych do efektywnego działania, wyznacza ramy czasowe pewnych wydarzeń. Przedstawia wartości Scruma, którymi są: Zaangażowanie, Skupienie, Otwartość, Szacunek, Odwaga. Opisuje również tzw. filary empiryzmu w Scrumie: przejrzystość, inspekcję i adaptację. Proces tworzenia produktu powinien być jasny i transparentny zarówno dla tworzących go osób, jak i dla odbiorców produktu. Powinno się poddawać pracę regularnej inspekcji, która umożliwia wykrywanie problemów i adaptację. Opisane dalej w artykule wydarzenia to narzędzia umożliwiające inspekcję. Adaptacja polega na ciągłym korygowaniu i ulepszaniu procesu.
Czego nie zawiera Scrum Guide?
Nie dyktuje szczegółowych wytycznych – zgodnie z duchem Agile stawia na zwinność i dostosowywanie się do konkretnych sytuacji.
Czym jest zespół deweloperski i jakie role zawiera?
Jednym z podstawowych konceptów Scruma jest praca w niewielkich, maksymalnie około dziesięcioosobowych zespołach, tak zwanych zespołach deweloperskich. Według zasad Scruma w takim zespole powinna występować jedna osoba o roli Scrum Mastera, jeden Product Owner oraz tak zwani deweloperzy, czyli po prostu wszyscy inni członkowie zespołu, których rola nie jest z góry narzucona. Mogą to być programiści, testerzy, analitycy biznesowi, projektanci… Zespół deweloperski powinien posiadać wszystkie kompetencje potrzebne do osiągnięcia założonych celów, czyli – w przypadku projektów informatycznych – zbudowania oprogramowania.
Scrum Master
Scrum Master to osoba odpowiedzialna za zrozumienie i prawidłowe przestrzeganie zasad Scruma w zespole. Jest to także osoba, która dogląda organizacji spotkań, często prowadzi je i moderuje, pilnuje, żeby odbywały się one regularnie, przebiegały sprawnie i w odpowiednich ramach czasowych. Scrum Master pomaga zespołowi w usuwaniu przeszkód utrudniających ich codzienną pracę i osiągnięcie celu.
Product Owner
Product Owner to osoba odpowiedzialna za tak zwany backlog produktu. Backlog to lista zadań potrzebnych do osiągnięcia celu zespołu, czyli do wytworzenia produktu w postaci działającego oprogramowania. Wymagania biznesowe oraz techniczne – czyli to jak dokładnie ma wyglądać i działać oprogramowanie – są opisane i usystematyzowane w postaci takiego właśnie zbioru zadań. Na początku każdego sprintu zespół wspólnie decyduje, ile elementów z backlogu jest w stanie wykonać przez dany sprint i które to będą elementy – w ten sposób powstaje backlog sprintu..
Definition of Done
To koncept, o którym nie można zapomnieć mówiąc o Scrumie. Definition of Done to uzgodnione przez zespół warunki, które muszą być spełnione by można było stwierdzić, że dane zadanie lub cała iteracja jest ukończona. Przykładowo definicja ukończenia może w sobie zawierać fakt pomyślnego przejścia wszystkich testów jednostkowych oraz fakt zlikwidowania wszystkich poważniejszych niż kosmetyczne defektów w danej funkcji systemu.
Jakie wyróżniamy rodzaje wydarzeń scrumowych?
Sprint
Istotą Scruma jest dostarczanie produktu w postaci iteracji – niewielkich części budowanego systemu, które docelowo utworzą całość. Iteracje dostarczane są w ramach tak zwanych sprintów – zamkniętych w ramy okresów trwających maksymalnie miesiąc (zwykle jedna iteracja jest dostarczana podczas jednego sprintu, choć zasady Scruma dopuszczają dostarczenie kilku iteracji w jednym sprincie). Sprint ma określony cel. Tuż po zakończeniu jednego sprintu rozpoczyna się kolejny. Na początku i końcu każdego sprintu występują odpowiednie wydarzenia, a w trakcie jego trwania zespół pracuje nad konkretnymi zadaniami wybranymi z backlogu, które w momencie wyboru trafiają z ogólnego backlogu do backlogu sprintu.
Daily Scrum
Inaczej stand up. To spotkanie które odbywa się codziennie, zwykle rano, i które ma czas trwania ograniczony do kwadransa. Podczas daily członkowie zespołu deweloperskiego informują o swoich postępach w pracy oraz o ewentualnych blokadach i rzeczach, które uniemożliwiają im osiągnięcie swoich celów.
Sprint Review
Sprint review to spotkanie odbywające się na koniec sprintu, podsumowujące cele zrealizowane w danym sprincie. Od retrospektywy różni się tym, że jest to spotkanie dla tak zwanych interesariuszy: dla biznesu, niekiedy dla użytkowników końcowych oprogramowania. Odbiorcami są osoby spoza zespołu deweloperskiego, a spotkanie służy pokazaniu postępów w pracy i ciągłej komunikacji pomiędzy zespołem wytwarzającym oprogramowaniem a jego odbiorcami.
Sprint Retrospective (Retrospektywa sprintu)
Retrospektywa to spotkanie odbywające się pod koniec sprintu, podczas którego zespół deweloperski dyskutuje o tym co poszło dobrze, a które aspekty pracy nie do końca się sprawdziły i można by je ulepszyć. Spotkanie ma na celu adaptację i ulepszanie pracy w ramach zasad inspekcji i adaptacji.
Sprint Planning
Na początku każdego sprintu organizuje się spotkanie, którego celem jest zaplanowanie sprintu i wybranie odpowiednich zadań z backlogu.
Jak wygląda przykładowy dzień pracy w Scrumie?
Dzień pracy w Scrumie zaczyna się zwykle od daily, na którym opowiada się o tym co robiło się poprzedniego dnia i jakie są plany na bieżący dzień. Podczas daily często omawia się bieżące zadania i potrzeby, na przykład programiści informują testerów o zakończeniu pracy nad danym fragmentem kodu i o gotowości do testowania. W ciągu dnia jest też czas na pracę własną, na pisanie kodu, wykonywanie testów, projektowanie lub opracowywanie wymagań biznesowych. Cyklicznie odbywają się również inne spotkania scrumowe – dość regularnie refinementy (spotkania mające na celu omówienie zadań, które mają trafić do backlogu, upewnienie się, że wymagania są jasne dla zespołu i oszacowanie ilości pracy potrzebnej do wykonania danego zadania, by można było następnie zaplanować kolejne sprinty), a jeśli jest to początek lub koniec sprintu to także planning, retrospektywa i review. W razie natrafienia na trudności w trakcie dnia pracy członkowie zespołu są zwykle w ciągłym kontakcie ze sobą i organizowane są także spotkania ad hoc w razie potrzeby. Zwykle zespół na bieżąco komunikuje się w sprawie postępów w pracy nad zadaniami, na przykład programiści dyskutują na bieżąco, który z nich weźmie z backlogu sprintu konkretne zadania do zakodowania.
Scrum idealny?
Jak wspomniano na początku, Scrum nie jest silnie sformalizowanym sposobem pracy, a frameworkiem, który udostępnia ogólne zasady. W praktyce rzadko spotyka się projekty, które idealnie spełniają wszystkie założenia Scruma. Każdy projekt wygląda nieco inaczej – począwszy od drobnych szczegółów, takich jak różne pory daily, a skończywszy na dużych różnicach. Przykładowo niektóre zespoły posiadają osobę będącą Scrum Masterem na 100%, w innych zaś rola Scrum Mastera pełniona jest przez osobę będącą jednocześnie członkiem zespołu deweloperskiego, na przykład testerem.