Historie Agile sahá až k publikaci „Manifestu pro Agile software development“, který se skládá z 12 základních principů z roku 2001. Nejsporněji se určité nastavení Agile přístupu objevily již dříve, ale pouze tento dokument je systematizoval a podal je v takovém rozsahu, který byl dostatečný pro použití. Rok co rok se k Manifestu hlásí nové firmy, IT specialisté a projektoví manažeři. Objevují se nové metody a verze systému agilního vývoje.
Co je metodologie Agile (flexibilní)?
Agile je interaktivní model vývoje, ve kterém je software vytvářen postupně od začátku projektu, na rozdíl od kaskádových modelů, kde je kód dodán na konci pracovního cyklu.
Flexibilní metodologie se zakládá na rozdělení projektů na malé provozní části nazývané uživatelské příběhy. Podle priorit jsou úkoly řešeny v krátkých dvoutýdenních cyklech (iteracích).
12 principů, které utvářejí Agile metodologii, lze zjednodušit na 4 hlavní myšlenky:
- Priorita lidí a komunikace před nástroji a procesy;
- Priorita funkčního produktu před bohatou dokumentací;
- Priorita spolupráce se zákazníky před potvrzením smlouvy;
- Priorita připravenosti na změny před dodržováním původního plánu.
Metody, které jsou součástí Agile:
Scrum
Termín Scrum byl převzat z ragby, kde toto slovo znamená metodu týmové hry ve formě tří řad postavených každým soupeřem snažícím se uchopit míč. Pro úspěšné uchopení je nezbytná nejen dobrá fyzická kondice – každý hrající hráč by měl jednat koordinovaně s ostatními, s jasným porozuměním cíle.
Tato metoda je úspěšně využívána takovými společnostmi jako Microsoft, Yahoo, Siemens Healthcare. Projektový manažer z Amazonu dokonce popsal případ zavedení Scrum na základě získaných zkušeností.
Protože Scrum je rámec pro vývoj, každý příklad, který následuje, se může lišit od předchozího.
Jeff Sutherland, autor knihy „Scrum. Umění dělat dvakrát tolik práce za polovinu času“, vymezil 8 kroků pro využití metodologie:
- Vyberte vlastníka produktu, který si je vědom cíle projektu a očekávaného výsledku.
- Organizujte tým — až 10 osob s dovednostmi potřebnými k vytvoření provozního produktu.
- Jmenujte Scrum mistra, který bude dohlížet na pracovní tok projektu a pomůže projektovému týmu při řešení výzev.
- Vytvořte produktový backlog — pro každou požadavek produktu nastavte priority na Agile tabuli. V tomto procesu je role vlastníka produktu zásadní, protože shromažďuje žádosti o produkt pro tým backlogu, aby je posoudil.
- sprinty (iterace) — časové úseky na dokončení konkrétních řetězců úkolů.
- Uspořádejte každodenní patnáctiminutová setkání — ptejte se každého člena týmu na 3 otázky: co udělal včera, co udělá dnes, co brání splnění úkolu.
- Udělejte hodnocení provozních částí produktu — zapojením zainteresovaných stran do takových hodnocení.
- Pořádejte retrospektivy — diskuse o problémech s hledáním řešení po každém sprintu. Implementujte výsledný plán úprav v následujícím sprintu.
Retrospektiva v Agile
Scrum má 4 klíčové prvky:
- Produktový backlog — seznam požadavků pro projekt
- Sprint backlog — seznam požadavků, které mají být splněny v nadcházejícím sprintu
- Sprint cíl — účel sprintu
- Sprint Burn Down Chart — diagram, který se aktualizuje, jakmile se úkoly splní. Umožňuje porozumět dynamice a pokroku týmu v projektu.
eXtreme Programming (XP)
Kent Beck, tvůrce této metodologie, vytvořil metodu extrémního programování zaměřenou na řešení nestabilních požadavků na software a zlepšení kvality vývoje.
Je použitelná pouze v oblasti vývoje softwaru a zakládá se na 4 procesech:
- kódování — podle společných standardů týmu;
- testování — testy jsou v zásadě vytvářeny programátory ještě před napsáním kódu, který bude testován;
- plánování — jak pro konečnou sestavu, tak pro jednotlivé iterace. Ty probíhají v průměru každé dva týdny.
- audice — jak vývojářů, tak zákazníka, za účelem odstranění nejasností a definování požadavků a hodnot.
Crystal Metodologie
Tato rodina metodologií vyvinutá Alistairem Cockburnem, jedním z autorů „Manifestu pro Agile Software Development“, je v některých místních oblastech projektového managementu málo známá. Cockburn navrhuje klasifikaci podle barev, založenou na kritériu, jako je počet osob v týmu: 2 (Crystal Clear) až 100 (Crystal Red). Barvy Maroon, Blue a Violet jsou přiděleny větším projektům.
Crystal projekty by měly splňovat 3 základní charakteristiky:
- rychlé dodání provozního kódu — vyvíjející myšlenka pro iterativní model v agile vývoji.
- zlepšení prostřednictvím reflexe — nová verze softwaru je vylepšena na základě informací o předchozí verzi.
- „osmotická“ interakce — Alistairova inovace, metafora pro komunikaci a výměnu informací mezi vývojáři softwaru v jedné místnosti.
Tato rodina metodologií je podrobně popsána v knize „Crystal Clear: A Human-Powered Methodology for Small Teams“ od Alistaira.
Metoda dynamického vývoje softwaru (DSDM)
Na vývoji DSDM nepracoval jen jeden člověk, ani tým, ale konsorcium 17 britských společností. Stejně jako extrémní programování, DSDM se převážně používá k vytváření softwaru.
Konečný uživatel (uživatel) hraje zvláštní roli v procesu vývoje. Tento základní princip je doplněn o následující základní:
- časté vydávání provozních verzí produktu
- autonomie vývojářů při rozhodování
- testování během celého pracovního cyklu.
DSDM je rozděleno na verze, které jsou aktualizovány, jakmile se technologie vyvíjejí a jakmile se objevují nové požadavky na vývoj softwaru. V současnosti je poslední verzí DSDM Atern, vydaná v roce 2007, i když předchozí verze (z roku 2003) je stále v provozu.
Na začátku tým zvažuje proveditelnost vývoje aplikace a jejího rozsahu použití. Poté je práce rozdělena do tří vzájemně propojených cyklů:
- cyklus funkčního modelu — vytváření analytických dokumentů a prototypů.
- cyklus designu a inženýrství — uvedení systému do provozu.
- implementační cyklus — nasazení systému.
Vývoj řízený funkcemi (FDD)
Tato metodologie vznikla ještě dříve než „Manifest pro Agile Software Development”.
Ačkoli FDD také využívá iterativní model vývoje, liší se od Agile v následujících rysech:
- větší pozornost věnovaná počátečnímu modelování
- zvýšený (ve srovnání s Agile) význam vytváření zpráv a diagramů
- metodologie je určena pro korporátní vývoj.
Vývoj řízený funkcemi se skládá z následujících cyklických fází:
- Vytvoření obecného modelu — vize projektu nabízená na základě předběžných dat.
- Vytvoření seznamu vlastností — podobně jako produktový backlog ve Scrum metodologii.
- Plánování podle vlastností — složitost vlastností je hodnocena každým členem týmu.
- Pro každou vlastnost — technický design a implementace – závěrečná fáze, po jejímž dokončení se vlastnost spojí s produktem a cyklus se opakuje.
Lean Software Development
Lean Software Development je soubor principů štíhlého řízení (nikoli metodologie), které směřují ke zvyšování efektivity vývojového procesu a minimalizaci nákladů.
Tento soubor zahrnuje následujících 7 základních principů:
- eliminace ztrát — všechno, co nepřidává hodnotu produktu pro koncového spotřebitele.
- průběžné školení — pokračující rozvoj týmu zvyšuje možnosti efektivního plnění úkolů.
- rozhodování co nejpozději — priorita je udělena promyšleným řešením, která jsou dobře vyvinutá a založená na získaných znalostech, spíše než za spontánní.
- rychlé dodávání — základní princip iterativního modelu.
- posílení týmu — jeden ze základních principů „Manifestu…“ tvrdí, že lidé a jejich interakce jsou důležitější než procesy a nástroje. Projektový tým je nejlepší zárukou úspěšného dokončení úkolů.
- integrita a kvalita — je nezbytné vytvořit původně kvalitní produkt, aby se zamezilo plýtvání časem a zdroji na další testování a odstranění chyb.
- pohled na celkový obraz — projekt nelze rozdělit na jednotlivé části, aniž by se pochopil současný stav vývoje, jakož i cíle, koncepce a strategie vyvíjeného softwaru.
Verze agilních metodologií vývoje
Agilní modelování (AM)
Agilní modelování je soubor hodnot, základů a praktik pro modelování softwaru.
AM se používá jako prvek v plnohodnotných metodologiích vývoje softwaru — například v extrémním programování nebo rychlém vývoji aplikací.
Agilní modelování má následující základní rysy:
- efektivní interakce mezi zainteresovanými stranami projektu;
- úsilí o vyvinutí konečného jednoduchého řešení ze všech možných, které splní všechny požadavky;
- průběžné získávání zpětné vazby;
- odvaha činit rozhodnutí a nést za ně odpovědnost;
- uvědomování si, že víte naprosto vše.
Agilní sjednocený proces (AUP)
AUP je zjednodušená verze jiné metodologie vývoje softwaru — racionální sjednocený proces (RUP). Od roku 2012 byla nahrazena disciplinovaným agilním dodáním (DAD), ale AUP je stále zde a tam.
Scott Ambler, autor metodologie, zdůraznil následující klíčové body v agilním sjednoceném procesu:
- Váš tým ví, co dělá;
- Jednoduchost je na prvním místě.
- Shoda se základy metodologie flexibilního vývoje.
- Zaměření na aktivity cenné pro projekt.
- Nezávislost na výběru nástrojů.
- Možnost přizpůsobení konfigurace AUP požadavkům konkrétního projektu.
Agilní datová metoda (ADM)
ADM je soubor iterativních metod vývoje softwaru, které zdůrazňují formování požadavků a řešení v projektu prostřednictvím spolupráce různých týmů. Stejně jako AUP, tato metodologie není ani samostatná.
Princip Agilní datové metody je definován šesti základními principy:
- Data — základ pro vytvoření jakékoli aplikace.
- Problémy v projektu — mohou být odhaleny pouze pokud je cíl a koncepce projektu jasně pochopena.
- Pracovní skupiny — kromě základního týmu vývojářů existují podnikové skupiny, které podporují ostatní pracovní skupiny.
- Jedinečnost — neexistuje dokonalá metodologie, takže každý projekt vyžaduje kombinaci nástrojů z různých metodologií.
- Týmová práce — společná práce je mnohem efektivnější než individuální aktivita.
- „Sladké místo” — hledání optimálního řešení problému („sladkého místa”) vyhýbáním se extrémům.
Esenciální sjednocený proces (EssUP)
Byl vyvinut Ivar Jacobsonem, švédským vědcem, za účelem zlepšení racionálního sjednoceného procesu.
EssUP používá koncept praxe, který zahrnuje:
- scénář použití — popis chování systému.
- iterativní vývoj — vytváření provozních částí kódu v krátkých cyklech během několika týdnů.
- týmové praktiky — zaměřené na posílení týmu a zvýšení jeho efektivity.
- procedurální praktiky — například „Myslete globálně, začněte malými kroky“ nebo „Zapojte zainteresované strany do obchodních procesů“.
Ve formě či jiné jsou všechny praktiky přítomny ve metodologiích RUP a CMMI, stejně jako ve flexibilní metodologii vývoje.
Realita (GR)
Toto je metodologie efektivní pro startupy a začínající týmy, která navrhuje maximální využití specifických rysů inherentních malým projektům a společnostem, jako jsou mobilita, flexibilita, hledání nových řešení, absence přísné a zmatené hierarchie atd.
Jason Fried a David Hansson, zakladatelé společnosti 37signals (nyní Basecamp), definovali Getting Real jako systém pro řešení realizovatelných úkolů, který je nakonec jednoduchý, komplexní a funkční.
GR je mix deseti agilních vývojových nástrojů, které se používají k minimalizaci následujícího:
- alternativy
- možnosti a nastavení
- organizace
- setkání
- sliby.
Taková mimořádná koncepce se nestala mainstreamovou, přestože se některé její prvky spojily s jinými metodologiemi.
OpenUP (OUP)
Toto je metodologie vývoje softwaru nezávislá na nástrojích a zbavená přísné struktury, která poskytuje následující praktiky:
- měření rychlosti operace týmu;
- denní schůzky a retrospektivy po dokončení iterací;
- koncept mikro kroků a rané testování pomocí kontrolních seznamů;
- metodologie Agile Model Driven Development (AMDD).
Těmito praktikami se realizují na základě čtyř principů:
- usmíření zájmů a dosažení společné vize při společné práci;
- průběžné zlepšování prostřednictvím průběžné zpětné vazby;
- zaměření na architekturu aplikace v raných fázích k minimalizaci rizik;
- maximalizace hodnoty pro konečného spotřebitele.
Agilní ukazatele
Vzhledem k rozmanitosti agilních nástrojů, praktik, metod a metodologií je nutné vybrat nástroj, který nám pomůže určit, jak efektivní každý z nich je.
Metriky jsou používány jako takový nástroj.
Pro většinu projektů budou tyto 4 kategorie metrik dostatečné:
- Produktivita — sousedí s metrikami průtoku a rozpracovanosti. První metrika se nehodí pro všechny projekty, protože se měří počet úkolů vykonaných za iteraci, ale iterace nejsou rovny. Metrika Work-in-Progress určuje limit úkolů v různých fázích: čím vyšší je, tím hůře to jde;
- Forecasting — kapacity metrika, která spočívá v určení počtu ideálních hodin, které jsou k dispozici v nadcházejícím sprintu. Odpovídajícím způsobem je možné pochopit, kolik času je k dispozici pro práci, míru efektivity plnění úkolů, stejně jako naplánovat počet úkolů pro sprint;
- Kvalita — například index stability požadavků, který se vypočítává podle vzorce = (Celkový počet původních obchodních požadavků + Počet požadavků, které byly změněny do daného okamžiku + Počet přidaných požadavků + Počet odebraných požadavků) / (celkový počet původních požadavků). Tato metrika se používá k určení času stráveného přepracováním úkolů;
- Hodnoty — tato metrika se počítá individuálně v každém případě, v závislosti na formátu projektu. Například ve startupu AirBnb byl jako metrika určující konečnou hodnotu produktu pro uživatele vybrán počet stažených kvalitních fotografií. Jak se toto číslo zvyšovalo, počet uživatelů rostl úměrně.
Pravidla platná pro metriky jsou stejná jako ty pro ostatní agilní nástroje.
Neexistuje jediná metrika, která by byla jednoznačně správná a relevantní pro váš projekt.
Metriky by měly být průběžně revidovány, zastaralé je třeba odebrat a nové přidat podle potřeby. Měly by být komplexní a přístupné pro celý tým, aniž by se proměnily v cíl samy o sobě. Metriky pro samotné metriky jsou špatným řešením.
Mýty o Agile
Popularita flexibilní metodologie vývoje si s ní pohrávala a mýty o určitých aspektech Agile lze vidět i na specializovaných portálech. Pojďme si je vyjasnit!
Mýtus č. 1: Agile vyhovuje všem projektům.
Toto je nejvýraznější omyl. Jen jedna Agile metoda sama o sobě nepřidá žádnou hodnotu produktu, ani nebude motivovat tým.
Mýtus č. 2: Agile nepřeje dokumentaci.
Agilní metodologie vývoje nezakazuje dokumentaci, popírá dokumentaci jako cíl sama o sobě. Pokud jde o výběr dokumentace jako prostředku komunikace, Agile skutečně upřednostňuje osobní komunikaci.
Mýtus č. 3: Agile a plánování jsou neslučitelné.
Tento mýtus vyvrací každodenní plánovací akce s 10minutovými stály, stejně jako plánování iterací, které probíhá každé dva týdny, sprinty atd.
Mýtus č. 4: Agile vyžaduje mnoho přepracování.
Agilní metodologie vývoje softwaru zahrnuje přepracování ve dvou formách: přepracování požadavků (uživatelé zjistí, co opravdu potřebují) a přepracování softwaru (týmy vývojářů hledají zlepšení způsobů, jak psát a navrhovat aplikace). Ale to se dá zažít také v jiných metodologiích! Navíc, taková novinka Agile jako model iterace slouží k minimalizaci negativního dopadu přepracování.
Výhody a nevýhody Agile v praxi
Výhody:
- zapojení zainteresovaných stran — tým se stává schopnějším pochopit požadavky zákazníků. Co víc, rané a časté dodání softwaru zvyšuje důvěru zainteresovaných stran v projektový tým a prohlubuje zapojení do projektu.
- rané a předvídatelné dodání — model založený na iteracích (v krátkých obdobích trvajících od 1 do 6 týdnů) poskytuje flexibilitu a podněcuje uvolnění produktu.
- zaměření na obchodní hodnotu — spolupráce se zákazníkem zajišťuje, že tým chápe, jak učinit produkt pro spotřebitele nakonec hodnotným.
- průběžné zlepšování kvality — testování během každé iterace s rozdělením konečné sestavy na jednotlivé části provozního kódu usnadňuje zlepšení a odstranění chyb softwaru před uvolněním konečného produktu.
Nevýhody:
- přísné požadavky na tým a zákazníky — bez úzké interakce mezi projektovým týmem a uživateli není možné zajistit vydání kvalitního produktu s vysokou hodnotou. Co víc, bohaté agilní nástroje a metody předpokládají, že tým by měl být zkušený pro jejich řádné zavedení.
- nejsou vhodné pro outsourcing a pro projekty, kde se účastníci navzájem setkávají pouze online.
- riziko, že konečná verze softwaru nebude nikdy uvolněna — překvapivě, tato nevýhoda vzniká z takových výhod Agile, jako jsou iterativní vývoj a průběžné zlepšování produktu.
- selhává bez jasné vize obchodních účelů projektu — protože se tým Agile řídí zainteresovanými stranami, není možné vyvinout produkt bez cíle a koncepce, které jsou jasně definované.
Aplikace
Ne všechny služby nebo programy pro řízení projektů budou vhodné pro řízení projektů založených na Agile, protože každý z nich má své specifické rysy.
Pokud je vaše podnikání marketingové & reklamní, designové, SEO nebo digitální agenturou, můžete využít SaaS službu Worksection, na které bude pracovat celý tým. Zatím jsme doporučováni COXO Digital, Royal ® Advertising a Prozorro.
Zde je několik tipů pro konfiguraci Agile v Worksection:
- konfigurujte značky a statusy, které jsou nezbytné pro práci ve vaší společnosti. Statusy mohou být: v procesu, kontrola, hotovo, nutné přepracování, kritické, funkce, splatnost. Značky často čtou jako: rozvržení, testování, výroba, koncept, kód.
- vytvořte projektový backlog a projektový sprint.
- vytvořte úkoly a předběžné kontrolní seznamy, skici atd. v backlogu.
- během setkání určte úkoly sprintu a přesuňte je z backlogu do sprintu.
- využijte přístup hosta zákazníků k úkolům, abyste měli vždy konzistentní a relevantní zpětnou vazbu na projekt.
- označte odpovědné osoby v úkolech, aby každý kolega věděl svoji oblast odpovědnosti a cítil se zapojený do výsledku sprintu.
Verdikt
Díky agilní metodologii vývoje softwaru dosahují malé projektové týmy maximální efektivity. Agile se realizuje prostřednictvím takových jiných flexibilních metod jako Scrum, XP, Lean atd.
Nemůže být nasazen uspěchaně, nezkušeným týmem, během krátkého časového období,
ale když je zaveden, Agile zlepší interakci mezi IT a podniky, podpoří uvedení produktu na trh a přidá hodnotu produktu pro koncového spotřebitele.