"Know your enemy and know yourself and you can fight a hundred battles without disaster" said Sun Tzu some 2500 years ago. I will not review his "Art of War"; today I'll talk about Agile and its most used flavour these days: Scrum. Is Scrum/Agile movement the enemy of Software Development Craftsmanship? A creativity killer? What about team's productivity?
"Cunoaște-ți inamicul și cunoaște-te pe tine însuți, astfel poți lupta în sute de bătălii fără înfrângere" spunea Sun-Tzu acum vreo 2500 de ani. Dar nu marele general chinez și a lui "Artă a Razboiului" este subiectul, pentru că acesta este Agile și Scrum în particular - poate cea mai răspândită metodologie Agile în zilele noastre. Dacă mișcarea Agile/Scrum este dușmanul meșteșugului dezvoltării de software? Este o piedică în calea creativității individuale într-o echipă? Dar despre productivitatea unei echipe Scrum ce s-ar putea spune?
De-a lungul istoriei umanității au fost mulți profeți ce au pretins că dețin adevărul absolut. Ideile lor au câștigat adepți în timp, iar unele dintre acestea au rezistat până în zilele noastre. Lumea din jurul nostru se schimbă din ce în ce mai repede. Numai în ultimii 250 de ani caii au fost înlocuiți de motoare cu aburi, ce au fost mai apoi înlocuite de cele cu ardere internă, care vor fi la rândul lor înlocuite în curând de cele electrice. De asemenea, mâna de lucru, managementul acesteia și procesele de producție au evoluat: lucrătorii s-au specializat, mai apoi au apărut liniile de asamblare, iar astăzi roboții le iau locul muncitorilor, fie că ne place sau nu - vezi Peter Leeson la ITCamp 2015
Cum schimbă Revoluția Digitală lumea în care trăim? Deși începută acum vreo 50 de ani, Era Digitală este încă la început (Ovidiu Șuta în TSM). O echipă în industria IT nu mai este formată dintr-un inginer, 2-3 maiștri și 20 de muncitori lucrând în schimburi. Echipele sunt formate din 20 de ingineri! Din păcate, managementul forței de muncă nu a putut ține pasul cu aceste schimbări și munca este încă organizată după modelul inventat de Henry Ford la începutul secolului XX, iar ierarhia organizațiilor este la fel cu a fabricilor din era industrială. Treptat, hardware-ul și software-ul au devenit utilități -la fel cu apa curentă sau electricitatea-, clienții au acum posibilitatea să își aleagă furnizorii din orice parte a lumii, iar aceasta face și mai dificilă supraviețuirea în lumea IT.
Iată-ne în anul 2001. Anul apariției unei idei revoluționare în lumea dezvoltatorilor software. Un pas uriaș ce ne îndepărtează de metodele de lucru tradiționale. Vă amintiți imaginile celebre cu Dumnezeu care îi vorbește lui Moise printr-un rug în flăcări? Priviți acum imaginea de fundal de pe site-ul http://agilemanifesto.org/! A fost acest pas uriaș făcut într-o direcție bună? Să vedem - prin prisma celor 15 ani trecuți de atunci!
Încă de la început principiile simple prezentate în Agile Manifesto au creat așteptări dincolo de puterile oamenilor din lumea IT, ceea ce a creat mai multă presiune într-o industrie deja aflată la un nivel critic de stres. Mai mult, câțiva întreprinzători abili au sesizat o oportunitate de câștig și au rostogolit la vale bulgărele de zăpadă, urmați la scurtă vreme de mare parte a managerilor companiilor din domeniu pentru că, de ce nu, ceilalți deja aplică principiile Agile, forțând lucrurile de sus în jos pe cale ierarhică.
Primul principiu al manifestului Agile declară că individul și interacțiunea directă dintre indivizi sunt mai valoroase decât procesele sau uneltele (tools). Dar.. ce este Scrum dacă nu un proces? Mai mult, diagrama Scrum amintește de descrierea unui proces de producție într-o fabrică din prima jumătate a secolului XX. Într-o organizare Scrum se presupune că Product Owner-ul este capabil să stea între echipa de dezvoltare și mulțimea de stakeholders și să asigure traducerea nevoilor de business în limbajul tehnicienilor; Se presupune că scopul sprint-ului nu se schimbă și că estimările sunt întotdeauna corecte și echipa de dezvoltare este capabilă să livreze ceea ce a promis; se presupune că micile blocuri (stories) realizate în cursul unei iterații pot fi asamblate și livrate ca un produs finit. Din păcate, aceste supoziții nu sunt întotdeauna corecte în lumea reală. Merită amintit și faptul că este imposibil să dezvolți un produs software fără unelte modern (IDE, versioning control, etc).
Al doilea principiu Agile pune software-ul funcțional (working software) înaintea documentației vaste. Cum ar fi să facem lucrurile bine de la început? Să măsurăm de două ori înainte să tăiem? Cât despre documentație.. ajunge să ne gândim că mulți dintre noi lucrăm sau am lucrat la un moment dat, într-un proiect început de altă echipă, poate chiar dintr-o altă țară! Nu ne-ar fi prins bine să avem la îndemână documentația la început? Cuvântul-cheie aici este "vast", dar se pierde împreună cu "documentație" în favoarea "working software".
Al treilea principiu Agile favorizează colaborarea cu clientul înaintea negocierilor contractuale.
Cel de-al patrulea și ultim principiu Agile este favoritul meu: receptivitatea la schimbare înaintea urmăririi unui plan. Ce imagine va vine prima dată în minte când citiți "cross-cutting, prepared, self-organizing, and responsive team"? O unitate de commando capabilă să facă față cu brio, în cel mai scurt timp și cu resurse limitate, unei misiuni în teritoriul inamic sau o echipă de ingineri software aplecați deasupra tastaturilor? "Before the Agile fad, 'Scrum' was a term sometimes used for what corporations might also call a 'Code Red' or a 'War Room emergency'. This is when a cross-cutting team must be built quickly to deal with an unexpected and, often, rapidly-evolving problem." (Michael O. Church - Why "Agile" and especially Scrum are terrible)
Ideile enunțate în manifestul Agile vin la pachet cu manualul de instrucțiuni: cele 12 principii pentru software agil (am citat din versiunea în limba română a site-ului http://agilemanifesto.org):
* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software - nimic de zis!
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage - Din păcate, acest principiu are un efect contrar regulii ce fixează scopul unei iterații. Product Owner-ul sau clientul nu are întotdeauna răbdare să aștepte începutul unui nou sprint, iar schimbările cerințelor nu sunt întotdeauna analizate în detaliu și pot avea efecte nedorite. În plus, schimbările din cadrul echipei sau al mediului de lucru sunt ignorate în totalitate.
* Business people and developers must work together daily throughout the project și The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Așa să fie oare? Adăugați la asta "open space policy" - vom observa oare o îmbunătățire a productivității? Sau o descreștere a nivelului de stres?
* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done și Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Pe termen nelimitat? Nu suntem mașini, dacă mașinile ar putea scrie cod am fi aflat asta deja. Este imposibil să alergi un întreg maraton în etape de 100m, în ritmul la care se aleargă astfel de curse scurte!
* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale și Working software is the primary measure of progress. Un produs software al zilelor noastre este un mecanism complex, în care componentele sunt strâns interconectate. Eliminând sau modificând una dintre componente, funcționarea întregului nu mai poate fi garantată. Ar fi posibil să construim un ceas automatic urmând un proces iterativ, fără a avea descris de la început, cât mai detaliat, produsul final? Mai mult, lucrul în iterații cu un scop precis a contribuit la apariția așa numitului "technical debt", care este una din marile probleme cu care se confruntă industria IT a zilelor noastre.
* The best architectures, requirements, and designs emerge from self-organizing teams. Cine crede că acestea pot fi făcute în paralel cu activitatea de dezvoltare?! Arhitectura sau designul unui produs software trebuie să preceadă alte activități și nu invers!
* Simplicity--the art of maximizing the amount of work not done--is essential. - nici aici nu ar fi nimic de comentat.
* Continuous attention to technical excellence and good design enhances agility. Echipele sunt încă organizate ierarhic. Chiar dacă nu este întotdeauna formalizată, ierarhia este prezentă, iar deciziile și comportamentul membrilor echipei țin cont de aceasta.
* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Echipele nu sunt întotdeauna capabile să se auto-organizeze. Să ne gândim doar la nivelurile diferite de experiență, la oamenii care vin și pleacă, la domeniul de activitate căruia i se adresează produsul software pe care echipa îl construiește. Nu susțin că este nevoie întotdeauna de un conducător, dar resposabilitățile și îndatoririle ar trebui bine definite și clarificate.
În concluzie, metodologia Scrum:
Se potrivește perfect unui proiect de cercetare (R&D) unde ingineri cu experiență colaborează pentru a ajunge la o soluție optimă. Sau pentru un proiect de tip Proof-of-Concept pentru validarea unei idei sau captarea atenției unui posibil nou client.
Se potrivește perfect organizațiilor mici sau celor care încearcă să pătrundă pe un segment nou de piață.
Nu se potrivește proiectelor mari, de tip enterprise, fără ca o etapă inițială de analiză pentru stabilirea scopului și a căilor de atingere a acestuia să fie incheiată cu o planificare riguroasă.
Așa cum o văd eu implementată, metodologia Scrum împiedică creativitatea și provoacă un overhead nedorit.
În concluzie, este Agile / Scrum inamicul artei dezvoltării software, al creativității sau al productivității în lumea IT? Răspunsul meu este "da" și "posibil".
Dezvoltarea produselor software ține mult de măiestrie, deoarece software-ul este un produs artizanal ce necesită multă creativitate. Cât timp cineva promite că va livra atâtea stories câte îi permite timpul disponibil în următoarea iterație, nu va mai avea timp să încerce soluții noi idei inovatoare. Productivitatea persoanei va scădea în timp, fără să menționez temutul "technical debt" ce se acumulează sprint după sprint. Știu - trăim într-o lume nebună, în care totul trebuie terminat ieri și mai bine decât competitorii direcți - dar acest fel de a face lucrurile nu poate fi susținut pe termen lung.
S-ar putea cumva îmbunătăți lucrurile? Bineînțeles! Schimbarea, contestarea "tradițiilor" este exact ceea ce a adus umanitatea la nivelul de azi. Dar, pentru a fi siguri că schimbarea este înspre bine, toate detaliile tradiționale trebuie cunoscute în amănunt. Pentru a-ți cunoaște dușmanul, trebuie să te identifici cu el. Să învățăm Scrum în detaliu, să câștigăm experiență folosindu-l zilnic; să învățăm despre rolurile de Scrum Master sau Product Owner; astfel vom fi capabili să observăm ce nu merge bine și unde se poate interveni fără a strica întregul !
de Ovidiu Mățan
de Vlad But
de Maria Revnic
de Delia Mircea
