Kód zamrzne: jsou stále relevantní pro agilní produktové manažery?

vypadá to jako otevřený a uzavřený případ.

zmrznutí kódu je relikvie. Zbytky z dob, kdy rigidní Vodopádové metodiky nabízely jedinou možnost pro vývoj a vydání produktu. Celý koncept zastavení výroby a oddálení vydání-jen pro testování chyb a dalších funkčních problémů-nemá v moderním, agilním řízení produktů místo.

alespoň to se zdá být konsensuální názor mezi mnoha agilními guruy.

ale vydrží to? Jakmile poškrábáte povrch nejběžnějších argumentů proti začlenění kódu zamrzne do agilního řízení produktů,budou se stále zdát archaické?

v tomto článku prozkoumáme tři hlavní argumenty proti začlenění code freezes do agilního řízení produktů a rozebereme, kde se tyto argumenty rozpadnou, a to vše, abychom vám pomohli lépe se rozhodnout, zda byste měli do agilního řízení produktů začlenit code freezes.

Argument 1: Zmrazení kódu je irelevantní a zbytečné

tento argument je velmi jednoduchý a konkrétní-moderní agilní metodiky a nástroje eliminovaly potřebu vyhrazeného QA a testovacího okna.

agilní metodiky, jako jsou recenze peer kódu, programování párů a neustálé sledování stavu systému, vám během vývoje poskytují mnohem větší přehled o výkonu aplikace nebo funkce. Chyby a problémy jsou jednodušší, a pravděpodobnější, být chycen během samotného vývoje, a vyřešeny před jakýmkoli vyhrazeným testováním a aktivitami QA.

nové nástroje také automatizovaly mnoho testů. Neustále vyhodnocují kód, aby se ujistili, že je vždy čistý a připravený k výrobě. Problémy jsou identifikovány v reálném čase a upozornění jsou okamžitě rozeslána, aby je vyřešila co nejdříve. Počet automatizovaných testů je již rozsáhlý a stále roste, což dramaticky snižuje objem ručních testů, které je třeba provést.

výsledek těchto nových agilních metodik a nástrojů je snadno viditelný. Většina základních testů a QA aktivit prováděných během zmrazení kódu je buď prováděna během vývoje, nebo prováděna softwarem. V Agile, software a funkce nyní ukončují vývoj na mnohem vyšší úrovni spolehlivosti, než tomu bylo dříve, takže vyhrazené zmrazení kódu je těžší a těžší ospravedlnit.

Argument 2: Code Freezes Break A Core Agile princip

tento druhý argument je o něco vyšší. V podstatě tvrdí, že code freezes nemají domov v agilní metodice, protože porušují jeden ze základních principů agilní metodiky-zkracují dobu mezi vývojem a vydáním.

čím rafinovanější je váš přístup k Agile, tím více se pokusíte zmenšit toto časové okno. Nejrafinovanějšími současnými přístupy k Agile jsou kontinuální integrace a kontinuální vývoj (CICD) a jejich cílem je rozdělit vývoj na malé přírůstkové změny, aby se změny kódu „uvolnily“ co nejrychleji. V nejčistší aplikaci CICD, vývoj a vydání sotva existují jako odlišné fáze-nový kód je integrován do aplikace téměř, jakmile je dokončena.

naproti tomu je třeba zachovat odlišné fáze vývoje a vydání, pokud se chystáte nasadit zamrznutí kódu. Koneckonců, to je místo, kde kód freeze žije – mezi těmito dvěma odlišnými fázemi. Místo toho, abyste se snažili minimalizovat nebo eliminovat toto časové okno mezi vývojem a vydáním, jako většina agilní metodiky, zmrazení kódu vás nutí formalizovat toto okno do té míry, že potřebujete vytvořit plány vývoje a vydání kolem něj.

pokud zmrazení kódu neodpovídá zásadám core Agile, pak je těžké učinit případ, že stále patří do metodiky.

Argument 3: zamrznutí kódu vede k pomalejším, méně kvalitním vydáním

tento konečný argument je velký a obsahuje několik různých úhlů.

Chcete-li začít, tvrdí, že zmrazení kódu přidává do vašeho plánu spoustu složitosti a dalších pohyblivých částí a přirozeně zvyšuje šance, že se něco pokazí a odhodí vaši časovou osu. I když se nic pokazí, práce zapojená do zmrazení kódu je časově náročná a nepředvídatelná (protože nevíte, jaké chyby najdete nebo jak dlouho bude jejich oprava trvat), že pouhým přidáním zmrazení kódu do plánu vytvoříte pomalejší vývojové a uvolňovací cykly.

dále tvrdí, že zmrazení kódu sníží produktivitu vašeho vývojového týmu. Zatímco agilní obecně, a konkrétně CICD, Udržujte své vývojáře neustále pracující v nepřerušeném řetězci produktivity, zmrazení kódu nutí vaše vývojáře zastavit práci v předem definovaných intervalech. Tímto způsobem porušíte jejich rytmus a přinutíte je, aby se pokusili obejít zásady zmrazení kódu, místo toho, abyste našli a udržovali jakýkoli tok, který je činí nejproduktivnějšími.

nakonec tvrdí, že vytvoření vyhrazených oken, kde přestanete přijímat obchodní požadavky, omezí funkce a funkce vašich verzí na vše, co lze dokončit před zmrazením, což povede k méně kvalitnímu a méně komplexnímu softwaru a aplikacím.

zamrznutí kódu: prohraná bitva?

v tuto chvíli to vypadá docela bezútěšně pro každého, kdo stále chce zahrnout zmrazení kódu do agilní metodiky. Kritici z této praxe uvádějí několik velmi přesvědčivých argumentů a celkově solidní případ, od vývoje moderní agilní metodiky, zamrznutí kódu se stalo:

1. zastaralé a irelevantní
2. nevyrovnané s moderními vývojovými postupy
3. překážkou rychlých a vysoce kvalitních verzí

ale i když jsou tyto argumenty přesvědčivé a obsahují mnoho přesných informací, nejsou neprůstřelné. A v každém z nich jsou zásadní nedostatky, které je třeba projednat před uzavřením knihy o zamrznutí kódu jako užitečného prvku agilního řízení produktů.

problém s argumentem 1: automatizované testování není komplexní

automatizované QA a agilní vývojové postupy zvýšily kvalitu kódu, jak je vyroben, to je fakt. Ale jen proto, že kus kódu prošel jednotkovým testováním, to neznamená, že je ve skutečnosti připraven na výrobu. Dokonce i ty nejjemnější přístupy CICD ne vždy zahrnují kritické kroky-jako regresní testování-které zajišťují, že část kódu je bez vad. Když na to přijde, existují jen některé věci, které nemůžete otestovat a vyřešit, když je kus kódu ve výrobě.

pokud se rozhodnete využít zmrazení kódu, nebudete se vzdát výhod automatizovaných QA a agilních osvědčených postupů. Vy a váš tým jednoduše chytíte menší, triviální problémy vašeho kódu během výroby, vymazání balíčků, abyste se zaměřili na zachycení větších problémů s vyšším dopadem během zmrazení, jako je celková stabilita a spolehlivost vašeho nového softwaru nebo funkce.

problém s argumentem 2: „snížit“, ne „eliminovat“

Agile je navržen tak, aby zkrátil dobu mezi vývojem a vydáním, to je také fakt. Ale je velký rozdíl mezi pokusem o zmenšení tohoto okna a pokusem o jeho úplné odstranění. To by bylo téměř nemožné, zejména u větších projektů.

zmrazení kódu může být v CICD velmi krátké-nebo se může vztahovat pouze na konkrétní větev, zatímco vývoj pokračuje na jiných větvích—ale stále existuje. Bez ohledu na to, jak rafinovaný Agile se stal, tam je téměř vždy bude bod ve všech vývojových a uvolňovacích plánů, kde nový kus softwaru nebo funkce budou vyhodnoceny v pevném stavu, než to jde ven uživatelům v reálném světě.

Problém S Argumentem 3: Přehodnocení rychlosti a kvality

pokud využijete zmrazení kódu, přidáte nový krok do svého vývojového a uvolňovacího cyklu. O tom není pochyb. A kdykoli přidáte nový krok do jakéhokoli procesu, zpomalíte tento proces a vytvoříte nový potenciální bod selhání. Zmrazení kódu není výjimkou.

ale je důležité udělat krok zpět a vzít širší pohled na zpomalení a ztracenou produktivitu.

pokud vaše funkce obsahuje chyby, budete je muset opravit, bez ohledu na to, zda jste tyto chyby zachytili během zmrazení kódu, nebo zda se po vydání přihlásili. Z čistě vývojového hlediska bude doba potřebná k jejich opravě v obou scénářích přibližně stejná.

ale pokud máte co do činění s chybami v živém prostředí, máte řadu dalších problémů, které je třeba vzít čas na řešení, včetně:

• rozhodování o tom, zda vrátit funkci buggy zpět nebo ji nechat žít.
• přičemž své vývojáře z jejich nových projektů, poté, co jsem začal pracovat.
• dělat to svým uživatelům v reálném světě, kteří byli ovlivněni chybami.
• odpovídání a řízení vašich interních zúčastněných stran, které nejsou příliš šťastné z vašeho problematického vydání.

seznam pokračuje. Není nic složitějšího, časově náročnějšího a ničivějšího pro produktivitu-pro vás a váš tým-než uvolnění nefunkční funkce nebo produktu. Kód zamrzne minimalizovat šance na to děje.

a pokud jde o argument, že zmrazení kódu vede k nižší kvalitě funkcí a produktů, protože snižují množství obchodních požadavků, které můžete sbírat? Vaše obchodní požadavky budou vždy o něco více než „nejlepší odhad“, jak by měl váš produkt nebo funkce fungovat. Nejcennější požadavky budou vždy pocházet od uživatelů v reálném světě, nasazení vašeho produktu nebo funkce v reálných scénářích. A tyto požadavky můžete sbírat pouze tím, že svým uživatelům poskytnete funkční verze, které mohou nasadit co nejplynuleji a bez chyb.

měli byste využít zmrazení kódu ve vašem agilním řízení produktů?

nakonec zmrazení kódu stále hraje důležitou roli pro mnoho agilních produktových manažerů.

nyní existují případy, kdy hrají méně kritickou roli. Velmi malé projekty nemusí vyžadovat vyhrazené období zmrazení kódu. Nové funkce, které mají relativně malé důsledky, pokud jsou nedokonale dodávány, nemusí stát za zmrazení. Totéž platí pro plány postupného uvolňování-jako Kanárské vydání-když si jen chcete vyzkoušet nové funkce s vřelým publikem, které jste připraveni očekávat buggy, nedokonalý zážitek.

ale ve většině případů stojí za to věnovat čas-dokonce i velmi krátkou dobu—, abyste se ujistili, že vaše nové funkce jsou tak dokonalé, jak si myslíte, že jsou, než je vložíte do rukou lidí, na kterých záleží nejvíce: vaši uživatelé v reálném světě.

tento článek byl původně publikován na flagship.io