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 90
Abonament PDF

Fragile Software Development

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



MANAGEMENT


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)

Antifragilitatea

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.

Sisteme complexe

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.

Antifragilitatea proiectelor software

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

Referințe

  1. PMI, PMBOK® Guide - Sixth Edition, Project Management Institute, 2017.

  2. N. N. Taleb, Antifragile: Things That Gain from Disorder., New York: Random House, 2012.

  3. F. Laloux și K. Wilber, Reinventing Organizations, Nelson Parker, 2014.

  4. A. Cockburn, "Effective Software Development in the 21st Century - The New Face Of Software Engineering," Tampere University of Applied Sciences, Tampere, 2008.

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