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 33
Abonament PDF

Abordare simplă a riscului în Scrum

Sebastian Botiș
Project Manager
@Arobs



MANAGEMENT

Î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:

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:

Considerăm că managementul de risc în agile ar trebui să fie făcut la două nivele : de proiect și de iterație.

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ă.

Lista de verificare

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.

Managementul riscurilor la nivel de proiect

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.

Identificarea riscurilor

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.

Planificarea riscurilor

Î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.

Monitorizarea riscurilor

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.

Managementul riscurilor la terminarea proiectului

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:

 

Procesul de management al riscurilor la nivel de iterație

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.

Startul 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.

 

În timpul iterației

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ă.

Sondaje

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:

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.

 

Concluzii

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

Resurse

  1. Risk Management in Agile Model - Monika Singh & Ruhi Saxena

  2. Project Risk Management model based on Prince2 and Scrum Frameworks - Martin Tomanel and Jan Juricek

  3. Three Key Agile Risk Management Activities - Ken Rubin

NUMĂRUL 138 - Maps & AI

Sponsori

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

INTERVIURI VIDEO

Sebastian Botiș a mai scris