Blog | Co je agile?

Co je agile?

Agile je způsob vývoje. Obvykle se používá k vývoji software, občas i k vývoji hardware a dalším vývojovým činnostem. Nejvíce spojované slovo s agile je flexibilita. Obsah toho slova je ale hlubší.

Agile je složeno ze tří částí:

agilní kultura – způsob, jak je vnímán vývoj, produkt, zákazník, tým, základní hodnoty, které jsou vyznávány; tyto hodnoty najdete v Agilním manifestu
- agilní metodika – manažerská metodika, která určuje role, pravidla, procesy, schůzky, formát zadání, vždy respektuje hodnoty agilního manifestu, mezi známé agilní metodiky patří Scrum a eXtreme Programming
- agilní techniky – konkrétní obvykle vývojářské postupy a techniky, které mají kořeny v agilních týmech, byť dnes už jsou rozšířenější

Agilní kultura

Agilní kultura vychází z agilního manifestu.

Překlad najdete zde:

Odkrýváme lepší cesty, jak vyvíjet software tím, že software vyvíjíme a pomáháme druhým ho vyvíjet. Prostřednictvím práce jsme došli k hodnotám:

Jednotlivci a interakce nad procesy a nástroji,
Fungující software nad úplnou dokumentací,
Spolupráce se zákazníkem nad trváním na smlouvě,
Reakce na změnu nad následováním plánu.

Přestože je hodnota i ve věcech napravo, my uznáváme víc hodnoty vlevo

Dál pak agilní manifest obsahuje 12 principů agilního vývoje.

Tyto principy jsou:

Nejvyšší prioritou je uspokojení zákazníka prostřednictvím kontinuálního doručování hodnotného software.

Vítat změny požadavků i v pozdní fázi vývoje, použít pro získání konkurenční výhody pro zákazníka.

Doručovat fungující software často.

Business lidé a lidé z vývoje pracují společně.

Vybudujte prostředí kolem motivovaných lidí, dejte jim prostředí, podporu a důvěru, že věc zvládnou.

Nejlepší forma komunikace je přímá řeč.

Pracující software je primární měřítko postupu.

Agilní týmy věří v trvalou udržitelnost vývoje. Všechny role by měly být schopny napořád udržet stejné tempo.

Neustálé zlepšování designu a posouvání technické excelence zlepšuje agilitu.

Jednoduchost, umění maximalizovat věci, které nejsou udělány, je esenciální.

Nejlepší architektura, požadavky a designy vznikají v sebeorganizu­jících týmech.

V pravidelných intervalech se týmy sejdou a hledají cesty, jak se stát efektivnějšími a pak navržené změny promítnou do svých procesů.
(Zdroj: agilemanifesto.org)

V praxi se pak tyto body projevují mimo jiné tak, že týmy jsou autonomnější, mizí micromanagement, lidé spolu více mluví, organizace se průběžně zlepšuje, lidé lépe poznávají potřeby zákazníků. Je běžné, že se průběžně refaktoruje, testuje.

Naprosto zásadní je přístup: Nemusíme to vymyslet dokonale napoprvé, pojďme ale udělat něco dobrého, co by mohlo být správné a připravme se na to se rychle přizpůsobit.

Takový přístup šetří peníze, vede k tomu, že dřív je produkt opravdu užitečný pro své uživatele a dřív začne vydělávat peníze.

Agilní kultura je nejdůležitější složkou a bez ní nelze mluvit o agilním týmu. Samotné zavedení metodiky bez kultury je automaticky odsouzeno k neúspěchu.

Agilní metodiky

Agilní metodiky zohledňují hodnoty agilního manifestu a kladou obvykle důraz na změny směru a priorit, plochou až žádnou hierarchii, získávání informací od zákazníka, neustálé učení se. Níže si rozebeme všechny tyto věci podrobněji.

Nejdřív si ale vypišme některé známé agilní metodiky. Jsou to Scrum, eXtreme Programming (velké X je záměrné, metodika se zkracuje jako XP), dále pak známé, ale v praxi skoro nepoužívané Crystal Clear, Feature Driven Development. Další metodiky, které existují, téměř nenajdete.

Tyto metodiky ale nepokrývají všechny agilní firmy a týmy. Desítky procent firem má metodiku vlastní odvozenou od potřeb, lidí ve firmě, zákazníků, historie firmy, strategie firmy.

Důležité části agilních metodik obvykle jsou:

Získávání informací od zákazníka

Agilní metodiky obvykle zapojují do procesu zákazníka. Tak, že pro něj vytváří konkrétní roli, která má vymezené povinnosti a práva. Ve Scrumu se této roli říká Product Owner, v eXtreme Programmingu je přímo Customer.

Se zákazníkem se ve vodopádovém modelu intenzivné komunikuje zpočátku vývoje a ke konci. V agilním vývoji je interakce intenzivní v celém průběhu vývoje. Práce je se zákazníkem průběžně vyjasňována, jsou předváděny výsledky, ty jsou průběžně schvalovány.

Změna směru a priorit

Tým přijímá změny jako přirozenou součást vývoje software. Chápe, že mnoho věcí nejde a ani není vhodné navrhovat dlouho dopředu. Že se mění legislativa, potřeby zákazníka, realita, ve které se software pohybuje, vychází nové platformy, aktualizují se operační systémy.

Tak se metodiky přizpůsobují potřebě změn. Počítá se s tím, že se bude více refaktorovat. Počítá se s tím, že software musí být flexibilní. S tím se pojí i to, že jsou často vydávány interní releasy, při kterých je software stabilizován. Díky tomu není otevřená žádná práce (tzv. Work in progress) a díky tomu lze v tuto chvíli jít jakýmkoliv směrem bez toho, aby byl zahozen rozdělaný vývoj.

Plochá až nulová hierarchie

Agilní týmy bývají velmi autonomní. Místo toho, aby byly úkoly konkrétně přidělovány, lidé si sami rozebírají práci. Místo toho, aby zadání bylo extrémně detailní, se spíš řeší, jaký význam má v businessu zákazníka, jak se to bude dobře používat a řadu věcí často domýšlí týmy samotné.

To je možné díky tomu, že agilní týmy jsou organizované podle produktů, ne podle odborností. Místo toho, aby byl vývojový tým, marketingový tým apod. máme tým pro daný produkt nebo zákazníka a ten tým dovede mnohem autonomněji doručovat to, co se od něj čeká.

Neustálé učení se

S tím, jak se mění směr, komunikuje se se zákazníkem, vydávají se často nové verze, získává vývoj zpětnou vazbu a informace. Učí se lépe vyvíjet a být užitečný zákazníkům. Obecně platí, že úspěšnou agilní implementaci poznáte podle toho, že se tým neustále zlepšuje na základě toho, že ze všech stran sbírá zpětnou vazbu a tu vyhodnocuje co nejvíc racionálně.

Zpětná vazba jak do businessu, tak i do vývoje

Multidisciplinární týmy jsou v agilním vývoji běžnou realitou (leč ne pravidlem). Je normální, že v jedné místnosti sedí vývojáři, grafici, produkťáci, lidé z marketingu, customer care. Je běžné, že lidé diskutují problémy a řešení jen tím, že zavolají od stolu na kolegu o pár metrů dál. Diskuzí je v agile více, než v běžném modelu, jsou ale kratší a efektivnější.

Agilní techniky

Agilní techniky byly vynalezeny agilními týmy nebo byly adoptovány do vývoje software z jiných oblastí. Dnes už ale zdomácněly i mimo toto prostředí. Agilních technik není extrémně mnoho a všechny jsou spojeny s rychlou zpětnou vazbou.

Prototypování

Nemyslí se jen wireframy (zjednodušené návrhy webu, průchodů, stránek), ale i funkční prototypy. Pomocí prototypů se zjišťuje, zda bylo správně pochopeno zadání, testují se průchody webu, použitelnost i uživatelská práva. Prototypy zásadním způsobem snižují náklady na vývoj u aplikací, kde právě není jasné UI.

Test Driven Development

Automatizované testování a Test Driven Development především patří k technikám, které pomáhají vývojářům v tom, aby si rychle ověřili, že v nasimulovaných podmínkách kód funguje tak, jak bylo zadáno. TDD je model vývoje, ve kterém vývojář rychle iteruje a testy pouští co pár minut. Zároveň ověřuje, že píše efektivní testy tak, že dřív než kód napíše test a nechá ho selhat. V TDD dostává vývojář zpětnou vazbu extrémně často.

Pair Programming

Párové programování je uspořádání vývoje, při kterém dva vývojáři sedí u jednoho stroje a spolu pracují na řešení problému. Jeden se obvykle více zaměřuje na konkrétní kód, druhý na architekturu, ale sleduje i překlepy, čistotu, špatně pojmenované proměnné, funkce apod. Párové programování je dnes používáno mnohem méně, než by si zasloužilo.

Continuous Integration

Continuous Integration je systém, při kterém je práce lidí průběžně slučována. Lidé nepracují ve svých větvích celé měsíce, ale naopak každý den spojí to, na čem pracují a vyzkoušejí, jestli jejich práce funguje dobře pohromadě.

V okamžiku, kdy se spojí kultura, metodika a techniky, můžeme mluvit o agilním týmu nebo firmě. Jen samotná metodika nestačí. Nasazení Scrumu není automaticky nasazení agile. Stojí za tím změna přemýšlení a to trvá. Ale stojí to za to.

Agile

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích