Upload
nelle-leblanc
View
32
Download
3
Embed Size (px)
DESCRIPTION
Agilní metodiky. Jan Smolík. Kritéria pro členění metodik. Zaměření metodiky Rozsah metodiky Váha metodiky Typ řešení Doména. Zaměření metodiky. Globální metodiky (Enterprise Methodologies) Zaměřené na komplexní proces vývoje a provozu celého IS Projektové metodiky - PowerPoint PPT Presentation
Citation preview
Kritéria pro členění Kritéria pro členění metodikmetodikZaměření metodikyRozsah metodikyVáha metodikyTyp řešeníDoména
Zaměření metodikyZaměření metodikyGlobální metodiky (Enterprise
Methodologies)◦Zaměřené na komplexní proces
vývoje a provozu celého ISProjektové metodiky
◦Zaměřené pouze na konkrétní vývojový projekt
Rozsah metodikyRozsah metodiky Jaké fáze životního
cyklu, role a dimenze zahrnuje
Fáze◦ GST globální strategie◦ IST informační
strategie◦ UST úvodní studie◦ GAN globální analýza
a návrh◦ DAN detailní analýza
a návrh◦ IMP implementace◦ ZAV zavádění◦ PUR provoz a údržba
Dimenze◦ hardware HW ◦ technologie ◦ data/informace DATA◦ funkce/procesy FUN ◦ uživatelské rozhraní
UI ◦ pracovní PRA ◦ organizační/
legislativní ORG ◦ ekonomická EKO
Váha metodikyVáha metodikyVelikost metodiky (methodology
size) vyjadřuje počet kontrolních prvků obsažených v metodice.
Hustota metodiky (methodology specific density) vyjadřuje míru podrobnosti a těsnost tolerance metodiky a požadovanou detailnost a konzistenci prvků.
Váha metodiky = součin těchto dvou hodnot
Typ řešeníTyp řešenívývoj nového řešení ( na zelené
louce)integrace řešenírozvoj a rozšíření řešení
(upgrade)customizace a implementace
typového řešeníužití řešení
DoménaDoména
Řízení a správa obsahu
ERP
Prodej,
nákup,
sklady
Finance,
Controling,
…
Zdroje,
výroba
Aplikační architektura podnikové informatiky
Business Intelligence, manažerské aplikaceBusiness Intelligence, manažerské aplikace
CRM
e/m Business
e/m Business
Obchodní partneři
Obchodní
partneři
Vlastníci, management
Obchodníci, referenci, kontaktní
centrum
Rigidní metodikyRigidní metodikyVycházejí z přesvědčení, že procesy
při budování IS lze popsat, plánovat, měřit
Podrobný popis metod, technik a nástrojů
Dost často velmi objemnéVodopádový přístup
◦Velká většinaIterativní přístup
◦OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP)
Agilní metodikyAgilní metodikyDůvody změny metodik
◦Změna technologií, ekonomického prostředí, extrémně rychlé budování IS
Řešení se pružně přizpůsobuje měnícím se požadavkům
Nabazujína BPRJedná se výhradně o metodiky
projektové (vývoj SW)Postup vývoje SW nelze jasně
popsat
Srovnání rigorózních a Srovnání rigorózních a agilních metodikagilních metodik
Zdroj: Buchalcevová A.: Návrh metodického rámce IS/ICT, disertační práce
Manifest agilního přístupu k Manifest agilního přístupu k vývoji ISvývoji ISOdhalujeme lepší způsob vývoje
software, sami jej používáme a chceme 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.“
I přestože hodnoty napravo mají svůj smysl, my si těch nalevo ceníme více.
Zásady agilního manifestuZásady agilního manifestuNejvyšší prioritou je uspokojovat
zákazníky včasnou a kontinuální dodávkou software, který jim přináší hodnotu.
Změny požadavků je možné provést i v pozdějších fázích vývoje, neboť změna může poskytnout zákazníkovi konkurenční výhodu.
Software je dodáván často, každých několik týdnů či měsíců, přičemž se preferují kratší intervaly
Uživatelé a vývojáři spolupracují denně na projektu.
Zásady agilního manifestuZásady agilního manifestuMotivovaní jedinci, kteří mají
podmínky a podporu vedení, jsou klíčovým faktorem úspěchu projektu.
Nejefektivnějším způsobem přenosu informací v rámci vývojového týmu je vzájemná konverzace.
Primární mírou úspěchu je fungující software.
Agilní procesy předpokládají udržitelný vývoj.
Zásady agilního manifestuZásady agilního manifestuStálá pozornost perfektnímu
technickému řešení i návrhu.Jednoduchost řešení, tj. umění
maximalizovat množství neudělané práce, je zásadní.
Nejlepší architektury, požadavky a návrhy vznikají ze samoorganizujících se týmů.
V pravidelných intervalech se tým radí, jak být efektivnější a upraví podle toho své chování
Příklady agilních metodikPříklady agilních metodikDynamic Systems Development
Method (DSDM)Adaptive Software Development
( ASD)Feature–Driven Development (FDD)Extrémní programování (Extreme
Programming, XP)Lean DevelopmentScrum Crystal metodikyAgilní modelování (Agile Modeling).
ScrumScrumSlovo scrum pochází z rugbyAutoři: Ken Schwaber a Ken
SuttherlandZákladem je přesvědčení, že
vývoj SW není definovaný proces, ale empirický
ScrumScrumProces vývoje je rozdělen do 2-4
týdenních sprintůVýsledkem každého sprintu je
fungující softwareTým má sadu požadavků a na
začátku každého sprintu rozhodne, které se budou implementovat
Uživatelé mohou své požadavky měnit
Pig and Chicker rolesPig and Chicker rolesA pig and a chicken are walking
down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."
Role v projektuRole v projektuPrasečí
◦ Product Owner Reprezentuje hlas zákazníka Zařazuje požadavky do fronty Zajišťuje, že se dělají správné věci z pohledu
byznysu◦ Scrum Master
Zajišťuje, že neexistují žádné překážky ve vývoji Není lídrem (tým je samoorganizující) Zajišťuje, že proces Scrumu probíhá správně
◦ TýmKuřecí
◦ Uživatelé◦ Stakeholders (zákazníci, prodejci)◦ Manažeři
Denní scrumDenní scrumKaždý den ve stejnou dobu na stejném se
tým sejdeZačíná se přesně včas (za pozdní příchod
jsou časté týmem určené tresty)Vítáni jsou všichni, ale mluví jen prasataSchůze trvá max. 15 – 20 minut (předem
určeno týmem) – nelze prodloužitVšichni přítomní stojíKaždý člen týmu odpovídá na tři otázky:
◦ Co udělal od včerejška◦ Co bude dělat dnes◦ Zda existují nějaké překážky
Plánovací míting sprintuPlánovací míting sprintuVybere se práce, která se bude v
daném sprintu dělatUrčí se fronta sprintu (rozvržení
práce v daném sprintu)Odhadne se, kolik práce se
pravděpodobně uděláČasový limit 8 hodin
Na konci sprintuNa konci sprintuSprint Review meeting
◦ Zhodnotí se, co se udělalo a co se neudělalo
◦ Zákazníkům jsou předvedené funkční bloky (nedokončené se nesmí předvádět)
◦ Max. 4 hodinySprint Retrospective
◦ Každý účastník se musí vyjádřit k minulému sprintu
◦ Kontinuální zlepšování◦ Dvě povinné otázky
Co proběhlo dobře Co musíme příště udělat lépe
◦ Max 3 hodiny
DokumentaceDokumentaceFronta produktu
◦ Celostní pohled na produkt◦ Požadované funkce, přání, seřazené podle
hodnoty pro byznys◦ Co se bude dělat◦ Obsahuje odhady pracnosti
Fronta scrumu◦ Detailní přehled, jaké věci a kdy budou dělány
v rámci aktuálního sprintu◦ Jednotlivé úlohy plánovány, aby trvaly 4 – 16
hodinBurn down chart
◦ Veřejný přehled, toho co je hotovo a co zbývá udělat
Extrémní programováníExtrémní programováníUrčené malým až středně velkým
týmům 2 – 10 programátorůZadání se rychle mění, nebo není
jasnéSchopnost reagovat na měnící se
potřebyNení to cochcárnaAutor: Kent Beck
Aktivity XPAktivity XP Programování
◦ Programový kód je jediný užitečný výstup◦ Dovedeno k extrému je programování i způsobem
návrhu – když nevíme kudy, tak naprogramujeme varianty
Testování◦ Unit testing◦ Acceptance test
Naslouchání◦ Programátor nemusí rozumět byznysu◦ Musí naslouchat zákazníkům, aby pochopil byznys
problém a jejich potřeby Design
◦ V určitém okamžiku se stává systém příliš složitým, než abychom vystačili jen s programování, design může ušetřit zbytečné závislosti
Základní hodnoty XPZákladní hodnoty XP Komunikace
◦ Snaha o rychlé sdílení znalostí, častá verbální komunikace (oproti dokumentaci v běžných metodikách)
Jednoduchost◦ Začněme s nejjednodušším řešením, finesy
přidejme později Zpětná vazba
◦ Testy jednotek (o systému), akceptační testy (od zákazníka), (od týmu) jak dlouho bude trvat implementace požadované vlastnosti
Kuráž◦ Nebát se psát pro dnešek a ne pro zítřek◦ Nebát se refaktorizace (přepsání kódu pro zítřek)
Respekt
Praktiky XPPraktiky XP Fine scale feedback
◦ Pair programming◦ Planning game◦ Test-driven development◦ Whole team
Continuous process◦ Continuous integration◦ Refactoring or design improvement◦ Small releases
Shared understanding◦ Coding standards◦ Collective code ownership◦ Simple design◦ System metaphor
Programmer welfare◦ Sustainable pace
Jemnozrnná zpětná vazbaJemnozrnná zpětná vazba Párové programování
◦ Programuje se ve dvojicích◦ Jeden má kontrolu nad stanicí a píše (zabývá se
detaily)◦ Druhý kód neustále reviduje a zabývá se celkovým
pohledem Testem poháněný vývoj
◦ Testy jednotek jsou připraveny předem◦ Nutí programátora přemýšlet◦ Hotovo je, když programátor nemůže přijít na
žádnou další podmínku, kdy by kód mohl spadnout Celý tým
◦ Zákazník (uživatel) musí být nepřetržitě k dispozici (jako součást týmu)
Plánovací hra
Plánovací hraPlánovací hraPlánování releasu
◦Zahrnuje zákazníka◦Explorace:
zákazníci píší požadavky formou „user story“ kartiček (sepsání, odhad pracnosti)
◦Commitment: Roztřídění podle hodnoty, riziika a rychlosti Výběr implementované rozsahu
◦Řízení S požadavky je ještě možno manipulovat
Plánování iterace
Plánovací hraPlánovací hraPlánování iterace
◦Explorace Vytvořit úlohy z požadavků Zkombinovat/rozdělit úlohy, aby byly
odhadnutelné Odhadnout úlohy
◦Commitment Programátoři se přihlásí k úlohám a
odhadnou je Celkový součet úloh se porovná s faktorem
maximální zátěže (cca 35 hodin)◦Řídící fáze
Nalezení partnera, design, napsání testu jednotky, napsání kódu, provedení testu, refaktorizace, provedení testu funkčnosti
Kontinuální procesKontinuální procesNeustálá integrace
◦Všichni pracují nad aktuálním kódem◦Lokální kopie je nutno vracet často
Zlepšování designu◦Když kód začne být špatný a špatně se
dělají změny, je třeba ho refaktorovat a generalizovat
Malé releasy◦Systém je dávkován v co nejmenších
alfa releasech, aby zákazník získal povědomí o tom, co je vyvíjeno
Sdílené porozuměníSdílené porozuměníStandardy kódu
◦Na kterých se tým dohodneKolektivní vlastnictví kódu
◦Všichni jsou zodpovědní za kód jako celekJednoduchý design
◦Pokud je jednodušší cesta, je nutné ji použítSystémová metafora
◦Sdílený příběh, který jsou schopni zákazníci, programátoři i manažeři o systému říct.
◦Měl by být jasný systém pojmenovávání, aby bylo jasné, co jednotlivé třídy/metody atd. dělají
Udržitelné tempoUdržitelné tempoMělo by se pracovat max. 40
hodin týdněPokud je jeden týden přesčas,
další by neměl být