Czy to możliwe żeby być na wakacjach nie ruszając się z Warszawy? I to na wakacjach, gdzie poznajemy egzotyczne zwie… wróć, egzotyczne metodyki pracy? Tak, na „Scrum Safari” organizowanych przy jednym z projektów w e-point, gdzie dodatkowy członek zespołu, czyli „podróżnik”, zagłębia się w praktykę prowadzenia projektu metodyką Scrum.

Safari (źródło: http://hr.wikipedia.org/wiki/Safari)

Czym jest Scrum?

Żeby wyjaśnić czym jest scrum, trzeba zacząć od przypomnienia, czym jest klasyczny model kaskadowy. Model kaskadowy, to taki który składa się z fazy analizy, projektowania, implementacji, testowania, wdrożenia i utrzymania. W klasycznym modelu proces od analizy do wdrożenia trwa 3-12 miesięcy (w przypadku projektów średniej wielkości, jakimi my się zajmujemy), co niesie za sobą ryzyko, że jak po roku klient zobaczy efekt prac, to może być jak w klasycznym branżowym żarcie:

Etapy realizacji systemu informatycznego (źródło: http://www.nurt.pl/?pg=71)

Oczywiście powyższego efektu można uniknąć poprzez prototypowanie, makiety, dobre poznanie potrzeb klienta, itd. Ponadto model kaskadowy zakłada rozłączne role: inne osoby analizują, projektują architekturę, projektują UI, inne implementują, a jeszcze inne testują. To z kolei prowadzi do rozproszenia odpowiedzialności, bo analityk czy projektant po zakończeniu swojej pracy niekoniecznie dalej uczestniczy w projekcie, bo jego praca się „zakończyła” i może nie doczekać wyniku (wdrożenia) bo angażuje się w inny projekt. Mnie osobiście bardziej boli rola programisty w takim projekcie, bo zdarza się że taki osobnik otrzymuje na biurko specyfikacje 5 modułów i polecenie „do roboty, i spotykamy się za 3 miesiące” – bez znajomości całego zakresu projektu, kontekstu biznesowego, innych zadań, motywacji, itd. Oczywiście przykład jest przejaskrawiony, bo tak w praktyce nigdy nie jest, jednak pokazuje zasadę.

Scrum to, w uproszczeniu, alternatywna metoda prowadzenia projektów zakładająca szybkie i „zwinne” podejście. Jest ona oficjalnie dokładnie opisana, ja tu przedstawię swoją definicje: zakłada bardzo szybkie dostarczanie i uruchamianie małych kawałków funkcjonalności, tak aby zamawiający (owner) od razu widział co powstaje. Zamiast czekać na działający efekt 12 miesięcy, dostarczamy pierwszą wersję w 2-4 tygodnie, a potem w kolejnych etapach (tzw. sprintach) rozwijamy ją o kolejne funkcjonalności wybierane na bieżąco przez zamawiającego. Dodatkowe założenia są następujące:

1. Bardzo bliska współpraca zamawiającego z zespołem developerskim, łącznie z fizycznym „kontaktem”, co jest rzadkością w modelu kaskadowym, oznaczająca również transparentność, czyli zamawiający wie, co konkretni ludzie robią w dowolnym momencie.
2. Ustalanie zakresu kolejnego etapu (sprintu) dopiero tuż przed jego startem, czyli tak naprawdę na początku projektu nie jest znany jego zakres ani harmonogram.
3. Sposób rozliczenia za czas pracy zespołu, a nie efekt – element wymagający zaufania od strony zamawiającego, bo w klasycznym modelu płaci on za efekt określony warunkami zamówienia lub specyfikacją.
4. Codzienne spotkania w których członkowie zespołu opowiadają o postępach prac i planach na kolejny dzień.
5. Współdzielenie ról i bliska współpraca: każdy może być projektantem, programistą, front-end developerem i testerem.
6. Wspólne wycenianie złożoności poszczególnych pozycji prac.

Jak łatwo się domyślić, powyższe cechy sprawiają, że metodykę scrum stosuje się do projektów gdzie zamawiający nie jest pewny czego konkretnie potrzebuje i system jest robiony metodą „odkrywkową”. Na pewno nie ma sensu stosować go tam, gdzie wymagania są oczywiste – np. gdy „przepisujemy” stary system na nową technologię bez znaczących zmian funkcjonalności.

Czym jest Scrum Safari?

Wdrożenie Scrum w zespołach działających klasycznie jest niełatwym zadaniem, bo wymaga od wszystkich zmian przyzwyczajenia, zarówno menadżerów, developerów jak i zamawiającego. Aby najmniej boleśnie zachęcić pracowników firmy, nasz lokalny ewangelista Scrum – w osobie Łukasza B. – zaproponował następujące rozwiązanie: zapraszanie do jego projektu, prowadzonego w metodyce Scrum, innych osób na jeden sprint, trwający 2 tygodnie. Założeniem uczestnictwa jest pełne zaangażowanie w prace zespołu w danym okresie, co wiąże się z koniecznością zarzucenia innych obowiązków, stąd nazwa kojarząca się z wakacjami.

W tym okresie uczestniczy się we wszystkich spotkaniach zespołu, dostaje się normalne zadania do implementacji oraz jest się normalnie rozliczanym z wyników. I tak właśnie spędziłem ostatnie dwa tygodnie „nasiąkając” scrumem.

Moje wnioski i przemyślenia

Najważniejszym wrażeniem jest poczucie działania w zespole i wspólny cel, jakim jest dostarczenie dobrego oprogramowania. Jako że na podsumowaniu sprintu wszyscy członkowie zespołu prezentują przed właścicielem projektu (klientem) wyniki swojej pracy, to naprawdę czują się odpowiedzialni za jakość.  Dobrze zapamiętałem moment w czasie takiego z klientem, gdy przy próbie logowania się do aplikacji pojawił się błąd – blady strach pojawił się na twarzach nas wszystkich :-). To uczucie całkowicie niespotykane w kaskadowym procesie, gdzie programista kończy swoją pracę i jedyny feedback ma od testerów, a klienta nigdy nie widzi na oczy. W takim układzie to menadżer projektu „świeci oczami” za błędy swoich programistów, a potem zdarza mu się wyładowywać swoją złość po powrocie ze spotkania z klientem. Więc plusem jest dbanie o jakość, jednak minusem jest fakt że często nie każdy członek zespołu jest gotowy do kontaktów z klientem, np. początkujący, bez doświadczenia, z kiepskimi umiejętnościami komunikacyjnymi.

Drugim pozytywnym wrażeniem jest efekt codziennych spotkań (tzw. daily scrum), gdzie każdy omawia co zrobił i planuje zrobić. To pierwszy od bardzo dawna projekt, w którym miałem wrażenie że każdy członek zespołu jest w stanie podsumować swoje prace, zaplanować kolejne i czuje się w obowiązku cel ten zrealizować. Ponadto wszyscy orientują się na bieżąco, co inni robią. W modelu kaskadowym, jak otrzymuje się zadanie które może zająć np. tydzień, to na początku jest małe zaangażowanie, tzw. „plaża”, a wraz ze zbliżającym się terminem zakończenia, tempo prac wrasta – trzeba co chwila odpytywać i wyciągać informacji „jak Ci idzie, kiedy skończysz”… W scrum „plaż” nie ma, bo nie wyobrażam sobie czyjejś zapowiedzi na daily scrum że „dzisiaj planuje wypoczywać” :-). Minusem tego rozwiązania jest wrażenie przepracowania, bo nie ma żadnych odpoczynków. Ale jest to stan do którego IMO można się przyzwyczaić, trochę jak w dowcipie (źródło: MordorNaDomaniewskiej):

Egzekucja: Wieszają szeregowego pracownika Mordoru z 3rzy letnim stażem.
Wyrok wykonany. Przychodzą go zdjąć po tygodniu.
Profilaktycznie szturchają i okazuje się, że żyje!!!

-Jak to się stało, że przeżyłeś?
-Na początku było ciężko, ale się przyzwyczaiłem

Trzecim pozytywnym efektem bliskiej współpracy z klientem jest znajomość przez wszystkich celów biznesowych systemu, potrzeb funkcjonalnych i pozafunkcjonalnych oraz prostych wrażeń z korzystania użytkownika z aplikacji – wyrażanych werbalnie i pozawerbalnie. Nic tak nie cieszy programisty czy front-end developera, jak uśmiech satysfakcji użytkownika systemu klikającego w nowe moduły, komponenty, itp. Jest to rzecz nie do przekazania przez menadżerów, którzy normalnie mają wyłączności na kontakty z klientem.

Ostatnim wnioskiem jest świetna metodyka pracy Łukasza, który w normalny cykl prac nad projektem zręcznie wplata elementy edukacji na temat metodyki scrum, zmuszając każdego członka zespołu do zrozumienia i opiniowania każdego kawałka tej dosyć skomplikowanej układanki. Efektem jest nabycie kompetencji pozwalających w przyszłości samodzielnie zarządzać zespołem scrumowym…

Reasumując: podobało mi się, chętnie wezmę udział w kolejnym projekcie robionym w Scrum oraz polecam każdemu skorzystać z Safari w zespole Łukasza Barana 🙂