Extrémní programovací postupy - Extreme programming practices

Extreme programming ( XP ) je agilní metodika vývoje softwaru používaná k implementaci softwarových projektů. Tento článek podrobně popisuje postupy používané v této metodice. Extrémní programování má 12 praktiky rozdělená do čtyř oblastí, které jsou odvozeny ze osvědčených postupů v oblasti softwarového inženýrství .

Jemná zpětná vazba

Párové programování

Párové programování znamená, že veškerý kód produkují dva lidé programující na jednom úkolu na jedné pracovní stanici. Jeden programátor má kontrolu nad pracovní stanicí a přemýšlí většinou o kódování podrobně. Druhý programátor se více zaměřuje na celkový obraz a průběžně kontroluje kód, který vytváří první programátor. Programátoři vyměňují role po minutách až hodinách.

Páry nejsou pevné; programátoři často střídají partnery, aby každý věděl, co všichni dělají, a všichni zůstali obeznámeni s celým systémem, dokonce i s částmi mimo jeho sadu dovedností. Tímto způsobem může párové programování také zlepšit komunikaci celého týmu. (To také jde ruku v ruce s konceptem kolektivního vlastnictví).

Plánovací hra

Hlavní plánovací proces v rámci extrémního programování se nazývá Planning Game. Tato hra je setkání, které se koná jednou za iteraci, obvykle jednou týdně. Proces plánování je rozdělen do dvou částí:

  • Plánování vydání : Toto je zaměřeno na určení, jaké požadavky jsou obsaženy v jakých krátkodobých vydáních a kdy by měly být dodány. Zákazníci a vývojáři jsou toho součástí. Release Planning se skládá ze tří fází:
    • Fáze průzkumu: V této fázi zákazník poskytne užší seznam požadavků na vysokou hodnotu systému. Ty budou zapsány na karty příběhů uživatelů .
    • Fáze závazku: Ve fázi závazku se obchod a vývojáři zaváží k funkcím, které budou zahrnuty, a datu příštího vydání.
    • Fáze řízení: Ve fázi řízení lze plán upravit, přidat nové požadavky a/nebo změnit nebo odstranit stávající požadavky.
  • Iterační plánování : Plánuje činnosti a úkoly vývojářů. Do tohoto procesu není zákazník zapojen. Iterační plánování také sestává ze tří fází:
    • Fáze průzkumu: V této fázi bude požadavek převeden na různé úkoly. Úkoly jsou zaznamenány na karty úkolů.
    • Fáze závazku: Úkoly budou přiděleny programátorům a bude odhadnut čas potřebný k dokončení.
    • Fáze řízení: Úkoly jsou prováděny a konečný výsledek odpovídá původnímu příběhu uživatele.

Účelem plánovací hry je vést produkt k dodání. Namísto predikce přesných termínů, kdy budou dodávky nutné a vyráběné, což je obtížné udělat, má za cíl „nasměrovat projekt“ do dodání pomocí přímého přístupu. Přístup Planning Game byl také přijat non-softwarovými projekty a týmy v kontextu agility podnikání .

Plánování vydání

Průzkumná fáze

Jedná se o iterativní proces shromažďování požadavků a odhad pracovního dopadu každého z těchto požadavků.

  • Napište příběh: Obchod přišel s problémem; během schůzky se vývoj pokusí definovat tento problém a získat požadavky. Na základě obchodního problému musí být napsán příběh ( příběh uživatele ). Provádí to byznys, kde poukazují na to, co chtějí, aby část systému dělala. Je důležité, aby vývoj neměl na tento příběh žádný vliv. Příběh je napsán na kartě příběhu uživatele.
  • Odhad příběhu: Vývoj odhaduje, jak dlouho bude trvat implementace práce vyplývající z karty příběhu. Vývoj může také vytvářet špičková řešení pro analýzu nebo řešení problému. Tato řešení se používají k odhadu a jsou vyřazena, jakmile každý získá jasnou vizualizaci problému. Opět to nemusí mít vliv na obchodní požadavky.
  • Rozdělit příběh: Před zahájením plánování iterace je třeba vyřešit každou složitost kritickou pro design. Pokud vývoj není schopen odhadnout příběh, musí být rozdělen a napsán znovu.

Když firma nemůže přijít s žádnými dalšími požadavky, pokračuje se do fáze závazku.

Fáze závazku

Tato fáze zahrnuje stanovení nákladů, přínosů a dopadu plánu. Má čtyři komponenty:

  • Seřadit podle hodnoty: Business seřadí uživatelské příběhy podle obchodní hodnoty .
  • Seřadit podle rizika: Vývoj třídí příběhy podle rizika.
  • Nastavit rychlost: Vývoj určuje, jakou rychlostí mohou projekt provést.
  • Zvolte rozsah: Budou vybrány příběhy uživatelů, které budou dokončeny v příštím vydání. Na základě příběhů uživatelů je určeno datum vydání.
Seřadit podle hodnoty

Obchodní stránka třídí uživatelské příběhy podle obchodní hodnoty. Uspořádají je do tří hromádek:

  • Kritické: příběhy, bez nichž systém nemůže fungovat nebo nemá žádný význam.
  • Významná obchodní hodnota : Nekritické uživatelské příběhy, které mají významnou obchodní hodnotu.
  • Rád: Uživatelské příběhy, které nemají významnou obchodní hodnotu.
Seřadit podle rizika

Vývojáři třídí uživatelské příběhy podle rizika. Kategorizují se také do tří hromádek: příběhy uživatelů s nízkým, středním a vysokým rizikem. Následuje příklad přístupu k tomuto:

  • Určete index rizika: Každému uživatelskému příběhu dejte index od 0 do 2 pro každý z následujících faktorů:
    • Úplnost (známe všechny podrobnosti příběhu?)
      • Kompletní (0)
      • Neúplné (1)
      • Neznámý (2)
    • Volatilita (pravděpodobně se změní?)
      • nízká (0)
      • střední (1)
      • vysoký (2)
    • Složitost (jak těžké je vybudovat?)
      • jednoduché (0)
      • standardní (1)
      • komplexní (2)

Jsou přidány všechny indexy pro uživatelský příběh, které přiřazují uživatelským příběhům index rizika nízký (0–1), střední (2–4) nebo vysoký (5–6).

Fáze řízení

Ve fázi řízení mohou programátoři a podnikatelé tento proces „řídit“. To znamená, že mohou provádět změny. Jednotlivé uživatelské příběhy nebo relativní priority různých uživatelských příběhů se mohou změnit; odhady se mohou ukázat jako špatné. Toto je šance upravit plán odpovídajícím způsobem.

Iterační plánování

Vzhledem k tomu, že se plánují příběhy o rychlosti týmu. Iterace může trvat 1 až 3 týdny.

Průzkumná fáze

Fáze průzkumu plánování iterace je o vytváření úkolů a odhadování doby jejich implementace.

  • Přeložte požadavek na úkoly: Umístěte na karty úkolů.
  • Spojit/rozdělit úkol: Pokud programátor nemůže odhadnout úkol, protože je příliš malý nebo příliš velký, bude muset programátor úkol zkombinovat nebo rozdělit.
  • Odhad úkolu: Odhadněte čas potřebný k provedení úkolu.
Fáze závazku

Ve fázi závazku plánování iterace jsou programátorům přiřazeny úkoly, které odkazují na různé uživatelské příběhy.

  • Programátor přijímá úkol: Každý programátor si vybere úkol, za který přebírá odpovědnost.
  • Programátor odhaduje úkol: Protože za program je nyní zodpovědný programátor, měl by poskytnout případný odhad úkolu.
  • Nastavit faktor zatížení: Faktor zatížení představuje ideální množství praktického času vývoje na programátora v rámci jedné iterace. Například ve 40hodinovém týdnu s 5 hodinami věnovanými schůzkám by to nebylo více než 35 hodin.
  • Vyvažování: Když jsou všem programátorům v týmu přiřazeny úkoly, provede se srovnání mezi odhadovaným časem úkolů a faktorem zátěže. Poté jsou úkoly vyváženy mezi programátory. Pokud je programátor přehnaný, ostatní programátoři musí převzít některé z jeho úkolů a naopak.
Fáze řízení

Implementace úkolů se provádí během fáze řízení iterace.

  • Získat kartu úkolu: Programátor dostane kartu úkolu za jeden z úkolů, ke kterým se zavázal.
  • Najít partnera: Programátor provede tento úkol společně s dalším programátorem. To je dále diskutováno v praxi Párové programování .
  • Navrhněte úkol: V případě potřeby programátoři navrhnou funkčnost úkolu.
  • Implementujte úkol pomocí Test-driven development (TDD) (viz níže)
  • Spustit funkční test: Spustí se funkční testy (na základě požadavků v přidruženém uživatelském příběhu a kartě úkolu).

Testovaný vývoj

Unit testy jsou automatizované testy, které testují funkčnost částí kódu (např. Třídy, metody). V rámci XP jsou jednotkové testy zapsány před kódováním případného kódu. Tento přístup má stimulovat programátora k zamyšlení nad podmínkami, za kterých by jeho kód mohl selhat. XP říká, že programátor dokončí určitý kus kódu, když nemůže přijít s žádnými dalšími podmínkami, za kterých by kód mohl selhat.

Testově řízený vývoj probíhá rychlým cyklováním v následujících krocích, přičemž každý krok trvá maximálně minuty, nejlépe mnohem méně. Protože každý uživatelský příběh bude obvykle vyžadovat jeden až dva dny práce, bude pro každý příběh nezbytný velmi velký počet takových cyklů.

  • Zápis jednotkového testu : Programátoři napíší minimální test, který by měl selhat, protože funkce nebyla plně implementována do produkčního kódu.
  • Podívejte se, jak nový test selhal: Programátoři ověří, že test skutečně selhal. I když se to může zdát jako ztráta času, tento krok je zásadní, protože ověřuje, že vaše přesvědčení o stavu produkčního kódu je správné. Pokud test neselže, měli by programátoři určit, zda je v testovacím kódu chyba, nebo zda produkční kód podporuje funkce popsané novým testem.
  • Zápis kódu: Programátoři napíší dostatek produkčního kódu, takže nový test projde.
  • Spustit test: Provádějí se testy jednotek, aby se ověřilo, že nový produkční kód prošel novým testem a že žádné další testy selhávají.
  • Refaktor : Odstraňte všechny pachy kódu z produkčního i testovacího kódu.

Intenzivnější verzi výše uvedeného postupu najdete ve třech pravidlech strýčka Boba TDD.

Celý tým

V rámci XP není „zákazník“ ten, kdo platí účet, ale ten, kdo systém skutečně používá. XP říká, že zákazník by měl být vždy po ruce a k dispozici pro dotazy. Například tým vyvíjející systém finanční správy by měl zahrnovat finančního správce.

Nepřetržitý proces

Nepřetržitá integrace

Vývojový tým by měl vždy pracovat na nejnovější verzi softwaru. Vzhledem k tomu, že různí členové týmu mohou mít verze uloženy lokálně s různými změnami a vylepšeními, měli by se pokusit nahrát svou aktuální verzi do úložiště kódu každých několik hodin, nebo když dojde k významnému přerušení. Kontinuální integrace zamezí zpožděním v pozdějším cyklu projektu, způsobeným problémy s integrací.

Vylepšení designu

Protože doktrína XP obhajuje programování pouze toho, co je dnes potřeba, a její implementaci co nejjednodušeji, někdy to může mít za následek zaseknutí systému. Jedním z příznaků je potřeba duální (nebo více) údržby: funkční změny začínají vyžadovat změny více kopií stejného (nebo podobného) kódu. Dalším příznakem je, že změny v jedné části kódu ovlivňují mnoho dalších částí. Doktrína XP říká, že když k tomu dojde, systém vám řekne, abyste svůj kód refaktorovali změnou architektury, což je jednodušší a obecnější.

Malé vydání

Dodávka softwaru se provádí častým vydáváním živých funkcí, které vytvářejí konkrétní hodnotu. Malé verze pomáhají zákazníkovi získat důvěru v postup projektu. To pomáhá zachovat koncepci celého týmu, protože zákazník může nyní přicházet se svými návrhy k projektu na základě skutečných zkušeností.

Sdílené porozumění

Kódovací standard

Kódovací standard je dohodnutý soubor pravidel, která celý vývojový tým souhlasí s dodržováním v průběhu projektu. Norma specifikuje konzistentní styl a formát zdrojového kódu ve zvoleném programovacím jazyce a také různé programovací konstrukce a vzory, kterým je třeba se vyhnout, aby se snížila pravděpodobnost defektů. Standardem kódování může být standardní konvence specifikovaná prodejcem jazyka (např. The Code Conventions for the Java Programming Language, recommended by Sun), or custom defined by the development team.

Extrémní programování podporovatelé obhajují kód, který je self-dokumentovat na nejvzdálenější stupeň možné. Tím se snižuje potřeba komentářů ke kódu , které se mohou synchronizovat se samotným kódem.

Kolektivní vlastnictví kódu

Kolektivní vlastnictví kódu (známé také jako „vlastnictví týmového kódu“ a „sdílený kód“) znamená, že za veškerý kód odpovídá každý; proto je každému dovoleno změnit jakoukoli část kódu. Kolektivní vlastnictví kódu není jen organizační politika, ale také pocit. „Vývojáři cítí vlastnictví týmového kódu více, když rozumějí kontextu systému, přispěli k danému kódu, vnímají kvalitu kódu jako vysokou, věří, že produkt uspokojí potřeby uživatelů a vnímají vysokou soudržnost týmu.“ K této praxi přispívá párové programování, zejména překrývající se rotace párů: díky práci v různých párech programátoři lépe porozumí kontextu systému a přispějí do více oblastí základny kódu.

Kolektivní vlastnictví kódu může urychlit vývoj, protože vývojář, který si všimne chyby, ji může okamžitě opravit, což může celkově omezit chyby. Programátoři však mohou také zavést chyby při změně kódu, kterému dobře nerozumí. Dostatečně definované jednotkové testy by měly tento problém zmírnit: pokud nepředvídané závislosti vytvářejí chyby, pak při spuštění jednotkových testů ukážou selhání.

Kolektivní vlastnictví kódu může vést k lepšímu zálohování členů, větší distribuci znalostí a učení, sdílené odpovědnosti za kód, vyšší kvalitě kódu a omezenému přepracování. Může to ale také vést ke zvýšenému konfliktu členů, nárůstu chyb, změnám mentálního toku vývojářů a přerušení jejich uvažování, prodloužení doby vývoje nebo menšímu porozumění kódu.

Jednoduchý design

Programátoři by měli k návrhu softwaru přistupovat způsobem „jednoduchý je nejlepší“. Kdykoli je napsán nový kousek kódu, autor by si měl položit otázku: „Existuje jednodušší způsob, jak zavést stejnou funkci?“. Pokud je odpověď ano, měl by být zvolen jednodušší kurz. Ke zjednodušení složitého kódu by mělo být také použito refaktorování.

Systémová metafora

Systémová metafora je příběh, o kterém každý - zákazníci, programátoři a manažeři - může vyprávět o tom, jak systém funguje. Jedná se o koncept pojmenování pro třídy a metody, který by měl členovi týmu usnadnit odhadnout funkčnost konkrétní třídy/metody, a to pouze podle jejího názvu. Například knihovní systém může vytvořit loan_records(class)pro borrowers(class), a pokud by se položka stala po splatnosti, může provést operaci make_overdue na catalogue(class). Pro každou třídu nebo operaci je funkce zřejmá pro celý tým.

Programátorský blahobyt

Udržitelné tempo

Koncept je takový, že programátoři nebo vývojáři softwaru by neměli pracovat déle než 40 hodin týdně, a pokud je jeden týden přesčas, příští týden by neměl zahrnovat více přesčasů. Vzhledem k tomu, že vývojové cykly jsou krátké cykly kontinuální integrace a cykly úplného vývoje (vydání) jsou častější, projekty v XP nedodržují typickou dobu krize, kterou vyžadují jiné projekty (vyžadující přesčas).

Součástí tohoto konceptu je také to, že lidé podávají nejlepší a kreativnější výkon, pokud jsou dobře odpočatí.

Klíčem k dosažení udržitelného tempa je časté sloučení kódu a vždy spustitelný a testovaný vysoce kvalitní kód. Neustálý způsob refaktorování práce posiluje členy týmu svěží a bdělou myslí. Intenzivní způsob spolupráce v týmu vede k potřebě dobít se o víkendech.

Dobře testovaný, průběžně integrovaný, často nasazovaný kód a prostředí také minimalizují četnost neočekávaných výrobních problémů a výpadků a s tím související požadovanou noční a víkendovou práci mimo pracovní dobu.

Viz také

Reference

externí odkazy