În modelul tradițional waterfall, riscurile sunt de obicei detectate și analizate folosind metode tradiționale de management. În zilele noastre, există o oarecare deficiență în ceea ce privește identificarea și prevenirea riscurilor în dezvoltarea de software care urmează principiile Agile. Modele Agile susțin faptul că tratează riscurile implicit. Prin modul în care este definit conceptul, abordarea sa iterativă favorizează o atenție deosebită la riscuri, care pot fi reduse prin diferite practici, cum ar fi continuous software integration. Din păcate, în realitate, modelele de tip agile implementează doar câteva practici din zona de risc al managementului.
Această stare de fapt a impus necesitatea punerii în aplicare a unor remedii. Un prim demers a fost să se obțină opinia unor manageri de proiecte implicați în managementul diferitelor proiecte din toate zonele lumii. În rândurile următoare, vom oferi o analiză referitoare la un chestionar axat tocmai pe această problemă, care a fost lansat nu cu mult timp în urmă.
Managementul de riscuri este o disciplină care se ocupă cu identificarea, monitorizarea și limitarea riscurilor. Managementul de risc ideal/eficient este considerat acela care stabilește o ierarhie a gravității riscurilor. Se acordă prioritate riscurilor care ar cauza mari pierderi și care implică o frecvență ridicată de apariție. În ordine descrescătoare, vor fi vizate riscurile cu probabilitate mai mică de a apărea și cu efecte mai puțin dezastruoase.
Efectiv, managementul de riscuri implică următoarele:
Identificarea riscului.
Analiza fiecărui risc pentru a determina nivelul efectelor negative.
Ierarhizarea riscurilor identificate în funcție de frecvență și de gravitatea consecințelor.
Crearea planurilor de acțiuni (răspunsuri) pentru a aborda riscurile cu prioritatea cea mai mare.
Managementul de risc în procesele agile este similar celui din managementul convențional al riscului, cu mici variații. O prezentare elocventă a ceea ce presupune managementul de risc ar trebui să răspundă la două întrebări esențiale:
Ar fi bine ca riscurile să fie monitorizate doar la nivel de iterație? Răspunsul este Nu.
Considerăm că managementul de risc în agile ar trebui să fie făcut la două nivele : de proiect și de iterație.
Procesul de risc management la nivel de proiect este realizat prin luarea în considerare a datelor generale de proiect și a cerințelor acestuia.
Aceste două procese par a fi separate, dar ele merg mână în mână pe durata de execuție a proiectului.
Este necesar să înțelegem, să identificăm, să monitorizăm și să reducem riscurile la cele două nivele. Managementul de risc la nivel de proiect ar oferi date de intrare pentru managementul de risc la nivel de iterație. Să luăm aminte că nu toate riscurile de la nivelul proiectului, sunt parte din riscurile la nivel de iterație. Unele riscuri pot fi diferite și altele pot fi unice doar la nivelul iterației. Monitorizarea riscurilor se face în timpul iterației, iar sesiunile de analiză a riscurilor ar trebui să aibă loc între iterații. Se recomandă ca situația riscurilor la nivel de iterație și de proiect să fie foarte bine cunoscută.
Cred că fiecare manager de proiect, Scrum master și echipă, ar trebui să înțeleagă cerințele pentru a înțelege riscurile majore care pot apărea într-un proiect. Cel mai probabil, crearea unei liste de verificare (una similară se poate găsi mai jos) care ar putea ajuta la identificarea potențialelor riscuri, reducerea lor încă din stadiile inițiale sau planificarea unor acțiuni de atenuare a lor, ar reduce cu mult costurile proiectului.
Lista de verificare pentru riscuri creată înaintea unei ședințe, poate fi folosită pentru o mai ușoară identificare a acestora. În timpul ședințelor, toate riscurile sunt identificate, discutate și se ajunge la un consens asupra acțiunilor ce se vor lua pentru aplanarea acestora. Lista riscurilor la nivel de proiect și lista riscurilor la nivel de iterație sunt create și făcute cunoscute în interiorul echipei, și vor fi menținute și completate pe parcursul proiectului și a iterației.
Managerul de proiect și/sau Scrum Masterul au obligația să mențină aceste artefacte.
Procesul de management al riscurilor la nivel de proiect include identificarea riscurilor, planificarea, monitorizarea și activitățile de închidere a riscurilor, de la sfârșitul unui proiect. Fiecare din acești pași are importanța sa, explicată în continuare.
La începutul unui proiect, riscurile proiectului sunt identificate dintr-o perspectivă largă. Lista de verificare (dacă se creează) ar putea fi de ajutor în identificarea acestora.
În timpul ședinței de planificare, planurile de atenuare ale riscurilor identificate sunt prezentate. Lista riscurilor la nivel de proiect este creată de managerul de proiect / scrum master, și echipa se poate servi de această listă la nevoie. Această activitate se face numai la demararea proiectului, iar lista de riscuri este actualizată pe parcursul derulării întregului proiect.
Toate riscurile identificate anterior, sunt revizuite și monitorizate în sesiunile dintre iterațiile proiectului. Lista de riscuri este actualizată, marcându-se acele riscuri care s-au închis, sau adăugându-se riscuri noi identificate pe măsura înaintării proiectului. Aceste informații sunt apoi folosite în sesiunile dintre iterații.
Lista riscurilor ar trebui actualizată cu diferite detalii despre ceea ce s-a întreprins în momentul în care echipa s-a confruntat cu diferite riscuri pe parcursul proiectului. Aceasta listă ar fi un bun punct de plecare în alte proiecte viitoare. De asemenea, documente cu cele mai bune practici și cu diferite concluzii ar putea fi create și distribuite între proiecte și echipe.
În imaginea de mai jos se poate observa procesul de management al riscurilor într-un mediu de dezvoltare Agile:
Acest proces începe chiar după prima sesiune de identificare a riscurilor la nivel de proiect. La nivel de iterație, managementul riscurilor implică mai multi pași. În mare, sunt două procese pe parcursul unei iterații, identificarea și planificarea la începutul iterației, și monitorizarea, pe tot parcursul iterației.
La începutul unei iterații, o ședință despre managementul riscurilor este programată. Această ședință este structurată în mai multe etape ca: înțelegerea, identificarea, analiză, prioritizarea și maparea riscurilor. Fiecare etapă are semnificația ei. Această discuție ar trebui să dureze 2 - 3 ore și ar trebui să includă toată echipa. Concluziile discuției similare la nivelul proiectului pot fi folosite ca puncte de pornire pentru aceasta discuție.
Fiecare etapă este detaliată mai jos.
Înțelegerea: echipa ar trebui să aibă o imagine foarte clară asupra cerințelor de funcționalitate cât și a celor non-funcționale. Înțelegerea cerințelor poate fi foarte folositoare în procesul de identificare a riscurilor la nivel de iterație.
Identificarea: din momentul în care avem o primă versiune a backlog-ului produsului și o bună înțelegere a cerințelor, echipa ar putea începe procesul de identificare a riscurilor. În timpul sesiunii, fiecare membru al echipei ar trebui să identifice riscurile potențiale. Sunt multe metode de a modela această sesiune, iar un mod simplu și eficient ar putea fi ceva similar cu identificarea cerințelor unui proiect folosind post-it-uri . Ca o regulă de urmat, în această sesiune, nu ar trebui adresate întrebări și nici nu ar trebui se creeze discuții pe marginea cerințelor. De ce? Deoarece această sesiune are un anumit timp fix alocat, care nu ar trebui depășit.
Analiza: în această etapă, colaborarea între membrii echipei va avea un rol foarte important. Fiecare risc identificat trebuie analizat și clasificat într-o o categorie logică sau arie. De exemplu: infrastructura, proces, dependințe externe, etc. . În timpul acestui proces, fiecare risc este cuantificat și i se dă o valoare (scala nu este predefinită, dar ar trebui să fie simplă). Odată clasificarea terminată, riscurile de aceeași categorie sunt grupate și valorile lor însumate. În locul valorilor nominale, o altă posibilitate de a grupa riscurile ar fi pe baza unor probabilități de apariție, sau al valorii impactului riscului respectiv.
Stabilirea ierarhiei riscurilor : în momentul în care toate riscurile sunt clasificate și evaluate, acestea sunt ordonate descrescător, începând cu grupul cu cea mai mare valoare în fruntea listei. Pentru o iterație, luați primele trei grupuri și amânați discuțiile despre restul grupurilor pentru o alta ședință viitoare. Pe parcursul execuției unei iterații, versiunea precedentă a listei riscurilor (actualizată în timpul iterației precedente) este consultată pentru a identifica riscurile care încă sunt prezente. Acest proces va fi repetat până la finalul proiectului.
Maparea: maparea este un exercițiu rapid care se face înainte de a da startul iterației. Primele cinci cele mai importante riscuri sunt mapate cu cerințele din backlog. Acest lucru este esențial pentru ca riscurile să fie foarte atent urmărite în timpul în care cerințele sunt implementate. Dacă nu s-a creat un backlog, acum e momentul să fie creat. Apoi ar trebui creată și lista riscurilor din iterație, împreună cu un plan de atenuare și un plan de răspuns pentru fiecare din riscurile identificate. Această listă va fi un punct de referință pentru echipă, pe tot parcursul iterației. Acest document este menținut și actualizat în timpul execuției iterației.
Poza de mai jos arată procesul uzual de management al riscurilor la nivel de iterație, detaliind pașii implicați.
Monitorizarea este cheia procesului de management al riscurilor. Aceasta trebuie să existe pe parcursul întregii execuții a iterației. Echipa răspunde și reacționează la riscuri cum și când apar în timpul execuției, dar și pe baza listei de riscuri. Scrum master-ul/managerul de proiect ține o evidență a fiecărui risc din iterație. În cazul în care un risc amânat inițial totuși apare în iterația curentă, acest risc trebuie să fie parte din iterația următoare. Nu trebuie să pierdem din timpul acestei iterații pentru riscurile amânate, doar dacă acele riscuri devin atât de critice încât este necesar să fie cercetate în iterația curentă.
Anul trecut, mai multe sondaje s-au efectuat în întreaga lume, implicând diferiți manageri de proiect de la companii mai mari sau mai mici, despre riscuri și managementul acestora. Am găsit recent un sondaj interesant din Europa de Est, incluzând aproximativ 70 de manageri de proiect, cu obiectivul de a afla care sunt practicile uzuale relative al managementul riscurilor din managementul Agile al proiectelor.
Rezultatele au fost următoarele:
67% din respondenți analizează riscurile proiectului săptămânal.
87% din respondenți susțin că managerul de proiect este cel responsabil de managementul riscurilor.
Respondenții au fost întrebați cine este responsabil principal de identificarea riscurilor. Răspunsurile au fost: echipa proiectului și membrii ei (80%), managerul de proiect (67%), echipa de dezvoltare și membrii ei (40%) și scrum master-ul (40%).
În același timp, 73% din respondenți folosesc o listă de riscuri pentru documentare, analiză și mentenanță, iar restul de 23% folosesc o altă tehnică de monitorizare sau nu documentează riscurile în nici un mod.
Respondenții au fost întrebați și care sunt atributele riscurilor pe care le documentează și le țin sub observație. Răspunsurile se pot vedea în graficul de mai jos. Respondenții au fost întrebați care din ceremoniile din Scrum este cea mai potrivită / folosită pentru a discuta riscurile cu echipa de development. Răspunsurile lor se pot vedea în graficul următor.
Există foarte multă informație și foarte multe detalii despre instrumente specifice folosite în identificarea, clasificarea (pe baza unor indicatori cantitativi sau calitativi), și monitorizarea riscurilor în timpul iterațiilor.
Chiar dacă utilizarea metodelor Agile reduce riscurile încă din fazele inițiale ale dezvoltării de software, trebuie să luăm în considerare tendința actuală de a include timp într-o manieră mult mai formalizată și pentru managementul riscurilor.
"Risc este pauză în livrare, nu muncitori inactivi" - Ken Rubin
Risk Management in Agile Model - Monika Singh & Ruhi Saxena
Project Risk Management model based on Prince2 and Scrum Frameworks - Martin Tomanel and Jan Juricek
