Agile Manažment 1/3 (Agile Role a Manažment požiadavok v agílnych projektoch)

AGILE ROLE

agilne procesy vykonávajú nasledujúce role:

product owner

>úlohy a zodpovednosti: hlavnou úlohou je zabezpečiť aby sa robilo to čo zákazník/koncový používatelia produktu požadujú, a to čo najefektívnejšie. konkretne teda ide o úlohy ako
-správa product backlogu: pridávanie/mazanie/zmena user stories, rozdelovanie user stories na menšie, prioritizácia user stories
-komunikácia: s používateľmi produktu a vývojovým tímom, vysvetľovanie fungovania výstupu
>vykonávateľ: priamo zákazník, alebo business analytik zastupujúci zákazníka.

vývojový tím

>úlohy a zodpovednosti:
-realizácia výstupu(produktu/služby)
-samoorganizované riadenie(self-organising) s cieľom doručenie výstupu pri dohodnutých podmienkach so zákazníkom.
>vykonávateľ: vývojári, testeri, grafici, teamleader, it operations

teamleader

>úlohy a zodpovednoti: hlavnou úlohou je zabezpečenie aby mal vývojový tím všetko čo potrebuje pre vývoj. konkretnejšie ide o úlohy ako:
-riešenie problémov(mediátor-riešenie konfliktov medzi členmi tímu, riešenie problémov so zákazníkom/product ownerom),
-coaching a rozvoj jednotlivcov
>vykonávateľ: teamleader/projekt manažer, alebo pri menších tímoch túto rolu môžu part-timovo vykonávať členovia vývojového tímu(podrobnejšie znalosti a schopnosti agile leadra). v scrum metodike sa táto rola nazýva scrummaster

Manažment požiadavok

špecifikáciu (tj. popis vlastnosti a chovania) požadovaného výstupu(produktu/služby) je vhodné rozkuskovať do relatívne malých blokov, popísať tieto bloky a vzťahy medzi nimi. Bloky sú vyjadrené v závislosti od požadovaného stupňa detailov vo forme user story, alebo detailnejsie vo forme táskov a vzťahy medzi blokmi sú vyjadrené vo forme story maps. Splnenie user story je definované splnením jej akceptačných kritérii. Akceptačné kritéria sú podkladom pre formuláciu taskov a task workflow.

user story

čo: user story je strucna forma popisu požadovanej funkcionality.Samotná user story is not a specification, but a communication and collaboration tool. user storí tvorí: description, order, estimate and business value.
kto: rola product ownera spravuje user stories
ako: formulácia user story v tvare AS I want BECAUSE .
kedy: Tvorba user stories je realizovaná na meetingu tvorby specifikacie. Úprava user stories je realizovaná priebežne podľa potreby.
prečo:
-prečo vyjadriť špecifikaciu v forme blokov požadovaných funkcionalít(user story)? aby bolo možné merať progres v plnení požadovaných funkcionalít a identifikovať a reagovať tak na odchylky plánu voči realite.
-prečo user story ma byť relatívne malá? z dôvodu presnejších odhadov pracnosti.veľké funkcionality(epic) sa ťažko odhaduju a sú preto nepresné.
-prečo uvedený format user story? odpovedá na otázky kto(type of user) čo(goal) a prečo(reason), ktoré sú dôležité pre pochopenie požadovanej funkcionality členov tímu.
Uvedenie “reason” podporuje lepšie pochopeniu biznis problému, odhaleniu problémov sporu s inými user story a pochopeniu súvislosti medzi user stories(napr. daný príčinu už riešia ine user story, alebo je možné efektívnejšie riešiť danú príčinu).
napr. user story bez zdôvodnenia prečo:
USER STORY1: ako projekt manažér CHCEM dostávať 2 x do týždňa reporty o stave plnenia metrík projektu
USER STORY2 ako projekt manažér chcem dostávať 1 krat do týždna report o aktuálne minutých nákladoch na projekt.
V týchto dvoch user stories development tím nepozná príčinu, nevie prečo to chce mať v emaily, či to chce niekomu ďalej tieto info posielať alebo je to na jeho informáciu,.. tim nepozná príbeh a preto urobí tuto user story(alebo požiada o zistenie príčiny).

VS user story so zdôvodnením prečo:
USER STORY1: AKO projekt manažér CHCEM dostávať 2 x do týždňa reporty o stave plnenia metrík projektu ABY som na základe týchto informácii urobil potrebné korekcie.
USER STORY2 ako projekt manažér chcem dostávať 1 krat do týždna report o aktuálne minutých nákladoch na projekt ABY som vedel reagovať na potenciálny sklz projektu.
-> v tomto prípade tím pozná príčinu a môže navrhnuť iné riešenie napr. web rozhranie kde po autentifikovaní užívateľa sa mu zobrazia všetky relevantné reporty. Týmto riešenim môže dôjsť k splneniu oboch user stories cez jeden task.

task

čo: detailný popis práce ktorú je potrebné urobiť pre realizáciu user story. (napr. user story registrácia užívateľa môže obsahovať tieto tasky: rozbehať na aplikačnom servri spring security s podporou ACL, vytvorenie DB schémy v postgresql, v JS MVC tvorba UI podla mockupov, validácia formulárových dát na frontende a backende,..).
ako: “rozbitie” user story na sekvenciu táskov
kedy: sprint planning meeting
kto: clenovia vývojového tímu
prečo: detailný technický popis potrebný k realizácii user story, alokácia ľudských zdrojov

user story maps

čo: spojenie user stories do príbehov
ako: vytvorenie najčastejších sekvencii(use casov) user stories.
prečo: pre pochopenie požadovanej funkcionality v kontexte, čo prispieva k tvorbe toho čo zákaznik naozaj potrebuje.
kto: product owner
kedy: Tvorba user stories maps je realizovaná na meetingu tvorby specifikacie, a ich úprava je realizovaná priebežne podľa potreby.

TIP pre tvorbu špecifikácie: vhodné medzi sebou prepojiť user story maps + UXprototip = specifikácia
Existuje viacero foriem UX prototipov statické alebo interaktívne. Dôležité je však zvoliť čo najefektívnejšiu(prínosy/náklady) formu. Osobne preferujem statické prototipy vo forme mockupov nasketchované na tablet do hociktorého paint programu(napr. oneNote,bamboo paper,..) alebo desktopove sw(napr. omnigraffle, balsamiq,..).

product backlog

čo: subor prioritizovaných, odhadnutých user stories
kto: zodpovedný za správu product backlogu je product owner
prečo: aby bolo možné určiť čo(ktoré funkcionality) kedy(čas doručenia) v akom poradí(s prioritou na najhodnotnejšie a zároven najmenej pracné funkcionality) sa ma robiť
ako:
-prvotná tvorba user stories je realizovaná na meetingu tvorby špeciikácie
-prioritizácia user stories je realizovaná na release meetingu celym teamom.
prioritizácia= business value / costs
náklady(costs): odhad pracnosti(v bodoch alebo ideal hours viac v estimation) a riziká
biznis hodnota(business value): dôležitosť vyjadrená v bodoch. možné využiť value stream mapping(veľmi často používany lean nástroj, určenie pridanej hodnoty jednotlivých krokov procesu), moscow, kano model
Prioritizácia sa ešte upravuje na základe vzťahov z business pohľadu(medzi user stories) a súvislosti medzi technickými taskami..

akceptačné kritéria

čo: detailny popis funkcionality user story na príklade(specification by example)
kto: product owner
preco: aby bolo možné určiť kedy je user story pokladaná za hotovú a taktiež pre
lepšie pochopenie domenovej oblasti a teda urobenie toho co zakaznik naozaj chce.
kedy: Tvorba akceptačných kritérii je realizovaná na meetingu tvorby specifikacie, a ich úprava je realizovaná priebežne podľa potreby.

TIP: akceptačné testy je vhodné transformovat do formy automatizovaných E2E BDD testov(viac v XP testing). BDD testy je v závislosti od požadovanej úrovne kvality a množstva zdrojov možné realizovať na viacero úrovniach: simulácia užívateľových krokov(nástroje ako selenimum), testovanie frontend funkcionality(v javascripte napr. jasmine) alebo BDD testovanie backendu(spock, cucumber).

marek malý

marek.maly@ambiso.sk

Like helping people, Business & IT, research & innovations, nature, travelling, sports(bike, mountaineering, ..)

No Comments

Post a Comment