ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 47
Abonament PDF

Cunoaște-ți inamicul!

Vasile Selegean
Software Quality Engineer @ NTT DATA Romania



MANAGEMENT

"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 !

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

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