Mina 01 - Dokumentacja: User Stories i Testy

Podstawą metodyk lekkich jest zasada "travel light", gdzie indziej wyrażana jako "eliminate waste", generalnie chodzi o to, żeby pozbywać się bagażu produktów i czynności, które powodują że proces jest ociężały i zawiera bardzo duży nakład prac okołoprojektowych, które nie skutkują krótko ani długoterminowo wartościami dodanymi dla projektu lub wartości te są mierne. Pierwszą rzeczą o której sie dowiedziałem, gdy usłyszałem o XP to było "brak dokumentacji". I tak rzeczywiście postrzegany jest ten proces przez innych. Wielokrotnie słyszałem komentarz "aha to ta metoda gdzie piszecie kod bez dokumentacji tak?" co ciekawe wypowiadany zarówno w pozytywnym jak i negatywnym kontekście.

Tak więc powszechną opinią jest, że dokumentacji w projektach agileowych powinno w zasadzie nie być per se, jej rolę mają przejąć:

• ustne przekazy
• mechanizmy społeczne takie jak pamięć grupowa
• karty wymagań (user stories), które same w sobie są "zwięzłą zapowiedzią dalszej rozmowy"
  
• ciągła komunikacja z klientem
• testy akceptacyjne - dokumentacja funkcjonalna
• testy jednostkowe oraz integracyjne - dokumentacja architektoniczna

Dla mnie jest to temat, który wygląda niewinnie ale może bardzo nieprzyjemnie się obrócić przeciw nam.


Czy taką dokumentacją "w locie" opisze się każdy kawałek skomplikowanego systemu?
Dla przykładu. W zależności od skomplikowania są potrzebne poglądowe dokumenty opisujące architekturę systemu "z lotu ptaka". Przeważnie trudno się obejść bez dokumentu wizji systemu. Trudno obejść się bez słowno-muzycznych opisów do skomplikowanych procedur logistycznych. Takie procedury oczywiście koniecznie powinny być wyrażone w postaci testów akceptacyjnych (FitNesse na przykład), lecz uważam że oprócz tabelek z możliwymi stanami systemu krótki opis danego przypadku, mocno podnosi wartość dokumentacyjną takiego testu.
Oczywiście do dyskusji jest kiedy te dokumenty mają powstać oraz jak obszerne mają być, i tutaj moim zdaniem tkwi klucz do pojęcia lekkości.


Czy wszyscy klienci grają fair i nie nadużywają procesu do niekończących się zmian
Jeśli pracujemy na kontrakt typu T&M (time & materials) to problemu nie ma, przynajmniej dla nas. Jednak większość z nas, w tym i ja, nie ma takiego luksusu. Więc tak, z jednej strony mamy proces, w którym chcemy odraczać decyzje, nie spisywać wszystkiego na papier, po prostu naszą dokumentacją i źródłem wiedzy jest nasz klient i on mówi czy w prawo czy w lewo. Super. Z drugiej zaś strony podpisaliśmy jakiś śmieszny papier, albo częściej jak to było w moim przypadku, ktoś to za mnie dawno temu zrobił i tak na prawdę to niezależnie co, ale za miesiąc to nam sie budżet na projekt skończy.
Miałem klientów, którzy to rozumieli i szło dobrze, rozumieli że jesteśmy elastyczni i nie muszą wszystkie mieć na ostatni guzik na start projektu i jak coś im się nie spodoba to będą mogli to zmienić, ale rozumieli, że jak coś wymyślą strasznego to będą musieli renegocjować, bo powyżej własnego tyłka nie podskoczymy.
Niestety spotkałem się też z brakiem takiego zrozumienia, lub może z perfidnym zrozumieniem oraz zrozumieniem jak można to wykorzystać dla własnej krótkoterminowej korzyści (tak, tak, łamiąc zasadę "repeat business"). Nie wiem, ale wolę myśleć, że jednak był to brak zrozumienia. Brak dokumentów (lub testów akceptacyjnych w ich roli) stwierdzających jak dana funkcjonalność ma działać powoduje, że zespół staje w sytuacji bez wyjścia. Odbieranie prac przez klienta na koniec iteracji i akceptacja ad-hoc też może niewiele przynieść jeśli na koniec projektu klient powie: "no dobra, a w umowie napisaliście, że będzie to to to i to".
Tak, jest to często sprawa kontraktu niedopasowanego do metodyki realizacji projektu, ale właśnie w tym jest problem. Nie pracujemy w laboratoryjnych, kontrolowanych i sterylnych warunkach, tylko w swoich firmach, gdzie cuda na kiju się dzieją. Do niedawna nie miałem żadnego wpływu na to co jest w kontraktach które podpisujemy, czy to znaczy że nie mogłem wdrażać praktyk XP? Myślę że mogłem, tylko jak zawsze, trzeba je wdrażać z głową. I nawet jak teraz mam na to wpływ to jednak nie znalazłem w sobie tyle siły perswazji, by jakiegoś klienta przekonać do T&M. Kontrakty to osobna paskudna mina, którą zajmę się później.


Czy są dostępne lekkie narzędzia wspierające ten typ dokumentacji?
Do kart wymagań używałem w zależności od uwarunkowań projektu: od białej tablicy, magnesów, kartek i mazaków przez XPlanner po Excela. Do testów akceptacyjnych od Canoo WebTest przez Selenium i FitNesse po NUnitForms. Do rozmów z klientem po prostu edytor tesktu do spisania notatek ze spotkania.
Każde z tych narzędzi jednak ma braki. Tablica jest super ale jak masz rozproszony zespół to robi się bezużyteczna. W tabelkach FitNesse super wyraża się wymagania ale napisanie warstw pośredniczących, wypracowanie DSLa, jeśli chcemy używać go do dokumentacji pochłania dużo czasu i energii.

Miało być tak lekko, a ja czasem czuje dość duży ciężar mimo wszystko.


Czy tego typu dokumentacja pokryje NFR?
Wymagania niefunkcjonalne (non-functional requirements) od zawsze są zmorą jeśli chodzi o testowanie. W szczególności zaś jeśli chodzi o zautomatyzowane testowanie z jakim mamy do czynienia tutaj. Dokumentacja w postaci testów akceptacyjnych czy integracyjnych musi w takim razie wyrazić takie aspekty niefunkcjonalne jak dostępność (np. 99,999%), jakość interfejsu użytkownika (usability) czy spełnienie określonych norm branżowych. Testami NFR zajmę się w oddzielnym temacie, więc nie będę sie rozwodził. Chciałem tylko przy tej okazji powiedzieć, że często potrzeba dokumentu, który takie wymagania po prostu w paru słowach opisze, do którego będzie się można później odnieść.


Czy pamięć grupowa rzeczywiście da radę?
Osobiście uważam że nie. Co więcej popiera to ostatnie moje doświadczenie. "Hmmm no dobra, to teraz rozbijamy te duże karty do następnego realeasu, hmmm czy ktoś pamięta co ta karta znaczyła, rozmawialiśmy o niej 2 miesiące temu." Niestety nikt nie pamiętał. Koniec tematu.


Zamiast podsumowania
Nie będę podsumowywał, bo chcę iść spać. Może coś jutro dodam jeszcze pod wpływem komentarzy, bo czuje że nie wyczerpałem tematu. Powiem tylko tak, jestem wielkim zwolennikiem bardzo lekkich form dokumentacji, najlepiej w formie testów lub przynajmniej zwięzłych notatek, powiązanych hipertekstowo, świetnie się do tego nadaje wiki. Szczególnie dobrze gra z tym FitNesse, który jednocześnie jest platformą do testów akceptacyjnych i wiki, dodam tylko że z FitNesse można z powodzeniem odpalać testy Selenium przez Selenium RC i wtedy jest full wypas. Problem z "travel light" jest taki ze nie bez przyczyny jest to "travel light" a nie "travel naked", analogicznie Mary Poppendieck mówi "eliminate waste" a nie "eliminate everything". Tylko nasz narodowy idol z Podlasia twierdzi, że "wszystko zlikwiduje", ale prezydentem nie został, więc jak widać na przykładzie podejście to jest nieskuteczne. Pytanie w takim razie jak rozeznać piernik od wiatraka to oddzielna bajka, nie na dziś.

Wstępna Lista Tematów Minolubnych

Ulegając namowie komentatorów, spisałem minogenne tematy o których już do tej pory albo pisałem wraz z Lechem Madeyskim (nota bene mam wielką nadzieje, że włączy sie do dyskusji) albo mówiłem podczas Agile Underground. Niestety systematyzacja tego zajęła mi trochę czasu i nie zdążyłem opisać pierwszej miny jak obiecałem, nadrobię to jutro.

Lista nie jest długa, ale jak zacząłem ja pisać to zacząłem rozmyślać, a to wiadomo nie prowadzi do niczego dobrego, no i nie wiadomo środek nocy sie zrobił ...

Kolejność tematów nieistotna

• dokumentacja: ustna dokumentacja, User Stories, testy
• On-Site Customer lub Whole Team
  
• praktyki XP vs. inżynieria wymagań
• wymagania niefunkcjonalne
• programowanie parami
• Test-Driven Development
• ciągłe i przyrostowe projektowanie
• współdzielony kod
• brak "manuala" do metodyk agile
• "it's about social change"
• wdrażanie praktyk XP
  
• wartości ekonomiczne
• kontrakty
• komunikacja
• plan vs. planowanie
  

Disclaimer Do Poradnika Młodego Sapera

Miny, które będę opisywał w tym cyklu dla niektórych mogą się wydawać trywialne do wykrycia, no cóż, teraz dla mnie też wiele z nich jest trywialnych, jednak większość z nich nauczyłem sie wykrywać "the hard way", więc uważam że jest pożyteczne spisanie i rozmawianie o tych prostych sprawach też, by móc później z pełnym zrozumieniem mówić o trudniejszych. My - zwolennicy metodyk lekkich - jako społeczność w Polsce nie za bardzo jeszcze istniejemy więc myślę, że takie rozmowy o podstawach się nam przydadzą.

Co więcej nie zamierzam się za bardzo rozpisywać na temat tego co zrobić z taką miną jak już się ją wykryje, z punktu widzenia tej serii najbardziej wartościowe wydaje mi się jak znaleźć taką minę, gdzie w procesie twórczym można się ich spodziewać i jakie są ich pierwsze symptomy.

Jeśli nie to to mam ogromną nadzieję, że te opisy przynajmniej oszczędzą (niektórych) problemów tym, którzy dopiero zaczynają okrywać dodane wartości tego ciągle rozwijającego się podejścia do inżynierii oprogramowania jakim jest nurt agile software development.

Prequel Poradnika Młodego Sapera

Podążając za namową uczestników iteracji pierwszej Agile Underground w Krakowie zdecydowałem się rozpocząć spisywanie i prowokowanie do dyskusji na temat problemów związanych z wprowadzaniem agile'owych praktyk w warunkach bojowych.

Zdecydowałem się zorganizować tę serię tak jak prezentację/dyskusję podczas Agile Underground. Każdy wpis będzie dotyczył jednej miny. Mina jak to mina, ma tendencję efektownie wybuchać gdy się na nią wejdzie, w czym związane są zwykle pewne obrażenia, czasem poważne, nawet krytyczne. O ile analogie w inżynierii oprogramowania do tej pory wyrządziły raczej więcej szkód niż pożytku to tę analogie uważam za trafną i nieszkodliwą. Miny, które zamierzam tutaj przedstawiać, mogą być powodem poważnych kłopotów podczas realizacji projektów, komplikacji pracy zespołów lub ich rozpadu. Niektóre takie miny są niegroźne w skutkach bezpośrednich, ale za to napsują tyle powietrza wkoło, że potem nikt nie chce słyszeć o kolejnym projekcie tymi dziwnymi metodami.

Zdecydowana większość opisów i przemyśleń bierze początek w mojej praktyce zawodowej, ale również jest owocem moich rozmów na różnych forach czy konferencjach, w szczególności z dr Lechem Madeyskim z Politechniki Wrocławskiej, moim serdecznym kolegą z którym napisałem kiedyś artykuł na konferencję, który z kolei stał się podstawą do rzeczonej prezentacji na Agile Underground.

Co bystrzejsi czytelnicy zdążyli się już zorientować, że do prowadzenia bloga wybrałem nasz język ojczysty. Przyczynę dlaczego tak wybrałem wyjawię w odpowiednim czasie ;). Wiem jednak, że będę tego żałował bo pewnie już przy pierwszym wpisie będę się skręcał wymyślając tłumaczenia angielskich sformułowań, więc bardzo proszę Was o wyrozumiałość, gdy będę po polsku odmieniał słowo agile czy bez tłumaczenia używał terminu Stand-Up Meeting czy Daily Scrum. Bo wybaczcie ale zwinny to był mój kot, dopóki mojej żony pies go nie przegonił z mieszkania. Są rzeczy, których tłumaczenia bym nie przeżył.

Pierwszy wpis obiecuję już w ten weekend. Bardzo będę się starał trzymać pewną rytmikę wpisów, bo wiem że taka regularność będzie dobra dla obu stron, jednak dziać się to raczej będzie w moim tzw. czasie wolnym, czyli gdy uśpiłem już i dzieci i żonę, a udało mi się przy tym samemu nie zasnąć. Chciałbym obiecać przynajmniej jeden wpis na 2 tygodnie. Myślę, że na tyle mogę się zadeklarować.