Scrum oczami testera oprogramowania

Maciej Kirkicki Starszy konsultant, PwC Polska 04/07/18

Scrum – czym właściwie jest ta metodyka?

Zgodnie z definicją w Wikipedii:

„Scrum – iteracyjne i przyrostowe ramy postępowania (ang. framework) zgodne ze Scrum Guide. Może mieć zastosowanie w realizacji projektów w oparciu o metodyki zwinne zgodne z manifestem Agile.W ramach tego postępowania rozwój produktu podzielony jest na mniejsze, trwające maksymalnie jeden miesiąc kalendarzowy iteracje, zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą jego wersję. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny.”

Dodać należy, że zespół Scrum liczy od 3 do 10 osób, których umiejętności powinny być na tyle rozproszone, żeby zespół był w stanie samodzielnie przeprowadzić projekt od fazy planowania po wdrożenie.
Główne role przypisane członkom takiego zespołu można podzielić na trzy grupy:

  • Zespół programistyczny (development team) - zespół odpowiedzialny za dostarczenie produktu
  • Właściciel produktu (product owner) - osoba odpowiedzialna za produkt. Reprezentant klienta, osoba która najlepiej orientuje się w tym, w jaki sposób wdrażany system ma służyć zlecającemu
  • Scrum Master - strażnik procesu. Osoba odpowiedzialna za działanie zgodne z wytycznymi metodyki.

Dewizą projektów prowadzonych w Scrum może być hasło „przede wszystkim działający produkt”. Jest to zasada nadrzędna: należy w zakładanym przedziale czasowym, zwanym sprintem, dostarczyć produkt, który w pełni działa. Nawet kosztem zakładanych w fazie planowania funkcjonalności, których nie udało się wdrożyć: konkretne wymaganie ma być dostarczone w całości i w pełni funkcjonalne. Jeżeli nie spełnia tego kryterium, należy odroczyć jego wdrożenie.

Takie podejście jest największą siłą metodyk zwinnych – pozwala na bardzo dużą elastyczność podczas realizacji zadań i dostosowywanie się do zmieniających się warunków.

Dlaczego projekty prowadzone w metodykach zwinnych kończą się niepowodzeniem?

Odpowiedź na to pytanie jest stosunkowo prosta i oczywista: najczęściej przyczyną niepowodzenia jest nieprzestrzeganie wytycznych Scrum i adaptacja tego podejścia do panujących w firmie wzorców i przyzwyczajeń.

Oto kilka największych błędów popełnianych przez organizacje:

  • Migracja ról z dotychczasowych projektów do nowo utworzonych zespołów, mających działać w Scrum.
    W ten sposób powstaje twór, w którym mamy menadżera projektu, kierownika zespołu programistów oraz kierownika testów. Żadna z tych ról nie funkcjonuje w Scrum.
  • Zaniedbywanie testów oprogramowania.
    W Scrum rola testera nie występuje odrębnie, oczywistym powinno zatem być, że tester oprogramowania jest częścią zespołu deweloperskiego. Często tak jednak nie jest. Testy nierzadko traktowane są po macoszemu i odkładane na końcowy etap sprintu, podczas gdy powinny stanowić one kryteria sukcesu i być integralną częścią projektu (Definition of Done).
  • Ścisłe trzymanie się podziału na specjalizacje.
    W wielu organizacjach pokutuje myślenie, że programista nie będzie testował, a tester oprogramowania nie popatrzy na kod. Jest to antywzorzec działania w tej metodyce. W zespołach Scrum role powinny się przeplatać, a członkowie zespołu powinni być w stanie
    zastępować siebie nawzajem w prostszych zadaniach.
  • Skupianie się nad rozwojem poszczególnych komponentów systemu przez dany zespół zamiast dostarczenia pełnej funkcjonalności.
    Przy większych systemach, popularną praktyką jest tworzenie wielu zespołów, które zajmują się poszczególnymi komponentami projektu. Często dana funkcjonalność przepływa pomiędzy modułami, a więc rozsądniej w takich przypadkach jest przydzielać
    poszczególnym zespołom nie komponenty systemu, a funkcjonalności sprecyzowane w wymaganiach.
  • Niepełne rozumienie tego co tworzona aplikacja ma robić.
    Właściciel produktu często pomimo wiedzy eksperckiej w danej dziedzinie, nie potrafi zidentyfikować prawdziwej potrzeby biznesowej stojącej za wdrożeniem.

Bardzo często zapomina się też o tym, że nie tylko właściciel produktu ma wiedzieć, jaką rolę aplikacja ma spełniać w organizacji klienta. Zespół w miarę upływu czasu powinien posiąść taką samą wiedzę, jak product owner na temat już wdrożonych funkcjonalności. Tutaj ponownie wraca temat testów - zaniedbywanych, pozostawionych na sam koniec każdego sprintu i  przeprowadzonych pobieżnie. Jest to jeden z kluczowych błędów, ponieważ to właśnie test jest potwierdzeniem, że prawidłowo zrozumieliśmy oczekiwania klienta i system działa zgodnie z jego wytycznymi. W tej kwestii wiele zależy od właściciela produktu, którego funkcja powinna być najbardziej zbliżona do podejścia testerskiego. Z reguły jest jednak dokładnie odwrotnie: cała uwaga skupiona jest na wdrożeniu, ale niekoniecznie już na weryfikacji poprawności tego wdrożenia.

Jak zatem sprawić aby metodyki zwinne były naprawdę zwinne?

Jak już wspomniano powyżej, najważniejszą cechą metodyk zwinnych jest elastyczność i możliwość dostosowania działań do pojawiających się problemów. Jednak elastyczność zespołu Scrum też ma swoje granice. Granicą nieprzekraczalną są testy, których nie udało się wykonać, bądź nie zakończyły się sukcesem – nie należy ich ignorować lub odkładać na później. Są one integralną częścią fazy tworzenia produktu i odkładane w czasie sprawią, że produkt oddany do użytku nie będzie spełniał oczekiwań klienta. Właściciel produktu, który tego nie rozumie to właściciel produktu, który powinien zostać zmieniony. Dobrze napisane testy oprogramowania lub aplikacji to dobrze rozumiany produkt. Dobrze rozumiany produkt to poprawne jego wdrożenie.

Tak więc pomimo tego, że w metodyce Scrum tester nie ma wyraźnie i formalnie określonej roli, to wykonywane przez niego zadania są integralną częścią procesu wdrożenia produktu. Oznacza to, że chociaż wprost nienazwana, rola testera jest krytyczna dla poprawności wdrożenia.

Należy również unikać tworzenia podejść hybrydowych, gdzie próbujemy wymieszać metodyki zwinne z kaskadowym modelem wdrażania oprogramowania.

Niepożądana sytuacja ma również miejsce wtedy, gdy stanowiska zdefiniowane dla modelu kaskadowego, funkcjonują nadal w Scrum, pomimo tego, że ta metodyka w ogóle ich nie przewiduje. Można to ująć w jednym haśle: „Elastyczność przede wszystkim, ale nie elastyczność mimo wszystko”.

Skontaktuj się z nami

Monika Kaczyńska
Dyrektor, PwC Polska
Tel.: +48 572 729 509
Email

Obserwuj nas