În continuarea articolului „Definiția unei cerințe pregătite și alte definiții”.
Mai țineți minte exemplul echipei din articolul despre estimări absolute? Multe lucruri au trebuit corectate în acel proiect, printre care și încrederea responsabilului de produs în dezvoltatori. Cu un pic de ajutor, echipa a conștientizat că cerințele erau prea vagi și prea mari, dar nu era capabilă să negocieze acest aspect. M-am documentat un pic legat de produsul lor, iar într-una din discuțiile private cu responsabilul de produs am încercat să abordez problema dintr-o altă perspectivă:
– De fiecare dată estimările cresc când intrăm în detalii, spunea responsabilul de produs.
– Diavolul este în detalii. De exemplu, să luăm cerința legată de crearea animațiilor pe baza imaginilor încărcate de utilizator. Dacă vrei ca echipa s-o implementeze în condițiile acestea … efortul este de două sau trei zile. Însă dacă vrei … și …, indiscutabil ajungem la câteva luni de muncă.
A rămas mască când a conștientizat că aveam dreptate.
Mai jos voi vorbi despre un alt caz, când responsabilul de produs vine la mine după prima ocazie de a da feedback echipei de dezvoltare pe baza muncii lor.
– Nu înțeleg. Au uitat să facă niște chestii banale.
– Crezi că au făcut-o intenționat?
– Nu. Dar nu este un semn bun.
– Crezi că dacă continui să definești cerințele la exact același nivel de detalii ca până acum, data viitoare vei obține rezultate diferite?
– Nu.
Ambele discuții au dus la stabilirea definiției unei cerințe pregătite. În mod normal, echipa de dezvoltare trebuie să fie capabilă singură să își exprime nevoia de informație și să reușească să explice responsabilului de produs cum anumite detalii din definiția unei cerințe pregătite pot împiedica finalizarea cerinței în condiții optime:
- echipa de dezvoltare decide dacă o cerință este pregătită sau nu
- echipa elaborează criteriile de evaluare a unei cerințe pregătite=>prima definiție a unei cerințe pregătite
- ca o cerință să fie pregătită ea trebuie să corespundă criteriilor INVEST, deci să poată fi testată
Pentru cei care lucrează în Kanban:
- avem o etapă cu cerințele pe care urmează să le pregătim „sugestii asumate”
- avem o etapă cu cerințele în curs de pregătire „rafinare”
- avem o etapă cu cerințele pregătite „de planificat”
- nicio cerință nepregătită nu intră în dezvoltare „de făcut”
Cei care lucrează în Scrum sunt ajutați în acest sens de către Scrum Master-ul care se va asigura că:
- nicio cerință nepregătită nu intră în iterație/sprint
- Scrum Master-ul își învață responsabilul de produs noi tehnici de definire a produsului pentru ca acesta să-și poată face treaba mai bine
- echipa de dezvoltare își ajută responsabilul de produs la pregătirea cerințelor în sesiunile de rafinare a backlogului (cu câteva zile înaintea începerii noii iterații/noului sprint) sau în momentele de planificare a iterației/sprintului
Diavolul este în detalii
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 2963 ori