Într-o perioadă în care presiunea din partea pieței și nevoia de creștere a competitivității în toate sectoarele economiei sunt mai mult decât o realitate, industria IT își are locul ei aparte și joacă un rol foarte important ce poate face diferența între companiile care vor fi sustenabile și de succes și în următorul deceniu, investind în inovație, cercetare, eficientizare a proceselor, și cele care se mulțumesc cu ceea ce fac în momentul de față, riscând astfel dispariția de pe piață.
În acest context foarte dinamic, în care una dintre certitudini e schimbarea continuă și adaptarea la noile tendințe ale pieței, provocarea pentru domeniul IT e să își desfășoare activitățile într-o manieră cât mai eficientă, cu livrabile cât mai rapide pe piață, cu o calitate cât mai bună și care să maximize investiția făcută de către acționari.
În mod evident, din punct de vedere al ciclului de viață complet al livrării soluției software, o abordare agilă pare a fi cea mai potrivită alegere în cele mai multe dintre situațiile care urmăresc beneficiile descrise mai sus. Un studiu recent elaborat de Agile Journal arată că peste 88% din companiile de software evaluate (multe cu peste 10.000 de angajați) folosesc deja sau au de gând să folosească practici agile pentru proiectele pe care le implementează.
Ceea ce se întâmplă de obicei în majoritatea companiilor este că acestea își încep experiența agilă prin adoptarea practicilor legate de Scrum - care descriu o strategie foarte bună pentru conducerea activităților unei echipe de dezvoltare. Din nefericire, Scrum-ul reprezintă doar o mică componentă din livrarea unei soluții software finale. Ceea ce se întamplă în multe cazuri este că echipele încep să se uite în stânga și în dreapta, uneori prin studiu propriu, alteori apelând la firme de consultanță pentru a umple golurile pe care Scrum-ul le ignoră în definiția sa, ideile căutate fiind în cea mai mare măsură legate de partea de construcție.
Se poate întâmpla ca multitudinea de surse existente și terminologia folosită să creeze mai multă confuzie decât să aducă rezultatele scontate. Mai mult decât atât, nici profesioniștii din IT nu știu exact unde ar trebui să caute sfaturi pentru situația în se află și care probleme ar trebui tratate în mod primordial.
Un exemplu - Scrum-ul vorbește despre existența unui Product/Scrum backlog și despre cum anume sunt tratate acestea în timpul unui sprint. Dar totuși, intrebare este de unde anume apare acest Product backlog? Apare acesta de nicăieri în proiect? Bineînțeles că nu, fiind rezultatul unei sesiuni de determinare a cerintelor inițiale care reprezintă unul dintre principalele obiective pe care trebuie să le atingem în faza de început a unui proiect.
Soluția pe care o implementăm în cadrul Yonder este una focusată pe o abordare agilă disciplinată prin oferirea de proceduri/sfaturi adaptate pentru fiecare client/proiect în parte. Disciplina constă pe de o parte într-o abordare secvențială și iterativă a proiectului (unde se urmărește atingerea anumitor obiective de-a lungul întregului ciclu de viață al livrării soluției), iar pe de altă parte prin oferirea de sfaturi concrete pentru atingerea fiecărui obiectiv în funcție de contextul proiectului.
Acest lucru este posibil prin adoptarea unor strategii din Scrum - XP, Agile Modeling, RUP, Lean/Kanban, DevOps într-o manieră structurată și se evită o aplicare prescriptivă a unor rețete bine cunoscute - pentru că există riscul ca acestea să nu se potrivească cu contextul proiectului și se merge către atingerea anumitor obiective.
Ideea care stă la bază este destul de simplă: avem de a face cu o abordare bazată pe faze concrete (Incepție, Construcție, Tranziție), în cadrul fiecărei faze existând o serie de obiective bine definite care trebuie atinse. De exemplu, unul dintre obiectivele fazei de Incepție este identificarea scopului inițial al aplicației (funcțional). Abordarea structurată are la bază descrierea mai multor aspecte sau procese care să ajute la îndeplinirea acestui obiectiv. De exemplu, în cazul de mai sus aspectele/procesele care trebuie luate în considerare sunt:
În funcție de contextul în care ne aflăm, vom alege pentru fiecare proces varianta care se potrivește cel mai bine necesităților actuale ale proiectului - dacă este vorba de un proiect în care trebuie să facem și suport putem alege un work item pool ca și modalitate de management al cerințelor de lucru în locul unui scrum product backlog.
Pentru a ne asigura că aceste obiective sunt îndeplinite am introdus milestone-uri pe tot parcursul desfășurarii proiectului. Un exemplu concret al unui astfel de milestone este la finalul fazei de Incepție unde verificăm consensul tuturor părților în legătură cu scopul inițial al aplicației.
Una dintre provocările cele mai mari ale acestei abordări este pe de o parte punerea la dispoziție a cât mai multor proceduri legate de cum anume obiectivele pot fi atinse și, pe de altă parte, evitarea situației de a deveni foarte prescriptivi . Metodologiile existente în momentul de față fie sunt foarte detaliate - când vine vorba de procesele pe care le implică (vezi cazul IBM RUP), fie descriu sumar activități importante din ciclul de viață al proiectului (vezi Scrum pentru partea de identificare a cerințelor inițiale sau instalarea soluției în producție).
Prin aplicarea acestor principii în cadrul tuturor proiectelor pe care le desfășuram în Yonder am reușit să creștem nivelul de satisfacție al clienților noștri, productivitatea crescută fiind unul dintre aspectele care au facut posibil acest lucru.
Această politică orientată către obiective crește foarte mult gradul de transparență în relația cu clienții, așteptările fiind setate și monitorizate corespunzător pe toata durata proiectului. Prin validarea continuă a "business case-ului" și a condițiilor inițiale care au generat proiectul - milestone multiplu în faza de Construcție - ne asigurăm de viabilitatea acestuia și punem la dispoziția factorilor de decizie toate informațiile necesare pentru ca hotărârile care se iau să fie bazate în primul rând pe numere și fapte concrete și mai puțin pe presupuneri.
Un alt aspect important e legat de creșterea calității, care la o primă vedere pare a fi o componentă destul de subiectivă, prin adoptarea celor mai bune practici din metodologiile agile (XP, TDD) pentru a satisface anumite obiective și migrarea acestora către o zonă măsurabilă. Date fiind tendințele actuale de a lucra cu echipe mari, distribuite geografic, care activează în domenii complexe cu soluții tehnice la fel, scalabilitatea se impune ca un aspect important.
Utilizând această abordare bazată pe obiective, în cadrul căreia se încurajează independența echipelor, menținem un nivel optim de guvernanță. În acest caz, scopul - dincolo de livrabilele aferente procesului de dezvoltare software - constă în oferirea unei soluții complete în care nevoile clientului sunt adresate în funcție de situația în care acesta se află. Astfel, punem bazele unui model care poate scala foarte ușor prin folosirea uneltelor potrivite, a practicilor și metodelor de succes dovedite pe alte proiecte.
Această abordare disciplinată și structurată a proiectelor Agile, pe care am îmbrățișat-o în special în cadrul Yonder după obținerea certificarii CMMI level 3, ne-a ajutat la mărirea numărului de clienți actuali datorită exemplelor și rezultatelor pozitive, profesionalizarea serviciilor și creșterea predictibilității prin aplicarea și îmbunătățirea continuă a acestui model.
Pentru ca cei interesați să nu treacă din nou printr-un proces de reinventare a roții și descoperirea tuturor acestor practici într-un mod empiric, cum se întâmplă în cele mai multe situații - un punct foarte bun de start al călătoriei către implementarea unui cadru agil disciplinat este cartea lui Scott Ambler și Mark Lines "Disciplined Agile Delivery".
de Ovidiu Mățan
