Managementul proiectelor software Agile: de la sprinturi la guvernanța portofoliului

Agile în dezvoltarea software: ce se schimbă față de PM-ul tradițional

Managementul de proiect tradițional presupune că un proiect poate fi definit de la început: domeniu, calendar, buget, resurse. Sarcina managerului de proiect este să planifice totul, să obțină aprobarea și apoi să urmărească execuția față de plan. Agile presupune opusul: că cerințele se vor schimba, că planificarea detaliată dincolo de următoarele săptămâni este ficțiune și că valoarea vine din livrarea de software funcțional în cicluri scurte în loc de o livrare mare la final. Pentru un manager de proiect aceasta este o schimbare reală, nu cosmetică. Planul devine progresiv în loc de fix, raportarea stării devine săptămânală în loc de bazată pe repere, iar succesul se măsoară prin valoarea livrată în loc de respectarea calendarului inițial.

Schimbările se împart în trei categorii. În primul rând, planificarea trece de la exhaustivă la progresivă: o foaie de parcurs de nivel înalt acoperă câteva luni, dar planificarea detaliată se extinde doar la următorul sprint sau două. În al doilea rând, controlul trece de la abaterea de calendar la velocity și throughput: managerul de proiect încetează să întrebe dacă suntem în graficul Gantt și începe să întrebe câtă valoare am livrat în acest sprint. În al treilea rând, comunicarea trece de la rapoarte de stare formale la o transparență continuă: sprint review, retrospectiva și daily standup înlocuiesc ședințele săptămânale ale managerului de proiect ca principale canale de informare. Niciuna dintre aceste schimbări nu îl face pe managerul de proiect redundant, dar schimbă ceea ce face. Dacă ai nevoie de o definiție mai completă a Agile în sine, ghidul nostru Ce este Agile? acoperă bazele; restul acestui articol presupune acea fundație și se concentrează pe practica managerului de proiect.

Modelul operațional al managerului de proiect Agile: sprinturi, ceremonii, artefacte

Munca managerului de proiect Agile se desfășoară într-o cadență de sprint, de obicei două până la patru săptămâni pe iterație. Înțelegerea ciclului din perspectiva managerului de proiect (nu a dezvoltatorului) este diferența dintre a conduce un proiect Agile și a doar participa la ceremonii.

Mecanica sprintului: planificare, execuție, review, retrospectivă

Sprintul are patru puncte în care rolul managerului de proiect este distinct. Planificarea sprintului este momentul în care echipa se angajează la un set de povești, iar sarcina managerului de proiect este să se asigure că angajamentul este realist având în vedere dependențele cunoscute, capacitatea și constrângerile externe. Execuția este momentul în care managerul de proiect înlătură obstacolele pe care echipa nu le poate gestiona singură: blocaje de achiziții, indisponibilitatea părților interesate, dependențe între echipe. Sprint review este momentul în care echipa demonstrează software funcțional părților interesate, iar sarcina managerului de proiect este să traducă rezultatele tehnice în limbaj de business pentru sponsor. Retrospectiva este momentul în care echipa își îmbunătățește procesul, iar managerul de proiect contribuie cu context între echipe pe care echipa s-ar putea să nu îl vadă. Velocity, măsurată ca story point-uri finalizate pe sprint, devine principala intrare de prognoză a managerului de proiect: cu trei sau patru sprinturi de istoric, prognozarea datelor de lansare devine un exercițiu matematic în loc de o presupunere.

Gestionarea backlogului: de la viziune la sprint

Product backlog-ul este lista principală a tot ce ar putea construi echipa; sprint backlog-ul este submulțimea angajată pentru sprintul curent. Product Owner-ul deține prioritățile din product backlog, dar managerul de proiect contribuie cu context pe care Product Owner-ul s-ar putea să nu îl aibă: dependențe între proiecte, repere de business care constrâng secvențierea, termene de reglementare sau conformitate. Estimarea în story point-uri este mecanismul prin care echipa dimensionează munca raportat la ea însăși, nu în timp absolut, iar managerul de proiect ar trebui să o înțeleagă suficient de bine încât să conteste estimările care ies din tipar, fără a face el însuși estimarea. Când echipa estimează o poveste la 13 puncte iar istoricul arată povești similare la 5, acesta este un semnal care merită investigat.

Artefacte și raportare: burndown, velocity, flux cumulativ

Trei artefacte propulsează raportarea managerului de proiect Agile. Graficul burndown arată munca rămasă față de timp într-un sprint, iar forma sa dezvăluie dacă echipa va îndeplini angajamentul sprintului. Tendințele velocity pe mai multe sprinturi dezvăluie capacitatea și stabilitatea echipei: o velocity în creștere înseamnă adesea că echipa devine mai pricepută cu baza de cod, o velocity plată sugerează o stare stabilă, iar o velocity în scădere semnalează adesea datorie tehnică sau perturbare a echipei. Diagramele de flux cumulativ arată elementele de lucru pe stări (backlog, în lucru, review, terminat) și dezvăluie blocajele: dacă munca în curs se umflă în timp ce cea terminată rămâne plată, echipa are o problemă de flux de rezolvat. Sarcina managerului de proiect nu este să producă aceste artefacte (instrumentele Agile le generează automat), ci să le citească și să traducă semnalele lor într-o raportare adecvată sponsorului.

Roluri și responsabilități în echipele software Agile

Cel mai neînțeles element al Agile în dezvoltarea software este unde se încadrează managerul de proiect. Scrum definește trei roluri (Product Owner, Scrum Master, echipa de dezvoltare) și nu include un manager de proiect. În practică, majoritatea implementărilor Agile din companii au în continuare manageri de proiect, iar înțelegerea a ceea ce fac ei cu adevărat previne modul de eșec frecvent în care managerul de proiect și Scrum Master-ul se suprapun sau intră în conflict.

Rolul managerului de proiect în echipele Agile

Managerul de proiect într-o echipă Agile este responsabil pentru rezultatele vizibile în afara echipei: livrarea către sponsori, coordonarea între echipe, raportarea la nivel de portofoliu, escaladarea riscurilor și alinierea cu business-ul. Managerul de proiect nu conduce ceremoniile sprintului (acesta este teritoriul Scrum Master-ului) și nu decide prioritățile funcționalităților (acesta este teritoriul Product Owner-ului). Autoritatea managerului de proiect este axată pe livrare: deține data de livrare față de business, bugetul cheltuit, dependențele cu alte echipe și comunicarea cu părțile interesate din afara echipei. În practică, aceasta înseamnă că managerul de proiect trăiește în spațiul dintre echipă și organizație, traducând în ambele direcții și înlăturând obstacolele organizaționale pe care echipa nu le poate rezolva intern.

Product Owner, Scrum Master, echipa de dezvoltare

Product Owner-ul deține product backlog-ul, prioritizează funcționalitățile și reprezintă clientul în fața echipei. Scrum Master-ul facilitează ceremoniile, înlătură impedimentele la nivel de echipă și îndrumă echipa în practica Agile. Echipa de dezvoltare (de obicei cinci până la nouă membri) construiește software-ul, se auto-organizează în jurul angajamentului sprintului și se angajează la povești specifice în fiecare sprint. Aceste roluri sunt tratate mai în detaliu în ghidul nostru despre Scrum Master și în ghidul despre Product Owner; ideea pentru managerii de proiect este că aceste trei roluri se ocupă de munca orientată către echipă, în timp ce managerul de proiect se ocupă de munca orientată către organizație.

Părți interesate și direcționare: cum se conectează proiectele Agile la business

O echipă Agile nu livrează unui client abstract; livrează unui context de business cu sponsori, comitete de direcție și proprietari de business care trebuie să ia decizii pe baza progresului echipei. Managerul de proiect structurează această conexiune prin trei mecanisme: actualizări periodice către sponsor care traduc rezultatele sprintului în termeni de business, o cadență a comitetului de direcție (de obicei lunară) în care se iau deciziile majore, și o relație cu proprietarul de business în care primesc răspuns întrebările zilnice despre produs. Fără aceste structuri, echipa dispare din vizibilitatea organizațională, iar organizațiile reacționează adăugând o supraveghere de tip cascadă care subminează flexibilitatea Agile. Sarcina managerului de proiect este să facă Agile lizibil pentru organizație fără a-l face să înceteze să fie Agile.

Framework-uri în dezvoltarea software: Scrum, Kanban, Scrumban, SAFe

Nu orice echipă Agile ar trebui să folosească Scrum. Alegerea framework-ului este o decizie a managerului de proiect care depinde de tiparul de lucru al echipei, de maturitatea Agile a organizației și de natura software-ului construit. Cele patru framework-uri de mai jos acoperă majoritatea dezvoltării software Agile din companii.

Scrum este clasicul bazat pe sprinturi. Iterații de lungime fixă (de obicei două săptămâni), ceremonii definite și un sprint backlog angajat. Cel mai potrivit pentru echipe care construiesc funcționalități noi într-o cadență predictibilă, cu un Product Owner capabil să se angajeze la un domeniu de sprint stabil. Slab pentru echipe cu multă muncă de mentenanță sau unde domină prioritățile dictate de întreruperi. Tratat în detaliu în introducerea noastră în metodologia Scrum.

Kanban este flux continuu, nu bazat pe sprinturi. Elementele de lucru se deplasează prin coloane (backlog, în lucru, review, terminat) cu limite de muncă în curs care controlează fluxul. Cel mai potrivit pentru echipe de suport, muncă de mentenanță și echipe unde prioritățile se schimbă mai frecvent decât lungimea unui sprint. Slab pentru echipe care au nevoie de o cadență de lansare predictibilă legată de limitele sprintului. Vezi ghidul nostru despre fluxul de lucru Kanban și ghidul despre tabla Kanban.

Scrumban le hibridizează pe cele două: ceremonii Scrum pentru planificare și review, tablă Kanban pentru gestionarea zilnică a muncii. Util pentru echipe în tranziție de la Scrum la Kanban (de obicei când Scrum pare prea greoi) sau de la Kanban la Scrum (de obicei când echipa are nevoie de mai multă disciplină în jurul angajamentului). Adesea alegerea pragmatică pentru echipe care depășesc Scrum-ul strict fără a dori să abandoneze complet iterațiile.

SAFe (Scaled Agile Framework) este pentru organizații care coordonează mai multe echipe Agile pe un program sau produs comun. Suprapune o planificare la nivel de program (Program Increment planning, de obicei trimestrială) peste Scrum-ul la nivel de echipă. Util pentru companii cu zeci de echipe Agile care lucrează la același produs. Excesiv pentru organizații cu mai puțin de 5-10 echipe; ia în considerare LeSS sau Nexus ca alternative mai ușoare.

Alegerea nu este permanentă. Organizațiile Agile mature trec adesea de la un framework la altul pe măsură ce se schimbă componența echipei, maturitatea produsului și contextul organizațional. Sarcina managerului de proiect în timpul alegerii framework-ului este să facă vizibile compromisurile și să testeze alegerea față de modul în care lucrează echipa cu adevărat, nu față de modul în care puriștii Agile spun că ar trebui să lucreze echipa.

Puntea dintre Agile și PMO: instrumentar pentru portofolii mixte

Cea mai mare parte a dezvoltării software din companii are loc în organizații care derulează și proiecte non-software: inițiative de business, campanii de marketing, investiții de capital, programe de conformitate. Aceasta creează o problemă de instrumentar pe care majoritatea textelor despre Agile o ignoră.

Problema portofoliului mixt: dezvoltatorii în Jira, business-ul în PPM

Dezvoltatorii preferă net Jira (sau Azure DevOps) pentru că se potrivește fluxului lor de lucru: urmărire la nivel de poveste, table de sprint, grooming al backlogului, integrare cu controlul versiunilor. Echipele de business preferă sistemele PPM (managementul portofoliului de proiecte) pentru că se potrivesc fluxului lor de lucru: urmărirea reperelor, gestionarea bugetului, dashboarduri la nivel de portofoliu, capacitatea resurselor între proiecte. Conducerea are nevoie de o singură vedere asupra întregului portofoliu, Agile și cascadă împreună. Când fiecare domeniu folosește instrumentul său nativ, organizația ajunge cu trei surse de adevăr: vederea dezvoltatorilor în Jira, vederea proprietarilor de business în PPM și vederea conducerii asamblată manual în slide-uri pentru fiecare comitet de direcție. Acesta este modul de eșec la care ajung majoritatea companiilor când adopția Agile crește fără o strategie de instrumentar.

Cum integrezi instrumentele Agile cu un sistem de portofoliu de proiecte

Răspunsul curat din punct de vedere arhitectural este să păstrezi munca la nivel de echipă în Jira (unde îi este locul) și munca la nivel de portofoliu într-un PPM (unde îi este locul), cu o integrare care le sincronizează pe cele două. Ce ar trebui să se sincronizeze: starea la nivel de sarcină (deschis, în lucru, terminat), atribuirea proprietarului, datele și story point-urile sau estimările. Ce nu ar trebui să se sincronizeze: comentariile zilnice, granularitatea sub-sarcinilor, câmpurile specifice dezvoltatorilor. Supra-sincronizarea creează zgomot; sub-sincronizarea creează lacune. Tiparul corect este ca dezvoltatorii să lucreze natural în Jira, managerii de proiect și PMO să vadă în PPM submulțimea relevantă pentru portofoliu a muncii din Jira alături de proiectele non-Jira, și nimeni să nu fie nevoit să se autentifice într-un instrument care nu este spațiul său principal de lucru.

Integrarea FlexiProject-Jira în practică

FlexiProject implementează acest tipar cu o integrare directă cu Jira care importă epics, povești și sarcini din Jira păstrând starea, proprietarul și tipul. Filtrele JQL le permit managerilor de proiect să selecteze exact ce elemente de lucru apar în vederea FlexiProject, iar importurile pot extrage din mai multe proiecte Jira simultan pentru programe între echipe. Maparea utilizatorilor rezolvă problema frecventă în care aceeași persoană are identificatori diferiți în Jira și în PPM: maparea se configurează o singură dată și apoi este automată, astfel încât proprietatea sarcinilor rămâne consecventă în ambele sisteme. Rezultatul este că sarcinile din Jira apar în calendarul FlexiProject alături de sarcini de business, sarcini de marketing și altă muncă non-software – conducerea și PMO văd întregul portofoliu fără a se autentifica vreodată în Jira, în timp ce dezvoltatorii continuă să lucreze în instrumentul lor preferat. Articolul dedicat integrării FlexiProject-Jira tratează configurarea tehnică mai în detaliu.

Guvernanță și raportare pentru proiecte Agile într-un PMO

PMO-urile guvernează proiectele Agile diferit de proiectele în cascadă, iar a face asta corect este locul în care majoritatea companiilor se chinuie. Modul de eșec este aplicarea guvernanței în cascadă (urmărire detaliată a calendarului, aprobări de repere, control al schimbărilor de domeniu) la munca Agile, ceea ce produce fricțiune fără a adăuga valoare de supraveghere.

Metrici care contează pentru raportarea PMO Agile

Nu orice metrică Agile își are locul într-un raport PMO. Graficele burndown și velocity sunt metrici la nivel de echipă utile pentru echipa însăși; a le arăta unui sponsor invită la micromanagement fără a adăuga valoare de decizie. Metricile care își au locul în raportarea PMO sunt orientate spre rezultate: cycle time (cât durează de la angajament la livrare), throughput (funcționalități livrate pe perioadă), rata defectelor scăpate (calitatea livrării) și rata de succes a obiectivului de sprint (dacă angajamentele sunt îndeplinite). Aceste metrici răspund la întrebările pe care sponsorii le pun cu adevărat: livrăm, se menține calitatea, sunt angajamentele realiste. Metricile interne sprintului rămân la echipă; metricile la nivel de portofoliu merg la PMO.

Vedere la nivel de portofoliu: amestecarea proiectelor Agile și în cascadă

Un proiect Agile fără date de final ferme și un proiect în cascadă cu repere fixe trebuie să apară în aceeași vedere de portofoliu, iar reconcilierea ritmurilor lor diferite este locul în care instrumentele PMO își merită costul. Tiparul pragmatic este rolling wave: proiectele Agile arată un val angajat pe termen scurt (următoarele unu până la trei sprinturi) la nivel detaliat, iar valurile viitoare la nivel de estimare. Proiectele în cascadă arată repere și dependențe cu aceeași greutate vizuală ca valurile Agile. Vederea de portofoliu le arată pe ambele în același timp, sponsorul putând vedea că următoarea lansare a echipei Agile se aliniază cu (sau ratează) reperul de tranziție al proiectului în cascadă. Abordările de management de proiect hibrid tratează aceeași problemă de reconciliere la nivel de proiect; instrumentele la nivel de portofoliu o scalează la nivelul întregii organizații.

Managementul riscurilor în proiectele Agile

Proiectele Agile au un profil de risc propriu pe care managementul tradițional al riscurilor adesea îl ratează. Eșecul sprintului (echipa nu finalizează poveștile angajate) semnalează probleme de estimare sau planificare și justifică o investigație, nu învinovățire. Varianța velocity de la un sprint la altul semnalează adesea o perturbare a echipei (membri noi, boală, priorități concurente) pe care managerul de proiect o poate aborda. Riscul de dependență între echipe este cea mai mare sursă unică de întârziere în Agile la scară: dacă sprintul echipei A depinde de munca finalizată a echipei B, iar B întârzie, A se blochează. Acumularea de datorie tehnică este un risc ascuns care reduce velocity în timp fără niciun defect vizibil. Registrele de riscuri ale PMO ar trebui să capteze aceste riscuri specifice Agile alături de riscurile de proiect tradiționale, iar cadența de revizuire ar trebui să corespundă limitelor sprintului mai degrabă decât ciclurilor lunare ale managerului de proiect.

Întrebări frecvente: managementul proiectelor software Agile

Care este diferența dintre un manager de proiect și un Scrum Master?

Scrum Master-ul facilitează echipa intern: conduce ceremoniile, îndrumă în practica Agile, înlătură impedimentele la nivel de echipă. Managerul de proiect livrează organizației extern: gestionează comunicarea cu sponsorul, dependențele între echipe, bugetul, raportarea de portofoliu și obstacolele organizaționale pe care echipa nu le poate rezolva singură. În echipele mici, o persoană poate juca ambele roluri, dar în Agile-ul din companii sunt distincte: Scrum Master-ul deține sănătatea echipei, managerul de proiect deține responsabilitatea livrării față de business.

Cum planifici o lansare cu echipe Agile?

Planificarea lansării combină velocity a echipei (puncte finalizate pe sprint) cu backlogul lansării (puncte estimate pentru domeniul lansării) pentru a produce un interval probabil al datei de lansare. Trei sprinturi de istoric de velocity oferă o prognoză utilizabilă; zece sprinturi oferă una fiabilă. Datele de lansare se exprimă ca intervale (P50 și P80) în loc de puncte și se rafinează pe măsură ce se finalizează mai multe sprinturi. Lansările cu dată fixă necesită flexibilitate de domeniu; lansările cu domeniu fix necesită flexibilitate de dată.

Cum se încadrează Agile într-un portofoliu cu proiecte în cascadă?

Proiectele Agile și în cascadă coexistă în portofoliu printr-un sistem de management al portofoliului care le arată pe ambele la granularitatea potrivită. Proiectele Agile arată munca angajată pe termen scurt în detaliu și munca viitoare la nivel de estimare; proiectele în cascadă arată repere și dependențe. Vederea de portofoliu scoate la iveală dependențele între proiecte (lansarea echipei Agile blochează go-live-ul proiectului în cascadă) astfel încât PMO-urile să poată gestiona portofoliul mixt fără a forța o metodologie în forma celeilalte.

De ce instrumente au nevoie managerii de proiect Agile în afară de Jira?

Jira gestionează bine munca Agile la nivel de echipă, dar nu gestionează bine PPM la nivel de portofoliu. Managerii de proiect Agile au de obicei nevoie de un sistem PPM care se integrează cu Jira (importând sarcini, stări și estimări) pentru raportare la nivel de portofoliu, dependențe cu proiecte non-Agile, gestionarea bugetului pe întregul proiect și dashboarduri executive. Fie că PPM-ul este FlexiProject, Planview sau altă platformă, tiparul de integrare este același: dezvoltatorii rămân în Jira, managerii de proiect și PMO lucrează în PPM, integrarea le menține pe ambele sincronizate.

Cum gestionezi proiectele cu domeniu fix și termen fix cu Agile?

Proiectele pur cu domeniu și termen fixe nu se potrivesc bine cu Agile-ul pur, dar sunt frecvente în industrii reglementate, proiecte de conformitate și contracte cu furnizori. Răspunsul pragmatic este hibrid: angajament de domeniu și termen de tip cascadă la nivel de proiect, execuție de tip Agile în interior. Sprinturile livrează incremental către termenul fix, sprinturile timpurii producând funcționalitate minim viabilă iar cele ulterioare adăugând finisaj. Compromisurile de domeniu se fac prin control explicit al schimbărilor în loc de rafinare continuă, protejând angajamentul de termen.

Cum faci ca PM-ul Agile să funcționeze în practică

Managementul proiectelor software Agile nu înseamnă să conduci ceremonii de sprint sau să scrii story point-uri. Înseamnă să livrezi cu succes proiecte software într-o organizație care derulează și muncă non-Agile, unde managerul de proiect se situează între o echipă Scrum și un PMO care are nevoie de vizibilitate la nivel de portofoliu. Sarcina managerului de proiect este diferită de cea a Scrum Master-ului: Scrum Master-ul deține sănătatea echipei, managerul de proiect deține responsabilitatea livrării față de business. Modelul operațional al managerului de proiect funcționează pe cadența sprintului dar raportează în metrici de rezultat, folosește framework-uri Agile potrivite tiparului de lucru al echipei și integrează munca de echipă bazată pe Jira într-o vedere de portofoliu bazată pe PPM. Guvernanța și raportarea se adaptează la ritmul Agile în loc să forțeze Agile în tipare de raportare în cascadă. Instrumentarul contează: fără integrare între Jira și un sistem PPM, organizația ajunge cu trei surse de adevăr și niciuna completă. FlexiProject susține acest tipar printr-o integrare directă cu Jira care importă epics, povești și sarcini cu starea, proprietarul și tipul păstrate, selecție filtrată prin JQL, mapare a utilizatorilor între sisteme și o vedere unificată a calendarului în care munca din Jira apare alături de proiectele non-Agile. Conducerea vede întregul portofoliu, dezvoltatorii rămân în instrumentul lor preferat, iar managerii de proiect încetează să reconstruiască aceeași vedere în trei locuri în fiecare săptămână. Sarcina managerului de proiect Agile este să facă asta să funcționeze în practică, nu doar să știe cum ar trebui să funcționeze în teorie.