Metodiky vývoje SW. Taxonomie metodik. Metodiky pro softwarový proces. Moderní strukturovaná analýza. Unifikovaný proces vývoje (UP) Klasické.

Transkript

1 Metodiky pro softwarový proces Metodiky vývoje SW Co to je softwarový proces umění, manufaktura, modelování? Proces vývoje software by se měl řídit nějakým doporučením sníží se tím pravděpodobnost chyb, opomenutí apod. Doporučení jsou obvykle shrnuta do metodiky (angl. methodology). Metodika je jen šablona, musíme ji přizpůsobit firmě, týmu, projektu, účelu (vývoj, provoz, přizpůsobení). Metodika předepisuje postup, jeho kroky a artefakty získané v těchto krocích. Skutečný proces vývoje pak využívá různé standardy, idiomy, předepsané formáty apod. 2 Taxonomie metodik Klasické Strukturované, objektové, komponentové Vodopád (MSA, SSADM) Unifikovaný proces (UP) RUP (Rational Unified Process) Agilní Testy řízený vývoj Extrémní programování (XP) Scrum AUP (Agile Unified Process) Moderní strukturovaná analýza Autoři E.Yourdon (analýza), M.Page-Jones (návrh). Sestavte aktéry a případy užití. Pro každý případ užití navrhněte funkci, která bude tento případ obsluhovat. Doplňte model o popis dat pro každou funkci vymysli vstupní a výstupní data. Proveďte generalizaci a dekompozici těchto funkcí. Generalizací dospějete k modelu jednání, dekompozicí k elementárním funkcím (minispecifikacím). Tento výstup analýzy podrob tzv. transformační analýze (založené na transakční analýze) a navrhni řešení. Transakční analýzou vyber podmnožinu, která se zabývá jednou transakcí. V této podmnožině hledej vstupní úpravy, vlastní zpracování a výstupní formátování dat. 3 4 act Moderní strukturov aná analýza (MSA) «centralbuffer» Hledání aktérů a případů Model jednání užití Návrh funkcí «centralbuffer» Model chování Doplnění dat Dekompzice Transakční analýza Transformační analýza Generalizace «centralbuffer» Datov ý model «centralbuffer» Logický model Unifikovaný proces vývoje (UP) UP je: Průmyslový standard kostry vývojového procesu Využívá notace UML (Unified Modeling Language) Je to otevřený standard (na rozdíl např. od RUP Rational Unified Process, dříve Rational, nyní IBM) Základem je publikace Jacobson, Booch, Rumbaugh: The Unified Software Development Process" UP je: Řízen požadavky a případy užití (use case driven) Řízen rizikem Staví na architektuře Iterativní a přírůstkový proces UP je: pouze generická metodika, musí být uzpůsobena pro danou firmu, projekt - standardy, šablony, nástroje, 5 6

2 Historie UP Prehistory Ericsson Approach Jacobson working at Ericsson Specification & Description Language Jacobson establishes Objectory AB Objectory Rational Approach Rational acquires Objectory AB Rational Objectory Process 1997 UML becomes an industry standard Rational Unified Process (RUP) 1998 Unified Software Development Process 1999 RUP Zdroj: Arlow, Neustadt: UML 2 a objektově orientovaný návrh. Ongoing RUP development 2004 Iterační a přírůstkový vývoj Iterace jsou základem UP Každá iterace je malý vodopád: Plánování Analýza a návrh Konstrukce, implementace Integrace a testování Uvolnění verze Celý produkt se tvoří řadou iterací, které představují přírůstky k řešení Iterace se mohou překrývat (paralelní vývoj) Iterace jsou rozděleny do fází, každá fáze může zahrnovat několik iterací, každá fáze končí milníkem 7 8 Fáze UP Kroky v rámci iterace Každá iterace může obsahovat základní kroky a další postupy, podle její polohy v životním cyklu. UP specifikuje 5 základních kroků Požadavky Analýza Návrh Implementace Testy Iterace Plánování Specifické postupy Odhady Zdroj: Jacobson, Booch, Rumbaugh: The Unified Process. 9 Další postupy 10 Požadavky a jejich metamodel Smyslem tohoto kroku je vytvořit přehledovou ( high-level ) specifikaci toho, co se má implementovat. Sháníme materiály, děláme interview se zainteresovanými osobami ( stakeholders ), abychom zjistili, co by od systému potřebovali jaké jsou jejich požadavky. Specifikace požadavků na software Katalog požadavků balík ikona kotvy Funkční požadavky Nefunkční požadavky P1 P3 Postup získávání požadavků act Postup tv orby specifikace požadav ků Hledání aktérů a případů Strukturov ání modelu užití případů užití Stanovení priorit Detailní popis případů užití Náv rh a prototypov ání interface Návrhář UI Popisovač případů Architekt Analytik Model jednání (Use case model) P2 případ užití (use case) aktér 11 12

3 A navíc act Postup tv orby specifikace požadav ků - 2 Správce požadavků Návrhář UI Popisovač případů Architekt Analytik Hledání aktérů a případů užití Stanovení priorit Náv rh a prototypov ání interface Detailní popis případů užití Náv rh funkčních požadav ků Strukturov ání modelu případů užití Mapov ání požadav ků na případy užití Stanovení priorit Náv rh nefunkčních požadav ků Pro správnou správu požadavků je třeba přidat aktivity související s návrhem funkčních a nefunkčních požadavků a jejich zapracováním do modelu Důležitost požadavků Zdroje chyb projektů Neúplná specifikace požadavků představuje primární zdroj možného neúspěchu projektu! The Standish Group, "The CHAOS Report (1994) " Neúplné požadavky Uživatel nebyl dostatečně zainteresován Nedostatek zdrojů Nerealistická očekávání Chybí podpora exekutivy Změny požadavků Nedostatek plánování Není dále zapotřebí Co to jsou požadavky? Jak požadavky zapisovat? Požadavky - Specifikace toho, co by mělo být implementováno : Jaké chování bude systém nabízet. Specifické vlastnosti systému. Jaká omezení je třeba brát v úvahu. V metodice UP se vytváří specifikace požadavků (Software Requirements Specification - SRS): Na počátku procesu konstrukce softwaru je dohoda o požadavcích mezi všemi zainteresovanými stranami. Katalog požadavků by měl být rozumně organizován do částí, které spolu souvisí. SRS obsahuje dvě části: Model požadavků, kam patří funkční a nefunkční požadavky. Model jednání (use case model), kam patří přehled aktérů a případů užití (use cases). <id> The <system> shall <function> Unikátní identifikátor Jméno systému keyword Požadavek Např. "32 Bankomat by měl validovat PIN." Není žádný obecný standard na psaní požadavků! Doporučuje se např. formát výše uvedený. Funkční požadavky co by měl systém dělat: Bankomat by měl poskytovat možnost identifikace zákazníka." Nefunkční požadavky omezení na způsob konstrukce a implementace: Bankomat by měl identifikaci zákazníka zvládnout vždy nejdéle za 4 sec." Modelování případů užití Součástí modelování a správy požadavků by mělo být i modelování případů užití. Modelování případů užití spočívá v hledání: hranice systému aktérů, případů užití (use cases) specifikace případů a scénářů, které se za nimi skrývají. To nám umožní definovat rozsah systému, kdo a na co jej má používat. Hledání aktérů a případů užití Doménový (business) model Model požadavků Seznam požadovaných vlastností Analytik Hledání aktérů a případů užití Hrubý model jednání Glosář projektu (datový slovník) 17 18

4 Subjekt, aktéři, případy užití Diagram případů užití Předtím, než budeme cokoliv vytvářet, měli bychom znát: kde leží hranice systému, kdo nebo co bude systém užívat, jaké služby bude systém uživatelům nabízet. Do modelu jednání vložíme: Subjekt hranici systému Aktéry kdo se systémem komunikuje Případy užití na co jej používá Vztahy mezi aktéry a případy užití. subjekt JménoSystému Mail Order System use case diagram communication relationship Customer Mail Order System Place Order Cancel Order Check Order Status Ship Product subject name system boundary ShippingCompany actor Send Catalogue use case Dispatcher Glosář projektu Detailní popis případů užití Project Glossary Termín1 Definice Synonyma Homonyma Termín2 Definice Synonyma Homonyma Termín3 Definice Synonyma Homonyma V každé doméně existuje žargon, proto doplňujeme modely glosářem. Smyslem glosáře je definovat synonyma a homonyma. Vytváříte slovník pro potřeby diskuse se zainteresovanými osobami, které mohou používat žargon dané domény. Model jednání [hrubý] Doplňující požadavky Glosář Popisovač případů užití (use case specifier) Popis detailů případů užití Případ užití (detailní popis) Detailní specifikace případů užití use case name use case identifier brief description the actors involved in the use case the system state before the use case can begin the actual steps of the use case the system state when the use case has finished alternative flows ID: 1 Primary actors: Time Use case: PaySalesTax Brief description: Pay Sales Tax to the Tax Authority at the end of the business quarter. Secondary actors: TaxAuthority 1. It is the end of the business quarter. Main flow: 1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of Sales Tax owed to the Tax Authority. 3. The system sends an electronic payment to the Tax Authority. 1. The Tax Authority receives the correct amount of Sales Tax. Alternative flows: implicit time actor 23 Předpoklady a důsledky Předpoklady (preconditions) a důsledky (postconditions) představují omezení. Předpoklady omezují stav systému před zahájením scénáře. Důsledky omezují stav systému po ukončení scénáře. Pokud nejso žádné předpoklady ani důsledky, je třeba to zdůraznit např. klíčovým slovem "None" pod hlavičkou. Place Order 1. A valid user has logged on to the system 1. The order has been marked confirmed and is saved by the system 24

5 Hlavní scénář <číslo> <někdo> <nějaká akce> Scénář zachycuje posloupnost kroků v rámci zpracování případu užití. Vždy se začíná tím že aktér něco provede (iniciuje událost). Dobrá technika je zahájit scénář: 1) Případ užití se spustí, když aktér - <funkce> Kroky scénáře by měly být : deklarativní, očíslované, uspořádané v čase. Hlavní scénář by měl představovat úspěšné použití: Vše probíhá podle očekávání, nenastaly chýby, odchylky, přerušení apod. Alternativní scénáře pak popisují tyto alternativy. Větvení: If Use the keyword if to indicate alternatives within the flow of events There must be a Boolean expression immediately after if Use indentation and numbering to indicate the conditional part of the flow Use else to indicate what happens if the condition is false (see next slide) Use case: ManageBasket ID: 2 Brief description: The Customer changes the quantity of an item in the basket. Primary actors: Customer Secondary actors: 1. The shopping basket contents are visible. Main flow: 1. The use case starts when the Customer selects an item in the basket. 2. If the Customer selects "delete item" 2.1 The system removes the item from the basket. 3. If the Customer types in a new quantity 3.1 The system updates the quantity of the item in the basket. Alternative flows: Opakování: For We can use the keyword For to indicate the start of a repetition within the flow of events The iteration expression immediately after For statement indicates the number of repetitions of the indented text beneath the For statement. ID: 3 Actors: Customer Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. If the system finds some matching products then 5.1 For each product found The system displays a thumbnail sketch of the product The system displays a summary of the product details The system displays the product price. 6. Else 6.1. The system tells the Customer that no matching products could be found. Alternative flows: Use case: FindProduct Brief description: The system finds some products based on Customer search criteria and displays them to the Customer. 27 Opakování: While We can use the keyword while to indicate that something repeats while some Boolean condition is true ID: 3 Primary actors: Customer Secondary actors: None Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. If the system finds some matching products then 5.1 For each product found The system displays a thumbnail sketch of the product The system displays a summary of the product details The system displays the product price. 6. Else 6.1. The system tells the Customer that no matching products could be found. Alternative flows: Use case: FindProduct Brief description: The system finds some products based on Customer search criteria and displays them to the Customer. 28 Alternativy We may specify one or more alternative flows through the flow of events: Alternative flows capture errors, branches, and interrupts Alternative flows never return to the main flow Potentially very many alternative flows! You need to manage this: Pick the most important alternative flows and document those. If there are groups of similar alternative flows - document one member of the group as an exemplar and (if necessary) add notes to this explaining how the others differ from it. Use case main flow alternative flows Only document enough alternative flows to clarify the requirements! Referencování alternativ List the names of the alternative flows at the end of the use case Find alternative flows by examining each step in the main flow and looking for: Alternatives Exceptions Interrupts alternative flows ID: 5 Main flow: Use case: CreateNewCustomerAccount Brief description: The system creates a new account for the Customer. Primary actors: Customer Secondary actors: The use case begins when the Customer selects "create new customer account". While the Customer details are invalid The system creates a new account for the Customer. 1. A new account has been created for the Customer. Alternative flows: Invalid Address InvalidPassword Cancel The system asks the Customer to enter his or her details comprising address, password and password again for confirmation. The system validates the Customer details

6 Příklad alternativy notice how we name and number alternative flows always indicate how the alternative flow begins. In this case it starts after step 2.2 in the main flow Alternative flow: CreateNewCustomerAccount:Invalid Address ID: 5.1 Brief description: The system informs the Customer that they have entered an invalid address. Primary actors: Customer Secondary actors: 1. The Customer has entered an invalid address Alternative flow: 1. The alternative flow begins after step 2.2. of the main flow. 2. The system informs the Customer that he or she entered an invalid address. The alternative flow may be triggered instead of the main flow - started by an actor The alternative flow may be triggered after a particular step in the main flow - after The alternative flow may be triggered at any time during the main flow - at any time 31 Trasování požadavků Given that we can capture functional requirements in a requirements model and in a use case model we need some way of relating the two There is a many-to-many relationship between requirements and use cases: One use case covers many individual functional requirements One functional requirement may be realised by many use cases Hopefully we have CASE support for requirements tracing: With UML tagged values, we can assign numbered requirements to use cases We can capture use case names in our Requirements Database If there is no CASE support, we can create a Requirements Traceability matrix Use cases U1 U2 U3 U4 R1 R2 R3 R4 R5 Requirements Requirements Traceability Matrix 32 Kdy používat analýzu případů užití? Případy užití popisují systém z pohledu aktérů. To je vhodné: Když u systému dominují funkční požadavky. Když systém poskytuje různou funkcionalitu různým aktérům. Pokud má systém rozmanitá rozhranní. Případy užití specifikují chování z hlediska poskytovaných funkcí. Nejsou vhodné: Když u systému dominují nefunkční požadavky. Pokud má systém jen málo aktérů. Pokud má systém jednoduchá rozhranní. Dodávky a přírůstky Každá iterace produkuje dodávku. Dodávka je sada revidovaných a ověřených artefaktů, které: Představují dohodnutý základ pro další vývoj Mohou mýt měněny jen na základě formalizovaných postupů konfigurace a změnové řízení. Přírůstek je rozdíl mezi dvěma následujícími dodávkami. Proto se UP nazývá iterativní a přírůstkové Struktura UP Fáze Milník Fáze Iterace Požadavky (Life-cycle Objectives) Architektura (Life-cycle Architecture) Beta verze (Initial Operational Capability) Incepce Elaborace Konstrukce Iter 1 Dodávka (Product Release) Přechod (Transition) Iter 2 Iter 3 Iter 4 Iter 5 Iter 6 5 základních postupů P A N I T Každá fáze může zahrnovat několik iterací. Skutečný počet závisí na rozsahu projektu, u malých projektů může mít fáze jen jednu iteraci. Každá fáze končí milníkem. Pro každou fázi je nutno specifikovat: Základní postupy Cíl fáze Co je milník na konci fáze Požadavky Analýza Návrh Implementace Testy Incepce Elaborace Konstrukce Přechod Předběžné iterace úsilí I1 I2 In In+1 In+2 Im Im

7 Incepce Relativní úsilí pro každý postup Milník konec incepce Zaměřeno na Cíle (zahájení, úvodní studie) Požadavky sestavit případy užití a rozsah. Vytipovat jejich důležitost. Analýza zhodnotit proveditelnost Návrh ověření konceptu nebo technický prototyp Implementace ověření konceptu nebo technický prototyp Testy zde nemají smysl Incepce Elaborace Konstrukce Přechod Ověřit proveditelnost projektu případně s využitím prototypů Sestavit požadavky a případy užití Vymezit hranici systému Identifikovat rizika P A N I Cíle projektu představující podmínky pro úspěšné řešení: Je určena hranice systému (system scope). Jsou definovány klíčové požadavky na systém a jsou schváleny zainteresovanými osobami (stakeholders). Existuje vize architektury systému, zatím jen hrubě. Je zpracována analýza rizik. Je zpracován odhad nákladů a výnosů (business case). Je povrzena proveditelnost projektu (feasibility study). Zainteresované osoby (stakeholders) souhlasí s objektivními charakteristikami projektu Zaměřeno na Cíle Elaborace (rozbor, analýza) Požadavky zkompletovat požadabky a hranici Analýza vymezení skutečného rozsahu Návrh vytvoření stabilní architektury Implementace realizace základny pro architekturu Testy testování architektonické základny Incepce Elaborace Konstrukce Přechod Vytvoření a návrh architektury Vyhodnocení rizik Výběr 80% funkčních požadavků Vytvoření detailního plánu pro fázi konstrukce Formulace požadavků na zdroje, čas, vybavení, týmy a cenu 39 P A N I T Milník konec elaborace Je určena architektura : Je definován robustní proveditelný, architektonický základ řešení. Je doplněna analýza rizik. Je vytvořen plán projektu, pro zajištění realistické představy o postupu. Obchodní plán je porovnán s plánem a původní představou. Zainteresované osoby (stakeholders) souhlasí s pokračováním. 40 Konstrukce Milník - konec konstrukce (návrh, implementace) I P A N T Částečná funkčnost systému: Produkt je připraven k beta-testování v prostředí uživatele. Požadavky objevování chybějících požadavků Incepce Elaborace Konstrukce Přechod Analýza dokončení analytického modelu Zaměřeno na Cíle Návrh dokončení návrhového modelu Implementace vytvoření počáteční funkčnosti beta verze Testy testování beta verze Dokončení specifikace Dokončení analýzy, návrhu, implementace a testování Údržba integrity architektury systému Vyhodnocení rizik 41 42

8 Přechod (transition, provoz) Požadavky nic Analýza nic N I T Incepce Elaborace Konstrukce Přechod Milník konec přechodu Produkt je k dispozici: Proběhlo beta-testování, akceptační test i opravy chyb. Produkt je uvolněn pro uživatele. Zaměřeno na Cíle Návrh modifikace podle výsledků beta testů Implementace přizpůsobení softwaru prostředí uživatele, opravy chyb a beta testů Testy akceptační testy v prostředí uživatele Opravy chyb Příprava prostředí uživatele a uzpůsobení softwaru tomuto prostředí Modifikace dle odhalených problémů Tvorba příruček a manuálů, dokumentace Poskytování konzultační podpory uživateli Vyhodnocení projektu UP - shrnutí UP metodika založená na analýze případů užití, je řízena rizikem, soustředí se na architekturu. Jedná se o iterativní a přírůstkový proces. UP má 4 fáze: Incepce Elaborace Konstrukce Přechod Každá fáze se skládá z jedné, či více iterací. Každá iterace má čtyři kroky: Požadavky Analýza Návrh Implementace Testování Agilní metodiky Psychologie týmu ( SCRUM ( Crystal Clear ( XP - Extreme Programming ( Extrémní programování (XP) Co to je XP? Řízeno požadavky uživatelů (user stories) Používá metaforu pro budovaný systém Vyvíjí se v iteracích Pracuje se ve dvojici Co nejjednodušší návrh (neprogramujeme dopředu) Okamžité testování Refaktorizace kódu Kód je společný - standardy pro kódování Co nejrychlejší zpětná vazba, uživatel součástí vývojového týmu, minimum dokumentace Nepřehánět zátěž - 40 hodin týdně Agilní technika vývoje softwaru, která dle agilního manifestu upřednostňuje: Týmovou spolupráci a interakci před formálními procesy a nástroji. Fungující software před obsáhlou, komplexní dokumentací. Spolupráci mezi zákazníkem a vývojáři před specifikacemi, zadáními, dohodnutými kontrakty. Rychlou adaptaci na změny v zadání před dodržováním předem stanovených pravidel

9 12 technik používaných v XP Plánování hrou Malé dodávky (releases) Metafory Jednoduchý návrh Párové programování Intezivní testování Refaktorizace kódu Kolektivní vlastnictví kódu Spojitá intergace 40 hodin/týden Zákazník součástí týmu Kódové standardy Plánování hrou Software se vyvíjí v malých iteracích. Vyvíjí se vždy pouze to, co zákazník v danou chvíli potřebuje. Iterace se skládá z: Sepsání požadavků user stories (zákazník) Rozdělení požadavků na úkoly (vývojáři) Časových odhadů jednotlivých úkolů (vývojáři) Určení priorit (zákazník) Programování (vývojáři) Akceptačních testů dle požadavků (zákazník) Malé dodávky (releases) Na konci každé iterace (zpracování jednoho příběhu user story) se vytvoří nová dodávka (release). To znamená: Zákazník dostává poměrně často nové verze (jednou za dva týdny, týden, den). Existuje okamžitá zpětná vazba, neboť zákazník může software neustále testovat a připomínkovat. Zákazník má k dispozici funkční část softwaru velmi rychle a může ho začít používat. Metafora Jednoduchá paralela nebo příběh, který popisuje budovaný systém slovy a pojmy, které všichni zúčastnění intuitivně chápou. Slouží k lepšímu porozumění a komunikaci mezi členy týmu, vývojáři a zákazníky Jednoduchý návrh Scott W.Ambler: Co přesně má software dělat a jak má vypadat víte v nejlepším případě až když ho potřetí přepisujete celý znova. Proto je vhodné udržovat návrh tak jednoduchý, jak to jde. Použít co nejjednodušší, který ještě splní akceptační testý. Neprogramovat pro budoucnost, netvořit frameworky, pokud to není nezbytně nutné. Párové programování Každá řádka kódu je napsána dvěma programátory u jednoho počítače s jedním monitorem a jednou klávesnicí. To zajišťuje: Vyšší spolehlivost kódu, neboť programátoři se kontrolují navzájem. Vyšší čitelnost a pochopitelnost kódu, neboť programátoři se kontrolují navzájem. Všeobecné povědomí všech vývojářů o celém kódu. Vzájemné učení se od sebe

10 Testování Refaktorizace Neustálé testování je jedna z fundamentálních technik XP, bez testování nemůže XP fungovat. Vývojáři píší testy jednotek (unit tests) na každou komponentu vyvíjeného systému, dokonce na každou třídu, tyto testy se spouští neustále. Pokud neprochází všechny testy jednotek a akceptační testy pro daný příběh, nelze pokračovat ve vývoji. Refaktorizace je technika zlepšování stávajícího kódu beze změny chování. Refaktoruje se kvůli: Zjednodušení kódu. Optimalizaci kódu. Lepší čitelnosti a pochopitelnosti kódu. Přidání nové funkcionality. Testy jednotek by měly zajistit, že se nezmění stávající chování Společné vlastnictví kódu Neustálá integrace Kterýkoliv vývojář v týmu využívajícím XP je oprávněn kdykoliv modifikovat kterýkoliv kus kódu, pokud po modifikaci procházejí testy. Veškerý kód je zpřístupněn všem vývojářům ve společném repozitáři. Kdykoliv je vyřešen (naprogramován) a otestován nějaký úkol, je kód uložen do repozitáře hodin týdně Zákazník v týmu Psychicky nebo intelektuálně unavený vývojář je: Nevýkonný Cybující Velmi naštvaný Proto je nutné vývojovému týmu zajistit klid na práci, důstojné pracovní prostředí a hlavně je nepřetěžovat. Součástí týmu by měl být on-site customer, který představuje typického uživatele a je kdykoliv k dispozici vývojářům aby: Zodpovídal otázky vývojářů během práce Tvořil akceptační testy pro jednotlivé příběhy Testoval a podával zpětnou vazbu 59 60

11 Kódové standardy Kdy se hodí XP? Je nutné, aby všichni programátoři dodržovali stejné standardy: Stejné zarovnání kódu Stejné konvence pro identifikátory Stejně nastavené vývojové prostředí Když je limitovaný čas nebo finance. Když zákazník není přesně co chce, nebo není schopen dodat dostatečně přesné zadání. Když zákazník chce spolupracovat na projektu. Když se ví, že se bude systém měnit. Když jsou členové týmu schopni spolupracovat a dobře spolu vycházejí Kdy se nehodí XP? Srovnání Když je nutný větší tým vývojářů (více než 15). Když je vývojový cyklus (oprava, překlad, sestavení spuštění) příliš dlouhý (5 minut, hodina). Když jsou testy příliš dlouhé (minuty, hodiny). Když nelze zákazníka dostat do týmu. Když zákazník nechápe principy XP. XP představuje alternativu k vodopádovému modelu. Není to nekoordinované hackování kódu zdivočelými programátory. Aby fungovalo, musí mít tým jisté zkušenosti a musí dodržovat všech 12 technik. XP není všelék, hodí se jen někdy, ale někdy může přinášet lepší výsledky za kratší čas Metodika SCRUM (pojem z rugby) SCRUM základní principy Žádné týmové hierarchie, tým do 7 osob, pracuje se v jedné místnosti (osmóza), tým si volí šéfa (scrum master) Krátké iterace (sprints) Plánovací schůzka před každou iterací Seznam akcí pro danou iteraci (backlog) Denní skrumáže (co jsem udělal, co budu dělat, jaké mám problémy) Retrospekce po každé iteraci (heartbeat session) Vlastníkem kódu je tým - standardy pro kódování Jednoduchost Hodnota pro zákazníka Analyzuj a uprav Pravidelná integrace Komunikace a spolupráce Kolektivní vlastnictví kódu Testování a revize součástí vývoje 65 66

12 SCRUM životní cyklus Rozdělit práci na menší celky sprinty Během sprintu by se měla stihnout celá úloha: Analýza Design a implementace Testování a revize Doba trvání jednoho sprintu cca do 30 dnů Ohodnocení úloh body Duration = Effort / Velocity. Pro první plán: 1bod = 1man-day Bod je bezrozměrný, máme jen rychlost týmu Výběr pořadí sprintů Role v metodice SCRUM Scrum je kostra metodiky, která stanovuje následující role: vedoucí projektu (Scrum Master) řídí procesy a celkovou práci, zadavatel (Product Owner) který reprezentuje zainteresované osoby (stakeholders) a tým (Team) který zahrnuje vývojáře SCRUM - postup Sprint Vytvoření plánu projektu (project backlog) Sestavení případů užití (user stories) Vytvoření potřebných úloh (sprintů) Realizace plánu projektu Výběr sprintu (sprint backlog) Realizace sprintu Denní setkání (SCRUM Meetings, skrumáže) Sledování postupu (burndown graf) Trvá typicky 2-4 týdny (rozhoduje si to tým). Výsledkem je přírůstek použitelného kódu. Zadání je vybráno z katalogu požadavků (product backlog) na schůzce (sprint planning meeting), kde zadavatel (product owner) informuje o požadavcích, které je zapotřebí realizovat jsou součástí katalogu požadavků (product backlog). Tým si vybere co je schopen realizovat v rámci jednoho sprintu a určuje si plán sprintu (sprint backlog) - hierarchickou sada požadavků, které by měl sprint realizovat. Během sprintu se plán sprintu nemůže měnit (je zmrazen). Po ukončení sprintu tým prezentuje vytvořený přírůstek a dokumentuje jeho funkčnost. Zdroj: Wikipedia Výhody metodiky SCRUM Metodika Scrum umožňuje vytváření samoorganizujících týmů pro členy týmu to znamená větší pocit svobody, ale také větší zodpovědnost. Klíčový princip metodiky Scrum je připravenost na změny (nazývané requirements churn) a pochopení, že tuto skutečnost nelze řešit klasickou organizací a plánováním. The End 71