Wszystko, co warto wiedzieć o Scrumie – cz. I

Poszukując pierwszej pracy, jako „samouk – programista” wiele rzeczy, które znajdowały się w ofertach pracy było dla mnie niezrozumiałych. Mając (jak wydawało mi się wtedy) solidną wiedzą o Javie, SQL oraz Springu sporo pojęć dalej było mi obcych – najczęściej dotyczyły one technologii lub narzędzi pracy, z którymi nie miałem jeszcze przyjemności się zapoznać. Jednak równie często jak pojęcia technologiczne, przejawiało się również stwierdzenie „praca w systemie zwinnym” lub „SCRUM-owa metodyka pracy”.

Jako ówczesny projektant maszyn z niewielkiej Polskiej firmy  było mi to pojęcie całkowicie nieznane – postanowiłem wtedy jak najszybciej uzupełnić wiedzę z tego tematu. I tak dowiedziałem się o jednym z najbardziej rozpowszechnionych sposobów organizacji pracy w świecie IT – sposobie, dzięki któremu efektywność pracy wzrasta, komunikacja w zespole jest na najwyższym poziomie, a sam klient ma realny wpływ na wynik naszej pracy. Jako, że jest to pojęcie niezmiernie popularne w nowoczesnych środowiskach pracy, postanowiliśmy w krótkiej serii artykułów przybliżyć Wam, czym tak właściwie jest Scrum, jakie są jego podstawowe założenia oraz pojęcia używane w tym temacie. Ponadto postaramy się również pokazać Wam pozytywne, jak i negatywne opinie na temat pracy w tej metodologii. Gotowi na Wasz pierwszy Sprint? 😉

Historia Scruma

Zacznijmy może od historii. Po raz pierwszy w odniesieniu do tworzenia produktu termin „scrum” został użyty już w roku 1986 – w artykule „New Product Development Game” (polecam przeczytać zainteresowanym – wiele ze stwierdzeń w artykule jest nadal aktualne w odniesieniu do czasów teraźniejszych). W artykule Harvard Business Review Hirotaka Takeuchi oraz Ikujiro Nonaka pisali o tym, iż w nowoczesnym środowisku produkcyjnym zwykłe, stare sekwencyjne podejście nie sprawdza się – zdecydowanie lepsze wyniki osiąga się poprzez stosowanie elastycznych technik produkcji, w której poszczególne fazy pokrywają się, a zespół produkcyjny pracuje jako jedna całość – nie zaś jako pojedyncze osoby.

W latach dziewięćdziesiątych nastąpił jednak prawdziwy rozwój tej metody. Ken Schwaber (jeden z dwójki ojców teraźniejszego scruma) stosował w swojej firmie praktyki, które nazywał „zaawansowanymi metodami rozwoju” (Advanced Development Methods), które w znacznym stopniu pokrywały się z tym, czym w dzisiejszych czasach jest scrum. Równolegle w  Easel Corporation Jeff Sutherland (drugi „ojciec”), John  Scumniotales oraz Jeff McKenna opracowywali podobne podejście nazywając je po prostu jednym słowem – scrum. Schwaber we współpracy z Sutherlandem wspólnie przedstawili w 1995 roku pracę opisującą metodologię Scrum (jako część „Object-Oriented Programming, Systems Languages & Applications ’95) na konferencji w Austin w Texasie.

W roku 2001 w ośrodku narciarskim „The Lodge at the Snowbird” zespół siedemnastu osób związanych z programowaniem (w tym Sutherland i Schwaber) przedstawili najbardziej znany manifest odnośnie metodologii pracy w IT – The Agile Manifesto . Miał być on zawołaniem do wszystkich twórców oprogramowania na całym świecie, aby stosować zupełnie inny sposób zarządzania projektami. W 2001 roku została również wydana książka „Agile Software Development with Scrum”, w której Ken Schwaber, we współpracy z Mikiem Beedlem, opisuje jak wdrożyć i stosować scrum w zarządzaniu projektami.

Scrum i jego wartości

Ale czym tak właściwie jest scrum i co leży u podstaw tej techniki zarządzania projektami?
Scrum w najprostszym tłumaczeniu jest czymś w rodzaju framework’u w zarządzaniu projektami związanymi z rozwojem oprogramowania. W jego centrum jest pięć głównych wartości:

– Focus (skupienie) – ponieważ zespół skupia się tylko na kilku rzeczach na raz, starając się dostarczyć produkt najwyższej jakości,

– Courage (odwaga) – spowodowana tym, że pracujemy w grupie, mamy więc większe możliwości aby podejmować trudniejsze wyzwania – mamy też odwagę, aby wierzyć w innych członków zespołu i w razie potrzeby komunikować im swój sprzeciw,

– Openness (otwartość) – współpracujemy i informujemy się na bieżąco o tym co robimy, o tym co nam stoi na przeszkodzie oraz o naszych obawach – dzięki temu możemy radzić sobie z nimi wspólnie,

– Commitment (zaangażowanie) – staramy się wykonywać swoją pracę jak najlepiej, angażując się w proces tworzenia produktu.,

– Respect (szacunek) – traktujemy się na równi oraz z szacunkiem. Szanujemy swoje decyzje oraz szanujemy nasz czas – nie spóźniając się na spotkania oraz będąc do nich przygotowanym.

Rys. 1 Wartości scrum.

 

Kto jest kim w zespole?

Zespoły, które zarządzane są tym sposobem, zazwyczaj składają się (idealnie) z siedmiu osób (w przybliżeniu – liczba ta może zmieniać się o mniej więcej dwa w górę bądź w dół), którym jest przydzielana jedna z trzech ról – Product Owner (właściciel produktu), scrum master oraz członek zespołu. Są to trzy główne role występujące w zespole. Właściciel produktu ma za zadanie być głosem klienta w procesie tworzenia oprogramowania – jest on odpowiedzialny za dostarczenie produktu na czas oraz jego jakość. Odpowiada on również za tworzenie historii użytkownika (czyli zadań, które są do wykonania w danym produkcie, spisywanych w oparciu o kontakt z klientem) oraz ustala, które zadania mają wartość priorytetową – w oparciu o ich ważność oraz zależności z innymi produktami. W zespole powinna znajdować się jedna osoba na tym stanowisku – nie powinno łączyć się tej roli z rolą scrum mastera. Mówiąc o scrum masterze – odpowiada on za kultywowanie metodologii scrumowej wśród zespołu. Jest on swojego rodzaju łącznikiem z zespołu programistów z właścicielem produktu. Jego obowiązki obejmują między innymi pomaganie w tworzeniu historii produktu, organizowanie codziennych spotkań oraz sprintów, nadzorowanie postępów w pracy oraz informowanie o postępach właściciela produktu. Terminu zespołu developerów nie trzeba chyba objaśniać – to ludzie którzy kawę zamieniają w działający produkt a wszystkie problemy rozwiązują zawsze na czas ;-).

Rys. 2 Schemat pokazujący specyfikę komunikacji w zespole scrumowym.

 

Praca w oparciu na metodykach zwinnych

W odróżnieniu od tradycyjnego modelu kaskadowego, w którym przed rozpoczęciem realizacji dokładnie planujemy i dokumentujemy funkcjonalność naszego produktu – stosujemy mechanizm iteracyjny. W strategii tej, proces tworzenia oprogramowania dzielimy na konkretne jednostki czasowe (tzw. Sprinty), w których zakładamy, że uda nam się zakończyć konkretną funkcjonalność. Oznacza to mniej więcej tyle, że na początku każdego sprintu (którego okienko czasowe zazwyczaj przyjmuje się na dwa tygodnie – aczkolwiek długość jednego sprintu może być modyfikowana w zależności od projektu, nad którym pracujemy) następuje planowanie, jakie czynności mają być wykonane w danej iteracji. Scrum zakłada, że dane jednostki są samodzielne i wybierają sobie zadania na podstawie oceny osobistych zdolności bądź preferencji. Wszystkie zadania, jakie są do wykonania powinny znajdować się w tzw „Sprint Backlog” (rejestr zadań przebiegu) wraz z oszacowaną czasochłonnością. Zadania to nic innego jak tworzone przez właściciela produktu historie użytkownika. Scrum stawia na ciągły kontakt z klientem, odchodzi się tutaj od standardowego pojęcia klient – dostawca. Stawia się raczej na stwierdzenie, iż klient jest również w pewnym sensie integralną częścią zespołu, która komunikuje swoje potrzeby i reaguje na produkty wytworzone przez developerów. Dzięki temu produkt jest w stanie być bardziej spersonalizowany i dokładnie odpowiada preferencjom zleceniodawcy, pozytywnie wpływając na jakość wykonywanej pracy.

Kolejnym ważnym punktem metodologii scrum są również codzienne spotkania, które powinny zawsze zamykać się w piętnastu minutach i odbywać o określonej godzinie i w określonym miejscu nawet w przypadku gdy brakuje osoby z zespołu. Podczas tych krótkich spotkań każdy członek zespołu zazwyczaj odpowiada na trzy pytania:

– Co zrobiłem wczoraj aby przybliżyć cel danego sprintu?

– Co mam zamiar zrobić dzisiaj aby przybliżyć cel danego sprintu?

– Czy widzę jakieś przeszkody na drodze do wykonania celu danego sprintu?

Każda przeszkoda, która pojawia się w czasie takiego spotkania powinna zostać zauważona przez scrum mastera i przedstawiona reszcie zespołu – tak, aby wspólnie móc wypracować jakieś rozwiązanie (ważne jest aby w czasie codziennych spotkań nie wchodzić w szczegóły – to nie jest czas na rozwiązywanie powstałych problemów).

Po zakończeniu danego sprintu następuje czas na sprint review (przegląd sprintu). W czasie przeglądu sprintu prezentowane są wyniki zakończonej iteracji – następuje rozmowa na temat realizacji planowanych założeń, spełnienia kryteriów oraz jak wytworzona funkcjonalność spełnia zapotrzebowanie klientów. Jest to również miejsce na podjęcie decyzji o tym, co można jeszcze usprawnić w danym produkcie. Ważnym punktem może być również przedstawienie wyników pracy właścicielowi produktu oraz klientowi – taki proces nosi nazwę sprint demo. Proces ten polega na przedstawieniu przez określony zespół konkretnej, działającej funkcjonalności. Dzięki temu właściciel produktu oraz klienci są w stanie udzielić informacji zwrotnych odnośnie ich opinii na temat działania funkcjonalności.

Tak mniej więcej wygląda jedna scrumowa iteracja! Proces ten jest powtarzany w celu ciągłego usprawniania produktu, opierając się na historiach użytkownika. Gwarantuje to zadowolenie klienta, który ma realny wpływ na to co dzieje się z produktem, oraz usprawnia komunikację w zespole – gdyż programiści mają jasno wytyczone zadania, a kontakt z klientem odbywa się przez scrum mastera i właściciela produktu. Jednak jak się połapać w tych wszystkich pojęciach i procedurach? W tym również postaramy się Wam pomóc – przedstawiając krótki słownik pojęć używanych w metodologii scrum. W ostatnim artykule przytoczymy opinie osób, które pracują w takim systemie, zarówno pozytywne jak i negatywne, tak abyście sami mogli ocenić czy według Was odpowiadałby Wam taki system pracy. Tymczasem dziękujemy bardzo za uwagę i do przeczytania w najbliższym czasie!

 

IT-Leaders.pl to pierwsza na rynku platforma łącząca Specjalistów IT bezpośrednio z pracodawcami. Anonimowy, techniczny profil i konkretnie określone oczekiwania finansowe to tylko niektóre z cech wyróżniających platformę. Zarejestruj się i zobacz jak Cię widzi pracodawca.

You may also like...