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:
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
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ů
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
Definition of Done on US level
PO accepted US
Fáze dodávky MVP
UX design - Finální verze je hotová a připravena pro vývoj (máme vše v jiře) | Code Review byl úspěšně schválen Dev Leadem/dev seniory | Výsledky testování jsou v souladu s test casy | Product Owner akceptoval novou funkcionalitu | Release na produkční prostředí | |
Onboarding | |||||
„Settings“ | Konec října | ||||
Prevence | Konec října | ||||
Najít lékaře | říjen | ||||
O zdraví |
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.