User Acceptance Tests

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.

"Zwinna" dokumentacja

Niejednokrotnie gdy rozmawiałem na temat metod zwinnych zarządzania projektami IT pojawiały się sugestie, że metody te to "wolna amerykanka" nie do zastosowania w "poważnych" sytuacjach. Jako jeden z głównych powodów podawano dokumentację. Od osób, z którymi rozmawiałem dowiadywałem się najczęściej, że metody zwinne zakładają brak dokumentacji projektu. Nic bardziej błędnego.

Metody zwinne (niektóre, żeby być całkowicie zgodnym z prawdą) zakładają brak zbędnej dokumentacji projektu. Ale żadna nie zakłada zrezygnowania całkowicie z dokumentacji. Wręcz przeciwnie, z tego co zauważyłem projekty realizowane metodami zwinnymi są dużo lepiej udokumentowane niż projekty prowadzone metodami standardowymi. Dlaczego? Hmm, żeby odpowiedzieć w pełni trzeba zacząć od zastanowienia się dlaczego dokumentacja (głównie techniczna wykonawcza) stanowi piętę achillesową wielu projektów w IT. Z mojego doświadczenia i rozmów z projektantami/programistami wynika, że wytłumaczenie braku dokumentacji lub jej szczątkowości jest następujące:

1. Bo nam się nie chciało, co można rozbić na:
1. Bo to jest za trudne
2. Bo nie wiem po co to pisać
2. Bo nie było czasu

Zastanówmy się nad przyczynami źródłowymi tych tłumaczeń i jak one wyglądają z punktu widzenia metod zwinnych.

1.1 Bo to jest za trudne. Trudne? Jakim cudem dla programisty, który pisze kod może być trudne pisanie dokumentacji do tego, co sam stworzył? To by przecież oznaczało, że nie wie co pisał??? No cóż, nie zawsze. Przyczyna może być bowiem również taka, że dokumentacja jest pisana dużo później niż sam kod. To dość częsty przypadek, kiedy kierownik projektu najpierw naciska na jak najszybsze skończenie pracy programistycznej a potem, po 6 miesiącach, kiedy software poszedł właśnie do testów i programiści nie za bardzo mają co robić rzucane jest hasło "to teraz dokumentujemy nasz kod". Faktycznie, pisanie dokumentacji do kodu pisanego 6 miesięcy wcześniej i wielokrotnie później przerabianego jest trudne. Jeżeli nie niemożliwe. W przypadku metod zwinnych kierownik projektu jest ograniczony jedną iteracją, czyli maksymalnie ośmioma tygodniami, w większości przypadków czterema. To oznacza, że programista nigdy nie będzie komentował kodu starszego niż średnio 4 tygodnie. Oczywiste jest, że będzie to dużo łatwiejsze. A w połączeniu z następnym punktem stanie się wręcz niezbędne.

1.2 Bo nie wiem po co to pisać. Duży uśmiech :-) W większości przypadków i projektów zarządzanych standardowo faktycznie programiści nie wiedzieli po co ta dokumentacja. Odgórne zarządzenie "teraz piszemy dokumentację techniczną" przychodziło zwykle w momencie kiedy system był już skończony. Co więcej przy założeniu, że to system pod konkretnego klienta i konkretne wymagania po co w takim momencie pisać dokumentację, skoro robota jest skończona? Z punktu widzenia programisty strata czasu. W przypadku metod zwinnych sprawa staje na głowie. Po pierwsze średnio co 4 tygodnie ma się ukazać gotowa wersja systemu. Łącznie z dokumentacją. Co już stanowi motywację do jej pisania. Jeszcze lepszą motywacją jest to, że w metodach zwinnych programista nie wie, co będzie realizował w kolejnej i następnych iteracjach. Skutkiem czego nigdy nie jest pewny kiedy będzie musiał wrócić do fragmentu kodu, który właśnie skończył pisać. To powoduje, że sam programista ma wielką motywację do pisania dokumentacji, dlatego że robiąc to robi dobrze sobie a nie kierownikowi czy komukolwiek innemu. Doświadczenie wskazuje, że najlepiej aby każdy z programistów na własnej skórze zobaczył co to znaczy pracować w n-tej iteracji na nieopisanym kawałku kodu stworzonym w iteracji n-3. Trochę kosztowny sposób nauki, ale skuteczność jest rewelacyjna. Po jednym takim przypadku nigdy nie będzie więcej problemów aby ten konkretny człowiek opisał to co robi.

2. Bo nie było czasu. Tu sprawa jest najbardziej skomplikowana. Co to znaczy, że nie było czasu? Projekt był źle oszacowany. Albo źle oszacowano czas trwania zadań i dokumentacja jako najmniej ważny element została pominięta w celu terminowego skończenia funkcjonalności (co ciekawe mówią tak te same osoby, które zarzucają zwinnym metodom, że są złe bo nie ma dokumentacji). Albo sytuacja jest jeszcze gorsza i w ogóle nie wzięto pod uwagę czasu potrzebnego na wykonanie dokumentacji technicznej. Metody zwinne w prosty sposób nie pomogą, ale zwykle pomagają nie-wprost. Po pierwsze są krótkie iteracje z rozbiciem na zadania. W związku z tym łatwiej jest pokazać czas przeznaczony na pisanie dokumentacji i nikt zwykle nie ma wątpliwości, że to tam powinno się znaleźć. Łatwiej jest bowiem dodawać po 2 dni na aktualizację dokumentacji do każdej z 10 iteracji, każda trwająca po 4 tygodnie niż z 10-cio miesięcznego projektu jeden miesiąc roboczy (20 dni) przeznaczyć na dokumentację. Po drugie natomiast i ważniejsze z powodów opisanych w poprzednim akapicie sami programiści, czyli osoby wykonujące zadania będą miały dużą motywację do pisania dokumentacji i sami nie pozwolą kierownikowi zapomnieć o tym aspekcie. Oczywiście działając z bardzo niskich pobudek, bo dla ułatwienia sobie pracy, ale czy to ważne?

Podsumowując metody zwinne systemowo ułatwiają pisanie dokumentacji. Nie wymuszają, ale ułatwiają. I tak za stan dokumentacji na koniec projektu odpowiada kierownik. Bez jego zdecydowanych działań, ustalenia z zespołem jasnych reguł i ich późniejszego egzekwowania rezultaty będą dużo poniżej oczekiwań. Moje doświadczenie wskazuje, że projekty realizowane zgodnie z metodami zwinnymi były najlepiej udokumentowanymi jakie widziałem. Do tego stopnia, że ostatnio jak przekazywaliśmy do innego zespołu pewien projekt (niezbyt duży, jakieś 4000 roboczogodzin) razem z dokumentacją zrealizowany czystym SCRUMem okazało się, że w okresie wsparcia (2 miesiące) nie dostaliśmy ani jednego pytania dotyczącego kodu czy też spraw wykonawczych.


PS. Cały czas w tym wpisie mowa była o tzw. technicznej dokumentacji wykonawczej i zdecydowanie uwagi powyższe nie dotyczyły np. dokumentacji użytkownika.