Co jsou plány doručení?
S růstem vývojových organizací musí přeuspořádat do menších týmů, které můžou efektivně spravovat dělené jednotky práce. Tyto týmy obvykle mají pracovní plány, panely a další procesy, které splňují jejich jedinečné potřeby v kontextu větších cílů organizace. Organizace můžou v průběhu času zjistit, že mají výhody sítě tím, že konsolidují své procesy v rámci konzistentní architektury.
Plán doručení je vizualizace jednoho nebo více pracovních plánů. Cílem je poskytnout týmům a správě celkový přehled o tom, co každý tým plánuje vytvořit a kdy. Umožňuje rozhodnutí, která optimalizují investice v celé organizaci.
Týmy musí pravidelně kontrolovat plány doručení, aby zajistily, že jejich pracovní plán odpovídá plánům jiných týmů. Tyto recenze by se měly zabývat otázkami, jako jsou:
- Jsme si jistí, že můžeme dodat, co jsme se zavázali k našemu aktuálnímu plánu?
- Jsme si jisti, že týmy, na které závisíme, budou poskytovat to, co potřebujeme podle jejich aktuálního plánu?
- Jsou v našem plánu lulls, které bychom mohli vyplnit prací?
- Dochází k problémům se závislostmi v rámci týmu nebo napříč týmy?
Plány doručení přidávají hodnotu v jakémkoli okamžiku životního cyklu projektu. Vzhledem k tomu, že se dynamicky generují na základě týmových backlogů, jsou vždy aktuální a nabízejí nejnovější přehledy.
Pojďme se připojit k webovému týmu Tailspin v diskuzi.
Andy: Právě jsem měl skvělou schůzku s technickým řízením. Ukázku práce, kterou děláme s Azure Boards, a jsou nadšeni z toho, že na palubě dostanou další týmy.
Mara: Úžasné! Kdy začnou?
Andy: To je ta nejlepší část. Už mají! Včera v noci vedoucí projektu herního stroje vytvořil tým s některými sprinty a začal přidávat pracovní položky. Dnes ráno jsem se rychle podíval a pěkně se to formuje. Ukážu ti, co jsou na tom.
Andy přejde na aktuální desku sprintu herního stroje. On a Mara si prohlédnou pracovní položky s velkým zájmem.
Andy: Hmm... Právě jsem si všiml, že neplánují nasadit beta do konce tohoto sprintu. Neočekáváme integraci naší tabulky výsledků s beta databází během našeho dalšího sprintu? Nemůžeme to udělat, pokud nedají beta verzi jako první.
Mara: To je dobrý bod. Na tomhle týmu jsme závislí, abychom tuto dodávku vytvořili, abychom mohli vytvořit jeden z našich vlastních produktů.
Andy: To by mohlo vážně poškodit naši produktivitu příští sprint. Zavolám jim, abych zjistil, co se děje.
Sofistikovanější týmové struktury bohužel můžou vést k mezerám nebo prodlevám v komunikaci. Když je jeden tým zablokovaný, nemusí být schopen vytvořit něco jiného, na čem je závislý jiný tým. To nemusí být zásadní problém pro malou skupinu týmů, které mají denní schůzky pro všechny zúčastněné. Vzhledem k tomu, že se týmy dají škálovat podle velikosti a umístění, může se stát, že všichni vědí všechno, co se děje všude. V tomto okamžiku musí organizace přejít z čistě "nabízeného" modelu (jako je osobní nebo e-mailová oznámení) na model "pull" (kde si týmy můžou prohlédnout a sledovat plány jednotlivých uživatelů).
Andy: Dobře, právě jsem mluvil s vedoucí dev. Řekla mi, že jejich tým je zablokovaný v expedici beta, dokud se umělecký tým vrátí z Cliffchella.
Mara: Horská hudební festival?
Andy: Ano, očividně je to obrovská dohoda v komunitě designu, a celý tým prostě odpustí mřížku po celý týden, aby se zúčastnil. Tým herního stroje je docela naštvaný, protože proklouzl plán o tři týdny. Kdyby věděli, že se blíží, měli by se ujistit, že artefakty, které potřebovali, předem. Také se omlouvali za to, že nás neoznámili dříve. Neuvědomili si, že budeme čekat na jejich beta verzi, aby nám mohli dodat naši část.
Mara: No, alespoň můžeme být rádi, že herní tým publikuje plány sprintů. Pomohlo nám najít tento problém závislostí dostatečně brzy, aby se přizpůsobil náš plán.
Andy: Jen bych si přála, aby se tato potenciální rizika snadněji zobrazila. Naše týmy mají v celé společnosti tolik závislostí, že se nemůžeme zúčastnit každé schůzky a přihlásit se k odběru každé distribuční skupiny.
Mara: Měli bychom vytvořit plán doručení, abychom viděli naše týmové sprinty vedle sebe. To oběma týmům usnadní identifikaci toho, jak se naše plány vzájemně ovlivňují.
Doporučení pro správu více agilních týmů
Agilní přístup společně s Azure DevOps může výrazně zlepšit transparentnost a předvídatelnost projektů. Projekty však mohou stále narazit na tradiční výzvy, často související s pracovníky nebo špatnou komunikaci. Tady je několik věcí, které byste měli zvážit při škálování agilního úsilí.
Budování důvěry v lidi a procesy
Časné traktory agilních implementací jsou často skeptičtí ohledně jejich schopnosti zlepšit výkon týmu. Je důležité, aby vedoucí pracovníci v organizaci vytvářeli důvěru tím, že ilustrují, jak nástroje a procesy vytvářejí výsledky. Někdy jsou tyto výsledky vylepšení produktivity, což je snadné kvantifikovat. Nezapomeňte ale zdůraznit výhry týmu, ke kterým dochází obcházením potenciálních problémů, jako jsou například vyhnutí se časovým skluzům nebo problémům s kvalitou. Když lidé začnou přidružit výhody k procesu, který je dosáhl, budete mít větší nadšení.
Zvýšení úrovně organizace nad tým (a jednotlivce)
Některé týmy a jednotlivci získají územní při návrhu nových procesů nebo politik. Místo vytváření rámců nových zásad jako negativní zveřejnění výkonu konkrétních týmů nebo jednotlivců zvýrazněte, jak nová transparentnost v celé organizaci informuje všechny o očekávání. Díky jedinému místu, kde může kdokoli sledovat, jak souvisí jejich práce s organizací, která splňuje její cíle, bude mít vliv na důležitost svého závazku k procesu.
Podpora kultury transparentnosti
Termín "transparentnost" bohužel dostane špatný rap. Nikdo se neptá o větší transparentnost, když všechno půjde skvěle. Místo toho je transparentnost (nebo její nedostatek) často obviňována, když se týmy potýkají. I když jsou všechny příležitosti k transparentnosti poskytované agilním týmům, je stále předmětem upřímnosti jednotlivců a týmů. Zvýrazněte, že jedním z důvodů transparentnosti je schopnost identifikovat a řešit potenciální problémy dříve, než je příliš pozdě. Každý rozumí tomu, že lidé někdy narazí na okolnosti, které jim brání v termínech pro schůzku s časovými termíny. Pokud se ale nebudou cítit v bezpečí při hlášení zklamání zpráv až do poslední možné chvíle, může to mít mnohem destruktivní dopad. Budování úrovně pohodlí s transparentností může začít poděkováním lidem za hlášení očekávaných zpoždění co nejdříve.