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 ◦ Zaměřené pouze na konkrétní vývojový projekt
Rozsah 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 metodiky Velikost 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í 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éna
Vlastníci, management
Aplikační architektura podnikové informatiky Business Intelligence, manažerské aplikace ERP e/m Business Obchodní partneři
CRM
Prodej, nákup, sklady
Financ e, Control ing, …
Zdroje, výroba
Řízení a správa obsahu
Obchodníci, referenci, kontaktní centrum
Obchodní partneři
e/m Business
Rigidní metodiky
Vychá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šina
Iterativní přístup ◦ OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP)
Agilní metodiky
Dů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 BPR Jedná se výhradně o metodiky projektové (vývoj SW) Postup vývoje SW nelze jasně popsat
Srovnání rigorózních a agilních metodik
Zdroj: Buchalcevová A.: Návrh metodického rámce IS/ICT, disertační práce
Agile Manifesto
Manifest agilního přístupu k vývoji IS
Odhalujeme 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 manifestu Nejvyšší 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 manifestu
Motivovaní 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 manifestu
Stá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 metodik Dynamic Systems Development Method (DSDM) Adaptive Software Development ( ASD) Feature–Driven Development (FDD) Extrémní programování (Extreme Programming, XP) Lean Development Scrum Crystal metodiky Agilní modelování (Agile Modeling).
Scrum Slovo scrum pochází z rugby Autoři: Ken Schwaber a Ken Suttherland Základem je přesvědčení, že vývoj SW není definovaný proces, ale empirický
Scrum Proces vývoje je rozdělen do 2-4 týdenních sprintů Výsledkem každého sprintu je fungující software Tý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 roles
A 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 projektu
Prasečí ◦ 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ým
Kuřecí ◦ Uživatelé ◦ Stakeholders (zákazníci, prodejci) ◦ Manažeři
Denní scrum
Každý den ve stejnou dobu na stejném se tým sejde Začí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 prasata Schůze trvá max. 15 – 20 minut (předem určeno týmem) – nelze prodloužit Vš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 sprintu Vybere se práce, která se bude v daném sprintu dělat Určí 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 sprintu
Sprint 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 hodiny
Sprint 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
Dokumentace
Fronta 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 hodin
Burn down chart ◦ Veřejný přehled, toho co je hotovo a co zbývá udělat
Scrum - nákres
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řeby Není to cochcárna Autor: Kent Beck
Aktivity 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 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 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á 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í hra
Plá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í hra
Plá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í proces
Neustá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í
Standardy kódu
◦ Na kterých se tým dohodne
Kolektivní vlastnictví kódu
◦ Všichni jsou zodpovědní za kód jako celek
Jednoduchý design
◦ Pokud je jednodušší cesta, je nutné ji použít
Systé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é tempo Mělo by se pracovat max. 40 hodin týdně Pokud je jeden týden přesčas, další by neměl být
Plánování a zpětná vazba
