Provocari Agile in echipe “operationale” – Dificultatea de a previziona volumul de munca “neplanificata”

Odata cu adoptarea din ce in ce mai frecventa a metodologiei Agile, precum si din nevoia unui continuous delivery pentru a isi mentine competitivitatea si/sau pentru a putea raspunde mai rapid schimbarilor cerute de clienti/comunitate, se observa in companiile de pe piata o crestere semnificativa in ultimii ani a conceptului de DevOps; cand zic crestere, ma refer atat la o prezenta mai pronuntata a pozitiilor dechise in aceasta zona, dar si la numarul de articole, best practice-uri si carti din literatura de specialitate.

Acest articol este primul dintr-o scurta serie ce isi propune sa impartaseasca cu voi cateva din provocarile intalnite in a livra cu success intr-o echipa mixta Ops-DevOps si cateva propuneri pentru a gestiona aceste aspecte, in speranta crearii unei discutii active cu idei si sfaturi cu un avantaj real pentru toti managerii de proiect ce activeaza in aceasta zona.

Pentru astazi:

1. Dificultatea de a previziona volumul de munca “neplanificata”

O echipa operationala este prin esenta centrata pe a oferi intai suport altor echipe partenere. In functie de complexitatea proiectului, numarul de clienti si pozitionarea acesteia in structura organizatioanala a diviziei/firmei, cantitatea de cereri/tichete poate varia. Un lucru este insa clar. Va fi dificil sa planificati, sa comiteti si sa livrati partea “planificata” a muncii (proiecte DevOps, tech improvements, etc) fara a sti care este capacitatea rezervata tichetelor. Un calcul simplu ne-ar spune ca aceasta este egala cu diferenta dintre capacitatea totala disponibila intr-un sprint (sa zicem de 2 saptamani) si ceea ce “puneti deoparte” pentru partea de Operatiuni de zi cu zi – ceea ce am putea numi foarte simplist munca “neplanificata”. Mai jos cateva sugestii pentru o mai buna previzionare a acestui “scope”.

1.1 Combinatii Kanban si Scrum

Pentru a reusi, ne “inarmam” de obicei cu tot ce avem mai bun. In acest caz, am identificat ca fiind de success o combinatie de Kanban si Scrum, ideal ambele configurate in acelasi tool (fie el JIRA, Redmine, Hansoft – sau orice folositi deja si poate fi configurat relativ usor). Vom folosi rapiditatea si flexibilitatea unui simplu board cu deja celebrele stari “To Do”, “In Progress”, “On Hold”, “Ready”, “Done” pentru a primi, asigna, monitoriza si comunica progresul pe tichetele operationale. Vom putea identifica si gestiona cu usurinta blocajele si vom putea tria rapid acele cerinte care necesita mai mult timp si poate o abordare mult mai formala (estimare, planificare, faza de testare, acceptanta) catre backlog.
Avantaje? Pastrarea SLA-urilor, velocitate crescuta, populare semi-automata backlog, comunicare imbunatatita (prin update-urile din ticket) si implicit, satisfactie crescuta din partea multiplilor clienti.
Pentru proiectele identiifcate la inceput de ciclu, pentru tot ce depaseste un anumit threshold de efort (si prin urmare nu se mai incadreaza la tichet, devenind astfel un mini-proiect), pentru munca ce are un caracter periodic (anumite release-uri predictibile, support pentru evenimente cu data fixa, etc) vom folosi Scrum. Abilitatea de a avea un backlog populat cu toate aceste initiative va permite Product Owner-ului sa priortizeze munca impreuna cu leadershipul echipelor de client si sa schiteze un release roadmap viabil.
Avantaje? Comunicare activa si decizii luate in comun cu toate echipele partenere, un grad sporit de predictibilitate pentru echipa ce va permite identificarea si gestionarea timpurie a dependentelor externe critice, planificare mai detaliata. Si din nou, de ce nu, satisfactie crescuta din partea clientilor.

1.2 Tagging-ul corect al request-urilor

Orice aplicatie moderna permite o clasificare primara a tichetelor primare. Cu putin efort, putem atinge nivelul urmator, utilizand componente, sub componente si chiar versiuni. Un minim de disciplina, atat din partea project managerului, dar si a echipei de proiect, va permite o clasificare corecta si in timp real a muncii primate. Aplicatia in sine poate fi configurata sa contina aceste campuri ca fiind obligatorii la inchiderea oricarui tichet. Veti avea cativa colegi vocali pentru o perioada, care va vor multumi insa mai tarziu. [Sau poate nu :)] Recomand de asemenea cu incredere folosirea in timpul planificarii unor “capacity buckets” pentru diferite surse de tichete: infrastructure, design & reviews, release management, Live Ops, client A requests, client B requests, etc.
Avantaje? Vezi punctul (1.3) mai jos, alaturi de o raportare corecta si usoara catre fiecare client in parte – un client informat este un client fericit, sau cel putin nu la fel de suparat atunci cand se depaseste un termen 🙂

1.3 Rolul extrem de important al datelor istorice

Cu o aplicatie corect setata si folosta [zic eu] cel putin un an, vom incepe sa culegem “roadele” muncii corect logate. Datele istorice vor fi cu atat mai valoroase cu cat acestea au fost validate in mai mult de o iteratie: spre exemplu, un deploy al unui release de complexitate X executat de mai multe ori, un tichet de configurare a unui serviciu pe un server de tip Y, etc).
Avantaje? Poate cel mai important lucru. Estimari mai bune pentru munca similara din viitor, cu un impact real in cresterea predictibilitatii in sesiunile de planificare la nivel de echipa.

1.4 Identificarea si managementul rapid ale blocajelor

Board-ul Kanban folosit pentru partea “operationala” a muncii dintr-un sprint va arata pe coloana “On Hold” tot ceea ce este “in asteptare” din varii motive. Echipa aduce de asemenea in stand-up-urile zilnice blocajele, insa un ritm foarte dinamic, specific unei echipe mixte Ops-DevOps poate genera blocaje critice mult mai frecvent si mai rapid. Personal consider ca avem nevoie de mai multe stari pentru un tichet blocat. Desi el este listat in acea coloana, putem folosi un grad suplimentar de triaj cu “pending client response”, “pending external team”, “blocked”, “escalated”. Un management vizual (atat de intalnit in ultima vreme, cu un LCD de dimensiuni generoase intr-un loc vizibil pentru toata echipa) pe care este afisat un dashboard in timp real cu toate tichetele blocate si/sau escalate, ve permite echipei, sau acelei persoane care joaca in acel sprint rolul de “firefighter” sa actioneze rapid asupra lor sau sa escaleze la randul lui managerului de proiect daca acestea necesita gestionarea unei dependeneste externe / suportul imediat al unei echipe partenere. Alte recomandari: marcarea unui ticket ca blocked daca [sa zicem] 2 follow-up-uri fara success cu o echipa partenera, configurare aplicatie pentru a genera tichete in mod automat cu prioritatea corecta pentru anumte comunicari cu cuvinte cheie sau trimise cu “high importance”.
Avantaje? Pastrarea SLA-urilor, informarea clientilor, evitarea pierderilor de capacitate din cauza intarzielor sau follow-up-urilor multiple fara a folosi lantul corect de escalare, sau chiar evitarea scaderii moralulul echipei de proiect.

Aceste 4 simple masuri va pot fi de folos in a tine “sub control” fluxul de request-uri operationale, pentru a putea dimensiona corect capacitatea rezervata muncii de DevOps, si implicit, a va creste sansele de reusita in a livra munca deja comisa.

Voi continua in articolul urmator cu “Managementul dependentelor externe”