Co znamená agilní?

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

Agile je termín, který popisuje přístupy k vývoji softwaru, který zdůrazňuje 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 nastavil zásady, které vedou 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 nad procesy a nástroji.
  • Funkční software v komplexní dokumentaci.
  • Spolupráce zákazníků přes vyjednávání smluv
  • Reagování na změnu podle plánu.

Manifest neznamená, že položky na pravé straně těchto příkazů nejsou důležité ani 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 agilní funkce není nic. Agilní neděláte. 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 agilní získala popularitu, mnoho stereotypů a chybných interpretací přetypovalo negativní stín na jeho účinnost. Je snadné říct "Ano, děláme agilní", bez jakékoli odpovědnosti. Mějte na paměti několik věcí, které agilní nejsou.

  • 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í vyžaduje definici hotové i explicitní hodnoty, která se dodává zákazníkům v každém sprintu. I když agilní hodnoty pro jednotlivce a týmy zdůrazňuje sladěnou autonomii, aby se zajistilo, že zvýšená autonomie vytváří vyšší hodnotu.
  • Agilní není bez rigoritu 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 stane. 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í funkce nedokáže vyjmout neplánovanou práci a další přerušení. Je důležité dokončit sprinty podle plánu. Ale jen proto, že problém přichází s tím, že vývoj vedlejších služeb neznamená, že sprint musí selhat. Týmy můžou plánovat přerušení tím, že předem navrhnou zdroje problémů a neočekávaných problémů. 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ší možností je, že škálovatelné přístupy k agilnímu přístupu představují strukturu a metody, které ohrožuje 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í pokaždé iteraci, aby si ukázali 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šak brzy 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. Místo prezentování funkčního produktu každých několik týdnů se jim může lépe porozumět datům.

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, co se dnes líbí k nákupu softwaru, s počátku 2000s. 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 říká, že je to nejlepší v jeho blogu Transforming Application Delivery (říjen 2020).

"Všechno se dramaticky změnilo. Udržitelnost, kromě zelené a čisté, znamená, že to, co dnes stavíme, musí být snadné a rychle změnit 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.