Tisk hmotností plánování

Článek
03/04/2013

Podle Mitch Lacey.Vlastník, Mitch Lacey & Associates, Inc., konzultační společnost se specializací na zavádění účelných vylepšení a vylepšení typu scrum.

Leden 2012.

Plánování Sprintu nemusí být náročné.Často je zábavné a je příležitostí, kdy se členové Scrum týmu mohou vzájemně seznámit a vytvořit přátelství společnou prací na otázce „K čemu se můžeme zavázat?“ V tomto článku poskytují autoři příklady a strategie pro udržení soustředěného a efektivního plánování sprintu a podrobně popisují možná řešení běžných problémů, se kterými se týmy při plánování sprintu setkají.

Platí pro

Správa životního cyklu aplikací; server Team Foundation Server

V tomto článku:

Úvod
Prognóza oproti praxi
Co je plánování Sprint?
Jak toho můžeme dosáhnout?
Běžné problémy
- Scénář: Tým nedokáže pokrýt všechny úkoly, které si vlastník produktu vyžádal.
- Scénář: Vlastník produktu nepřichází připraven.
- Scénář: Část 1 překročí svůj časový rámec.
- Scénář: Část 2 překročí svůj časový rámec.
- Scénář: Vlastník produktu není k dispozici.
- Scénář: Tým nemá potřebná kritéria přijetí.
- Scénář: Vlastník produktu neví, co znamená „hotovo“.
- Scénář: Vedoucí Scrum nebo vlastník produktu odhaduje/ovlivňuje odhady/práci týmu.
Závěr

Neplánujeme.Používáme možnosti Scrum, takže zkrátka plníme požadavky.

To poslouchám pořád.Lidé mají pocit, že Scrum a agilita představují absenci plánování, odhadování, schůzek a vůbec všeho!To nemůže být vzdálenější od pravdy.Plánujeme na různých úrovních agilního projektu: denní plán nebo denní výstup, týdenní plány (sprinty nebo iterace, rezervní položky), plán vydání (rezervní položky produktu) a potenciálně další možnosti.

Pojďme se zaměřit na plánování sprintu.

Prognóza oproti praxi

V létě roku 2011 Ken Schwaber a Jeff Sutherland revidovali své Průvodce Scrum.Je zde odebráno dlouho zavedené chování známé Scrum, což je závazek týmu ve vztahu k vlastníku produktu a zákazníkům.Závazek byl nahrazen prognózou.Říká se, že týmy mohou předvídat prognózy své práce, ale ne zavazovat se k nim.

Zatímco chápu jejich logiku, upřednostňuji z následujících důvodů závazek:

Specializace na některou věc změní mindset týmu oproti pouhému prognózování.Pokud tým přichází s prognózou, předpokládá se, že nesplnění všech potenciálních plánů je přijatelné.Zatímco týmy mohou získávat zkušenosti ze svých prognóz, případně s méně odchylkami, uvědomuji si, že týmům využívajícím prognózy trvá déle omezení odchylek v porovnání s týmy, jež se zavazují.
Předpověď nebo odhad jsou vhodné pro nevyřízené položky produktů.Když však týmy přesunují příběhy z nevyřízených položek do sprintu nevyřízených položek a rozčlení je, mohou přidat jinou úroveň zrnitosti. Tím mohou zjistit malé podrobnosti, které jim umožní zeptat se samy sebe „Můžeme se k tomuto zavázat?“. Prognózování spustí rizika pádu zpět do líného stavu místo toho, aby si tým řekl „Potřebujeme pouze prognózy. Je v pořádku, pokud přehlédneme některé položky. Můžeme je zjistit později.".

A na lehčí notu, představte si, že řeknete své manželce, manželovi či partnerovi: "Předvídám, že spolu budeme deset let.“ a nebo „Odevzdávám se ti.“ – to bude v pořádku.

Nakonec, Scrum je o zdravém rozumu.Navrhuji, abyste zkusili přístup závazku i přístup prognózy.To je vše o učení, nikoli o použitých slovech, takže buďte nápadití, experimentujte s obojím a používejte to, co více vyhovuje vám, vašemu týmu a společnosti.

Co je plánování Sprint?

Pozdrželi jsme plánování schůzky sprintu, aby bylo naplánováno co tým bude tvořit v nadcházejícím sprintu a jak bude tým postupovat.I když na ni odkazujeme jako na schůzku plánování sprintu, skládá se ve skutečnosti ze dvou různých částí.Část 1 se zaměřuje na to, co je po týmu požadováno vytvořit a účastní se jí vlastník produktu i tým.Část 2 se zaměřuje na to, jak tým plánuje vytvořit požadované funkce.Přestože se celý tým musí zúčastnit části 2, účast vlastníka produktu je volitelná.Pokud se z nějakého důvodu vlastník produktu neúčastní Části 2, měl by zůstat k dispozici pro případné otázky.

V části 1 schůzky pro plánování sprintu má vlastník produktu příležitost popsat požadovanou množinu příběhů týmu.Toto je hlubší relace ohledně předmětu částí příběhů.Vlastník produktu představuje příběhy, zobrazuje způsob interakce objektů a prochází rozhraní.Dále mohou přezkoumat infrastrukturu nebo architektonické položky.Cílem je získat dostatek informací, aby tým mohl začít vymýšlet, jak navrhnout funkce v sestavení.Tým položí různé otázky, aby shromáždil informace jak pro schůzku:

„Jaké jsou podmínky pro přijetí všech těchto úloh“
„Jaké zdroje dat myslíte, že používáme?“
„Jak by mělo vypadat rozhraní u této komponenty?“

Během části 2 schůze plánování sprintu věnuje tým pozornost vytváření nevyřízených položek sprintu – seznamu článků a úloh, které je nutné během sprintu dokončit.K sestavení rezervních položek tým rozdělí každý příběh, který vlastník produktu vyžádal pro úroveň úkolu; každému úkolu je přiřazen hodinový odhad.Do konce části 2 se tým rozhodne, pro které články může potvrdit dokončení během sprintu.

Společně dvě části sprintu plánování schůzky může trvat od dvou do osmi hodin.Obecným pravidlem je, že každá část by měla zabrat jednu hodinu pro každý týden délky sprintu.To znamená, že pokud používám týdenní sprinty, schůzka bude trvat celkem dvě hodiny (jedna hodina část 1 a jedna hodina část 2).Pokud ale používám čtyřtýdenní běhy, schůzka bude trvat celkem osm hodin (čtyři hodiny pro Část 1 a 4 hodiny pro Část 2).

Jak toho můžeme dosáhnout?

Pokud tým opustí schůzku plánování sprintu se závazkem dokončení seznamu článků, splnil tým účel plánování sprintu.Dostání týmu do bodu, kdy si každý člen týmu připadá dobře ohledně tohoto závazku, ale vyžaduje plánování předem a poskytnutí podpory.

Vlastník produkt má jednu úlohu při plánování sprintu: přijít na schůzi a popsat požadovaných příběhů.Cílem týmu je pochopit příběhu z pohledu vlastníka produktu, sdílet vizi vlastníka produktu.Vedoucí Scrum by měl zajistit, že tým pokládá dostatek otázek a sbírá všechna výsledná data, včetně kritérií přijatelnosti, náčrtků a všech předpokladů.Vedoucí Scrumu by také vlastníkovi produktu sdělit, že tým může mít další otázky i po rozpisu otázek do úkolů.Ačkoli vlastník produktu představuje články, jejichž celkové součty bodů zhruba odpovídá historické rychlosti týmu, tým musí nakonec rozhodnout, zda může ve skutečnosti trvat na všech článcích v daném sprintu, na základě toho, co se naučí během části 1 a části 2 plánovací schůzky sprintu.

Jakmile týmu získal všechny informace od vlastníka produktu, musí rozdělit články do úloh a vytvořit nevyřízené položky sprintu, které zachycují všechny články, poznámky, kritéria přijetí, úkoly a odhady pro konkrétní sprint.Existuje mnoho způsobů, jak to provést, lze využívat následující metodu, která využívá všech nápadů členů týmu a poskytuje všem hlas v rozložené úkolu.

Nechejte vedoucího schůzky přečíst příběh a zeptejte se „Rozumějí mu všichni?“. Celý tým by měl, protože právě strávil čas s majitelem produktu a probírali ho.Pokud někdo v týmu nerozumí, věnujte nějaký čas opakování příběhu a vlastníkovi produktu položte veškeré nutné otázky.
Dále každého člena týmu nechte uchopit lístek.Požádejte každého člena týmu, aby napsal jeden úkol na každý lísteček a vhodil jej doprostřed stolu.
- Při každém vhození lístečku doprostřed stolu oznámí vhazující úkol.Takže pokud zapíšete „aktualizovat uložený postup“, řeknete to nahlas.To je důležité, protože vzniknou nové nápady a způsobí, že ostatní řeknou: „No jasně, a my musíme aktualizovat zdroj dat.“ V tomto bodě, někdo může napsat na lísteček: „Aktualizovat zdroj dat“. Řekněte to a hoďte jej doprostřed.Tato aktivita debata skutečně umožňuje odplavit všechny přidružené úlohy.V tomto okamžiku se není třeba obávat duplicitní položky.Zbavení se všech rychlých poznámek úkolu obvykle trvá asi pět až deset minut na příběh.
Pokud jsou všechny rychlé poznámky na tabulce, je čas je seřadit.Vložte je všechny na zeď, ustupte si a co neuvidíte – spousta nálepek!Začněte identifikovat duplicity; překryjte poznámky, které se zdají být duplicitní.Poté vyhledejte úkoly, které se zdají být slučitelné, buď protože jsou podobné, nebo protože jsou navzájem závislé.Například, pokud dvě rychlé poznámky mají podobný vztah, dejte je k sobě tak, aby se lehce překrývaly, jak ukazuje následující obrázek:

Pokud dva úkoly tak úzce souvisejí, že jsou téměř identické, překryjte je téměř zcela, jak je znázorněno níže:

Uspořádáním lístečků může týmu setřídit seznam úkolů a znázornit vztahy mezi těmi, které zůstávají.
Při řazení úkoly je čas na odhad.Osobně pro odhadování úloh používám plánovací pokerovou techniku, s jediným rozdílem. Čísla na kartách neznamenají body, ale hodiny.Dělám to proto, že lidé mají tendenci se na hodiny zaseknout na nepodstatných detailech, obzvláště u velkých úloh.Mají pro své znepokojení dobrý důvod.Společnosti příliš často používají odhad jako normu pro tým.„Řekli jste, že vám to bude trvat 8 hodin a trvalo to 12.Co je špatně?“ nebo „Řekli jste, že by to mělo trvat 8 hodin a trvalo to pouze 4.Doplňujete své odhady.“

Stejným způsobem, jakým karty pomáhají uchovat odhady story bodů abstraktní, pomůže použití karet pro odhad úlohy týmu získat svobodu díky množině pevných čísel, ze kterých je možné vybírat, přičemž jsou nuceni ke konečnému výběru.Také odstraňuje vyhřívané diskusí, zda úkol by měly být odhadnuty na 6 hodin nebo 6.5 hodiny nebo 7 hodin.

Bez ohledu na závěrečný odhad, nezapomeňte, že odhad provádí tým a je určen pro použití týmem pouze ke zvýšení své důvěry a zjištění, zda lze práci na základě rychlosti podle požadavků vlastníka produktu.Odhady úkolu nejsou metrikou a neměly by být takto používány.Nikdy nepoužívejte odhady jako zbraň proti týmu.
Nyní, když jsou odhadnuty úlohy, musí tým určit, zda má kapacitu na převzetí další práce.K tomu budete potřebovat znát kapacitu týmu a celkový počet hodin, které má tým k dispozici během sprintu.Stanovení kapacity je snadné, pokud máte plně specializovaný týmu, ale stává se těžším, máte-li tým tvořený zaměstnanci na částečný úvazek, kteří jsou rozděleni mezi více projektů.Požádejte každého, aby zapsal počet hodin, které může každý odpracovat na projektu za den (nebo celkem za sprint).Sečtením všech čísel dohromady získáte celkový počet hodin, které má tým k dispozici.Řekněme, že zjištěná kapacita týmu bude 200 hodin.Pokud se odhaduje, že součet úloh příběhu zabere 30 hodin, zeptejte se týmu „Zvládneme více práce?“. V této rané fázi je odpověď samozřejmé Ano.

Protože máte větší kapacitu pro vyplnění, přejděte na následující článek a opakujte kroky 1 až 5.

(Informace o tom, jak tuto úlohu dokončit pomocí serveru Team Foundation Server, naleznete v části Agilní plánování a iterací.)

V určitém momentu budete mít potíže s odpovědí na otázku: „Můžeme si vzít více práce?“ Je to proto, že se blížíte kapacitě svého týmu.Když procházíte prací na procesu, berte ohled na to, že nechcete vyplnit celou kapacitu sprintu.Pokud naplníte skleničku vodou po její horní hranu, je pravděpodobné, že se vylije.Totéž platí pro sprinty.Pokud odhadovaný počet hodin spotřebuje veškerý dostupný čas a až později je zjištěn nový úkol, postup se zhroutí.Je třeba ponechat prostor pro vznikající úkoly.

Při zvažování závazků sprintu, pomáhá zvážit retrospektivní data z minulých sprintů.Potřebuje tým přinášet stále více práce?Možná má tým během plánování sprintu na víc.Není tým stále schopný dokončit všechnu práci pro sprint?Tým bude pravděpodobně potřebovat konzervativnější přístup s patřičnými závazky před tím, než adresuje základní příčinu nedokončených sprintů.

Jedním způsobem, jak přiřadit číslo k otázce „nakolik je vaše sklenice plná“ je zvážit růst ve velikosti plánu.Nárůst velikosti plánu poměřuje skutečné strávené hodiny s počátečními odhady.Řekněme například, že náš tým má k dispozici kapacitu 200 hodin.Tým se zavazuje k tomu, co na základě svých odhadů považuje za 190 hodin.Na konci sprintu tým vypočítá, že tyto články obsahují 240 skutečných hodin práce, což má za následek nárůst velikosti plánu o 20 %.

Tým, který zjistí tuto nesrovnalost, musí strávit určitou dobu zpětným zkoumáním důvodů:

Probíhá při provádění zjišťování příliš mnoha úkolů, které nebyly identifikovány během plánování?
Podcenil tým svoje úlohy na základě aktuálních schopností?
Přecenil tým svoji kapacitu?
Atd.

Tým by také měl zvážit růst velikosti plánu během další schůzky pro plánování sprintu při určování, zda se lze zavázat k příběhu.Když se vrátíme zpět k našemu příkladu, pokud tým stále odhaduje 200 hodin, tým by měl odečíst 20 % horní hodnoty a kompenzovat tak „očekávaný“ růst šířky plánu na základě historických dat.Jinými slovy, je-li zapotřebí zabránit únikům alespoň pro tento sprint, jakmile tým dosáhne 160 hodin, měl by sám deklarovat svoji kapacitu.

Zohlednění růstu velikosti plánu je jedním ze způsobů, jak kvantifikovat podobu celého sprintu.Uvědomíte si však, že cílem není přesně pokrýt kapacitu.Namísto toho je třeba umožnit týmu cítit se jistě při zaměření se na odpovídající počet úkolů – počet, který pro tým představuje adekvátní výzvu bez jeho přetěžování.Nárůst velikosti plánu je pouze způsob přibližného určení, jak by měl další sprint vypadat, pokud všechny faktory zůstanou stejné.

Jakmile jsou všechny příběhy odhadnuty nebo byl spotřebován příběhy, přejděte zpět k vlastníkovi produktu a sdílejte rezervní položky sprintu, které se tým zavázal dodat.Nyní je sprint zahájen – takže do práce!

Běžné problémy

Za mnoho let konzultací, které týmům pomáhaly přijmout Scrum, jsem zjistil opakující se problémy, které bránily úspěšnému plánování sprintu.Ačkoliv se plánování sprintů zdá jasné, týmy, které s technikou s Scrum právě začínají, mají obvykle potíže.V této části je podrobně popsán velký počet těchto problémů a jejich možných řešení.

Scénář: Tým nedokáže pokrýt všechny úkoly, které si vlastník produktu vyžádal.

Je třeba počítat s tím, že k tomu bude občas docházet.Dokud tým může zálohovat závazek s daty ze kroků čtyři a pět dříve v tomto tématu, měl by být vlastník produktu spokojen.Budete chtít sledovat, zda selhání potvrzení není výsledkem nadřazování nebo velkých úkolů.Vedoucí Scrum by měl rozpoznat, co je zřejmě příliš konzervativní odhady, aby se ujistil, zda jsou přesné.Vlastník produktu by se měl dotázat na všechny úkoly, které mají odhad se dvěma číslicemi.Jakýkoli úkol, jehož trvání se odhaduje na déle než dva pracovní dny, je nutné rozdělit na menší úkoly a znovu provést odhad.Platí pro všechny projekty, ale je problémem zejména pro týmy, které používají týdenní nebo dvoutýdenní sprinty.

Scénář: Vlastník produktu nepřichází připraven.

Jednou hodnotou Scrum je respekt.Příchod na schůzku bez přípravy nelze tolerovat.Takže co týmu bude dělat, pokud se vlastník produktu objeví bez informací, které tým potřebuje?Ačkoli jednou možností je odložit schůzku, dokud vlastník produktu nebude připraven, tento postup pouze podněcuje stejné chování – vyhněte se mu.Další možností je zrušit sprint.Přestože to může fungovat, je to extrémní.

Podle mě je nejlepší řešení dvojí.Za prvé, nevyřízené položky produktu by měly být v na prvních místech v prioritách, takže pokud vlastník produktu nemá konkrétní sadu příběhů, tým a vlastník mohou prodiskutovat prioritní příběhy až do bodu, kdy se domnívají, že dosáhli kapacity nebo překročili její rámec.Tým se potom může rozhodnout na přesném závazku během druhé části schůzky, jako obvykle.

Po schůzce by měl ScrumMaster pracovat na pochopení, proč nebyl vlastník produktu připraven.Pokud byl problém nedostatečné zapojení, můžete ScrumMaster poučit vlastníka produktu o významu toho, že přijde na schůzku připravený a se sadou příběhů.Pokud na druhé straně byl problém to, že se vlastník produktu nebyl schopen připravit, možná protože mu tým nedokázal pomoci při sbližování, ScrumMaster by také měl pomoci tyto problémy vyřešit.

Scénář: Část 1 překročí svůj časový rámec.

Jinou hodnotou je fokus.Pokud Část 1 schůzky trvá příliš dlouho, jedná se o příznak nedostatečné soustředěnosti.Vlastník produktu je někdy nesoustředěný z důvodu nedostatku přípravy, stanovení priorit nebo se pokouší vysvětlit příliš mnoho příběhů.Jindy nedostatek zaměření může vycházet z toho, že tým nesprávně nahrazuje diskuze na téma „co“ diskuzemi na téma „jak“.

Vedoucí Scrum by měl pomoci dát věci do pohybu trváním na tom, aby vlastník produktu zařadil do tabulky všechny příběhy, které nelze plně vysvětlit a že tým bude vést podrobné diskuse o implementaci, podle části 1.Jedna jednoduchá náprava pro nesoustředěnou diskuzi je používat stopky nebo časovač.

Scénář: Část 2 překročí svůj časový rámec.

Znovu jde o fokus.Pokud máte tým, který hodně mluví, někdy je disciplína, která je třeba pro udržení diskuze v kolejích, to jediné, co potřebujete. Přineste časomíru a udržujte minutu nebo dvě minuty dlouhou konverzaci mezi odhady úkolů.Cílem je přesnost, ne 100% preciznost.

Jindy nedostatek zaměření během části 2 vykazuje nedostatek péče o rezervní položky produktů během spuštění sprintu.Rozvíjení je období, kdy tým společně s majitelem produktu pracuje na budoucích příbězích a na přidání příběhů nebo styčných bodů za účelem získání pokynů k designu nebo řešení otázek architektury.Bez pravidelné zálohy produktu, záloh sprintu se stává plánování nepraktické a nepříjemné.

Scénář: Vlastník produktu není k dispozici.

Pokud se vlastník produktu z nějakého důvodu nemůže zúčastnit schůzky a neposlal svého zástupce, jednejte tak, jako by vlastník produktu přišel na schůzku nepřipravený.Pracujte skrze nejlepší položky a zapište k nim nejlepší návrhy.Může se stát, že budete chtít změnit čas schůzky, aby vyhovovala plánu vlastníka produktu plánu.Ne.Posunutím času schůze vyjdeme vstříc potřebám jednoho na úkor ostatních.Nevyplatí se to.

Scénář: Tým nemá potřebná kritéria přijetí.

Vždy radím týmům, aby se zeptaly vlastníka produktu během Části 1: „Co je kritérium přijetí?“ nebo „Co musíme udělat, abyste práci přijali?“. Pokud se tyto otázky neobjeví ani v Části 2, kdy tým určuje úkoly, nebude mít tým ponětí, jak příběh uzavřít.Pokud tým musí na základě toho, co slyšel v Části 1, hádat, vystavuje se riziku, že se vlastník produktu na konci běhu rozhodne, že příběh není dokončený.Požádejte o kritéria přijetí od zahájení každého článku.Vedoucí Scrum – naučte vlastníky produktu, aby tato data poskytovali.

Scénář: Vlastník produktu neví, co znamená „hotovo“.

Stejně jako tým požaduje kritéria přijetí, vlastník produktu si zaslouží aktuální popis, co si tým představuje pod větou „příběh je hotov.“ Tento seznam hotových položek by měl být výrazně umístěn v aktuální podobě, aby byl vždy k dispozici vlastníkovi produktu.Zastaralý seznam hotových položek ztěžuje plánování, protože neexistuje společné chápání podoby hotových položek.Ujistěte se, že aktualizace seznamu hotových položek je součástí každé revize sprintu či retrospektivy.

Scénář: Vedoucí Scrum nebo vlastník produktu odhaduje/ovlivňuje odhady/práci týmu.

Vlastník produktu je vítán ve druhé části schůzky, ale role vlastníka produktu ve druhé části by měla být omezena na objasňování požadavku nebo adresování konkrétních otázek.Vlastník produkty by nikdy neměl zasahovat do diskuse týmu o implementaci článku a nemá žádné pravomoci v oblasti odhadu úkolu.Vlastník výrobku musí důvěřovat týmu, že práci odvede.

Pokud vlastník produkt nedodržuje tyto pokyny, ScrumMaster by ho měl přinutit chovat se přiměřeněji a vhodněji.Pokud majitel produktu odmítne přijmout pasivnější roli, ScrumMaster je oprávněn požádat vlastníka produktu, aby odešel.

Plánování Sprintu nemusí být náročné.Často je zábavné a je příležitostí, kdy se členové Scrum týmu mohou vzájemně seznámit a vytvořit přátelství společnou prací na otázce „K čemu se můžeme zavázat?“ Nezapomeňte, že pokud zjistíte, že vaše schůzky trvají dlouho, příčinou jsou pravděpodobně zásadní problémy.Pokud jste ScrumMaster, veďte schůzku tak, aby se vlastník produktu a tým věnovali řešení nevyřízených položek produktů.Pomozte vlastníkovi produktu přijít připraven, a to tak, že si kritéria přijetí příběhu připravíte již před schůzkou.Nakonec se snažte udržet vlastníka produktu a tým zaměřené na aktuální úkol – určete, co mohou potvrdit pro sprint.