Beneficiile Metodologiei Agile

Se vorbește mult despre Metodologia Agile.

Și pe bună dreptate.

Pentru că echipele care vor să fie în ritm cu tendințele, să-și mențină clienții mulțumiți pe termen lung, evoluează. Și nu uită că satisfacția membrilor echipei e la fel de importantă.

Așadar, produs livrat rapid, costuri reduse, clienți și echipa mulțumită.

Cum adică?

Metodologia Agile este o modalitate de a gestiona un proiect prin împărțirea lui în mai multe faze. Implica colaborarea constantă cu părțile interesate și îmbunătățirea continuă în fiecare etapă. Odată ce începe munca, echipele parcurg un proces de planificare, execuție și evaluare. Colaborarea continuă este vitală, atât cu membrii echipei, cât și cu părțile interesate din proiect.

Valoarea supremă în aplicarea Metodologiei Agile este aceea că permite echipelor să ofere valoare mai rapid, cu o calitate și predictibilitate mai mari și cu aptitudini îmbunătățite de a răspunde la schimbări. Scrum și Kanban sunt două dintre cele mai utilizate metodologii Agile.

Învață cum să aplici instrumentele Agile ca să lansezi rapid proiectele și să te bucuri de o rată înaltă a succesului participând cu echipa la cursul: Metodologia Agile, unde vei primi un program adaptat specificului activității companiei tale.

CARE SUNT BENEFICIILE METODOLOGIEI AGILE?

• Pentru clienți. Aceștia constată că furnizorul este mai receptiv la solicitările de dezvoltare. Caracteristicile de mare valoare sunt dezvoltate și livrate mai rapid, cu cicluri scurte în comparație cu ciclurile lungi care se aplică în cazul metodologiilor clasice de tip cascadă.
• Pentru vendori. Furnizorii reduc risipa prin concentrarea efortului de dezvoltare pe caracteristicile de mare valoare în așa mod reducând timpul de lansare pe piață a produsului. În rezultat se reduc și cheltuielile, iar eficiența crește. Ca rezultat, satisfacția îmbunătățită a clientului duce către creșterea retenției acestuia și la referințe pozitive pentru furnizor.
• Pentru echipa de dezvoltare. Membrilor echipei le place munca de dezvoltare și le place să-și vadă munca folosită și apreciată. Scrum aduce beneficii membrilor echipei prin reducerea muncii neproductive (de exemplu, scrierea specificațiilor sau alte artefacte pe care nimeni nu le folosește) și oferindu-le mai mult timp pentru a face munca care le place. Membrii echipei știu, de asemenea, că munca lor este apreciată, deoarece cerințele sunt alese pentru a maximiza valoarea pentru clienți.
• Pentru Product Manageri. Managerii de produs, care de obicei ocupă rolul de Product Owner, sunt responsabili pentru a face clienții fericiți, asigurându-se că munca de dezvoltare este aliniată cu nevoile clienților. Scrum face această aliniere mai ușoară, oferind oportunități frecvente de re-prioritizare a muncii, pentru a asigura livrarea produsului cu maximum valoare.
• Pentru Project Manageri. Managerii de proiect care ocupă rolul de ScrumMaster constată că planificarea și urmărirea sunt mai ușoare și mai concrete, în comparație cu procesele în cascadă. Accentul pe urmărirea îndeplinirii sarcinii, utilizarea Burndown Charts pentru a afișa progresul zilnic și întâlnirile zilnice Scrum, toate împreună oferă managerului de proiect o conștientizare extraordinară despre starea proiectului în orice moment. Această conștientizare este esențială pentru monitorizarea proiectului și pentru identificarea și abordarea rapidă a problemelor.
• Pentru PMO și directori de nivel C. Scrum oferă o vizibilitate ridicată zilnică asupra stării de dezvoltare a unui proiect. Părțile interesate externe, cum ar fi directorii de nivel C și personalul din Biroul de management al proiectelor, pot folosi această vizibilitate pentru a face planific[ri mai eficient și pentru a-și ajusta strategiile pe baza unor informații mai solide și cu mai puține speculații.

Ce este SCRUM?

Scrum este un subset al Agile. Este cel mai utilizat și ușor cadru de proces pentru dezvoltarea agilă.

Un „cadru de proces” este un anumit set de practici care trebuie urmat pentru ca un proces să fie în concordanță cu cadrul. (De exemplu, cadrul procesului Scrum necesită utilizarea ciclurilor de dezvoltare numite Sprints, framework-ul XP necesită programare în perechi și așa mai departe.)

„Ușor” înseamnă că costul general al procesului este menținut la un nivel cât mai mic posibil, pentru a maximiza cantitatea de timp productiv disponibil pentru realizarea de lucruri utile.

Un proces Scrum se distinge de alte procese ale Metodologiei Agile prin concepte și practici specifice, împărțite în cele trei categorii de roluri, artefacte și casete de timp. Acești termeni și alții folosiți în Scrum sunt definiți mai jos. Scrum este cel mai adesea folosit pentru a gestiona dezvoltarea de software și produse complexe, folosind practici iterative și incrementale, dar poate fi aplicat și altor domenii. Scrum crește semnificativ productivitatea și reduce timpul necesar pentru obținerea de beneficii în comparație cu procesele clasice „în cascadă”. Procesele Scrum permit organizațiilor să se adapteze fără probleme la cerințele în schimbare rapidă și să producă un produs care îndeplinește obiectivele de afacere. Un proces Scrum agil aduce beneficii organizației, ajutând-o să:

• Crească calitatea livrabilelor;
• Facă față mai bine schimbărilor;
• Ofere estimări mai bune în timp ce petrece mai puțin timp creându-le;
• Aibă control asupra programului și stării proiectului.

CARE SUNT CERINȚELE SCRUM?

Scrum nu definește exact ce formă trebuie să ia cerințele, ci pur și simplu spune că acestea sunt adunate în Product Backlog și denumite generic „Product Backlog Items” sau „PBI” pe scurt. Având în vedere natura încadrată în timp a unui Sprint, putem de asemenea deduce că fiecare set de lucruri de făcut nu ar trebui să necesite mai mult timp pentru implementare decât durata însăși a Sprintului. Majoritatea proiectelor Scrum împrumută practica „XP” (programare extremă) de a descrie o solicitare de caracteristică drept „User Story”, deși o minoritate folosește conceptul mai vechi de „Use case”.

User Story

Un User Story descrie o caracteristică dorită (cerință funcțională) sub formă narativă. User Story-urile sunt de obicei scrise de Product Owner și sunt responsabilitatea Product Owner-ului. Formatul nu este standardizat, dar are de obicei un nume, un text descriptiv, referințe la documente externe (cum ar fi capturi de ecran) și informații despre cum va fi testată implementarea.

Story

Nu toate cerințele pentru noile dezvoltări de produse/proiecte reprezintă caracteristici pe care le vor folosi utilizatorii finali, însă reprezintă o muncă semnificativă care la fel trebuie făcută. Aceste cerințe deseori, dar nu întotdeauna, reprezintă munca care trebuie făcută pentru a susține funcțiile necesare pentru utilizatorii finali. Le numim „Povești tehnice”. Ele au aceleași elemente ca și poveștile utilizatorilor (User Story-urile), dar nu trebuie să fie transformate în formă narativă dacă nu există niciun beneficiu în acest sens. Poveștile tehnice sunt de obicei scrise de membrii echipei și sunt adăugate la Product Backlog. Product Owner-ul trebuie să fie familiarizat cu aceste povești și să înțeleagă dependențele dintre acestea și User Story-urile pentru a clasifica (secvența) toate poveștile pentru implementare.

Defect

Un defect sau un raport de eroare este descrierea incapacității produsului de a se comporta în modul așteptat. Defectele sunt stocate într-un sistem de urmărire a erorilor, care poate fi sau nu același sistem utilizat pentru stocarea User Story-urilor adică Product Backlog-ul. Dacă nu, atunci cineva (de obicei, Proprietarul produsului) trebuie să introducă fiecare Defect în Product Backlog, pentru secvențiere și programare.

CARE SUNT ROLURILE SCRUM?

Cele trei roluri definite în Scrum sunt ScrumMaster, Product Owner și Echipa (care este formată din membrii echipei). Oamenii care îndeplinesc aceste roluri lucrează împreună îndeaproape, în fiecare zi, pentru a asigura fluxul fluid al informațiilor și rezolvarea rapidă a problemelor.

ScrumMaster

ScrumMaster (uneori scris „Scrum Master”, deși termenul oficial nu are spațiu după „Scrum”) este deținătorul procesului. ScrumMaster este responsabil pentru ca procesul să funcționeze fără probleme, pentru eliminarea obstacolelor care afectează productivitatea și pentru organizarea și facilitarea întâlnirilor critice. Responsabilitățile ScrumMasters includ:

• Îl învață pe Product Owner cum să maximizeze rentabilitatea investiției (ROI) și să-și atingă obiectivele prin Scrum.
• Îmbunătățește viața echipei de dezvoltare facilitând creativitatea și împuternicirea.
• Îmbunătățește productivitatea echipei de dezvoltare în orice mod posibil.
• Îmbunătățește practicile și instrumentele de inginerie, astfel încât fiecare increment de funcționalitate să poată fi livrat.
• Păstrează informațiile despre progresul echipei la zi și vizibile pentru toate părțile.

În termeni practici, ScrumMaster trebuie să înțeleagă Scrum suficient de bine pentru a instrui și a îndruma celelalte roluri, precum și pentru a educa și a ajuta alte părți interesate care sunt implicate în proces. ScrumMaster ar trebui să mențină o conștientizare constantă a stării proiectului (progresul său până în prezent) în raport cu progresul așteptat, să investigheze și să faciliteze rezolvarea oricăror blocaje care împiedică progresul și, în general, să fie suficient de flexibil pentru a identifica și rezolva orice problemă care apare, în orice mod care este necesar. ScrumMaster trebuie să protejeze Echipa de perturbările altor persoane, acționând ca interfață între ei. ScrumMaster nu atribuie sarcini membrilor echipei, deoarece atribuirea sarcinilor este o responsabilitate a echipei. Abordarea generală a ScrumMaster față de echipă este să încurajeze și să le faciliteze capacitățile de luare a deciziilor și de rezolvare a problemelor, astfel încât să poată lucra cu o eficiență crescândă și cu o nevoie în scădere de supraveghere. Scopul este de a avea o echipă care nu numai că este împuternicită să ia decizii importante, dar și să facă asta bine regulat și constant.

Product Owner

Product Owner-ul este păstrătorul cerințelor. Product Owner-ul oferă „sursa unică de adevăr” pentru echipă în ceea ce privește cerințele și ordinea planificată a implementării acestora. În practică, Product Owner este interfața dintre afacere, clienți și nevoile lor legate de produse, pe de o parte, și Echipa, pe de altă parte. Product Owner protejează echipa de solicitările de caracteristici și de remediere a erorilor care provin din mai multe surse și este singurul punct de contact pentru toate întrebările despre cerințele produsului. Product Owner lucrează îndeaproape cu echipa pentru a defini cerințele tehnice și pentru utilizator, pentru a documenta cerințele după cum este necesar și pentru a determina ordinea implementării acestora. Product Owner-ul menține Product Backlog-ul (care este depozitul pentru toate cerințele legate de produs), menținându-l la zi, la nivelul de detaliu și calitate cerut de Echipă. Proprietarul de produs stabilește, de asemenea, programul de eliberare a lucrărilor finalizate către clienți și face apelul final pentru a stabili dacă implementările au caracteristicile și calitatea necesare pentru lansare.

Echipa

Echipa este un grup auto-organizat și inter-funcțional de oameni care fac munca practică de dezvoltare și testare a produsului. Întrucât echipa este responsabilă pentru producerea produsului, trebuie să aibă, de asemenea, autoritatea de a lua decizii cu privire la modul de realizare a lucrărilor. Prin urmare, echipa se auto-organizează: membrii echipei decid cum să împartă munca în sarcini și cum să aloce sarcinile indivizilor, pe tot parcursul Sprintului. Mărimea echipei trebuie menținută în intervalul de la cinci la nouă persoane, dacă este posibil. (Un număr mai mare îngreunează comunicarea, în timp ce un număr mai mic duce la productivitate scăzută și fragilitate.) Notă: Un termen foarte similar, „Echipă Scrum”, se referă la Echipa plus ScrumMaster și Product Owner.

CARE SUNT METRICILE AGILE CE POT FI UTILIZATE PENTRU RAPORTARE?

Ce să măsori în Agile este întrebare de lungă durată. Ar trebui să existe două filtre primare pe care trebuie să ni le punem ca întrebări înainte de a măsura ceva; „Această măsurătoare va accelera livrarea valorii?” și „Această măsurătoare va spori încrederea?”.

Mai jos este un exemplu de măsurare agilă corectă. În mod obișnuit, o organizație își va seta un obiectiv de a crește viteza îndeplinirii unui User Story, s-ar părea că acest lucru este rațional, deoarece ne străduim întotdeauna să oferim mai mult acolo unde este posibil. Cu toate acestea, această perspectivă este totuși privită dintr-un unghi greșit, deoarece ceea ce dorim este obținerea unei valori mai mari, dar nu a unei productivități crescute. Iar aceste lucruri nu sunt una și aceeași; unul este concentrat pe rezultat, iar celălalt este concentrat pe productivitate. Metodologia Agile pune accent pe livrarea de rezultat; ceea ce înseamnă mai multă valoare, dar nu productivitate. Dacă privim lucrurile din perspectivă livrării mai rapide, asta înseamnă următoarele; echipele nu lucrează suficient de mult, iar productivitatea este echivalentă cu valoarea. Din care ambele ipoteze sunt de regulă neadevărate.

Ar trebui să folosim viteza pentru a ne conduce afacerea; o viteză poate fi utilizată pentru a distribui User Stories-urile din Backlog și a planifica o dată aproximativă când anumite caracteristici funcționale ale produselor vor fi disponibile pentru clienții noștri. Ceea ce trebuie să facem este să creștem stabilitatea în viteză, nu viteza în sine care se schimbă sau e în flux. Într-o lume în care există stimulente pentru creșterea vitezei, echipele se vor simți obligate să ofere o viteză mai mare de realizare a User Stories-urilor. Ei vor crește recompensa în realizarea mai rapidă a User Stories-urilor, ceea ce, la rândul său, reduce capacitatea noastră de a conduce afacerea, deoarece în așa situație viteza își pierde sensul.

Dacă ar fi să analizăm cele spuse într-un mod ușor diferit, am putea măsura afirmația cu îndeplinirea User Story-urilor din sprint. Am putea să ne focusăm pe câte User Story-uri s-au îndeplinit într-un Sprint, față de câte au fost planificate din start. Ca rezultat, stimulentul va fi crearea stabilității în previziunea îndeplinirii taskurilor, ceea ce oferă capacitate companiei să prezică mai exact când vor fi lansate pe piață produsele, proiectele.

Prima perspectivă le spune echipelor despre neîncrederea în ele și le deteriorează percepția asupra valorii, pe când a doua variantă promovează atât valoarea ca rezultat cât și stabilitatea în viteza îndeplinirii taskurilor. A doua variantă, surprinde de asemenea echipele cu faptul că se descurcă bine, pe măsură ce estimările lor se adeveresc și se convertesc în performanță. Trecerea la a spune zero oferă afacerii capacitatea de a lua viteză, precum și de a construi încredere în cadrul organizației. Toată lumea câștigă; clienții noștri, organizația noastră și echipa.

Exemplu de metrici operaționale

• Lead Time
• Cycle Time
• Burndown Charts

Eșantion de valori de ieșire

• Throughput
• Agility Assessment Model
• Technical quality / defect measurements / code coverage
• # of features, etc.

Eșantion de rezultat/valoare

• Moralul echipei
• Satisfacția clienților / NPS
• Valoarea afacerii

CARE ESTE CEA MAI BUNĂ ABORDARE HOLISTICĂ A ADOPȚIEI METODOLOGIEI AGILE?

Adesea, atunci când o organizație adoptă Metodologia Agile, se pune accent pe grupul de servicii de inginerie, cu o colaborare marginală cu departamentul de management al produsului. Acest tipar este omniprezent și explică de obicei de ce companiile nu simt că primesc beneficiile pe care le așteaptă de la o adoptare a metodologiei, promovând presupunerea că această metodologie nu funcționează.

Nevoile comerciale, dimensiunea companiei, structura organizațională și o serie de alte considerente creează contextul necesar pentru adoptarea Metodologiei Agile. De departe, sistemul de succes principal necesită includerea tuturor aspectelor afacerii. Gândirea de sistem, este aceea de a înțelege că toate domeniile companiei se ocupă de livrarea de valoare, sunt aliniate și lucrează împreună. Prin urmare, dacă cereți departamentului de inginerie, cu un oarecare suport din partea departamentului de management să adopte metodologia Agile, atunci cu siguranță nu veți reuși.

Din păcate, afacerea va trebui mai mult ca sigur să ia în considerare restructurarea și schimbarea stilurilor de management pentru a obține alinierea organizațională. Cele mai bune rezultate au loc atunci când echipele merg all-in analizând posibilitățile de colaborare cu o minte deschisă.

Câteva exemple sunt atunci când departamentul de contabilitate trece de la Contabilitatea costurilor la Contabilitatea Lean. Un alt exemplu este atunci când departamentul de resurse umane ia în considerare trecerea la OKR și eliminarea MBO și KPI. Valorile companiei se concentrează pe măsurători care se corelează cu livrarea valorii în comparație cu producția.

Cea mai bună abordare atunci când luați în considerare o adoptare a Metodologiei Agile este să țineți cont de contextul organizației dvs., așa cum este descris mai sus. Apoi, fiți incluziv cu echipa de conducere și cu zonele lor de interes, punând accent pe livrarea accelerată a valorii versus producție și utilizare.