În 2001, un grup de oameni nemulțumiți de starea lucrurilor din industria de software development s-a adunat într-o stațiune de schi din Utah. Dintr-una în alta, au ajuns să discute despre metodele industriale aplicate la vremea respectivă pentru gestiunea programatorilor și despre metodele așa-numite lightweight pe care mulți dintre ei le foloseau informal. Rezultatul acestei întâlniri, cum probabil știți, a fost The Agile Manifesto.
Conversațiile despre Agile Manifesto se concentrează de obicei pe conținut. Dar ce putem spune despre autori?
Acestea sunt doar câteva nume din lista de autori. Ceea ce putem observa este că fiecare dintre ei avea o baza solidă în programare, inclusiv pe proiecte foarte complexe.
Astăzi agile este cel mai adesea considerat sinonim cu Scrum, fiind cea mai răspândită metodă agilă. Pe bună dreptate: Scrum poate îmbunătăți productivitatea unei echipe într-un mod fundamental. Dar dacă am compara Scrum cu Extreme Programming, vom observa ceva interesant. Modalitatea de lucru în Scrum și XP e foarte similară. Rolurile și structura unui sprint sunt mai bine definite în Scrum decât în XP. Diferența majoră între ele constă însa în faptul că XP cerea un set de practici tehnice, de la collective code ownership, continuous integration, coding standard până la pair programming, refactoring, TDD și simple design. Motivul este simplu și corect: Scrum s-a dorit a combina setul de practici agile care se pot aplica la orice tip de "knowledge work". De aceea, Scrum lasă la latitudinea echipei practicile pe care le vor folosi pentru a livra software de calitate în fiecare sprint. După cum Ken Schwaber a spus la conferința OpenAgile 2009 București, "Scrum se bazează pe craftsmanship", fie el în software, marketing sau crearea unei emisiuni radio. Setul de practici tehnice diferă în funcție de tipul de muncă.
Companiile care aleg să adopte Scrum trec prin câteva etape. Mai întâi, echipa e formată. Apoi planul și starea curentă sunt făcute vizibile. Câteva lucruri se pot întâmpla de acum încolo:
Iată cum agilitatea presupune aplicarea unor practici precum:
Mai mult, agilitatea presupune că toți membrii unei echipe, fie ei testeri, programatori, designeri, analiști de business învață permanent noi metode de a lucra mai bine împreună, pe baza impedimentelor întâlnite. Acest lucru presupune fie planificarea sesiunilor de învățare în cadrul sprintului, fie învățarea în "communities of practice".
Acesta este software craftsmanship: combinația între practicile care ajută în mod pragmatic la aducerea de valoare de business mai repede și mai eficient și dezvoltarea personală continuă într-o comunitate de oameni care au aceleași valori. Agilitatea presupune craftsmanship, pentru că nu se poate altfel.
A nu se înțelege de aici că abordarea Scrum este greșită. Dimpotrivă, ea permite adoptarea incrementală a practicilor tehnice care sunt de ajutor în contextul dat. Una este dacă trebuie să faci un release la șase luni deoarece clienții nu vor mai des (exemplul tipic fiind spitalele sau băncile) și alta să trebuiască să faci release de 15 ori pe zi precum aplicațiile web pentru consumatori care au adesea nevoie. Selecția practicilor tehnice depinde fundamental de nivelul de agilitate dorit. Cei care au pornit pe acest drum pot să le descopere singuri sau să ceară ajutor expert pentru a învăța mai rapid.
În concluzie, practicile tehnice au fost de la început parte din agile. Scrum le-a eliminat din model nu pentru că nu sunt utile, ci pentru că a vrut să fie mai general și pentru că se bazează pe echipă să le selecteze pe cele care au sens în context. Dar agilitatea este imposibil de atins fără un set de practici tehnice pe care să se poată adaugă organizare și, în final, business agility.
de Dan Suciu
