Agilní ceremonie, které využíváme na projektu

• Během vývoje mobilní aplikace pro Loono používáme Jiru.

• Práci se snažíme naplánovat na dvou týdenní bázi (říkáme tomu sprint).

• Cílem sprintu je dodat úkol, ke kterému jsem byl/ a přiřazena. Pokud vidím někde riziko, že to nezvládnu, komunikuji do Slacku.

• Zde jsou týmové schůzky, které nyní máme:

Stand-upy

• každé pondělí a čtvrtek nebo úterý a čtvrtek (podle toho kdy mám plánování) - automatická zpráva ve Slacku (dev channel) + tagnutí lidí kteří mají user storky v jiře.

• SM večer udělá review/odpovídá - řeší problémy/ adresuje další kroky

Návod jak to nastavit ve Slacku:

Open

Otázky můžeš přizpůsobit, ale používali jsme:

• Co jsem do dneška udělal/a proto, abych pomohl/a týmu splnit cíl sprintu?

• Co budu dělat do příštího stand-up meetingu, abych pomohl/a týmu splnit cíl sprintu?

• Vidím nějakou překážku, která mi (nebo týmu) brání ve splnění cíle sprintu?

Doporučení - hlavně se ptát na blockery

Sprint planning celého týmu

• Neboli plánování práce na následující 2 týdny. Snažíme se plánovat to, co jsme schopni dodat. Chceme maximálně využít čas dobrovolníka. O tradičním scrumovém plánování se můžeš dozvědět detaily zde.

• Probíhá jednou za 2 týdny v úterý: 8.00 hodin.

• Účastníci: Core tým (Product Owner, Dev Lead, UX Lead, Scrum Master, Marketing - Loono, Projektový koordinátor Česko.Digital, analytička, vývjáři (backend i frontend))

Sprint review

• Probíhá 1x za sprint v pátek odpoledne

• Děláme společné review tasků / storek v jiře a těch, které máme v progresu + PO prioritizuje

• Píšeme nové “issue types” do Jiry a připravujeme backlog tak, aby byl vždy prioritizován naší PO

• Práce s Definition of Done (mít akceptační kritéria, popisky, assignee osobu která má průběžný přehled o stavu ticketu)

Demo a retrospektiva

• Probíhá jednou za 2 týdny z lokálního prostředí kdy Dev Lead / nebo někdo z týmu ukazuje progres (Live Demo) za celý vývojový tým (+ někdy i nový UX design) a PO s týmem komentuje

• retrospektiva s týmem probíhá po dovršení dalšího milníku / po Hackhatonech - předešlé retra v miru zde: Realizace/inkub-loono_pruvodce_prevenci

Hackatony

• po debatě s týmem + PO

• většinou jednou měsíčně, detaily předešlých zde:

• Hackaton "Průvodce prevencí"

• Hackathon #2 Aplikace pro Loono

• Hackathon #3 Preventivka pro Loono

• Hackathon #4 Preventivka pro Loono

Jak odhadujeme práci?

• Jakákoliv práce, která nám zabere více než 1 sprint by se měla rozpadnout na menší User storky

Proč potřebujeme odhadovat?

• Abychom zlepšili plánování kapacit pro sprinty

Co odhadujeme?

• User storky

T-shirt method

• XS - User storky které zvládneme dodat do 1 sprintu - k approvalu PO (ideální případ)

• S - User storky které dodáme do 2 sprintů - k approvalu PO (ideální případ)

• M - User storky které nám zaberou 2-3 sprinty

• L - 4 a více sprintů

Open

Kdy děláme odhady?

• Ve fázi kdy máme za analýzu hotovo a předáváte vývoji. Odhadujeme jen implementační část.

Jak odhady aplikovat do jiry?

• Inspirace v článku zde

Kdy odhadujeme práci?

• Před týmovým commitment během sprint planningu, že US dodáme

Feedback z testování (v budoucnu změnové požadavky) / nyní bugy

Jak testovat Preventivku a zadávat bugy do Jira

Definition of Done on US level

• PO accepted US

Fáze dodávky MVP

@Martin Ladecký @Jana Hejnová @Romana Pokorná Tabulka pro základní orientaci, napište mi prosím zda vám to dává smysl nebo ne/ co přidat? Naše workflow v Jiře nám tohle jasně neřekne. Cílem není přidávat další tabulku, ale zorientovat se v naší práci z časového hlediska abychom věděli co vylepšit.