Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Agile je termín, který popisuje přístupy k vývoji softwaru, které zdůrazňují přírůstkové doručování, týmovou spolupráci, průběžné plánování a průběžné učení. Termín Agile byl vytvořen v roce 2001 v agilním manifestu. Manifest si kladl za cíl nastavit zásady, které usměrní lepší přístup k vývoji softwaru. V jádru manifesto deklaruje čtyři příkazy hodnot, které představují základ agilního pohybu. Jak je uvedeno, manifesto uvádí:
Přišli jsme na hodnotu:
- Jednotlivci a interakce jsou důležitější než procesy a nástroje.
- Funkční software má přednost před komplexní dokumentací.
- Spolupráce zákazníků přes vyjednávání smluv
- Reakce na změnu místo dodržování plánu.
Manifest nemá naznačovat, že položky na pravé straně těchto prohlášení nejsou důležité nebo potřebné. Místo toho jsou položky vlevo jednoduše hodnotnější.
Agilní metody a postupy
Je důležité si uvědomit, že Agile není věc. Agile nepraktikujete. Agilní je spíše myšlení, které řídí přístup k vývoji softwaru. Vzhledem k tomu, že neexistuje jediný přístup, který by fungoval ve všech situacích, přišel termín Agile představovat různé metody a postupy, které jsou v souladu s příkazy hodnot v manifestu.
Agilní metody, které se často označují jako architektury, jsou komplexní přístupy k fázím životního cyklu DevOps: plánování, vývoj, doručování a provoz. Předepisují metodu pro práci s jasnými pokyny a zásadami.
Scrum je nejběžnější agilní architektura a ta, se kterou začíná většina lidí. Agilní postupy jsou na druhou stranu techniky, které se používají ve fázích životního cyklu vývoje softwaru.
- Plánování Pokeru je postup odhadu spolupráce, který je navržený tak, aby členům týmu podporoval, aby se podělili o to, co se dělá . Mnoho lidí našel proces zábavné a ukázalo se, že pomáhá podporovat týmovou práci a lepší odhady.
- Kontinuální integrace (CI) je běžný agilní technický postup, který často zahrnuje integraci změn kódu do hlavní větve. Automatizované sestavení ověřuje změny. V důsledku toho dochází ke snížení integračního dluhu a nepřetržitě přepravitelné hlavní větve.
Tyto postupy, jako jsou všechny agilní postupy, mají agilní popisek, protože jsou konzistentní s principy v manifestu Agile.
Co agilní není
Jak Agile získalo popularitu, mnoho stereotypů a chybných interpretací vrhlo negativní stín na její účinnost. Je snadné říct "Ano, děláme agilní", bez jakékoli odpovědnosti. Mějte na paměti několik věcí, které Agile není.
- Agilní kódování není kovbojské. Agilní by se nemělo zaměňovat s přístupem "my to zjistíme, jak jdeme" k vývoji softwaru. Takový nápad nemohl být dál od pravdy. Agilní metodika vyžaduje jak definici dokončení, tak i explicitní hodnotu, která se dodává zákazníkům v každém sprintu. Přestože agilní metodiky hodnotí autonomii jednotlivců a týmů, zdůrazňují sladěnou autonomii, aby zajistily, že zvýšená autonomie přináší větší hodnotu.
- Agilní metody nejsou bez rigoróznosti a plánování. Naopak agilní metodologie a postupy obvykle zvýrazňují disciplínu při plánování. Klíčem je průběžné plánování v celém projektu, nejen plánování předem. Průběžné plánování zajišťuje, aby se tým mohl učit z práce, kterou provádí. Díky tomuto přístupu maximalizují návratnost investic (ROI) plánování.
"Plány jsou bezcenné, ale plánování je všechno." – Dwight D. Eisenhower
- Agilní funkce není omluvou pro nedostatek plánu. Tato špatná představa pravděpodobně způsobila největší škodu celkovému agilnímu pohybu. Organizace a týmy, které sledují agilní přístup, naprosto vědí, kde se chystají, a výsledky, které chtějí dosáhnout. Rozpoznávání změn v rámci procesu se liší od otáčení v novém směru každý týden, sprint nebo měsíc.
- Agilní vývoj není bez specifikací. V jakémkoli projektu je potřeba udržovat tým v souladu s tím, proč a jak se práce provádí. Agilní přístup ke specifikacím zahrnuje zajištění správné velikosti specifikací a odpovídajícího způsobu fungování týmových sekvencí a poskytování práce.
- Agilní přístup není neschopný přizpůsobit se neplánované práci a jiným přerušením. Je důležité dokončit sprinty podle plánu. Jen proto, že se objeví problém, který odklání vývoj, neznamená, že sprint musí selhat. Týmy mohou plánovat přerušení tím, že předem vyhradí zdroje na problémy a nepředvídatelné situace. Tyto problémy pak můžou řešit, ale budou mít přehled o vývoji.
- Agilní funkce není pro velké organizace nevhodná. Běžnou stížností je, že spolupráce, klíčovou součástí agilních metodologií, je ve velkých týmech obtížná. Další stížností je, že škálovatelné přístupy k Agilu představují strukturu a metody, které ohrožují flexibilitu. I přes tyto chybné představy je možné úspěšně škálovat agilní principy. Informace o řešení těchto potíží najdete v tématu Škálování agilního přístupu pro velké týmy.
- Agilní funkce není neefektivní. Aby se vývojáři přizpůsobili měnícím se potřebám zákazníků, investují v každé iteraci čas, aby předvedli funkční produkt a shromáždili zpětnou vazbu. Je pravda, že tyto snahy zkracují čas strávený vývojem. Začlenění zákaznických požadavků v rané fázi ušetří významný čas později. Když budou funkce v souladu s vizí zákazníka, vývojáři se vyhýbají zásadním opravám.
- Agilní aplikace nejsou vhodné pro dnešní aplikace, které se často soustředí na streamování dat. Takové projekty obvykle zahrnují více úloh modelování dat a extrakce a transformace (ETL) než uživatelská rozhraní. Tento fakt znesnadňuje předvedení použitelného softwaru v konzistentním a těsném plánu. Ale úpravou cílů můžou vývojáři stále používat agilní přístup. Vývojáři se místo práce na provádění jednotlivých iterací můžou soustředit na spouštění experimentů s daty. Namísto prezentování funkčního produktu každých pár týdnů se mohou zaměřit na lepší pochopení dat.
Proč agilní?
Tak proč by někdo zvážil agilní přístup? Je zřejmé, že pravidla zapojení ohledně sestavování softwaru se v posledních 10 až 15 letech zásadně změnila. Řada aktivit vypadá podobně, ale krajina a prostředí, kde je používáme, jsou výrazně odlišné.
- Porovnejte, jaké je dnes nakupování softwaru s počátky 2000. let. Jak často lidé jezdí do storu a kupují si obchodní software?
- Zvažte, jak se shromažďuje zpětná vazba od zákazníků o produktech. Jak tým pochopil, co lidé mysleli na svůj software před sociálními sítěmi?
- Zvažte, jak často tým chce aktualizovat a vylepšit software, který poskytuje. Roční aktualizace už nejsou pro moderní hospodářskou soutěž proveditelné.
Forrester's Diego Lo Guidice to nejlépe vystihuje na svém blogu Transforming Application Delivery (říjen 2020).
"Všechno se dramaticky změnilo. Udržitelnost, kromě zelené a čisté, znamená, že to, co dnes budujeme, musí být snadno a rychle změněno zítra. Strategické plány jsou krátkodobé a plánování a změny jsou průběžné." – Diego Lo Guidice, Forrester
Pravidla se změnila a organizace po celém světě se teď odpovídajícím způsobem přizpůsobují vývoji softwaru. Agilní metody a postupy neslíbí, že vyřeší každý problém. Slibují ale, že vytvoří kulturu a prostředí, kde se řešení objevují prostřednictvím spolupráce, neustálého plánování a učení a přání dodávat vysoce kvalitní software častěji.
Další kroky
Rozhodování o agilní cestě k vývoji softwaru může představovat zajímavé příležitosti k vylepšení procesu DevOps. Jedním z klíčových aspektů se zaměřuje na to, jak agilní vývoj porovnává a kontrastuje s aktuálním přístupem organizace.