Agilní metodiky
From Wikipedia, the free encyclopedia
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] 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.[2]
Až do nástupu odlehčených metodik se používaly rigorózní metodiky. Ty jsou někdy kritizovány pro svůj vodopádový model vývoje, který údajně 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.[1] 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ů.[zdroj?!]
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.[3] V manifestu je mimo jiné definováno 12 principů agilního propracování.[4]
V Americe probíhá již většina vývoje právě agilní metodou.[zdroj?!] Agilní přístup je bezpečnější pro dodavatele i odběratele. 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.
Dále není problém kvůli rozdělení vývoje na sprinty průběžně nějaké funkce upravit, na rozdíl od vodopádového modelu vývoje, kde klient obvykle spatří až výsledný produkt. Nevýhoda agilního vývoje je zásadní nutnost zapojit klienta do procesu vývoje.[1]
Extrémní programování (XP)
Podrobnější informace naleznete v článku Extrémní programování.
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
Podrobnější informace naleznete v článku 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)
Podrobnější informace naleznete v článku 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.
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í.
