Un proiect reprezintă un efort temporar asumat în vederea obținerii unui produs, serviciu sau rezultat unic [1]. Caracteristica aceasta de unicitate a rezultatului implică un anumit grad de incertitudine în ceea ce privește derularea activităților și, inclusiv, un anumit nivel de risc. Cu cât gradul de incertitudine este mai mare, cu atât proiectul este mai fragil, mai predispus la eșec. De aceea, în managementul clasic, o bună parte din activitatea de management al unui proiect se focusează pe identificarea, măsurarea, monitorizarea, diminuarea și eliminarea riscurilor. Pe de altă parte, metodologiile Agile folosesc mecanisme ce conduc indirect la controlul riscurilor fără însă a propune practici explicite de eliminare a incertitudinii. Cu toate acestea (sau poate tocmai din această cauză), simțim de multe ori că ne aflăm constant pe nisipuri mișcătoare și că proiectul pare scăpat de sub control. Sunt acestea semne ale fragilității proiectului? Părerea mea este că nu și voi încerca să demonstrez acest lucru de-a lungul următoarelor secțiuni.
Fragile Software Development nu este vreun concept nou de dezvoltare a proiectelor software, ci doar un simplu joc de cuvinte utilizat pentru a face conexiunea dintre metodologiile Agile de management al proiectelor și ideea de fragilitate/anti-fragilitate introdusă de Nassim Taleb în cartea sa Antifragile: Things That Gain From Disorder din 2012 [2]. În continuare vom descrie triada fragil/robust/antifragil, așa cum a fost ea definit de Taleb, vom analiza fragilitatea proiectelor prin prisma complexității acestora și, în final, vom discuta despre caracterul antifragil al proiectelor software.
Figura 1. Diferența dintre sistemele complicate și cele complexe:
A. Stacey Matrix (Ralph D. Stacey) B. Cynefin Framework (Dave Snowden) C. Organic vs Mecanic (Nassim Taleb)
Ideea de bază a cărții lui Taleb pornește de la definirea fragilului. Spunem că este fragil orice obiect care se deteriorează sau chiar se distruge cu ușurință, care este vulnerabil la interacțiunea cu factori sau stresori externi. Obiectele fragile trebuie protejate de evenimente aleatorii, de dezordine sau de haos pentru că acestea le-ar putea face rău. În contrast, un obiect robust este un obiect care este dificil de deteriorat sau distrus. Acesta rezistă, fără a-și schimba forma sau structura, la șocuri sau factori de stres externi.
Ni se pare firesc să privim robustul ca fiind antonimul fragilului (în Dicționarul Explicativ al Limbii Române este precizat explicit acest lucru). Nassim Taleb ne spune, însă că, de fapt, opusul fragilului nu este ceva care este rezistent la presiuni externe, ci mai degrabă ceva căruia șocurile sau stresorii externi îi fac bine. Și pentru că nu a existat un cuvânt care să descrie un astfel de obiect Taleb a "inventat" termenul de antifragil. Antifragilul iubește variabilitatea, aleatoriul, dezordinea și volatilitatea pentru că îl ajută la creștere și dezvoltare.
Astfel, robust este mai degrabă neutru, caracterizând un obiect care rămâne neschimbat și nu suferă nici o modificare în condiții de stres. În același timp, deoarece tot ceea ce are mai multe dezavantaje decât avantaje de pe urma evenimentelor aleatorii sau anumitor șocuri este considerat fragil, prin contrast, acele lucruri care în condiții similare beneficiază de mai multe avantaje decât de dezavantaje sunt numite antifragile.
Avem nenumărate exemple în jurul nostru de obiecte, situații sau sisteme fragile sau robuste. Probabil, însă că nu ne-am pus vreodată problema în mod intenționat să identificăm acele obiecte sau sisteme care sunt antifragile. Corpul nostru ne ajută însă să observăm unele dintre ele.
Mușchii, de exemplu, sunt antifragili. În absența activității fizice aceștia se atrofiază. Ei trebuie "stresați" cu o oarecare regularitate pentru a se dezvolta, pentru a deveni mai puternici. Similar, anumite performanțe de efectuare a calculelor aritmetice pot avea de suferit în absența unui exercițiu mental regulat. Aceasta deoarece creierul nostru este antifragil.
La fel este și sistemul imunitar al corpului uman. Expunerea organismului la factori nocivi, dar în doze mici (nu neglijabile), eventual crescânde, cu perioade de recuperare între doze, crește capacitatea acestuia de a rezista efectelor negative ale factorilor respectivi. Pe acest proces, numit hormeză, se bazează "funcționarea" tuturor vaccinurilor.
Nu în ultimul rând, trebuie precizat că protejarea lucrurilor antifragile de evenimente aleatorii poate duce la fragilizarea acestora. Consumul de antibiotice în exces, care nu fac altceva decât să crească robustețea bacteriilor și fragilitatea organismului nostru, este un exemplu. De asemenea, părinții ultra-protectivi care cred că pot elimina aleatoriul din lumea copiilor lor nu fac decât să îi decălească pe aceștia, să îi fragilizeze.
Concluzia lui Nassim Taleb este aceea că, în general, lucrurile inerte, artificiale, mecanice, complicate sunt fragile. Pe de altă parte, sistemele vii, organice, complexe sunt antifragile. Prin urmare, pentru a determina dacă proiectele software sunt fragile sau nu, va trebui să stabilim mai întâi dacă acestea reprezintă sisteme complicate sau complexe. În secțiunea următoare vom analiza diferențele dintre cele două categorii de sisteme, urmând ca în secțiunea finală să stabilim care este contextul ideal în care ar trebui să se dezvolte un proiect software.
Diferența dintre sistemele complicate și cele complexe a fost tratată de mai mulți autori, cele mai relevante descrieri fiind prezentate în Figura 1.
Matricea Stacey ia în considerare maturitatea tehnologiei utilizate și stabilitatea cerințelor funcționale pentru a determina dacă activitatea de dezvoltare a unui produs este una complicată (atât tehnologia cât și cerințele sunt cunoscute și în mare parte stabile) sau complexă. (Atunci când nivelul de instabilitate este unul ridicat sau când avem de-a face cu extreme: cerințele sunt "înghețate", dar tehnologia utilizată este imatură sau cerințele sunt foarte vagi, existând un nivel ridicat de expertiză în tehnologia utilizată).
Pe de altă parte, Dave Snowden la definirea frameworkului Cynefin folosește conexiunea dintre cauză și efect pentru a determina dacă o situație este complicată sau complexă. Astfel, dacă în contextul dat legătura dintre cauză și efect este una anticipabilă (de către un expert) și repetabilă atunci situația este una complicată. Dacă, însă legătura dintre cauză și efect nu poate fi determinată decât retrospectiv, mergând de la efect spre cauză, legătura nefiind nici anticipabilă, nici repetabilă (din cauza variabilității, volatilității și a ambiguității ridicate a contextului, atunci situația este una complexă.
Nassim Taleb este mult mai pragmatic în definiția sa, spunând, mai în glumă, mai în serios, că tot ceea ce seamănă cu o mașină de spălat este complicat și tot ce seamănă cu o pisică e complex. Astfel, putem afirma că o mașină este complicat, iar traficul este complex, că o casă este complicată, dar o gospodărie este complexă, că o carte este complicată și gândurile sunt complexe și, în fine, că un calculator este complicat dar că o aplicație software este complexă.
Prin urmare, încercând să extragem un numitor comun al celor trei abordări, deducem că un sistem complex este caracterizat de un număr mare de interdependențe între componentele sale, și de un nivel ridicat de volatilitate, incertitudine și ambiguitate, caracteristici care implică un grad scăzut de predictibilitate.
Parafrazând spusele lui Alistair Cockburn [3], proiectele software sunt dezvoltate de echipe formate din oameni care comunică, creează și iau decizii rezolvând probleme, pe care încă nu le înțeleg și care sunt într-o continuă schimbare, concepând soluții, pe care nu le înțeleg pe deplin și care sunt într-o continuă schimbare, lucrând alături de oameni, pe care încă nu îi înțeleg și care sunt într-o continuă schimbare, exprimându-și gândurile într-un limbaj sau prin intermediul unor tehnologii, pe care încă nu le înțeleg și care sunt într-o continuă schimbare, și urmând metodologii, pe care încă nu le înțeleg și care sunt într-o continuă schimbare. Este fără doar și poate descrierea unui context VUCA (Volatile-Uncertain-Complex-Ambiguous) în care dinamica schimbărilor este alertă, iar nivelul de predictibilitate este relativ scăzut.
De aceea, dezvoltarea proiectelor software este o întreprindere complexă, și prin urmare antifragilă. Aplicarea în acest context a unei metodologii clasice, tradiționale, cum sunt Waterfall, V-Model sau Spiral Model, poate conduce la fragilizarea proiectului. Managementul riscului, procesele formale de aprobare și implementarea modificărilor de cerințe sau planificarea detaliată înaintea începerii dezvoltării efective sunt doar câteva dintre practicile specifice acestor metodologii predictive care au ca scop eliminarea ambiguității și incertitudinii și protejarea proiectului de evenimente probabile ce pot avea un impact negativ asupra factorilor principali de succes: scopul, bugetul și termenele.
Așa cum am văzut însă, un anumit tip de "dezordine" este necesar pentru a permite sistemelor complexe să se dezvolte. În plus, acestea vor beneficia de pe urma evenimentelor stresante care pot afecta pozitiv calitatea și robustețea atât a echipei cât și a produsului final. Valorile și principiile Manifestului Agile susțin dezvoltarea constantă incrementală și iterativă. Iterațiile reprezintă modalități de introducere de șocuri moderate, cu perioade de recuperare între ele, ce întăresc echipa, măresc performanța și conduc spre o calitate sporită a produsului final și, implicit, la o satisfacție crescută a clientului.
Un exemplu relevant este dat de integrarea componentelor dezvoltate de membrii echipei. Într-un context waterfall, această integrare se realiza la finalizarea componentelor, după o perioadă relativ lungă te timp (2-3 luni) și era în general dificilă și tensionată, deoarece apăreau mereu cazuri speciale, neanticipate, în comunicarea dintre componente. Rezultatul era de cele mai multe ori unul încropit, cu repercusiuni pe termen scurt sau lung în implementările ulterioare.
Într-un context agil integrarea se realizează continuu (zilnic, sau chiar de două-trei ori pe zi), conducând la creșterea calității produsului final și optimizarea dezvoltării. Fără doar și poate, putem spune că integrarea continuă reprezintă un mod particular de aplicare a hormezei în contextul dezvoltării de aplicații software.
Interesant este și faptul că practicile recent apărute în comunitatea Agile sunt în deplină concordanță cu caracterul antifragil al proiectelor software, așa cum a fost descris el de Taleb. Astfel reteaming (practică definită ca arta destabilizării unei echipe, căreia i-am dedicat un articol special în numărul 75 al Today Software Magazine din septembrie 2018 și care accentuează problemele ce pot să apară într-o echipă stabilă, lipsită de șocurile periodice atât de utile performanței), chaos engineering (disciplină ce permite creșterea capabilităților unui sistem prin supunerea acestuia la evenimente destabilizatoare aleatorii) sau interesul crescut din ultima perioadă pentru profiluri de full-stack developer în industria IT (numiți și comb-shape employees datorită specializărilor multiple, dar nu foarte profunde, pe diverse tehnologii) demonstrează validitatea teoriei că șocuri frecvente, de intensitate redusă, dar nu neglijabilă și cu perioade de recuperare între ele, duc la creșterea beneficiilor proiectelor complexe.
În concluzie, va trebui să ne obișnuim cu ideea că încă o bună perioadă de timp (cel puțin până când sistemele de inteligență artificială vor reuși să dezvolte independent aplicații software cap-coadă) implicarea în dezvoltarea eficientă de software va însemna inevitabil un stres- e adevărat moderat- distribuit continuu cu o anumită frecvență și cu reprize de recuperare. Va trebui să încercăm să ne ținem conștient departe de zona de confort, atât la nivel individual, cât și la nivel de echipă pentru că, așa cum spunea Nassim Taleb "sistemele complexe sunt slăbite sau chiar omorâte atunci când sunt private de stres".
PMI, PMBOK® Guide - Sixth Edition, Project Management Institute, 2017.
N. N. Taleb, Antifragile: Things That Gain from Disorder., New York: Random House, 2012.
F. Laloux și K. Wilber, Reinventing Organizations, Nelson Parker, 2014.
de Ovidiu Mățan
de Ovidiu Mățan
