A Quick Guide to Implementing ATDD

Ten artykuł stanowi szybki przewodnik dla wszystkich zainteresowanych wdrożeniem ATDD w swoich zespołach i projektach. Przedstawia korzyści płynące z zastosowania tego podejścia Agile w oparciu o moje pierwsze doświadczenia z pracy w korporacyjnym zespole programistów.

Współpraca jest jedną z podstawowych wartości metodyki Agile. Pewnego razu, gdy pracowałem nad dużym projektem, zauważyłem brak współpracy pomiędzy programistami, testerami i osobami myślącymi biznesowo; brak jasności w wymaganiach; częste przekraczanie zakresu wymagań; brak widoczności w odniesieniu do przeprowadzonych testów; oraz defekty identyfikowane późno w cyklu życia projektu. Najważniejsze dla mnie było jednak to, że nikt nie miał pojęcia o naszym frameworku automatyzacji, więc wszystkie testy automatyzacji były pisane po tym, jak funkcjonalności były już opracowane i gotowe do testowania. W związku z tymi obserwacjami, zacząłem badać, jak ludzie radzą sobie z tego typu problemami. W rezultacie, znalazłem Acceptance Test Driven Development (ATDD) jako jedno z podejść stosowanych w celu złagodzenia wielu z tych problemów. Jest ono często używane synonimicznie z Behavior Driven Development (BDD), Story Test Driven Development (SDD) i Specification By Example (SBE). Głównym wyróżnikiem ATDD, w przeciwieństwie do innych podejść zwinnych, jest skupienie się na tym, aby programiści, testerzy, ludzie biznesu, właściciele produktu i inni interesariusze współpracowali jako jedna jednostka i tworzyli jasne zrozumienie tego, co musi być zaimplementowane.

Bazując na własnym doświadczeniu, podzielę się moimi pomysłami na to, jak zespoły mogą wdrożyć ATDD w swoich własnych projektach.

Kontekst

Pracowałem w dużej firmie, która miała mentalność startupu, więc wszelkie innowacyjne pomysły i informacje zwrotne były zachęcane przez zespół. Szybko budowaliśmy prototypy, aby sprawdzić, czy dany pomysł ulepszy nasz produkt lub pomoże w osiągnięciu nadrzędnych celów firmy. Byłem głównym testerem w 25-osobowym zespole, w skład którego wchodził jeden szef scruma, jeden lider techniczny, wielu analityków biznesowych, projektantów, programistów i testerów. W wyniku kultury innowacji, w zespole często panował chaos, w tym częste zmiany wymagań dotyczących funkcji, osoby pracujące w silosowych środowiskach i morale zespołu na bardzo niskim poziomie. Było to dla mnie niepokojące, więc zgłosiłem się na ochotnika do pomocy w znalezieniu rozwiązania tych bolączek, co doprowadziło mnie do ATDD.

Wszystkie moje nauki i doświadczenia z ATDD można podzielić na 3 poniższe kroki.

Cykl wdrażania ATDD

Wykonany przez Raj Subramanian

Krok 1 – Szkolenie i eksperymentowanie

Jest wiele sposobów podejścia do zadań, szczególnie jeśli weźmie się pod uwagę doświadczenia osób pracujących w różnych zespołach zwinnych wewnątrz i na zewnątrz ich obecnych organizacji. Aby przynieść wspólne i powszechne zrozumienie celów zespołu i organizacji, ważne jest zapewnienie odpowiedniego szkolenia. W odniesieniu do ATDD, powinno ono zawierać cele, założenia, oczekiwania oraz informacje o rezultatach, które będą wynikały z zastosowania tego podejścia. Po szkoleniu, ważne jest, aby zacząć od wdrożenia na małą skalę, aby spróbować różnych rzeczy i otrzymać iteracyjne informacje zwrotne.

Na przykład, po zbadaniu ATDD, wyjaśniłem różnym interesariuszom, dlaczego musimy zbadać to podejście i jakie korzyści otrzymalibyśmy z tego. Podkreśliłem kilka możliwych pozytywów, takich jak zwiększona współpraca w zespole, lepsze sprecyzowanie wymagań, wcześniejsza identyfikacja defektów w ramach cyklu życia rozwoju oprogramowania (SDLC), zwiększona widoczność i wcześniejsze wykorzystanie automatyzacji w SDLC, jak również zaangażowanie całego zespołu w wymyślanie jasnych kryteriów akceptacji.

Podczas mojej dyskusji z interesariuszami podkreśliłem, że będzie to wymagało pewnych eksperymentów, ale bez wypróbowania tego podejścia nigdy nie poznamy jego korzyści. Po kilku długich dyskusjach zdecydowaliśmy się podzielić pierwotny zespół 25 osób na dwa mniejsze zespoły: Zespół A składał się z 12 osób, i to on miał zaimplementować ATDD. Zespół B składał się z pozostałych 13 osób i miał kontynuować to, co już robił.

Zaplanowałem 2-dniowe warsztaty szkoleniowe dla zespołu A, ucząc się o ATDD, określając, które koncepcje mają sens w kontekście naszego projektu i jak możemy wykorzystać automatyzację w tym procesie. W szkoleniu zawarłem mieszankę ćwiczeń teoretycznych i praktycznych. Niektóre z nich znajdują się poniżej:

• Jak pisać deklaracje Gherkin – Given/When/Then (GWT)
• Jakie są kluczowe atrybuty dobrej historii użytkownika?
• Demonstracja naszego frameworka automatyzacji, włączając w to zarówno sposób jego działania, jak i strukturę. Były też ćwiczenia, jak pisać prosty kod testów automatyzacji jako zespół. Przed warsztatami, wraz z członkiem zespołu zmodyfikowaliśmy nasz framework automatyzacji, aby był zgodny z podejściem ATDD. Użyliśmy wtyczki Cucumber z Javą i Appium do naszego frameworka automatyzacji.

Źródło

Krok 2 – Zwiększenie widoczności

Kiedy projekt żyje przez wiele sprintów, łatwo jest stracić orientację w różnych procesach, które muszą być przestrzegane. Kluczem jest więc uczynienie celów, zadań i oczekiwań widocznymi dla całego zespołu.

Gdy zaczęliśmy używać ATDD, zacząłem po prostu od zapisania każdego z codziennych procesów, które będą musiały być przestrzegane na tablicy, którą umieściłem tam, gdzie nasz zespół miał swoje codzienne spotkania stand-up. Do każdej historyjki użytkownika dodałem listę kontrolną elementów, które muszą zostać wykonane, zanim historyjka zostanie uznana za kompletną. W ten sposób nie było żadnych niejasności co do tego, jakie procesy ATDD muszą być przestrzegane. Jednym z takich elementów listy kontrolnej było spotkanie początkowe, podczas którego deweloper, tester i ludzie z biznesu omawiali wymagania jako zespół, identyfikowali, które wymagania mogą być zautomatyzowane i nakreślali kryteria akceptacji historii w formacie GWT. Kolejnym elementem listy kontrolnej było QA-Dev Handoff, podczas którego deweloper pokazywał testerowi, poprzez szybkie demo lub dyskusję, w jaki sposób wymagania zostały spełnione i jakie testy jednostkowe zostały napisane jako część historyjki. Dzięki temu, tester dowiadywał się, które obszary nie zostały objęte testami jednostkowymi i lepiej rozumiał zaimplementowaną funkcję, co prowadziło do lepszego pokrycia testami. Pozycje listy kontrolnej były czasami oczywiste, ale dobrze jest mieć je jasno określone. Jedną z nich było zapewnienie, że wszystkie defekty związane z daną historią zostały zamknięte; inną było ostateczne zatwierdzenie przez osobę z biznesu po obejrzeniu dema, co zapewniało, że funkcja została zbudowana zgodnie z wcześniej ustalonymi wymaganiami i oczekiwaniami.

Zaczęliśmy również mieć „Jastrzębia Procesu”. Był to indywidualny członek zespołu; mógł to być szef scruma, kierownik projektu lub ktokolwiek, kto zapewniał, że zespół będzie postępował zgodnie z procesem. W moim przypadku był to inny starszy tester w zespole; on i ja regularnie przypominaliśmy wszystkim o przestrzeganiu procesu ATDD na wszystkich spotkaniach, włączając w to standup, planowanie, retrospektywę i inne spotkania zespołu.

Krok 3 – Iteracyjna nauka i informacja zwrotna

Ciągła pętla informacji zwrotnej jest kluczowa w implementacji każdego zwinnego podejścia, włączając w to ATDD. Organizowanie cotygodniowych lub dwutygodniowych spotkań retrospektywnych z całym zespołem jest ważnym sposobem, aby wiedzieć, które części procesu rzeczywiście przynoszą korzyści zespołowi, a które mogą wymagać modyfikacji. Jak już wiemy, coś, co nie pomaga zespołowi, prowadzi do marnowania czasu i wysiłku. Jak twierdzi Brian Tracy, autor książki „Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time”, „Jednym z najgorszych sposobów wykorzystania czasu jest robienie czegoś bardzo dobrze, co wcale nie musi być zrobione.”

W obecnej erze technologii informacyjnych, organizacje nie mogą sobie pozwolić na marnowanie czasu i energii na nieefektywne podejścia; potrzebujemy raczej szczupłych i efektywnych procesów. Wiąże się to z zasadą lean startup Validated Learning: cykl Build, Measure, Learn.

Mając to na uwadze, zacząłem organizować 30-minutowe spotkania w każdy czwartek z zespołem A, aby sprawdzić, jak zespół radzi sobie z nowym procesem. Był to dobry sposób, aby ocenić, jakie zmiany należy wprowadzić w oparciu o reakcje zespołu. Spotkania te odbywały się niezależnie od spotkań retrospektywnych, które miały miejsce na koniec 2-tygodniowych sprintów. Takie podejście przyniosło ciągłą informację zwrotną od zespołu, co pozwoliło nam na wprowadzenie natychmiastowych i skutecznych zmian. Informacje zwrotne pochodziły nie tylko z cotygodniowych spotkań kontrolnych procesu; codzienne spotkania stand-up również okazały się cennym źródłem informacji. Aktualizacje i dyskusje poszczególnych członków zespołu ujawniły czerwone flagi związane z procesem, a my byliśmy w stanie natychmiast się nimi zająć, zanim wpłynęły na resztę zespołu.

Podsumowanie

W wyniku zastosowania cyklu wdrożenia ATDD, Zespół A zaczął dostrzegać znaczące różnice w morale zespołu, współpracy i wymaganiach.

Morale zespołu

Wszyscy zaczęli pracować jako zespół i poczuli się wzmocnieni. Każda osoba była właścicielem historii od początku do końca. Upewnił się, że historia posiada wszystkie niezbędne informacje do rozpoczęcia prac rozwojowych i testowych. Członek zespołu upewniał się również, że wszystkie czynności związane z historią zostały wykonane. Wreszcie, osoba ta była odpowiedzialna za zaprezentowanie historii wszystkim interesariuszom na koniec sprintu. To poczucie własności znacząco podniosło morale zespołu.

Współpraca

Spotkania inauguracyjne zgromadziły razem osobę odpowiedzialną za biznes, programistę i testera, w celu wypracowania wspólnego zrozumienia historii użytkownika. Spotkanie QA-Dev Handoff, które miało miejsce przed wysłaniem builda na serwery QA, pomogło deweloperowi i testerowi dowiedzieć się, jakie testy zostaną wykonane w ramach historii i przyniosło lepsze zrozumienie wdrażanej funkcjonalności. Zwiększona została widoczność automatyzacji, ponieważ cały zespół przejął odpowiedzialność, a nie tylko testerzy. Wreszcie, podczas spotkań planistycznych, cały zespół omawiał historię razem, generując w ten sposób więcej pomysłów, pytań i dyskusji. Zwiększona współpraca doprowadziła również do zwiększenia ilości nauki – zespół zdecydował się na sesje coachingowe peer-to-peer, aby uczyć się od siebie nawzajem, testerzy zaczęli przeprowadzać sparowane testy eksploracyjne, a sesje lunch-n-learn były organizowane przez różnych członków zespołu w celu omówienia różnych tematów dotyczących technologii. Wszystkie te rzeczy doprowadziły do poprawy ogólnej współpracy w zespole.

Wymagania

Jednym z głównych problemów w naszych poprzednich procesach były częste zmiany wymagań i rozrastanie się zakresu. W podejściu ATDD konieczne było, aby po rozpoczęciu pracy nad historyjką, wymagania zostały zablokowane. Wszelkie zmiany muszą być traktowane priorytetowo wraz z innymi nadchodzącymi historiami i dodawane do nadchodzących sprintów. Zmniejszyło to obciążenie zarówno programistów, jak i testerów, a także zapobiegło nierealistycznym oczekiwaniom interesariuszy co do ukończonych funkcji.

Po zaobserwowaniu wszystkich powyższych usprawnień Zespół B również zaczął wdrażać ATDD. W rezultacie, cały oryginalny zespół używał tego podejścia po regularnych eksperymentach i informacjach zwrotnych.

Wnioski

Polecam podejście ATDD, które jest zgodne z „Paradygmatem przesunięcia w lewo”, który mówi, że rozwój i testowanie powinny rozpocząć się tak wcześnie, jak to możliwe w SDLC. Przyniosło to większą widoczność automatyzacji, ponieważ zaczęliśmy pisać testy automatyczne na początku SDLC, co z kolei zwiększyło współpracę w zespole.

Źródło

Pamiętaj, ATDD nie jest rozwiązaniem „uniwersalnym”. Było to podejście zwinne, które miało największy sens w kontekście mojego projektu, ale istnieje wiele innych sposobów na poprawę procesów w zespołach. Użyłem tego podejścia ze względu na nacisk na lepsze testy akceptacyjne, ale co ważniejsze, ze względu na nacisk na współpracę. Współpraca jest integralną częścią tego podejścia i uważam, że jest najbardziej wartościowa.

O autorze

Raj Subrameyer jest strategiem kariery w branży technologicznej, koncentrującym się na pomaganiu ludziom w znalezieniu wymarzonej pracy i osiągnięciu sukcesu jako lider. Pasjonuje się prowadzeniem profesjonalistów, aby zmaksymalizować ich możliwości i odkryć ich strefę geniuszu. Wykorzystuje swoje doświadczenie w branży technologicznej, aby badać, mówić i pisać o tym, jak możemy korzystać z technologii i stać się pełnoprawnymi obywatelami cyfrowymi. Jest rozchwytywanym prelegentem na różnych konferencjach i pojawiał się w licznych podcastach i publikacjach, w tym CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success i The Good Men Project. Jest również autorem nowej książki – „Skyrocket Your Career”. Jego obszary specjalizacji obejmują rozwój kariery, przywództwo, motywację, produktywność i przedsiębiorczość. W wolnym czasie uwielbia podróżować i delektować się piwem rzemieślniczym. Więcej informacji o tym jak służy ludziom można znaleźć na jego stronie internetowej.