Programování

Co je agilní metodika? Vysvětlení moderního softwaru

Zdá se, že každá technologická organizace dnes praktikuje agilní metodiku pro vývoj softwaru nebo její verzi. Nebo alespoň věří, že ano. Ať už jste v agilním vývoji aplikací noví, nebo jste se vývoj softwaru naučili před desítkami let pomocí metodiky vývoje softwaru waterfall, dnes je vaše práce přinejmenším ovlivněna agilní metodikou.

Co je to ale agilní metodologie a jak by se měla praktikovat při vývoji softwaru? Jak se agilní vývoj liší od vodopádu v praxi? Co je to životní cyklus agilního vývoje softwaru nebo agilní SDLC? A co je agilní scrum versus Kanban a další agilní modely?

Společnost Agile byla oficiálně zahájena v roce 2001, kdy 17 technologů vypracovalo Agilní manifest. Napsali čtyři hlavní principy agilního řízení projektů s cílem vyvinout lepší software:

  • Jednotlivci a interakce nad procesy a nástroji
  • Pracovní software přes komplexní dokumentaci
  • Spolupráce se zákazníky při vyjednávání smluv
  • Reakce na změnu v průběhu sledování plánu

Before agile: The era of waterfall metodologie

Staré ruce jako já si pamatují časy, kdy byla metodika vodopádu zlatým standardem pro vývoj softwaru. Proces vývoje softwaru vyžadoval spoustu dokumentace předem, než začalo jakékoli kódování. Někdo, obvykle obchodní analytik, nejprve napsal dokument s obchodními požadavky, který zachytil vše, co podnikání v aplikaci potřebovalo. Tyto dokumenty obchodních požadavků byly dlouhé a podrobně popisovaly vše: celkovou strategii, komplexní funkční specifikace a vizuální návrhy uživatelského rozhraní.

Technologové vzali dokument s obchodními požadavky a vyvinuli vlastní dokument s technickými požadavky. Tento dokument definoval architekturu aplikace, datové struktury, objektově orientované funkční návrhy, uživatelská rozhraní a další nefunkční požadavky.

Tento proces vývoje softwaru vodopádu by konečně nastartoval kódování, poté integraci a nakonec testování, než bude aplikace považována za připravenou k výrobě. Celý proces může snadno trvat několik let.

Od nás vývojářů se očekávalo, že budeme znát „specifikaci“, jak se nazývala úplná dokumentace, stejně dobře, jako to věděli autoři dokumentů, a byli jsme často pokáráni, pokud jsme zapomněli správně implementovat klíčový detail popsaný na straně 77 stránkový dokument.

Tehdy také samotný vývoj softwaru nebyl snadný. Mnoho vývojových nástrojů vyžadovalo specializované školení a nikde poblíž open source ani komerčních softwarových komponent, API a webových služeb, které dnes existují. Museli jsme vyvinout věci na nízké úrovni, jako je otevření databázových připojení a multithreading našeho zpracování dat.

I pro základní aplikace byly týmy velké a komunikační nástroje byly omezené. Naše technické specifikace odpovídaly nám a my jsme je využívali jako Bibli. Pokud by se požadavek změnil, provedli bychom vedoucí firmy dlouhým procesem kontroly a odhlášení, protože komunikace změn v týmu a oprava kódu byla nákladná.

Protože byl software vyvinut na základě technické architektury, byly nejprve vyvinuty artefakty nižší úrovně a poté artefakty závislé. Úkoly byly přidělovány dovednostmi a bylo běžné, že databázoví inženýři nejprve vytvořili tabulky a další artefakty databáze, poté vývojáři aplikací kódující funkčnost a obchodní logiku a nakonec bylo překryto uživatelské rozhraní. Trvalo měsíce, než kdokoli viděl, že aplikace funguje, a do té doby se zúčastněné strany staly nepříjemnými a často chytřejšími o tom, co opravdu chtějí. Není divu, že implementace změn byla tak drahá!

Ne všechno, co jste dali uživatelům, fungovalo podle očekávání. Uživatelé někdy funkci vůbec nepoužívají. Jindy byla funkce široce úspěšná, ale vyžadovala reengineering, aby podpořila potřebnou škálovatelnost a výkon. Ve světě vodopádů jste se tyto věci naučili až po nasazení softwaru, po dlouhém vývojovém cyklu.

Související video: Jak agilní metodika skutečně funguje

Zdá se, že všichni mluví o agilním vývoji softwaru, ale mnoho organizací nemá pevné pochopení toho, jak tento proces funguje. Podívejte se na toto pětiminutové video a rychle se rozjeďte.

Klíč k agilnímu vývoji softwaru

Metodika vodopádu, která byla vynalezena v roce 1970, byla revoluční, protože přinesla disciplínu do vývoje softwaru, aby zajistila, že bude následovat jasná specifikace. Byl založen na metodě výroby vodopádu odvozené z inovací montážní linky Henryho Forda z roku 1913, která poskytovala jistotu v každém kroku výrobního procesu, aby bylo zaručeno, že konečný produkt odpovídá tomu, co bylo na prvním místě.

Když se do softwarového světa dostala vodopádová metodika, výpočetní systémy a jejich aplikace byly obvykle složité a monolitické a vyžadovaly disciplínu a jasný výsledek. Ve srovnání s dneškem se požadavky také pomalu měnily, takže rozsáhlé úsilí bylo méně problematické. Ve skutečnosti byly systémy postaveny za předpokladu, že se nezmění, ale budou věčnými bitevními loděmi. Víceleté časové rámce byly běžné nejen při vývoji softwaru, ale také při výrobě a dalších podnikových činnostech. Ale tuhost vodopádu se stala Achillovou patou v éře internetu, kde byla vyžadována rychlost a flexibilita.

Metodika vývoje softwaru se začala měnit, když vývojáři začali pracovat na internetových aplikacích. Mnoho počátečních prací bylo provedeno u startupů, kde byly týmy menší, byly barevně uspořádány a často neměly tradiční prostředí počítačové vědy. Existovaly finanční a konkurenční tlaky na rychlejší uvedení webových stránek, aplikací a nových funkcí na trh. V reakci na to se vývojové nástroje a platformy rychle změnily.

To vedlo mnoho z nás pracujících v startupech k otázkám ohledně metodiky vodopádů a hledání způsobů, jak být efektivnější. Nemohli jsme si dovolit dělat veškerou podrobnou dokumentaci předem a potřebovali jsme více iterativní a kolaborativní proces. Stále jsme diskutovali o změnách požadavků, ale byli jsme otevřenější experimentům a přizpůsobení se potřebám koncových uživatelů. Naše organizace byly méně strukturované a naše aplikace byly méně složité než starší podnikové systémy, takže jsme byli mnohem otevřenější budování oproti nákupu aplikací. Ještě důležitější je, že jsme se snažili rozvíjet podniky, takže když nám naši uživatelé řekli, že něco nefunguje, rozhodli jsme se je častěji poslouchat.

Naše dovednosti a naše schopnosti inovovat se staly strategicky důležitými. Mohli byste získat všechny peníze, které jste chtěli, ale nemohli byste přilákat talentované softwarové vývojáře schopné pracovat s rychle se měnícími internetovými technologiemi, pokud s nimi budete zacházet jako s podřízenými programátory otrocky podle „specifikace“. Odmítli jsme projektové manažery, kteří přicházeli s end-to-end plány popisujícími, co bychom měli vyvinout, kdy by se aplikace měly dodávat, a někdy dokonce i to, jak strukturovat kód. Byli jsme strašliví, když jsme narazili na tříměsíční a šestiměsíční plány, které manažeři projektů vodopádu navrhovali a neustále aktualizovali.

Místo toho jsme jim začali říkat, jak je třeba navrhovat internetové aplikace, a výsledky jsme dodávali podle plánu, který jsme iterativně sestavili. Ukázalo se, že jsme nebyli tak špatní, když jsme dodali to, co jsme řekli, když jsme se k tomu zavázali, v malých týdenních až čtyřtýdenních intervalech.

V roce 2001 se skupina zkušených vývojářů softwaru spojila a uvědomila si, že společně praktikují vývoj softwaru odlišně od klasické metodiky vodopádu. A nebyli všichni v startupech. Tato skupina, která zahrnovala technologické osobnosti Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber a Jeff Sutherland, přišla s Agilním manifestem, který dokumentoval jejich sdílenou víru v to, jak by měl moderní proces vývoje softwaru fungovat. Zdůraznili spolupráci ohledně dokumentace, spíše sebeorganizace než rigidních praktik řízení a schopnosti zvládat neustálé změny, spíše než se omezovat na rigidní proces vývoje vodopádu.

Z těchto principů se zrodila agilní metodika vývoje softwaru.

Role v agilní metodice

Agilní proces vývoje softwaru vždy začíná definováním uživatelů a dokumentací prohlášení o vizi o rozsahu problémů, příležitostí a hodnot, které je třeba řešit. Vlastník produktu tuto vizi vystihuje a při plnění této vize pracuje s multidisciplinárním týmem (nebo týmy). Zde jsou role v tomto procesu.

Uživatel

Agilní procesy vždy začínají s ohledem na uživatele nebo zákazníka. Dnes je často definujeme pomocí uživatelských osob, abychom ilustrovali různé role v pracovním toku, který software podporuje, nebo různé typy potřeb a chování zákazníků.

Vlastník produktu

Samotný proces agilního vývoje začíná u někoho, od koho se vyžaduje, aby byl hlasem zákazníka, včetně všech interních zúčastněných stran. Tato osoba destiluje všechny postřehy, nápady a zpětnou vazbu, aby vytvořila vizi produktu. Tyto vize produktů jsou často krátké a přímočaré, nicméně vytvářejí obraz o tom, kdo je zákazník, jaké hodnoty jsou řešeny, a strategii, jak je řešit. Dokážu si představit, že původní vize Googlu vypadala asi jako „Pojďme usnadnit každému, kdo má přístup na internet, najít relevantní webové stránky a webové stránky pomocí jednoduchého rozhraní založeného na klíčových slovech a algoritmu, který ve výsledcích vyhledávání řadí renomované zdroje výše.“

Tomuto člověku říkáme produktový vlastník. Jeho odpovědností je definovat tuto vizi a poté spolupracovat s vývojovým týmem na jejím uskutečnění.

Při práci s vývojovým týmem produktový vlastník rozdělí vizi produktu na řadu uživatelských příběhů, které podrobněji vysvětlí, kdo je cílový uživatel, jaký problém se pro ně řeší, proč je pro ně řešení důležité a jaká omezení a kritéria přijetí definují řešení. Tyto uživatelské příběhy jsou upřednostňovány vlastníkem produktu a zkontrolovány týmem, aby bylo zajištěno, že mají společné porozumění tomu, co se od nich požaduje.

Tým pro vývoj softwaru

Agilní vývojový tým a odpovědnosti jeho členů se liší od odpovědností v tradičním vývoji softwaru.

Týmy jsou multidisciplinární a skládají se z různorodé skupiny lidí se schopnostmi dokončit práci. Vzhledem k tomu, že se soustředíme na poskytování pracovního softwaru, musí tým dokončit kompletní funkční aplikace. Takže databáze, obchodní logika a uživatelské rozhraní část aplikace vyvinuta a poté předvedena - ne celá aplikace. K tomu musí členové týmu spolupracovat. Setkávají se často, aby se ujistili, že je každý v souladu s tím, co staví, s tím, kdo co dělá, a přesně s tím, jak se software vyvíjí.

Kromě vývojářů mohou týmy pro vývoj softwaru zahrnovat inženýry pro zajištění kvality (QA), další inženýry (například pro databáze a back-end systémy), designéry a analytiky, v závislosti na typu softwarového projektu.

Scrum, Kanban a další agilní rámce

Mnoho agilních frameworků, které poskytují specifika vývojových procesů a agilních vývojových postupů, přizpůsobených životnímu cyklu vývoje softwaru.

Nazývá se nejpopulárnější agilní framework skrumáž. Zaměřuje se na kadenci doručení zvanou a sprint a struktury setkání, které zahrnují následující:

  • Plánování - kde jsou identifikovány priority sprintu
  • Závazek - kde tým zkontroluje seznam nebo nevyřízené položky uživatelských příběhů a rozhodne, kolik práce lze udělat za dobu trvání sprintu
  • Denní stand-up schůzky - takže týmy mohou komunikovat aktuální informace o svém vývoji a strategiích)

Sprinty končí ukázkovou schůzkou, kde se funkcionalita zobrazí vlastníkovi produktu, následovanou retrospektivní schůzkou, kde tým diskutuje o tom, co proběhlo dobře a co je třeba zlepšit v jejich procesu.

Mnoho organizací zaměstnává mistry skrumáže nebo trenéry, kteří týmům pomáhají řídit proces skrumáže.

Ačkoli dominuje scrum, existují i ​​jiné agilní rámce:

  • Kanban funguje jako proces fan-in a fan-out, kde tým vytahuje uživatelské příběhy z přijímací desky a trychtýří je procesem postupného vývoje, dokud nejsou dokončeny.
  • Některé organizace používají hybridní agilní a vodopádový přístup, využívající agilní procesy pro nové aplikace a vodopád pro ty starší.
  • Existuje také několik rámců, které organizacím umožňují rozšířit praxi na více týmů.

Zatímco agilní rámce definují proces a spolupráci, agilní vývojové postupy jsou specifické pro řešení úkolů vývoje softwaru prováděných v souladu s agilním rámcem.

Například:

  • Některé týmy přijímají párové programování, kde dva vývojáři kódují společně, aby řídili kvalitnější kód a umožnili vyšším vývojářům mentorovat ty mladší.
  • Pokročilejší týmy používají vývoj a automatizaci zaměřenou na testování, aby zajistily, že základní funkce přinese očekávané výsledky.
  • Mnoho týmů také přijímá technické standardy, aby interpretace uživatelského příběhu vývojáře nevedla pouze k požadované funkčnosti, ale splňovala také zabezpečení, kvalitu kódu, konvence pojmenování a další technické standardy.

Proč je agilní metodika lepší

$config[zx-auto] not found$config[zx-overlay] not found