Am tot scris pe blog despre definiția unei cerințe pregătite, despre utilitatea și dezavantajele folosirii unui astfel de instrument, și-am să descriu în acest articol alte două motive pentru care folosirea acestei definiții poate descuraja tranziția către agilitate:

1. Folosește întrebări în loc de reguli.
2. Mai întâi realitatea, abia apoi ceea ce vă doriți.

Unul dintre dezavantajele majore în externalizarea unui proiect software constă în incapacitatea Scrum Master-ului de a-și detașa observarea și evaluarea de interesul celui care-l plătește. Pe scurt, dacă Scrum Master-ul este angajatul clientului, atunci îi va fi foarte greu să nu-și încline acțiunile în defavoarea furnizorului, și invers (mai degrabă invers, de obicei Scrum Master-ul este plătit de furnizor).

O echipă de dezvoltare software înțelege foarte repede interesul unui set de reguli care să indice clientului, responsabilului de produs dacă vorbim de Scrum, când o anumită cerință este suficient de pregătită pentru a putea fi incrementată. Acest imediat este o problemă. De fapt, înțelegerea imediată este simtomul existenței sentimentului de urgență, așa cum este le descris în Leading Change de John Kotter, dar și al frustrărilor:

• Cerințele nu sunt clare. Noi implementăm și cârpim după.
• Clientul nu știe ce vrea. Cum să meargă lucrurile bine?!
• Dacă nu avem specificații bune, ce calitate se mai așteaptă de la mine?!

Dacă dezvoltatorii continuă să gândească în acest mod, implementarea acestei definiții devine o barieră în colaborarea cu clientul (cazul 1). Însă, dacă dezvoltatorii au același scop cu clientul și reușesc să se detașeze de efectele neplăcute din cotidianul lor (cazul 2), de obicei sub influența Scrum Master-ului, atunci rezistența adoptării unei astfel de practici scade considerabil.

În primul caz, tendința echipei este să construiască o listă de constrângeri care riscă să-l sufoce pe client prin proces. Să nu mai considere nicio cerință ca fiind pregătită până când nu există cazuri de teste detaliate, design complet, etc. Aceste constrângeri pot fi utile, dar nu întotdeauna. Din zecile de exemple pe care le-am văzut anul trecut, adesea, se cere prea mult de la client și cu utilitate scăzută, prea devreme sau prea târziu. Cu alte cuvinte, echipa construiește ceea ce și-ar dori, nu face vizibil ceea ce se întâmplă în realitate. Iese din zona pragmatismului și se concentrează pe probleme. De aceea intră direct în negocieri, ceea ce întârzie adoptarea definiției în proces.

În cel de-al doilea caz, echipa face vizibilă o listă de criterii pe care ei le aplică deja în realitate. Ceea ce n-ar trebui să ducă la nicio negociere. Abia când ceva nu funcționează bine, echipa întreagă, cu clientul și dezvoltatorii, se întreabă ce-ar putea schimba în această definiție ca să-și atingă scopul unic la care s-au angajat, cu grație, rapid și ușor.

Ce trebuie să rețineți până la urmă?

• Nu folosiți definiția unei cerințe pregătite pentru a cere clientului să facă mai mult ci doar ca să faci vizibil ceea ce se întâmplă în realitate.
• Asigurați-vă mereu că întreaga echipă are același scop, știe unde se află față de acel scop și-și poate autoevalua șansele de succes.

Caz practic despre cerințe pregătite

În noiembrie 2015 am asistat la demararea unui proiect nou la Paris, într-unul dintre cele mai ambițioase și promițătoare medii de start-upuri din Europa. Clientul m-a întâmpinat cu:

– Eu nu suport procesul! Vreau să fac cum vreau. Nu am nimic cu voi, e doar o chestiune de gust.

Misiunea mea consta în a mă asigura că proiectul pornește pe baze bune, nu să-i impun un anumit proces. În diversele sesiuni de lucru în care clientul își explica intențiile și așteptările, am ascultat atent discuțiile dintre angajații noștri și ai lor. Aveau un scop comun, nu se punea problema. Toată lumea era pozitivă. Mi-am notat acele întrebări pe care și le puneau de obicei ca să se asigure că nu muncesc degeaba.

• Cum va arăta funcționalitatea?
• Cine-o va folosi?
• Cum o vei testa?
• Există ceva ce ar putea preveni echipa să finalizeze cerința? Exemplu: conturi, servicii externe, alte dependințe…
• Cum va fi implementată cerința? (listă de sarcini)
• Câte zile va dura implementarea?
• Să se testeze și pe pre-prod sau direct în prod?
• Să se testeze și pe alte navigatoare sau doar pe ultima versiune de Chrome?
• Este post-it-ul mutat în coloana „Cerințe pregătite”?

După pregătirea mai multor cerințe, i-am arătat clientului notițele mele. I-a plăcut și a apreciat. Așa se întâmplă de atunci și în continuare am înțeles că încă nu se vorbește despre proces.

Iar lista de întrebări de mai sus nu este exhaustivă. De fapt, cum ar trebui să se întâmple în cazul ideal.

Atunci când un programator primește niște sarcini, începe să-și structureze un plan de acțiune mental. Odată cu experiența, lista de întrebări pe care și le adresează înainte de a începe să muncească crește (ba chiar aș putea spune că devine prea mare, dar aceasta este o altă poveste). În mintea mea, întrebările sună de obicei în felul următor:

• Vrei butoanele aliniate la stânga sau la dreapta?
• Există deja funcționalitatea această în altă parte a aplicației? Dar ceva similar?
• Oare cum o voi implementa?
• Dacă ar fi să se întâmple ceva rău, ce-ar fi acel lucru?
• Câți utilizatori vor accesa ecranul concomitent?
• Când vrei să fie gata?
• Ce se va întâmpla rău dacă nu reușesc? Dar bun?
• Ar trebui să mai pregătim ceva suplimentar pentru conferință?
• etc.

Dacă vă doriți sistematizarea folosirii Definiției unei cerințe pregătite (Definition of ready), tot ce trebuie să faceți este să luați aceste întrebări și să le explicitați. Deci, nu uitați! Recomand

1. folosirea întrebărilor, pe cât posibil, întrebări deschise, în locul unei liste de bife care să constrângă echipa.
2. să nu treceți la negocierea acestei definiții din prima etapă.

Lecții învățate despre utilizarea Definiției unei cerințe pregătite (Definition of Ready for a feature)

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 2127 ori