Extrémní programování

Extrémní programování (XP) je agilní metodologie vývoje softwaru, vytvořená skupinou lidí okolo Kenta Becka počátkem 90. let 20. století, která předepisuje určité činnosti všem účastníkům vývojového procesu. Jedná se o tradiční činnosti, které jsou však dovedeny do extrému. Díky tomu by mělo být extrémní programování schopné se lépe přizpůsobit měnícím se požadavkům zákazníků a dodávat software vyšší kvality.

Historie extrémního programování

Extrémní programování bylo vytvořeno Kentem Beckem, počátkem devadesátých let dvacátého století, během jeho práce v Chrysleru na mzdovém systému C3. Základní praktiky extrémního programování jsou však mnohem starší. Kent Beck byl přizván do projektu C3 za účelem optimalizace systému. Využil své práce, kterou vytvořil se svým častým spolupracovníkem Wardem Cunninghamem, a navrhl několik změn v činnostech týmu. Dále do projektu přizval Rona Jeffriese, aby jim pomohl vyvinout a vylepšit tyto nové metody. Informace o principech a činnostech extrémního programování se začaly šířit internetem za pomoci různých wiki stránek. Do vývoje se začali připojovat další lidé a vznikaly i odvozené metodologie. Avšak první oficiální příručkou extrémního programování se stala kniha Kenta Becka, Extreme Programming Explained, vydaná roku 1999. V dnešní době je již extrémní programování obecně známou metodologií, která je používána i v mnoha netradičních oblastech. Její vývoj však stále trvá, a extrémní programování neustále přijímá nové agilní metody zatímco jiné, které se ukázaly býti příliš rigidními, jsou vypouštěny.

Proč extrémní?

Pokud XP používá pouze osvědčené a známé principy a postupy vývoje software, co tuto metodiku dělá tak extrémní? Základní princip je v dotažení těchto osvědčených činností do extrému.

  • Pokud se osvědčila revize kódu, pak v XP se zdrojový text reviduje neustále. Využívá se tzv. párového programování, kdy společně u jednoho počítače pracují dva programátoři. Zabraňuje se tam mimo jiné tzv. profesionální slepotě.
  • Pokud se osvědčilo testování kódu, pak v XP se testuje vše a neustále. Testují jak programátoři pomocí „jednotkových testů“ tak i zákazníci pomocí „akceptačních testů“ (testů funkcionality). Testovací kód mnohdy svým rozsahem převyšuje vlastní výkonný kód. Testování pak probíhá prakticky neustále, před změnou kódu, po změně kódu a kontroluje zda se v průběhu vývoje funkcionalita nepoškodila.
  • Pokud se osvědčilo navrhování kódu, pak v XP bude navrhovat úplně každý a neustále. Pomocí refaktorizace může každý kontrolovat návrh kódu a vhodně ho upravovat.
  • Pokud se osvědčila jednoduchost, pak v XP udržujeme program na co nejmenší úrovni složitosti. Vždy programujeme jen to, co je v danou chvíli nezbytné. Nejjednodušší program, který bude fungovat.
  • Pokud je důležitá architektura, pak v XP se bude každý neustále podílet na definování a úpravě architektury. Využívá se k tomu metafory.
  • Pokud je důležité testování integrace, pak se v XP testuje integrace jednotlivých komponent i několikrát denně, aby bylo zajištěno že všechny části spolupracují tak jak mají. Toto pravidlo se nazývá neustálou integrací.
  • Pokud se osvědčily krátké iterace, pak v XP zkrátíme iterační periodu na extrémně krátkou – minuty, hodiny či dny místo týdnů, měsíců či roků. Jakmile je nová funkce připravena a otestována, integrujeme ji do produkční verze programu. K určení optimální iterační periody využíváme plánovací hru.

Jak napsal Kent Beck ve své knize Extreme Programming Explained, je to jako, když máte ovládací panel s otočným knoflíkem, od jedné do deseti, pro každou osvědčenou metodu. Extrémní programování nastává, pokud všechny knoflíky otočíte na desítku.

Základní principy extrémního programování

Extrémní programování uznává základní čtyři hodnoty:

Komunikace

V rámci projektu je třeba udržovat kvalitní komunikaci mezi všemi zainteresovanými subjekty. Pokud selže komunikace mezi programátorem a zákazníkem, dostaneme software, který zákazníkovi nemusí vyhovovat. Pokud selže komunikace mezi manažerem a programátorem, důležité informace o stavu projektu mohou manažerovi ztížit jeho rozhodování. XP přichází s postupy práce, které komunikaci podporují nebo i vyžadují. Patří mezi ně například párové programování. Stejně tak důležitá je i role kouče, který je v týmu mimo jiné od toho, aby špatně komunikující články a jejich interakci s týmem obnovil.

Jednoduchost

V extrémním programování se vždy programuje pouze to, co je třeba ke splnění aktuálních požadavků. Nikdy se nevytváří kód, který se bude „nejspíš“ hodit v budoucnu.

XP vychází z předpokladu, že požadavky se mohou zítra změnit, jakákoliv práce navíc by pak byla ztracena, zbytečná. Plýtvání se tedy předchází, kód navíc, „do zásoby“ nebo „pro strýčka Příhodu“, se raději ani vůbec nenapíše.

Související informace naleznete také v článcích KISS a Occamova břitva.

Zpětná vazba

Zpětná vazba se v projektu projevuje hned na několika místech. V první řadě programátoři neustále tvoří jednotkové testy, takže v krátkých časových intervalech dokáží ověřit, že vše funguje tak jak má a že se nic poslední změnou kódu nerozbilo. Dále je zde například zpětná vazba pro zákazníky, kteří prováděním svých akceptačních testů dokáží zjistit, v jakém stavu se program nachází.

Odvaha

Odvaha je u programátora potřeba, pokud například narazí na významný problém, jehož oprava nejspíš způsobí kaskádu souvisejících problémů. Pustit se do tak velké změny vyžaduje odvahu.

Stejně tak vyžaduje odvahu zahodit kód, na kterém programátor pracoval třeba celý den, ale stále se mu nedaří ho zprovoznit. Zahození celodenní práce vyžaduje odvahu, ale druhý den programátor pravděpodobně dokáže najít optimální řešení mnohem rychleji.

12 základních praktik extrémního programování

Praktiky používané v extrémním programování se dají rozdělit do tří základních oblastí. Business praktiky, týmové praktiky a programovací praktiky.

Business praktiky

Plánovací hra

Zákazník a vývojový tým společně určují, jak dosáhnout maximálního ekonomického přínosu softwaru za co nejkratší čas. Celý proces začíná tím, že zákazníci vytvoří seznam funkčních požadavků, které od systému požadují. Každý tento požadavek se rozepíše jako tzv. uživatelský scénář, kde je v jazyku zákazníka funkce popsána. V dalším kole si tyto požadavky projde vývojový tým, a určí, jak rychle a za jakou cenu je schopný jednotlivé funkce vytvořit. Na řadě je opět zákazník a musí se rozhodnout, co je pro něj důležité a co má být implementováno jako první. Jednotlivé požadavky jsou pak seskupeny do jednotlivých iterací podle důležitosti.

Zákazník na pracovišti

K vytvoření použitelného software je potřeba mít k dispozici skutečného zákazníka, čím není myšleno toho, kdo bude platit, nýbrž toho, kdo bude systém používat. Tato osoba musí mít pravomoc určovat požadavky a stanovovat priority. Umožňuje lepší komunikaci mezi vývojáři a zákazníkem.

Vydávání malých verzí

Dle extrémního programování je třeba vydávat nové verze tak často, jak to jen jde. Tak aby se nové, přínosné funkce dostaly k zákazníkovi co nejdříve. Programátoři tak mají také rychlejší zpětnou vazbu.

Metafora

V projektovém týmu je důležité, aby všichni dokázali jednoduše o systému komunikovat. Proto je zde metafora, která poskytuje systém jmen a popisů systému. Používané pojmy tak jsou zapamatovatelné, jednoduché k pochopení a především sdílené celým týmem.

Týmové praktiky

Párové programování

Na produkčním kódu vždy pracují společně dva programátoři. Společně pracují nad jedním zdrojovým kódem. Zatímco jeden píše kód (řidič), druhý (navigátor) přemýšlí o souvislostech přidávaného kódu, zda je to optimální řešení a podobně. Oba programátoři spolu neustále komunikují své záměry a postřehy a vzniká tak rychlá zpětná vazba. Programátoři si své role v páru střídají. Stejně tak se během dne obměňují i páry. Pár většinou tvoří dva programátoři s různými znalostmi, které je potřeba skloubit pro vyřešení určitého problému. Pokud se programátor rozhodne zkoumat nějakou experimentální větev programu, pak může pracovat samostatně. Nemůže pouze psát kód určený k integraci do finálního systému.

Společné vlastnictví kódu

Žádný z programátorů nemá výhradní právo na určitou část kódu či softwarový modul. Kdokoliv může měnit kód kdekoliv a kdykoliv. Funkce se přece jenom opírají o testy, takže i když se něco pokazí, hned bude vidět kde. Společné vlastnictví kódu je také základem pro párové programování a refaktorování.

Standardy kódu

Pro dobrou spolupráci na společném kódu je třeba vytvořit určité společné standardy. Ať už se jedná o sjednocení odsazování či pojmenovávání, ve výsledku je třeba, aby byl kdokoliv schopný efektivně pracovat s kódem kohokoliv druhého. V ideálním případě by nemělo být poznat, kdo psal kterou část kódu. Dodržování tohoto principu je nutné pro efektivní práci v párech a pro refaktorování.

Udržitelné tempo

Metodika XP zastává názor, že pokud jsou programátoři unavení, pak dělají více chyb a produkují špatný kód. Proto je třeba nastavit takové tempo, které bude udržitelné po dlouhou dobu. Přesná hodnota je individuální na konkrétním pracovníkovi ale obecně se pohybuje okolo 40 hodin týdně. Přesčasy jsou v XP spíše nežádoucím jevem a také znakem možných problémů projektu. Někdy je sice třeba zapracovat déle, ale XP má pro tyto situace jednoduché pravidlo: Nemůžete pracovat přesčas, pokud jste pracovali přesčas minulý týden.

Programovací praktiky

Průběžná integrace

Do produkčního softwaru jsou integrovány nové funkce co možná nejčastěji, minimálně jednou denně. Po přidání každé funkce jsou spuštěny testy a dá se tak okamžitě zjistit pokud něco nefunguje. Reakce na takovouto chybu je tak také mnohem rychlejší.

Jednoduchý návrh

XP tvrdí, že je pravděpodobné, že se požadavky na software stejně změní a proto je neefektivní plánovat dopředu funkčnost, které by mohla mít účel v budoucnu. Pravidlo zní, vždy vytvářet ten nejjednodušší program, který splňuje aktuální požadavky.

Refaktorizace kódu

Programátoři vylepšují kvalitu kódu tím, že při své práci neustále kontrolují, zda by se nedal kód vylepšit či zjednodušit. Eliminují duplicity a zvyšují čitelnost. Díky společnému vlastnictví kódu může každý programátor bez obav vylepšovat jakýkoliv kód. Díky společným standardům mu nebude dělat potíže vyznat se v cizím kódu a jeho nový kód bude také srozumitelný. Navíc se mohou programátoři pouštět i do složitých a nebezpečných změn, protože jsou jištěni sadou testů.

Testování

Programátoři v XP začínají vždy psaním testů a až následně vlastního funkčního kódu, který naplňuje požadavky dané testy. Dále jsou zde i zákazníci, kteří tvoří akceptační testy. Ty vychází z uživatelských příběhů a kontrolují, zda je v kódu obsažena všechna požadovaná funkčnost. V XP musí zásadně procházet testy na 100%.

Postup vývoje

Podrobnější informace naleznete v článku Proces vývoje softwaru.

Pravidla, která se v XP dodržují:

Zadání

  • sepsání „User stories“ (uživatelských příběhů, scénářů)
  • seznam funkčních požadavků, akceptačních kritérií, i podle uživatelských příběhů
  • Zákazník může akceptační kritéria kdykoli doplnit a restartovat tak cyklus vývoje.
    • Dosavadní již rozběhlý běh vývoje pak je ale nutno prohlásit za promarněný (i peněžně).

Plánování

  • plánování vydání tvoří časový harmonogram
  • časté vydávání malých změn
  • měří se aktuální rychlost vývoje
  • projekt je rozdělen do iterací
  • každá iterace začíná plánováním
  • rychlé schůze, nejlépe ve stoje
  • „sprav to, když se to rozbije“

Design

  • ceněná je jednoduchost
  • pro systém musí existovat metafora
  • pro design se používají Class, Responsibilities, and Collaboration kartičky
  • pro zmenšení rizika „spike solution“
  • funkčnost není přidávána předčasně
  • časté refaktorování (kdykoliv a kdekoliv)

Programování

Podrobnější informace naleznete v článku Programování.
  • zákazník vždy spolupracuje
  • zdrojový kód musí odpovídat firemní kultuře
  • nejdřív se píší jednotkové testy
  • veškerý kód programují programátoři ve dvojicích (tj. dva programátoři sedí u jednoho počítače a u jedné klávesnice)
  • integraci provádí v jednu chvíli pouze jediný pár programátorů
  • integrace probíhá často
  • zdrojové kódy vlastní všichni programátoři (každý přispívá k celku a odpovídá za celek)
  • optimalizace se provádí až nakonec
  • žádné pracovní přesčasy

Testování

Podrobnější informace naleznete v článku Testování softwaru.
  • všechen kód má své unit testy a všemi musí produkt úspěšně projít, všechny splnit, než je vydán.
  • když se najde chyba, vytvoří se na ní nové unit testy. (je zahrnuta do knowledge-base, znalostní báze produktu)
  • unit testy jsou jen nutnou, ale ne postačující podmínkou „otestovanosti“: Cílené testování testery/QA se i nadále předpokládá
  • interní akceptační testy se spouští/provádí často a reprodukovatelně, jejich výsledky se zaznamenávají.

Dodávka a akceptace

Podrobnější informace naleznete v článku Akceptace (software).
  • Dodavatel je povinen pro zákazníka připravit akceptační prostředí, do něj produkt nasadit, nakonfigurovat ho a naplnit daty.
  • Zákazník svá akceptační testování provádí právě a jen podle příběhů a kritérií ze zadání.
  • Pokud dodávka splňuje všechna akceptační kritéria, zákazník ji musí převzít.
    • Zákazník však může akceptační kritéria doplnit a iniciovat tak další cyklus vývoje (placeného).

Odkazy

Literatura

  • Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley
  • Kent Beck and Cynthia Andres: Extreme Programming Explained: Embrace Change, Druhé vydání, Addison-Wesley
  • Kent Beck, Martin Fowler: Planning Extreme Programming
  • Ron Jeffries, Ann Anderson, Chet Hendrickson: Extreme Programming Installed, předmluva Kent Beck

Související články

Externí odkazy