Wszystko, co powinieneś wiedzieć o SCRUM – cz. III

W pierwszej i drugiej części naszej serii udało nam się pokrótce przybliżyć czym jest metodyka scrum oraz jej podstawowe pojęcia. W ostatnim artykule  chcemy przedstawić Wam opinie programistów na temat pracy w systemie scrumowym oraz odpowiedzieć na pytanie: Czy rzeczywiście aż tak bardzo wpływa on na pracę nad oprogramowaniem?

Same środowiska scrumowe reklamują się poprawą takich czynników jak:

– wydajność – w niektórych źródłach internetowych i książkowych znajdują się wzmianki o tym, iż scrum zwiększa wydajność osób w zespole nawet o 300% (!) w porównaniu do metodyka waterfall (kaskadowej);

– większe zadowolenie klienta – spowodowane głównie tym, iż klient jest uwzględniony w procesie developmentu oraz jego uwagi na temat funkcjonalności są uwzględniane w planie produkcji przez product ownera;

– zwiększona kontrola nad postępami projektu – dzięki codziennym spotkaniom oraz retrospekcjom jesteśmy w pełni świadomi stanu produktu oraz powstających funkcjonalności;

– zwiększone morale wśród zespołu – scrum stawia przede wszystkim na samoorganizację, a więc programiści mają większą dozę dowolności i możliwość eksperymentowania. Dodatkowo relacje koleżeńskie (zamiast podległych) pomiędzy zespołem a biznesowym właścicielem produktu pozytywnie wpływają na relacje.

To tylko niektóre z pozytywów, które wymienia się w literaturze związanej z tą metodyką. Co jednak na ten temat myślą sami uczestnicy zespołów scrumowych? Zebraliśmy kilka opinii i postanowiliśmy podzielić się nimi z Wami tak, abyście mogli spróbować wykreować własne poglądy na ten temat.

Wpisując w google hasło „scrum opinions” (opinie na temat scruma) jako pierwszy wyskakuje nam wynik „Why Agile and especially Scrum are terrible” (czemu metodyki zwinne i szczególnie scrum jest okropny). Ta opinia jest również po części podzielana przez naszego pierwszego rozmówcę, Adama (młodszy programista Java, pracujący w scrumie przez półtora roku):

„Uważam że scrum sam w sobie nie jest zły – jest to metodyka jak każda inna. Mi nie podobał się cały ten obrządek, codzienne spotkania sprawiały, że czułem się jak gdyby scrum master nie ufał mojej pracy, codziennie powtarzane te same pytania sprawiały że czułem na sobie całkiem sporą presję. Dodatkowo sprinty niekiedy nie pozwalały na wdrażanie innowacji w projekt – przede wszystkim skupialiśmy się na tym aby stworzyć działającą funkcjonalność (niestety niekiedy byle jak – byleby można było się czymś pochwalić na retrospekcji). Dodatkowo jestem jedną z tych osób, które nie przepadają za zabiegami coachingowymi – a odniosłem wrażenie że tylko taką funkcję przyjmował scrum master. Żeby nie było sam scrum – ma też on swoje plusy, jak na przykład to, że doskonale jestem w stanie śledzić postępy projektu i zazwyczaj nie przeszkadzano mi w zadaniu do którego się zadeklarowałem na spotkaniu planującym. Być może była to wina złej implementacji, ale ta metodyka po prostu dla mnie nie zdawała egzaminu, powiększała niekiedy mój poziom stresu i zdecydowanie bardziej przypadają mi do gustu tradycyjne metody zarządzania. W obecnej pracy czuję się zdecydowanie bardziej swobodnie, a według mojej opinii prace nad aplikacjami przebiegają w mniej więcej takim samym tempie.”

Odmiennego zdania jest natomiast Mateusz Wilczewski (C# developer, pracuje w tej metodyce od mniej więcej roku) – zapytany o pracę w scrumie zwraca uwagę przede wszystkim na to, że dzięki scrumowi w zespole panuje porządek i wszyscy wiedzą co mają robić:

„Scrum jest bardzo dobrym narzędziem do pracy w zespole – pozwala w doskonały sposób kontrolować przebieg pracy nad produktem. Dzięki współpracy z właścicielem produktu omija nas cały kontakt z klientem – gdy na studiach pracowałem przy frontendzie nienawidziłem współpracować z często niezdecydowanym klientem. Dzięki historyjkom wiem co mi jest potrzebne, backlog w łatwy i przejrzysty sposób ukazuje elementy, które zostały jeszcze do zrobienia, retrospekcje pozwalają na lokalizowanie miejsc, w których łatwo możemy coś poprawić. Jeden element ze standardowego scruma, który bym poprawił to codzienne spotkania, czasem ustalaliśmy, że spotkania odbywały się co drugi dzień – gdyż codzienne spotkania nie zawsze przynosiły zamierzony skutek. Dużo zależy też od mastera, dobry scrum master jest nieoceniony w swojej pracy i poprawia efektywność programistów. W scrumie podoba mi się również to, że tak naprawdę sami decydujemy o tym co mamy robić – podczas planowania sami wybieramy nasze zadania co dobrze wpływa na morale zespołu”.

O opinię na temat scruma zapytaliśmy również Roberta Wachowiaka, dyrektora działu systemów finansowych w banku. W trakcie swojej kariery pracował on w tej metodyce kilka razy i wyrobił sobie konkretne zdanie na ten temat:

„Scrum przede wszystkim jest narzędziem – nie jest on złotym środkiem do rozwiązania wszystkich problemów powstających podczas procesu tworzenia oprogramowania. Oczywiście na samym wstępie należy również wspomnieć, że między bajki można włożyć siedmiokrotne przyspieszenie produkcji (co potrafią niekiedy deklarować osoby zaangażowane w scruma). Z doświadczenia wiem, iż przykładowo w projektach regulacyjnych sprawuje się on dużo gorzej niż zwykła metodyka kaskadowa”. Mówiąc o projektach regulacyjnych Robert tłumaczy nam, iż chodzi o projekty, w których należy dostosować istniejące oprogramowanie do zewnętrznych regulacji – wtedy najważniejsze jest jak najszybsze i najtańsze wytworzenie produktu. „Kiepsko również może się sprawdzać w zespołach o małej (lub bardzo dużej) liczebności – najczęściej nie ma wtedy sensu wprowadzania całego obrządku scruma do zespołu. Inna sprawa kiedy zajmujemy się nowymi projektami, w których tworzymy aplikację od zera, wtedy scrum okazuje się niesamowicie przydatny. Po pierwsze, pozwala dokładnie śledzić co dzieje się w projekcie – dzięki komunikacji zespół scrum – product owner – klient wszyscy doskonale wiedzą na jakim etapie znajdują się prace nad produktem. Po drugie, dzięki codziennym spotkaniom developerzy są w stanie szybciej reagować na pojawiąjące się na drodze problemy. Po trzecie, dzięki historyjkom łatwo jest panować nad tym co ma się znaleźć w projekcie i w jakiej kolejności powinno być implementowane. Na sam koniec warto również dodać, iż tworzenie w czasie jednego sprintu działającej funkcjonalności doskonale działa na morale zespołu oraz na samopoczucie klienta, wszyscy są w stanie wtedy zobaczyć jak szybko posuwają się prace nad projektem.”

Na temat scruma wyraził również opinię Paweł Prociów CTO w firmie Proxi.cloud (firma zajmuje się dostarczaniem usług opartych na beaconach i geolokalizacji). Jego opinia dotyczy drugiej strony – w scrumie był właścicielem produktu:

„Przede wszystkim jest to metodologia bardzo wygodna dla developerów – dzięki organizacji w sprinty mają pewność, że nikt im nie dorzuci łatwo zadań, których nie powinni robić w danym czasie. Uważam również, że dzięki standupom i ceremoniom odpowiedzialność za ewentualne błędy jest rozmyta, co również jest bardzo wygodne dla zespołu programistów. Generalnie, łatwo jest zająć się swoim i nie trzeba się zastanawiać nad szerszą perspektywą. Nieco gorzej ma się sytuacja z perspektywy właściciela produktu bądź biznesu – czasem ciężko jest odpowiadać nawet na najbardziej proste pytania od klientów, jak, na przykład, «Kiedy będzie dostępna dana funkcjonalność?” » lub «Kiedy będzie poprawiony dany błąd?». Dodatkowo poprzez rozmycie odpowiedzialności menagerowi trudniej jest odsiać dobrych developerów od złych, co powoduje to, że trudniej jest pozbyć się tych drugich z zespołu”.

Podsumowanie

Jak widać, opinie na temat tej metodyki pracy potrafią być bardzo różne – zmieniają się one również w zależności od pełnionej w zespole funkcji. Warto pamiętać o tym, iż to jak będziemy postrzegać scruma zależy też od tego w jaki sposób będzie implementowany w naszym środowisku pracy i jak my sami podejdziemy do korzystania z tej możliwości organizacji projektu. Jedno jest pewne, metodyki zwinne mają ogromną popularność na całym świecie i na pewno nie dzieje się to bez powodu. Tym wpisem kończymy również serię artykułów o scrumie. Mamy nadzieję, że udało nam się chociaż trochę przybliżyć Wam tą metodykę, jej zastosowania oraz wady i zalety. Na sam koniec zachęcamy również do podzielenia się Waszą opinią na ten temat w komentarzach – dzięki temu każdy czytający będzie mógł jeszcze bardziej wzbogacić swoją wiedzę na ten temat!

Autor: Marek Makuch

Zaktualizowany wpis, który pojawił się na naszym blogu w lipcu 2018r.