SAFe. Nevoile clientului. Rolurile de Product Manager si Product Owner

In articolul nostru anterior am discutat despre Epics si procesele asociate acestora. Insa companiile au clienti cu nevoi care trebuie implementate cat mai repede posibil. Cine coordoneaza toate aceste cereri? Cine le transpune in documente si cerinte pe care echipele mai apoi trebuie sa le implementeze? Cine valideaza rezultatele implementarii?

Oct 16, 2019 114
In articolul nostru anterior am discutat despre Epics si procesele asociate acestora. Insa companiile au clienti cu nevoi care trebuie implementate cat mai repede posibil. Cine coordoneaza toate aceste cereri? Cine le transpune in documente si cerinte pe care echipele mai apoi trebuie sa le implementeze? Cine valideaza rezultatele implementarii? Aici raspunsul este relativ usor deoarece in Scrum exista un rol specific, Product Owner, care se ocupa de aceste activitati. Insa ce se intampla cu aceste activitati si cu acest rol in SAFe? Raspunsul este ca exista, dar cu cateva schimbari.

Product Owner-ul in SAFe (Scaled Agile Framework)

In primul rand cineva trebuie sa se ocupe de clienti. Sa fie mereu in contact cu ei. Sa exploreze constant nevoile lor, sa le raspunda la intrebari si cereri, sa le prioritizeze si sa defineasca un roadmap cu livrabilele. Nu doar asta, dar aceasta persoana trebuie sa fie un expert in domeniul caruia i se adreseaza produsul sau serviciul. Trebuie sa monitorizeze piata si schimbarile din business. Mai mult decat atat trebuie sa fie capabil sa priveasca in viitor si sa anticipeze ce functionalitati au sens sa fie implementate din punct de vedere financiar sau nu.

In al doilea rand echipele au nevoie de prezenta constanta a unei persoane care este un expert functional si care ii poate ajuta sa traduca nevoile clientilor in stories pe care le pot intelege si implementa. Acesta trebuie sa ii ajute sa prioritizeze sarcinile si sa raspunda la intrebarile pe care le-ar putea avea. Este nevoie de cineva care sa se descurce cu schimbarile la nivel de cerinte, atat in materie de scope cat si in materie de prioritati Ц intr-un mod pragmatic care sa aiba in vedere si nevoile tehnice ale echipei. Deoarece echipele tehnice au nevoie ca progresul pe care il fac pe sarcini sa fie comunicat catre oamenii de business intr-un mod in care acestia sa il inteleaga si sa raspunda la el.

Putem astfel trage concluzia ca aceste doua arii nu pot sa se afle sub responsabilitatea unei signure persoane? Din acest motiv in SAFe avem doua roluri separate: primul este orientat catre client si business si se numeste Product Manager. Cel de-al doilea este orientat spre echipa si tehnologie si se numeste Product Owner. Aduce aceasta separare un grad mai ridicat de complexitate si eventual niste situatii conflictuale? Poate, si din acest motiv este nevoie ca acesti doi oameni sa lucreze impreuna in marea majoritate a timpului.

Atunci cand discutam de Дwork break-downФ, aceste doua roluri, impreuna cu Epic Owners, vor imparti Epics in Features si apoi in Stories. Vor oferi estimari de timp (implicand echipa atunci cand este necesar), vor lucra cu echipa pe parcursul etapei de implementare si apoi vor reagreaga Stories in Features si mai departe in Epic MVPs si Epic implementation.

SAFe. Nevoile clientului. Rolurile de Product Manager si Product Owner.jpg


Dezvoltarea unor sisteme de anvergura. Cone of uncertainty. Planning horizons

In aceasta parte a articolului ne uitam la organizatiile care trebuie sa construiasca solutii de anvergura - un sistem care implica mii de oameni, are o multime de subcomponente, necesita un nivel ridicat de interactiune si incorporeaza solutii de la terti. Putem sa avem o abordare agile atunci cand vorbim despre dezvoltarea si livrarea unei asemenea solutii?

Raspunsul este da. SAFe are o configuratie dedicata in mod specific pentru companiile care au aceste situatii. Se numeste ДLarge SolutionФ. Aceasta organizeaza compania intr-o structura denumita Solution Train care are scopul de a modela toate nevoile implementarii unui sistem major. Incepe de la definirea nevoilor in termeni de capacitate, apoi le imparte in Features si Stories. Apoi urmeaza implementarea, agregarea si validarea. Aceasta configurare spune ca Solution Train trebuie sa fie compusa din mai multe Agile Release Train, incorporeaza vendorii externi si se ocupa de aspectele legate de integrarea Solution precum si alte aspecte precum compliance. Veti gasi aici si toate rolurile si functiile care colaboreaza in cadrul unei asemenea organizatii.

In implementarea in interatii a oricarei solutii, tot ceea ce facem, la un nivel abstract, este facut ca sa reduca Дthe cone of uncertaintyФ in ceea ce priveste functiile sau features (Scope) si design-ul. Lucru care va duce la un sistem de succes care sa satisfaca nevoile clientului. Conceptul de ДCone of uncertaintyФ este o metafora care evidentiaza faptul ca la inceputul unui proiect sunt foarte multe necunoscute. Insa folosind o abordare interativa, aceste incertitudini se transforma intr-un set de cunostinte stabilit, un design fix si un scope fix. Acesti pasi iterativi sunt cicluri de invatare si daca ne uitam la modul in care procesele sunt definite in SAFe le putem identifica incepand cu echipa (daily sau sprint), apoi Product Increment cycle, la nivelul ART si apoi Solution Increment pentru Solution Train.

Ceremoniile pentru facilitarea ciclurilor de invatare in SAFe (Scaled Agile Framework)

Exista ceremonii specifice pentru facilitarea acestor cicluri de invatare la fiecare dintre cele trei nivele. Ceremonii precum Product Increment Planning, intalniri Pre si Post PI Planning, System and Solution Demo. Cei care dezvolta aceste solutii (Solutions) trebuie sa inteleaga ca cele mai mari cicluri controleaza de fapt evolutia sistemului si ca functionalitatile noi nu pot sa fie adaugate mai repede decat cea mai lenta frecventa de integrare. Astfel ca atunci cand vrem sa optimizam livrarea de valoare si sa facem lucrurile mai eficiente, abordarea ar trebui sa fie de sus in jos.

Deoarece totul este Agile si chiar si o organizatie foarte mare va trebui sa fie capabila sa se adapteze rapid la schimbare, se poate crea o impresie falsa. Si anume ca intr-un mediu Agile nu exista planificare, nu exista control si totul este haos. Dar daca ne uitam mai de aproape putem vedea ca in Agile este mai multa planificare decat intr-o abordare traditionala. In Waterfall spre exemplu, toata planificarea are loc la inceput si presupunerea este ca ai cum sa prevezi viitorul cu un grad ridicat de probabilitate.

In SAFe, si in contextul unei Large Solution, putem sa identificam cel putin 5 planning horizons:
  • Daily plan la nivel de echipa Ц se intampla in principal in timpul Daily Stand-ups
  • Iteratii/Sprint Ц un plan care defineste munca pe care o va face o echipa in timpul urmatoarei iteratii
  • Product Increment planning Ц la nivelul programului si acopera Commited Features si Enabler pentru PI actual
  • Product Roadmap Ц acopera o perioada scurta (3-4 PI), estimari de Features si Milestones
  • Solution Roadmap Ц acopera o viziune pe mai multi ani, milestones, events si roadmap pentru Solutions

Vrei sa adopti SAFe in organizatia ta? Descopera cursurile noastre.


Iulian Velea
Certified SAFeЃ Program Consultant (SPC4)

Daca iti place acest articol, distribuie-l si prietenilor tai!




Luxoft Warsaw - Warsaw Spire, plac Europejski 1, 00-844 Warszawa
Dimitrie Pompeiu nr 5-7 , building C, Et. 5, sect 2, Bucharest, 014459

Contact phone:

021 371 4858
Luxoft Poland Wroclaw - Silver Tower pl. Konstytucji 3-go Maja 3 50-048 Wroclaw
Aleja Generała Tadeusza Bora-Komorowskiego 25, Quattro Business Park Five, 31-476 Kraków, Poland

Contact phone:

+48 122110650
Success
Iti multumim.
Inregistrarea ta a fost trimisa.