Kadlec, Václav: Agilní programování

Softwarové inženýrství

• Metodiky coby jedny z nejdůležitějších produktů softwarového inženýrství. Metodiky vzniklé po tzv. softwarové krizi (koncem 60. let minulého století) kladly důraz na rozfázování (analýza – specifikace – testy atd.), protože absence těchto činností vedla právě k softwarové krizi. Naopak dnešní (agilní) metodiky se snaží vést vývoj tak, aby výsledný produkt byl dodán co nejdříve (rychlost v současnosti jako jeden ze základních požadavků na vývoj).
• Současné trendy softwarového inženýrství: 1) architektury, 2) metodiky, 3) předvídání změn.

Vyvíjíme tradičně

• Tradičním vývojem SW se míní klasické, léty (pr)ověřené metodiky a modely životního cyklu, dnes už ceněné zpravidla jen jako referenční elementy. Základním problémem tradičního sekvenčního přístupu je totiž ten, že před sebou tlačí (často netušená) rizika, jejichž odstranění se pak prodražuje. Naproti tomu iterativní a inkrementální přístup detekuje rizika průběžně a díky lepší správě změn a znovupoužitelnosti je i blíž zákazníkovi.
• Vodopádový model. Jedná se patrně o nejtradičnější model životního cyklu vývoje SW (není metodikou!), který ve své době znamenal převrat. Člení vývoj na jednotlivé sekvenční fáze – definice problému, specifikace požadavků, návrh, implementace, integrace a testování, údržba – a zavádí jejich logickou posloupnost, odstupňovanou do schématu vodopádu. Dnes už je sice překonán, neboť je nepružný a nedokáže pojmout rozsáhlejší projekty, přesto je však ještě běžnou praxí a na jednodušší projekty může být za určitých okolností i vyhovující. Je totiž nejen jednoduchý a systematický, ale i dobře manažersky kontrolovatelný.
• Spirálový model. Jedná se o tzv. riziky řízený přístup (risk-driven approach), oproti vodopádu sofistikovanější a komplikovanější model životního cyklu softwarového produktu, charakteristický cyklickým, iterativním vývojem. Pokouší se odstranit některé zjevné nedostatky vodopádu – do vývoje integruje některé další fáze, především analýzu rizik, a hlavně přichází s koncepcí iterativního vývoje, bez níž se neobejde vývoj jakéhokoliv rozsáhlejšího projektu. Jde tedy o sekvenci cyklů, která má radiální rozměr (spirála) reprezentující časové i finanční nároky vývoje.
• Metodika Rational Unified Process (RUP). Jedná se o do šířky i hloubky propracovanou a komplexní komerční metodiku vývoje SW, založenou na objektově orientované iterativní koncepci (use-case-driven approach). Společnost Rational vnímá svůj produkt jako jakéhosi online instruktora, který poskytuje metodické pokyny, instrukce, šablony a příklady pro všechny aspekty a fáze vývoje. Podrobně zodpovídá všechny otázky související s procesem tvorby SW: kdo (pracovníci – workers), co (meziprodukty – artifacts), kdy (pracovní procesy – workflows) a jak (činnosti – activities). RUP se hodí spíše pro rozsáhlé projekty a větší vývojové týmy, které potřebují precizně stanovený a důsledně zdokumentovaný vývojový proces. RUP však lze také přizpůsobit konkrétním potřebám konkrétního projektu i konkrétnímu týmu vývojářů, a to v jednotném rámci, který zajišťuje konzistenci celého procesu. Je tedy použitelný i pro menší týmy nebo internetové projekty, u nichž se předpokládá další společná činnost.
• Metodika Unified Software Development Process (USDP), zkráceně Unified Process (UP). Jedná se o méně robustní, bezplatnou verzi metodiky RUP.

Vyvíjíme agilně

• Tzv. agilní metodiky vývoje SW jsou nové inovativní přístupy, které na jednu stranu sice vychází z ortodoxního softwarového inženýrství, ale na stranu druhou boří mnohá dogmata a zažité postupy. Jejich cílem je vytvářet SW svižněji, pružněji a efektivněji, nezakopávat se v dílčích vývojových fázích, ale co nejrychleji postupovat k cíli – tj. k dodání fungující aplikace – a lépe tak vyhovět požadavkům dnešní dynamické doby. Agilní metody na rozdíl od těch tradičních, kde se množina požadavků považuje za neměnnou, předpokládají měnící se požadavky na funkcionalitu. Základní principy agilních metodik: inkrementální vývoj s krátkými iteracemi, přímá (osobní) komunikace, nepřetržitý kontakt se zadavatelem/uživatelem, opakované automatizované testování, zdrojový kód coby nejspolehlivější nositel informace a známý princip Occamovy břitvy (Occam‘s razor), čili dělat jen to, co je nezbytně nutné k dosažení cíle. Cenou za tyto výhody je však obvykle menší rozsah projektu (v menším vývojovém týmu).
• Metodika Extrémní programování (Extreme Programming, XP). Tato nejznámější agilní metodika je určená pro menší týmy – svou progresivitou a odlehčeným přístupem (cesta „zdravého rozumu“) boří konzervativní představy o týmové spolupráci při vývoji, jelikož přímo počítá se změnami požadavků a nehledí zbytečně moc dopředu. Po prozkoumání problému a hrubém náčrtu plánu projektu se ihned zahajuje implementace (návrh probíhá současně s programováním a testováním), což se neobejde bez odvahy refaktorizovat, komplet přepracovat nebo i zahodit již hotové zdrojové kódy, ukáže-li se navržená architektura jako nevhodná. XP je jednoduché v detailech, ale obtížné při vykonávání, protože jak se ukazuje, pro mnohé je tím nejobtížnějším právě to dělat věci jednoduše.
• Metodika Scrum. Název z ragbyové terminologie (z angl. srum = skrumáž, kumulace, hromada hráčů na jednom místě, kdy se snaží dostat míč na požadovanou pozici) je paralelou pro vývoj SW. Ten probíhá ve zhruba měsíčních iteracích, tzv. sprintech (Sprints), dopředu se však neví, kudy přesně se vývoj bude ubírat. Průběžná koordinace/reakce/rekapitulace se zajišťuje na každodenních cca 15-30minutových schůzkách, tzv. Scrum Meetings. Scrum vychází z objektově orientovaného přístupu – každý vývojář odpovídá za určitou množinu objektů. Scrum týmy bývají tří- až šestičlenné, vzájemně kooperující a otevřeně komunikující. Pružná reakce na změny a jejich každodenní reflexe, to jsou hlavní přednosti Scrumu. Na druhou stranu je možná lepší, když organizace již pracuje podle nějaké jiné metodiky (nebo má vlastní fungující systém) a z metodiky Scrum si přebírá „jen“ způsob řízení projektu, protože Scrum představuje spíš souhrn vzorů nežli celistvou metodiku.
• Metodika Lean Development. Nejedná se o tak komplexní metodiku, jakou je kupř. RUP, ale spíš o soubor doporučení, jak by měl vývoj probíhat, a upozornění na častá plýtvání, kterým je naopak třeba se vyhnout. Rovněž doporučuje iterativní vývoj (vývoj tažený poptávkou) a předkládá deset jednoduchých pravidel + sedm principů. Prvním a zároveň nosným pravidlem je zbavení se všeho nadbytečného, co v průběhu vývoje vzniká, snižuje efektivitu a zvyšuje náklady.
• Vlastnostmi řízený vývoj SW (Feature-Driven Development, FDD). Jedná se o přístup k vývoji, v němž se postupuje „po jednotlivých vlastnostech“ (vlastnosti systému jako hnací motor vývoje). Na základě rozhovorů se zadavatelem (doménovým expertem) se tvoří kategorizovaný seznam vlastností, nad nímž pak probíhá celý vývoj. Metodika je vhodná spíše pro menší projekty (ale klidně větší, než zvládne např. XP), které lze specifikovat souhrnem vlastností.
• Testy řízený vývoj SW (Test-Driven Development, TDD). Metodika klade důraz především na testování vyvíjeného SW a odhalování chyb, dokud jsou „čerstvé“. Odpadá tak nepříjemná fáze debuggingu. TDD razí netradičním postup: nikoliv od implementace k testům, ale právě naopak. Výsledkem by měl být vysoce kvalitní SW s předvídatelným a dobře prozkoumaným chováním.
• Metodiky Crystal. Nejedná se o striktně definovanou metodiku, ale spíše o rodinu adaptabilních metodik, resp. sadu doporučení, jak si vytvořit metodiku vlastní. Vychází se z myšlenky, že každý SW je jiný, tedy si žádá také odlišný proces výroby (kroky, které jednou fungovaly, nemusí fungovat i podruhé). Opět se staví na otevřené komunikaci a kvalitě lidských zdrojů.
• Adaptivní vývoj SW (Adaptive Software Development, ASD). Základní myšlenka: vývoj SW není neměnným a stabilním procesem, který lze snadno popsat od první do poslední fáze, ale je nutno počítat s řadou dynamických akcí, a teprve dohromady to může vytvořit fungující agregát. ASD chápe změnu vyloženě jako příležitost, nikoliv jako komplikaci či dokonce problém.
• Metoda dynamického vývoje SW (Dynamic Software Development Method, DSDM). Jedná se o komerční produkt – metodiku dodávanou spolu s frameworkem, který práci s DSDM podporuje. Metodika je zajímavá hlavně zaváděním kategorizace požadavků podle priorit.