Agilní metodiky
Agilní metodiky jsou skupiny metod původně určených pro vyvíjení softwaru založené na iterativním a inkrementálním vývoji. Umožňují rychlý vývoj softwaru a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu. Podle těchto metodik se správnost systému ověří jedině pomocí rychlého vývoje, předložení zákazníkovi a následných úprav dle zpětné vazby.[1][2] Agilní přístup není omezen pouze na programování, ale našel své uplatnění také ve finančnictví, telekomunikacích, marketingu i v oblasti řízení lidských zdrojů. Protikladem agilního přístupu je vodopádový model.[3]
Historie
Až do nástupu odlehčených metodik se používaly těžké, rigorózní metodiky. Ty jsou někdy kritizovány pro svůj vodopádový model vývoje, který není schopný reagovat na změny, omezuje ho fixně nadefinovaná spolupráce a potřeba mít již na začátku projektu detailní návrh.[2] Z těchto důvodů navíc statisticky dosáhne smluveného cíle za smluvených podmínek (cena, čas apod.) jen cca 13 % ze všech projektů.[1]
V polovině devadesátých let se proto začaly objevovat odlehčené metodiky. Ty se podle jejich tvůrců navrací k vývojovým praktikám ze samotných počátků softwarového vývoje. Mezi tyto odlehčené metodiky patřil Scrum, Crystal Clear, Extrémní programování či Vývoj řízený vlastnostmi.
Pojem agilní metodiky se pro ně však začal používat až od února roku 2001, kdy se v Utahu sešli odborníci z oblasti softwarového inženýrství a vývoje softwaru, aby diskutovali o odlehčených metodách vývoje. Tehdy sepsali Manifest agilního programování, kde definují přístup k vývoji nyní známý jako agilní programování. Autory tohoto manifestu jsou Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland a Dave Thomas.[4][5]
Priority agilního programování
- Lidé a jejich spolupráce před procesy a nástroji
- Fungující software před obsáhlou dokumentací
- Spolupráce se zákazníkem před sjednáváním smluv
- Reakce na změnu před dodržováním plánu
V manifestu je také definováno 12 principů agilního programování.
Principy agilního programování
- Nejvyšší prioritou je uspokojit zákazníka průběžnými a rychlými dodávkami kvalitního software.
- Změnové požadavky jsou vítány, dokonce i v průběhu vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely konkurenční výhody.
- Dodávejte fungující software často, v intervalech týdnů až měsíců. Upřednostňujte kratší intervaly dodání.
- Lidé z businessu a vývojáři musí spolupracovat každý den během celého projektu.
- Pro práci na projektu vybírejte motivované jedince. Dejte jim prostředí a podporu, kterou potřebují, a důvěřujte jim, že práci dokončí.
- Nejúčinnější metoda sdílení informací vývojářskému týmu (i uvnitř tohoto týmu) je osobní setkání.
- Fungující software je hlavním měřítkem postupu vývoje.
- Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopní dodržovat stálý výkon dokud je třeba.
- Průběžná pozornost věnovaná technické dokonalosti a dobrému návrhu posiluje agilní přístup.
- Základem je jednoduchost – umění co nejvíce práce vůbec nedělat.
- Nejlepší architektury, požadavky a návrhy vznikají v týmech, které se samy organizují.
- Tým v pravidelných intervalech vyhodnocuje svou práci a upravuje své postupy tak, aby byl co nejefektivnější.[5]
Agilní metodika
V Americe probíhá již většina vývoje právě agilní metodou. Přináší to hned několik výhod. Agilní přístup je bezpečnější pro dodavatele i odběratele. Odběratel již od počátku nemusí mít zcela jasno v tom, jak bude výsledný produkt vypadat a může dělat v jeho průběhu změny, a dodavatel produktu nemusí být již od počátku schopen odhadnout cenu celé zakázky. Je to proto, že agilní řízení probíhá v iteracích, tj. 14denních sprintech, na jejichž konci se vždy výsledek vyhodnocuje odběratelem a zpravidla po vytvoření minimum viable productu i jeho zákazníky. Nehrozí proto tolik dohady nad podobou finálního produktu, který by jinak nemusel odpovídat představám klienta či by mu mohlo něco chybět nebo přebývat, popř. nad cenou za práci, pokud to vše netrvalo přesně tak dlouho, jak mělo. Všichni v každém momentě vývoje jednoduše ví, na čem asi jsou.[1]
Dále není problém díky rozdělení vývoje na sprinty průběžně nějaké funkce upravit, vynechat nebo přidat a jednoduše se na to v dalším sprintu soustředit. U vodopádového modelu vývoje to ale problém je. Klient totiž obvykle spatří až výsledný produkt, kde poté i jakákoliv drobná změna vyjde na obří sumy.[1]
Nevýhoda agilního vývoje je zásadní nutnost zapojit klienta do procesu vývoje.[1] Vyžaduje to od něj alespoň základní technické a metodické znalosti, vysokou míru součinnosti i schopnosti přebrat zodpovědnost za vyvíjený software. Navíc je těžší odhadnout, kdy bude software opravdu vyvinutý a za kolik.[2] Agilní vývoj je proto dobré nasadit zejména tehdy, když jsou obě strany zkušené a důvěřují si.[1]
Příklady agilních metodik
Extrémní programování (XP)
XP je pravděpodobně nejznámější agilní metodikou. Propaguje časté dodávky software v krátkých vývojových cyklech. Kromě toho navrhuje párové programování, jednotkové testování celého kódu (nejdříve se vytvoří test, až pak samotný kód), programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód. Mezi další praktiky patří společné vlastnictví kódu a neustálý refaktoring. Vývojáři by měli počítat se změnami požadavků v průběhu času. Důležitá je častá komunikace se zákazníkem i mezi programátory.
Scrum
Klíčovou částí metodiky jsou každodenní krátká setkání týmu, nazývaná daily standups. Každý člen zde referuje o své činnosti z minulého dne, o tom, co bude dělat dnes, a na jaké problémy narazil. Metodika prosazuje iterativní vývoj. Období iterace se nazývá Sprint a trvá 1-4 týdny. Výsledkem Sprintu je demo vzniklých úprav, které je předvedeno stakeholderům (zákazníkovi, sponzorovi, management boardu, investorům). Ti poskytují zpětnou vazbu, což umožňuje rychle reagovat na změny v požadavcích. Jsou zde rozeznávány tři role – Product Owner má za úkol komunikovat se zákazníkem a definici co nejlepšího produktu, bývá nazýván hlasem zákazníka. Správné fungování vývojového týmu zajišťuje Scrum Master. Člen vývojového týmu se nazývá Scrum Team Member. Vývoj a školení metodiky má na starost Scrum Alliance.
Vývoj řízený vlastnostmi (FDD – Feature Driven Development)
FDD začíná vytvořením doménového modelu popisujícího celý systém. Ten se převede do seznamu vlastností (elementární funkcionality, které přináší hodnotu uživateli). Vývoj má celkem pět fází (první tři sekvenční, další dvě iterativní). Iterace trvá většinou dva týdny. Během každé iterace se implementují konkrétní užitné vlastnosti systému. Zákazník průběžně dostává mezivýsledky a nové verze produktu. Na rozdíl od XP nebo SCRUM je jednotlivým programátorům práce přidělena – nevybírají si ji sami.
Lean development
Lean development je spíš než metodikou souhrnem pravidel, jejichž používání by mělo zefektivnit a zrychlit vývojový proces. Tato pravidla zní: eliminovat zbytečné (to, co nepřináší zákazníkovi žádnou hodnotu), zdůraznit proces učení, rozhodovat se tak rychle a pozdě, jak je možné, posílit odpovědnost týmu, zabudovat integritu a vidět systém jako celek.
Součástí štíhlé výroby mohou být metody (např. Kanban) a nástroje, které metodická pravidla umožní realizovat.
Vývoj řízený testy (TDD – Test Driven Development)
TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód. Implementuje se přesně takové množství kódu, jaké dokáže projít testem.
Crystal metodiky
Nejde jen o jednu metodiku. Hlavní myšlenkou je to, že je lepší metodiku přizpůsobit danému projektu, žádná metodika nebude vyhovovat každému projektu. Vytvoření individuální a účelové metodiky pro konkrétní projekt je první fází vývoje. Pro vytvořenou metodiku je rozhodující například velikost projektu a vývojového týmu.
Agilní metodiky v právním rámci
Při vývoji software za použití agilních metodik se zpravidla využívají následující dva typy smluv.
Fixed-Time Fixed-Price
V případě Fixed Time Fixed Price (FTFP) smlouva definuje dílo, které má vzniknout a být dodáno za pevně stanovenou částku a v pevně stanoveném čase. Z právního hlediska se jedná o Smlouvu o dílo, kterou se “zhotovitel zavazuje na svůj náklad a nebezpečí provést pro objednatele dílo a objednatel se zavazuje dílo převzít a zaplatit cenu” (§ 2586 odst. 1 NOZ).
Time and Material
Time and Material (T&M) vyžaduje Rámcovou smlouvu o poskytování služeb. Tato smlouva nedefinuje dílo, ale pouze služby, které bude dodavatel zákazníkovi poskytovat (například design, programování, testování a podobně). Jednotlivé služby jsou poskytovány na základě dílčích objednávek, které typicky následují například po sprint planningu. Time & Material a agilní metodiky si tedy z principu konvenují.
Odkazy
Reference
V tomto článku byl použit překlad textu z článku Agile software development na anglické Wikipedii.
- Agilní vývoj – splněný sen dodavatele i klienta?. synetech.cz [online]. [cit. 2021-08-16]. Dostupné online. (česky)
- Tvorba zadávací dokumentace | ASWA. aswa.cz [online]. [cit. 2021-08-16]. Dostupné online. (česky)
- Poradna: Co je to agilní metoda řízení? [online]. [cit. 2021-08-16]. Dostupné online. (česky)
- http://agilemanifesto.org
- Principy stojící za Agilním Manifestem. agilemanifesto.org [online]. [cit. 2021-08-16]. Dostupné online.
Související články
Externí odkazy
Obrázky, zvuky či videa k tématu agilní metodiky na Wikimedia Commons - Rozdíl mezi agilním a vodopádovým modelem
- SCRUM alliance - scrumalliance.org
- Agilní asociace - agilniasociace.cz
- Agilia - agilia.cz
- Asociace softwarových agentur - aswa.cz
