În continuarea articolului „Diavolul este în detalii”.
De ce avem nevoie de definiția unei cerințe finalizate am vorbit deja. La fel am vorbit și despre definiția unei iterații sau a unei livrări finalizate. Merită să mai zăbovim un pic asupra numărului de definiții. Este important de reținut că în ghidul Scrum este menționată o singură definiție atât pentru finalizarea cerințelor, cât și pentru finalizarea incrementului. Atunci când propun mai multe definiții am două motive:
- Echipa nu are experiență cu modul de lucru agil,
- Prestatorul de servicii IT trebuie să cifreze proiectul înaintea câștigării clientului.
Despre increment și produs potențial livrabil
Conform ghidului Scrum, incrementul este suma tuturor elementelor finalizate de-a lungul unei iterații și valoarea incrementelor din iterațiile anterioare. La finalul iterației, noul increment trebuie să fie „Finalizat” (Done), ceea ce înseamnă că trebuie să fie în condiții utilizabile. Toate cerințele considerate finalizate trebuie și să fie conform cu definiția unei cerințe finalizate, iar incrementul va fi conform cu definiția unei iterații finalizate. Ambele definiții sunt stabilite de echipa de dezvoltare. Incrementul trebuie să fie în condiții utilizabile – potențial livrabil – indiferent dacă responsabilul de produs cere să îl livreze sau nu.
Totul pornește de la cel de-al șaptelea din cele doisprezece principii agile: „Software-ul funcțional este principala măsură a progresului”. Deci singurul indicator al realității este confirmat de realitate. Între „funcționează pe postul de lucru al programatorului” și „funcționează în mediul de producție” se pot întâmpla foarte multe lucruri.
Echipa nu are experiență cu modul de lucru agil
Considerăm o cerință ca fiind finalizată abia când aceasta este incrementată. Lucru greu de făcut din cauza multiplelor etape prin care trebuie să treacă fiecare cerință după scrierea codului până la atestarea funcționării corecte utilizând produsul potențial livrabil. Cu cât echipa este mai agilă, cu atât ea tinde să scurteze acest ciclu fără să neglijeze calitatea. Unele echipe ajung să considere cerința ca fiind finalizată atunci când aceasta este deja în producție, reușind să facă chiar și câteva livrări pe zi. Pentru o echipă care nu a mai lucrat astfel, o asemenea performanță este de neconceput. De obicei diferența constă în practicile de inginerie și maturitatea echipei, dar și în tehnologia și soluția tehnică aleasă. Unii programatori mi-au spus că doar firme ca Google sau Facebook pot face așa ceva. Și îi înțeleg. La fel gândeam și eu până când cineva m-a ghidat la rândul meu. Dificultatea nu vine din rezistența echipei de dezvoltare ci din experiența lor. Un curs poate ajuta, însă transformarea va rămâne lentă din cauza lipsei de încredere a echipei în forțele proprii. Coach-ingul aduce rezultate mai rapid și mult mai bune în această privință.
Când metamorfoza cerințelor este prea lungă, echipa este descurajată. Toate aspectele legate de calitate încep să sune mai mult a birocrație decât a valoare adăugată. O primă consecință este identificarea activităților redundante dar absolut necesare. De exemplu: instalarea aplicației, reinițializarea bazei de date, pregătirea pentru demo, etc. Acestea vor fi realizate cel puțin o dată la finalul iterației intrând astfel în definiția unei iterații finalizate alături de alte activități precum realizarea documentației, atelierul de revizuire a arhitecturii, etc.
Sarcinile deduse din definiția unei iterații finalizate sunt dispuse pe tabla de lucru într-o zonă cu sarcini orfane – care nu țin de o cerință anume.
Transparență
Ca principiu orientativ, când lucrăm iterativ, un ciclu de metamorfoză a cerințelor în increment nu trebuie să dureze mai mult de o pătrime din durata iterației – Scrum Primar. Ar însemna că la o iterație de 2 săptămâni, 10 zile calendaristice, să rafinăm cerințele suficient de bine încât acestea să poată fi realizate sub 2.5 zile. Însă dacă ținem cont și de factorul de concentrare ciclul ar fi mult mai mic.
Prestatorul de servicii IT trebuie să cifreze proiectul înaintea câștigării clientului
Cine nu are experiență în industria software, și chiar și cei care au dar s-au îndepărtat de programare, pot subestima ușor efortul necesar creării unui produs potențial livrabil la final de fiecare iterație. Să lucrezi cu iterații de două săptămâni este ca atunci când ai avea mai multe proiecte de câte două săptămâni pe care le înșirui fără pauză între ele. Acest aspect este neglijat adesea în momentul estimărilor. Scoaterea în evidență a definițiilor este metoda care dă rezultate excelente în negocieri datorită accentului pe transparență și posibilelor discuții pe care le putem genera.
Un sprint suplimentar
O bună parte din activitățile pe care le găsim în definiția unei iterații sunt considerate un rău necesar, ele putând fi automatizate sau înlocuite în timp de altele mai utile – aceeași valoare, sau valoare adăugată mai mare, cu eforturi și timpi mai mici. Din păcate, nu toate echipele reușesc să îmbunătățească suficient de mult de-a lungul proiectului și mai au nevoie de ceea ce numim în practică definiția unei livrări finalizate. Bineînțeles că și această definiție se traduce prin alte activități suplimentare înainte de a lansa produsul. Acestea ajung să fie realizate într-un ultim sprint adițional. Noi trebuie să reținem însă că:
- indiferent de câte definiții dispunem, ele trebuie mereu văzute în ansamblul lor,
- echipele trebuie să lucreze în permanență la eliminarea răului necesar.
Ultimul sprint – un rău necesar
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 2714 ori