Extrémní programování (XP) je agilní metodologie vývoje softwaru. Stejně jako jiné agilní metodologie má XP své unikátní nástroje, procesy a role. Tvořitel XP, americký vývojář Kent Beck, nevynalezl nic zcela nového, ale vzal nejlepší postupy agilního vývoje a umocnil je do extrému, a proto se to jmenuje Extrémní programování.
Autor metodologie, Kent Beck, vedl projekt Chrysler Comprehensive Compensation System na konci 90. let, kde poprvé aplikoval postupy XP. Své zkušenosti a vytvořený koncept zdokumentoval v knize “Extrémní programování vysvětleno,” publikované v roce 1999. Tato kniha byla následována dalšími, které podrobně popisují praktiky XP. Mezi přispěvateli k vývoji metodologie jsou Ward Cunningham, Martin Fowler a další.
Na rozdíl od jiných agilních metodologií se XP exkluzivně používá ve vývoji softwaru. Nelze ji aplikovat na jiné podnikání nebo každodenní život jako Scrum, Kanban nebo Lean.
Cílem XP je vyrovnat se s neustále se měnícími požadavky na softwarový produkt a zlepšit kvalitu vývoje. Proto je XP vhodný pro složité a nejisté projekty.
XP se točí kolem čtyř základních aktivit: programování, testování, navrhování a naslouchání. Navíc má Extrémní programování základní hodnoty: jednoduchost, komunikaci, zpětnou vazbu, odvahu a respekt.
13 praktik extrémního programování
1. Celý tým
Všichni účastníci projektu používající XP pracují jako jeden tým. Tento tým musí zahrnovat zástupce zákazníka, nejlépe skutečného koncového uživatele znalého o oboru. Zákazník stanoví požadavky na produkt a prioritizuje funkčnost. Obchodní analytici mohou zákazníkovi pomoci. Z pohledu vykonavatelů tým zahrnuje vývojáře, testery, občas trenéra, který tým vede, a manažera poskytujícího zdroje.
2. Plánovací hra
Plánování v XP probíhá ve dvou fázích: plánování vydání a plánování iterace.
- Plánování vydání: Programátorský tým se setká se zákazníkem, aby určil požadovanou funkčnost pro další vydání, obvykle za 2 – 6 měsíců. Vzhledem k tomu, že požadavky zákazníka jsou často nejasné, vývojáři je objasňují a dělí na úkoly, které lze dokončit během jednoho dne nebo méně. Zákazník musí rozumět provoznímu prostředí, kde bude produkt fungovat.
Úkoly jsou zaznamenávány na kartičkách a zákazník je prioritizuje. Vývojáři pak odhadují čas potřebný pro každý úkol. Jakmile jsou úkoly popsány a odhadnuty, zákazník přezkoumá dokumentaci a schválí zahájení práce. Pro úspěch projektu je rozhodující, aby zákazník a programátorský tým hráli na stejném hřišti: zákazník volí skutečně potřebnou funkčnost v rámci rozpočtu a programátoři přiměřeně přizpůsobují požadavky zákazníka svým schopnostem. - Plánování iterace: Probíhá každé dva týdny, někdy častěji nebo méně často. Zákazník je přítomen, aby definoval funkčnost pro další iteraci a provedl změny v požadavcích na produkt.
3. Malá vydání
Vydání XP jsou častá, ale s omezenou funkčností. Tento přístup usnadňuje testování a údržbu operability systému a poskytuje zákazníkovi funkčnost s obchodní hodnotou při každé iteraci.
4. Zákaznické testy
Zákazník specifikuje automatizované akceptační testy k ověření funkčnosti produktu. Tým tyto testy píše a používá je k testování kódu.
5. Kolektivní vlastnictví kódu
V XP může jakýkoli vývojář upravit jakoukoli část kódu, neboť kód nepatří jeho autorovi, ale celému týmu.
6. Kontinuální integrace
Nové části kódu jsou okamžitě integrovány do systému – týmy XP vydávají novou verzi každých pár hodin nebo častěji. Tato praxe zajišťuje, že vliv nedávných změn na systém je okamžitě viditelný. Pokud nový kousek kódu něco rozbije, identifikace a oprava chyby je mnohem snazší.
7. Standardy kódování
Se společným vlastnictvím kódu je zásadní přijetí běžných standardů kódování, aby kód vypadal, jako by byl napsán jedním profesionálem. Týmy mohou vyvinout své standardy nebo přijmout existující.
8. Metafora systému
Metafora systému je srovnání s něčím známým, aby se vytvořila společná vize v týmu. Typicky ji vytváří osoba vyvíjející architekturu a vidící systém jako celek.
9. Udržitelný rytmus
Týmy XP pracují při maximální produktivitě, zatímco udržují udržitelný rytmus. Extrémní programování odrazuje od přesčasů a podporuje 40hodinový pracovní týden.
10. Vývoj řízený testy (TDD)
Jedna z nejnáročnějších praktik v XP. Programátoři píší testy před tím, než napíší kód, který bude testován. Tento přístup zajišťuje, že každý kus funkčnosti je plně pokryt testy. Když vývojáři commitují kód, jednotkové testy se okamžitě spouštějí a všechny testy musí projít, což zajišťuje, že tým se ubírá správným směrem.
11. Párové programování
Představte si dva vývojáře pracující na jednom počítači na jednom kusu funkčnosti. Tato praxe se nazývá párové programování, což je nejkontroverznější praxe v XP. Přísloví “dvě hlavy jsou lepší než jedna” dobře ilustruje její podstatu. Z dvou řešení problému je vybráno to nejlepší, kód je okamžitě optimalizován a chyby jsou zachyceny dříve, než k nim dojde, což vede k čistému kódu, kterému oba vývojáři rozumí.
12. Jednoduchý design
Jednoduchý design v XP znamená dělat jen to, co je nyní potřeba, aniž by se snažil předpovědět budoucí funkčnost. Jednoduchý design a neustálé refaktoring vytvářejí synergický efekt – když je kód jednoduchý, je snazší ho optimalizovat.
13. Refaktoring
Refaktoring je kontinuální proces zlepšování designu systému, aby splnil nové požadavky. To zahrnuje odstranění duplicit kódu, zvýšení soudržnosti a snížení spojení. XP vyžaduje neustálý refaktoring, takže design kódu zůstává vždy jednoduchý.
Výhody a nevýhody XP
XP je kontroverzní a často kritizován těmi, kteří se jej nepodařilo implementovat. Nicméně jeho přínosy jsou zřejmé, když tým plně využije alespoň jednu praktiku XP.
Výhody úsilí o XP zahrnují:
- Spokojenost zákazníka: Zákazníci dostávají produkt, který potřebují, i když nemají původně jasnou vizi.
- Flexibilita: Tým rychle provádí změny kódu a přidává nové funkčnosti díky jednoduchému designu kódu, častému plánování a publikování.
- Spolehlivost: Kód vždy funguje díky neustálému testování a kontinuální integraci.
- Udržovatelnost: Tým může snadno udržovat kód, protože je napsán podle jednoho standardu a neustále refaktorován.
- Produktivita: Rychlé tempo vývoje díky párovému programování, žádným přesčasům a zapojení zákazníka.
- Vysoce kvalitní kód
- Omezení rizik: Rizika vývoje jsou snížena, protože odpovědnost je rovnoměrně rozložena, a projekt není ohrožen odchodem nebo příjezdem členů týmu.
- Nákladová efektivita: Náklady na vývoj jsou nižší, protože se tým soustředí na kód místo dokumentace a setkání.
Navzdory svým výhodám XP né vždy funguje a má několik slabin:
- Zapojení zákazníka: Úspěch závisí na zapojení zákazníka, což může být obtížné dosáhnout.
- Neprůhledné časové osy: Je obtížné předpovědět časové náklady na projekt, protože úplný seznam požadavků není znám na začátku.
- Závislost na úrovni dovedností: XP silně závisí na úrovni dovedností programátorů a nejlépe funguje se seniorskými profesionály.
- Odpor managementu: Management často odporuje párovému programování, zpochybňuje potřebu platit dva programátory místo jednoho.
- Náklady: Častá setkání s programátory mohou být pro zákazníky nákladná.
- Kulturní změny: Implementace XP vyžaduje významné kulturní změny.
- Nedostatek struktury: Absence struktury a dokumentace v XP činí metodologii nevhodnou pro velké projekty.
- Nefunkční požadavky: Funkční požadavky je obtížné popsat jako uživatelské příběhy v agilních metodologiích.
Principy XP
Ve své první knize Kent Beck načrtl následující principy XP: jednoduchost, komunikace, zpětná vazba a odvaha. V následné edici přidal pátý princip — respekt.1. Jednoduchost
Vývoj XP začíná s nejjednodušším řešením, které splňuje aktuální funkční potřebu. Členové týmu zvažují pouze to, co je nyní potřeba, a nezahrnují funkčnost, která by mohla být potřebná v budoucnu.
2. Komunikace
Komunikace v XP probíhá živě, nikoli prostřednictvím dokumentace. Tým aktivně komunikuje mezi sebou i se zákazníkem.
3. Zpětná vazba
Zpětná vazba v XP je realizována třemi způsoby:
- Další zpětná vazba: Prostřednictvím neustálého testování modulů.
- Zákaznická zpětná vazba: Zákazník je součástí týmu a podílí se na psaní akceptačních testů.
- Týmová zpětná vazba: Během plánování týká se odhadů času vývoje.
4. Odvaha
Některé praktiky XP jsou tak nekonvenční, že vyžadují odvahu a neustálé sebekontrolu.5. Respekt
Respekt v XP znamená respektování týmu a sebeúctu. Členové týmu by neměli provádět změny, které by přerušily kompilaci, modulové testy nebo zpomalily práci kolegů. Každý člen usiluje o nejvyšší kvalitu kódu a designu.
Implementace XP a pracovní postup
Kent Beck doporučuje implementaci XP k řešení problémů projektu. Tým vybere nejurgentnější problém a vyřeší ho pomocí jedné z praktik XP. Poté přejdou k dalšímu problému, použijí jinou praktiku. Tento přístup zajišťuje, že problémy motivují adopci XP a tým postupně zvládne všechny nástroje metodologie.
Aby bylo možné implementovat XP v existujícím projektu, postupně jej přizpůsobte v následujících oblastech:
- Testování: Tým vytváří testy před tím, než napíše nový kód, a postupně refaktoruje starý kód.
- Design: Tým nepřetržitě refaktoruje starý kód, obvykle před přidáním nové funkčnosti.
- Plánování: Tým musí úzce spolupracovat se zákazníkem.
- Management: Manažeři zajišťují, že všichni členové týmu dodržují nová pravidla.
- Vývoj: Začněte organizací pracovních stanic pro párové programování a podporujte páry, aby programovaly většinu času.
Příklad pracovní postupu pomocí XP
Kdo používá XP
Podle průzkumu VersionOne z roku 2016 používá pouze 1% agilních společností XP v jeho čisté formě. Dalších 10% používá hybrid Scrum a XP.I když XP není nejběžnější metodologie, její praktiky jsou používány většinou společností, které používají agilní metodologie. Například Pivotal Software, Inc. přisuzuje svůj úspěch XP.
Pivotal Software, Inc.
Pivotal Software, Inc. vyvíjí obchodní analýzy na základě velkých dat a poskytuje konzultační služby. Jejich produkty používají korporace jako Ford, Mercedes, BMW, GAP, Humana, hlavní banky, vládní agentury a pojišťovny.
Pivotal prosazuje agilní metodologie jako nezbytné pro moderní vývoj. Mezi agilními varianty si zvolili XP, což je win-win přístup pro zákazníky a programovací týmy. Jejich pracovní den začíná stand-up schůzkami a končí v 18:00 – bez přesčasů. Pivotal používá plánovací hry, párové programování, neustálé testování, kontinuální integraci a další praktiky XP.
Co číst, abyste pochopili XP
- “Extrémní programování vysvětleno,” “Plánování extrémního programování,” “Vývoj řízený testy” od Kenta Becka: Tyto knihy od tvůrce XP poskytují hluboké porozumění metodologii a jejím výhodám.
- “Refaktoring: Zlepšení designu existujícího kódu” od Martina Fowlera: Kniha spoluautora XP vysvětlující principy a techniky refaktoringu.
- “Extrémní programování v praxi: Jak vyhrát” od Kena Auera a Roye Millera: Praktický průvodce praktikami XP s příklady.
Nástroje pro implementaci XP v týmech
Redmine
Bezplatný, open-source správce úloh s funkcemi jako podpora více projektů, flexibilní správa úkolů, Ganttovy diagramy, sledování času, řízení dokumentace a vytváření úkolů prostřednictvím e‑mailu.
Basecamp
Jednoduchá, uživatelsky přívětivá služba pro spolupráci na projektech, včetně správce úkolů, nástěnek, vestavěného chatu, úložiště souborů a kalendáře.
Jira
Robustní služba navržená pro agilní vývojáře projektů, kombinující sledovač chyb a nástroj pro řízení projektů s mnoha funkcemi a možnostmi synchronizace.
Worksection
Bezpečná služba pro práci na projektech, která umožňuje nastavování úkolů a kontrolu procesů, sledování korespondence, přizpůsobení filtrů, sledování času a financí a správu souborů.
Závěr
Extrémní programování je agilní metodologie zaměřená na výrobu vysoce kvalitního, funkčního kódu s jednoduchou architekturou. Jejím cílem je snížit nejistotu v projektech a flexibilně reagovat na měnící se požadavky produktů.
XP je výhradně pro vývoj softwaru a nelze ji přizpůsobit jinému podnikání.
Je to jedna z nejnáročnějších metodologií k implementaci kvůli svým třinácti praktikám. Jejich praktiky jsou však široce využívány v agilních projektech, což dokazuje jejich efektivitu.
Autoři radí postupně si osvojovat praktiky XP při řešení problémů projektu. Pokud vidíte výhody, pokračujte ve stejném duchu. Neexistuje žádná povinnost implementovat XP na základě all-or-nothing. Koneckonců, agilní metodologie by měly být flexibilní v aplikaci – přizpůsobovat se potřebám konkrétního projektového týmu.