Na podstawie wielu artykułów i poradników śmiało można stwierdzić, że spośród robiących obecnie karierę metodyk zwinnych najpolpularniejszą jest SCRUM. I teraz w momencie, kiedy uświadamiamy sobie, że faktycznie wszystkie działania podporządkowane są pewnej powtarzalności i regularności w każdym projekcie – szukamy schematu i przyczyn możliwego braku dobrej oragnizacji własnej pracy. I w takim momencie warto zapoznać się z metodyką SCRUM. Dla osób, które przeniosły się z pracy w metodykach tradycyjnych do pracy w metodyce SCRUM, pierwsze działania mogą wydawać się niczym innym jak chaosem.

Agile zaskakuje takimi aspektami jak: bliska wspólpraca w zespole (programiści, architekci, testerzy, osoby ‘biznesowe’), regularne pojawianie się nowych funkcjonalności, bezpośredni sposób komunikacji, wycofanie specyfikacji wymagań w formie masy kartek, częsta zmiana wymagań, ale z umiarem który określa niezmienny budżet.

Elementy, które są szczególnie kontrowersyjne dla tradycjonalisty to: częsta – bezpośrednia komunikacja i częste nowe funkcjonalności, które chwieją mozolnie opracowaną specyfikacją i właściwie podkreślają jej zbędność.

Patrząc z innej strony można się zastanawiać, biorąc pod uwagę wszystkie wyżej wymieniane aspekty, jak wysoka będzie jakość końcowego produktu a co za tym idzie jakość stworzonego kodu. Mając na uwadzę poźniejszą rozbudowę – chaos nie bedzię tu wskazany. Przecież brakuje obszernej specyfikacji – programista wobec tego zakodzi tylko funkcjonalności po najmniejszej lini oporu. Do tego – regularnie pojawiają się nowe fukcjonalności – i tak programista pochodzący z tradycyjnych metodyk zupełnie traci głowę. Dlatego warto nabywać doświadczenie – NIE TYLKO programistyczne ale i testerskie w projektach w metodydze AGILE.

Zazwyczaj iteracje trwają od tygodnia do czterech a w tym ciągła komunikacja i współpraca. Stąd nie można być zakompleksionym w sobie, ukrytym w formie „szarej myszki” bo coś w łańcuchu zostaje przerwane. Ogniwo komunikacji wydaje się być najbardziej znaczącym. Stąd w agile konieczne są ciągłe spotkania, cykliczne rozmowy, w których każdy ma prawo wypowiedzenia się na temat zrealizownych zadań i planów przyszłej pracy.


Tutaj można skupić się już na samym SCRUM: czyli opisie ram, których należy przestrzegać w procesie prowadzenia projektu. Mamy tu zdyscyplinowanych członków zespołów, gdzie wg założeń, nie powinniśmy mieć wyraźnej roli lidera – narzucania z góry zadań. Tutaj wszyscy są tak samo równi i tak samo niezbędni w całym procesie tworzenia.

Mistrz SCRUM

W SCRUM mamy dwie role: Mistrza SCRUM – trenera, który ogrania wszystkich członków zespołu i wskazuje poprawność ram jakie definiuje SCRUM. Druga rola to Właściciel produktu – czyli ktoś, kto reprezentuje biznes.

Sprint

Projekt SCRUM składa się z iteracji które nazywane są sprintami. Na starcie jest określona ilość fukcjonalności, które implementują programiście. Na finishu sprintu mamy zaimplementowane funkcjonalności i przetetsrwane. Na koniec prezentacja dla Właściciela Produktu.

W trakcie sprintu

Muszą być organizowane praktycznie codziennie spotkania zespołu, trwające do 15 minut, gdzie każdy omawia prace jakie wykonał wczoraj, czym zajmie się dzisiaj, jakie były/są blokady i problemy. W takim spotkaniu wskazana jest obecność zarówno Mistrza jak i Właściciela produktu.

Mistrz jest ponad wszystkim.

Mistrz SCRUM nie jest to rola znana pod nazwą Kierownika Projektu, Project Managera czy Team Lidera. Mistrz dlatego, że jest mistrzem nie bierze udziały w codziennym życiu zespołu, nie będzie przypisywał zadań, kierunek nadaje Właściciel Produktu. A Mistrz obmyśla jak zespół może uzyskać najwyższą efektowność.

Tester w SCRUM

Tester ma przypadki testowe i testuje. Blisko współpracuje z całym zespołem. Samodzielnie podejmuje decyzje co, gdzie, kiedy i jak przetestować. I właśnie tutaj – w SCRUM testowanie wzrasta do dużo większej rangi niż w innych metodykach. Bo właśnie w SCRUM tester nie jest tylko odbiorcą produktu, który zwraca wynikowe testy. On bierze znaczący udział w powstawaniu konkretnych funkcjonalności. Oby nie było to wypowiedziane na wyrost ale jest tu wyraźne wrażenie, że tester ma znaczący wpływ na prace programisty, wręcz wyręcza go z obmyślania działania, wyglądu pewnych funkcjonalności. Nie chodzi tu o to żeby programista stał się ‘narzędziem’ w rękach testera – broń boże. Przecież wszyscy w zespole są równi. Jest tu też ważna zależność – w żadnym wypadku programista nie może entuzjastycznie ogłosić, że jego funkcjonalność jest zakończona, jeżeli tester jej nie przetestował.

Rywalizacja

W SCRUM poradzono sobie z rywalizacją w prosty sposób – sprowadzono wszystkich do tego samego poziomu. Testerzy są od samego początku planowania projektu (a nie tylko testują końcowy finalny produkt). Tester i programista to role w SCRUM tak samo ważne.

Testy testera w SCRUM

• regresyjne – sprawdzenie jak mają się wcześniej zaimplementowane funkcjonalności. Tutaj ze względu na czasochłonność wskazana jest częściowa automatyzacja.
  -eksploatacyjne – tutaj bierze udział cały zespół – i tak otrzymujemy szybką informację zwrotną co do nowych funkcjonalności.
• automatyczne – bo ważne jest utrzymanie dotąd zaimplementowanych funkcjonalności.
• integracyjne – weryfikują poprawność integracji nowych modułów z już istniejącymi.
• niefunkcjonalne – testy wydajności, usability, bezpieczeństwa.

Podsumowując z punktu widzenia testera wychodzi na to, że SCRUM jest COOL - i warto próbować się w nim odnaleźć, dynamicznie działać i komunikować się w zespole.

Piwo!

I teraz kiedy zauważasz, że chaos może być mozolnie wypracowaną taktyką – musisz się w niej odnależć – wszystko dla dobra produktu. Reasumując: Testerzy i programiści powinni częściej chodzić na wspólne piwo!



Źródło zdjęcia 1, 2, 3