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

Să se revizuiască, dar să nu se schimbe nimic…

Dan Suciu
Lector, PhD @ Facultatea de matematică și informatică, UBB



MANAGEMENT


Motto: "Din două una, dați-mi voie: ori să se revizuiască, primesc!
dar să nu se schimbe nimica; ori să nu se revizuiască, primesc!
dar atunci să se schimbe pe ici pe colo, şi anume în punctele… esențiale."
I.L. Caragiale, O scrisoare pierdută

Am simțit nevoia să revin, prin acest articol, asupra unui subiect pe care de-a lungul timpului l-am întors pe toate părțile: schimbarea. Chiar în Today Software Magazine, în șase dintre cele treisprezece articole pe care le-am publicat, am vorbit într-un fel sau altul despre schimbare. Ba că e necesară ([1], [5]), ba că e naturală și firească ([3]); uneori descriind procese sau frameworkuri care ne-ar putea ajuta în adaptare ([2], [4]), alteori propunând schimbarea modului de abordare a... schimbării ([6]).

În slalomul meu printre aceste teme am repetat faptul că schimbarea e dificilă. Nu am considerat nici util, nici necesar să insist asupra acestui aspect pentru că am considerat că este de la sine înțeles de ce se întâmplă acest lucru. Am constatat însă că există o atitudine constantă de respingere a schimbării chiar și în contexte neașteptate, unde ne așteptăm ca disponibilitatea de acceptare și adaptare la schimbare să fie una ridicată. Iată de ce voi extinde în acest articol unele dintre gândurile expuse în [6] ca rezultat al eforturilor mele de a (-mi) explica de ce ne deranjează atât de mult schimbările și în ce condiții acestea pot deveni nocive chiar și în medii sau organizații considerate agile.

Primul din 12

În ultimii patru ani de zile de când m-am dedicat exclusiv activităților de instruire, mentorare și coaching am avut ocazia să vorbesc de multe ori despre schimbare. În cursuri sau traininguri. Am sentimentul că este un subiect relevant, în special atunci când vorbim despre un context Agile.

Mereu încep discuția de la bază. De la fundamente. Mereu încep de la valorile Agile, valori enunțate în urmă cu mai bine de 20 de ani în Manifestul Agile [7].

Cu toții știm sau simțim cât de importanți pentru atingerea succesului sunt oamenii cu care lucrăm și mai ales modul în care interacționăm sau colaborăm cu ei, fie că e vorba de alți colegi din echipa de dezvoltare sau de clienți și reprezentanți ai acestora. În același timp este la fel de important ca ceea ce facem să aibă un sens, să fie de folos cuiva, să rezolve o problemă concretă, să ducă la atingerea unor obiective importante. Cu alte cuvinte să funcționeze! Iar în această lume VUCA [9], această lume volatilă, incertă, complexă și atât de ambiguă, este important să ne putem adapta, să avem capacitatea de a ne reconfigura traseul cu ușurință.

Prin urmare "individuals and interactions", "working software", "customer collaboration" și "responding to change" au devenit în mod natural o necesitatea pentru o echipă de succes și, implicit, parte a valorilor enunțate de Manifestul Agile.

Dar acestea sunt valori abstracte. Este foarte dificil ca o echipă să înțeleagă ce trebuie să facă exact pentru a instala aceste valori în mintea sau în mentalitatea membrilor săi. De aceea, pentru a aduce mai multă claritate, fondatorii Agile Manifesto au propus doisprezece principii, mai concrete în ceea ce privește aplicabilitatea [8]. Cele doisprezece principii Agile reprezintă o combinație foarte puternică.

A fi agil înseamnă a urma toate aceste principii, nu doar o parte dintre ele. Dar, deși toate principiile sunt la fel de importante, ele nu sunt și la fel de ușor de implementat.

De obicei, după ce fac o trecere în revistă a celor patru valori și doisprezece principii Agile, acesta e momentul în care întreb care dintre principii reprezintă cea mai mare provocare, care este cel mai dificil principiu de implementat? Și pun aceeași întrebare atât studenților mei de la cursul de Agile de la programele de master de informatică ale Universității "Babeș-Bolyai", cât și participanților la trainingurile livrate în diverse organizații, indiferent dacă lucrează deja de multă vreme într-un mediu Agile sau sunt în plin proces de transformare Agile.

Am pus cap la cap toate răspunsurile primite în ultimii patru ani de zile și am constatat că unul dintre principii este considerat mereu ca fiind cel mai dificil de urmat sau de îmbrățișat. Iar acest principiu câștigă detașat însumând de fiecare dată în jur de 40% dintre opinii. Este vorba despre principiul al doilea, cel care se referă la îmbrățișarea schimbării și la convertirea acesteia în avantaj competitiv pentru clienți (în original: "Welcome changing requirements, even late in the project. Agile processes harness change for the customer's competitive advantage").

Pe poziția a doua este principiul al zecelea, despre construirea de soluții simple, iar pe poziția a treia este principiul al patrulea, cel referitor la comunicare zilnică cu clienții.

Dar oare de ce se întâmplă asta? De ce îmbrățișarea schimbării este atât de dificilă într-o echipă de proiect? Am încercat să detaliez în următoarele trei secțiuni unele dintre motivele pe care eu le consider esențiale:

A. înclinația de a identifica șabloane;

B. cultura;

C. atașamentul față de propriile rezultate.

Șabloane și confort

În [6] detaliam o idee expusă de un bine-cunoscut designer de jocuri video într-o celebră carte a sa, și anume aceea că creierul uman este în mai mare parte un devorator de șabloane, de tipare [11]. A învăța ceva înseamnă în esență a descoperi acele șabloane care pot fi repetate ulterior în diverse contexte. Percepem mai toate lucrurile și evenimentele din jurul nostru ca încadrându-se într-un tipar sau altul, mai mult sau mai puțin subtil. Facem asta pentru a ne conserva energia. Creierului nostru nu îi place să gândească. Și asta din simplu motiv că procesul de gândire, de concentrare duce la un consum de peste 25% din energia corpului. De aceea creierul nostru are nevoie de aceste șabloane pentru a automatiza cât mai mult comportamentul nostru în rezolvarea problemelor.

Probabil că cel mai specializat șablon este cel al feței umane. O parte surprinzător de mare a creierului uman este dedicată identificării fețelor și o mare parte din puterea sa de procesare se consumă pe interpretarea înfățișării. Creierul nostru devine încă din primele zile specializat în recunoaștere facială, iar această specializare se datorează faptului că fizionomiile sunt extrem de importante pentru modul în care funcționează societatea umană. Nu de puține ori am regăsit "fețe" în dispunerea aleatorie a norilor de pe cer, în zugrăveala pereților sau în secțiuni de cartofi, ca să dau doar câteva exemple.

Capacitatea de a distinge o față într-o schiță de câteva linii și de a interpreta emoțiile subtile din aceasta indică lucrul pe care creierul știe să îl facă cel mai bine: să recunoască tipare și să umple "golurile" atunci când tiparele par a fi incomplete, pe baza tiparelor recunoscute anterior.

De asemenea, capacitatea noastră de a identifica șabloane este folosită intens în măsurarea inteligenței. Însă cercetările arată că pe măsură ce ne crește capacitatea de a descoperi mai repede diferite șabloane în jurul nostru, suntem mai predispuși să ne atașăm de stereotipuri. În special oamenilor cu un IQ ridicat le este mai dificil să își reconfigureze convingerile și credințele. De foarte multe ori convingerile pe care le avem ne determină să respingem sau să ignorăm argumentele pe care le pot aduce ceilalți. Noi deja avem răspunsurile, nu-i așa? Aceste convingeri ne fac să acceptăm mult mai greu al doilea principiu al Manifestului Agile.

Cultura lui "așa cum trebuie"

Nici cultura nu ne ajută prea mult. Unul dintre cele mai interesante mecanisme în ceea ce privește analiza diferențelor culturale este teoria dimensiunilor culturale dezvoltată de Geert Hofstede [10]. Aceasta arată efectele culturii unei societăți asupra valorilor membrilor săi și modul în care aceste valori se raportează la comportament. Teoria propune șase dimensiuni de-a lungul cărora ar putea fi analizate valorile culturale:

  1. distanța de putere (referindu-se la forța ierarhiei sociale);

  2. individualism vs. colectivism;

  3. motivarea de realizare și succes;

  4. evitarea incertitudinii;

  5. orientarea pe termen lung/scurt;

  6. indulgență vs. reținere.

Relevant pentru articolul de față este indicele de evitare a incertitudinii, care este definit ca fiind "toleranța unei societăți față de ambiguitate", în care oamenii îmbrățișează sau evită un eveniment neașteptat, necunoscut sau care îi îndepărtează de status quo. Un scor mai mic pentru acest indice arată un grad mai mare de acceptare a gândurilor sau ideilor diferite. Societatea tinde să impună mai puține reglementări, ambiguitatea nu este privită ca un aspect negativ, iar mediul este mai liber. În contrast, societățile care obțin un scor ridicat în acest indice optează pentru coduri rigide de comportament, legi mai stricte și, în general, se bazează pe adevărul absolut sau pe credința că un singur adevăr dictează totul și că oamenii știu care este acesta.

România înregistrează un scor foarte ridicat pentru dimensiunea de evitare a incertitudinii, și anume 90 (figura 1). Acest lucru se reflectă în munca noastră de zi cu zi prin încercarea de a obține specificații complete pentru fiecare sarcină pe care trebuie să o dezvoltăm, încercăm să identificăm sau să anticipăm cât mai multe excepții, punem multe întrebări înainte de a începe să lucrăm la un user story și simțim o frustrare uriașă atunci când specificațiile se schimbă după ce ne-am apucat de lucru. Nu de puține ori simțim că aceste schimbări sunt o consecință a slabei pregătiri profesionale a clienților noștri.

Vedem echipe care au o definiție foarte rigidă a user story-urilor sau echipe care au tendința de a sări peste ședințele de revizuire a iterațiilor, deoarece consideră că aceste ședințe sunt doar o invitație pentru stakeholderi de a propune modificări.

Figura 1. Cele 6 dimensiuni culturale ale modelului lui Geert Hofstede [10]

Evident că nici acest comportament nu ajută prea mult la adoptarea celui de-al doilea principiu al Manifestului Agile.

Bad Romance

În echipele noastre de proiect ne lovim zilnic de probleme care trebuie rezolvate. Pentru fiecare problemă analizăm, proiectăm și scriem cod pentru a dezvolta cea mai potrivită soluție. Nu de puține ori însă, problema se schimbă între timp și brusc soluția noastră devine inutilă. Reacția instinctivă este aceea de a ne apăra soluția: "Hei, soluția noastră e bună! Noua problemă este greșită sau inadecvată." Acest comportament este unul normal deoarece reflectă atașamentul nostru față de propria soluție și este greu să acceptăm că tot entuziasmul și efortul nostru au devenit inutile. Oricât de greu ne este însă, aceasta e realitatea.

În urmă cu doi ani am aflat de povestea podului de peste Choluteca, un râu aflat în zona sudică a Hondurasului. Construit inițial în 1930, podul a fost reconstruit de mai multe ori deoarece zona s-a confruntat de-a lungul timpului cu condiții meteorologice extreme. În 1997, guvernul din Honduras a angajat unele dintre cele mai bune minți arhitecturale din lume pentru a construi un pod care să reziste oricărui uragan. Din păcate, în 1998, Hondurasul a fost lovit de uraganul Mitch, o furtună de categoria 5 care a devastat regiunea. Drumurile au fost distruse, clădirile au suferit pagube considerabile, iar toate celelalte poduri din Honduras au fost grav afectate. Cu toate acestea, podul de peste Choluteca a rezistat și a supraviețuit în condiții aproape perfecte. A fost, într-adevăr, o realizare arhitecturală uimitoare. Sau, cel puțin, astfel ar fi trebuit să rămână în memoria noastră dacă nu ar fi fost o problemă: uraganul a fost suficient de puternic pentru a "forța" râul să își croiască o cale complet nouă, să își sape o nouă albie care, din păcate, nu mai trecea pe sub pod. Prin urmare, podul cel robust nu mai trecea peste râu, devenind astfel inutil.

Este remarcabil cât de repede se pot schimba lucrurile. Această istorie demonstrează cum chiar și lucrurile care ni se par foarte greu sau puțin probabil de schimbat se schimbă. Iar noi nu putem influența sau controla aceste situații.

Concluzia ar fi aceea că nu trebuie să ne îndrăgostim de soluțiile noastre, ci de problemă, cum foarte bine sugera Uri Levine, confondator al Waze, în cartea sa [12]. Atașamentul față de o problemă ne obligă să ne întrebăm de ce există aceasta și de ce nu a fost încă rezolvată. Ne cere să ne întrebăm de ce lucrurile care par a fi soluții nu sunt. Ne cere să explorăm și să căutăm cauzele profunde și să întâmpinăm, cu deschidere, surprizele.

Concluzii

Cum ne descurcăm în aceste condiții? Cum facem față unei lumi VUCA? În primul rând, trebuie să considerăm schimbările ca fiind ceva normal. Schimbările într-un proiect, în special într-un proiect software, nu sunt excepții. Ele sunt de multe ori o consecință a faptului că am luat-o pe un drum greșit. Mindsetul trebuie să fie mereu acela al experimentării. Fiecare nou rezultat/livrabil reprezintă o posibilă soluție, cu siguranță una mult mai apropiată de ceea ce trebuie să obținem decât soluțiile anterioare. Și asta produce valoare pentru clienții noștri. Cu alte cuvinte, cel mai greu lucru într-un context Agile este înțelegerea profundă a nevoii de a fi agil și evitarea de modele de gândire exprimate chiar de titlul acestui articol!

Un alt sfat important e acela de a implementa soluții cât mai simple. Este suficient că problemele pe care trebuie să le rezolvăm sunt complexe. Să nu înrăutățim exponențial lucrurile implementând și soluții complexe. Soluțiile noastre trebuie să fie cât mai simple posibil. Nu simpliste, doar simple. Există multe exemple care ne demonstrează că implementarea de cod reutilizabil, proiectarea de arhitecturi multi nivel sau utilizarea excesivă de frameworkuri conduc la o creștere exponențială a complexității soluțiilor software pe care le dezvoltăm.

Dar, dacă revenim asupra topului nostru cu cele mai dificile principii Agile de urmat, observăm că pe a doua poziție se află exact principiul simplității (în original: "Simplicity — the art of maximising the amount of work not done — is essential"). Deci, nu ar strica să actualizăm lista principalelor motive pentru care principiul al doilea este greu de urmat cu un nou punct, al patrulea:

D. apetența pentru complexitate.

Nici nu am terminat bine articolul și deja avem propuneri de a schimba conținutul.

Well, change is normal!

Referințe

  1. D.M. Suciu, "Particularităţi ale proiectelor informatice", TSM, nr 8, ianuarie 2013, pp. 11-13

  2. D.M. Suciu, "Best Practices in Agile", TSM, nr 16, noiembrie 2013, pp. 13-15

  3. D.M. Suciu, "Agile Humanum Est", TSM, nr 39, septembrie 2015, pp. 12-14

  4. D.M. Suciu, "Agile și adaptarea la schimbare", TSM, nr 63, septembrie 2017, pp. 15-16

  5. D.M. Suciu, "Fragile Sofware Development", TSM, nr 90, Cluj-Napoca, decembrie 2019, pp. 12-14

  6. D.M. Suciu, "(Re)Gândește Agile", TSM, nr 111, Cluj-Napoca, septembrie 2021, pp. 6-8

  7. Manifesto for Agile Software Development, 2001

  8. Principles behind the Agile Manifesto, 2001

  9. U.S. Army Heritage and Education Center, "Who first originated the term VUCA (Volatility, Uncertainty, Complexity and Ambiguity)?", USAHEC Ask Us a Question, The United States Army War College, 2018

  10. Geert Hofstede, "Cultures and Organizations: Software of the Mind", Third Edition, McGraw-Hill Education - Europe, iulie 2010

  11. Raph Koster, "Theory of Fun for Game Design", Second Edition, O'Reilly Media, 2013

  12. Uri Levine, "Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs", Matt Holt, 2023

LANSAREA NUMĂRULUI 143

Railroads

miercuri, 29 mai, ora 18:00

Târgu-Mureș, Studium Hub

Facebook Meetup StreamEvent YouTube

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

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

INTERVIURI VIDEO