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.

Agilitatea este un set de valori și principii, o cultură. Agilitatea nu înseamnă Scrum sau Extreme Programming. Introducere la manifestul agil.

Recent am avut o discuție pe Facebook legată de aceleași neînțelegeri despre ce înseamnă să fii agil. Discuția roia în jurul articolului lui Robert Martin despre adevărata corupție a agilității. Robert susține că agilitatea este o cultură exprimată printr-un set de practici, contrazicându-l astfel pe Allen Holub, și nu numai, care scrisese că agilitatea este o cultură, nu un set de practici. Este important de reținut că până aici amândoi recunosc agilitatea ca fiind o cultură, nu o metodologie.

Termenul de agil și noțiunea de dezvoltare agilă de software au apărut împreună cu manifestul agil publicat în 11-13 februarie 2001 și neschimbat de atunci. Autorii, autointitulați anarhiștii organizaționali ai epocii, reprezentau diferitele cadre de lucru cunoscute deja la acea vreme, acum considerate ca fiind agile: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, sau simpatizau cu ideea unei alternative la dezvoltarea software caracterizată de documentație excesivă și de procese greoaie.

Eu am auzit de manifest la mult timp după apariția sa, mai precis prin 2005. La fel ca orice ținea de valori, cultură organizațională și leadership, le-am parcurs rapid, n-am înțeles nimic și am trecut mai departe. Nici acum nu sunt multe organizații în România care să-și fi oficializat un sistem de valori pe care să-l conștientizeze și să-l încarneze în activitățile zilnice. Lipsa de încredere a românilor într-o astfel de abordare este obstacolul major în adopția unui management bazat pe o cultură organizațională, implicit și în leadership sau în adopția agilității.

Despre practicile agile

Din punctul meu de vedere, agilitatea este o cultură care se reflectă și printr-un set de practici. Însă doar aplicarea acelor practici nu ne face automat agili. Motiv pentru care nu sunt de acord cu articolul unchiului Bob. Aceste practici evoluează odată cu trecerea timpului. În 2001 nu se vorbea despre behavior-driven development, practică ce-și găsește originile în TDD și care a fost îmbrățișată imediat de comunitatea agilă. Asta nu-i face pe cei care practicau XP, Scrum sau DSMD, mai puțin agili decât sunt astăzi. La fel :

  • nici cei care estimează în valori absolute nu sunt mai puțini agili decât cei care estimează în valori relative,
  • nici cei care folosesc o tablă virtuală de vizualizare a progresului nu sunt mai puțin agili decât cei care folosesc un tablou fizic lipit pe perete,
  • nici cei care lucrează bazându-se pe cadrul Kanban nu sunt mai puțin agili decât cei care folosesc cadrul Scrum,
  • nici cei care folosesc use case nu sunt mai puțin agili decât cei care folosesc user story,
  • etc.

Lista cu exemple de practici de inginerie fără de care putem fi agili în continuare putea crește foarte mult. Înainte să folosim orice practică este bine să ne punem următoarele întrebări:

  • de ce folosim practica X și nu practica Y?
  • care sunt avantajele? dar dezavantajele?
  • am încercat și …?

Însă pot fi de acord cu, Martin Fowler, care, mai puțin incisiv decât Robert Martin, ne aduce aminte că nu se poate Scrum fără valorile și principiile agile și că în timpul tranziției către Scrum n-ar trebui să neglijăm cel de-al nouălea principiu din manifestul agil: Atenția continuă pentru excelentă tehnică și design bun îmbunătățește agilitatea.

Nu este vorba doar de practici

Efectele asimilării corecte a valorilor și principiilor agile nu sunt reprezentate doar de practicile de inginerie utilizate de o echipă de dezvoltare. Nu degeaba în Scrum rolurile sunt definite precis. S-a constatat că organizațiile agile au suferit schimbări profunde

  • în strategie,
  • în structură,
  • în procese,
  • în sistemul de recompense și
  • în politicile de resurse umane.

Astfel, mereu când se vorbește de tranziția către agilitate, Craig Larman, Mike Cohn, Jeff Sutherland – doar ca să dau câteva nume cu rezonanță, vorbesc de abordările concomitente:

  • atât de sus în jos (top-down),
  • cât și de jos în sus (bottom-up).

O echipă va fi mereu limitată în adopția agilității de organizația din care face parte.

Mai degrabă să fim agili decât să practicăm agilitatea

În cartea Scaling Lean & Agile Development, există un capitol numit „să fii agil”. Pornind de la motto-ul „Be agile  rather than do agile”, Craig Larman explică:

„Agilitatea” nu înseamnă o practică. Este calitatea organizației și a oamenilor săi

  • să se poată adapta,
  • să fie receptivi,
  • să învețe în continuu și
  • să evolueze.

– să fie agili, având ca obiectiv succesul competitiv în afaceri și livrarea rapidă a produselor și cunoștințelor valoroase din punct de vedere economic. Agilitatea nu poate fi practicată de unul singur, deși este o neînțelegere des întâlnită cum că s-ar putea. Astfel de neînțelegeri sunt legate de ideea că agilitatea înseamnă mod de lucru iterativ sau XP.

Un grup care lucrează la un produs poate practica Scrum sau XP – metodologii concrete. Și pot să utilizeze practici care să încurajeze agilitatea – practicile agile. Dar grupul poate doar să fie agil sau doar să nu fie.

Agilitatea nu înseamnă să livrezi mai repede. Agilitatea nu înseamnă mai puține defecte sau calitate ridicată. Agilitatea nu înseamnă productivitate mai mare. Agilitatea înseamnă să fii agil – abilitatea de a te mișca cu grație, rapid și ușor, să fii sprinten și să te poți adapta. Să îmbrățișezi schimbarea și să devii maestru al schimbării – să întregești prin adaptabilitate, fiind capabil să schimbi mai repede decât pot concurenții.

În plus, este vital să înțelegem că agilitatea organizațională nu poate fi atinsă doar de o echipă de dezvoltare izolată. Este o provocare a sistemului de redefinire a organizației.

Și continuă așa până la manifestul agil și valorile și principiile definite în acesta.

Dezvoltarea agilă este bazată pe un set de valori – nu de practici – care suportă și încurajează ceea ce înseamnă să fii agil.

Craig Larman nu uită să menționeze valorile Scrum și principiile managementului agil, dar care nu fac parte din scopul acestui articol și despre care voi vorbi în altă zi.

Aceleași idei le-am dezbătut și eu în articolul „Gânduri despre agilitate”.

Manifestul pentru dezvoltarea agilă de software

Putem verifica cât suntem de agili revenind regulat la valorile și principiile descrise în acest manifest și întrebându-ne dacă suntem aliniați întocmai.

Cele patru valori din manifestul pentru dezvoltarea agilă de software

Noi scoatem la iveală modalități mai bune de dezvoltare de software prin experiență proprie și ajutându-i pe ceilalți.
Prin această activitate am ajuns să apreciem:

  1. Indivizii și interacțiunea înaintea proceselor și uneltelor
  2. Software funcțional înaintea documentației vaste
  3. Colaborarea cu clientul înaintea negocierii contractuale
  4. Receptivitatea la schimbare înaintea urmăririi unui plan

Cu alte cuvinte, deși există valoare în elementele din dreapta, le apreciem mai mult pe cele din stânga.

Cele 12 principii ale manifestului

Noi urmăm aceste principii:

  1. Prioritatea noastră este satisfacţia clientului prin livrarea rapidă şi continuă de software valoros.
  2. Schimbarea cerinţelor este binevenită chiar şi într-o fază avansată a dezvoltării. Procesele agile valorifică schimbarea în avantajul competitiv al clientului.
  3. Livrarea de software funcţional se face frecvent, de preferinţă la intervale de timp cât mai mici, de la câteva săptămâni la câteva luni.
  4. Oamenii de afaceri şi dezvoltatorii trebuie să colaboreze zilnic pe parcursul proiectului.
  5. Construieşte proiecte în jurul oamenilor motivaţi. Oferă-le mediul propice şi suportul necesar şi ai încredere că obiectivele vor fi atinse.
  6. Cea mai eficientă metodă de a transmite informaţii înspre şi în interiorul echipei de dezvoltare este comunicarea faţă în faţă.
  7. Software funcţional este principala măsură a progresului.
  8. Procesele agile promovează dezvoltarea durabilă. Sponsorii, dezvoltatorii şi utilizatorii trebuie să poată menţine un ritm constant pe termen nedefinit.
  9. Atenţia continuă pentru excelenţă tehnică şi design bun îmbunătăţeşte agilitatea.
  10. Simplitatea–arta de a maximiza cantitatea de muncă nerealizată–este esenţială.
  11. Cele mai bune arhitecturi, cerinţe şi design emerg din echipe care se auto-organizează.
  12. La intervale regulate, echipa reflectă la cum să devină mai eficientă, apoi îşi adaptează şi ajustează comportamentul în consecinţă.

Valorile și principiile de mai sus sunt extrase din manifestul pentru dezvoltarea agilă de software publicat la adresa http://agilemanifesto.org/iso/ro/

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice

Tranziția către agilitate

Nu știu cine zicea că agilitatea este o călătorie nu o destinație, dar mare dreptate avea. Mike Cohn a scris recent un articol: adevărata cale să fii agil. El nu vine cu un răspuns ferm, dar crede că adevărata cale să fii agil ar putea fi cea care funcționează cel mai bine pentru echipă. În comentarii se abordează chiar și ideea compromisurilor din partea unei echipe din organizație pentru binele suprem: organizația să fie agilă.

Dacă totul era atât de simplu, toate organizațiile erau deja agile.

Concluzie

Deci, cum răspundem la întrebarea: Ce este agilitatea? Corect, este un set de valori și principii, o cultură.

Agilitatea_este_un_set_de_valori_și_principii,_o_cultură

Agilitatea este un set de valori și principii, o cultură. Agilitatea nu înseamnă Scrum sau Extreme Programming. Introducere la manifestul agil.

Cornel FătulescuDacă 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 5032 ori