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

Best Practices în Agile

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



MANAGEMENT


Ideea acestui articol mi-a venit cu mai multe luni în urmă, atunci când pregăteam o prezentare pentru conferința "…și mamuții sunt Agile" ce a avut loc la Cluj-Napoca în această primăvară. Se întâmplă uneori ca anumite lucruri să pară a fi foarte clare și evidente la un moment dat, însă atunci când le studiezi mai îndeaproape ai surpriza să constați contrariul. Așa s-a întâmplat și atunci, când dorind să studiez eficiența și beneficiile aderării la bunele practici Agile adoptate în anumite organizații sau echipe de proiect, am ajuns la concluzii ce sunt departe de a le considera optimiste.

Voi încerca în cadrul acestui articol să identific principalele elemente ce duc la ideea că a aplica practici de succes în implementarea Agile ale altor organizații/echipe în propria echipă de proiect poate să aibă mai multe dezavantaje decât avantaje.

Vederea idilică asupra proiectelor IT

O comparație care mie mi se pare foarte sugestivă este aceea dintre un proiect informatic și un joc de șah. Suntem tentați să spunem că ambele au câteva caracteristici de bază pe care le cunoaștem de la bun început:

  • știm care sunt jucătorii,
  • știm care sunt rolurile "pieselor" pe care le utilizăm,
  • știm care sunt procesele și regulile ce trebuie urmate.

Dacă mergem mai departe cu această comparație, putem spune că o abordare Agile a jocului de șah este una în care reacționăm corespunzător la fiecare mutare a partenerului de joc, în timp ce Waterfall-ul clasic este mai degrabă o încercare de a anticipa din start cât mai bine mișcările adversarului, urmând să mutăm piesele pe baza unei strategii proprii şi ignorând ce se întâmplă de cealaltă parte a mesei până când apare o "coliziune" (mod de lucru care, de multe ori, are loc și la "adversar").

Evident în modul Waterfall probabilitatea de eșec este semnificativă, lucrurile ameliorându-se în funcție de cât de repede ne "trezim" și ne coordonăm mișcările cu cele ale adversarului.  

Consider că aceasta este o vedere idilică a proiectelor IT deoarece pleacă de la ideea că dacă stăpânești foarte bine procesele ce guvernează "jocul" și dacă ai mai văzut un stil de joc asemănător cu al adversarului în trecut, șansele de succes sunt mari. Strategia de succes s-ar axa pe aceste două componente esențiale care te conduc la algoritmi (aproape) infailibili în situaţii date şi care îţi şi permit să faci predicţii cât se poate de realiste.

Multitudinea de cărţi de IT project management se referă, în mare parte, la astfel de proiecte şi iau în considerare un "numitor comun" al proiectelor IT, un context aproape ideal sau care se îndepărtează într-o manieră decentă, benignă, de acest ideal, specificându-se de fiecare dată că anumite lucruri pot fi adaptate în practică în funcţie de specificul unui proiect sau altul. Project Managementul clasic se referă la proiecte ca la un context în care există un set minim de procese şi reguli şi sunt îndeplinite anumite rolurile concrete, fiind pus accent pe cicluri, mai lungi sau mai scurte, de monitorizare, coordonare şi control.

În realitate însă proiectele IT sunt mult mai imprevizibile decât ar putea fi un joc de şah. Acest lucru se întâmplă pentru faptul ca regulile se schimbă (de multe ori în timpul derulării proiectului), procesele sunt mai mult sau mai puţin respectate, iar unele roluri pot lipsi complet din "peisaj". Spunem adesea că proiectele IT nu sunt fair, surprinzându-ne cu elemente ce le scot din sfera a ceea ce cunoaştem sau am mai întâlnit deja. Aş dori să fiu bine înţeles: pornim deja de la premisa că proiectele, prin definiţia lor, sunt întreprinderi unice, care au elemente ce nu au fost întâlnite până atunci, însă caracteristicile specifice proiectelor IT (despre care am vorbit în detaliu în numărul 8 al Today Software Magazine) fac ca numărul diferenţelor într-un astfel de proiect să fie covârşitor. Iar acest lucru nu se întâmplă în cazul unor excepţii nedorite, ci în marea majoritate a proiectelor IT.

Iar unul dintre motivele principale pentru care project managementul clasic nu s-a dovedit a fi eficient în cadrul proiectelor IT este tocmai faptul că nu acoperă aceste excepţii majoritare.

Este Agile "glonțul de argint" al proiectelor IT?

Metodologia Agile a apărut ca o necesitate în a accepta şi trata "excepţiile" pomenite mai sus și fiind în primul rând, o schimbare de atitudine. Abordarea clasică "forţează" setarea unui anumit context rigid care "garantează" succesul unui proiect și oferă sugestii cu privire la modul în care ar trebui să fie tratate situațiile de excepție pentru reintra în "normal".

Filozofia Agile pornește de la ideea că aceste excepții sunt firești, și nu trebuie neapărat să adaptăm contextul la condițiile noastre, ci mai degrabă să ne adaptăm noi la condițiile impuse de context. Însă noi suntem diferiți. Modul în care reușesc eu să mă transpun și să gestionez o anumită situație cheie diferă de modul în care o fac ceilalți. Sfaturile lor și ideile lor despre cum ar trebui să abordez o anumită problemă îmi sunt folositoare atâta timp cât le trec prin filtrul personal și reușesc să le adaptez la context.Prin urmare Agile trebuie privit ca o stare de spirit, ca un mod de abordare, ca un mindset.

Pentru a mă face mai bine înțeles voi da câteva exemple despre cum nu ar trebui să procedăm în anumite situații.

Conferințele de profil abundă uneori în descrierea unor studii de caz și ale unor povești de succes despre aplicarea Agile. Foarte mulți dintre cei prezenți la astfel de conferințe vin cu speranța că vor găsi sfaturi utile pentru proiectele în care sunt implicați la momentul respectiv. Întrebările sunt foate diverse: "Cât de mare e echipa?", "Echipa este colocată sau nu?", "Product Owner-ul este la client sau din propria organizație?". Toate aceste întrebări au doar darul de a găsi un șablon cât se poate de potrivit care să fie aplicat propriului proiect pentru a garanta succesul. De cele mai multe ori însă acest lucru nu se întâmplă, și este normal să fie așa: sunt atât de multe configurații posibile și situații aparte în proiectele IT, încât este foarte greu să găsești două proiecte similare. Prin urmare, în loc să încercăm să găsim proiecte de succes similare cu ale noastre, principala întrebare pe care ar trebui să o adresăm este: "Cum reușesc să aplic și să adaptez unele dintre lucrurile auzite în rezolvarea propriilor probleme pe care le am în proiect?"

Un alt exemplu este dat de cei care, în diverse situații, spun: "Proiectul pe care lucrez nu este Agile", referindu-se în general la faptul că anumite roluri nu sunt îndeplinite corespunzător, că anumite documente nu au o structură ideală sau că anumite ședințe (sau ceremonii cum sunt ele denumite în Agile Scrum) nu se desfășoară așa cum scrie la carte, uitând faptul că rolurile, documentele sau ceremoniile sunt doar instrumente de lucru Agile. Nu proiectul este Agile, ci modul în care îl abordăm poate fi Agile. Și acest mod de abordare este și cel pe care va trebui să îl aplicăm pentru a adapta aceste instrumente (când e cazul) sau pentru a ne adapta noi la intrumentele pe care le avem la dispoziție. Nu cădeți în capcana de a stabili o singură cale adevărată de abordare Agile a unui proiect!

În sfârșit, o altă greșeală frecventă este aceea de a aplica în mod identic o abordare de succes dintr-un proiect anterior în proiectul curent. Acest lucru este o greșeală deoarece, după cum am mai subliniat, proiectele IT diferă foarte mult unele de celelalte. Într-o companie ce oferă servicii software, așa cum este și 3Pillar Global, acest lucru este dureros, pentru că în cazul fiecărui client pornești aproape de la zero. Fără doar și poate există o experiență în spate care s-a format, însă contextul va fi de fiecare dată altul și multe dintre concluziile trase în trecut nu mai sunt valabile în noua variantă.

Concluzii

O primă concluzie pe care o putem trage este faptul că ideea de best practices în gestiunea proiectelor software nu doar nu ajută foarte mult, dar poate chiar dăuna. Un set de worst practices ar fi mult mai util oricui este responsabil de gestionarea unui proiect IT.

O a doua concluzie este doar o reiterare a unui fapt pe care multă lume pare să-l fi uitat: nu există o formulă Agile. Agile este în principal un set de valori și principii, iar dacă cineva nu își poate imagina modalități de organizare unei echipe de proiect în jurul acestor valori și principii atunci putem spune că acea persoană nu este Agile. Aceast lucru este foarte important de înțeles într-o perioadă în care mulți devin rigizi în susținerea unui mod unic de a fi Agile.

Aș mai sublinia în încheiere că adoptarea unei metodologii Agile poate da naștere în general unei mișcări de rezistență puternice, deoarece afectează toată activitatea unei persoane implicate. În general, din ceea ce am constat eu, lumea nu se plânge de schimbarea stilului de dezvoltare ci de faptul că acesta nu se schimbă. Exista în acest moment o dorință mare de a fi Agile pe toate nivelele de senioritate și în toate categoriile de oameni implicați într-un proiect. Toti vor să devină Agile, dar Agile în sensul în care fiecare dintre ei îl văd. Fiecare are o viziune proprie despre ce înseamnă a fi Agile, fiindu-i adeseori greu să împărtășească această strategie cu ceilalți, dar manifestă o rezistență mare la schimbări în momentul în care direcția de agilitate nu este cea anticipată.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO