Extrémní programování. Metodiky vývoje softwaru

Důkladné ekonomické zdůvodnění všech akcí – dělá se jen to, co zákazník potřebuje a nevede to k nerentabilnosti projektu.

Formování základní architektury co nejdříve.

Použití komponentní architektury.

Prototypování, postupný vývoj a testování.

Pravidelné hodnocení aktuálního stavu.

Řízení změn, neustálý vývoj změn zvenčí projektu.

Zaměřte se na vytvoření produktu, který funguje v reálném prostředí.

Zaměřte se na kvalitu.

Přizpůsobení procesu potřebám projektu.

Extrémní programování

Extrémní programování (XP) se objevil jako evoluční metoda vývoje softwaru"dolů nahoru". Tento přístup je příkladem tzv. metody„živý“ vývoj (metoda agilního vývoje) . Do skupiny „živých“ metod patří kromě extrémního programování i metody SCRUM, DSDM (Dynamic Systems Development Method, metoda vývoje dynamických systémů), Funkcemi Vývoj (vývoj řízený funkcemi systému) atd.

Základní principy živého vývoje softwaru jsou zakotveny v manifestu živého vývoje, který se objevil v roce 2000.

Lidé zapojení do projektu a jejich komunikace jsou důležitější než procesy a nástroje.

Funkční program je důležitější než komplexní dokumentace.

Spolupráce se zákazníkem je důležitější než projednávání detailů smlouvy.

Procházet změnami je důležitější než držet se plánů.

„Živé“ metody se objevily jako protest proti přílišné byrokratizaci vývoje softwaru, množství vedlejších dokumentů, které nejsou nutné k získání konečného výsledku, které je třeba vypracovat při realizaci projektu v souladu s většinou „těžkých“ procesů. , práce navíc podporovat pevný proces organizace, jak je požadováno například v rámci CMM. Většina takových prací a dokumentů přímo nesouvisí s vývojem softwaru a zajišťováním kvality, ale jejich účelem je splnit formální doložky vývojových smluv, získat a potvrdit certifikáty pro shodu s různými standardy.

„Live“ metody umožňují vývojářům soustředit většinu svého úsilí na vývojové úkoly a uspokojování skutečných potřeb uživatelů. Absence hromady dokumentů a nutnost jejich udržování v koherentním stavu umožňuje rychleji a efektivněji reagovat na změny požadavků a prostředí, ve kterém bude muset budoucí program fungovat.

XP má však svůj vlastní diagram vývojového procesu (ačkoliv obecně řečeno, široce používané chápání „procesu vývoje“ jako poměrně rigidního schématu akcí je v rozporu se samotnou myšlenkou „živého“ vývoje), znázorněné na obr. 15.

Podle autorů XP tato technika nesleduje ani tak nějaké obecné vzorce jednání, jako spíše kombinaci následujících technik. Každá technika je však důležitá a bez jejího použití se vývoj nepovažuje za XP, podle Kenta Becka, jednoho z autorů tohoto přístupu, spolu s Wardem Cunninghamem a Ronem Jeffriesem.

Živá plánovací hra

Jeho úkolem je co nejrychleji určit množství práce, kterou je třeba vykonat před další verzí softwaru. Rozhoduje se především na základě priorit zákazníka (tedy jeho potřeb, co potřebuje od systému pro větší úspěch

provozování vašeho podnikání) a za druhé na základě technických posouzení (tj. posouzení složitosti vývoje, kompatibility s ostatními prvky systému atd.). Plány se mění, jakmile se začnou rozcházet s realitou nebo přáním zákazníka.

"Vhazovací" řešení

Obrázek 15. Diagram pracovního postupu v XP.

Časté změny verzí (malá vydání)

Úplně první pracovní verze by se měla objevit co nejrychleji a měla by se začít okamžitě používat. Další verze připravené v poměrně krátkých časových intervalech (od několika hodin pro drobné změny v malém programu až po měsíc nebo dva pro velké přepracování velký systém).

Metafora systému

Metafora v poměrně jednoduchém a týmu pochopitelné formulář by měl popisovat základní mechanismus systému. Tento koncept připomíná architekturu, ale měl by popisovat hlavní podstatu technických rozhodnutí mnohem jednodušeji, pouze jednou nebo dvěma frázemi.

Jednoduchá konstrukční řešení

V každém okamžiku by měl být systém navržen co nejjednodušší. Funkce není třeba přidávat předem - pouze po výslovné žádosti. Veškerá zbytečná složitost je odstraněna, jakmile je objevena.

Testem řízený vývoj(vývoj řízený testem)

Vývojáři nejprve píší testy, poté se snaží implementovat své moduly tak, aby testy fungovaly. Zákazníci předem píší testy, které demonstrují hlavní schopnosti systému, aby viděli, že systém skutečně funguje.

Kontinuální refaktorování

Programátoři neustále přepracovávají systém, aby odstranili zbytečnou složitost, zvýšili srozumitelnost kódu, zvýšili jeho flexibilitu, ale beze změny jeho chování, což se ověřuje spuštěním po každém přepracování testů. Zároveň se dává přednost elegantnějším a flexibilnějším řešením oproti těm, která jednoduše poskytují kýžený výsledek. Neúspěšně přepracované komponenty by měly být identifikovány během provádění testu a vráceny zpět do posledního neporušeného stavu (spolu s komponentami, které na nich závisí).

Párové programování

Kódování provádějí dva programátoři na jednom počítači. Párování je libovolné a liší se úkol od úkolu. Ten, v jehož rukou se klávesnice snaží vyřešit aktuální problém tím nejlepším způsobem. Druhý programátor práci analyzuje

první a dává rady, zvažuje důsledky určitých rozhodnutí, nové testy, méně přímá, ale flexibilnější řešení.

Kolektivní vlastnictví kódu

V Každý člen týmu může kdykoli změnit kteroukoli část kódu. Nikdo by neměl mít vlastní oblast odpovědnosti, za veškerý kód je zodpovědný celý tým jako celek.

Průběžná integrace

Systém je sestaven a prochází integračním testováním tak často, jak je to jen možné, několikrát denně, pokaždé, když několik programátorů dokončí implementaci další funkce.

40 hodinový pracovní týden

Práce přesčas je považována za znamení velké problémy v projektu. Přesčasová práce 2 týdny po sobě není povolena – to programátory vyčerpává a jejich práce je výrazně méně produktivní.

Začlenění zákazníka do týmu(zákazník na místě)

V Součástí vývojového týmu je vždy zástupce zákazníka, který je k dispozici po celý pracovní den a je schopen zodpovědět veškeré dotazy k systému. Jeho odpovědností je pohotově odpovídat na dotazy jakéhokoli typu týkající se funkcí systému, jeho rozhraní, požadovaného výkonu, správného fungování systému v obtížných situacích, nutnosti udržovat komunikaci s ostatními aplikacemi atd.

Použití kódu jako prostředku komunikace

Kód je považován za nejdůležitější prostředek komunikace v týmu. Srozumitelnost kódu je jednou z hlavních priorit. Dodržování standardů kódování, které poskytují tuto jasnost, je nezbytné. Takové standardy by kromě srozumitelnosti kódu měly zajistit minimální jazyk (žádné zdvojení kódu a informací) a měly by být přijaty všemi členy týmu.

Otevřete pracovní prostor

Tým je umístěn v jedné poměrně prostorné místnosti, která usnadňuje komunikaci a umožňuje skupinové diskuse při plánování a přijímání důležitých technických rozhodnutí.

Změna pravidel podle potřeby (jen pravidla)

Každý člen týmu musí přijmout uvedená pravidla, ale v případě potřeby je tým může změnit, pokud s touto změnou souhlasí všichni jeho členové.

Jak je patrné z použitých technik, XP je určen pro použití v rámci malých týmů (ne více než 10 programátorů), což autoři této techniky zdůrazňují. Větší velikost týmu ničí snadnou komunikaci nezbytnou pro úspěch a znemožňuje implementaci mnoha uvedených technik.

Výhody XP, pokud je lze implementovat, jsou větší flexibilita, schopnost rychle a přesně provádět změny v softwaru v reakci na měnící se požadavky a individuální přání zákazníků, vysoká kvalita výsledného kódu a absence nutnosti přesvědčit zákazníky, že výsledek splňuje jejich očekávání.

Nevýhodou tohoto přístupu je neproveditelnost dostatečně velkých a komplexních projektů v tomto stylu, nemožnost naplánovat načasování a složitost projektu na dostatečně dlouhou dobu a jednoznačně předvídat výsledky dlouhodobého projektu z hlediska poměru. kvality výsledku a nákladů na čas a zdroje. Lze také poznamenat, že XP není vhodný pro případy, kdy možná řešení nejsou okamžitě nalezena na základě dříve získaných zkušeností, ale vyžadují předběžný výzkum

XP jako soubor popsaných technik byl poprvé použit při práci na projektu C3 (Chrysler Comprehensive Compensation System, vývoj systému účtování plateb

zaměstnanci Daimler Chrysler). Z 20 účastníků tohoto projektu 5 (včetně výše zmíněných 3 hlavních autorů XP) publikovalo 3 knihy a obrovské množství článků věnovaných XP během samotného projektu i následně. Tento projekt je opakovaně zmiňován v různých zdrojích jako příklad použití této techniky. Následující data jsou sestavena ze zmíněných článků bez neoficiálních důkazů a ilustrují problémy s některými technikami XP při aplikaci na poměrně složité projekty.

Projekt byl zahájen v lednu 1995. Od března 1996, po zahrnutí Kenta Becka, běží pomocí XP. V této době již přesáhl rozpočet a plány na postupnou implementaci funkcí. Vývojový tým byl přerušen a asi šest měsíců poté se projekt vyvíjel docela úspěšně. V srpnu 1998 se objevil prototyp, který mohl sloužit asi 10 000 zaměstnanců. Původně se předpokládalo, že projekt bude dokončen v polovině roku 1999 a výsledný software bude sloužit ke správě benefitů pro 87 000 zaměstnanců společnosti. To bylo zastaveno v únoru 2000 po 4 letech běhu XP kvůli úplnému nedodržení časového rámce a rozpočtu. Vytvořený software nebyl nikdy použit pro práci s daty o více než 10 000 zaměstnancích, i když se ukázalo, že zvládne data o 30 000 zaměstnancích společnosti. Osoba, která hrála roli zákazníka zařazeného do projektového týmu, po několika měsících takové práce odešla, nebyla schopna vydržet pracovní zátěž a do konce projektu nikdy nedostala adekvátní náhradu.

Literatura k přednášce 3

W. Royce. Řízení softwarových projektů. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Jednotný proces vývoje softwaru. Petrohrad: Petr, 2002.

Kroll, Duch RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

K. Beck. Extrémní programování. Petrohrad: Petr, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler jde do „extrémů“. Distributed Computing, 10/1998.

A. Cockburn. Výběr metodiky projektu. Software IEEE, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Posílení argumentů pro párové programování. Software IEEE 4/2000.

G. Keefer. Extrémní programování považováno za škodlivé pro spolehlivý vývoj softwaru. Technická zpráva AVOCA, 2002.

K dispozici jako http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Zveřejněno na http://www.allbest.ru/

Obsah

• Úvod
• 1. Co je XP?
• 3.1 Základní technikyXP
• 4. Výhody a nevýhody
• 5. Historie používání
• Závěr

Úvod

Extrémní programování, často zkráceně XP, je disciplína vývoje softwaru a softwarového podnikání, která zaměřuje úsilí obou stran (programátorů a obchodníků) na společné, dosažitelné cíle. Týmy používající XP produkují kvalitní software velmi rychlým tempem. Techniky, které tvoří disciplínu HR, jsou vybrány, protože jsou založeny na lidské kreativitě a přijetí toho, že lidé jsou nestálí a omylní stvoření.

XP jsou často prezentovány jako soubor technik, ale XP samotné nejsou konečnou čárou. K tomu, abyste na konci tohoto procesu získali dlouho očekávanou zlatou hvězdu, není potřeba HR cvičit a rozvíjet stále lépe. Naopak XP je startovací čára. XP si klade otázku: "Jak minimální může být naše úsilí, abychom mohli pokračovat ve výrobě kvalitního softwaru?"

Extreme Programming je zjednodušená produkční metodika pro malé a střední týmy specialistů vyvíjejících softwarový produkt v podmínkách nejasných nebo rychle se měnících požadavků.

1. Co je XP?

Extrémnímprádloprogrammpotulovat se(Angličtina) Extrémní Programování, XP) je jednou z flexibilních metodik vývoje softwaru. Autory metodiky jsou Kent Beck, Ward Cunningham, Martin Fowler a další.

XP je zjednodušený, efektivní, flexibilní, předvídatelný, vědecky podložený a velmi příjemný způsob vývoje softwaru s nízkým rizikem. HR se od ostatních metod liší v následujících ohledech:

Použitím extrémně krátkých vývojových cyklů nabízí XP rychlou, skutečnou a průběžnou zpětnou vazbu.

XP používá inkrementální plánování, jehož výsledkem je poměrně rychlý vznik celkového plánu projektu, ale je zřejmé, že tento plán se vyvíjí po celou dobu trvání projektu.

XP používá flexibilní harmonogram implementace té či oné funkcionality, což zlepšuje reakci na měnící se charakter podnikání a měnící se požadavky zákazníků v souvislosti s tím.

XP je založeno na automatické testy, vyvinuté jak programátory, tak zákazníky. Díky těmto testům je možné sledovat vývojový proces, zajistit správný vývoj systému a včas odhalit závady existující v systému.

XP je založeno na ústní komunikaci, testech a zdrojovém kódu. Tyto tři nástroje se používají k výměně informací o struktuře a chování systému.

XP je založeno na vyvíjejícím se procesu návrhu, který pokračuje, dokud samotný systém existuje.

XP je založeno na úzké interakci mezi programátory s nejběžnějšími dovednostmi a schopnostmi.

XP je založeno na technikách, které uspokojují jak krátkodobé instinkty jednotlivých programátorů, tak dlouhodobé zájmy celého projektu.

XP je disciplína vývoje softwaru. Toto je disciplína, protože v rámci XP existují určité věci, které musíte udělat, pokud chcete používat XP. Neměli byste si vybírat, zda budete psát testy nebo ne, protože pokud ne, programování, které děláte, není extrémní.

Metodika XP je navržena tak, aby pracovala na projektech, na kterých může pracovat dva až deset programátorů, které nejsou omezeny pevnými hranicemi stávajícího počítačového prostředí a ve kterých lze všechny potřebné testovací práce dokončit během jednoho dne.

2. Kde to začíná? extrémní programování

Kde začíná extrémní programování? Z pochopení, že typická pozice tuzemského softwarového vývojáře zavazuje co nejvíce snižovat náklady na vývoj. A k tomu je potřeba se zákazníkem intenzivně spolupracovat, rozumět jeho zájmům a nakonec dělat přesně to, co chce: nic víc a nic míň.

Extrémní programování není založeno na konkrétních technikách, jak se běžně věří, ale pouze na čtyřech základních principech: komunikace, jednoduchost, Zpětná vazba a odvahu. Zde je třeba začít.

Extreme Programming nabízí hotové řešení: udržet vše co nejjednodušší, nechat si zákazníka pro sebe nebo zůstat se zákazníkem, nechat ho aktivně sledovat vývojový proces, vítat změnu – a úspěch je téměř zaručen.

V XP týmech je komunikace vždy podporována – nejvíce rychlá náprava výměna informací a zkušeností. To je velmi důležité, když je vyžadována maximální rychlost vývoje. Ale komunikace, jako každé jiné užitečné úsilí, vyžaduje neustálou podporu. Proto musí někdo z týmu převzít odpovědnost za sledování komunikace, stát se takzvaným diplomatem. Komunikace a potřeba vysvětlovat své jednání ostatním členům týmu vás nutí dělat vše co nejjednodušeji. Pokud to nevyjde napoprvé, pracují na zjednodušování znovu a znovu, dokud není dosaženo hlavního cíle – maximální srozumitelnosti kódu pro ostatní vývojáře.

Bez ohledu na to, co děláme – navlékáme nit do jehly nebo jdeme na večírek – vždy se snažíme dosáhnout nějakého cíle. Pokud si všimneme, že se od něj odchylujeme, přizpůsobíme tomu své jednání. A teď si představte, jak je těžší navléci jehlu se zavřenýma očima nebo se krásně oblékat bez zrcadla! Ale při vývoji programů se často stává toto: děláme něco, čehož výsledek nevidíme. Proto je v extrémním programování pravidlem vidět výsledek svého jednání co nejrychleji. Nebo mluvení technický jazyk, poskytnout co nejrychlejší zpětnou vazbu.

Extrémní programování se nás ptá: proč nerozvinout odvahu? Ostatně ve své práci je velmi důležitá. Je možné bez odvahy převzít odpovědnost za dokončení úkolu a v určitém časovém rámci? Je možné si bez odvahy uvědomit, že jste se dostali do slepé uličky, udělat krok zpět a hledat řešení? A konečně, co umožní vývojáři přiznat svou chybu při posuzování úkolu a včas na ni upozornit ostatní, místo aby jim předkládal hotovou věc až po uplynutí všech lhůt? Výhody odvahy jsou zřejmé a každý úspěch, i v tom nejmenším úkolu, může tuto odvahu rozvinout.

3. XP techniky

Extrémní programování (XP) se objevilo jako evoluční metoda vývoje softwaru zdola nahoru. Tento přístup je příkladem tzv. Agilní vývojové metody. Do skupiny „živých“ metod patří kromě extrémního programování i metody SCRUM, DSDM (Dynamic Systems Development Method, metoda pro vývoj dynamických systémů), Feature-Driven Development (vývoj řízený systémovými funkcemi) atd.

Základní principy živého vývoje softwaru jsou zakotveny v manifestu živého vývoje, který se objevil v roce 2000.

· Lidé zapojení do projektu a jejich komunikace jsou důležitější než procesy a nástroje.

· Pracovní program je důležitější než komplexní dokumentace.

· Spolupráce se zákazníkem je důležitější než projednávání detailů smlouvy.

· Procházet změnami je důležitější než držet se plánů.

„Živé“ metody se objevily jako protest proti přílišné byrokratizaci vývoje softwaru, množství vedlejších dokumentů, které nejsou nutné k získání konečného výsledku, které je třeba vypracovat při realizaci projektu v souladu s většinou „těžkých“ procesů. , další práce na podporu pevného procesu organizace, jako je tato požadovaná například v rámci CMM. Většina takových prací a dokumentů přímo nesouvisí s vývojem softwaru a zajišťováním kvality, ale jejich účelem je splnit formální doložky vývojových smluv, získat a potvrdit certifikáty pro shodu s různými standardy.

„Live“ metody umožňují vývojářům soustředit většinu svého úsilí na vývojové úkoly a uspokojování skutečných uživatelských potřeb. Absence hromady dokumentů a nutnost jejich udržování v koherentním stavu umožňuje rychleji a efektivněji reagovat na změny požadavků a prostředí, ve kterém bude muset budoucí program fungovat.

XP však má svůj vlastní diagram vývojového procesu (ačkoli obecně rozšířené chápání „vývojového procesu“ jako poměrně rigidního schématu akcí je v rozporu se samotnou myšlenkou „živého“ vývoje), znázorněné na obr. .

Podle autorů XP tato technika nesleduje ani tak nějaké obecné vzorce jednání, jako spíše kombinaci následujících technik. Každá technika je však důležitá a bez jejího použití se vývoj nepovažuje za XP, tvrdí Kent Beck, jeden z autorů tohoto přístupu spolu s Wardem Cunninghamem a Ronem Jeffriesem.

· Žítplánování (plánováníhra)

Jeho úkolem je co nejrychleji určit množství práce, kterou je třeba vykonat před další verzí softwaru. Rozhoduje se v prvé řadě na základě priorit zákazníka (tedy jeho potřeb, co potřebuje od systému, aby mohl úspěšněji podnikat) a za druhé na základě technických posouzení (tedy odhadů složitosti vývoj, kompatibilita s ostatními prvky systému atd.). Plány se mění, jakmile se začnou rozcházet s realitou nebo přáním zákazníka.

Rýže.1 Diagram pracovního postupu XP

· ČastézměnaPROTIverze (malývydání)

Úplně první pracovní verze by se měla objevit co nejrychleji a měla by se začít okamžitě používat. Další verze se připravují v poměrně krátkých intervalech (od několika hodin pro malé změny v malém programu až po měsíc nebo dva pro velké přepracování velkého systému). Verze (vydání) produktu by měly být uváděny do provozu co nejčastěji. Dokončení každé verze by mělo zabrat co nejméně času. Každá verze navíc musí být dostatečně smysluplná z hlediska užitečnosti pro podnikání.

· Metafora (metafora) systémy

Metafora v celkem jednoduché a pro tým srozumitelné formě by měla popisovat základní mechanismus systému. Tento koncept připomíná architekturu, ale měl by popisovat hlavní podstatu technických rozhodnutí mnohem jednodušeji, pouze jednou nebo dvěma frázemi.

Architektura je určitá představa o komponentách systému a o tom, jak jsou vzájemně propojeny. Vývojáři používají architekturu k tomu, aby pochopili, kam v systému se přidávají nové funkce a s čím budou některé nové komponenty interagovat.

Metafora systému je analogií toho, co se ve většině technik nazývá architektura. Metafora systému dává týmu představu o tom, jak systém aktuálně funguje, kam se přidávají nové komponenty a jakou formu by měly mít.

· Jednoduchýdesignřešení (jednoduchýdesign)

V každém okamžiku by měl být systém navržen co nejjednodušší. Funkce není třeba přidávat předem - pouze po výslovné žádosti. Veškerá zbytečná složitost je odstraněna, jakmile je objevena.

XP vychází ze skutečnosti, že v průběhu práce se podmínky problému mohou opakovaně měnit, což znamená, že vyvíjený produkt by neměl být předem navržen jako celek. Pokud se při prvním spuštění pokoušíte navrhnout systém od začátku do konce podrobně, ztrácíte čas. XP předpokládá, že návrh je tak důležitý proces, že musí být prováděn nepřetržitě v průběhu projektu. Návrh musí být prováděn po malých krocích s ohledem na neustále se měnící požadavky. V každém okamžiku se snažíme použít ten nejjednodušší design, který je vhodný pro řešení aktuálního problému. Zároveň jej měníme tak, jak se mění podmínky problému.

· Rozvojnazákladtestování (test- řízenýrozvoj)

Vývojáři nejprve píší testy, poté se snaží implementovat své moduly tak, aby testy fungovaly. Zákazníci předem píší testy, které demonstrují hlavní schopnosti systému, aby viděli, že systém skutečně funguje.

XP klade zvláštní důraz na dva typy testování:

ь testování jednotek;

b akceptační zkoušky.

extrémní programovací software

Vývojář si nemůže být jistý správností kódu, který napsal, dokud nefungují absolutně všechny testy modulů systému, který vyvíjí. Unit testy umožňují vývojářům ověřit, že jejich kód funguje správně. Pomáhají také ostatním vývojářům pochopit, proč je potřeba konkrétní část kódu a jak funguje. Unit testy také umožňují vývojáři bez obav refaktorovat.

Akceptační testy zajišťují, že systém skutečně má uvedené schopnosti. Kromě toho akceptační testy umožňují ověřit správné fungování vyvíjeného produktu.

Pro XP má vyšší prioritu přístup zvaný TDD (Test Driven Development), nejprve se napíše test, který neprojde, poté se napíše kód, aby test prošel, a teprve poté se kód refaktoruje.

· Konstantnírecyklace (refaktorování)

Není žádným tajemstvím, že přidání každé nové funkce a růst kódu komplikuje vývoj, identifikaci chyb a provádění následných změn. Jedním z triků extrémního programování je kompenzovat přidávání funkcí pomocí vylepšení kódu. Jedná se o zpracování kódu neboli refaktoring.

Programátoři neustále přepracovávají systém, aby odstranili zbytečnou složitost, zvýšili srozumitelnost kódu, zvýšili jeho flexibilitu, ale beze změny jeho chování, což se ověřuje spuštěním po každém přepracování testů. Zároveň se dává přednost elegantnějším a flexibilnějším řešením ve srovnání s těmi, která jednoduše dávají požadovaný výsledek. Neúspěšně přepracované komponenty by měly být identifikovány během provádění testu a vráceny zpět do posledního neporušeného stavu (spolu s komponentami, které na nich závisí).

Refaktoring je technika pro vylepšení kódu bez změny jeho funkčnosti. XP znamená, že jakmile je kód napsán, bude téměř jistě v průběhu projektu několikrát přepsán. Vývojáři XP nemilosrdně přepracovávají dříve napsaný kód, aby jej vylepšili. Tento proces se nazývá refaktoring. Nedostatek testovacího pokrytí vyvolává odmítnutí refaktoru kvůli obavám z prolomení systému, což vede k postupné degradaci kódu.

· Programovánív párech (párprogramování)

Zkušení vývojáři si všimli, že pravidelná kontrola kódu jiných lidí má pozitivní vliv na jeho kvalitu. Mistři extrémního programování vyvinuli tento přístup neustálou kontrolou kódu během vývoje pomocí techniky zvané párové programování.

Kódování provádějí dva programátoři na jednom počítači. Párování je libovolné a liší se úkol od úkolu. Ten, v jehož rukou se klávesnice snaží vyřešit aktuální problém tím nejlepším způsobem. Druhý programátor analyzuje práci prvního a poskytuje rady, zvažuje důsledky určitých rozhodnutí, nové testy, méně přímá, ale flexibilnější řešení. V případě potřeby se klávesnice volně přenáší z jedné na druhou. Při práci na projektu nejsou dvojice pevně dané: doporučuje se je smíchat, aby každý programátor v týmu dobře porozuměl celému systému. Tímto způsobem párové programování zlepšuje spolupráci v týmu.

· Kolektivnímajetekkód (kolektivnívlastnictví)

Kolektivní majetek znamená, že každý člen týmu je zodpovědný za veškerý zdrojový kód. Každý má tedy právo provádět změny v jakékoli části programu. Párové programování podporuje tuto praxi: při práci v různých párech se všichni programátoři seznámí se všemi částmi kódu systému. Důležitou výhodou sdíleného vlastnictví kódu je, že urychluje proces vývoje, protože pokud dojde k chybě, může ji opravit každý programátor.

Tím, že dáváme každému programátorovi právo změnit kód, riskujeme chyby zavedené programátory, kteří si myslí, že vědí, co dělají, ale neberou v úvahu určité závislosti. Dobře definované UNIT testy řeší tento problém: pokud neprozkoumané závislosti generují chyby, pak další běh UNIT testů selže.

· Konstantníintegrace (kontinuálníintegrace)

Systém je sestaven a prochází integračním testováním tak často, jak je to jen možné, několikrát denně, pokaždé, když několik programátorů dokončí implementaci další funkce.

Pokud dostatečně často integrujete systém, který vyvíjíte, můžete se vyhnout většině problémů s ním spojených. V tradičních metodách se integrace obvykle provádí na samém konci práce na produktu, kdy se má za to, že všechny součásti vyvíjeného systému jsou zcela připraveny. V XP se integrace kódu celého systému provádí několikrát denně poté, co se vývojáři přesvědčí, že všechny testy jednotek probíhají správně.

Navzdory své jednoduchosti má tato technika svá vlastní pravidla použití, jako je úspěšnost stávajících jednotkových testů pro integrovanou funkčnost, přítomnost funkčních nebo akceptačních testů a samozřejmě schopnost vrátit se do předchozího stavu. . Integraci a řešení souvisejících potíží obvykle provádí několik programátorů na samostatném počítači. To umožňuje minimalizovat riziko nežádoucích důsledků integrace.

· 40 hodinpracovnítýden

Práce přesčas je považována za známku větších problémů v projektu. Přesčasová práce 2 týdny po sobě není povolena – to programátory vyčerpává a jejich práce je výrazně méně produktivní.

Člověk, zvláště je-li programátorem, je schopen pro obchod udělat hodně: zdržovat se v práci, chodit do práce o víkendech, vzdát se dovolené, být několik dní vzhůru a sedět u klávesnice... Obecně, co můžete udělat pro svou oblíbenou činnost. Ale extrémní programování je kategoricky proti takovému sebeobětování a porušování přijatých pracovněprávních norem.

To je diktováno nejen ohledy na zákonnost a lidskost, ale především potřebou zvýšit efektivitu práce a přísnou organizaci. Koneckonců, extrémní programování je kolektivní hra, určená ne pro jednotlivce, ale pro celou skupinu. A taková věc, jako je například párové programování, je možné pouze tehdy, když se synchronizují biorytmy jeho účastníků. A je nemožné, když jeden přijde do práce v devět a druhý ve dvanáct, nebo se někdo rozhodne, že je pro něj lepší pracovat v sobotu a neděli, zatímco druhý je nepohodlný.

Nejdůležitější ale je, že k udržení zdraví a výkonnosti potřebuje člověk pořádný odpočinek. Osmihodinový pracovní den a pětidenní pracovní týden jsou stanoveny právě z důvodu maximální produktivity. V mnoha západních společnostech je pozdní odchod z práce považován za nedostatečnou výkonnost nebo neschopnost řádně řídit pracovní dobu. Ve většině případů je to pravda. A z lékařského hlediska vedou prodlevy v práci k neustálé únavě, podrážděnosti a snížené mozkové aktivitě. Je to účinné? Jak zorganizovat neustálou práci v takovém týmu? otevřená komunikace mezi vývojáři a bude možné párové programování? Odpověď je záporná. Normy jsou normy a měly by se dodržovat.

· ZařazenízákazníkPROTItým (na- místozákazník)

Hlavním problémem vývoje softwaru je nedostatek znalostí programátorů ve vývoji předmětová oblast. Extrémní programování našlo cestu z této situace. Ne, toto není vývojářská stáž v podniku zákazníka - pak nebude chtít programovat. Naopak je to účast zákazníka na procesu vývoje.

Součástí vývojového týmu je vždy zástupce zákazníka, který je k dispozici po celý pracovní den a je schopen zodpovědět veškeré dotazy k systému. Jeho odpovědností je pohotově odpovídat na dotazy jakéhokoli typu týkající se funkcí systému, jeho rozhraní, požadovaného výkonu, správného fungování systému v obtížných situacích, nutnosti udržovat komunikaci s ostatními aplikacemi atd.

Mnozí pochybují o možnosti zapojení zákazníka do procesu vývoje. Zákazníci jsou skutečně různí. Pokud se nedaří zákazníka nebo jeho zástupce zaujmout, je někdy vhodné dočasně najmout specialistu na vyvíjený obor. Tento krok omezí nejasnosti v práci, zvýší rychlost vývoje a přiblíží projekt tomu, co chce zákazník obdržet. To může být přínosné i z finanční stránky: vždyť plat programátora je někdy výrazně vyšší než plat specialistů v jiných odvětvích.

· PoužíváníkódJakzařízeníkomunikace

Kód je považován za nejdůležitější prostředek komunikace v týmu. Srozumitelnost kódu je jednou z hlavních priorit. Dodržování standardů kódování, které poskytují tuto jasnost, je nezbytné. Takové standardy by kromě srozumitelnosti kódu měly zajistit minimální jazyk (žádné zdvojení kódu a informací) a měly by být přijaty všemi členy týmu.

· OTEVŘENOpracovníprostor (OTEVŘENOpracovní prostor)

Tým je umístěn v jedné poměrně prostorné místnosti, která usnadňuje komunikaci a umožňuje skupinové diskuse při plánování a přijímání důležitých technických rozhodnutí.

· ZměnapravidlaPodlenutnost (prostěpravidla)

Každý člen týmu musí přijmout uvedená pravidla, ale v případě potřeby je tým může změnit, pokud s touto změnou souhlasí všichni jeho členové.

Jak je patrné z použitých technik, XP je určen pro použití v rámci malých týmů (ne více než 10 programátorů), což autoři této techniky zdůrazňují. Větší velikost týmu ničí snadnou komunikaci nezbytnou pro úspěch a znemožňuje implementaci mnoha uvedených technik.

3.1 Základní techniky XP

Dvanáct základních technik extrémního programování (na základě prvního vydání knihy Extrémní programování vysvětlil) lze sloučit do čtyř skupin:

· Krátký cyklus zpětné vazby (zpětná vazba s jemným měřítkem)

o Testem řízený vývoj

o Plánovací hra

o Zákazník je vždy nablízku (celý tým, zákazník na místě)

o Párové programování

Kontinuální spíše než dávkový proces

o Průběžná integrace

o Refaktoring (vylepšení designu, Refaktor)

o Častá malá vydání

· Porozumění sdílené všemi

o Jednoduchost (jednoduchý design)

o Systémová metafora

o kolektivní vlastnictví kódu nebo vybraných návrhových vzorů (kolektivní vlastnictví vzorů)

o Kódovací standard nebo kódovací konvence

· Programátorské blaho:

o 40hodinový pracovní týden (udržitelné tempo, čtyřicetihodinový týden)

HraPROTIplánování

Náš svět je příliš proměnlivý a nepředvídatelný na to, abychom spoléhali na neměnnost situace. Totéž se děje při vývoji softwaru: u vzácného systému lze říci, že jeho finální podoba byla předem detailně známa již na samém počátku vývoje. Chuť zákazníka obvykle přichází během jídla: neustále chce něco změnit, něco zlepšit nebo něco úplně vyhodit ze systému. To je ta variabilita požadavků, které se všichni tak bojí. Naštěstí je člověku dána schopnost předvídat možné možnosti a tím udržet situaci pod kontrolou.

V extrémním programování je plánování nedílnou součástí vývoje a s tím, že plány se mohou měnit, se počítá od samého začátku. Opěrným bodem, technikou, která vám umožní předvídat situaci a bezbolestně se smířit se změnami, je plánovací hra. Během takové hry lze rychle shromáždit, posoudit a naplánovat známé systémové požadavky podle priority.

Jako každá jiná hra má plánování své účastníky a svůj cíl. Klíčovou postavou je samozřejmě zákazník. Je to on, kdo sděluje potřebu té či oné funkcionality. Programátoři poskytují přibližné hodnocení každé funkce. Krása plánovací hry spočívá v jednotě účelu a solidaritě mezi vývojářem a zákazníkem: v případě vítězství všichni vyhrají, v případě porážky všichni prohrají. Ale zároveň jde každý účastník svou cestou k vítězství: zákazník vybírá nejdůležitější úkoly v souladu s rozpočtem a programátor hodnotí úkoly v souladu s jeho schopnostmi je realizovat.

Extrémní programování předpokládá, že vývojáři jsou schopni sami rozhodnout, jak dlouho jim splnění úkolů potrvá a kdo z nich by byl ochotnější řešit jeden problém a kdo jiný.

V ideální situaci by se plánovací hra mezi zákazníkem a programátorem měla hrát každých 3-6 týdnů, dokud nezačne další vývojová iterace. Díky tomu je poměrně snadné provádět úpravy na základě úspěchů a neúspěchů předchozí iterace.

4. Výhody a nevýhody

Výhody XP, pokud je lze implementovat, jsou větší flexibilita, schopnost rychle a přesně provádět změny v softwaru v reakci na měnící se požadavky a individuální přání zákazníků, vysoká kvalita výsledného kódu a absence nutnosti přesvědčit zákazníky, že výsledek splňuje jejich očekávání.

Nevýhodou tohoto přístupu je neproveditelnost dostatečně velkých a komplexních projektů v tomto stylu, nemožnost naplánovat načasování a složitost projektu na dostatečně dlouhou dobu a jednoznačně předvídat výsledky dlouhodobého projektu z hlediska poměru. kvality výsledku a nákladů na čas a zdroje. Lze také poznamenat, že XP není vhodný pro případy, kdy možná řešení nejsou okamžitě nalezena na základě dříve získaných zkušeností, ale vyžadují předběžný výzkum.

5. Historie používání

XP jako soubor popsaných technik byl poprvé použit při práci na projektu C3 (Chrysler Comprehensive Compensation System, vývoj systému pro účtování zaměstnaneckých výhod ve společnosti Daimler Chrysler). Z 20 účastníků tohoto projektu 5 (včetně výše zmíněných 3 hlavních autorů XP) publikovalo 3 knihy a obrovské množství článků věnovaných XP během samotného projektu i následně. Následující údaje ilustrují problémy s některými technikami XP při aplikaci na poměrně složité projekty.

Projekt byl zahájen v lednu 1995. Od března 1996, po zahrnutí Kenta Becka, běží pomocí XP. V této době již přesáhl rozpočet a plány na postupnou implementaci funkcí. Vývojový tým byl přerušen a asi šest měsíců poté se projekt vyvíjel docela úspěšně. V srpnu 1998 se objevil prototyp, který mohl sloužit asi 10 000 zaměstnanců. Původně se předpokládalo, že projekt bude dokončen v polovině roku 1999 a výsledný software bude sloužit ke správě benefitů pro 87 000 zaměstnanců společnosti. To bylo zastaveno v únoru 2000 po 4 letech běhu XP kvůli úplnému nedodržení časového rámce a rozpočtu. Vytvořený software nebyl nikdy použit pro práci s daty o více než 10 000 zaměstnancích, i když se ukázalo, že zvládne data o 30 000 zaměstnancích společnosti. Osoba, která hrála roli zákazníka zařazeného do projektového týmu, po několika měsících takové práce odešla, nebyla schopna vydržet pracovní zátěž a do konce projektu nikdy nedostala adekvátní náhradu.

Závěr

Všechny výše uvedené metody nejsou spojeny náhodou. Jejich důsledná kombinace může uvést vývojový proces do intelektuální rezonance, výrazně zvýšit kvalitu produktu a urychlit dobu jeho vydání. Hlavní krásou všeho extrémního programování je předvídatelnost a minimalizace nákladů na vývoj; poskytnout zákazníkovi produkt, který si přeje obdržet v době vydání; a samozřejmě komunikace a školení vývojářů přímo na pracovišti.

Názory na navrhovanou metodiku se mohou lišit. Je důležité pochopit, že extrémní programování nemá za cíl nahradit stávající vývojové technologie. Naopak, XP mohou poskytnout další impuls týmům využívajícím tradiční přístupy. Zde byste neměli hledat odpovědi na všechny své otázky. Nejedná se o programovací technologii, ale spíše o technologii pro organizaci práce a právě v této podobě má právo na život.

Publikováno na Allbest.ru

Podobné dokumenty

Analýza fází a vlastností vývoje optimálního a funkčního modelu ARIS - softwarového produktu společnosti IDS Scheer pro modelování podnikových procesů společnosti. Studium základních pojmů, metodologií a přístupů extrémního programování.

test, přidáno 06.04.2011


Hlavní fáze vývoje softwaru (softwarový balík), analýza systémových požadavků. Metoda detailování krok za krokem. Programovací jazyky nízká úroveň a vysoká úroveň (imperativní, objektově orientovaná, funkční, logická).

prezentace, přidáno 13.10.2013


Vývojový jazyk, implementační prostředí, vývojové nástroje. Vlastnosti virtuálního prostředí pro implementaci programu a jejich zohlednění při vývoji softwarového produktu. Systémová makra a jejich použití ve vývojových textech. Vizuální programovací nástroje.

návod, přidáno 26.10.2013


Problém spolehlivosti softwaru, jeho indikátory a podpůrné faktory. Metody sledování procesu vývoje programů a dokumentace, prevence chyb. Etapy procesu ladění softwaru, techniky strukturovaného programování a princip modularity.

prezentace, přidáno 30.04.2014


Strojové kódy a assembler. První programovací jazyky na vysoké úrovni. programovací jazyk FORTRAN. Výhody a nevýhody ALGOL. Vědecké a účetní programy. Základní principy, které byly dodrženy při tvorbě programovacího jazyka Basic.

práce v kurzu, přidáno 21.06.2014


Pojem a klíčový rozdíl vývoje distribuovaného softwaru, jeho výhody a nevýhody. Koncepční řešení a volba typu zástavby. Vlastnosti softwaru s otevřeným zdrojovým kódem. Myšlenka a vývoj Open Source.

práce v kurzu, přidáno 14.12.2012


Koncept životního cyklu softwaru. Rozlišují se dva druhy činností technické projekty: design a výroba. Hlavní principy manifestu stoupenců flexibilních metodologií. Základní principy extrémní programování.

prezentace, přidáno 14.08.2013


Mezinárodní standard pro programovací jazyk Pascal. Techniky objektově orientovaného programování v Turbo Pascalu. Symboly jazyka, jeho abeceda. Etapy vývoje programu. Pojem algoritmy a algoritmizace. Struktura programů v Pascalu.

práce v kurzu, přidáno 28.02.2010


Moderní nástroje pro vývoj softwaru pro řídicí systémy. Univerzální programovací jazyky a jejich srovnání se SCADA systémy. Vývoj softwaru pomocí vícekanálových měřicích převodníků Ш9327.

práce, přidáno 13.07.2011


Základní techniky pro práci v prostředí Programování v Delphi. Vlastnosti technologie pro vytváření jednoduchých aplikací. Práce s komponentami vývojového prostředí aplikací. Vstup, editace, výběr a výstup informací. Aspekty použití větvené struktury.

Snad každý designér či analytik se alespoň jednou v životě setkal se zákazníkem, který se snažil získat svůj projekt co nejlevněji a navíc v co nejkratším čase. Ale pokud jsou náklady na projekt velmi reálným předmětem vyjednávání, pak je vyjednávání o úpravě termínů dodání projektu mnohem obtížnější. Netrpělivých zákazníků je dnes stále více, což lze vysvětlit stavem moderního dynamického trhu, klesající mírou důvěry mezi interprety a zákazníky a chováním investorů, jejichž apetit přichází při jídle (pokud existuje více či méně fungující verze produktu, peníze na další vývoj dávají mnohem ochotněji) atd. V tomto ohledu se klasické vývojové metodiky (ve kterých dlouhý cyklus vlastního návrhu a sběru informací, kdy klient investuje nemalé finanční prostředky, ale po poměrně dlouhou dobu nedostává reálných výsledků) dostávají do velmi přísného rozporu se zájmy netrpělivý zákazník. To vše dalo impuls k vývoji alternativních metodologií designu ve dvou hlavních směrech: zvýšení důvěry zákazníků poskytnutím skutečných důkazů o úspěšně se rozvíjejícím vývojovém procesu a výrazné zkrácení doby vývoje produktu. Skupina těchto metodologií se nazývá „aktivní programování“.

Zrychlený a kolaborativní vývoj aplikací

Koncoví uživatelé a management zákazníků se obvykle domnívají, že proces návrhu selhal, pokud nejsou k dispozici skutečné běžné komponenty. Zákazník často trvá na provedení fáze realizace projektu v předstihu, aby získal konkrétní výsledek a co nejrychleji jej předvedl. V tomto případě je velmi lákavé zvolit Accelerated Application Development (AAD) nebo Collaborative Application Development (CAD). Tyto metody zahrnují vývoj funkčního prototypu a jeho následné předvedení uživatelům, kteří si všimnou, co se jim líbí a co ne. Poté návrhář prototyp zdokonalí s ohledem na vznesené připomínky a znovu předvede, co se stalo. Proces se opakuje, dokud uživatelé nejsou spokojeni s tím, co vidí, a z prototypu se nestane funkční aplikace. Obvykle je stanoven časový limit a počet iterací, jinak budou uživatelé donekonečna vyžadovat nová vylepšení prototypu. Teoreticky to umožňuje získat přesně ten systém, který uživatelé potřebují.

Zde tedy vidíme iterativní vývojový model s velmi krátkými spirálovými cykly v obou případech. V obou metodách se zkracuje čas strávený na počátečních fázích návrhu: strategie (buď zcela vynechána nebo sloučena s analýzou), analýza (ve většině případů omezená na počáteční výběr informací a analýzu formulářů - zpravidla zprávy, které se používají k obnově struktury funkcí systému), design (zaměřený na co nejrychlejší získání primárního prototypu). Výsledkem vývoje je prototyp, který je následně podroben průmyslové realizaci. V tomto případě je testování prováděno za aktivní účasti zákazníka, nebo se zákazník stává testerem (v lepším případě beta testerem).

V praxi je tento přístup k vývoji aplikací spojen s následujícími problémy:

Veškerá pozornost je soustředěna na obrazovkové formuláře a vše, co souvisí s pravidly zpracování dat a systémovými funkcemi, zůstává v pozadí. Je zde pokušení začít pracovat s reporty, přičemž report není výchozí produkt, ale odvozený produkt informačního systému.

Uživatelé předpokládají, že pokud je odsouhlasena verze prototypu, pak je modul připraven. Ve skutečnosti to může být jen obrázek se sadou „pahýlů“ pro volání funkcí systému a interakci s ostatními moduly.

Moduly jsou navrženy odděleně od sebe. Důsledkem toho jsou rozpory mezi moduly, duplikace funkcí a dat, které lze identifikovat pouze testováním sady modulů.

Funkčnost jsou rozšiřovány paralelně v několika směrech, takže struktura datového skladu musí být řízena. S URP návrh databáze připomíná vrakoviště, kde jsou tabulky ve spěchu shazovány dohromady a výsledkem je soubor protichůdných a duplicitních dat.

Dokumentace při použití metody URP obvykle chybí ze dvou důvodů: není dostatek času a vzniká iluze, že uživatel je schopen pochopit podstatu toho, co se děje, bez dokumentů. Když aplikace začne fungovat jinak, než uživatel očekával, nastanou problémy.

Způsob, jakým jsou výjimky zpracovávány, se pro různé moduly liší.

Vyvstává problém integrace modulů: zpravidla nefunguje kompletní systém, protože byl původně navržen jako soubor komponent, které byly následně narychlo propojeny.

Kontrola kvality produktu se dostává do přísného rozporu s načasováním vývoje projektu, v důsledku čehož se fáze testování a implementace další verze produktu prakticky spojují a jsou přeneseny přímo na testovací místo zákazníka. Je jasné, co se v tomto případě stane zákazníkovi, který je krajně nespokojený s kvalitou produktu; jinými slovy, špinavé prádlo se pere na veřejnosti v naprosto nesprávnou dobu.

Nabízí se otázka: lze takové problémy vyřešit a jak? Koneckonců, opravdu chcete získat projekt co nejrychleji! Extrémní programování (eXtreme Programming, XP) lze do jisté míry považovat za evoluci a možná i revoluci na poli mladších metodik aktivního programování. Zda je tato metodika vhodná právě pro váš vývojový tým, je na vás a pouze na vás, protože například ne každý je nadšený extrémními sporty.

Extrémní programování

XP principy a metody používané k urychlení vývoje

Kent Beck je považován za otce-ideologa extrémního programování. XP je poměrně mladá metodika, jejíž hodnocení jsou velmi rozporuplná - od nadšených po ostře negativní. Hlavní zásady jsou:

Jednoduchost řešení.

Intenzivní rozvoj v malých skupinách (ne více než 10 osob), aktivní komunikace ve skupině i mezi skupinami (komunikace).

Zpětná vazba od klienta, který je skutečně zapojen do procesu vývoje.

Dostatečná míra odvahy a ochoty riskovat.

Prvním faktorem urychlení vývoje je iterativnost: vývoj probíhá v krátkých iteracích s aktivním vztahem se zákazníkem. XP je iterativní vývojový proces, který sám o sobě není revoluční. Navrhuje se, aby iterace jako takové byly krátké, doporučená doba trvání je 2-3 týdny a ne více než 1 měsíc. V jedné iteraci je zapotřebí skupina programátorů k implementaci několika vlastností systému, z nichž každá je popsána v uživatelském příběhu. Uživatelské příběhy jsou v tomto případě prvotní informací, na základě které je modul vytvořen. Uživatelské příběhy se liší od případů použití: příběh uživatele je krátký – 1–2 odstavce, zatímco případy použití jsou obvykle psány poměrně podrobně, s hlavním a alternativním tokem – výsledkem je tedy přibližně stránka plus diagram (nejběžnější formalizace je aktuálně navržený v UML); Uživatelské příběhy píší samotní uživatelé (kteří jsou v XP součástí týmu), na rozdíl od případů použití, které obvykle píší systémový analytik. Nedostatečnou formalizaci popisu vstupních dat projektu v XP se snaží kompenzovat aktivním zapojením zákazníka do procesu vývoje jako plnohodnotného člena týmu a neustálým kontaktem se zákazníkem (aktivní komunikace a nepřetržitá podpora zpětné vazby ). Extrémní je v tomto případě míra zapojení zákazníka do programování kuchyně, což je způsobeno snahou zkrátit dobu vývoje komunikací a zpětnou vazbou.

Druhým faktorem urychlujícím vývoj produktu je přítomnost malých skupin a párového programování (kdy dva programátoři společně vytvářejí kód na jednom společném pracovišti). To vše je zaměřeno na dosažení vysoké úrovně komunikace ve skupině a také na co nejrychlejší odhalování problémů (jak chyb, tak zmeškaných termínů). Párové programování má za cíl stabilizovat projekt, protože s touto metodikou existuje vysoké riziko ztráty kódu v důsledku odchodu programátora, který nevydržel náročný pracovní rozvrh. V tomto případě hraje druhý programátor z dvojice roli „nástupce“ kódu (který je u klasických metod implementován v technické dokumentaci). Důležité také je, jak přesně jsou skupiny v pracovním prostoru rozmístěny – XP používá otevřený pracovní prostor, který předpokládá rychlý a bezplatný přístup pro každého ke všem; Pracovní prostor je obvykle postaven kolem kruhu.

Třetím faktorem urychlujícím vývoj procesů je vytvoření prvního nejjednoduššího funkčního řešení. Extrémnost metody je v tomto případě spojena s vysokou mírou rozhodovacího rizika kvůli povrchnosti analýzy a napjatému časovému harmonogramu. Realizováno minimální sada hlavní funkce systému při první a každé další iteraci; funkčnost se rozšiřuje s každou iterací.

Cvičení

XP je obvykle charakterizováno souborem 12 akcí (cvičení), které je nutné provést, aby bylo dosaženo dobrý výsledek. Postupy XP nedefinují samotný proces XP, ale XP tyto postupy definují – to znamená, že provádění postupů nezaručuje výsledky. Žádná z praktik není zásadně nová, ale XP je spojuje.

Procesní plánování (plánovací hra). Celý tým se sejde a kolektivně se rozhodne, jaké vlastnosti systému budou implementovány v další iteraci. Sada vlastností je určena uživatelskými příběhy. Složitost XP každé vlastnosti určují sami programátoři.

Úzká interakce se zákazníkem (zpětná vazba, zákazník na místě). Zákazník musí být členem týmu XP (zákazník na místě). Píše uživatelské příběhy, vybírá příběhy, které budou implementovány v konkrétní iteraci, a odpovídá na otázky související s podnikáním. Zákazník musí být odborníkem v oblasti automatizace. Je potřeba mít neustále zpětnou vazbu od zákazníka (feed-back).

Systémová metafora. Dobrá metafora systému znamená jednoduché pojmenování tříd a proměnných. V reálný život hledání metafory je nesmírně obtížný úkol; najít dobrou metaforu není snadné. V každém případě musí mít tým jednotná pravidla pojmenování.

Jednoduchá architektura (jednoduchý design). Jakákoli vlastnost systému by měla být implementována co nejjednodušeji. Programátoři v týmu XP pracují pod heslem: "Nic nadbytečného!" Je přijato první nejjednodušší pracovní řešení, na kterém je implementována požadovaná úroveň funkčnosti tento moment. To šetří čas programátora.

Kódovací konvence. Standardy kódování jsou potřebné pro podporu dalších postupů: sdílené vlastnictví kódu, párové programování a refaktoring. Bez jednotného standardu je přinejmenším obtížnější tyto praktiky provádět a ve skutečnosti zcela nemožné: skupina bude pracovat v neustálém nedostatku času. Nejsou vyžadovány podrobné normy, pouze důležité věci je třeba standardizovat. Určení nejdůležitějších objektů standardizace v XP je subjektivní.

Refaktorování. Refaktoring je optimalizace existující kód směrem ke zjednodušení, což obnáší neustálou práci na zjednodušení kódu. Tím, že je kód transparentní a prvky kódu jsou definovány pouze jednou, programátoři snižují počet chyb, které musí později opravovat. Při implementaci každé nové funkce systému musí programátor zvážit, zda je možné zjednodušit stávající kód a jak to pomůže implementaci nové funkce. Navíc refaktoring nelze kombinovat s designem: pokud se vytváří nový kód, refaktoring musí být odložen.

Párové programování je jednou z nejznámějších XP praktik. Všichni programátoři musí pracovat ve dvojicích: jeden píše kód, druhý hlídá. Je tedy nutné umístit skupinu programátorů na jedno místo, což je nejjednodušší provést v prostorách zákazníka (všichni potřební členové týmu jsou geograficky umístěni na jednom místě); XP funguje nejúspěšněji v nedistribuovaných týmech programátorů a uživatelů.

40 hodinový pracovní týden. Programátor by neměl pracovat více než 8 hodin denně. Potřeba přesčasů je jasným indikátorem problému v této konkrétní oblasti rozvoje; Navíc zákazník neplatí za práci přesčas v XP. Najít důvody přesčasové práce a co nejrychleji je odstranit je jedním ze základních pravidel.

Kolektivní vlastnictví kódu. Každý programátor v týmu XP by měl mít přístup ke kódu v jakékoli části systému a provádět změny v jakémkoli kódu. Povinné pravidlo: pokud programátor provede změny a systém poté nefunguje správně, pak je to tento programátor, kdo musí opravit chyby. Jinak bude chod systému připomínat totální chaos.

Časté změny verzí (malé verze). Minimální opakování je jeden den, maximum je měsíc; Čím častěji jsou vydávána, tím více systémových chyb bude identifikováno. První verze pomáhají identifikovat nedostatky v nejranějších fázích, poté je funkčnost systému rozšířena (na základě stejných uživatelských příběhů). Vzhledem k tomu, že uživatel je zapojen do procesu vývoje od prvního vydání, vyhodnotí systém a poskytne uživatelský příběh a zpětnou vazbu. Na základě toho se určí další iterace: jaké bude nové vydání. XP je o poskytování neustálé zpětné vazby uživatelům.

Průběžná integrace. K integraci nových částí systému by mělo docházet co nejčastěji, alespoň jednou za několik hodin. Základní pravidlo integrace je následující: integraci lze provést, pokud všechny testy projdou úspěšně. Pokud testy selžou, musí programátor buď provést opravy a poté integrovat komponenty systému, nebo je neintegrovat vůbec. Toto pravidlo je přísné a jednoznačné – pokud je ve vytvořené části systému alespoň jedna chyba, pak integraci nelze provést. Častá integrace vám umožní získat hotový systém rychleji, místo abyste strávili týden montáží.

Testování Na rozdíl od většiny ostatních metodik je testování v XP jednou z nejdůležitějších součástí. Extrémní přístup je psát testy před psaním kódu. Každý modul musí mít unit test - test tohoto modulu; V XP se tedy provádí regresní testování (testování návratnosti, „nezhoršení kvality“ při přidávání funkčnosti). Většina chyb je opravena ve fázi kódování. Testy píší sami programátoři; každý programátor má právo napsat test pro jakýkoli modul. Další důležitý princip: test určuje kód a ne naopak (tento přístup se nazývá vývoj řízený testem), to znamená, že část kódu je uložena do úložiště tehdy a pouze tehdy, pokud všechny testy projdou úspěšně, jinak je tato změna kódu odmítl.

XP tedy extrémně odmítá všechny artefakty vývojového procesu, kromě zdrojového kódu. Proces XP je vysoce neformální, ale vyžaduje vysokou úroveň sebekázně. Pokud toto pravidlo není dodrženo, XP se okamžitě promění v chaotický a nekontrolovatelný proces. XP nevyžaduje, aby programátoři psali mnoho zpráv a sestavovali mnoho modelů. V XP je každý programátor považován za kvalifikovaného pracovníka, který své povinnosti bere profesionálně a s velkou zodpovědností. Pokud to tým nemá, pak je zavádění XP naprosto zbytečné – je lepší nejprve začít tým přestavovat. Riziko vývoje je sníženo pouze v týmu, pro který je XP ideální; ve všech ostatních případech je XP vývojovým procesem s nejvyšší mírou rizika, protože prostě neexistují žádné jiné metody pro snížení komerčních rizik, kromě banálního lidského faktoru. , v XP.

Existující rizika používání metodiky

Stojí za to zdůraznit rizika XP, která mohou selhat v projektu, pokud nejsou zohledněna a není jim zabráněno.

Plánovací hra. Programátoři implementují pouze ty funkce, které jsou nezbytné pro vlastnosti vybrané zákazníkem v dané iteraci. V důsledku tohoto rozhodnutí zůstává vývoj systému v zákulisí, v důsledku čehož je během vývoje potřeba stavět „pahýly“ a přepisovat kód.

Neustálá účast zákazníka (zákazník na místě). Po dobu práce na systému je zástupce zákazníka ve vývojovém týmu a požadavky na kvalifikaci tohoto člověka nebo týmu jsou velmi vysoké. Pokud zákazník nesouhlasí s poskytnutím personálu na odborné úrovni, pak projekt spadá do skupiny s nejvyšším rizikem.

Metafora. Obecná forma systém je definován pomocí metafory nebo sady metafor, na kterých zákazník a programátoři pracují společně. Pokud proces není zaprotokolován a struktura pojmenování není standardizovaná, proces se může stát nekonečně iterativní.

Jednoduchá architektura (jednoduchý design). V každém okamžiku vyvinutý systém provádí všechny testy a podporuje všechny vztahy definované programátorem, nemá žádné duplicitní kódy a obsahuje minimální možný počet tříd a metod. Toto pravidlo lze stručně vyjádřit takto: „Každou myšlenku formulujte jednou a jen jednou“. Tento princip je v rozporu s rychlostí zápisu kódu. Bez vysoké sebekázně a přísných standardů kódu se systém okamžitě stává ohroženým.

Časté změny verzí (malé verze). Systém je uveden do provozu během několika měsíců po zahájení implementace, aniž by se čekalo na konečné vyřešení všech nastolených problémů. Frekvence vydávání nových verzí se může lišit od denní po měsíční. V takovém období není možné testovat více či méně složitou součást; zákazník ve skutečnosti funguje jako beta tester. Ohroženy jsou systémy, které vyžadují nepřetržitý spolehlivý provoz (tzv. požadavek 24/7).

Refaktoring systému. Architektura systému se neustále vyvíjí. Současný projekt je transformován, přičemž je zajištěno správné provedení všech testů. Extrémní programování vychází ze skutečnosti, že vždy je možné předělat část systému i bez něj zvláštní náklady. Praxe však často ukazuje opak.

Průběžná integrace. Nový kód je integrován do stávajícího systému během několika hodin. Poté se systém znovu sestaví do jednoho celku a proběhnou všechny testy. Pokud alespoň jedna z nich není provedena správně, provedené změny se zruší. V tomto případě není vždy jasné, kdo přesně bude opravovat chyby, nejen lokální, ale i ty způsobené nesprávným kódem. V této fázi se neplánuje provádět složité testy; Kromě toho se změny uloží, i když je zjištěna chyba.

Párové programování. Veškerý kód projektu je napsán skupinami dvou lidí pomocí jednoho pracoviště. Rozhodující roli v tomto případě hraje lidský faktor: pár buď funguje, nebo ne, třetí možnost neexistuje.

40hodinové týdny. Objem přesčasové práce nesmí přesáhnout dobu trvání jednoho pracovního týdne. I ojedinělé případy přesčasů, které se vyskytují příliš často, jsou známkou vážných problémů, které vyžadují okamžitou pozornost. Jak ukazuje praxe používání extrémního programování (navzdory řadě pozitivních příkladů poskytnutých příznivci tato metoda), přesčasy u tohoto přístupu jsou pravidlem, nikoli výjimkou, a boj s problémy je v tomto případě neustálým jevem. Zintenzivňuje se v období výměny současné surové verze produktu za jinou – méně surovou. Pokud zákazník neobdrží konzistentní důkazy o zlepšení systému, pak máte vážný problém.

Kolektivní vlastnictví. Každý programátor má možnost v případě potřeby kdykoliv vylepšit jakoukoliv část kódu v systému. Bez standardu kontroly zdrojového kódu se proces vývoje stává zcela nekontrolovatelným.

Otevřete pracovní prostor. Vývojový tým se nachází ve velké místnosti obklopené menšími místnostmi. Uprostřed pracovního prostoru jsou instalovány počítače, na kterých pracují dvojice programátorů (a v souladu s výše uvedenými zásadami by to vše mělo být umístěno v prostorách zákazníka, protože je velmi aktivně zapojen do procesu vývoje). Pokud existuje geograficky distribuovaná skupina vývojářů a zákazníků, projekt vyžaduje standardizaci protokolu interakce (rychlý, spolehlivý, bezproblémový) nebo spadá do rizikové skupiny.

Testy. Programátoři neustále píší unit testy. Dohromady by tyto testy měly fungovat správně. Pro iterační fáze zákazníci píší funkční testy, které musí také správně fungovat. V praxi to však není vždy dosažitelné. Abyste se mohli správně rozhodnout, musíte pochopit, kolik bude stát dodání systému se známou vadou, a porovnat to s náklady na oddálení jeho odstranění. Testy psané samotnými programátory (zejména při práci přesčas) nejsou plně funkční a rozhodně nezohledňují zvláštnosti víceuživatelské práce. Vývojáři obvykle nemají dostatek času na pokročilejší testy. Tento problém se řeší používáním stykačů po určitou dobu, což je spojeno s velkou rolí lidského faktoru: od r. technická dokumentace zpočátku chybí, pak jsou informace přenášeny prostřednictvím komunikace mezi programátory. I když je samozřejmě možné postavit vývojový systém tak, že se vším budou od začátku do konce řešit stejní lidé. K výše uvedenému je nutné dodat, že testování systému není omezeno na testování komponent (jednotek); Neméně důležité jsou i testy interakce mezi nimi a totéž platí pro testy spolehlivosti. Metoda extrémního programování však nezahrnuje vytváření testů. této třídy. To je vysvětleno tím, že takové testy samy o sobě mohou představovat poměrně složitý kód (to platí zejména pro testy, které napodobují skutečný provoz systému). Tato technologie také nezohledňuje další důležitou třídu testů – testy chování systému při nárůstu objemu zpracovávaných informací. Při vysoké frekvenci změn verzí je technologicky nemožné takový test provést, protože jeho implementace vyžaduje stabilní a nezměněný kód projektu například do týdne. V takovém případě budete muset vývoj komponent buď pozastavit, nebo během testu vytvořit paralelní verzi projektu, která zůstane nezměněna, zatímco druhá se změní. Poté budete muset projít procesem sloučení kódu. V tomto případě však bude muset být test vytvořen znovu, protože extrémní programovací metody jednoduše neumožňují vývoj nástrojů, které umožňují předvídat chování systému za určitých změn. XP navrhuje řešit tyto problémy pomocí stejného lidského faktoru a sebekázně.

Nic víc než jen pravidla. Členové týmu pracující pomocí technologie extrémního programování se zavazují dodržovat uvedená pravidla. Nejde však o nic jiného než o pravidla a tým je může kdykoli změnit, pokud se jeho členové v zásadě dohodnou na provedených změnách. Tento princip je silně závislý na lidském faktoru; Porušení vývojové disciplíny má za následek zmeškání termínů a v důsledku vede ke kolapsu projektu.

Dostáváme tak metodu, která je potenciálně vysoce adaptabilní na vážně a často se měnící požadavky projektu, ale zároveň není prosta řady zásadních nedostatků a je značně závislá na lidském faktoru.

Výsledek použití metody extrémního programování tedy může být extrémně dobrý nebo extrémně špatný.

Extreme Programming nebo XP, eXtreme Programming je flexibilní metodika vývoje softwaru. Stejně jako ostatní agilní metodiky má specifické nástroje, procesy a role. Autor XP sice nepřišel s ničím novým, ale vzal osvědčené postupy agilního vývoje a posílil je na maximum. Proto se programování nazývá extrémní.

Autorem metody je americký vývojář Kent Beck. Na konci 90. let vedl projekt Chrysler Comprehensive Compensation System a zde se stal průkopníkem praxe extrémního programování. Své zkušenosti a koncept, který vytvořil, popsal v knize Extreme Programming Explained, vydané v roce 1999. Po něm následovaly další knihy podrobně popisující postupy XP. Na vývoji metodiky se podíleli také Ward Cunningham, Martin Fowler a další.

XP se od ostatních agilních metodik liší tím, že platí pouze v oblasti vývoje softwaru. Nemůže být použit v jiném podnikání nebo každodenním životě, jako je scrum, kanban nebo lean.

Cílem metodiky XP je vyrovnat se s neustále se měnícími požadavky na softwarový produkt a zlepšit kvalitu vývoje. Proto se XP dobře hodí pro složité a nejisté projekty

Metodika XP je postavena na čtyřech procesech: kódování, testování, návrh a naslouchání. Kromě toho má extrémní programování hodnoty jednoduchosti, komunikace, zpětné vazby, odvahy a respektu.

1. Celý tým

Všichni účastníci projektu používající XP pracují jako jeden tým. Musí obsahovat zástupce zákazníka, je lepší, když je skutečný koncový uživatel produkt, obchodní důvtip. Zákazník klade požadavky na produkt a upřednostňuje implementaci funkčnosti. Pomoci mu mohou obchodní analytici. Na straně realizace tým zahrnuje vývojáře a testery, někdy kouče, který tým vede, a manažera, který týmu poskytuje zdroje.

2. Plánovací hra

Plánování v XP probíhá ve dvou fázích – plánování vydání a plánování iterací.

Při plánování vydání se sejde programátorský tým se zákazníkem, aby zjistil, jakou funkcionalitu chce získat pro další vydání, tedy za 2-6 měsíců. Protože požadavky zákazníků jsou často vágní, vývojáři je specifikují a rozdělují na části, jejichž realizace netrvá déle než jeden den. Je důležité, aby zákazník rozuměl provoznímu prostředí, ve kterém bude produkt fungovat.

Úkoly se zapisují na kartičky a zákazník si určuje jejich prioritu. Dále vývojáři odhadují, kolik času bude každý úkol trvat. Když jsou úkoly popsány a vyhodnoceny, zákazník zkontroluje dokumentaci a dá souhlas k zahájení práce. Pro úspěch projektu je klíčové, aby zákazník a programátorský tým hráli na stejném poli: zákazník si v rámci rozpočtu vybere funkcionalitu, která je skutečně potřebná, a programátoři adekvátně porovnávají požadavky zákazníka se svými schopnostmi.

V XP, pokud tým nestihne dokončit všechny úkoly k datu vydání, vydání není odsunuto, ale je odstraněna část funkčnosti, která je pro zákazníka nejméně důležitá.

Provádí se iterační plánování každé dva týdny, někdy více či méně často. Zákazník je vždy přítomen: určuje funkčnost pro další iteraci a provádí změny požadavků na produkt.

3. Časté vydávání verzí

V XP jsou verze vydávány často, ale s malou funkčností. Za prvé, malé množství funkcí lze snadno testovat a udržovat funkčnost celého systému. Za druhé, při každé iteraci zákazník obdrží část funkce, která nese obchodní hodnotu.

4. Uživatelské testy

Zákazník sám definuje automatizované akceptační testy pro kontrolu funkčnosti další funkce produktu. Tým píše tyto testy a používá je k testování hotového kódu.

5. Kolektivní vlastnictví kódu

V XP může každý vývojář upravovat jakýkoli kus kódu, protože... Kód není přiřazen svému autorovi. Celý tým vlastní kód.

6. Průběžná integrace kódu

To znamená, že nové části kódu jsou okamžitě zabudovány do systému – týmy XP nahrávají nové sestavení každých pár hodin nebo častěji. Za prvé je hned jasné jak poslední změny ovlivnit systém. Pokud nový kus kódu něco pokazí, pak je nalezení a oprava chyby mnohem jednodušší než o týden později. Za druhé, tým vždy spolupracuje Nejnovější verze systémy.

7. Kódovací standardy

Když každý vlastní kód, je důležité přijmout konzistentní standardy návrhu, aby kód vypadal, jako by byl napsán jedním profesionálem. Můžete vyvinout své vlastní standardy nebo přijmout již hotové.

8. Systémová metafora

Metafora systému je přirovnáním systému k něčemu známému, aby se vytvořila sdílená vize mezi týmem. Metaforu systému obvykle vymýšlí ten, kdo architekturu navrhuje a představuje si systém jako celek.

9. Rovnoměrné tempo

Týmy XP pracují s maximální produktivitou a zároveň si udržují stabilní tempo. Extrémní programování má zároveň negativní postoj k přesčasům a prosazuje 40hodinový pracovní týden.

10. Testem řízený vývoj

Jedna z nejobtížnějších metod metodiky. V XP píší testy sami programátoři, PŘED napsáním kódu, který je potřeba otestovat. S tímto přístupem bude každý kus funkčnosti 100% pokryt testy. Když pár programátorů nahraje kód do úložiště, okamžitě se spustí testy jednotek. A VŠECHNY by měly fungovat. Pak budou mít vývojáři jistotu, že jdou správným směrem.

11. Párové programování

Představte si dva vývojáře u jednoho počítače, kteří pracují na jedné funkcionalitě produktu. Toto je párové programování, nejkontroverznější praxe XP. Staré přísloví „jedna hlava je dobrá, dvě jsou lepší“ dokonale ilustruje podstatu přístupu. Ze dvou možností řešení problému je vybrána ta nejlepší, kód je okamžitě optimalizován a chyby jsou zachyceny dříve, než k nim dojde. Výsledkem je čistý kód, ve kterém se dobře vyznají dva vývojáři.

12. Jednoduchý design

Jednoduchý design v XP znamená dělat pouze to, co nyní potřebujete, aniž byste se snažili odhadnout budoucí funkčnost. Jednoduchý design a průběžný refaktoring mají synergický efekt – když je kód jednoduchý, je snadné jej optimalizovat.

13. Refaktoring

Refaktoring je proces neustálého zlepšování návrhu systému tak, aby vyhovoval novým požadavkům. Refaktoring zahrnuje odstranění duplicitního kódu, zvýšení soudržnosti a snížení vazby. XP zahrnuje neustálé refaktorování, takže návrh kódu zůstává vždy jednoduchý.

Výhody a nevýhody XP

Metodika XP vyvolává mnoho kontroverzí a kritiky ze strany těch, kteří ji nikdy nebyli schopni implementovat ve svém týmu.

Výhody extrémního programování mají smysl, když tým plně využívá alespoň jednu z praxí XP. Co tedy stojí za to vyzkoušet:

• zákazník dostane přesně ten produkt, který potřebuje, i když si na začátku vývoje sám přesně nepředstavuje jeho finální podobu
• tým rychle provádí změny kódu a přidává nové funkce prostřednictvím jednoduchého návrhu kódu, častého plánování a vydávání
• kód vždy funguje díky neustálému testování a neustálé integraci
• tým snadno udržuje kód, protože je psána podle jednotné normy a neustále se refaktoruje
• rychlé tempo vývoje díky párovému programování, nedostatek přepracování, přítomnost zákazníka v týmu
• vysoká kvalita kódu
• rizika spojená s vývojem se snižují, protože odpovědnost za projekt je rozdělena rovnoměrně a odchod/příjezd člena týmu proces nezruinuje
• náklady na vývoj jsou nižší, protože tým je orientován na kód, nikoli na dokumentaci a schůzky

Přes všechny výhody XP ne vždy fungují a mají řadu slabin. Takže extrémní programování - nevýhody:

• úspěch projektu závisí na zapojení zákazníka, kterého není tak snadné dosáhnout
• Je těžké předvídat čas strávený na projektu, protože... na začátku nikdo neví úplný seznam požadavky
• Úspěch XP silně závisí na úrovni programátorů, metodika pracuje pouze se staršími specialisty
• management má negativní postoj k párovému programování, nechápe, proč by měl platit dva programátory místo jednoho
• Pravidelné schůzky s programátory jsou pro zákazníky drahé
• vyžaduje příliš mnoho kulturních změn
• kvůli nedostatku struktury a dokumentace není vhodný pro velké projekty
• protože Agilní metodiky jsou funkčně orientované, nefunkční požadavky na kvalitu produktu se těžko popisují formou uživatelských příběhů.

Principy XP

Kent Beck ve své první knize formuloval principy extrémního programování: jednoduchost, komunikaci, zpětnou vazbu a odvahu. V novém vydání knihy přidal pátou zásadu – respekt.

1. Jednoduchost

V XP začíná vývoj nejjednodušším řešením, které uspokojí aktuální potřebu funkčnosti. Členové týmu berou v úvahu pouze to, co je třeba udělat nyní, a nevkládají do kódu funkce, které budou potřeba zítra, za měsíc nebo nikdy.

2. Komunikace

V XP se komunikace mezi vývojáři neprovádí prostřednictvím dokumentace, ale živě. Tým aktivně komunikuje mezi sebou i se zákazníkem.

3. Zpětná vazba

Zpětná vazba v XP je implementována ve třech směrech najednou:

1. zpětnou vazbu ze systému při neustálém testování modulů
2. zpětná vazba od zákazníka, protože je součástí týmu a podílí se na psaní akceptačních testů
3. zpětnou vazbu od týmu během plánování ohledně doby vývoje.

4. Odvaha

Některé extrémní programovací techniky jsou tak neobvyklé, že vyžadují odvahu a neustálou sebekontrolu.

5. Respekt

V extrémním programování je respekt vnímán jako respekt k týmu a sebeúcta. Členové týmu by neměli nahrávat změny, které naruší kompilaci, testy jednotek nebo zpomalí práci kolegů. Každý o to usiluje nejvyšší kvalita kód a design.

Algoritmus pro implementaci metodiky XP a pracovního procesu

Beck Kent doporučuje implementovat XP k řešení problémů v projektu. Tým vybere nejpalčivější problém a vyřeší jej pomocí jedné z praktik extrémního programování. Poté se s větší praxí přesune k dalšímu problému. S tímto přístupem fungují problémy jako motivace pro používání XP a tým si postupně osvojuje všechny nástroje metodiky.

Chcete-li implementovat XP do existujícího projektu, musíte postupně zvládnout jeho techniky v následujících oblastech:

• testování
• design
• plánování
• řízení
• rozvoj

Testování.

Tým vytváří testy PŘED napsáním nového kódu a postupně přepracovává starý kód. U starého kódu se testy píší podle potřeby: když potřebujete přidat novou funkcionalitu, opravit chybu nebo přepracovat část starého kódu.

Design.

Tým postupně refaktoruje starý kód, obvykle před přidáním nové funkce. Stejně jako u testování se refaktoring starého kódu provádí pouze v případě potřeby. Zároveň by měl tým formulovat dlouhodobé cíle pro přepracování kódu a postupně jich dosahovat.

Plánování.

Tým musí přejít na úzkou interakci se zákazníkem. V této fázi je důležité zprostředkovat mu výhody práce ve stejném týmu s vývojáři a začlenit ho do týmu.

Řízení.

Úlohou manažerů při přechodu na XP je zajistit, aby všichni členové týmu pracovali podle nových pravidel. Projektový manažer rozhodne, kdy se rozejít s členem týmu, který nezvládá práci v novém prostředí, nebo najít nového a řádně ho začlenit do práce.

Rozvoj.

Transformace ve vývoji začínají organizací pracovních stanic pro programování ve dvojicích. Další výzvou je většinu času programovat ve dvojicích, bez ohledu na to, jak obtížné to pro vývojáře může být.

V projektu, který pracuje podle metodiky XP, je proces strukturován takto:

Kdo používá XP

Podle studie Versionone z roku 2016 pouze 1 % agilních společností používá extrémní programování v jeho čisté podobě. Dalších 10 % pracuje pomocí hybridního scrumu a metodiky XP.

Zajímavé je, že ačkoli XP není zdaleka nejběžnější metodikou ve své čisté podobě, její postupy používá většina společností pracujících na agilních metodologiích. Důkazem toho jsou údaje ze stejné studie:

Není snadné najít informace o týmech, které používají XP, ale jsou tací, kteří propagují, že tato metodika je důvodem jejich úspěchu. Příkladem extrémního programování je Pivotal Software, Inc.

Pivotal Software, Inc.

Americká softwarová společnost, která vyvíjí software pro obchodní analýzy založené na velká data a poskytuje poradenské služby. Pivotal produkty používají Ford, Mercedes, BMW, GAP, Humana, velké banky, vládní agentury, pojišťovny atd.

Pivotal je zastáncem agilních metodologií jako jediné možné v moderní vývoj. Ze všech možností flexibilních metodologií si společnost vybrala XP jako oboustranně výhodný přístup pro zákazníky a programátorské týmy. Každý pracovní den začíná schůzkou na cestách a končí přesně v 18:00 – žádné přesčasy. Pivotal využívá plánování her, párové programování, průběžné testování, průběžnou integraci a další postupy XP. Pro mnoho praxí mají svůj vlastní software.

extrémní programování,
Extrémní programování: plánování,
Extrémní programování: Testem řízený vývoj / Kent Beck

O extrémním programování od tvůrce metodiky Kenta Becka. Začněte tím prvním, který popisuje koncept XP s příklady a zdůvodňuje jeho výhody. Později autor vydal několik dalších knih, kde podrobně popsal jednotlivé XP praktiky.

Refaktoring: Zlepšení stávajícího kódu / Martin Fowler

Extrémní programování: formulace procesu. Od prvních kroků k hořkému konci / Ken Auer, Roy Miller

Protože Extreme Programming usiluje o čistý a snadno udržovatelný kód, seznam knih obsahuje všechny publikace, které vás naučí, jak lépe programovat.

Aplikace pro implementaci XP v týmu

Týmy pracující na projektech využívajících metodiku XP využívají správce úloh a služby pro agilní projekty. Takových produktů je na trhu mnoho, my se podíváme na pár příkladů.

Zdarma a open source správce úloh. Hlavní funkce: práce na více projektech najednou, flexibilní systém řízení úkolů, Ganttův diagram, kontrola času, práce s dokumentací, vytváření úkolů přes email atd.

Jednoduchá pohodlná služba pro spolupráce na projektech. Zahrnuje správce úloh, nástěnku, vestavěný chat, úložiště souborů, kalendář

Jira

Výkonná služba navržená speciálně pro vývojáře agilních projektů. Kombinuje nástroj pro sledování chyb a službu řízení projektů. Mnoho funkcí plus synchronizace s dalšími službami. Řešení pro týmy různých velikostí.

Pracovat na projektech. Umožňuje nastavovat úkoly a řídit proces provádění, korespondovat spolu na úkolu, nastavovat filtry, zohledňovat časovou a finanční náročnost a pracovat se soubory.

Výrok

Extreme Programming je flexibilní metodika, která se zaměřuje na vysoce kvalitní, funkční kód s jednoduchou architekturou. Jeho účelem je snížit míru nejistoty v projektech a skutečně pružně reagovat na změny požadavků na produkty.

Tato metodika je určena výhradně do terénu vývoj softwaru a nelze je přizpůsobit pro jiné podnikání.

Jedná se o jednu z nejobtížněji implementovatelných metodologií, protože zahrnuje až třináct postupů!

Jen málo společností riskuje práci na čistém XP, ale jeho vývojové postupy jsou nejoblíbenější v agilních projektech. A to je pádný argument ve prospěch jejich účinnosti.

Nikdo vás nenutí implementovat XP na principu všechno nebo nic. Na konci dne musí být agilní metodiky flexibilní ve své aplikaci – přizpůsobené potřebám konkrétního týmu a projektu.