Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Metoda : Extrémní programování (XP)
Extrémní programování (XP)
Kód metody

Standarní kód metody v MBI

:
M527
Popis, obsahové vymezení

Obsahové vymezení metody - rekapitulace základních principů ve vztahu k řízení informatiky

1. Extrémní programování (XP) - celková charakteristika

1.1. Koncepce XP

Extrémní programování je velmi „lehká“, ale disciplinovaná metodika, která zavádí specifické praktiky jako párové programování, refaktorizace, testy před kódováním a další. Patří mezi nejpopulárnější a nejpoužívanější agilní metodiky. Extrémní programování vychází z principů a postupů běžných při vývoji softwaru, které však dovádí do extrémů [BECK, 2002] – neustálé revize zdrojového kódu (párové programování), neustálé testování vývojáři (testování jednotek) i zákazníky (testování funkcionality), každodenní návrh (refaktorizace), to nejjednodušší, co ještě může fungovat, integrace a testování několikrát denně (nepřetržitá integrace), opravdu krátké iterace.

1.2. Praktiky XP

1.3. Tým jako celek (Whole Team)

Základem týmu je zákazník, který s týmem denně pracuje na projektu. Tým dále zahrnuje programátory, může zahrnovat i testery, kteří pomáhají zákazníkovi definovat akceptační testy. Analytici mohou pomáhat zákazníkovi definovat požadavky. Obvykle je v týmu kouč, který vede projekt. Tým, pokud je to možné, nemá specialisty, ale generalisty, kteří přispívají společnému cíli.

1.4. Plánovací hra (Planning Game)

Plánování v XP řeší dvě klíčové otázky: předpovídá, co bude součástí dodávky a určuje, co dělat dále. Tyto otázky adresují dvě plánovací činnosti – plánování dodávky (Release Planning) a plánování iterace (Iteration Planning). Plánování dodávky je praktika, při které zákazník prezentuje požadované vlastnosti programátorům, kteří odhadují jejich náročnost. Na základě odhadu a priorit vlastností zákazník určí hrubý plán projektu, který se zpřesňuje po každé iteraci. Plánování iterace je praktika, při které si tým určuje, co bude vyvíjet v rámci dvoutýdenní iterace. Zákazník prezentuje vlastnosti, které by měly být realizovány během dvou týdnů, programátoři je rozdělí na úkoly a odhadují jejich náročnost. Na základě množství práce, která byla udělána v předchozí iteraci (project velocity), se tým rozhodne, co zařadí do plánované iterace.

1.5. Požadavky v XP

Požadavky se v XP definují ve formě uživatelských příběhů (user story). Uživatelské příběhy píší zákazníci a vyjadřují v nich své potřeby, které má systém podpořit. Popis požadavku je stručný (3 věty až odstavec) a používá terminologii zákazníka. Požadavky zákazníci kategorizují podle toho, jak jsou pro ně významné (nutné, důležité, „bylo by dobré“). Programátoři pak pro každý požadavek odhadují čas potřebný pro implementaci. Požadavky ve formě uživatelských příběhů mají 3 důležité aspekty, které XP vyjadřuje jako CCC (Card, Conversation, Confirmation) – karta, konverzace, potvrzení. Karta slouží k zaznamenání požadavku. Neobsahuje všechny informace, ale je symbolem požadavku – obsahuje právě tolik textu, aby byl požadavek identifikován. Karta se používá pro plánování, zapisují se na ni odhady nákladů a priority. Karty jsou velmi flexibilní, dají se libovolně uspořádat a snadno předávat. Když je požadavek vybrán pro implementaci, předává se karta programátorům a po dokončení implementace se vrací zpět k zákazníkovi. Požadavek je komunikován mezi zákazníkem a programátorem prostřednictvím konverzace. Konverzace je hlavně ústní, ale může být doplněna dokumenty. Potvrzení je reprezentováno akceptačními testy. Pro každý požadavek musí být vytvořen jeden nebo více akceptačních testů, které ověří, že byl správně implementován.

1.6. Malé verze (Small Releases)

XP je založeno na iterativním, přírůstkovém vývoji. Výsledkem iterace je implementované řešení dodané zákazníkovi. Protože si zákazník sám zvolil, které vlastnosti budou v iteraci realizovány, řešení mu přináší hodnotu. Verze jsou dodávány často (denně, týdně, měsíčně), což je možné díky praktice kontinuální integrace. Nepřetržité testování snižuje chybovost, takže po uvolnění verze není nutné dlouho testovat.

1.7. Zákaznické testy (Customer tests)

Pro každý požadavek specifikuje zákazník akceptační test (Acceptance Test), který ověří, zda byl požadavek implementován úspěšně. Akceptační testy se provádějí často a jejich výsledky jsou zveřejňovány. Vytvoření akceptačního testu před implementací pomáhá zákazníkovi jasně definovat problém a komunikovat jej s programátory.

1.8. Metafora (Metaphor)

XP týmy definují společnou vizi fungování systému, která se nazývá metafora. Metafora pomáhá pochopit prvky systému a vztahy mezi nimi. Může být poetická, ale někdy je těžké takovou vytvořit. V každém případě je ale nutné, aby tým používal společnou terminologii a chápal, jak systém pracuje.

1.9. Nepřetržitá integrace (Continuous Integration)

Integrace a sestavení se provádí několikrát denně. Každý pár je zodpovědný za integraci svého kódu, kdykoliv se v něm vyskytne významnější změna

1.10. Společné vlastnictví kódu (Collective Ownership)

V XP projektu může každý provést jakoukoli změnu systému. To znamená, že na každou část kódu dohlíží mnoho lidí, což zvyšuje kvalitu kódu a snižuje množství chyb. Aby tato praktika fungovala, je třeba ji spojit s dalšími praktikami XP, zejména párovým programováním a testy.

1.11. Standardy pro psaní zdrojového kódu (Coding Standard)

Všichni dodržují konvence pro psaní zdrojového kódu. Konvence jsou definovány tak, že umožňují komunikaci prostřednictvím zdrojového kódu, udržují kód konzistentní a pochopitelný pro celý tým a umožňují snadnou refaktorizaci. Dodržování konvencí je nutným předpokladem pro praktiky párové programování a společné vlastnictví kódu.

1.12. Udržitelný vývoj (Sustainable Pace)

XP prosazuje zdravý vývoj, stanovenou týdenní pracovní dobu, maximálně 1 týden práce přesčas a dovolenou.

1.13. Jednoduchý návrh (Simple Design)

XP prosazuje nejjednodušší možné řešení. Každé složitější řešení je třeba ihned nahradit jednodušším. Udržování jednoduchého návrhu je ale těžké a vyžaduje odvahu nezahrnout do řešení žádné budoucí požadavky.

1.14. Párové programování (Pair Programming)

Programování v XP probíhá v párech u jednoho počítače. Jeden z páru přemýšlí o implementaci dané metody, druhý přemýšlí strategicky – jaké napsat další testy, jak zjednodušit implementaci. Páry jsou dynamické a během dne se mění, což podněcuje komunikaci. Tato praktika sice na první pohled vypadá jako málo efektivní, ale opak je pravdou. Umožňuje vytvářet kvalitnější software, sdílet a přenášet znalosti a zajistit dodržování praktik XP.

1.15. Refaktorizace (Refactoring)

Refaktorizace (refactoring) znamená změnu struktury systému bez změny jeho chování. Jejím cílem je zjednodušení, zpřehlednění a zajištění flexibility. Refaktorizace v průběhu celého životního cyklu projektu šetří čas a zvyšuje kvalitu.

1.16. Vývoj řízený testy (Test-Driven Development)

Vývoj řízený testy požaduje, aby pro každou část kódu byl napsán jednotkový test (unit test), a to dříve než bude napsán kód. Jednotkové testy plní úlohu záchranné sítě při regresním testování. Jsou také podmínkou refaktorizace. Před uvolněním (distribucí) musí každý kód úspěšně projít jednotkovými testy.

2. Poznámky, reference

Buchalcevová, A. - Metodiky budování informačních systémů - (Oeconomica 2009) - ISBN9788024515403,

Beck, K. ; Makovec, P. ; Gamma, E. - Extrémní programování: knihovna programátora - (Grada Publishing 2002) - ISBN9788024703008,

Jeffries, R. - What is Extreme Programming? - (xprogramming.com 2008) - pro MBI zpracovala: Buchalcevová, A. (katedra IT, VŠE)