Agilní metodikyAgilní metodikyJan Smolík

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

Agile ManifestoAgile Manifesto

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

Scrum - nákresScrum - nákres

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

Plánování a zpětná vazbaPlánování a zpětná vazba