ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ 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.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects