Agiln a rigorzn metodiky pednka IT215 ing Alena

  • Slides: 54
Download presentation
Agilní a rigorózní metodiky přednáška IT_215 ing. Alena Buchalcevová 1

Agilní a rigorózní metodiky přednáška IT_215 ing. Alena Buchalcevová 1

Metodiky vývoje, údržby a provozu IS/ICT problémy n n n metodik je velké množství

Metodiky vývoje, údržby a provozu IS/ICT problémy n n n metodik je velké množství a nejsou jednotně popsány obtížně je lze srovnávat a vyhledat vhodnou metodiku mnohé metodiky se zaměřují jen na určité aspekty vývoje, jen na určité fáze živ. cyklu většinou jsou zaměřeny jen na vývoj nového SW tradiční rigorózní metodiky pro současné projekty nevyhovují většina metodik je v angličtině 2

Velké množství metodik n objektivní důvody ¨ ¨ ¨ n n různé technologie vyžadují

Velké množství metodik n objektivní důvody ¨ ¨ ¨ n n různé technologie vyžadují různé techniky organizace se liší firemní kulturou každý jedinec je jedinečný každý tým je jedinečný projekty se liší velikostí projekty se liší důležitostí snaha prezentovat se komerční důvody 3

Kategorizace existujících metodik Kritérium Kategorie/ vysvětlení zaměření metodiky globální projektové rozsah metodiky fáze –

Kategorizace existujících metodik Kritérium Kategorie/ vysvětlení zaměření metodiky globální projektové rozsah metodiky fáze – role - dimenze váha metodiky velikost metodiky x hustota metodiky [Cockburn] typ řešení vývoj nového řešení, rozšíření stávajícího řešení, integrace řešení, implementace typového řešení, užití řešení například formou ASP doména ERP, CRM, SCM, EAI, . . . přístup k řešení Strukturovaný, objektově orientovaný, RAD 4

Kritérium celý systém versus projekt n globální metodiky ¨ metodiky IS v rámci celé

Kritérium celý systém versus projekt n globální metodiky ¨ metodiky IS v rámci celé organizace Enterprise metodiky např. MMDIS, Enterprise Unified Process (EUP), n projektové metodiky zabývají se vývojem části IS – jeden projekt většina metodik 5

Kritérium rozsah n n metodiky pokrývající celý životní cyklus vývoje . např. MMDIS viz

Kritérium rozsah n n metodiky pokrývající celý životní cyklus vývoje . např. MMDIS viz dále dílčí metodiky – zabývají se jen částí životního cyklu IS – např. jen návrh a implementace 6

Kritérium podrobnosti metodiky – váha metodiky n těžké metodiky podrobný popis ¨ rigorózní ¨

Kritérium podrobnosti metodiky – váha metodiky n těžké metodiky podrobný popis ¨ rigorózní ¨ n lehké metodiky ¨ minimálně dostatečná metodika „barely sufficient“ Cockburn „a little bit less than just enough“ Highsmith ¨ agilní metodiky 7

Kritérium přístupu k vývoji n n strukturované metodiky RAD metodiky ¨ n RAD nástroje,

Kritérium přístupu k vývoji n n strukturované metodiky RAD metodiky ¨ n RAD nástroje, prototypování objektově orientované metodiky 8

Kritérium způsobu vývoje n n tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní

Kritérium způsobu vývoje n n tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj 9

Kritérium domény EAI Enterprise Application Integration BIN Business Intelligence SCM Supply Chain Management ERP

Kritérium domény EAI Enterprise Application Integration BIN Business Intelligence SCM Supply Chain Management ERP Enterprise Resource Planning CRM Customer Relationship Management ECO e-commerce OIS kancelářské systémy CTM Content Management WKF wokflow ELE e-learning 10

Charakteristika rigorózních metodik n těžké metodiky ¨ n podrobné, hodně formalit, direktivní řízení předpokládají

Charakteristika rigorózních metodik n těžké metodiky ¨ n podrobné, hodně formalit, direktivní řízení předpokládají opakovatelnost procesů ¨ možnost definovat všechny požadavky na řešení předem ¨ n příklady OPEN, RUP, EUP, OOSP n metodiky pro hodnocení SW procesů (Software Process Assesment ) Capability Maturity Model CMM 11

Model zralosti SW Capability Maturity Model for Software n n n označovaný zkratkou SW–CMM.

Model zralosti SW Capability Maturity Model for Software n n n označovaný zkratkou SW–CMM. vyvinut v Institutu pro softwarové inženýrství (Software Engineering Institute – SEI) za účelem hodnocení dodavatelů softwarových řešení pro ministerstvo obrany USA – v r. 1995 Integrační model zralosti (Capability Maturity Model Integration, CMMI) od r. 2000 12

Úrovně zralosti CMM Počáteční úroveň (initial) • softwarové procesy jsou náhodné a chaotické •

Úrovně zralosti CMM Počáteční úroveň (initial) • softwarové procesy jsou náhodné a chaotické • organizace nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy. Opakovatelná úroveň (repeatable) • organizace mají definovány a zavedeny postupy řízení projektu. • softwarový proces je disciplinovaný Definovaná úroveň (defined) • organizace má definovány, dokumentovány a standardizovány procesy pro řízení i softwarově inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace • softwarový proces je standardní a konzistentní Řízená úroveň (managed) • organizace má stanoveny detailní metriky softwarových procesů i kvality produktu • softwarový proces je predikovatelný Optimalizovaná úroveň (optimizing) • organizace má vytvořeny podmínky pro kontinuální zlepšování procesů. 13

Rigorózní metodiky pro mnohé současné projekty nevyhovují n vycházejí z předpokladu, že : požadavky

Rigorózní metodiky pro mnohé současné projekty nevyhovují n vycházejí z předpokladu, že : požadavky je možné specifikovat předem ¨ změnám se snažíme zabránit, jsou náročné ¨ velké množství meziproduktů ¨ ztrácí se cíl vývoje – vytvořit fungující SW odpovídající potřebám uživatelů ¨ n 14

Charakteristika agilních metodik společné principy: n iterativní vývoj s velmi krátkými iteracemi, n zaměření

Charakteristika agilních metodik společné principy: n iterativní vývoj s velmi krátkými iteracemi, n zaměření na fungující SW, který má hodnotu pro zákazníka, n lidé jsou prvořadým faktorem – důraz na spolupráci a komunikaci, n tolerantní ke změnám, n automatizované testování. 15

Agilní metodiky praktiky místo procesů Proces je popisován v manuálech, ¨ pohlíží na lidi

Agilní metodiky praktiky místo procesů Proces je popisován v manuálech, ¨ pohlíží na lidi jako na sekundární, ¨ zaměřuje se na explicitní (popsanou) znalost Praktika ¨ je, co se odehrává v realitě, ¨ soustředí se primárně na lidi, ¨ soustředí se na interní „tacit“ znalosti. ¨ 16

Agilní metodiky Hodnota pro zákazníka n n n jestliže SW musí dodávat hodnotu pro

Agilní metodiky Hodnota pro zákazníka n n n jestliže SW musí dodávat hodnotu pro zákazníka, kdo může nejlépe určit, jaká hodnota to je? vývojáři ne, ale zákazníci ano, přesun zodpovědnosti na zákazníka ¨ n zákazník určuje a mění priority funkcí zákazník nevidí do budoucna, proto my, vývojáři musíme do systému zabudovat funkce a data , které by mohl zákazník v budoucnu potřebovat X ¨ je lepší vytvořit systém tolerantní ke změnám, který umí akceptovat změny v budoucnu ¨ 17

Agilní metodiky osobní komunikace 18

Agilní metodiky osobní komunikace 18

Spolupráce zákazníků a vývojářů Rigorózní metodiky n postaveny na nedůvěře. n Nevěřím ti, že

Spolupráce zákazníků a vývojářů Rigorózní metodiky n postaveny na nedůvěře. n Nevěřím ti, že uděláš práci správně, tak tě musím neustále sledovat a kontrolovat. Agilní metodiky n vůdcovství a spolupráce - jsou formovány na důvěře a respektu. n Věřím ti, že uděláš práci dobře, a tak budeme spolupracovat, abychom dosáhli výsledku. 19

Spolupráce zákazníků a vývojářů / 2 Rigorózní metodiky n standardizují lidi v organizaci n

Spolupráce zákazníků a vývojářů / 2 Rigorózní metodiky n standardizují lidi v organizaci n snaží se vykázat lidi do role zaměnitelné součástky n čím větší projekty se realizují, tím více specialistů je třeba zapojit Agilní metodiky n využívají individualit a silných stránek lidí n požadují integraci znalostí, stálá interakce a kooperace, sdílení znalostí v týmu, týmové řešení problému. 20

Manifest pro agilní vývoj SW podepsán v únoru 2001 Odhalili jsme lepší způsob vývoje

Manifest pro agilní vývoj SW podepsán v únoru 2001 Odhalili jsme lepší způsob vývoje SW, sami jej používáme a chceme n n pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji provozuschopnému software před obsažnou dokumentací spolupráci se zákazníkem před sjednáváním kontraktu reakci na změnu před plněním plánu 21

Které metodiky řadíme mezi agilní? n n n n Adaptive Software Development (ASD), Dynamic

Které metodiky řadíme mezi agilní? n n n n Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD), Extreme Programming (XP), Lean Development, SCRUM, Crystal metodiky, Agile Modeling 22

Porovnání rigorózních a agilních metodik použití obsah předpoklady rigorózní metodiky agilní metodiky • SW

Porovnání rigorózních a agilních metodik použití obsah předpoklady rigorózní metodiky agilní metodiky • SW procesy lze popsat • SW procesy nelze popsat • požadavky je možné definovat předem • předem jen hrubé požadavky přesně definované procesy, činnosti, artefakty standardní projekty, velké projekty jen generativní pravidla, praktiky a principy výzkumné projekty time-to-market menší týmy 23

Předpoklady agilního vývoje n n n n n zákazník je součástí týmu a je

Předpoklady agilního vývoje n n n n n zákazník je součástí týmu a je k dispozici dle potřeby dokumentace a modely nehrají klíčovou roli při vývoji požadavky a prostředí se mění v průběhu vývoje přizpůsobování procesu vývoje vede k vyšší kvalitě produktu vývojáři mají zkušenosti potřebné k přizpůsobování procesů viditelnost procesů je jen při ukončení přírůstku hodnocení produktu je neformální cílem není znovupoužitelnost SW může být vyvíjen inkrementálně Tur, D. - France, R. - Rumpe, B. : Limitations of Agile Software Process 24

Omezení agilního vývoje n n n omezená podpora pro distribuované prostředí vývoje týmy nejlépe

Omezení agilního vývoje n n n omezená podpora pro distribuované prostředí vývoje týmy nejlépe v jedné místnosti, komunikace tváří v tvář omezená podpora subdodavatelů omezená podpora pro vytváření znovupoužitelných artefaktů omezená podpora pro vývoj ve velkém týmu omezená podpora pro vývoj kritických aplikací omezená podpora pro vývoj velkého komplexního SW - není architektura !! Tur, D. - France, R. - Rumpe, B. : Limitations of Agile Software Process 25

Více o agilních metodikách Buchalcevová, A. : Metodiky vývoje a údržby informačních systémů, Grada

Více o agilních metodikách Buchalcevová, A. : Metodiky vývoje a údržby informačních systémů, Grada publishing, 2005, ISBN 80 -247 -1075 -7 26

Extrémní programování XP n hlavní praktiky ¨ ¨ ¨ automatizované testy testování před kódováním

Extrémní programování XP n hlavní praktiky ¨ ¨ ¨ automatizované testy testování před kódováním jednoduchý návrh refaktorizace párové programování společné vlastnictví kódu Jednoduchý návrh redukuje testovací práci. Neustálé testování redukuje čas dodávky. Prokládání kódování a testování dává vývojářům a testerům lepší porozumění kódu. Automatizované testy dovolují vývojářům provádět refaktorizaci. 27

Metodika Feature-Driven Development (FDD) n n n přináší výhody agilního vývoje, ale staví na

Metodika Feature-Driven Development (FDD) n n n přináší výhody agilního vývoje, ale staví na modelování autoři Jeff De Luca a Peter Coad je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu (feature-driven) 28

Praktiky FDD n doménové objektové modelování (Domain Object Modeling) ¨ n n n n

Praktiky FDD n doménové objektové modelování (Domain Object Modeling) ¨ n n n n diagram tříd UML, který zahrnuje nejdůležitější typy objektů v problémové doméně a vztahy mezi nimi vývoj podle užitných vlastností (Developing by Feature), vlastnictví tříd (Individual Class Ownership), týmy pro užitné vlastnosti (Feature Teams), inspekce (Inspections) pravidelné buildy (Regular Builds), řízení konfigurací (Configuration Management), reporting/viditelnost výsledků (Reporting/Visibility of Results). 29

Vývoj podle užitných vlastností (Developing by Feature) užitná vlastnost(feature) n malá funkce (realizovatelná během

Vývoj podle užitných vlastností (Developing by Feature) užitná vlastnost(feature) n malá funkce (realizovatelná během 2 týdenní iterace) n s hodnotou pro zákazníka n vyjádřená ve formátu <akce> <výsledek> <objekt> např. vypočítat celkovou sumu prodeje 30

Procesy FDD 31

Procesy FDD 31

SCRUM n n vývoj SW není definovaný proces, který je možné přesně popsat a

SCRUM n n vývoj SW není definovaný proces, který je možné přesně popsat a opakovat, ale empirický proces vyžaduje odlišný styl řízení - vyžaduje konstantní monitorování a adaptaci 32

SCRUM n n framework pro řízení projektu Pre-sprint seznam užitných vlastností backlog ¨ definování

SCRUM n n framework pro řízení projektu Pre-sprint seznam užitných vlastností backlog ¨ definování cíle sprintu ¨ n Sprint v rámci sprintu se nesmí měnit priority ¨ Scrum meetings ¨ n Post-sprint ¨ zhodnocení posunu, předvedení zákazníkovi 33

SCRUM meetings n n n n umožňují monitorovat stav, konají se ve stejný čas

SCRUM meetings n n n n umožňují monitorovat stav, konají se ve stejný čas na stejném místě trvají méně než 30 minut (cílem je 15 minut) vede je Scrum master účastní se jich všichni členové týmu (vývojáři, uživatelé , testeři, . . ) navštěvují je manažeři, aby věděli o stavu, ale aktivně se neúčastní slouží ke zjištění problémů, ale ne k jejich řešení každý účastník musí zodpovědět 3 otázky co udělal od poslední scrum porady ¨ co bude dělat do příští scrum porady ¨ jaké překážky mu stojí v cestě ¨ 34

Agilní modelování Scott Ambler n n lehká metodika pro efektivní modelování postavená na prověřených

Agilní modelování Scott Ambler n n lehká metodika pro efektivní modelování postavená na prověřených modelovacích technikách jde o kolekci praktik - doporučení, jak efektivně modelovat 35

Modelování n n modelování základní částí vývoje SW ať v lehkých nebo těžkých metodikách

Modelování n n modelování základní částí vývoje SW ať v lehkých nebo těžkých metodikách dva primární důvody, proč modelovat: n n n abyste pochopili podstatu toho, co vytváříte, abyste mohli komunikovat v týmu je bohužel obětí mýtů a nepochopení 36

Mýty o modelování 1. Modelování je vždy svázáno s dokumentací n n model je

Mýty o modelování 1. Modelování je vždy svázáno s dokumentací n n model je abstrakce, která popisuje jeden nebo více aspektů problému a možné řešení problému tradičně jsou modely chápány jako diagramy a odpovídající dokumentace Realita n nevizuální artefakty jako CRC karty, textový popis byznys pravidel jsou považovány také za modely při modelování nejde o model jako takový, ale o proces modelování většina modelů není součástí oficiální dokumentace systému, ale některé modely je dobré uchovat - persistentní modely 37

Mýty modelování 2. Je možné vše namodelovat předem a správně snaha namodelovat vše předem

Mýty modelování 2. Je možné vše namodelovat předem a správně snaha namodelovat vše předem a správně a zmrazit požadavky před začátkem kódování Realita n nemá smysl modelovat ve všech podrobnostech n programátoři příliš neuznávají modely n základem vývoje SW je iterativní přístup - trochu modelování, trochu kódování, trochu testování a hlavně nasazení fungující verze SW a zpětná vazba od zákazníka n 38

Mýty modelování 3. Modelování je spojeno s rigorózními metodikami Realita n je možné modelovat

Mýty modelování 3. Modelování je spojeno s rigorózními metodikami Realita n je možné modelovat agilním způsobem – používat jednoduché modely a jednoduché nástroje 39

Mýty modelování 4. Při vývoji softwaru je třeba zmrazit požadavky Při zmrazení požadavků na

Mýty modelování 4. Při vývoji softwaru je třeba zmrazit požadavky Při zmrazení požadavků na začátku životního cyklu nejspíš dodáte to, co bylo požadováno, ale pravděpodobně ne to, co je třeba. Realita n dochází ke změnám, mění se požadavky protože se mění byznys priority ¨ protože zákazník po dodání části systému jej lépe pochopí ¨ n lepší než zmrazit požadavky a riskovat neúspěch je uchopit změnu a odpovědět na ni 40

Mýty modelování 5. Návrh je vytesán do kamene Realita n nikdo, ani nejlepší návrhář

Mýty modelování 5. Návrh je vytesán do kamene Realita n nikdo, ani nejlepší návrhář není dokonalý a stejně tak jeho dílo, nemá smysl fixovat chyby n pokud nechceme zmrazit požadavky, není možné zmrazit návrh n návrh je hotov, až po dodání kódu 41

Mýty modelování 6. Při modelování je nutné používat CASE nástroj který nejlépe zachytí všechny

Mýty modelování 6. Při modelování je nutné používat CASE nástroj který nejlépe zachytí všechny aspekty modelu a zajistí konzistenci mezi modely Realita n daleko efektivnější je vytvářet jednoduché modely, které zachycují jen podstatné informace n a používat jednoduché nástroje 42

Mýty modelování 7. Modelování je ztráta času častý názor nových vývojářů, kteří se orientují

Mýty modelování 7. Modelování je ztráta času častý názor nových vývojářů, kteří se orientují jen na kódování Realita n často se produktivita vývojáře zvýší náčrtkem diagramu, vytvořením prototypu UI atd. n produktivní vývojáři modelují před psaním kódu n 43

Mýty modelování 8. Základem je datové modelování datová komunita má politickou sílu Realita n

Mýty modelování 8. Základem je datové modelování datová komunita má politickou sílu Realita n datové modelování je důležitý, ale sekundární úkol modelování n 44

Mýty modelování 9. Všichni vývojáři umí modelovat n umění modelovat vyžaduje léta zkušeností 45

Mýty modelování 9. Všichni vývojáři umí modelovat n umění modelovat vyžaduje léta zkušeností 45

Agilní modelování – hodnoty odvozeny z hodnot Extrémního programování n komunikace ¨ n n

Agilní modelování – hodnoty odvozeny z hodnot Extrémního programování n komunikace ¨ n n mezi vývojáři, uživateli, projekt manažery, vedením, modely jednoduchost zpětná vazba odvaha skromnost ¨ umět si přiznat, že nevím vše a že ostatní mohou přidat hodnotu 46

Agilní modelování – principy n n n n primárním cílem je fungující software sekundárním

Agilní modelování – principy n n n n primárním cílem je fungující software sekundárním cílem je umožnit další rozvoj projektu obsah je mnohem důležitější než reprezentace jednoduchost komunikace modelovat za určitým účelem více modelů znát své modely 47

Agilní modelování – principy / 2 n n n n n přizpůsobení metodiky maximalizovat

Agilní modelování – principy / 2 n n n n n přizpůsobení metodiky maximalizovat výnosy z investic otevřená komunikace učit se od druhých důraz na kvalitu rychlá zpětná vazba uchopit změnu inkrementální změny cestovat nalehko 48

Agilní modelování – praktiky n n n n n aktivní účast investorů používání standardů

Agilní modelování – praktiky n n n n n aktivní účast investorů používání standardů modelování využívání vzorů používání správných artefaktů kolektivní vlastnictví testovat modely paralelní vytváření různých modelů jednoduchý obsah jednoduché zobrazení modelů 49

Agilní modelování – praktiky / 2 n n n n modelování v malých přírůstcích

Agilní modelování – praktiky / 2 n n n n modelování v malých přírůstcích modelování pro komunikaci modelování pro porozumění modelování s druhými odstranění dočasných modelů veřejné vystavení modelů formalizace požadovaných modelů přechod na jiné artefakty 50

Agilní modelování – praktiky / 3 n n testování modelů kódem znovupoužití existujících zdrojů

Agilní modelování – praktiky / 3 n n testování modelů kódem znovupoužití existujících zdrojů úprava jen, když je to nezbytné používání nejjednodušších nástrojů 51

Agilní model „just barely good enough“ n n n n plní svůj účel je

Agilní model „just barely good enough“ n n n n plní svůj účel je pochopitelný je dostatečně přesný je dostatečně konzistentní je dostatečně detailní přináší kladnou hodnotu je co možná nejjednodušší 52

Agilní modelování n n n lehká metodika pro efektivní modelování postavená na prověřených modelovacích

Agilní modelování n n n lehká metodika pro efektivní modelování postavená na prověřených modelovacích technikách jde o kolekci praktik - doporučení, jak efektivně modelovat je možné ji použít v rámci jiných metodik (RUP, XP, SCRUM, FDD, . . . 53

Agilní modelem řízený vývoj Agile Model Driven Development AMDD 54

Agilní modelem řízený vývoj Agile Model Driven Development AMDD 54