Vizibilitate tuturor!

Sunt adeptul suprimării formelor fără fond cu precădere prin educație, viziune comună, focalizarea energiilor, obiectivism și foarte multă răbdare.

Diavolul este în detalii


Î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”

Kanban_pentru_IT_-_exemplu_-_Cornel_Fătulescu_-_Fără_Limite_-_Faza_de_analiză

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

definitia_unei_cerințe_pregătite2

Citește în continuare …

Diavolul este în detalii

Cornel FătulescuArticol scris de Cornel Fătulescu. Găsiți mai multe informații despre Cornel Fătulescu pe pagina membrilor AgileHub, în articolul despre mine sau la pagina de contact.

Comentarii

Comentarii