În continuarea articolului „Indivizii și interacțiunea înaintea proceselor și uneltelor”.
Exemplul din utilitatea documentației este unul fericit. Am auzit de proiecte în care s-a lucrat un an de zile doar la specificații. A rezultat un document de mai mult de trei mii de pagini pe care nimeni n-a putut să-l revizuiască integral. Acest lucru n-a împiedicat însă pe nimeni să valideze specificațiile și să le estimeze. Proiectul a fost un eșec lamentabil.
Cu toate acestea, într-un proiect avem nevoie de informații, și adesea vrem:
- să nu le pierdem,
- să putem reveni asupra lor,
- să le revizuim,
- să le putem arhiva și
- vrem să fie accesibile tuturor indiferent de barierele fizice care pot exista între membrii echipei.
Când spunem Software funcțional înaintea documentației vaste, înțelegem să nu facem mai multă documentație decât avem nevoie și să nu uităm că aspectul central al proiectul trebuie să rămână produsul software pe care îl dezvoltăm, documentația nefiind un scop în sine.
Obiectele de hotar
Deseori încercăm să folosim documentele ca obiecte de hotar sau chiar contracte între client și furnizor, între echipe, între departamente sau între indivizii aceluiași grup. Într-o oarecare măsură, obiectele de hotar sunt mereu expresia hegemoniei – Isto Huvila, și ar trebui adaptate la nevoile tuturor părților implicate în proiect. În organizațiile non-agile, rareori se întâmplă ca echipa să-și decidă nivelul de documentație, acesta fiind impus de forțe exterioare.
Frica și încrederea
Documentația abundentă poate fi simptomul unei organizații bolnave, unde frica și stresul sunt la ele acasă. Nu rareori mi s-a întâmplat să văd membrii unui grup, că nu poate fi vorba de o echipă, ascunzându-se în spatele documentației.
Utilitatea documentației
Orice sarcină realizată de echipă trebuie să aibă utilitate. Utilitatea poate fi calculată la fel ca rentabilitatea unei investiții (Return on investment), adică raportul dintre valoarea adusă și efortul necesar producerii ei. Orice document trebuie să aducă o utilitate mai mare decât toate celelalte sarcini rămase de făcut în acel moment.
O chestiune de practici și de unelte
Organizațiile certificate ISO sau CMMi, unde procesele primează oamenilor și indirect utilității, capitalizarea chițibușurilor duce la documentație excesivă. Acest aspect contravine agilității. Partea bună este că uneltele au evoluat atât de mult încât multe din exigențele acestor norme sunt tratate implicit. De exemplu, trasabilitatea cerințelor este realizată automat atunci când folosim Jira, Redmine și multe alte unelte similare, BDD-ul (Behaviour driven development), dincolo de avantajele centrale, poate veni ca un complement în acest sens, ș.a.m.d.
Progresul
Principalul indicator al progresului este software-ul funcțional confirmat de realitate. Realizarea specificațiilor înseamnă progres 0. Până când nu livrăm măcar o funcționalitate clientului, riscăm să trăim o iluzie. Inspectarea produsului real ca principala măsură a progresului ne va forța încet-încet să renunțăm la gradul ridicat de documentație. Din păcate, managementul tradițional arată slăbiciuni în acest sens. Ca în exemplul cu care mi-am început articolul, timp de un an de zile, cineva arăta celor interesați că se avansează conform planului. Noul produs nici nu-și începuse existența până nu s-au considerat specificațiile gata. Mai trist a fost că în timpul dezvoltării și-au dat seama de tot felul de inadvertențe și inconsistențe. Abia în această etapă, când s-au pus la masă analiștii de business cu dezvoltatorii și cu tester-ii, făceau specificații adevărate. O grămadă de bani aruncați pe fereastră! Despre acest aspect am mai vorbit și în articolul în grafic.
Controlul
Rapoartele de activitate sunt o practică învechită, cu puțină valoarea adăugată și scot în evidență managementul precar. Majoritatea uneltelor sunt capabile să reconstituie munca și sarcinile destul de ușor pe baza istoricului înregistrat în sistem. Însă aici apar alte probleme:
– Păi, uite că nu fac 8 ore pe zi! îmi zice un manager de echipă.
– Așa este, probabil că au raportat timpul real.
– Noi facturăm zile întregi la client!
– Tot ce contează este cât s-a făcut în unitatea de timp (iterație), adică capacitatea reală a echipei. Pentru acest lucru n-ai nevoie de timp raportat. Vezi cât se acceptă la final de iterație. Clientul la rândul lui asta va plăti. Cerând echipei să mintă sau să muncească mai mult astfel încât să raporteze 8 ore pe zi nu faci decât să pierzi vizibilitatea pe care o ai acum și/sau să strici transparența cu clientul. Clientul trebuie să accepte că nu plătește rezultatul, ci ziua de muncă. Și noi ne plătim angajații la fel.
Verificatul timpului consumat amplifică iluzia controlului. În realitate, tot ce vom obține este un raport cu 8 ore pe zi, când toată lumea acceptă tacit că nimeni nu lucrează la foc automat, fără măcar o pauză pe zi. Nu este niciun manager mai în control când se uită peste rapoartele de activitate. Am mai scris despre asta și în articolul Antecedente, consecințe, penalizări și managementul performanței. Tot ce fac rapoartele de activitate la minut este să deformeze realitatea și să pună presiune inutilă pe echipă.
Experiența
Un alt motiv, deloc de neglijat, din cauza căruia apare surplusul de documentație în loc să privilegiem software-ului funcțional este lipsa experienței. S-ar putea să ne fie mai simplu așa, să nu știm că se poate face și altfel, etc. Ca să declanșăm acel gând de schimbare în mintea colectivă am putea întreba dacă ei s-ar plăti pe ei pentru ceea ce fac. Care-s activitățile pe care le-ar plăti dacă s-ar pune în pielea clientului? Exercițiul se termină mereu cu idei noi de ameliorare a modului de lucru.
Simplitatea
Întreaga serie instrumente simple este dedicată acestui principiu. Din motive diverse căutăm soluții complexe când în jurul nostru sunt multe soluții simple și plăcute. În momentul în care nu putem înțelege singuri și ușor situația proiectului, unde suntem, care sunt obstacolele și ce ne rămâne de făcut vom născoci tot felul de indicatori și rapoarte care să compenseze aceste lipsuri.
Gestiunea de anomalii și de defecte
Specificațiile stufoase nu fac decât să ascundă problemele și interdependența dintre funcționalități. Privilegierea software-ului funcțional, faptul că ne dorim să livrăm frecvent, des și la intervale regulate, ne obligă să decupăm perimetrul funcțional în cerințe INVEST. Orice problemă este identificată rapid și rezolvată. Însă atunci când trebuie să implementăm cerințele descrise într-un document de specificații pe o perioadă de 3 luni de zile nu vom mai ști de unde vin defectele. Vom fi nevoiți să creăm un subproces de gestiunea anomaliilor și a defectelor.
Inspecția
În câteva proiecte, care teoretic urmăreau principiile, în niciun caz modelul, dezvoltării în V, am apucat să văd scrierea cazurilor de test în paralel cu dezvoltarea. Adică programatorii primeau niște specificații ca date de intrare în etapa de dezvoltare, iar în paralel, tester-ii balotau cazuri de test. La final, cele două procese se întâlneau, sau mai bine zis, se bușeau. După mulți manageri, asta era treaba tester-ilor, să-i surprindă cu noi perspective pe dezvoltatori. Eu m-aș supăra să-mi fie criticată munca pe baza unor criterii stabilite în timpul jocului. Culmea, se pare că mai toată lumea pare deranjată de o astfel de abordare. Există o regulă nescrisă: nu avem așteptări și muncă ascunsă. Cerințele sunt pregătite înainte să începem dezvoltarea lor. Dacă cerințele necesită cazuri de teste pentru a fi implementate corect, atunci definim aceste cazuri de test înainte de a le considera pregătite de implementare.
Software funcţional înaintea documentaţiei vaste este probabil și cea mai controversată valoare relativă din manifestul agil. Și eu am crezut la un moment dat că agilitatea înseamnă să lucrezi fără documentație și încă aud această interpretare. A generat multe dispute și neînțelegeri. Drept urmare, voi mai reveni asupra acestui subiect.
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 2628 ori