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