TABLE OF CONTENTS:
Na początku ostrzeżenie dla wszystkich Agile/Scrum maniaków: poniższy tekst podważa sensowność stosowania czystego Scruma, przez co może spowodować nieodpartą chęć wyrządzenia krzywdy autorowi.
Na temat sposobów wprowadzenia podejścia Agile do rozwoju oprogramowania napisano tysiące książek oraz opisano setki use case’ów, które w znakomitej części kończą się happy endem i ogólną szczęśliwością.
Ja chciałbym pokazać problem z nieco innej strony, z punktu widzenia lidera zespołu ściśle testerskiego, lidera związanego emocjonalnie z testowaniem… i to testowaniem w całości projektu, obsadzonego w realiach outsourcingu. Co to zmienia w kontekście wszechobecnych poradników i jak sobie z tym poradziliśmy w Solwicie?
Mój zespół jest zespołem testerskim, czyli składa się z ludzi, którzy pragną wykonywać testy, chcą automatyzować testy, żyją tym i w tym się specjalizują. Postulat Agile mówi, że wszyscy członkowie są deweloperami, a zespół (nawet szeroko patrząc) jest interdyscyplinarny. W naszym przypadku jednak nie ma to zastosowania, bo ludzi można nazwać jak się komu podoba, ale oni nadal będą chcieli tylko i wyłącznie testować. I nie staną się interdyscyplinarni, bo nie ma takiej potrzeby projektowej. Teoretycznie można by rozwiązać team Quality Assurance, nauczyć ludzi developmentu kodu produkcyjnego, a deweloperów pisać testy, tylko jak to się może skończyć? Z mojej praktyki wynika, że źle, szczególnie gdy jedni i drudzy tego nie chcą robić… i się na tym nie znają.
Metodyka Scrum zakłada, że prace planuje się całym zespołem i razem decyduje, co zostaje przypisane do danego sprintu, oraz ocenia ile zdąży się zrobić w ramach określonej liczby Story Points.
Jak wyglądała sytuacja u nas? Timeline developmentu był rozpisany na pół roku do przodu i wskazywał jakie funkcjonalności mają zostać utworzone, a na planowaniu decydowano wyłącznie jak „szeroko” zostaną one zaimplementowane. Zespół testerski musiał się do tego dostosować i nie mógł decydować o tym, czy dany feature można „wciągnąć” do sprintu, czy nie, bo taka decyzja została już wcześniej podjęta przez biznes. Jedyną zmienną zespołu był zakres testów, który musiał być tak dobrany, aby wyrobić się w sprincie. Warto wiedzieć, że nowe testy w sprincie stanowiły do 5% już istniejącej puli (będące de facto regresją).
Do tego momentu na pewno większość „Agile Couches” nie widzi problemu, a już na pewno ma wiele pomysłów na wprowadzenie pełnego Agile i jeszcze więcej pomysłów na zabawy, które mają udowodnić, że „da się”.
Niestety w tym konkretnym wypadku „nie da się”. Dlaczego?
To skomplikowane – jako firma staramy się wspierać wszystkie inicjatywy związane z ogólnie pojętą zwinnością wytwarzania oprogramowania. Posiadamy w swoich szeregach certyfikowanych SCRUM Masterów, a i nie jeden Agile Coach by się znalazł.
Prowadzimy z naszymi klientami liczne projekty, które są wzorcowo Agilowe od samego początku, są też takie, które nie miały ze zwinnością nic wspólnego, ale dzięki rozmowom z klientem i chęci ulepszenia samego procesu, udało się nam zmienić ich oblicze na bardziej zwinne. Tak naprawdę to, jak daleko idące zmiany są możliwe, definiuje głównie poprzednie doświadczenia klienta w tym zakresie oraz jego chęć zmian w kierunku zwinności.
Natomiast w tym konkretnym projekcie, relacja klient – dostawca była ściśle określona wieloma umowami i rozliczana licznymi parametrami KPI oraz SLA. I nie wynikało to z potrzeby nadmiernej kontroli, ale raczej z braku doświadczeń w zakresie outsourcingu, a tym bardziej sposobu jego realizacji w Agile. Dlatego też umowa wykluczała istnienie jednego teamu, decydowania o tym co zostanie zrobione, a co nie.
Praktycznie nie było możliwości wpływu na proces wytwarzania oprogramowania przez klienta, a tym bardziej na harmonogram. Dla swojego spokoju ducha klient założył, że będzie początkowo sam decydował jakie testy będą wykonane oraz kiedy, pomimo, że team merytorycznie był w stanie przejąć na siebie to zadanie, tak jak ma to miejsce w innych prowadzonych przez nas projektach. Ale czy to grzech klienta? Moim zdaniem nie – każdy kto płaci za usługę, chce mieć pewność, że wszystko będzie wykonane jak należy, a na początku współpracy ciężko oczekiwać pełnego zaufania, więc nadmierna kontrola jest standardem.
W realiach tego konkretnego projektu przyszło mi się zmierzyć z pytaniami: w jaki sposób w takich warunkach być Agile? Czy da się to zrobić? Jak dać ludziom „swobodę” w działaniu oraz „decyzyjność” odnośnie tego co obecnie wykonują lub co będą robić?
Problemy trudne do rozwiązania, szczególnie, że cały czas chodziło o pracę zespołu testerskiego, gdzie jest bardzo dużo powtarzalnej pracy i bardzo trudno jest uzyskać element nowości.
Uświadomiłem sobie, że nie da się pewnych rzeczy zmienić (a przynajmniej nie od razu) tak, jakby się chciało. Podjąłem więc decyzję, że nigdy nie wprowadzimy czystego, idealnego Scruma/Kanbana, bo nie mamy takiej możliwości. Po szkoleniach zewnętrznych i bardzo burzliwych rozmowach z naszymi wewnętrznymi specjalistami od Agile, miałem już pewien zarys tych „fajnych” elementów, które chciałbym wprowadzić w zespole, aby polepszyć efektywność i po prostu uatrakcyjnić wykonywaną pracę. Był to jeden z trudniejszych, ale i najważniejszych etapów, bo miał stanowić podstawę dalszych działań. Dla mnie najważniejszym założeniem z tego etapu była chęć dania ludziom możliwości wyboru zadań jakie będą wykonywać cały czas mając na uwadze w jakim otoczeniu się znajdujemy.
Abyśmy, jako dostawca usługi, mogli decydować o tym jakie zadanie możemy wykonywać, to takie „uprawnienia” musi nam nadać klient.
To chyba najtrudniejszy etap do wykonania, bo trzeba przekonać klienta, że musi w pewnym sensie zaryzykować i pozwolić nam decydować o tym, co ma być testowane i w jaki sposób. Oczywiście taka decyzja niesie wiele plusów dla klienta, między innymi zdjęcie z niego pewnej puli obowiązków związanych z wynajętym zespołem testerskim i przeniesienie ryzyka związanego z testowaniem na vendora.
Nam udało się przekonać klienta swoją dokładną i skrupulatną pracą, jaką wykonywaliśmy wcześniej. Poprzez zgłaszane inicjatywy, daliśmy się poznać jako zespół prawdziwych specjalistów QA, którzy przede wszystkim wiedzą co robią i, co najważniejsze, dlaczego to robią. Oczywiście dla spokoju ducha managmentu, umieściliśmy w umowie dodatkowe KPI związane z procesem egzekucji testów. Natomiast najważniejszy cel został osiągnięty – mieliśmy możliwość decydowania o wykonywanych testach, a zakres testów stał się zawsze celem uzgodnień po obu stronach.
Implementacja rozwiązania. Najprzyjemniejszy etap, bo sprawdzający, czy przyjęte założenia i pomysły się sprawdziły.
Jak już wspomniałem, na początku sprintu razem z klientem określiliśmy zakres testów, biorąc pod uwagę to, co będzie implementował development.
W narzędziu Jira stworzyliśmy tablicą Kanbanową, w której w backlogu umieściliśmy taski ze wszystkimi testami do wykonania. Każdy task zawierał po kilka testów pogrupowanych tematycznie, co finalnie dało całkiem pokaźną liczbę zadań do wykonania. Co ważne, do tablicy w każdej chwili można było coś dodać lub usunąć, co dawało bardzo dużą elastyczność tak ważną w przypadku zespołu QA. Jako, że była to tablica Kanbanowa, miała ona określone limity na poszczególne kolumny statusowe, ale nie było one limitami blokującymi przepływ zadań. Miały one głównie służyć jako informacja o tym, jak jesteśmy obciążeni oraz być lampką ostrzegawczą jeśli liczba zadań zblokowanych czy „in progress” zbliża się do niebezpiecznej granicy.
Codziennie rano odbywaliśmy „daily meeting”, który był krótkim podsumowaniem tego co zostało zrobione oraz zauważone podczas wykonywania kolejnych tasków. Stanowiło to kluczowy element przekazywania informacji między zespołem. Taski wykonane, z tablicy usuwał lider zespołu potwierdzając w ten sposób, że dane zadanie zostało przez niego uznane jako prawidłowo wykonane.
Na koniec sprintu odbywała się retrospektywa – omawialiśmy napotkane problemy i szukaliśmy sposobu ich rozwiązania. Nadchodził kolejny sprint i cała przygoda zaczynała się na nowo.
Każdy członek zespołu otrzymał swobodę decydowania o tym co będzie wykonywał danego dnia, jakie testy i jakiego komponentu (bo przecież każdy z nas ma czynności które lubi, a których wolałby uniknąć).
W razie napotkanych problemów testerzy od razu wiedzieli do kogo z kolegów się zgłosić, bo bez problemu można było sprawdzić kto ostatnio robił danego taska z testami.
Dało to też element świeżości, bo odpowiednio wybierając zadania, czasem przez 3 – 4 sprinty można było nie trafić na te same testy.
Skończyło się wpisywanie „placeholderów” na planowaniu dla testerów, bo w przyjętym modelu nie było problemu z tym, aby w trakcie sprintu coś dorzucić do tablicy lub z niej usunąć.
Tablica Kanbanowa świetnie pokazywała status testowania w każdym momencie sprintu. Od razu było wiadomo co zostało przetestowane, a co jeszcze czeka w kolejce. A finalnie klient przekonał się, że można nam całkowicie zaufać w kwestii testowania i powierzył nam zdecydowaną większość decyzji z tym związanymi, co i jemu pozwoliło zaoszczędzić sporo własnego czasu.
Czy spełniamy manifest Agile? Moim zdaniem tak. Czy jest to czysty Scrum lub Kanban? Na pewno nie, to raczej hybryda, coś „pomiędzy”.
Ale czy warto robić coś tylko dla idei? Czy nie najważniejsze jest właśnie usprawnienie pracy i zwiększenie zadowolenia zespołu? Moim zdaniem na tym właśnie powinni się skupić wszyscy, którzy chcą być bardziej Agile, zamiast ślepo, na siłę wprowadzać wszystkie zasady wybranych zwinnych metodyk. Jeśli się to nie uda, to należy próbować dalej, bo przecież o to chodzi w zwinnym podejściu, aby się dostosowywać do istniejącej sytuacji i w kolejnych iteracjach osiągnąć założony cel.
