Mai avem oare nevoie de documentație în agilitate?


documentatie in agilitateLa cursurile Agile, când ajungem la punctul “Software funcţional înaintea documentaţiei vaste”  cel mai des avem dezbateri lungi, cu păreri diferite și devine clar că pentru mulți e un punct sensibil și că au avut de suferit în legătură cu acest aspect.

Așa nu

În modul clasic de lucru, cel mai des, fiecare e responsabil doar pe realizarea unei etape, nu pe tot produsul. Analistul își pune ca obiectiv să facă specificații de calitate, dezvoltatorul – cod de calitate, testerul – teste și rapoarte de test de calitate etc. Așa ajunge dezvoltatorul să ceară analistului specificații foarte detaliate, își alocă timp să explice bine punct cu punct, încearcă să acopere din start toate scenariile posibile și imposibile, deseori ajungând să trateze multe aspecte ce nu vor ajunge niciodată să fie utilizate de utilizatorii finali. Apoi ceva similar se poate întâmpla atunci când dezvoltarea a luat sfârșit și e timpul să intervină testerul, e nevoie de a face un transfer de cunoștințe pentru toată munca făcută. Pot fi auzite replici de genul ”De ce mă întrebi, nu ai citit documentația? …vezi și tu pe la pagina 389….chiar crezi că citește cineva până acolo?”.  În așa fel, în modul clasic de lucru, se consumă o parte semnificativă de efort pentru transferul de cunoștințe și realizarea unei documentații vaste la fiecare tranziție de la o etapă la alta, până funcționalitățile ajung în producție. Când încerci să analizezi de ce a eșuat un asemenea proiect, prima reacție poate fi mirarea: hmm, fiecare în parte parcă și-a făcut treaba (de fapt a făcut treaba sau cel puțin și-a acoperit spatele). Există multe exemple în acest sens, vă invit să citiți unul interesant în articolul lui Cornel.

Dezavantajele acestei abordări sunt la suprafață: oameni supraîncărcați și demotivați, costuri ridicate de realizare, valoare redusă pentru produsul livrat, termene limită depășite, scenarii uitate, căutarea vinovaților, pedepsirea celor mici și neajutorați etc. De fapt, în asemenea cazuri, se întâmplă să putem observa o bună parte din categoriile de pierderi (waste)  identificate de Taiichi Ohno (părintele Toyota Production System).

Ce propune agilitatea?

Agilitatea nu neagă nevoia de a avea documentație. Diferența mare este în abordare. Totul pornește de la crearea unui mediu de lucru constructiv și colaborativ, în care fiecare este încurajat să comunice, să pună întrebări (uneori stupide), să propună noi idei (unele pe lângă), să fie  sau nu decacord cu alții, să facă experimente, să facă greșeli și ca urmare cu toții să învețe. Apoi, echipa poate decide să documenteze unele elemente învățate sau agreate fie pentru a nu le uita, fie pentru a simplifica transferul de cunoștințe către alte persoane. Când vor documenta, cât de mult, în ce format și alte aspecte vor fi decise de către echipă în dependență de valoarea și nevoia reală, totodată luând în calcul costul producerii și menținerii acestora.

Concluzie

Consider că documentația poate avea sens dacă este creată în urma colaborării parților implicate și nu în loc de colaborare. Strategia Just-in-Time este de mare ajutor atunci când vrem să răspundem la întrebările: ce documentație să producem? în ce cantitate? când?

Leave a comment

Adresa ta de email nu va fi publicată. Câmpurile necesare sunt marcate *


*

Poți folosi aceste etichete și atribute HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>