În continuarea articolului „Agilitatea este un set de valori și principii, o cultură. Agilitatea nu înseamnă Scrum sau Extreme Programming. Introducere la manifestul agil”.
Esența acestei valori este explicată cel mai simplu prin cazuri concrete. Dacă am avea de gândit o nouă ergonomie, atunci ar trebui să preferăm o întrevedere în care să schițăm ideile noastre discutând liber, decât să lucrăm fiecare în colțul lui și să schimbăm e-mail-uri între noi până ajungem la varianta convenabilă tuturor. Avem de clarificat niște specificații și ne trimitem documente cu întrebări unul altuia, noi stând de fapt la două birouri distanță. Clientul are o urgență, și programatorii nu fac nimic până nu apare și un tichet în bugtracker (Jira, Redmine, Mantis,…) sau până când nu vine cineva să le zică ce să facă și să le gestioneze ordinea sarcinilor.
Într-o zi, îmi vin doi colegi de la Chișinău să lucrăm împreună la Brașov. Unuia dintre ei i s-a stricat încărcătorul de la laptop. Merge să ceară un altul nou, iar răspunsul a fost negativ din motive administrative. În România nu se puteau face achiziții decât de la Dell, iar în Moldova doar de la HP, fiecare țară fiind reprezentată de o entitate juridică separată, și fiecare entitate juridică având propriile parteneriate cu furnizorii. Cei doi colegi veniți de la Chișinău erau obligați să lucreze unul lângă altul. Cine avea bateria mai consumată folosea încărcătorul. Însă la un moment dat nu mai aveau de ales. Amândoi urmau să fie în ședințe simultane cu potențiali clienți diferiți. Noroc că obstacolul a ajuns la urechile mele cu ceva timp înainte de catastrofă. Rezolvarea a fost foarte simplă:
- Am întrebat de ce nu putem achiziționa un încărcător HP. Mi s-a răspuns că nu avem voie.
- Am întrebat cine poate lua o decizie în acest sens. Am fost direcționat către responsabilul de departament.
- Am explicat situația responsabilului și dificultatea a fost depășită. Decizia a fost luată în mai puțin de cinci minute. Încărcătorul a ajuns într-o oră.
Exemplul de mai sus n-ar trebui să ne ducă cu gândul că procesele și uneltele nu sunt utile și trebuie eliminate, însă ar trebui să ne reevalueze poziția față de gradul de asimilare al valorilor și principiilor agile. În ceea ce ține strict de această valoare, indivizii și interacțiunea înaintea proceselor și uneltelor, încercați să vă adresați întrebările de mai jos:
- Este procesul cunoscut și respectat de toată echipa? dar uneltele?
- Este procesul instituit de echipă sau impus de management? dar uneltele?
- Va știi echipa să evalueze corect când trebuie să treacă peste reguli? la fel ca în cazul unei excepții rare ca cea de mai sus.
- Dacă echipa întâmpină o astfel de excepție, va trece peste reguli sau nu? Dacă răspunsul este nu, ce ar împiedica-o?
- Ce se întâmplă dacă procesul nu este respectat? Este cineva pedepsit sau penalizat?
- Cum se poate adapta procesul astfel încât riscul încălcării lui să fie diminuat considerabil? Poate o trecere de la proces definit la proces empiric va ajuta.
- Ce se întâmplă dacă uneltele noastre nu mai sunt funcționale? nu mai funcționează bugtracker-ul, a picat mașina de integrare continuă sau nu mai avem internet – fără să ne gândim la toate scenariile apocaliptice.
- Are echipa maturitatea necesară să execute procesul de o manieră autonomă? dar uneltele?
- Este echipa împuternicită și suficient de protejată astfel încât să aleagă singură procesul și uneltele? sau să le schimbe dacă consideră necesar?
Despre astfel de exemple am mai vorbit în seria instrumente simple.
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 2242 ori