[Díl 2.] Extrémní programování

Extrémní programování (XP) je jedním z mnoha procesů uplatňujících agilní přístup. Další agilní procesy jsou například Scrum, Crystal, Feature-driven development nebo adaptive software development.

Praktiky extrémního programování:

  • Tým pohromadě - celý tým zahrnující vývojáře, managery, zákazníka by měl být pohromadě. Navzájem vědět o problémech a spolupracovat na jejich řešení.
  • User stories - pro potřeby plánování potřebujeme vědět nějaké požadavky na systém. Nespecifikujeme požadavky detailně, potřebujeme znát jen tolik, abychom mohli udělat odhad náročnosti. Detaily specifikujeme až ve fázi implementace konktétních user stories. Zákazník vybere implementaci jednotlivých user stories na základě jejich priority a náročnosti.
  • Krátké cykly - XP vydává obvykle novou verzi každé dva týdny. Jeden takový cyklus se nazývá iterace. Na konci každé iterace je provedena ukázka zákazníkovi a ten na její základě předá týmu zpětnou vazbu.
  • Iterační plán - iterační plán je seznam user stories vybraných zákazníkem na základě „budgetu“ určeného vývojáři. Budget/rozpočet určí vývojáři na základě tempa v předešlých iteracích. Zákazník určí libovolnou kombinaci user stories, ale dohromady jejich odhady pracnosti nesmí překročit budget. Jakmile je iterace započata, tak se nemění user stories v ní obsazené. Verze vydávané na konci každé iterace se značí jako minor release.
  • Plán vydávání - Obvykle se jedná o tříměsíční plán, vydávané verze mohou často sloužit jako produkční. Jinak funguje podobně jako iterační plán, zákazník vybírá user stories, tým určí budget na základě předešlého cyklu. Na rozdíl od iteračního plánu se ovšem může měnit.
  • Acceptance tests – Detaily o user stories jsou zachyceny ve formě acceptance testů, které mají za úkol zajistit, že se systém chová dle požadavků. K jejich psaní se používají skriptovací jazyky, které umožňují jejich automatické spouštění a opakování.
  • Programování ve dvojicích - kód je psán dvojicí programátorů, kteří sdílejí jeden počítač. Jeden píše kód a druhý ho sleduje, hledá chyby a vylepšení. Pravidelně si střídají pozice. Zároveň se často mění jednotlivé dvojice, během jedné iterace by měl každý člen týmu pracovat alespoň jednou se všemi ostatními členy a zároveň téměř na všem, co je v dané iteraci. Díky tomu má celý tým povědomí o celém systému a jeho designu, zároveň se jednotliví členové rychle učí. Pokud je na nějaký úkol potřeba specialista, tak na něm může pracovat s kýmkoliv dalším. Tím se šíří speciální odbornost mezi tým.
  • Test-driven development - první píšeme test, který selže, protože neexistuje kód, který by zajišťoval funkcionalitu. Testy zajišťují požadované chování. Až poté píšeme kód, který zajistí splnění testu. Unit testy nám zajistí, že v případě úpravy nějakého modulu zůstane jeho chování v pořádku. Samozřejmě pokud se změní požadavky, je potřeba nejdříve přizpůsobit unit testy a poté kód.
  • Kolektivní vlastnictví - dvojice má právo vylepšit jakýkoliv modul. Nikdo není zodpovědný za jednotlivý modul, ale naopak všichni zodpovídají za všechno.
  • Stálá integrace - programátoři integrují kód do systému několikrát denně. Platí jednoduché pravidlo, kdo dřív přijde. Ostatní musí kusy kódu sloučit a integrovat. XP používá source control systémy, které neblokují přístup. To znamená, že na stejném kódu může pracovat i více párů zároveň, ale musí být připraveny, že budou muset sloučit kód. Z tohoto důvodu se integrace provádí velice často, aby se předešlo dlouhým „merging sessions“. Při každé integraci jsou spuštěny všechny testy, včetně acceptance testů, které kontrolují, že je vše v pořádku.
  • Stálé tempo - vývoj softwaru mnohdy trvá i více než rok, proto je potřeba si držet tempo a neunavovat se. XP nedovoluje přesčasy, s jedinou výjimkou – poslední týden „release“ cyklu.
  • Otevřené pracoviště - celý tým sdílí jednu místnost. Díky tomu mohou ostatní poradit, pokud má nějaký pár problém, komunikace s ostatními je velmi jednoduchá. U každého počítače jsou dvě židle, na zdech jsou nástěnky, tabule, flip charty, diagramy a podobně.
  • Planning game - zákazník určí, jak důležité jsou jednotlivé funkce/user stories a tým určí jejich „cenu“ (náročnost na implementaci). Na základě toho se plánuje další iterace. Každý člen týmu se poté hlásí k jednotlivým úkolům.
  • Jednoduchý design - XP tým udržuje co nejjednodušší design. Soustředí se pouze na funkcionalitu pro současnou iteraci, nezabývají se tím, co by mohlo přijít v další a nepřipravují si pro to infrastrukturu. Snaží se o co nejlepší design pro současnou funkcionalitu.
  • Refactoring - jedná se o drobné úpravy pro zlepšení a zpřehlednění kódu. Například dlouhé metody jsou rozděleny do více menších, jsou upraveny názvy, aby měly větší vypovídající hodnotu a podobně. Refactoring je prováděn pravidelně, vždy když je napsán nový kus kódu. Po refactoringu jsou spuštěny všechny unit testy pro ověření, že vše funguje tak jak má.
  • Metafory - jedná se o metafory pro vyvíjený systém, pro lepší chápání souvislostí.

Shrnutí

XP je sada jednoduchých a konkrétních praktik, které dohromady tvoří agilní proces. Není to ovšem nic, čeho bychom se museli přesně držet. Můžeme si tyto praktiky přizpůsobit, pokud zjistíme, že nám to vyhovuje více.

[Díl 1.] Agilní praktiky

Agilní praktiky vznikly z důvodu efektivního řízení softwarových projektů. Bez jakýchkoliv praktik se projekt může změnit v nekontrolovatelnou noční můru. Na druhou stranu se objevily praktiky, které zaváděly až neúnosně mnoho pravidel a procesů, které měly za následek zpomalení projektů. V roce 2001 se sešla skupina expertů a zkušených profesionálů, zvaných „Agile alliance“, a nastínili praktiky, které by pomohly skupinám vývojářů vyvíjet rychle, efektivně a reagovat na změny. Výsledkem několika měsíců práce je „Manifesto for Agile Software Development“ – manifest pro agilní softwarový vývoj:

  • Jednotlivci a interakce před procesy a nástroji – členové týmu a jejich spolupráce jsou nejdůležitější složkou úspěchu. Když není dobrý tým, nezachrání to ani špičkové procesy a nástroje a naopak špatné procesy mohou udělat dobré týmy neefektivními.
  • Funkční software před detailní dokumentací – funkční software je nejdůležitější. Příliš dlouhá dokumentace je stejně špatná jako žádná dokumentace. Dokument popisující systém by měl být stručný a krátký, pokrývající nejdůležitější aspekty návrhu systému. Dokument by měl být neustále aktuální. Zároveň by zdrojový kód měl být co nejjednodušší a čitelný, sloužící jako nejlepší a aktuální dokument.
  • Spolupráce zákazníka před vyjednáváním zakázky - software nelze objednat tak, že vypíšeme požadované funkce, za určitý čas a určitou cenu. Zákazník by se měl pravidelně účastnit tvorby softwaru a pravidelně předávat zpětnou vazbu. Nejlepší kvality se dosáhne, když zástupce zadavatele pracuje přímo s týmem.
  • Reagovat na změnu před dodržováním plánu – požadavky na funkcionalitu se velmi často mění v průběhu vývoje softwaru, dost často si zákazník uvědomí, že některé funkce nepotřebuje a jiné naopak potřebuje přidat. Pokud tvoříme plány, měly by být flexibilní a pokud možno co nejkratší. Krátkodobé plány mohou být detailní, ale střednědobé a dlouhodobé by měly být více obecné.

Agilní principy:

  1. Nejvyšší prioritou je uspokojení zákazníka skrze brzkou a pravidelně pokračující dodávku hodnotného softwaru. V agilním vývoji se první verze dodá co nejdříve a poté co nejčastěji v pravidelném intervalu. Díky tomu si zákazník může kontrolovat požadovanou funkcionalitu a schválit ji nebo vybrat změny, které jsou potřeba.
  2. Vítat měnící se požadavky, dokonce i v pozdním stádiu vývoje. Změny znamenají vyšší hodnotu systému pro zákazníka a zároveň pomáhají porozumět jeho businessu. Díky tomu je zákazník spokojenější s dodaným softwarem. Agilní tým udržuje strukturu softwaru velmi flexibilní díky návrhovým vzorům a dalším praktikám a může reagovat na změny požadavků s minimálním vlivem na celý systém.
  3. Pravidelná dodávka softwaru, od pár týdnů po pár měsíců, s preferencí kratších intervalů. Dodáváme funkční software, dodáváme ho brzo a často. Našim cílem je funkční software uspokojující zákazníka.
  4. Zákazník a vývojáři musejí spolupracovat na projektu denně. Musejí diskutovat o funkcích a nejasnostech. Jen tak se dosáhne nejvyšší kvality.
  5. Tvořit projekt kolem motivovaných lidí, dopřát jim prostředí a motivaci k práci a věřit, že svoji práci splní. Lidé jsou nejdůležitější složkou úspěchu. Ostatní faktory jako například prostředí, proces a podobně se dají jednoduše změnit.
  6. Nejefektivnější způsob přenosu informací do nebo z vývojářského týmu je skrze osobní konverzaci. Psané dokumenty jsou psané pouze podle potřeby.
  7. Fungující software je hlavní měřítko postupu. Agilní projekty měří postup skrze množství softwaru vyhovující potřebám zákazníka. Pokud je hotovo 50% požadovaných funkcí, pak je hotovo 50% projektu. Množství potřebné infrastruktury nebo dokumentace je irelevantní.
  8. Agilní procesy se vyznačují stabilním tempem vývoje. Vývoj softwaru je jako běh na dlouhou trať, je potřeba udržovat svižné stabilní tempo a neunavit se.
  9. Neustálý důraz na dobrý design a technickou kvalitu. Agilní týmy udržují kód co nejčistší a nejjednodušší jak jen to jde a jsou zavázáni nejvyšší kvalitě. Nenechávají za sebou nepořádek v kódu, jakmile vznikne, tak ho hned „uklidí“.
  10. Jednoduchost – volba jednoduchých přímých řešení. Nezabývají se problémy, které mohou nastat zítra a nepřipravují se na ně. Udržují co nejjednodušší kód pro dnešní funkcionalitu, který je velice flexibilní a jednoduchý změnit.
  11. Nejlepší architektura, požadavky, návrhy pocházejí od týmu. Tým se podílí na celém projektu, nikdo nerozhoduje za tým. Veškerý kód je všech a každý člen týmu může provést kdekoliv úpravu.
  12. V pravidelných intervalech tým provádí sebereflexi a upravuje svoje chování a práci.

Shrnutí

Cílem každého vývojáře a týmu je poskytnutí co nejvyšší hodnoty pro zákazníka. Principy agilního vývoje byly zformovány k tomu, aby týmům usnadnily dosáhnutí těchto cílů.

V příštím díle se podíváme na extrémní programování.

Seriál o agilním vývoji a návrhových vzorech

Rozhodl jsem se, že napíši seriálu o agilním vývoji, jeho principech a praktikách a o návrhových vzorech. A to z důvodů, že kdykoliv jsem hledal, tak jsem nenašel žádný komplexní materiál v češtině o zmíněné tématice a přesto, že se jedná o důležité aspekty programování, tak na školách jsou poměrně dost přehlíženy.

Poměrně hodně budu vycházet z knihy Agile Principles, Patterns, and Practices in C# od Roberta C. Martina. Jedná se o kvalitní knihu v angličtině a všem, kteří to myslí s vývojem softwaru a zároveň nechtějí čekat na můj seriál, bych ji doporučil. Jako nevýhodu bych uvedl, že jde pouze o přepracovanou edici pro jazyk C#, který je použit ve starých verzích a autor nepoužívá například ani genericitu, který tu s námi je od verze .Net frameworku 2.0. Naštěstí to u knihy o návrhových vzorech a agilních praktikách není zase až takový problém. Zároveň rád uvítám jakékoliv tipy na další povedené knihy k tématu.