Metodyka zwinna lekiem na całe zło, czyli o co w tym Scrumie chodzi?

Scrum od dłuższego czasu króluje w branży IT. Sporo firm chwali się, że pracują w zwinnej metodyce, przedstawiając korzyści takiego rozwiązania, a kolejni gracze wprowadzają Scrum w zespołach projektowych. Czy ta popularność jest uzasadniona, a może jest to tylko chwilowy trend? O tym rozmawiamy z Michałem Stochmalem, Senior Project Managerem w Comarch.

Może na początek mógłbyś wyjaśnić, w najprostszych słowach, czym jest Scrum?

Mówiąc najprościej, Scrum jest narzędziem pozwalającym na prowadzenie projektu w warunkach dynamicznych zmian potrzeb rynku. Można powiedzieć, że jest frameworkiem¹ do zarządzania projektami i tak jak programiści używają frameworków do pracy z kodem, tak cały zespół używa tego konkretnego do pracy z projektem.

Jak to jest ze Scrumem i Agile? Bardzo często, najczęściej w różnych ofertach pracy, spotykamy się z wymiennym używaniem tych dwóch pojęć. A to są dwa różne „narzędzia”?

Scrum jest jednym z narzędzi, które pomaga osiągnąć założenia zwinnego podejścia do wytwarzania oprogramowania, czyli właśnie Agile. Często w organizacjach stosuje się również inne narzędzia do zwinnego zarządzania projektem, które wspierają i przeplatają się ze Scrumem. Moim zdaniem używanie tych pojęć zamiennie w ofertach pracy nie jest błędem, bo ma pokazać potencjalnemu kandydatowi, że firma preferuje zwinne podejście do zarządzania projektami. Scrum jest na tyle elastyczny, że w każdej organizacji wygląda inaczej, więc trudno byłoby porównywać dwie oferty z dwóch różnych firm tylko ze względu na ten parametr. Użycie pojęcia Agile pozwala na generalizowanie podejścia do prowadzenia projektów w organizacji.

Twój zespół od jakiegoś czasu pracuje w Scrumie. Co się zmieniło dzięki wdrożeniu takiego rozwiązania?

W specyfice projektów webowych wcześniej dominowało podejście waterfall-owe. To oznaczało, że na początku zbieraliśmy wymagania od klienta, a następnie trwała dość długa faza developmentu (proces wytwarzania oprogramowania – przyp. red.), w czasie której klient nie widział żadnych efektów pracy. Dopiero w ostatnim kroku, gdy zespół uznał, że zrealizował wszystkie założenia klienta, przekazywał efekty pracy do jego oceny. Niestety często bywało tak, że klient nie był sobie w stanie wyobrazić, jak coś będzie działało i, szczególnie w przypadku „wirtualnych produktów”, nie miał doświadczenia oraz wiedzy technicznej, która pozwalałaby mu na precyzyjne ujęcie swoich oczekiwań. Wówczas następował moment, w którym gotowy produkt zderzał się z jego wyobrażeniami, co niejednokrotnie powodowało rozczarowanie. „Myślałem, że to będzie działało inaczej” jest chyba najczęstszym stwierdzeniem, które słyszy zespół pracujący waterfall-owo.

Przy pracy w Scrumie klient jest obecny w projekcie cały czas, po każdym sprincie² widzi konkretne efekty pracy, które może ocenić na bieżąco, a w przypadku konieczności zmiany zakresu projektu - może to zrobić w dowolnym momencie. Zespół pracując w Scrumie ma poczucie, że pracuje tylko nad funkcjonalnościami, których klient faktycznie chce i potrzebuje, przez co unika sytuacji, w których jego praca jest wyrzucana do kosza, ponieważ „pół roku temu zmieniły się potrzeby biznesowe klienta”.

Ważną rolę w zespole odgrywa bez wątpienia Scrum Master³, przed którym stoi sporo wyzwań. Jakich błędów powinien unikać początkujący SM? 

Przede wszystkim usztywniania się. Sztywne stosowanie książkowych reguł nie sprawdza się w życiu - również dotyczy to Scruma. Nie znam żadnego przypadku literalnego stosowania wszystkich zasad tej metodyki w praktyce, który zakończyłby się sukcesem. Każda organizacja jest inna i każdy zespół jest inny, dlatego należy te zasady dostosować do panujących warunków. Należy pamiętać, że teoria przedstawia wyidealizowany świat, w którym wszystkie te reguły zastosowane w pierwotnej postaci przyniosą szczęście dla zespołu i klienta. Życie bardzo szybko weryfikuje wszystkie idylliczne podejścia. 

Wspomniałeś o obecności klienta w projekcie i swobodniejszej możliwości wprowadzania zmian w zakresie wymogów. Jaka zatem jest rola feedbacku w pracy nad produktem?

Cały Scrum oparty jest na feedbacku. „Dowożąc” w każdym sprincie jakiś działający fragment, zespół w naturalny sposób oczekuje informacji zwrotnej. Bez tego elementu nie ma możliwości szybkiej reakcji na dynamiczne zmiany. Pomaga to również uniknąć najgorszej sytuacji w pracy programisty - frustracji.

Feedback w krótkich cyklach i możliwość modyfikacji zakresu oraz kierunku projektu jeszcze w trakcie jego tworzenia, pozwala na uniknięcie scenariusza, w którym po dwóch latach ciężkiej pracy, wypuszczamy niedopasowany produkt do potrzeb rynkowych, i w którym jedynym rozsądnym rozwiązaniem, jest zrezygnowanie z niego. Taka sytuacja powoduje właśnie tę frustrację, o której wspomniałem.

Mówisz o informacji zwrotnej, którą na etapie prac nad projektem, zgłasza klient, ale odnosi się to, do całego projektu – pracy zespołowej. Czy w takim razie można zakładać feedback indywidualny w zespole Scrumowym?

W zespole Scrumowym z założenia wszystkie feedbacki są grupowe, bo zespół wewnętrznie sam się reguluje. Jeśli ktoś zrobił coś, co zasługuje na uznanie - zostaje to podniesione w całym zespole. W przypadku negatywnego feedbacku sytuacja może być nieco bardziej skomplikowana, bo mocno zależy od indywidualnego podejścia do krytyki poszczególnych członków zespołu. Z założenia retrospekcja jest idealnym miejscem na feedback zarówno pozytywny, jak i negatywny. Są jednak sytuacje, gdy negatywna wiadomość o pracy, jest bardziej konstruktywna, kiedy jest przekazywana indywidualnie. Należy pamiętać, że bardzo łatwo można przekroczyć granicę, gdy zwracamy komuś uwagę podczas spotkania całego zespołu i może się ono przerodzić w swoistą formę linczu.

Patrząc na to trochę „z boku” można odnieść wrażenie, że feedback w branży IT różni się od swojego odpowiednika w innych branżach. Czy tutaj trzeba zwrócić uwagę na coś specjalnego?  

Moim zdaniem feedback w branży IT jest zupełnie inny niż w innych branżach. Trzeba pamiętać, że po pierwsze wytwarzamy coś ekstremalnie niematerialnego i to najczęściej w procesie, który jest zupełnie niezrozumiały dla klienta. Klient wie, że wyprodukowanie krzesła musi zająć czas, bo trzeba zgromadzić materiał, obrobić go, złożyć i polakierować. Doskonale wie, że z tego krzesła fabryka nie zrobi sofy, bo nagle zmienił zdanie. My produkujemy tysiące sof z krzeseł każdego roku, bo przecież „co to za problem? Przecież to taka mała zmiana więc nie powinna Wam zająć dużo czasu”.  Myślę, że to esencja różnicy w feedbacku między naszą branżą a innymi. 

Czy programiści chętnie przyjmują krytykę? Mówi się, że to są indywidualiści, ale jak to jest w praktyce? Czy rzeczywiście tak jest, czy jest to powtarzany mit?

Z mojego doświadczenia możemy powiedzieć o dwóch rodzajach krytyki. Pierwsza to krytyka wewnątrz zespołu. Tutaj zazwyczaj nie ma z tym żadnego problemu. Krytyka wówczas jest bardzo przemyślana. Musimy pamiętać, że również dla krytykujących to bardzo stresująca sytuacja, bo zmusza do konfrontacji, której chyba żaden programista nie lubi. Jest ona najczęściej bardzo konstruktywna i przygotowana z matematyczną precyzją, żeby uniknąć „odwracania kota ogonem”. Z taką krytyką większość programistów nie ma problemu. 

Jest jeszcze drugi rodzaj krytyki. Krytyka „zewnętrzna”, czyli krytyka od przełożonego lub klienta. Ona prawie zawsze wywołuje poczucie krzywdy. Ten typ jest ciężej przyjmowany przez programistów, ale to nie jest związane z indywidualizmem. Nawet „gracze zespołowi” nie przyjmują jej łatwo.

Dlaczego?

Bo każdy programista, który jest zaangażowany w swoją pracę, tworzy coś zgodnie z wymaganiami, które zostały przygotowane. W swojej ocenie zgodnie z tym, co zostało zgłoszone w wymogach projektowych, dostarcza najwyższej jakości produkt. Oczywiście, jeśli produkt, który dostarczył działa. Jeśli z góry wie, że nie wszystko zostało zrobione, ta krytyka jest przyjmowana bardziej ze zrozumieniem. Na koniec wszystko oceniane jest przez klienta, który nie zawsze potrafił doprecyzować wymagania. Wówczas pojawiają się krytyczne opinie z jego strony, bo produkt nieco mija się z jego założeniami i właśnie ten typ krytyki ciężko przyjąć.

Sporo powiedziałeś o krytyce i pochwałach w zespole Scrumowym. Można oceniać cały produkt, ale pozostaje jeszcze kwestia „mniejszych elementów”, które się na niego składają. Jakie w takim razie ma znaczenie Code Review⁴ w codziennej pracy programisty?

Myślę, że przede wszystkim daje poczucie komfortu w pracy. Komfortu wynikającego z tego, że jeszcze jedna para oczu rzuci okiem na napisany kod i jeśli zauważy coś, co mogło nam umknąć albo wydaje nam się, że powinno działać idealnie - zostanie to nam wskazane. Wiem, że czasem managerowie unikają tego elementu, bo KOSZTY, ale moim zdaniem to wielki błąd. Code Review pomaga w wypuszczaniu przez zespół wysokiej jakości kodu, a jednocześnie pozwala poszczególnym programistom na rozwijanie swoich umiejętności. Każdy zwrot „to fix” po Code Review jest cenną lekcją i pomaga na uniknięcie podobnych błędów w przyszłości. Każde „to fix” jest traktowane mocno ambicjonalnie, bo właśnie ambicji zdecydowanie nie brakuje w tym zawodzie. 

Wracając jeszcze na koniec do Scrumu. Ta metodyka cieszy się od dłuższego czasu sporą popularnością. Skąd wynika ta moda na pracę w Scrumie?

Najprościej mówiąc wynika to z wygody po stronie zespołu i poczucia kontroli po stronie klienta. W podejściu waterfall-owym klient przedstawiał wymagania, a potem czekał wiele miesięcy na efekty prac. W Scrumie ma on kontakt z zespołem, może zadać pytania, jeśli czegoś nie rozumie. To działa w dwie strony – zespół również może wyjaśnić niejasne kwestie. W tym modelu pracy obie strony budują w sobie poczucie odpowiedzialności za projekt, co na końcu daje obustronną satysfakcję.

Brzmi jak idealne rozwiązanie. Czy istnieje inna metodyka, która mogłaby go zastąpić? 

Oczywiście! Jest wiele narzędzi, które można wykorzystać. Warto pamiętać, że Scrum nie nadaje się do wszystkich projektów. Wciskanie go na siłę tam, gdzie po prostu nie pasuje, jest dużym błędem. Na początku pierwszym pytaniem, które musimy sobie zadać, to czy w tym przypadku jego wprowadzenie ma sens? Jeśli ma - róbmy projekt w Scrumie. Jeśli nie? Wykorzystajmy inne narzędzie, które będzie lepiej dopasowane do naszych potrzeb. Czasem nawet waterfall może okazać się w konkretnym przypadku najlepszym podejściem.

Przypisy

1) Frameworki stanowią pewnego rodzaju szkielet do budowy aplikacji. Framework oprócz tego, że definiuje strukturę samej aplikacji również definiuje mechanizm jej działania. (źródło: teamquest.pl)
2) Sprint jest zdefiniowany w Scrum jako stały czas, podczas którego jest wykonywana cała praca. (źródło: scrum.org.pl)
3) Osoba odpowiedzialna za proces. Scrum Master ma dbać o to, by Scrum był prawidłowo zrozumiany i stosowany zarówno w samym zespole jak i w organizacji. Scrum Master odpowiada także za zespół, jego produktywność i zaangażowanie. (źródło: scrum.org.pl)
4) Przegląd Kodu (ang. Code Review) polega mniej więcej na tym, że po zakończeniu implementacji jakiegoś konkretnego kawałka funkcjonalności, zwykle przed „wbitką” zmian do systemu kontroli wersji, pokazujemy nasz kod koledze z zespołu do oceny. (źródło: nafrontendzie.pl)