Sdílet prostřednictvím

Podpora přechodu pomocí digitálních vynálezů

  • Článek

Konečným testem inovací je reakce zákazníka na váš vynález. Ukázala se hypotéza pravdivá? Používají zákazníci toto řešení? Škáluje se tak, aby vyhovovala potřebám požadovaného procenta uživatelů? A co je nejdůležitější, budou se pořád vracet? Žádná z těchto otázek se nedá položit, dokud se nenasadí řešení MVP (Minimum Viable Product).

V tomto článku se zaměříme na podporu přechodu pomocí nástrojů kanálu kontinuální integrace a průběžného nasazování (CI/CD). Kontinuální integrace je automatizace kódu několikrát denně, aby se aktualizoval jeden projekt. Průběžné nasazování je automatické doručování těchto funkcí v průběhu dne.

Omezení tření CI/CD, které ovlivňuje přijetí

Některé překážky přijetí je možné minimalizovat kombinací technologií a procesů. Čtenáři se znalostmi procesů CI/CD nebo DevOps budou znát následující procesy kanálů CI/CD. Tento článek vytváří výchozí bod pro týmy přechodu na cloud, které podporují inovace a smyčky zpětné vazby. Tento výchozí bod může podporovat robustnější přístupy k CI/CD nebo DevOps s tím, jak produkty a týmy dospívají.

Jak je popsáno v tématu Měření dopadu na zákazníka, pozitivní ověření jakékoli hypotézy vyžaduje iteraci a určení. Cílem tohoto článku o CI/CD je minimalizovat technické špičky , které zpomalují inovace, a zároveň zajistit, abyste zachovali osvědčené postupy. Pomůžete tím týmu navrhnout budoucí úspěch a současně splnit aktuální potřeby zákazníků.

Posílení přechodu a digitálních vynálezů: Model vyspělosti

Primárním cílem metodiky inovací je budovat partnerství se zákazníky a urychlit smyčky zpětné vazby, což vede k inovacím na trhu. Následující obrázek a části popisují počáteční implementace, které tuto metodologii podporují.

Diagram znázorňující model vyspělosti přechodu na podporu

Pokud chcete minimalizovat technické špičky, předpokládejme, že vyspělost bude zpočátku v rámci těchto principů nízká. Plánujte dopředu tím, že se přizpůsobíte nástrojům a procesům, které se můžou škálovat, jakmile budou hypotézy jemněji odstupňované. GitHub a Azure DevOps v Azure umožňují malým týmům začít s minimálními třeními. Tyto týmy se můžou rozrůst o tisíce vývojářů, kteří spolupracují na škálovaných řešeních a testují stovky hypotéz zákazníků. Zbytek tohoto článku ukazuje přístup "plánování velkého, zahájení v malém", který umožňuje přechod na základě těchto principů.

Sdílené řešení

Jak je popsáno v tématu Měření dopadu na zákazníka, pozitivní ověření jakékoli hypotézy vyžaduje iteraci a určení. Během jakéhokoli inovačního cyklu se setkáte s mnohem více selháními, než kolik zvítězí. To se očekává. Když ale zákazník potřebuje, hypotézu a řešení ve velkém měřítku, svět se rychle změní.

Při škálování digitálních vynálezů a inovací neexistuje cennější nástroj, než je sdílený základ kódu řešení. Bohužel neexistuje žádný spolehlivý způsob, jak předpovědět, která iterace nebo který MVP získá vítěznou kombinaci. Proto není nikdy příliš brzy na vytvoření sdíleného základu kódu nebo úložiště. Toto je jediná technická špička , která by se neměla zpozdit. Když tým prochází různá řešení MVP, sdílené úložiště umožňuje snadnou spolupráci a zrychlený vývoj. Když změny v řešení přetáhnou dolů metriky učení, správa verzí vám umožní vrátit se k dřívější a efektivnější verzi řešení.

Nejčastěji používaným nástrojem CI/CD pro správu úložišť kódu je GitHub, který umožňuje vytvořit sdílené úložiště kódu v několika krocích. K vytvoření úložiště Git nebo TFVC je navíc možné použít Azure Repos funkci Azure DevOps.

Smyčky zpětné vazby

Vytvoření zákazníka jako součásti řešení je klíčem k budování partnerství se zákazníky během inovačních cyklů. Toho se dosahuje částečně měřením dopadu na zákazníky. Vyžaduje rozhovory a přímé testování se zákazníkem. Oba generují zpětnou vazbu, kterou je potřeba efektivně spravovat.

Každý bod zpětné vazby je potenciálním řešením pro potřeby zákazníka. Důležitější je, že každá přímá zpětná vazba od zákazníků představuje příležitost ke zlepšení partnerství. Pokud se zpětná vazba stane řešením MVP, oslavte to se zákazníkem. I když určitou zpětnou vazbu není možné použít, pouhá transparentnost rozhodnutí o vyřazení zpětné vazby ukazuje růstové myšlení a zaměření se na průběžné učení.

Azure DevOps zahrnuje způsoby , jak požadovat, poskytovat a spravovat zpětnou vazbu. Tyto nástroje centralizuje zpětnou vazbu, aby tým mohl podniknout kroky a poskytovat následná opatření v rámci transparentní smyčky zpětné vazby.

Kontinuální integrace

Kontinuální integrace je automatizace kódu několikrát denně, aby se aktualizoval jeden projekt. S tím, jak se přechody škálují a hypotéza se ve velkém blíží skutečným inovacím, má počet testovaných menších hypotéz tendenci rychle narůstat. Pro přesné smyčky zpětné vazby a bezproblémové procesy přijetí je důležité, aby tyto hypotézy byly integrované a podporovaly primární hypotézu inovací. To vyžaduje rychlý přechod k inovacím a růstu, což vyžaduje více vývojářů pro testování variací základní hypotézy. Pro pozdější fázi vývoje můžete dokonce potřebovat několik týmů vývojářů, z nichž každý bude směřovat ke sdílenému řešení. Kontinuální integrace je prvním krokem ke správě všech pohyblivých částí.

Při kontinuální integraci se změny kódu často sloučí do hlavní větve. Automatizované procesy sestavení a testování zajišťují, aby kód v hlavní větvi byl vždy v produkční kvalitě. Tím se zajistí, že vývojáři budou spolupracovat na vývoji sdílených řešení, která poskytují přesné a spolehlivé smyčky zpětné vazby.

Azure DevOps a Azure Pipelines poskytují možnosti průběžné integrace v několika krocích v GitHubu nebo jiných úložištích. Další informace najdete v tématu Co je kontinuální integrace? nebo vyzkoušejte praktické cvičení pro průběžnou integraci. K dispozici jsou architektury řešení, které můžou urychlit vytváření kanálů CI/CD prostřednictvím Azure DevOps.

Spolehlivé testování

Vady v jakémkoli řešení mohou být falešně pozitivní nebo falešně negativní. Neočekávané chyby můžou snadno vést k nesprávné interpretaci metrik přijetí uživateli. Můžou také generovat negativní zpětnou vazbu od zákazníků, která přesně nevystižuje test vaší hypotézy.

Během časných iterací řešení MVP se očekávají vady. Raní uživatelé by je mohli dokonce považovat za roztomilé. V dřívějších verzích obvykle neexistuje akceptační testování. Jeden aspekt budování s empatií se však týká ověření potřeby a hypotézy. Obojí je možné dokončit prostřednictvím testů jednotek na úrovni kódu a ručních akceptačních testů před nasazením. Společně poskytují některé možnosti spolehlivosti při testování. Měli byste se pokusit automatizovat dobře definovanou řadu testů sestavení, jednotek a akceptace. Ty zajistí spolehlivé metriky související s jemnějšími úpravami hypotézy a výsledného řešení.

Funkce Azure Test Plans poskytuje nástroje pro vývoj a provoz testovacích plánů během ručního nebo automatizovaného provádění testů.

Nasazení řešení

Možná nejsouznamnějším aspektem přechodu je vaše schopnost řídit vydávání řešení pro zákazníky. Poskytnutím samoobslužného nebo automatizovaného kanálu pro vydávání řešení zákazníkům zrychlíte smyčku zpětné vazby. Když zákazníkům umožníte rychle pracovat se změnami v řešení, pozvete je do procesu. Tento přístup také spouští rychlejší testování hypotéz, což snižuje předpoklady a potenciální přepracování.

Existuje několik metod nasazení řešení. Mezi tři nejběžnější patří:

  • Průběžné nasazování je nejpokročilejší metoda, protože automaticky nasazuje změny kódu do produkčního prostředí. Pro vyspělé týmy, které testují vyspělé hypotézy, může být průběžné nasazování mimořádně cenné.
  • Během počátečních fází vývoje může být vhodnější průběžné doručování . Při průběžném doručování se všechny změny kódu automaticky nasadí do produkčního prostředí. Vývojáři, pracovníci s rozhodovací pravomocí a další členové týmu můžou pomocí tohoto prostředí ověřit, že jejich práce je připravená na produkční prostředí. Tuto metodu můžete použít také k testování hypotézy se zákazníky, aniž by to ovlivnilo probíhající obchodní aktivity.
  • Ruční nasazení je nejméně sofistikovaný přístup ke správě vydaných verzí. Jak název napovídá, někdo v týmu ručně nasadí nejnovější změny kódu. Tento přístup je náchylný k chybám, nespolehlivý a většina zkušených techniků ho považuje za antipattern.

Během první iterace řešení MVP je ruční nasazení běžné, a to navzdory předchozímu posouzení. Pokud je řešení velmi plynulé a zpětná vazba od zákazníků neznámá, existuje značné riziko při resetování celého řešení (nebo dokonce základní hypotézy). Tady je obecné pravidlo pro ruční nasazení: žádné ověření zákazníkem, žádná automatizace nasazení.

Včasné investování může vést ke ztrátě času. Ještě důležitější je, že může vytvořit závislosti na kanálu verze, díky kterým bude tým odolnější vůči počátečnímu pivotu. Po několika prvních iteracích nebo když zpětná vazba od zákazníků naznačuje potenciální úspěch, by se měl rychle přijmout pokročilejší model nasazení.

V jakékoli fázi ověřování hypotéz poskytují Azure DevOps a Azure Pipelines možnosti průběžného doručování a průběžného nasazování. Přečtěte si další informace o průběžném doručování nebo se podívejte na praktické cvičení. Architektura řešení může také urychlit vytváření kanálů CI/CD prostřednictvím Azure DevOps.

Integrovaná měření

Při měření dopadu na zákazníky je důležité pochopit, jak zákazníci reagují na změny v řešení. Tato data, označovaná jako telemetrie, poskytují přehled o akcích, které uživatel (nebo kohorta uživatelů) provedl při práci s řešením. Z těchto dat je snadné získat kvantitativní ověření hypotézy. Tyto metriky se pak dají použít k úpravě řešení a vygenerování podrobnějších hypotéz. Tyto jemnější změny pomáhají vyzrát počáteční řešení v pozdějších iteracích a nakonec povedou k opakovanému přijetí ve velkém měřítku.

Azure Monitor poskytuje v Azure nástroje a rozhraní pro shromažďování a kontrolu dat z prostředí zákazníků. Tato pozorování a přehledy můžete použít k upřesnění backlogu pomocí Azure Boards.

Další kroky

Jakmile získáte znalosti o nástrojích a procesech kanálu CI/CD potřebných k podpoře přechodu, je čas prozkoumat pokročilejší inovační disciplínu: interakci se zařízeními. Tato disciplína může pomoci snížit překážky mezi fyzickými a digitálními prostředími a usnadnit tak přijetí vašeho řešení.

Interakce se zařízeními