Nastavení iterací a plánu vydávání

Agilní a další iterativní metodologie jsou založené na konceptech iterací a vydaných verzí. Tento článek popisuje přiřazení iterací a verzí během plánování. Tato zadání umožňují viditelnost časové osy a usnadňují tak konverzace mezi členy týmu cloudové strategie. Přiřazení také ladí technické úkoly způsobem, který tým přechodu na cloud může během implementace spravovat.

Vytvoření iterací

Při iterativním přístupu k technické implementaci plánujete technické úsilí kolem opakujících se časových bloků. Iterace bývají časové bloky z jednoho týdne až šesti týdnů. Konsensus naznačuje, že dva týdny jsou průměrnou dobou trvání iterace pro většinu týmů přechodu na cloud. Volba doby trvání iterace ale závisí na typu technického úsilí, administrativní režii a preferenci týmu.

Pokud chcete začít sladit úsilí s časovou osou, doporučujeme definovat sadu iterací, které trvají 6 až 12 měsíců.

Principy rychlosti

Sladění úsilí s iteracemi a verzemi vyžaduje pochopení rychlosti. Rychlost je množství práce, kterou je možné dokončit v libovolné iteraci. Během počátečního plánování je rychlost odhadem. Po několika iteracích se rychlost stává velmi cenným indikátorem závazků, které tým může s jistotou splnit.

Rychlost můžete měřit abstraktními výrazy, jako jsou body scénáře. Můžete ho také měřit hmatatelněji, například hodiny. U většiny iterativních architektur doporučujeme používat abstraktní měření, abyste se vyhnuli výzvám v oblasti přesnosti a vnímání. Příklady v tomto článku představují rychlost v hodinách na sprint. Díky tomuto znázornění je téma obecnější.

Příklad: Pětičlenný tým přechodu na cloud se zavázal k dvoutýdenním sprintům. Vzhledem k aktuálním povinnostem, jako jsou schůzky a podpora dalších procesů, může každý člen týmu k přechodu konzistentně přispívat 20 hodin týdně. Pro tento tým je počáteční odhad rychlosti 100 hodin na sprint.

Plánování iterace

Zpočátku plánujete iterace vyhodnocením technických úloh na základě backlogu s prioritou. Týmy přechodu na cloud odhadují úsilí potřebné k dokončení různých úkolů. Tyto úlohy se pak přiřadí k první dostupné iteraci.

Během plánování iterace týmy přechodu na cloud ověřují a upřesní odhady. Dělají to tak dlouho, dokud nebudou srovnávat veškerou dostupnou rychlost s konkrétními úkoly. Tento proces pokračuje pro každou úlohu s prioritou, dokud se veškeré úsilí nesrovná s předpokládanou iterací.

V tomto procesu tým ověří úkoly přiřazené k dalšímu sprintu. Tým aktualizuje své odhady na základě konverzace týmu o jednotlivých úkolech. Tým pak přidá každý odhadovaný úkol do dalšího sprintu, dokud se nesplní dostupná rychlost. Nakonec tým odhaduje další úkoly a přidá je do další iterace. Tým provede tyto kroky, dokud se nevyčerpá rychlost této iterace.

Předchozí proces pokračuje, dokud nebudou všechny úkoly přiřazeny k iteraci.

Příklad: Pojďme stavět na předchozím příkladu. Předpokládejme, že každá migrace úloh vyžaduje 40 úloh. Také předpokládejme, že odhadujete, že každý úkol trvá v průměru jednu hodinu. Kombinovaný odhad je přibližně 40 hodin na migraci úlohy. Pokud tyto odhady zůstanou konzistentní pro všech 10 úloh s prioritou, budou tyto úlohy trvat 400 hodin.

Rychlost definovaná v předchozím příkladu naznačuje, že migrace prvních 10 úloh bude trvat čtyři iterace, což jsou dva měsíce kalendářního času. První iterace se bude skládat ze 100 úloh, které povedou k migraci dvou úloh. V další iteraci bude mít podobná kolekce 100 úloh za následek migraci tří úloh.

Upozornění

Jako příklad se používají pouze předchozí počty úkolů a odhadů. Technické úlohy jsou zřídka tak konzistentní. Tento příklad byste neměli vidět jako odraz doby potřebné k migraci úlohy.

Plánování vydání

V rámci přechodu na cloud se verze definuje jako kolekce výsledků, které vytvářejí dostatek obchodních hodnot k odůvodnění rizika narušení obchodních procesů.

Uvolněním jakýchkoli změn souvisejících s úlohami do produkčního prostředí dojde k určitým změnám obchodních procesů. V ideálním případě jsou tyto změny bezproblémové a firma vidí jejich hodnotu bez významných přerušení služeb. Riziko narušení obchodního provozu je však přítomen při jakékoli změně a nemělo by se brát na lehkou váhu.

Aby se zajistilo, že se změna ospravedlní jejím potenciálním výnosem, měl by se tým cloudové strategie podílet na plánování verzí. Jakmile jsou úkoly sladěné se sprinty, může tým určit přibližnou časovou osu, kdy budou jednotlivé úlohy připravené k produkčnímu vydání. Tým cloudové strategie zkontroluje načasování každé vydané verze. Tým by pak identifikoval inflexní bod mezi rizikem a obchodní hodnotou.

Příklad: V předchozím příkladu tým cloudové strategie zkontroloval plán iterace. Kontrola identifikovala dva body vydání. Během druhé iterace bude k migraci připraveno celkem pět úloh. Těchto pět úloh poskytne významnou obchodní hodnotu a spustí první vydání. Další verze přijde o dvě iterace později, až bude k vydání připraveno dalších pět úloh.

Přiřazení cest a značek iterace

Pro zákazníky, kteří spravují plány přechodu na cloud v Azure DevOps, se předchozí procesy projeví přiřazením cesty iterace ke každé úloze a uživatelskému scénáři. Doporučujeme také každou úlohu označit konkrétní verzí. Toto označování a přiřazení tvoří zdroj automatického souboru sestav časové osy.

Další kroky

Odhadněte časovou osu , abyste správně sdělili očekávání.

Odhadnutí časových os