ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 16
Abonament PDF

Agilitatea Presupune Craftsmanship

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works
MANAGEMENT

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

  • Mike Beedle - a publicat articole despre Object-Oriented Programming (OOP), pattern-uri, reutilizarea componentelor și framework-urilor, limbaje de programare.
  • Ward Cunningham - a fost Principal Engineer la Tektronix, compania care a creat Smalltalk, primul limbaj object oriented utilizat pe scară largă. A participat la crearea Extreme Programming (XP), a creat metoda de software design cu CRC și a contribuit activ la comunitatea de patterns Patterns Language of Programming (PLoP).
  • Martin Fowler - este un binecunoscut autor în subiecte de software design și refactoring.
  • Andrew Hunt - partener la editura "Pragmatic Programmer" care ne-a dat multe cărti utile pentru programatori și co-inițiator al mișcării Software Craftsmanship.
  • Ron Jeffries - consultant și programator foarte experimentat în Extreme Programming.
  • Jon Kern - evanghelist OOP, începand cu C++ și continuând cu Java
  • Brian Marick - tester și programator specializat în limbaje functionale.
  • Robert C. Martin - binecunoscut autor al unor cărți despre design și despre programare, promotor al mișcării Software Craftsmanship.

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:

  • Echipa nu știe să lucreze incremental, drept urmare apar story-uri care nu pot fi terminate într-un sprint. E nevoie de îmbunătățirea modului de a face story slicing.
  • Dezvoltarea se termină în cadrul sprintului, dar nu e timp pentru testare. Testarea se mută în alt sprint (sau sprinturi). E nevoie de: testare încrucișată, pairing între programator și tester și automatizarea testelor.
  • Story-urile sunt în general dezvoltate și testate în cadrul sprintului, dar punerea în productie durează foarte mult și reduce semnificativ viteza de dezvoltare. E nevoie de continuous integration pentru automatizarea incrementală a deployment-ului.
  • Viteza de dezvoltare crește, se stabilizează, dar apare un story care modifică fundamental o parte din design-ul aplicației și durează mai mult de un sprint. E nevoie de refactoring și de design mai bun care urmărește principiile SOLID.
  • Dacă aplicația este dezvoltată pentru un mediu mai complex, de obicei enterprise, anumite modificări sunt foarte dificil de împărțit în story-uri care încap într-un sprint. Uneori este un semn de architectural debt, și e nevoie de gândire arhitecturală pe termen mediu și lung.

Iată cum agilitatea presupune aplicarea unor practici precum:

  • Pair programming pentru prevenirea greșelilor și obținerea unui design mai flexibil;
  • Unit testing pentru scurtarea timpului necesar validării produsului;
  • Refactoring continuu pentru păstrarea unui design flexibil;
  • TDD (Test Driven Development) sau BDD (Behavior Driven Development) pentru definirea clară a problemei și găsirea soluțiilor celor mai simple;
  • Urmărirea unor principii de design și folosirea de design patterns pentru a păstra deschiderea la modificari;
  • Gândirea strategică pe termen lung a arhitecturii pentru micșorarea riscurilor tehnice și de dezvoltare.

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.

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects