Extrémní programování

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.

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.

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 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.

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.

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.

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.

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.

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.

Žá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í.

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í.

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.

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ší.

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.

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ů.

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%.

• 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í 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“

• 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)

• 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

• 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í.

• 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).