}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA V B RN Eˇ FAKULTA INFORMATIKY
Agilní metodiky vývoje software D IPLOMOVÁ PRÁCE
Bc. Tomáš Kotrla
Brno, Podzim 2005
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. Barbora Zimmerová ii
Podˇekování Rád bych podˇekoval Ing. Václavu Kadlecovi za pˇredstavení zajímavého odvˇetví agilních metodik, Mgr. Barboˇre Zimmerové za cenné rady a trpˇelivost projevenou pˇri mém vedení a své matce za podporu a zázemí, které jsem mˇel bˇehem celého studia.
iii
Shrnutí Agilní metodiky vývoje softwaru jsou v poslední dobˇe rychle se rozvíjejícím odvˇetvím softwarového inženýrství, kterému mnozí odborníci pˇredpovídají slibnou budoucnost. Agilní metodiky jsou vyhledávané zejména pro svoji schopnost rychle poskytnout fungující základ systému a flexibilnˇe reagovat na mˇenící se požadavky. Práce se vˇenuje odvˇetví agilních metodik vývoje software a pro dukladnˇ ˚ ejší zkoumání si vybírá metodiky Extrémní programování, Crystal metodiky a Dynamic Systems Development Method, které popisuje a srovnává. Souˇcástí práce je náˇcrt rˇ ešení pˇrípadové studie pomocí vybraných metodik.
iv
Klíˇcová slova vývoj software, agilní metodiky, Extrémní programování, XP, Crystal metodiky, Crystal Clear, Dynamic Systems Development Method, DSDM
v
Obsah 1
Úvod . . . . . . . . . . . . . . . . . . . . . . . 1.1 Struktura práce . . . . . . . . . . . . . . 2 Agilní metodiky . . . . . . . . . . . . . . . . 2.1 Charakteristika agilních metodik . . . . 2.2 Srovnaní s klasickým pˇrístupem . . . . 2.3 Manifest agilního vývoje software . . . 2.4 Hodnocení agilních metodik . . . . . . . 3 Vybrané agilní metodiky . . . . . . . . . . . 3.1 Extrémní programování . . . . . . . . . 3.1.1 Principy . . . . . . . . . . . . . . 3.1.2 Role . . . . . . . . . . . . . . . . . 3.1.3 Postupy . . . . . . . . . . . . . . 3.1.4 Životní cyklus . . . . . . . . . . . 3.1.5 Hodnocení . . . . . . . . . . . . . 3.2 Crystal metodiky . . . . . . . . . . . . . 3.2.1 Principy . . . . . . . . . . . . . . 3.2.2 Role . . . . . . . . . . . . . . . . . 3.2.3 Postupy . . . . . . . . . . . . . . 3.2.4 Životní cyklus . . . . . . . . . . . 3.2.5 Hodnocení . . . . . . . . . . . . . 3.3 Dynamic Systems Development Method 3.3.1 Principy . . . . . . . . . . . . . . 3.3.2 Role . . . . . . . . . . . . . . . . . 3.3.3 Postupy . . . . . . . . . . . . . . 3.3.4 Životní cyklus . . . . . . . . . . . 3.3.5 Hodnocení . . . . . . . . . . . . . 3.4 Srovnání vybraných metodik . . . . . . 3.4.1 Principy . . . . . . . . . . . . . . 3.4.2 Role . . . . . . . . . . . . . . . . . 3.4.3 Postupy . . . . . . . . . . . . . . 4 Pˇrípadová studie . . . . . . . . . . . . . . . . 4.1 Výchozí podmínky . . . . . . . . . . . . 4.2 Extrémní programování . . . . . . . . . 4.3 Crystal Clear . . . . . . . . . . . . . . . . 4.4 Dynamic Systems Development Method 4.5 Srovnání životních cyklu˚ . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 2 3 5 7 10 11 12 14 15 17 19 20 22 23 24 27 29 29 30 31 33 34 35 37 37 39 41 44 44 45 49 51 52 54 55
vi
Seznam obrázku˚ 2 Agilní metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Srovnání tradiˇcních a agilních pˇrístupu˚ 3 3 Vybrané agilní metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Životní cyklus podle XP 20 3.2 Volba odpovídající metodiky z „rodiny“ Crystal 21 3.3 Cykly projektu rˇ ízeného metodikou Crystal Clear 28 3.4 Životní cyklus podle DSDM 36 4 Pˇrípadová studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Ukázka karty zadání 45 4.2 Ukázka úkolové karty 47 4.3 Ukázka bleskové plánovací karty 49
1
Seznam tabulek 2 Agilní metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Vlastnosti agilních metodik 8 4 Pˇrípadová studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ 4.1 Cást karet zadání vybraných do první iterace 46
2
Kapitola 1
Úvod Potˇreba vývoje software je stejnˇe stará, jako první poˇcítaˇce. Tato disciplína se musela vyporˇ ádat s rˇ adou problému˚ a prodˇelala tak mnoho zmˇen. Od, ve své dobˇe, revoluˇcního vývoje podle modelu vodopád se pˇres spirálový model dostala až k souˇcasným sofistikovaným pˇrístupum ˚ k vývoji software. Úspˇešným zástupce takových pˇrístupu˚ je metodika firmy IBM s názvem Rational Unified Process [8], zkrácenˇe RUP. V poslední dobˇe se však objevili nové metodiky, které smˇele slibují rychlejší a levnˇejší dodávky software. Jsou souhrnnˇe oznaˇcované jako agilní. Pˇritahují na sebe cˇ ím dal tím vˇetší pozornost a cˇ ást odborné veˇrejnosti jim pˇredpovídá slibnou budoucnost. Úkolem a cílem práce je získat pˇrehled o agilních metodikách a následnˇe je zhodnotit. Druhým úkolem je výbˇer tˇrí metodik a jejich vzájemné srovnání. Posledním úkolem je pak ukázka vývojového cyklu pomocí pˇrípadové studie.
1.1
Struktura práce
Práce je rozdˇelena na pˇet kapitol, v první uvádím zadání práce a definuji její cíle. V kapitole 2. Agilní metodiky charakterizuji agilní metodiky, vˇenuji se duvod ˚ um ˚ jejich vzniku, srovnávám je s tradiˇcními pˇrístupy a hodnotím jejich vlastnosti. Na zaˇcátku kapitoly 3. Vybrané agilní metodiky si vybírám trojici agilních metodik, kterým se v práci více vˇenuji. Každou struˇcnˇe pˇredstavuji, uvádím její principy, definované role v týmech, pˇredepsané postupy, typickou podobu vývojového cyklu a vyjadˇruji hodnocení dané metodiky. Na závˇer srovnávám principy, role a postupy vybraných metodik, pˇriˇcemž se zamˇerˇ uji vˇetšinou jen na rozdíly. V kapitole 4. Pˇrípadová studie se snažím struˇcnˇe ukázat prubˇ ˚ eh projektu ve vybraných metodikách a nakonec metodiky srovnat na základˇe jejich vývojových cyklu. ˚ Poslední kapitola je závˇerem práce, kde shrnuji výsledky práce a zabývám se možnostmi dalšího bádání v oblasti agilních metodik.
1
Kapitola 2
Agilní metodiky Tato kapitola se vˇenuje obecnˇe všem agilním metodikám, popisuje jejich pˇrístup k vývoji software, uvádí jejich spoleˇcné principy a rozdíly oproti tradiˇcním pˇrístupum. ˚ Kapitola je ukonˇcena struˇcným hodnocením obsahujícím výˇcet pozitivních a negativních vlastností agilních metodik.
2.1
Charakteristika agilních metodik
V angliˇctinˇe se agilní metodiky oznaˇcují jako „agile methodologies“. Toto spojení lze pˇreložit jako „ˇcilé“, „hbité“ nebo „živé“ metodiky. Dˇríve se užíval pojem „lightweight methodologies“, který mˇel zduraznit ˚ „lehkost“ metodik (z pohledu produkované dokumentace), tento pojem má však více ruzných ˚ významu, ˚ a tak se od jeho používání postupnˇe upustilo. Samotné pˇreklady uvedené v pˇredchozím odstavci výstižnˇe popisují cíle agilních metodik, vývoj software má být „hbitý“ (software je dodán v co nejkratším cˇ ase), „lehký“ (vývoj se omezuje jen na potˇrebné cˇ innosti a tvorbu nutných dokumentu) ˚ a „živý“ (software musí být úspˇešnˇe dodán, tedy celý projekt má pˇrežít). Vzhledem k rostoucímu poˇctu firem v oboru ICT1 získává ekonomická stránka vývoje software na významu. Pokud chce firma v konkurenci obstát, musí být schopná dodat software v co nejkratším cˇ ase a udržet pˇritom minimální náklady. Duvod ˚ je zˇrejmý, zakázku získá konkurenˇcní firma, která je schopná vyvinout software rychleji a levnˇeji. Je nutné si uvˇedomit, že se pˇri vývoji uvažují dva ruzné ˚ cˇ asy. Prvním je celkový cˇ as, který zabere realizace softwarového rˇ ešení, tedy od poˇcáteˇcního sepsání smlouvy až po akceptaci koneˇcného rˇ ešení. Druhým a významnˇejším uvažovaným cˇ asem je doba potˇrebná k dodání první fungující cˇ ásti software2 , kterou již muže ˚ zákazník používat pˇri své práci. Minimalizace právˇe druhého uvažovaného cˇ asu je pro vývoj software klíˇcová z dvou hlavních duvod ˚ u. ˚ Fungující cˇ ást software zákazníkovi pˇrináší užitek a tím i urˇcitý pˇríjem, který ˇ snižuje náklady na vývoj zbývajících cˇ ástí software. Cím dˇríve zákazník uvidí systém v provozu, tím dˇríve získává vývojový tím zpˇetnou vazbu. Dalším významným faktorem je psychologie práce ve skupinˇe. Agilní metodiky považují motivované lidi v týmu za klíˇcový pˇredpoklad pro úspˇešný vývoj. Proto se agilní metodiky zamˇerˇ ují na pracovní prostˇredí, na zajištˇení podpory všem cˇ lenum ˚ týmu, aby mohli 1. Informaˇcní a komunikaˇcní technologie (Information and Communications Technology) 2. Tento cˇ as je cˇ asto oznaˇcován zkratkou TTM (Time To Market)
2
ˇ 2.2. SROVNANÍ S KLASICKÝM P RÍSTUPEM odvádˇet svou práci co nejlépe, na vzájemnou komunikaci mezi cˇ leny týmu i mezi týmem a zákazníkem. Z pohledu agilních metodik jsou lidé významnˇejší, než dodržované postupy, produkované dokumenty nebo používané nástroje.
2.2
Srovnaní s klasickým pˇrístupem
Pˇredchozí cˇ ást kapitoly byla úvodem do oblasti agilních metodik, v této cˇ ásti jsou zduraz˚ nˇeny základní principy agilních metodik vˇcetnˇe jejich srovnání s tradiˇcními pˇrístupy. Výstižnˇe tyto ruzné ˚ pˇrístupy srovnává obrázek 2.1 pˇrevzatý z pˇrednášky Agilní metodiky [4] Aleny Buchalcevové.
Obrázek 2.1: Srovnání tradiˇcních a agilních pˇrístupu˚ Z obrázku 2.1 je patrné, že tradiˇcní pˇrístupy považují za fixní funkcionalitu, tedy podepsanou specifikaci na zaˇcátku projektu, která se dále v prubˇ ˚ ehu projektu nemˇení. Implementace takové specifikace následnˇe zabere nˇejaký cˇ as a spotˇrebuje urˇcité zdroje (platy vývojáˇru˚ a kapitál firmy). Hodnoty tˇechto promˇenných jsou pˇri plánování v úvodní fázi odhadnuty, bˇehem prubˇ ˚ ehu projektu se však mohou a cˇ asto také mˇení, vývoj pak trvá déle a stojí víc. Agilní metodiky oproti tradiˇcnímu pˇrístupu zamˇenují ˇ fixní a volné promˇenné. Na zacˇ átku se odhadnou a pevnˇe naplánují potˇrebné zdroje a cˇ as, funkcionalita je ponechána jako volná promˇenná jejíž hodnota je upravována podle aktuální úspˇešnosti projektu, jinými slovy v pˇrípadˇe problému˚ se implementace cˇ ásti funkˇcnosti odloží v zájmu dodržení termínu. Zdrojový kód jako nositel informace Jak uvádí Václav Kadlec ve své knize Agilní programování [3], agilní metodiky produkují mnohem ménˇe formální dokumentace, vycházejí totiž z pˇresvˇedˇcení, že základním, jednoznaˇcným, exaktním, nezpochybnitelným a spolehlivým nositelem informace je zdrojový 3
ˇ 2.2. SROVNANÍ S KLASICKÝM P RÍSTUPEM kód. Toto pˇresvˇedˇcení nesdílí tradiˇcní pˇrístupy, které vývoj software staví na tvorbˇe ruznˇ ˚ e objemných dokumentací (formální specifikace, detailní návrh, apod.) pˇred samotným psaním zdrojového kódu. Duraz ˚ na dokumentaci je zpusoben ˚ strachem z neúspˇešného projektu, nutností rozumného udržení znalostí a mnohdy pˇrímo vynucen uzavˇrenou smlouvou. Iterativní a inkrementální vývoj Plán projektu podle agilních metodik sestává z velmi krátkých iterací, bˇehem nichž se postupnˇe vyvíjí inkrementy výsledného software. Získává se tak dˇríve zpˇetná vazba a eliminuje riziko, kdy vývojový tým na konci dodá nˇeco, co zákazník vubec ˚ nechtˇel. Zárovenˇ tým dˇríve zjistí integraˇcní problémy. Výhody iteraˇcního a inkrementálního vývoje jsou nesporné, našli si proto své místo i mezi tradiˇcními pˇrístupy (spirálový model, iterace a buildy v metodice RUP). Agilní metodiky se tedy liší jen tím, že jejich iterace bývají vˇetšinou kratší. Pˇrímá osobní komunikace Mnoho komplikací bˇehem vývoje zpusobuje ˚ špatná komunikace a problémové vztahy mezi cˇ leny týmu. Agilní metodiky se tyto komplikace snaží rˇ ešit utužováním vzájemných vztahu˚ a zavedením cˇ asté osobní komunikace do základních cˇ inností vývoje. V každém týmu je osoba zodpovˇedná za vˇcasné zjištˇení a vyˇrešení všech komunikaˇcních problému. ˚ Osobní komunikace je považována za nejlepší zpusob ˚ pˇredání informace. ˇ Tradiˇcní pˇrístupy se vˇetšinou zabývají více cˇ innostmi vývoje než vztahy mezi lidmi. Rešení spoleˇcenských problému˚ je spíše ponecháno na umu vedoucích pracovníku. ˚ Osobní komunikace není tradiˇcními pˇrístupy samozˇrejmˇe potlaˇcována, je však vyžadována komunikace podle urˇcených formálních pravidel. Duvodem ˚ je snaha o zaznamenání všech dule˚ žitých rozhodnutí a o udržení uceleného systému znalostí. Blízká spolupráce s uživatelem Agilní týmy bˇehem své práce cˇ asto komunikují s budoucími uživateli, upˇresnují ˇ si tak potˇrebné informace o fungování zákazníkova obchodu nebo o požadavcích na software. Tato komunikace je ve stejné míˇre bˇehem celého projektu, v ideálním pˇrípadˇe jsou zástupci budoucích uživatelu˚ pˇrímo cˇ leny týmu. Tradiˇcní pˇrístupy oproti tomu s uživateli komunikují na zaˇcátku bˇehem psaní specifikace, v prubˇ ˚ ehu bˇehem obˇcasných doplnujících ˇ schuzek, ˚ pˇrípadnˇe pˇri pˇredvádˇení prototypu˚ a nakonec bˇehem akceptace dodaného software. Lze tedy rˇ íci, že komunikace je celkovˇe menší a v prubˇ ˚ ehu projektu nerovnomˇernˇe rozprostˇrená. Prubˇ ˚ ežné testování Vyvíjený software se cˇ asto bˇehem projektu mˇení, proto je duležité ˚ jeho dukladné ˚ regresní testování cˇ asto a pravidelnˇe provádˇené v prubˇ ˚ ehu celého vývoje. Znovu otestování celého software je vˇetšinou nelehký úkol, je tedy nutné software navrhovat tak, aby jeho testování 4
2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE bylo co nejsnazší a aby ho bylo možné realizovat pomocí nástroju˚ pro automatizované testování. Metodika Extrémní programování dokonce trvá na vytváˇrení pˇríslušných testu˚ dˇríve, než programátor pˇristoupí k implementaci daného požadavku. Pˇri tradiˇcním pˇrístupu etapa testování navazuje na etapu implementace. Detaily provádˇení samotných testu˚ jsou vˇetšinou specifické pro konkrétní projekt. Zpravidla je vyžadováno, aby testování a implementaci provádˇely ruzné ˚ osoby a snížila se tak pravdˇepodobnost opakování chybného porozumˇení specifikaci.
2.3
Manifest agilního vývoje software
Jednotliví autoˇri se snažili pˇri vytváˇrení metodik reagovat na nové potˇreby kladené na úspˇešný vývoj software. Dˇrívˇejší potˇrebu spolehlivého software v souˇcasnosti doplnují ˇ nové potˇreby jako ekonomická stránka vývoje nebo psychologie skupinové práce, zminované ˇ již v úvodu této kapitoly. Nejdˇríve každý autor považoval svou metodiku za ojedinˇelou, v únoru 2001 ze spoleˇcného setkání v Utahu vyplynul opak, vznikající metodiky mˇely rˇ adu spoleˇcných tezí. Vznikla tak Aliance pro agilní vývoj software [1], zastˇrešující jejich spoleˇcnou cˇ innost a byl sepsán Manifest agilního vývoje software [2], kde jsou vyjmenovány spoleˇcné teze, nˇekteré pˇreklady jmen tezí uvedených dále jsou pˇrevzaty z knížky Agilní programování [3] od Václava Kadlece. Základní myšlenky manifestu jsou: •
pˇrijmout a umožnit zmˇenu požadavku˚ je efektivnˇejší než jí bránit,
•
požadavek na zmˇenu se urˇcitˇe objeví.
Na základˇe uvedených myšlenek autoˇri manifestu dávají pˇrednost: •
individualitám a komunikaci pˇred procesy a nástroji,
•
provozuschopnému software pˇred obsáhlou dokumentací,
•
spolupráci se zákazníkem pˇred vyjednáváním formálních smluv,
•
reakci na zmˇenu pˇred striktním plnˇením plánu.
Na základˇe uvedených myšlenek a pˇredností formulovali autoˇri manifestu následující teze. Užitná hodnota pro zákazníka Zákazník má vˇetší užitek z dodaného fungujícího software než z rozsáhlé dokumentace v podobˇe UML-diagramu˚ a ERA-modelu. ˚ Metodiky proto davají vˇetší prioritu vyvíjenému software než jeho dokumentaci. 5
2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE Vítané zmˇeny Prostˇredí, ve kterém zákazník podniká, se vˇetšinou rychle mˇení, proto požadavky identifikované na zaˇcátku projektu (pˇri psaní specifikace) nemusí být na konci projektu žádané, mohou se výraznˇe zmˇenit nebo dokonce zrušit. Pˇridaní nového požadavku až v prubˇ ˚ ehu realizace projektu muže ˚ znamenat významnou konkurenˇcní výhodu pro zákazníka. Z tˇechto duvod ˚ u˚ metodiky nefixují požadavky v úvodních fázích, ale pˇrizpusobují ˚ vývoj a plánovaní mˇenícím se požadavkum. ˚ ˇ Casté dodávky Vývoj software je iterativní a inkrementální. Dodávky nových verzí jsou v co možná nejkratším intervalu. Tím získává tým od zákazníka vˇcasnou zpˇetnou vazbu a zákazníkovi pˇrináší bežící software oˇcekávaný užitek. Zákazníci spolupracují s týmem Vítané zmˇeny znamenají, že vývojový tým nemá detailní specifikaci k dispozici od zacˇ átku implementace, proto jsou nutné cˇ asté konzultace se zamˇestnanci zákazníka k upˇresnˇení specifikace. Klíˇcová motivace Základem úspˇešného vývoje jsou lidé. Ti musí být patˇriˇcnˇe motivovaní a musí jim být dána dostateˇcná duvˇ ˚ era a kompetence k dˇelání klíˇcových rozhodnutí. Vzájemná konverzace Pˇrímá konverzace je nejrychlejší a nejefektivnˇejší formou pˇrenosu informace. Pokud ji podmínky umožnují, ˇ je snadnˇejší než psaní a cˇ tení dokumentace. Úspˇech posuzujeme podle fungování Fungující software je primárním ukazatelem prubˇ ˚ ehu projektu. Udržitelný vývoj Lidé nevydrží efektivnˇe tvoˇrit, pokud musejí být v práci dlouhodobˇe pˇresˇcas. Udržitelný vývoj znamená, že lidé dlouhodobˇe nepˇrekraˇcují standardní pracovní dobu. Perfektní návrh a rˇešení Vzhledem k cˇ astým zmˇenám v požadavcích je nutné mít perfektní návrh a rˇ ešení, které umožní rychlé zapracování zmˇen do již vyvinutého systému. Zmˇena návrhu nebo zdrojových kódu˚ je považována za pˇrirozenou vˇec pˇri agilním vývoji, neznamená tedy selhání nˇekteré pˇredchozí cˇ innosti. Návrh a implementace probíhají souˇcasnˇe, navzájem se prolínají ve velmi krátkých cyklech. 6
2.4. HODNOCENÍ AGILNÍCH METODIK Jednoduchost Základem úspˇechu je udˇelat minimum práce pˇrinášející maximum užitku. Vyvíjený software je postupnˇe skládán z jednoduchých cˇ ástí, které lze snadno zmˇenit. Oˇcekávání cˇ astých zmˇen zpusobuje ˚ maximální možné odkládání implementace požadavku. ˚ Samoorganizující se tým Nejlepší výsledky mají samoorganizující se týmy obsahující schopné a kreativní cˇ leny, kteˇrí spolu cˇ asto komunikují. Zdokonalování Bˇehem vývoje se cˇ asto hledají slabá místa a zpusoby ˚ jejich odstranˇení. Stejnˇe tak se hledají silné stránky a jejich možné vylepšení. Celkovˇe tato snaha vede ke zvýšení efektivity vývojového týmu.
2.4
Hodnocení agilních metodik
Osobnˇe si myslím, že žádná metodika (ani tradiˇcní pˇrístup) nemuže ˚ zaruˇcit úspˇech každého projektu. Za nejvýznamnˇejší faktor ovlivnující ˇ úspˇech projektu považuji vlastnosti a schopnosti všech zainteresovaných lidí, které mají mnohem vˇetší vliv než používaná metodika nebo nástroje. Vycházím z pˇredpokladu, že tým rozumných, schopných a zkušených lidí si sám najde pro nˇej vhodné a potˇrebné postupy, jak kvalitnˇe a v požadovaný cˇ as (pokud je reálný) vyvinout požadovaný software. Pokud v týmu pˇrevládají lidé opaˇcných vlastností a pokud ještˇe zastávají vedoucí pozice, pak rozsáhlejší a složitˇejší projekt s velkou pravdˇepodobností skonˇcí neúspˇechem. Z jednotlivých prací a metodik autoru˚ agilního manifestu je patrné, že jejich názory jsou stejné jako muj ˚ (uvedený v pˇredešlém odstavci). Agilní metodiky tak nelze chápat jako univerzální návody jak tvoˇrit software, ale je nutné je brát jako soubor doporuˇcení, rad, návodu˚ a možných pˇrístupu, ˚ který nám poskytují na základˇe svých dlouhodobých zkušeností autoˇri metodik. Agilní metodiky obsahují rˇ adu postupu, ˚ jejichž nevhodné použití týmu pˇrinese další komplikace. V pˇrípadech kdy tyto postupy použít lze, dokáží naopak urychlit a usnadnit vývoj software. Je tedy na odpovˇednosti vedoucích pracovníku˚ rozhodnout, zda lze metodiku nebo její cˇ ást použít. V tabulce 2.1 uvádím kladné a záporné body použití agilních metodik, jejich pomˇer je vyrovnaný. Iterativní a inkrementální vývoj je nespornou výhodou, jsou urˇceny pevné termíny dodání jednotlivých verzí. Ty bohužel mají nezaruˇcený rozsah, protože nelze dopˇredu urˇcit, jaké komplikace se objeví a jak zredukují rozsah provádˇené iterace. Není známý postup, jak rozsah zaruˇcit, pravdˇepodobnˇe žádný takový postup ani nemuže ˚ existovat. Pro zákazníka je lepší vˇedomí, že v daném termínu dostane verzi s nezaruˇceným obsahem, než cˇ ekání neznámou dobu na verzi v plném rozsahu. 7
2.4. HODNOCENÍ AGILNÍCH METODIK Kladné iterativní a inkrementální vývoj brzy první verze zduraz ˚ nují ˇ význam komunikace regresní testování flexibilní reakce na zmˇeny optimalizace metodik
Záporné nezaruˇcené rozsahy verzí smlouva nelze formalizovat omezují dokumentaci testuje pˇrímo autor nadprumˇ ˚ erné schopnosti nelze na cˇ ásteˇcný úvazek
Tabulka 2.1: Vlastnosti agilních metodik Metodiky pˇristupují k implementaˇcní fázi velmi rychle, bˇehem krátké doby tak vyvinou první verzi software s omezenou funkˇcností. I tak ale vˇetšinou lze software již komerˇcnˇe využít. Na zaˇcátku projektu te tˇežké odhadnout pˇresnˇe cenu vývoje a podrobnˇe urˇcit jednotlivé milníky. Lze tedy tˇežce sepsat nˇejakou formálnˇejší smlouvu. Pro agilní metodiky je vhodnˇejší zákazník, který týmu duvˇ ˚ erˇ uje a je ochoten pˇristoupit na neformálnˇe sepsanou smlouvu. Pro zákazníka by mohl být vhodný tzv. team outsourcing, tedy pronajmutí a rˇ ízení celého týmu. Mˇel by tak lépe pod kontrolou své výdaje a práci týmu. Komunikace je pro vývoj duležitá. ˚ Myslím si, že každý tým na svˇetˇe si toho je vˇedom. Považuji za klad agilních metodik, že se snaží o nastavení podmínek k efektivní komunikaci. Nelze však spoléhat pouze na pˇrímou komunikaci. Duležité ˚ závˇery a poznatky musí být poznamenané na nˇejaké místo, kde je pujde ˚ v pˇrípadˇe potˇreby snadno dohledat. Pokud by se dokumentace zcela vynechala, tým by se mohl dostat do problému. ˚ Nelze spoléhat na vˇedomosti a znalosti obsažené jen v hlavˇe programátoru˚ a zdrojovém kódu, lidé zapomínají a jejich vlastní kód jim cˇ asem nebude dávat smysl. Testování je další nespornˇe výhodná vlastnost. Rizikem však je, pokud programátor testuje vlastní výtvor. Pˇripouštím však, že v agilním pojetí vývoje nelze cˇ ekat, až vytvoˇrí test nˇekdo další. Regresní testování poskytuje týmu velkou míru jistoty, protože jeho pomocí lze najít zavleˇcenou chybu ve všech cˇ ástech systému. Z rostoucím objemem systému však i roste rozsah potˇrebných testu˚ a tím rostou i náklady na jejich tvorbu, údržbu a bˇeh. Proto považuji za vhodnˇejší použití metody Risk Based Testing3 (RBT), kdy se testování zamˇerˇ uje jen na nejvýznamnˇejší cˇ ást systému. Urˇcení takové cˇ ásti je ale nejkomplikovanˇejším prvkem RBT. Agilní metodiky jsou cenˇené pro svou schopnost flexibilní reakce na zmˇenu požadavku. ˚ Aby toho byly schopné, potˇrebují mít v týmu schopné lidi. Tohle je ale slabé místo metodik, protože na trhu práce nemusí být dostateˇcný poˇcet uchazeˇcu, ˚ kteˇrí mají požadované znalosti a zkušenosti. V prubˇ ˚ ehu projektu pravidelnˇe vˇenují agilní metodiky urˇcitý cˇ as a úsilí k optimálnˇejšímu nastavení svých parametru. ˚ Kontrolují správnost odhadu, ˚ hledají možná zlepšení. Vývojový proces se tak postupem cˇ asu stává lépe ovladatelným a efektivnˇejším. 3. Informace lze nalézt na <www.riskbasedtesting.com/>
8
2.4. HODNOCENÍ AGILNÍCH METODIK Agilní metodiky je tˇežší realizovat v týmech zamˇestnávajících studenty na cˇ ásteˇcný úvazek, protože nejsou k dispozici po celou dobu a pˇricházejí tak o cˇ ást komunikace. Její zprostˇredkování nepˇrítomným je možné, ale zatíží a zpomalí to tým prací navíc. Agilní metodiky jsou zajímavým pˇrístupem k tvorbˇe software, své uplatnˇení naleznou pˇri projektech, ve kterých nejsou na zaˇcátku zcela jasné požadavky nebo se v prubˇ ˚ ehu projektu znaˇcnˇe mˇení. Slibují cˇ asté a pravidelné dodávky software. Vyžadují úzkou spolupráci s uživateli. Agilní metodiky nelze použít pˇri projektech, kde je provádˇení zmˇen v prubˇ ˚ ehu projektu nákladné nebo dokonce nemožné.
9
Kapitola 3
Vybrané agilní metodiky Mezi nejznámˇejší agilní metodiky patˇrí •
Extrémní programování (XP)
•
SCRUM Development Process
•
Crystal metodiky
•
Vlastnostmi rˇ ízený vývoj (FDD)
•
Dynamic System Development Method (DSDM)
•
Adaptivní vývoj software (ASD)
•
Lean Development
•
Testy rˇ ízený vývoj (TDD)
Pro dukladnˇ ˚ ejší zkoumání byly vybrány metodiky Extrémní programování, Crystal metodiky a Dynamic System Development Method, tato a následující kapitola 4 Pˇrípadová studie se jim postupnˇe vˇenují. Informace o ostatních metodikách je možné nalézt v pˇrednášce Aleny Buchalcevové Agilní metodiky [4], v knize Václava Kadlece Agilní programování [3], v diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [6] nebo v práci Agile software development methods [11]. Každá podkapitola nejprve metodiky struˇcnˇe charakterizuje. Následnˇe jmenuje principy, na kterých jsou metodiky postavené. Zabývá se rolemi, které lze identifikovat v týmech ctících danou metodiku. Poté uvádí postupy metodik odvozené z jejich principu. ˚ Je popsán životní cyklus vývoje software podle zvolené metodiky. Na závˇer je uvedeno struˇcné hodnocení metodiky. Nˇekteré detaily metodik jsou prezentovány až v následující kapitole 4 Pˇrípadová studie, spolu s náˇcrtem rˇ ešení studie vybranou metodikou. Poslední podkapitola obsahuje pˇrehledné srovnání vybraných metodik. 10
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ
3.1
Extrémní programování
Extrémní programování (XP) je jednou z nejznámˇejších agilních metodik. Pojmy XP a agilní metodiky jsou dokonce nˇekdy nesprávnˇe považovány za ekvivalentní. Tato podkapitola podrobnˇeji popisuje tuto metodiku na základˇe informací získaných z knihy Extrémní programování [12], jejímž autorem je Kent Beck. Kniha byla pˇreložena do cˇ eštiny pˇred tˇremi lety, metodika jistˇe prošla rˇ adou zlepšení, které zde tak nejsou zahrnuty. Extrémní programování vznikalo bˇehem devadesátých let minulého století na základˇe praktických zkušeností jeho autoru, ˚ kterými jsou Kent Beck a Ward Cunningham. Je postavené na známých a bˇežných postupech, ale dotahuje tyto postupy do extrému. ˚ Když se vyplácí revize, tak se reviduje neustále. Pokud je nutné testovat, tak se testuje nˇekolikrát dennˇe. XP pomocí svých principu˚ a postupu˚ dovádí do extrému všechny cˇ ásti vývoje software jako jsou revize kódu, testování aplikace, návrh architektury, integrace systému a iteraˇcní vývoj. Stejnˇe tak se XP snaží bojovat proti rizikum ˚ jako zpoždˇení harmonogramu, zrušení celého projektu, krachující systém, zvˇetšující se míra poruchovosti, nepochopení zadání, prubˇ ˚ ežné zmˇeny zadání, pˇremíra funkcí a fluktuace pracovníku. ˚ Základem celého vývoje software je pro XP psaní zdrojového kódu a testování. Prostˇrednictvím zdrojového kódu komunikují cˇ lenové týmu. Výsledky spouštˇených testu˚ vypovídají o stavu projektu. XP vychází z pˇredstavy, jak by vývoj vypadal, kdyby na nˇej bylo dost cˇ asu. Vývojáˇri by psali dobˇre strukturovaný a rˇ ádnˇe otestovaný kód. Psaní zdrojového kódu a testovaní se v metodice XP prolíná. Programátoˇri bˇehem dne stˇrídavˇe píší jednotlivé testy a implementace, nejdˇríve test jedné funkˇcnosti, následnˇe její implementaci. Když test projde, pˇrechází se na další funkˇcnost. Tento zpusob ˚ vývoje rˇ ízeného testy je možné použít jako samostatnou metodiku Test Driven Development (TDD), Kent Beck ji popisuje v knize Programování rˇ ízené testy [10]. Informace lze také nalézt v knize Václava Kadlece Agilní programování [3] nebo diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [6]. Další duležitou ˚ cˇ inností v XP je poslouchání. Kent Beck tvrdí, že nejlepším zpusobem ˚ komunikace je rozhovor, a proto je XP navrženo tak, aby maximálnˇe podporovalo a vynucovalo vzájemnou komunikaci jak mezi jednotlivými programátory, tak mezi programátory a zákazníkem. Konkrétnˇe to zajišt’ují postupy s jménem párové programování a zákazník na pracovišti, které jsou spolu s dalšími postupy vysvˇetleny v kapitole 3.1.3 Postupy. Poslední podstatnou cˇ inností pro XP je navrhování. Navrhování provádˇejí všichni programátoˇri každý den. XP klade duraz ˚ na zdrojový kód, a tak programátory nenutí ke kreslení diagramu, ˚ pokud to sami nechtˇejí. Návrh systému zaˇcíná psaním testu, ˚ kdy si musí programátoˇri dobˇre rozmyslet rozhraní vyvíjené aplikace, nebot’ právˇe toto rozhraní testují. Dalším postupem, kdy se programátoˇri plnˇe vˇenují navrhování je refaktorizace, tedy zmˇena zdrojového kódu pˇri zachování funkˇcnosti. Více je postup refaktorizace popsán v kapitole 3.1.3 Postupy, detaily pak obsahuje kniha Refaktoring [9], jejímž autorem je Martin Fowler. Pˇri své práci se snaží programátoˇri navrhnout a udržet vyvíjený systém v nejjednodušší možné podobˇe, která muže ˚ ještˇe fungovat a pˇritom pˇrináší zákazníkovi oˇcekávaný užitek. Pro rˇ ízení vývojového procesu uvažuje XP cˇ tyˇri rˇ ídící promˇenné, jsou to náklady, cˇ as, 11
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ kvalita a šíˇre zadání. Zákazníci nebo manažeˇri zadávají hodnoty tˇrí libovolnˇe zvolených promˇenných, vývojový tým pak urˇcí odpovídající hodnotu zbývající promˇenné. Tento pˇrístup vychází z jednoduchých úvah. Napˇríklad když má málo lidí v krátkém cˇ ase udˇelat moc práce, jsou ve stresu a výsledky jejich snažení nedosahují odpovídající kvality. Ve vˇetšinˇe pˇrípadu˚ stres a nereálné požadavky zpusobí ˚ zpoždˇení projektu a s tím i zvýšené náklady. Právˇe z tˇechto duvod ˚ u˚ XP rˇ íká, že týmu nelze nadiktovat hodnoty všech rˇ ídících promˇenných, ale musí mu být dáno právo urˇcit odpovídající hodnotu zbývající promˇenné. Pokud nejsou manažeˇri s odpovˇedí spokojeni, mohou si vybrat jiné tˇri promˇenné, ale nikdy nesmí urˇcovat hodnoty všech cˇ tyˇr promˇenných. Za nejvhodnˇejší volnou promˇenou pak XP považuje právˇe šíˇri zadání. 3.1.1 Principy Tato cˇ ást práce prezentuje principy XP tak, jak jsou uvedené v knize Kenta Becka Extrémní programování [12]. Prvních pˇet principu˚ je považovaných za hlavní, zbytek pak za doplnˇ kové. Rychlá zpˇetná vazba Doba reakce je duležitá ˚ kvuli ˚ uˇcení. Spoleˇcnost se nauˇcí, jak muže ˚ systém nejlépe pˇrispívat, a tento poznatek pˇredá zpˇetnou vazbou bˇehem dnu˚ cˇ i týdnu, ˚ a nikoliv bˇehem mˇesícu˚ nebo let. Programátor se nauˇcí, jak systém nejlépe navrhnout, implementovat a testovat, a tento poznatek pˇredá zpˇetnou vazbou bˇehem vteˇrin cˇ i minut, a nikoliv bˇehem dnu, ˚ týdnu˚ nebo mˇesícu. ˚ Pˇredpoklad jednoduchosti Dˇelejme systém co nejjednodušší, složitˇejší vˇeci pˇridávejme až když jsou opravdu tˇreba. Vyvíjíme pro dnešek, ne pro zítˇrek. Vˇerˇ íme ve své schopnosti kdykoliv pˇridat požadovanou funkˇcnost, nemusíme s ní tedy poˇcítat pˇredem. Jednoduchý systém se lehce testuje, je pˇrehledný a snadný na údržbu. Pˇrírustková ˚ zmˇena Nelze udˇelat velkou zmˇenu najednou. Návrh, plán a velikost týmu se musí mˇenit postupnˇe. Nemužeme ˚ vše navrhnout okamžitˇe, svuj ˚ návrh upˇresnujeme ˇ za základˇe znalostí již vyvinutého systému a zjištˇených problému. ˚ Stejnˇe tak nevíme, jak pˇresnˇe bude vývoj probíhat, proto nemuže ˚ provést dukladné ˚ plánování hned na zaˇcátku. Nejprve vytvoˇríme hrubý odhad, který postupnˇe upˇresnujeme ˇ pro každou iteraci. Je nesmyslné mít na zaˇcátku projektu tým cˇ ítající deset programátoru, ˚ pokud máme práci sotva pro dva. Dokonce i pˇrijmutí XP je postupné, po malých krocích. Nejdˇríve se použije XP na cˇ ást, se kterou má náš vývoj nejvˇetší problémy. Využití zmˇeny 12
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Nejlepší strategie je ta, která zachovává nejvíce možností a pˇritom skuteˇcnˇe vyˇreší ten nejnaléhavˇejší problém. Tento princip souvisí s pˇredpokladem jednoduchosti. Vyvíjený systém je nejjednodušší možný, který pokrývá všechny klíˇcové požadavky. Pˇridanou hodnotou využití zmˇeny je pak možnost rychle reagovat na zmˇenˇený požadavek a uvedení nové funkˇcnosti do provozu dˇrív než konkurence. Kvalitní práce Práce bude tým bavit, jen pokud ji bude odvádˇet kvalitnˇe, tedy kvalita není ve skuteˇcnosti volná promˇenná, muže ˚ nabývat jen dvou hodnot a to „vynikající“ a „neuvˇerˇ itelnˇe skvˇelá“. Kvalitní práce je duležitou ˚ složkou XP, tuto metodiku není možno provozovat s týmem neobsahujícím velmi zkušené programátory. Tým se nemusí skládat jen z výborných programátoru, ˚ musí však obsahovat alesponˇ nˇejaké, kteˇrí budou svým vlivem zdokonalovat ménˇe zkušené programátory. Výuka poznatku˚ Metodika XP se zamˇerˇ uje na výuku strategií k získávání poznatku˚ o tom, kolik testování, navrhování, refaktorizace a všeho ostatního bychom mˇeli provádˇet. Tˇemto strategiím dává pˇrednost pˇred dogmatickými postupy, jak dˇelat urˇcitou cˇ innost. Malá poˇcáteˇcní investice Nízké rozpoˇcty nutí programátory a zákazníky, aby zredukovali své požadavky a pˇrístupy. Vˇetšinou všichni vystaˇcí s nižšími prostˇredky, než které by chtˇeli. Prostˇredky však mohou být také pˇríliš malé. Hraní na výhru Vývoj programového vybavení hraný na výhru dˇelá všechno, co týmu pomuže ˚ vyhrát a nedˇelá nic, co k výhˇre nepomuže. ˚ Opakem je hraní, aby se neprohrálo, kdy se vše dˇelá pˇredpisovˇe, aby jsme byli krytí, když se projekt nepovede. Konkrétní experimenty Neotestovaná rozhodnutí pˇredstavují riziko, že nebudou správná. To znamená, že debata o návrhu nebo o požadavcích by mˇela vyústit v rˇ adu experimentu, ˚ které provˇerˇ í jejich realizovatelnost. Všechna abstraktní rozhodnutí by mˇela být takto otestovaná. Otevˇrená a upˇrímná komunikace Dobrá komunikace je jeden z nejnutnˇejších pˇredpokladu˚ úspˇešného vývoje software. Pokud je dlouhá doba odezvy, nebo nˇekdo nˇeco podstatného nesdˇelí ostatním, protože zapomnˇel nebo se bál, má to negativní vliv na celkový vývoj. Programátoˇri proto musejí mít absolutní svobodu, aby mohli vyjadˇrovat své obavy a získávat podporu, aby mohli sdˇelit nedobrou zprávu zákazníkum ˚ a manažerum, ˚ aby ji mohli sdˇelit vˇcas a aby za ní nebyli potrestáni. 13
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Práce v souladu s lidskými instinkty Lidé rádi vyhrávají. Lidé se rádi uˇcí. Lidé se rádi stýkají s jinými lidmi. Lidé mají rádi, když jsou souˇcástí týmu. Lidé jsou rádi, když mají kontrolu. Lidé jsou rádi, když se jim vˇerˇ í. Lidé rádi odvádˇejí dobrou práci. Lidé jsou rádi, když jejich software funguje. „XP se shoduje s pozorováním programátoru˚ v divoˇcinˇe“ cituje Kent Beck ve své knize [12]. Pˇrijetí odpovˇednosti Odpovˇednost musí být pˇrijata, nikoliv pˇredána. Pokud však tým dospˇeje k rozhodnutí, že je tˇreba splnit urˇcitý úkol, nˇekdo si ho bude muset vybrat bez ohledu na jeho nepˇríjemné stránky. Místní pˇrizpusobení ˚ XP nemuže ˚ být univerzální kuchaˇrkou. Každý tým, který chce XP pˇrijmout, si ho musí pˇrizpusobit ˚ vlastním podmínkám. XP muže ˚ jen upozornit na následky pˇri odboˇcení od nˇekterých jeho principu. ˚ Cestování nalehko Udržované nástroje by mˇeli splnovat ˇ tˇri vlastnosti, mˇel by jich být malý poˇcet, mˇeli by být jednoduché a hodnotné. Potˇreba jsou jen testy a zdrojový text. Poctivé mˇerˇení Mˇerˇ ení je podstatné pˇri vývoji, protože slouží ke sledování a kontrole jeho prubˇ ˚ ehu. Duležité ˚ je pro mˇerˇ ení zvolit odpovídající pˇresnost, která bude mít dostateˇcnou vypovídající hodnotu a nebude zatˇežovat tým více než je nutné. 3.1.2 Role XP v týmu uvažuje následující role. Nˇekteré mohou být obsazené stejným cˇ lovˇekem. Napˇríklad povinnosti kouˇce a stopaˇre vˇetšinou plní jeden cˇ lovˇek. Kouˇc Má na starosti celý tým. Je k dispozici jako vývojový partner, zejména pro nové programátory. Sleduje dlouhodobé cíle refaktorizací. Pomáhá programátorum ˚ s jednotlivými technickými dovednostmi jako testování, formátování a refaktorizace. Vysvˇetluje proces manažerum ˚ na vyšších úrovních. Tým by mˇel rˇ ídit spíše jemným nasmˇerováním než pomocí autoritativních pˇríkazu. ˚ Stopaˇr Jeho úkolem je sledovat aktuální metriky a hlídat, zda projekt pokraˇcuje podle plánu˚ a pˇrání. Zárovenˇ zajišt’uje, aby tým vidˇel, jak si na tom právˇe stojí. Toho dosahuje vyvˇešováním ruzných ˚ statistik na tabule v pracovní místnosti. 14
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Programátor Je základem týmu, odhaduje pracnost zadání a jednotlivých úkolu˚ bˇehem plánovací hry. Psaním unit testu˚ analyzuje požadavky a navrhuje rozhraní vyvíjeného systému. Komunikuje se zákazníkem a ostatními programátory pˇri upˇresnování ˇ požadavku˚ a jejich rˇ ešení. Bˇehem párového programování dva programátoˇri píší testy, zdrojové kódy a integrují zmˇeny do systému. Zákazník Rozhoduje, co se má dˇelat. Bˇehem plánovací hry píše karty zadání, následnˇe upˇresnuje ˇ nejasnosti, a tak se uˇcí psát karty pˇresnˇeji. V pˇrípadˇe komplikací pˇri vývoji rozhoduje, která cˇ ást funkˇcnosti má menší prioritu a muže ˚ být pˇresunuta do následující iterace a dodána až v další verzi. Zákazník s pomocí testera vytváˇrí testy funkcionality, které slouží jako akceptaˇcní testy pro dodaný systém. Tester Vˇetšinu testování v XP zajišt’ují programátoˇri, role testera pomáhá zákazníkovi vybírat a psát testy funkcionality. Zajišt’uje správný chod všech testovacích nástroju. ˚ Má na starosti pravidelné spouštˇení testu˚ funkcionality a seznámení týmu s výsledky tˇechto testu. ˚ Konzultant Pomáhá týmu ve specifických problémech, na které tým obˇcas narazí. Problémy však nikdy neˇreší sám nˇekde v ústraní, ale vždy s alesponˇ jedním programátorem, který se tímto od nˇej uˇcí. Velký šéf Zodpovídá za vývojový proces jako celek. Zajišt’uje nové lidi, když jsou potˇreba. Nemˇel by se týmu plést do cesty, pokud nemá podezˇrení, že se tým ubírá špatným smˇerem. V takovém pˇrípadˇe je na týmu, aby svoje jednání obhájilo. Když to tým nedokáže, smˇerˇ oval vývoj nejspíše špatným smˇerem a velký šéf splnil svou povinnost, když nenechal tým dál pokraˇcovat, ale naopak ho pˇrimˇel k zastavení a zamyšlení. 3.1.3 Postupy XP je založeno na dvanácti postupech, které jsou struˇcnˇe popsány v této kapitole, více informací lze najít v knize Extrémní programování [12]. Tyto postupy použité samostatnˇe mohou zpusobit ˚ projektu vážné problémy, ale dohromady tvoˇrí silný celek, který urychluje vývoj software. Plánovací hra Plánovací hra slouží v XP k rˇ ízení projektu. Zákazník jejím prostˇrednictvím rozhoduje o šíˇri celkového zadání, stanovuje priority požadavku, ˚ urˇcuje jaké funkˇcnosti spolu souvi15
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ sejí a mají se tak objevit spoleˇcnˇe v další verzi uvolnˇeného software, podle svých zámˇeru˚ (napˇríklad úˇcast na veletrhu) upravuje datum, kdy se mají jednotlivé verze uvést do provozu. Programátoˇri bˇehem plánovací hry odhadují potˇrebný cˇ as na vývoj jednotlivých požadavku, ˚ radí zákazníkovi pˇri technických rozhodnutích (napˇríklad volba databáze) a vytváˇrejí podrobný harmonogram právˇe zaˇcínající iterace. Malé verze Pro zákazníka je duležité, ˚ aby novou funkˇcnost mohl zaˇcít používat co nejdˇrív, proto XP dodává malé verze a v krátkých cˇ asových intervalech v rˇ ádu mˇesíce nebo dvou, v pˇrípadˇe rozsáhlejšího systému maximálnˇe po pul ˚ roce. Metafora Metafora zajišt’uje komunikaci mezi vývojovým týmem a zákazníkem. Je spoleˇcným „pˇríbˇehem“, kterým popisuje zákazník provádˇení stávajících procesu˚ ve své spoleˇcnosti a programátoˇri mluví o chování vyvíjeného software. V XP metafora zastupuje význam architektury. Jednoduchý návrh Vyvíjený software má neustále nejjednodušší možnou podobu, která pokrývá aktuální požadavky zákazníka. Nic se nevyvíjí dˇríve, než je to potˇreba, protože se muže ˚ stát, že to nebude potˇreba nikdy. Testování Programátoˇri pomocí testu˚ jednotek ovˇerˇ ují svuj ˚ zdrojový kód a udržují si tak víru ve své schopnosti a duvˇ ˚ eru k dˇríve vyvinuté cˇ ásti systému. Zákazník z výsledku˚ testu˚ funkcionality pozná, jaká cˇ ást systému je již úspˇešnˇe vyvinutá a kolik funkˇcnosti ještˇe chybí. Refaktorizace Programátoˇri pomocí refaktorizace udržují zdrojové kódy, tak aby neobsahovaly duplicity, aby šlo lehce pˇridat novou funkˇcnost, aby zvýšili cˇ itelnost zdrojového kódu, aby zlepšili návrh aplikace atd. Pˇri této cˇ innosti jim pomáhají hotové testy, které jim dávají jistotu, že se chování systému nezmˇenilo. Duležité ˚ je, aby programátoˇri rozlišovali, kdy refaktorují a kdy vyvíjí novou funkˇcnost, a nikdy tyto dvˇe cˇ innosti neprovádˇeli souˇcasnˇe. Párové programování Pˇri XP se zdrojový kód píše v páru, jeden programátor píše nový test, kód nebo refaktoruje, druhý mu pˇritom radí a hlídá, jestli výsledek cˇ innosti prvního odpovídá celkové strategii. První programátor pˇri své práci uvažuje jen o cˇ ásti systému, kterou mˇení cˇ i doplnuje. ˇ Dusledky ˚ pro systém jako celek musí mít na mysli druhý, v pˇrípadˇe potˇreby musí prvního opravit. Páry se mˇení vˇetšinou dvakrát za den. 16
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Spoleˇcné vlastnictví Všichni cˇ lenové týmu mají stejnou odpovˇednost za celý vyvíjený systém, proto pokud objeví nˇekde chybu nebo pˇríležitost ke zlepšení, mají pravomoc (dokonce povinnost) chybu opravit nebo zlepšení realizovat sami, namísto aby upozornily odpovˇednou osobu a cˇ ekali, až tato osoba bude mít cˇ as. Nepˇretržitá integrace Procesy testování a integrace se opakují v XP bˇehem velmi krátkého cˇ asu, vždy alesponˇ jednou za den. Pro integraci je vyhrazen pˇrímo jeden poˇcítaˇc, ke kterému si dvojice sednou, když dokonˇcí implementaci svého úkolu. Na tomto vyhrazeném poˇcítaˇci pak provedou integraci s již vyvinutým systémem, to znamená vyˇreší všechny pˇrípadné kolize, provedou pˇreklad zdrojových kódu˚ a následnˇe spustí testy. Pokud testy neprojdou na sto procent, musí chyby odstranit nebo svuj ˚ kód zahodit a zaˇcít znovu implementovat. 40hodinový týden Pˇresˇcasy jsou známkou problému˚ pˇri vývoji software. Unavení programátoˇri nemužou ˚ vyvíjet rychle a kvalitnˇe, proto XP zakazuje pˇresˇcasy v dvou následujících týdnech. Pokud je potˇreba, aby byl tým v práci dlouhodobˇe pˇresˇcas, je nezbytné rychle identifikovat a odstranit problém, který to zpusobil. ˚ To muže ˚ nakonec samozˇrejmˇe zpusobit ˚ i pˇreplánování zbytku iterace. Zákazník na pracovišti Všechny agilní metodiky mají spoleˇcný požadavek, aby byl zákazník kdykoliv k dispozici pro upˇresnˇení nejasností v zadání a poskytnutí konzultací z oboru podnikání zákazníka. Nejvhodnˇejší je, pokud je zákazník v jedné místnosti s týmem a je tak možná rychlá a pˇrímá komunikace. Zákazník sice musí být k dispozici kdykoliv, tˇežko ho však bude tým neustále zahlcovat dotazy, a tak se muže ˚ zákazník po vˇetšinu cˇ asu vˇenovat vlastní práci. Standardy pro psaní zdrojového textu Standardy jsou nutné kvuli ˚ spoleˇcnému vlastnictví kódu, všichni programátoˇri musí znát a dodržovat standardy, které si celý tým vzal za své, aby se snadno a rychle vyznali v kódu, který psal nˇekdo jiný. 3.1.4 Životní cyklus Metodika XP se pˇrizpusobuje ˚ podmínkám projektu a potˇrebám týmu, životní cyklus se proto bude projekt od projektu lišit. V této cˇ ásti práce je popsáno, jak probíhá ideální životní cyklus. Pruzkum ˚ (Exploration) 17
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Každý projekt zaˇcíná pruzkumem. ˚ Bˇehem této fáze si programátoˇri zkouší navrhnout a cˇ ásteˇcnˇe realizovat ruzné ˚ architektury plánovaného systému. Ze svých pokusu˚ pak vyberou nejvhodnˇejší architekturu. Zárovenˇ se uˇcí odhadovat, kolik cˇ asu jim zaberou jednotlivé úkoly, porovnáním odhadovaného a skuteˇcnˇe potˇrebného cˇ asu. Pokud úspˇešné zvládnutí zaˇcínajícího projektu vyžaduje po programátorech znalosti nové technologie, seznamují se s touto technologií právˇe v této fázi. Zárovenˇ tato fáze slouží k ovˇerˇ ení výkonnostních limitu˚ požadovaného systému. Ovˇerˇ ení je provádˇeno pomocí vhodných prototypu. ˚ Ve stejné dobˇe se zákazník uˇcí psát své požadavky v podobˇe karet zadání, aby byly srozumitelné pro programátory. V této etapˇe by mˇel sepsat požadavky na první verzi systému. Délka etapy je závislá na znalostech a zkušenostech programátoru˚ s danými nástroji, technologiemi a oborem podnikání zákazníka, pohybuje s v rozmezí nˇekolika týdnu˚ až mˇesícu, ˚ pˇriˇcemž by nemˇela pˇresáhnout pul ˚ roku. Plánování Etapa plánování navazuje na etapu pruzkumu. ˚ Pokud se bˇehem pruzkumu ˚ zákazník i tým dostateˇcnˇe pˇripraví, pak samotná etapa plánování trvá jeden cˇ i dva dny, bˇehem nichž se vyberou karty zadání pro první verzi systému a dohodne se termín jejího uvolnˇení. Tento termín bývá v období následujících dvou až šesti mˇesícu. ˚ Pokud je tým schopen první verzi dodat dˇrív, je to jen dobˇre, ale vˇetšinou se to nestává. Naopak doba delší než šest mˇesícu˚ znamená zvýšení rizika. Iterace do uvolnˇení první verze Iterace, které probíhají do uvolnˇení první verze, trvají jeden až cˇ tyˇri týdny. Pro první iteraci se vybírají taková zadání, aby pokryla celý systém, tedy aby výsledkem první iterace byla kostra systému. Která zadání jdou do dalších iterací rozhoduje zákazník na základˇe svých priorit. Na konci každé iterace by mˇela být malá oslava dodání plánované funkcionality. Výsledkem poslední iterace je pak první verze software urˇcená k nasazení do ostrého provozu. Zprovoznování ˇ Tato etapa slouží k nasazení první verze systému k zákazníkovi. Nejprve je nutné systém dukladnˇ ˚ e otestovat, pˇrípadnˇe pomocí paralelního testování nového a starého systému. Zárovenˇ se v této dobˇe tým pokouší o vyladˇení výkonu, protože má už dostatek znalostí o systému a zárovenˇ má k dispozici provozní hardware. Bˇehem této etapy vˇetšinou dochází ke zkrácení iterace ze tˇrí týdnu˚ na jeden. Zárovenˇ dochází i ke zpomalení vývoje, protože veškeré zmˇeny musejí být lépe promyšleny, nebot’ systém je už nasazen do ostrého provozu. Nové myšlenky tykající se implementace se sepíší a odloží do následujících iterací. Nasazení systému je vhodné uzavˇrít menší oslavou, jde totiž o významný okamžik celého projektu. 18
3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Údržba Po nasazení systému do ostrého provozu dochází ke zpomalení vývoje. Jedním z duvod ˚ u˚ je, že programátoˇri musejí vedle implementace nových úkolu˚ zárovenˇ zajišt’ovat servis bˇežící aplikace. Proto je vhodné v tento okamžik pˇribrat nové programátory do týmu. Jejich rychlé zaškolení je realizováno pomocí párového programování se zkušenˇejším kolegou. Vývoj dalších verzí zaˇcíná vždy pruzkumem, ˚ v rámci nˇehož se mužeme ˚ pokusit o odvážnou zmˇenu architektury nebo muže ˚ zákazník pˇrijít s novým pˇrelomovým zadáním. Tým však musí být více opatrný, protože pracuje s ostrými daty a bˇežícím systémem. Zárovenˇ se musí snažit o co nejˇcastˇejší sluˇcování nového zdrojového kódu s provozním, aby se pozdˇeji vyhnul velkým integraˇcním problémum. ˚ Tým muže ˚ pˇredem odhadovat, jak jeho efektivitu sníží soubˇežný servis bˇežícího systému. Duležité ˚ je tyto odhady bˇehem údržby potvrdit nebo vyvrátit pomocí mˇerˇ ení. Stejnˇe tak je vhodné programátory poskytující servis postupem cˇ asu prostˇrídat. Bˇehem servisu se mohou nauˇcit mnoho duležitých ˚ vˇecí, na druhou stranu jim jejich práce nepˇrijde tak zábavná, jako pˇri implementaci nových úkolu. ˚ Smrt Smrt znamená konec vývoje systému. Ten muže ˚ nastat ze dvou duvod ˚ u. ˚ Ménˇe cˇ astým duvodem ˚ je, že zákazník nemá už žádné nové zadání, které by chtˇel realizovat a systém ˇ eji je však ukonˇcení je dokonale vyladˇený, tudíž vývojový tým nemá, co by víc udˇelal. Castˇ vývoje zpusobeno ˚ neschopností vývojového týmu pˇridat efektivnˇe novou funkcionalitu. Bˇehem této etapy se sepisuje nˇekolikastránkový dokument o vyvinutém systému, který by mˇel týmu pomoci, kdyby se k systému po cˇ ase vrátil. Taktéž je vhodné prozkoumat pˇríˇciny, které vedly k ukonˇcení vývoje, a vzít si z nich pouˇcení do dalších projektu. ˚
Jednotlivé etapy životního cyklu vývoje software podle metodiky XP shrnuje obrázek 3.1 pˇrevzatý z práce Agile software development methods [11]. 3.1.5 Hodnocení Metodika XP se hodí do prostˇredí, ve kterém se požadavky cˇ asto mˇení nebo pˇricházející až bˇehem samotného vývoje, nebot’ je zmˇenˇe otevˇrená, požadavky v podobˇe karet zadání mužou ˚ pˇrijít kdykoliv a nejpozdˇeji v následující iteraci na nˇe tým i reaguje. Na druhou stranu XP potˇrebuje prostˇredí, ve kterém je cena zmˇeny víceménˇe konstantní, nelze ho tedy použít tam, kde cena zmˇeny s postupem cˇ asu rapidnˇe roste. V tˇechto pˇrípadech je nejdˇríve nutná dukladná ˚ analýza a celý vývoj by nešel s XP skloubit. Dále v XP vidím cˇ tyˇri potencionální rizika. Hrozí, že programátory refaktorizace zaujme tak, že ji budou dˇelat poˇrád a nevyvinou žádnou novou funkcionalitu. Vývoj se muže ˚ dostat do slepé uliˇcky, ze které nebude cesta ven, jen proto, že se celou dobu navrhuje pro dnešek a nemyslí se na zítˇrek. Dalším nedostatkem je fakt, že bˇehem plánování se dostateˇcnˇe neuvažuje závislosti mezi jednotlivými úkoly. A za poslední nedostatek, cˇ ásteˇcnˇe rˇ ešený pomocí 19
3.2. CRYSTAL METODIKY
Obrázek 3.1: Životní cyklus podle XP
párového programování, považuji skuteˇcnost, že zdrojový kód a jeho test píše stejný cˇ lovˇek, tudíž hrozí, že jeho chyba bude jak v kódu, tak v testu a ve výsledku zpusobí ˚ funkˇcní test a tedy neodhalení této chyby. Metodiku XP celkovˇe považuji za zajímavou možnost, jak vyvíjet software. Spíše než její samostatné použití bych však doporuˇcil kombinaci s jinou metodikou, která bude robustˇ nˇejší a odstraní nedostatky XP. Clánky o spoleˇcném použití XP a metodik jako RUP, SCRUM, Prince a dalších lze najít na serveru Aliance agilního vývoje software [?].
3.2
Crystal metodiky
Crystal není jméno jedné metodiky, ale slouží k oznaˇcení celé „rodiny“ metodik, které vymyslel Alistair Cockburn. Jednotlivé metodiky jsou pojmenované podle barev a navzájem se ˇ odlišují svou vhodností pro ruznˇ ˚ e velké týmy a ruznˇ ˚ e složité projekty. Cím tmavší barva je, tím je metodika robustnˇejší a vhodnˇejší pro rozsáhlejší, pˇrípadnˇe kritiˇctˇejší projekty. Jednotlivé barvy jsou cˇ irá, žlutá, oranžová, cˇ ervená, hnˇedá, modrá a fialová. Tyto metodiky nejsou pˇresné „kuchaˇrky“, ale obsahují rˇ adu rad, jak je pˇrizpusobit ˚ vlastním potˇrebám. Vhodná metodika pro projekt se volí na základˇe hodnot tˇrí následujících vlastností projektu. První vlastností je velikost vývojového týmu, tedy kolik lidí se úˇcastní vývoje. Druhou vlastností je kritiˇcnost projektu, která ohodnocuje dopad selhání systému a muže ˚ nabývat cˇ tyˇr hodnot. 20
3.2. CRYSTAL METODIKY •
Ztráta komfortu (C) je nejmenší dopad, kdy lze systém i nadále používat, ale uživatele to stojí zvýšené úsilí.
•
Malá ztráta penˇez (D) má vˇetší dopad, v tomto pˇrípadˇe firma kvuli ˚ selhání ztratí nˇejaké finance.
•
Velká ztráta penˇez (E) je podobný dopad, jako pˇredchozí, tentokrát ovšem firma ztrácí nezanedbatelnou cˇ ást svých financí.
•
Ztráta lidských životu˚ (L) je nejhorším možným dopadem.
Poslední vlastností, podle které se rˇ ídí výbˇer správné metodiky, je priorita projektu. Tato vlastnost vyzdvihuje tu stránku projektu, která má pro nás nejvˇetší význam. Mužeme ˚ se rozhodnout, zda budeme prubˇ ˚ eh projektu optimalizovat pro maximální produktivitu vývoje nebo dáme pˇrednost napˇríklad dukladnému ˚ mˇerˇ ení postupujícího projektu. Volbu vhodné metodiky ilustruje obrázek 3.2 pˇrevzatý z práce Agile software development methods [11]. ˇ Ctvereˇ ckovanˇe jsou na obrázku oznaˇceny oblasti, které jsou nedosažitelné nebo pro které neexistuje pˇríslušná Crystal metodika.
Obrázek 3.2: Volba odpovídající metodiky z „rodiny“ Crystal Robustnˇejší metodiky jsou postupnˇe navrhovány a ovˇerˇ ovány v praxi. Já se v této práci zamˇerˇ il na základní metodiku s cˇ irou barvou (Crystal Clear), která spadá do kategorie D6, 21
3.2. CRYSTAL METODIKY tedy je urˇcená pro tým cˇ ítající od dvou do osmi lidí, kdy pˇri selhání firma ztrácí malou cˇ ást financí. Má volba byla ovlivnˇena ostatními metodikami, nebot’ jsem chtˇel srovnávat metodiky urˇcené pro pˇribližnˇe stejnˇe velké týmy. Mou volbu ovlivnil také fakt, že v knihovnˇe je k dispozici pomˇernˇe nová kniha Crystal Clear [5], ze které jsem tak mohl cˇ erpat. 3.2.1 Principy Metodika Crystal Clear vychází ze sedmi principu, ˚ z nichž první tˇri jsou nutné pro fungování metodiky a další cˇ tyˇri jen zvyšují pravdˇepodobnost úspˇešnosti celého projektu, posouvají projekt dál v „zónˇe bezpeˇcnosti“ (Safety zone). Alistair Cockburn v druhé kapitole své knihy Crystal Clear [5] uvádí dále jmenované principy jako vlastnosti metodiky Crystal Clear. Pravidelné dodávky (Frequent delivery) Pro vývoj systému˚ je duležité ˚ pravidelné uvolnování ˇ nových verzí. Získáváme tak cˇ astou a pravidelnou zpˇetnou vazbu od uživatelu. ˚ Stejnˇe tak má vedení lepší pˇrehled o pru˚ bˇehu vývoje. Z pohledu tohoto principu nemá délka jedné iterace takový vliv, jako interval mezi uvolnˇením jednotlivých verzí systému. Pro programátory muže ˚ být duležité, ˚ aby zadaní nebylo bˇehem iterace mˇenˇeno a oni se tak mohli plnˇe soustˇredit na rˇ ešení jednotlivých úkolu. ˚ Zdokonalování procesu˚ (Reflective improvement) Pˇri práci je duležité ˚ pouˇcení se z vlastních chyb. Proto se tým jednou za cˇ as sejde, aby prodiskutoval proces vývoje, našel jeho silné i slabé stránky a pokusil se najít zpusob, ˚ jak proces v dalších iteracích vylepšit. Pravidelnost, stejnˇe jako prubˇ ˚ eh a druh výstupu tˇechto zdokonalovacích schuzek, ˚ je ponechána na úvaze týmu. Metodika jen trvá na jejich konání a dává nezávazné rady. Podprahová komunikace (Osmotic communication) Jedná se o velmi duležitý ˚ princip, objevující se i v jiných metodikách, který lze bohužel snadno realizovat jen v malých týmech s vhodným návrhem pracovního místa. Spoˇcívá ve spoleˇcné práci všech vývojáˇru˚ na jednom místˇe. Každý cˇ len týmu je tak pˇrítomen a podprahovˇe vnímá každou relevantní komunikaci. Pokud má co rˇ íct, muže ˚ rychle a efektivnˇe sdílet své vˇedomosti. Pˇrátelské prostˇredí (Personal safety) Cílem je pracovní kolegy vnímat jako pˇrátele. Programátor se nesmí bát oznámit šéfovi problémy s vývojem nˇekteré cˇ ásti systému. Musí umˇet upozornit kolegu na chybu v jeho kódu nebo naopak být schopen požádat o pomoc s vlastním kódem. Nesouhlasné názory na návrh architektury se nesmí projevit ve vzájemných citech. Takové prostˇredí se kladnˇe projeví i pˇri zdokonalování vývojového procesu. 22
3.2. CRYSTAL METODIKY Pozornost (Focus) V tomto principu se skrývají dvˇe velké myšlenky. Vývojáˇr musí mít na pamˇeti, které dva úkoly z probíhající iterace má na starost. Práce na tˇechto úkolech má pro nˇej pak nejvˇetší prioritu. Aby se této práci mohl plnˇe vˇenovat zajišt’uje druhá myšlenka. Vývojáˇr dˇelá minimálnˇe dva pracovní dny práci pro jeden projekt, pak muže ˚ další dva dny dˇelat pro jiný projekt. Nemusí tedy cˇ asto pˇreskakovat mezi úkoly pro ruzné ˚ projekty. Každý den má zaruˇcené dvˇe hodiny, kdy nebude od své práce vyrušován. Dostupnost uživatelu˚ Programátoˇri bˇehem vývoje si cˇ asto potˇrebují ujasnit zadání, proto je potˇreba aby kompetentní (expertní) uživatel byl dostupný v dostateˇcnˇe krátkém cˇ ase. Je potˇreba rozlišit konzultace s uživateli od konzultací s doménovým expertem (Bussiness expert), který je vˇetšinou pˇrímo souˇcástí týmu. Realizováno to je napˇríklad tak, že uživatel je pravidelnˇe jednou týdnˇe osobnˇe k dispozici na spoleˇcné schuzce ˚ se všemi programátory a zbytek týdne konzultuje s vývojáˇri pˇrípadné problémy telefonicky. Technické vybavení Rychlý a kvalitní vývoj systému˚ je potˇreba podpoˇrit patˇriˇcným technickým vybavením a osvˇedˇcenými postupy. Použití konfiguraˇcního managementu a spouštˇení automatizovaných testu˚ musí být pro tým samozˇrejmostí. Významnou roli také hrají krátké iterace a pˇredevším cˇ astá integrace nových cˇ ástí s existujícím systémem.
Uvedené principy jsou spoleˇcné pro všechny metodiky rodiny Crystal, s výjimkou principu Podprahová komunikace. Tento princip je v ostatních metodikách rodiny huˇ ˚ re realizovatelný, protože vývojový tým je už moc velký, pˇrípadnˇe rozmístˇen do více kanceláˇrí. 3.2.2 Role Crystal clear se od ostatních barev liší pˇredevším tím, že se projektu úˇcastní pouze jeden tým, který sdílí spoleˇcnou kanceláˇr. Tento tým obsahuje maximálnˇe osm lidí, proto jeden cˇ lovˇek vˇetšinou zastává nˇekolik z uvedených rolí. Práci rolí tester nebo písaˇr, naopak vˇetšinou dˇelá kdokoliv v týmu, kdo má zrovna cˇ as. Sponzor (Executive Sponsor) Stejnˇe jako metodiky DSDM má tato role na starost financování projektu, na který se dívá z dlouhodobého pohledu. V krátkodobém pomˇeru balancuje priority jednotlivých požadavku, ˚ rozsah a cenu plánovaných verzí. 23
3.2. CRYSTAL METODIKY Uživatel (Expert user) Jedná se o zástupce uživatelu, ˚ kteˇrí budou používat nebo již používají vyvíjený systém. Týmu je užiteˇcný svými konzultacemi a testováním jak funkˇcních vlastností, tak použitelnosti systému. Zná cˇ etnosti jednotlivých obchodních procesu˚ a souvisejících operací. Radí pˇri návrhu systémových rozhraní. Hlavní vývojáˇr (Lead designer) ˇ Clovˇ ek v této roli dˇelá stejnou práci jako ostatní obsazení v roli vývojáˇr, rozdíl je však v tom, že znalosti hlavního vývojáˇre v oblasti návrhu architektury, programování systému a projektových procesu˚ jsou na mnohem vyšší úrovni. Duležité ˚ nebo složité úkoly proto obstarává tato role. V malém týmu, který má Crystal Clear, se málokdy najde víc než jeden cˇ lovˇek schopný zastávat tuto roli. Vzhledem k duležitosti ˚ role bývá tento jediný cˇ lovˇek cˇ asto pˇretˇežován. Je tedy potˇreba, aby maximum svých jednodušších úkolu˚ delegoval na ostatní. Vývojáˇr (Designer-programmer) Navrhování bez programování muže ˚ produkovat tˇežce realizovatelné návrhy, protože osobˇe chybí právˇe zpˇetná vazba z programování. Proto každý cˇ lovˇek v roli vývojáˇre systém navrhuje i programuje. Doménový expert (Business expert) Na rozdíl od uživatele musí mít tato role všeobecný pˇrehled o podnikání zákazníka. Ví jak jednotlivé procesy podnikání probíhají, jakými se rˇ ídí pravidly, jak cˇ asto se mˇení apod. Koordinátor (Coordinator) Koordinuje práci ostatních, zaznamenává a zpˇrehlednuje ˇ prubˇ ˚ eh projektu pro sponzora. Musí mít dobré spoleˇcenské cítˇení, schopnosti podporovat diskusi a urovnávat spory. Tester (Tester) Testuje vyvíjený systém a objevené chyby zaznamenává do seznamu chyb (Bug report). Písaˇr (Writer) Má na starost tvorbu uživatelské dokumentace (User Help Text). 3.2.3 Postupy V metodice Crystal Clear se místo o praktikách mluví o strategiích a technikách. Metodika ovšem nediktuje použití žádné strategie ani techniky, v této oblasti dává týmu úplnou svobodu. Tým tedy muže ˚ zustat ˚ u svých nauˇcených postupu, ˚ pˇrípadnˇe muže ˚ použít postupy z jiné metodiky než z rodiny Crystal. 24
3.2. CRYSTAL METODIKY Pro usnadnˇení pˇrijmutí Crystal Clear jako nové metodiky Alistair Cockburn ve své knize ˚ do zaˇcátku alesponˇ výbˇer doporuˇcených postupu. ˚ Jedná se o následují[5] dává zájemcum cích pˇet strategií a sedm technik. Strategie jsou: Pruzkum ˚ (Explory 360) Nejdˇríve se zkoumá, zda má celý projekt vubec ˚ smysl. Jestli je realizovatelný za rozumných ekonomických podmínek. Jestli má tým dostatek zkušeností s potˇrebnými technologiemi. Celý pruzkum ˚ trvá od nˇekolika dnu˚ po jeden až dva týdny, jeho výsledkem je bud’ spuštˇení projektu nebo jeho zamítnutí. Pˇri rozhodování se zjišt’uje pˇridaná hodnota plánovaného systému pro zákazníka. Identifikují se hlavní pˇrípady užití, budoucí uživatelé systému, požadavky na systém. Vytváˇrí se doménový model, zkouší se technologie, odhaduje se hrubý plán vývoje. Na závˇer se všechny získané poznatky prodiskutují na spoleˇcném workshopu. Motivující úspˇech (Early victory) Dosažený úspˇech lidi dobˇre motivuje v jejich další práci. Toho se dá využít tak, že projekt zaˇcneme realizací nejsnazších požadavku. ˚ S velkou pravdˇepodobností budeme úspˇešní, motivuje tým do další iterace, uživatelé brzo uvidí první náˇcrt systému, zákazník bude spokojený, že vývojový proces funguje. Tahle strategie je pravým opakem doporuˇcení udˇelat nejkomplikovanˇejší vˇeci jako první, abychom co nejdˇríve snížili riziko neúspˇechu. Cockburn doporuˇcuje nechat nejtˇežší vˇeci až jako druhý úkol. Následnˇe dodává, že z ekonomického hlediska je nejvýhodnˇejší nejdˇríve realizovat požadavky s nejvyšším pˇrínosem pro obchod. Bˇežící kostra (Walking skeleton) Cílem úvodní fáze projektu je co nejdˇríve vytvoˇrit fungující kostru budoucího systému. Tato kostra postrádá ze zaˇcátku témˇerˇ veškerou požadovanou funkcionalitu. Jejím úkolem je však propojit jednotlivé cˇ ásti systému jako napˇríklad rozhraní a databázi, cˇ ímž se zvýší možnost paralelního vývoje v následujícím období. Je nutné si uvˇedomit, že tato kostra neslouží k ovˇerˇ ení technologií, ale je už skuteˇcným základem vyvíjeného systému, rˇ ádnˇe provˇerˇ eným pomocí testu. ˚ Bˇehem následujícího období bude nejspíše zdrojový kód kostry mˇenˇen a zdokonalován, pro vývoj je však duležité ˚ mít nˇejakou funkˇcní podobu co nejdˇríve. Inkrementální architektura (Incremental Rearchitecture) Bˇežící kostru je nutné zdokonalit. To lze nejlépe realizovat pomocí inkrementálních zmˇen architektury navrhovaného systému. Zárovenˇ s provádˇenými zmˇenami architektury jsou inkrementálnˇe mˇenˇeny funkcionalita a rozhraní systému. Rozsáhlou architekturu nelze navrhovat jinak než inkrementálnˇe, mozek žádného návrháˇre nedokáže rozumnˇe uchopit tak rozsáhlou abstrakci, i o cˇ ásti architektury lze efektivnˇe 25
3.2. CRYSTAL METODIKY pˇremýšlet po dobu maximálnˇe dvou týdnu. Informaˇcní tabule (Information Radiators) Smyslem informaˇcních tabulí je prezentovat informace o prubˇ ˚ ehu projektu na snadno dostupných místech. Jde o informace, jejichž opakované sdˇelování vedení by tým zbyteˇcnˇe zdržovalo. Také jsou takto prezentovány informace užiteˇcné pro samotný tým. Doporuˇcené techniky jsou: Nastavení metodiky (Methodology shaping) Na zaˇcátku projektu se nejprve nastaví prvotní parametry metodiky. Dˇeje se tak na spoleˇcném workshopu, kde cˇ lenové týmu diskutují o svých pˇrednostech a slabinách. Hledají se postupy, které pˇrednosti vyzvednou a maximálnˇe eliminují rizika plynoucí ze slabin. Zdokonalující workshop (Reflection workshop) Jednou za cˇ as, vˇetšinou po uvolnˇení nové verze, se tým sejde a probere své pocity z probíhajícího procesu vývoje. Tato schuzka ˚ slouží k prubˇ ˚ ežnému upravení parametru˚ metodiky nastavených pˇredešlou technikou. Tým urˇcuje postupy, které chce i nadále zachovat. Opˇet se identifikují problémy s vývojem a hledá se zpusob ˚ jejich odstranˇení. Navrhují se nové postupy, které mají vyzkoušet bˇehem následující iterace. Bleskové plánování (Blitz planning) Toto plánování se používá pro horizont pˇríštích tˇrí mˇesícu. ˚ Pˇri plánování se sejdou sponzor, zástupci budoucích uživatelu˚ a celý vývojový tým. Jako alternativu lze použít i plánovací hru metodiky XP. Na kartiˇcky se sepíší všechny identifikované úkoly. Tyto úkoly vývojový tým doplní o své odhady pracnosti. Pokud je k realizaci potˇreba konkrétní cˇ lovˇek, je jeho jméno doplnˇeno na kartiˇcku. Plánování je realizováno pˇresouváním kartiˇcek na stole podle priorit pro zákazníka, návazností jednotlivých úkolu˚ a s pˇrihlédnutím na zatížení pˇrípadných lidí, kteˇrí jsou na kartiˇcce uvedení jako nutní k realizování úkolu. Vˇeštˇení doby trvání (Delphi estimation) Na zaˇcátku je tˇežké pˇresnˇe urˇcit dobu trvání jednotlivých úkolu. ˚ Nemáme jinou možnost než použít expertní odhady. Odhadují se poˇcet tˇríd, jejich nároˇcnost, potˇrebné znalosti vývojáˇru. ˚ Konkrétní pˇríklad uvádí Cockburn ve své knize. Denní schuzky ˚ (Daily stand-ups) Tato technika pochází z metodiky SCRUM. Každé ráno se celý tým sejde na pár minut a probere, co kdo udˇelal, co bude dˇelat a jaké má problémy. Tyto problémy jsou bˇehem schuzky ˚ pouze identifikovány, nikoliv rˇ ešeny, proto celá schuzka ˚ netrvá déle než cˇ tvrt hodiny. Problémy se pˇrípadnˇe rˇ eší až po schuzce ˚ v kruhu zainteresovaných lidí. 26
3.2. CRYSTAL METODIKY Optimalizace rozhraní (Essential interaction design) Tuto techniku Cockburn pˇrejímá od Jeffa Pattona a ve své knize [5] ji detailnˇe popisuje. Já na tomto místˇe práce jen krátce naznaˇcím její význam a cíle. Ruzné ˚ skupiny budoucích uživatelu˚ budou pracovat se systémem ruzným ˚ zpusobem, ˚ proto mají na systém ruzné ˚ požadavky a ruzné ˚ oˇcekávání. Asi se nám nepodaˇrí vyhovˇet všem skupinám, musíme tedy identifikovat jednu nebo dvˇe nejduležitˇ ˚ ejší a pro uživatele tˇechto skupin optimalizovat rozhraní vyvíjeného systému. Miniprojekt (Process miniature) Pro cˇ lovˇeka seznamujícího se s novou metodikou je ze zaˇcátku tˇežké chápat závislosti mezi jednotlivými procesy. Cockburn doporuˇcuje uspoˇrádat pro nováˇcky malý projekt trvající maximálnˇe den, pˇri kterém si vše vyzkouší a uvidí závislosti mezi jednotlivými procesy. Blízké programování (Side-by-side programming) Jde o lehˇcí verzi párového programování, které definuje metodika XP. Cockburn považuje za vhodnˇejší, pokud programátoˇri pracují každý na svém úkolu na vlastním poˇcítaˇci. Sedí však dostateˇcnˇe blízko sebe, takže vidí na monitor druhého a jsou mu k dispozici ke konzultaci. Pˇrírustkové ˚ grafy (Burn charts) Technika urˇcená k jednoduché, rychlé a pˇrehledné prezentaci pokroku pˇri vývoji. Na viditelné místˇe je umístˇen a pravidelnˇe aktualizován graf, na jehož horizontální ose je cˇ as a na vertikální mˇerˇ itelná jednotka pokroku. Vhodnou jednotkou na ose pokroku je taková, která je bˇehem celého procesu vývoje známá. Nebude jí tedy poˇcet rˇ ádku˚ zdrojového kódu (celkový poˇcet je znám až na konci poslední iterace), lepší je použití napˇríklad poˇcet pˇrípadu˚ užití. Pˇri úvodním plánování se do grafu nanese k jednotlivým milníkum ˚ pˇredpokládané procento implementovaných pˇrípadu˚ užití ze všech požadovaných a tˇemito body je proložena kˇrivka. Opakovanˇe (napˇríklad na konci každé iterace) je do grafu zaneseno skuteˇcné procento navržených, naprogramovaných a otestovaných pˇrípadu˚ užití. 3.2.4 Životní cyklus Projekt rˇ ešený metodikou Crystal Clear je tvoˇren skupinou do sebe vnoˇrených cyklu˚ ruz˚ ných délek. Tˇemito cykly jsou vývoj, iterace, dodávka a celý projekt. Jejich vzájemné usporˇ ádání ukazuje obrázek 3.3. Ve zbytku podkapitoly jsou postupnˇe popsány jednotlivé etapy, k cˇ emuž jsou hojnˇe používány pojmy vysvˇetlené v pˇredchozích cˇ ástech práce 3.2.3 Postupy a 3.2.2 Role. Projekt zaˇcíná etapou nazvanou mapování. Bˇehem ní je nejdˇríve sestaven tým, duraz ˚ je kladen na vhodné obsazení rolí sponzor, hlavní vývojáˇr a uživatel. Tým je podle potˇreby doplnˇen o asi dva až pˇet vývojáˇru. ˚ Dále je realizována strategie pruzkum ˚ nebo nˇekterá její 27
3.2. CRYSTAL METODIKY
Obrázek 3.3: Cykly projektu rˇ ízeného metodikou Crystal Clear
alternativa pˇrevzatá napˇríklad z metodiky RUP. Následuje technika nastavení metodiky. Na závˇer se vytvoˇrí prvotní plán projektu. K jeho tvorbˇe muže ˚ být použita již zminovaná ˇ technika bleskové plánování, nebo nˇekterá její alternativa používaná metodikou DSDM, SCRUM, nebo XP. Po etapˇe mapování následují cˇ asovˇe dlouhé cykly pojmenované dodávka, skládající se z jedné nebo nˇekolika iterací, popsaných dále. Minimálnˇe na konci etapy je nový inkrement dodán alesponˇ nˇekterým uživatelum, ˚ kteˇrí otestují novou funkcionalitu a pˇredevším informují tým o použitelnosti nových obrazovek. Bˇehem dodávky je alesponˇ jednou uskuteˇcnˇen zdokonalující workshop, kdy je pˇrezkoumán a vylepšen proces vývoje. Délka jedné iterace se muže ˚ pohybovat mezi jedním týdnem a dvˇema mˇesíci. Obˇe uvedené hodnoty jsou extrémní a vyžadují velkou opatrnost. Pˇri dlouhé iteraci nesmí tým zapomenou na prubˇ ˚ ežné ukázky systému uživatelum ˚ kvuli ˚ vˇcasné zpˇetné vazbˇe. Krátká iterace zase vyžaduje rozdˇelení požadavku˚ na velmi malé úkoly realizovatelné v tak krátké dobˇe. Iterace v sobˇe obsahuje plánování, jednotlivé pracovní dny, integraˇcní cykly, ukonˇcení a oslavu. ˇ Délka integraˇcního cyklu je závislá na schopnostech týmu. Cetnost integrace muže ˚ být ruzná, ˚ 3.3 naznaˇcuje provádˇení integrace nˇekolikrát za den, stejnˇe tak existují projekty, kde ˇ se integrace provádí jednou za den, tˇri dny, týden i více. Cím delší je interval mezi jednotlivými integracemi, tím vˇetší je riziko problému. ˚ Snadnost etapy integrace významnˇe ovlivnuje ˇ technické vybavení, jak je již zmínˇeno v cˇ ásti 3.2.1 Principy. Mezi uvažované cykly patˇrí i týden a den, které mají v každém týmu specifický prubˇ ˚ eh. Pondˇelní pˇrivítání po víkendu, krátké konstatování stavu a podobnˇe. Na zaˇcátku každého dne je vhodné uspoˇrádat krátkou denní schuzku, ˚ jak ji zavádí metodika SCRUM. 28
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Posledním zde popsaným cyklem je vývoj, který je souˇcástí integraˇcního nebo denního cyklu (podle cˇ astosti integrace). V tomto cyklu se ve skuteˇcnosti skrývá návrh, programování, testování a hledání chyb.
3.2.5 Hodnocení Celou rodinu metodik Crystal shledávám velmi zajímavou pro jejich obrovskou flexibilitu. Žádná metodika nemuže ˚ být univerzální pro každý projekt. Metodiky Crystal z tohoto konstatování pˇrímo vycházejí, projekt zaˇcíná volbou a konfigurací vhodné metodiky z rodiny podle daných doporuˇcení. Samotná vybraná metodika je pak spíše sadou doporuˇcení, kterými se tým muže ˚ rˇ ídit. Dokonce i u povinných úkolu˚ má tým možnost vybrat si zpusob ˚ jejich realizace, napˇríklad použít alternativní postup jiné metodiky. Zmínˇená flexibilita muže ˚ být bohužel pro nˇekteré týmy i pˇrekážkou. Zaˇcínající vývojáˇri vˇetšinou uvítají „berliˇcku“ v podobˇe striktnˇe definovaných postupu˚ „zaruˇcenˇe“ vedoucích k úspˇešnému rˇ ešení projektu. Metodiky rodiny crystal jsou orientovány více na lidi než implementaci. Dostupné jsou zatím jen metodiky pro malé a stˇrednˇe velké týmy a pro lehké a stˇrednˇe obtížné projekty.
3.3
Dynamic Systems Development Method
Dynamic Systems Development Method (DSDM) je vytváˇrena konsorciem DSDM od roku 1984, první verze metodiky byla uvolnˇena až v roce 1995. Dlouho dobu lze vysvˇetlit faktem, že konsorcium si dalo za cíl vytvoˇrit podpurné ˚ prostˇredí pro rychlý vývoj software. Vedle doporuˇcených postupu˚ tak metodika obsahuje rovnˇež framework, nad kterým jsou aplikace vyvíjeny. Dále metodiku doplnují ˇ vývojové nástroje a šablony vytváˇrených dokumentu. ˚ Od prvního uvolnˇení konsorcium usilovnˇe metodiku rozšiˇruje a vylepšuje, v dobˇe psaní této práce je k dispozici Framework for Business Centred Development verze 4.2. Metodika DSDM je nejvíce rozšíˇrená ve Velké Británii, je však používána i v jiných státech Evropy a Severní Ameriky. Pˇrístup k metodice a frameworku je bohužel limitován, k jeho použití je potˇreba licence. Z tohoto duvodu ˚ jsem pˇri popisu metodiky DSDM cˇ erpal z neauthentizované cˇ ásti portálu Konsorcia DSDM [7], knihy Agilní programování [3] od Václava Kadlece a dále z práce Agile software development methods [11]. DSDM vychází z myšlenky, která je spoleˇcná vˇetšinˇe agilních metodik, pevnˇe definovat potˇrebný cˇ as a náklady na vývoj software, pˇriˇcemž rozsah vyvinutého systému je pak závislou promˇennou. Zdárné dokonˇcení projektu zajišt’uje použití dvou praktik cˇ asový blok a MoSCoW, které jsou detailnˇe popsány v cˇ ásti 3.3.3 Postupy. 29
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.1 Principy Metodika DSDM je založena na devíti principech, z nichž vˇetšina vychází z manifestu agilního vývoje [2]. Aktivní úˇcast zákazníka Kvalifikovaní zástupci budoucích uživatelu˚ musí být k dispozici po celou dobu vývoje systému, aby týmu zajišt’ovali cˇ astou a pˇresnou zpˇetnou vazbu. Tým má pravomoc k rozhodování ˇ Cekání na potvrzení dalšího postupu od vedení neúmˇernˇe prodlužuje vývoj systému. DSDM tým má na základˇe komunikace s kvalifikovanými zástupci zákazníka pravomoc rozhodnout o dalším smˇeru vývoje. Duraz ˚ na cˇ asté dodávky Nové verze systému jsou uvolnovány ˇ co nejdˇríve je to možné. Zrychluje se tak zpˇetná vazba od uživatelu˚ systému, dˇríve se objeví zmˇenové požadavky a zjistí nepochopené zadání. Vhodnost systému pro podnikání Zákazník oˇcekává systém, který mu pˇrinese svým používáním oˇcekávaný užitek. Splnˇení tohoto oˇcekávání je pro nˇej duležitˇ ˚ ejší než vˇedomí, že systém využívá nejnovˇejší technologie a prošel dukladným ˚ regresním testováním. Iteraˇcní vývoj a inkrementální dodávky Systém je vhodnˇejší dodávat postupnˇe pomocí inkrementu˚ než celý najednou na konci vývoje. Chyby v systému jsou tak objeveny a odstranˇeny dˇríve. Iterace jsou nejvhodnˇejší postup vývoje software. Vratné zmˇeny Bˇehem vývoje je snadné vydat se špatnou cestou, je však duležité ˚ mít možnost se z této cesty rychle dostat zpˇet. Veškeré provádˇené zmˇeny proto musí jít lehce vrátit do puvodního ˚ stavu. Požadavky na vysoké úrovni Vysoká abstrakce pˇri práci s požadavky umožnuje ˇ opoždˇené rozhodování, požadavky jsou postupnˇe upˇresnˇeny až v dobˇe, kdy je jejich detailní podoba jistá nebo kdy je detailní popis nutný pro další vývoj. 30
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Prubˇ ˚ ežné testování Testování se provádí v prubˇ ˚ ehu celého vývoje, aby se eliminovalo riziko, že ke konci už na testování nebude cˇ as, tudíž se neprovede, nebo provede nedostateˇcnˇe. Vzhledem k inkrementálnímu vývoji se provádí regresní testování, tedy opakovanˇe se pˇretestuje celý zatím vyvinutý systém, což zvyšuje pravdˇepodobnost odhalení zavleˇcených chyb. Spolupráce Dokonalá spolupráce a dostateˇcná komunikace je základem úspˇešného vývoje systému. Duležitá ˚ je jak mezi cˇ leny týmu pˇri spoleˇcném rˇ ešení požadavku, ˚ tak mezi týmem a uživateli pˇri rozhodování o pˇridaných funkcionalitách v nové verzi systému. 3.3.2 Role DSDM uvažuje dohromady patnáct ruzných ˚ rolí. Pˇrehled a struˇcný popis nejvýznamnˇejších rolí následuje. Vývojáˇr (Developer) Tato role spolu s následující jsou jediné, které mají v týmu na starost samotný vývoj systému. Jde o obecné oznaˇcení pro zamˇestnance, kteˇrí mají na starost analýzu, návrh, programování nebo testování vyvíjeného systému. Senior vývojáˇr (Senior developer) Do této role je povýšen nˇekterý ze zamˇestnancu˚ v roli vývojáˇre, pokud má vˇetší zkušenosti nebo znalosti než jeho kolegové. Tento cˇ lovˇek jim pak dˇelá vedoucího. Technický koordinátor (Technical coordinator) Navrhuje architekturu vyvíjeného systému a je zodpovˇedný za její technickou kvalitu. Zárovenˇ hlídá projekt po technické stránce, má na starost konfiguraˇcní management. Zástupce uživatelu˚ (Ambassador user) V této roli je obsazen jeden z budoucích uživatelu˚ systému. Jeho úkolem je zajišt’ovat komunikaci mezi vývojovým týmem a budoucími uživateli. Týmu musí poskytnout znalosti uživatelu˚ a tlumoˇcit jejich požadavky. Uživatele pak musí naopak informovat o prubˇ ˚ ehu projektu a výsledcích vývoje. Rádce (Adviser user) Zastupuje pˇredchozí roli v pˇrípadech, kdy se jedná o specifické požadavky. Muže ˚ se jednat napˇríklad o zamˇestnance zákazníka z ICT nebo finanˇcního oddˇelení. 31
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Vizionáˇr (Vissionary) Je cˇ lovˇek, který pˇrišel s myšlenkou nového systému. Jeho úkolem je zajistit, aby se všechny základní požadavky na systém identifikovaly v rané cˇ ásti celého projektu. V následném cˇ ase pak hlídá, že projekt smˇerˇ uje správným smˇerem a realizuje identifikované požadavky. Výkonný rˇeditel (Executive sponsor) Je cˇ lovˇek na stranˇe zákazníka, který má na starost financování celého projektu. Z toho vyplývá, že pˇri rozhodování má poslední slovo. Projektový manažer (Project manager) Tradiˇcní role, která má na starosti hladký prubˇ ˚ eh projektu. Netradiˇcní u metodiky DSDM je, že tuto roli muže ˚ zastávat i nˇekdo ze strany zákazníka. Týmový pˇredák (Team leader) Má na starost celý tým, kontroluje a napomáhá jejich práci a odbourává pˇrípadné komunikaˇcní bariéry. Tester (Tester) Má na starost ty testy, které nemuže ˚ realizovat zákazník sám. Písaˇr (Scribe) Úˇcastní se všech workshopu, ˚ porad a schuzek ˚ a zodpovídá za jejich dokumentaci. Mimo jiné zapisuje i všechny nalezené požadavky. Moderátor (Facilitator) Nepovinná role, která se stará o hladký prubˇ ˚ eh workshopu, ˚ porad a schuzek. ˚ Specialisté (Specialist) V roli specialistu˚ jsou odborníci na ruzné ˚ oblasti vývoje software. Muže ˚ se jednat napˇríklad o doménové experty, správce kvality, test architekty nebo systémové integrátory.
V závislosti na velikosti projektu se úˇcastní vývoje jeden nebo více týmu. ˚ Mezi velkým a malým projektem se z pohledu rˇ ízení témˇerˇ nerozlišuje, protože se vychází z pˇredpokladu, že velký projekt lze rozdˇelit na menší nesouvisející cˇ ásti, které mohou rˇ ešit jednotlivé týmy nezávisle na sobˇe. Tým je složen ze dvou až šesti lidí. Minimum je dáno požadavkem, že v každém týmu musí být alesponˇ uživatel a vývojáˇr. Maximum šesti lidí je výsledkem dlouhodobých zkušeností z používání metodiky DSDM. 32
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.3 Postupy Vzhledem k nutné licenci pro použití DSDM se mi podaˇrilo získat informace bohužel jen o dvojici nepodstatnˇejších postupu, ˚ v terminologii DSDM nazvaných technikami. ˇ Casový blok (Timebox) Celý projekt i jednotlivé iterace mají pevnˇe stanovené datum ukonˇcení, které nelze za žádných okolností odložit. Délka iteraˇcních bloku˚ se typicky pohybuje v rozmezí dvou až šesti týdnu, ˚ podle nároˇcnosti plánované iterace. Bˇehem bloku se postupnˇe realizují požadavky, které jsou seˇrazeny podle priorit. Žádná iterace díky tomu nepˇrekroˇcí plánované datum ukonˇcení, muže ˚ se však stát, že nˇekteré z ménˇe duležitých ˚ požadavku˚ se nestihnou realizovat. Každý blok obvykle projde postupnˇe tˇremi fázemi: zkoumáním, zdokonalením a konsolidací. První ovˇerˇ uje, zda projekt zdárnˇe pokraˇcuje ke svému cíly. Druhá zajišt’uje zlepšování procesu˚ na základˇe poznatku˚ získaných bˇehem pˇredešlého vývoje. Poslední pak slouží k dokonˇcení všech nepˇresných a nedokonˇcených aspektu. ˚ MoSCoW Slovo MoSCoW vzniklo jako složenina cˇ tyˇr písmen oznaˇcující jednotlivé úrovnˇe priorit. Jedná se postup, kterým DSDM pˇriˇrazuje jednotlivým požadavkum ˚ ruzné ˚ priority, podle kterých je bˇehem vývoje s požadavky nakládáno. DSDM uvažuje následující úrovnˇe priorit. •
Nezbytné (Must) jsou požadavky, které musejí být nezbytnˇe realizovány, jinak je ohrožen prubˇ ˚ eh celého projektu.
•
Doporuˇcené (Should) jsou požadavky, které by mˇeli být realizovány, neohrožují však životaschopnost projektu.
•
Možné (Could) jsou požadavky, jejichž nesplnˇení nezpusobuje ˚ projektu žádné vážnˇe problémy.
•
Odložitelné (Won’t) jsou požadavky, které lze realizovat kdykoliv pozdˇeji.
DSDM dále uvádí další techniky, které souvisí s vývojem software. Jedná se o známé pojmy softwarového inženýrství, proto zde techniky pouze vyjmenuji bez jejich detailnˇejšího popisu. Uvádˇenými technikami jsou modelování, tvorba prototypu, ˚ testování a konfiguraˇcní management. Všechny tyto techniky nejsou obecnˇe vhodné pro každý projekt, jejich použití záleží na konkrétním pˇrípadˇe. 33
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.4 Životní cyklus Bˇehem vývoje podle metodiky DSDM projde projekt sedmi etapami uvedenými dále. První tˇri jsou sekvenˇcní, další cˇ tyˇri pak inkrementální a iterativní. Jednotlivé iterace mají pevnou, pˇredem danou délku, to vyplývá z použití cˇ asových bloku, ˚ zmínˇených již dˇríve v cˇ ásti 3.3.3 Postupy. Úvod projektu (Pre-project) Jedná se o krátkou etapu pˇredcházející samotnému vývoji sloužící k ujištˇení, že je projekt dobˇre nakonfigurován a všechny související procesy správnˇe nastartovány. Studie proveditelnosti (Feasibility study) V této etapˇe se rozhoduje, jestli je systém realizovatelný pomocí DSDM. Rozhodnutí je závislé na technických možnostech a hrozících rizicích. Bˇehem této etapy vznikají dva dokumenty, jsou to Zpráva o proveditelnosti (Feasibility report) a Rámcový plán vývoje (Outline plan for development). Pokud projekt vyžaduje týmu málo známou technologii, vytváˇrí se bˇehem této etapy prototyp, který ovˇerˇ í proveditelnost. Délka této první etapy smí být maximálnˇe nˇekolik týdnu. ˚ Obchodní studie (Business study) V této etapˇe se zkoumají základní charakteristiky fungování firmy zákazníka a požadovaných technologií. DSDM doporuˇcuje bˇehem této etapy uspoˇrádat workshop, na kterém se s experty zákazníka projdou aspekty vyvíjeného systému a urˇcí priority jednotlivých úkolu. ˚ Pˇri této etapˇe se vytváˇrí dokument Definice prostˇredí firmy (Business Area Definitions), ve kterém jsou identifikovány provádˇené procesy a zainteresovaní lidé ve zkoumané firmˇe. Dalšími produkovanými dokumenty jsou Definice architektury (System Architecture Definition) a Rámcový plán pro prototyp (Outline Prototyping Plan). První uvedený dokument v sobˇe obsahuje prvotní návrh architektury vyvíjeného systému, tento návrh se bˇehem dalších etap muže ˚ mˇenit. Druhý dokument navrhuje strategie pro vývoj prototypu a obsahuje informace duležité ˚ pˇredevším pro konfiguraˇcní manažery. Stanovení modelu funkcí (Functional model iteration) Tato etapa je první inkrementální a iteraˇcní. Bˇehem jednotlivých iterací probíhá jak analýza tak kódování. Jedním z výstupu˚ této etapy je Funkˇcní model (Functional Model), tedy kód prototypu. Dále tato etapa produkuje dokumenty Priority funkcionalit (Prioritized functions), Revize funkˇcního modelu (Functional prototyping review documents), Nefunkˇcní požadavky (Non-function requirements) a Analýza rizik dalšího vývoje (Risk analysis of futher development). Bˇehem etapy se prubˇ ˚ ežnˇe testuje. Návrh a implementace (Design and build iteration) 34
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Pˇri této etapˇe se navrhuje a vytváˇrí vyvíjený systém. Bˇehem iterací se zárovenˇ upravuje vzhled a celý systém se sestavuje dohromady. Jako zpˇetná vazba slouží pˇripomínky uživatelu, ˚ kteˇrí bˇehem této etapy systém zkouší. Hlavním produktem etapy je otestovaný systém, který splnuje ˇ pˇrinejmenším pˇredem domluvenou minimální množinu kladených požadavku. ˚ Nasazení (Implementation) Bˇehem této poslední etapy se vyvinutý systém nasadí do ostrého provozu u zákazníka. Zárovenˇ probíhá školení uživatelu˚ nového systému. V pˇrípadech, kdy je tato etapa cˇ asovˇe nároˇcnˇejší, muže ˚ probíhat v podobˇe nˇekolika iterací. Souˇcástí etapy je dodání dvou dokumentu, ˚ Uživatelský manuál (User manual) a Zhodnocení projektu (Project Review Report). Závˇer projektu (Post-project) Tato etapa následuje po nasazení systému u zákazníka. Pˇred koncem celého projektu se ovˇerˇ uje, zda systém bˇeží efektivnˇe a zda nasazení systému pˇrineslo oˇcekávaný užitek.
Po skonˇcení pˇredposlední etapy nasazení mohou nastat cˇ tyˇri možnosti, jak bude celý projekt pokraˇcovat, všechny uvádí následující pˇrehled: •
všechny požadavky na systém byly splnˇeny a vývoj konˇcí
•
vˇetší množství požadavku˚ bylo odloženo, nebo byly nˇekteré požadavky objeveny v pozdˇejší cˇ ásti vývoje, pak se celý životní cyklus opakuje od první etapy
•
ménˇe kritické funkˇcnosti byly vynechány, cyklus se opakuje od tˇretí etapy
•
nebyl cˇ as na nˇekteré technické požadavky, pak se cyklus opakuje od cˇ tvrté etapy
Celý životní cyklus vývoje software podle metodiky DSDM ještˇe shrnuje obrázek 3.4 pˇrevzatý z webových stránek Konsorcia DSDM [7]. Na obrázku je zárovenˇ vidˇet, že zpˇetný pˇrechod na pˇredchozí etapu je možný i dˇríve než po dokonˇcení nasazení. 3.3.5 Hodnocení Metodika DSDM mi pˇripadá duslednˇ ˚ e propracovaná a velmi dobˇre dokumentovaná. Je poznat, že se usilovnˇe zdokonaluje už deset let. Licencovaný pˇrístup k této metodice, dle mého názoru, významnˇe omezuje její výrazné rozšíˇrení mezi vývojáˇrskou spoleˇcnost. Ménˇe restriktivní pˇrístup by mohl zdokonalování metodiky urychlit, protože by se do tohoto procesu zapojilo mnohem více lidí. Za zajímavou považuji myšlenku cˇ asových bloku˚ a navržené úrovnˇe priorit jednotlivých požadavku. ˚ Kombinace tˇechto dvou postupu˚ s velkou pravdˇepodobností zaruˇcí, že verze 35
3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
Obrázek 3.4: Životní cyklus podle DSDM
vyvíjeného systému budou dodány vˇcas. Celkový cˇ as trvání projektu se samozˇrejmˇe muže ˚ i pˇresto protáhnout. Zajímavou zkušeností by byl vývoj nad frameworkem DSDM a jeho srovnání s jinými. Bohužel to kvuli ˚ licencím není možné. V opaˇcném pˇrípadˇe by šla posoudit jeho úrovenˇ a odhadnout jakým zpusobem ˚ urychlí a pomuže ˚ pˇri vývoji software. Výhodné muže ˚ být použití metodiky DSDM spolu s metodikou RUP, XP nebo Prince2. Této problematice se vˇenuje rˇ ada cˇ lánku˚ odkazovaných z portálu Aliance agilního vývoje software [1]. Zájemci o detailnˇejší poznání této metodiky cˇ lánky doporuˇcuji k pˇreˇctení. Závˇerem ještˇe uvedu, že podle práce Agile software development methods [11] je tato metodika vhodnˇejší pro projekty z obchodní sféry než pro inženýrské nebo vˇedecké projekty. 36
3.4. SROVNÁNÍ VYBRANÝCH METODIK
3.4
Srovnání vybraných metodik
Obsahem této kapitoly je srovnání vybraných metodik. V úvodu je každá metodika pˇredstavena pomocí jediného odstavce, ve zbývajících sekcích jsou postupnˇe srovnány principy, role a postupy. Extrémní programování je metodika urˇcená pro jeden tým (do deseti programátoru). ˚ Zamˇerˇ uje se pˇredevším na psaní kódu a ostatní disciplíny vývoje ponechává stranou. Je to nejznámˇejší a asi nejrozšíˇrenˇejší agilní metodika, která se pomalu usídluje i u nás. Lze se inspirovat z dobrých programátorských návyku˚ (testovaní a refaktoring), které metodika prezentuje. Bez doplnˇení dalšími pˇrístupy (tˇreba metodikou RUP) je samostatnˇe ve vˇetších ˇ firmách nepoužitelná. Cásteˇ cné osvojení muže ˚ však softwarové firmˇe pˇrinést užitek. Crystal metodiky jsou skupinou metodik, které si dávají za cíl pokrýt všechny možné projekty, vybráním správné metodiky ze skupiny a nastavením odpovídajících parametru. ˚ Zatím jsou však k dispozici jen metodiky pro malé a stˇrednˇe velké týmy a pro lehké a stˇrednˇe složité projekty. Celkovˇe jsou metodiky spíš zamˇerˇ eny na lidský faktor a poradenství, detailní popis postupu˚ ve vˇetšinˇe pˇrípadu˚ neposkytují. Metodiky jsou velmi flexibilní, postupy a cˇ innosti týmu pouze doporuˇcují, pˇrípadnˇe dávají na výbˇer z nˇekolika alternativních možností, kde nˇekteré jsou pˇrevzaté i s ostatních agilních metodik (XP, SCRUM, DSDM). Metodika Dynamic Systems Development Method je postavená na vlastním frameworku, který umožnuje ˇ rychlý vývoj aplikací. Kromˇe frameworku mají vývojáˇri podporu i ve vývojových nastrojích a v šablonách dokumentu. ˚ Postupy jsou z cˇ ásti povinné, z cˇ ásti doporuˇcené. Metodika nepokrývá celou oblast vývoje, je proto vhodná kombinace s jinou metodikou, která jí doplní. Pˇríkladem takové metodiky muže ˚ být RUP. Použití metodiky a frameworku je omezeno licencí. To bohužel zabranuje ˇ masivnˇejšímu rozšíˇrení. 3.4.1 Principy Nemá smysl znovu podrobnˇe rozebírat principy jednotlivých metodik, pro pˇripomenutí však alesponˇ uvedu jejich seznam. Extrémní programování •
Rychlá zpˇetná vazba
•
Pˇredpoklad jednoduchosti
•
Pˇrírustková ˚ zmˇena
•
Využití zmˇeny
•
Kvalitní práce
•
Výuka poznatku˚
•
Malá poˇcáteˇcní investice 37
3.4. SROVNÁNÍ VYBRANÝCH METODIK •
Hraní na výhru
•
Konkrétní experimenty
•
Otevˇrená a upˇrímná komunikace
•
Práce v souladu s lidskými instinkty
•
Pˇrijetí odpovˇednosti
•
Místní pˇrizpusobení ˚
•
Cestování nalehko
•
Poctivé mˇerˇ ení
Crystal metodiky •
Pravidelné dodávky
•
Zdokonalování procesu˚
•
Podprahová komunikace
•
Pˇrátelské prostˇredí
•
Pozornost
•
Dostupnost uživatelu˚
•
Technické vybavení
Dynamic Systems Development Method •
Aktivní úˇcast zákazníka
•
Tým má pravomoc k rozhodování
•
Duraz ˚ na cˇ asté dodávky
•
Vhodnost systému pro podnikání
•
Iteraˇcní vývoj a inkrementální dodávky
•
Vratné zmˇeny
•
Požadavky na vysoké úrovni
•
Prubˇ ˚ ežné testování
•
Spolupráce
38
3.4. SROVNÁNÍ VYBRANÝCH METODIK Srovnání Všechny tˇri porovnávané metodiky vycházejí z manifestu agilního vývoje software [2], a tak se jejich principy témˇerˇ neliší. Principum, ˚ které lze najít ve všech tˇrech metodikám, se zde nebudu vˇenovat, uvedu jen zbývající. Jen XP má pˇrijetí odpovˇednosti, jako jediná tak uvažuje psychologický efekt vybrání si úkolu místo jeho pˇridˇelení. Crystal metodiky zase jako jediné zajišt’ují nerušený cˇ as (pozornost), což je rozdílné od XP, kde se pˇredpokládá, že jeden programátor druhému kdykoliv pomuže. ˚ 3.4.2 Role Stejnˇe jako pˇri srovnání principu˚ nejdˇríve pˇripomenu role jednotlivých metodik. Extrémní programování (XP) •
Kouˇc
•
Stopaˇr
•
Programátor
•
Zákazník
•
Tester
•
Konzultant
•
Velký šéf
Crystal Clear (CC) •
Sponzor
•
Uživatel
•
Hlavní vývojáˇr
•
Vývojáˇr
•
Doménový expert
•
Koordinátor
•
Tester
•
Písaˇr
39
3.4. SROVNÁNÍ VYBRANÝCH METODIK Dynamic Systems Development Method (DSDM) •
Vývojáˇr
•
Senior vývojáˇr
•
Technický koordinátor
•
Zástupce uživatelu˚
•
Rádce
•
Vizionáˇr
•
Výkonný rˇ editel
•
Projektový manažer
•
Týmový pˇredák
•
Tester
•
Písaˇr
•
Moderátor
•
Specialisté
Srovnání U všech metodik lze identifikovat tˇri skupiny rolí: programátorské, uživatelské a rˇ ídící. U první skupiny metodiky shodnˇe rozlišují programátory podle zkušeností. U XP kouˇc své zkušenosti a znalosti pomocí párového programování rychle pˇredává mezi ostatní, zvyšuje tak svou technickou zastupitelnost. Hlavní vývojáˇr u CC takto jednoduše své povˇedomí o architektuˇre nepˇredává, v pˇrípadˇe problému˚ proto bývá pˇretížen, protože je nezastupitelný. Je duležité, ˚ aby si v týmu „vychoval“ alesponˇ jednoho „náhradníka“. Uživatelských rolí je nejvíce u DSDM, lze z toho tedy usuzovat, že se metodika detailnˇe zamˇerˇ uje na ruzné ˚ vazby mezi týmem a zákazníkem. Otázkou je, zda to má smysl. Možným duvodem ˚ by mohla být skuteˇcnost, že DSDM je i pro velké projekty, kdy se vývoje úˇcastní více týmu. ˚ Za takových okolností by adresování komunikace na ruzné ˚ role na stranˇe zákazníka v závislosti na rˇ ešeném problému dávalo smysl. Ve všech metodikách je role tester chápána jako specialista na proces testování, který je v této oblasti oporou ostatním cˇ lenum ˚ týmu, pˇrípadnˇe zákazníkovi. Je to dáno faktem, že jedna ze spoleˇcných vlastností všech agilních metodik je regresní automatizované testování, v týmech tedy nejsou lidé, kteˇrí by na základˇe testovacích scénáˇru˚ ruˇcnˇe testovali vyvíjený software. 40
3.4. SROVNÁNÍ VYBRANÝCH METODIK Metodiky také spoleˇcnˇe uvádˇejí role specializovaných odborníku, ˚ kteˇrí vývojáˇrum ˚ poskytují podporu v neznámých oblastech. Kromˇe role moderátor u DSDM neexistuje jiná role specifická pro nˇekterou metodiku. Celkovˇe lze rˇ íci, že vybrané metodiky se z pohledu rolí liší jen v jemnosti dˇelení, napˇríklad role obsazené lidmi od zákazníka, konkrétnˇe zákazník, pˇrípadnˇe velký šéf v XP oproti zástupce uživatelu, ˚ rádce, vizionáˇr, výkonný rˇ editel, pˇrípadnˇe projektový manažer a specialisté v DSDM. 3.4.3 Postupy Opˇet nejdˇríve uvedu seznam principu˚ pro pˇripomenutí. Extrémní programování (XP) •
Plánovací hra
•
Malé verze
•
Metafora
•
Jednoduchý návrh
•
Testování
•
Refaktorizace
•
Párové programování
•
Spoleˇcné vlastnictví
•
Nepˇretržitá integrace
•
40hodinový týden
•
Zákazník na pracovišti
•
Standardy pro psaní zdrojového kódu
Crystal Clear (CC) •
Pruzkum ˚
•
Motivující úspˇech
•
Bˇežící kostra
•
Inkrementální architektura 41
3.4. SROVNÁNÍ VYBRANÝCH METODIK •
Informaˇcní tabule
•
Nastavení metodiky
•
Zdokonalující workshop
•
Bleskové plánování
•
Vˇeštˇení doby trvání
•
Denní schuzky ˚
•
Optimalizace rozhraní
•
Miniprojekt
•
Blízké programování
•
Pˇrírustkové ˚ grafy
Dynamic Systems Development Method (DSDM) •
ˇ Casový blok.
•
MoSCoW
Srovnání Postupy DSDM cˇ asový blok a MoSCoW jsou alternativní k plánovací hˇre v XP a bleskovému plánování v CC. Všechny slouží k plánování rozsahu verze na základˇe odhadovaného cˇ asu a pˇridˇelené priority, každá však jiným zpusobem. ˚ Nejsnáze lze pochopit a použít plánovací hru, bleskové plánování je však pˇrehlednˇejší. Další postupy metodiky DSDM jsem bohužel nezjistil, takže dále srovnám jen metodiky XP a CC, pˇriˇcemž se zamˇerˇ ím jen na rozdíly, tedy postupy které v druhé metodice nemají alternativní postup nebo postupy. Pokud není nˇekterý postup dále uveden, znamená to tedy, že k nˇemu lze najít alternativu. U metodiky XP jsou ojedinˇelými postupy metafora a spoleˇcné vlastnictví. Pˇríbˇeh k snadnˇejším úvahám o software se u CC nevyskytuje, ani nic podobného. Postup, kdy je zdrojový kód všech a muže ˚ ho tak kdokoliv mˇenit není také zrovna typickým. Proti metafoˇre nic nenamítám, ale myslím si, že za kód by mˇel být nˇekdo zodpovˇedný. Zárovenˇ i chápu, že pokud chce být XP rychlé, nemuže ˚ cˇ ekat až chybu opraví nˇekdo jiný. Optimum vidím v kompromisu, kdy kód muže ˚ mˇenit kdokoliv, ale povˇerˇ ená osoba musí zmˇenu pˇrijmout. U metodiky Crystal Clear lze najít také dva jedineˇcné postupy, jsou to optimalizace rozhraní a miniprojekt. Metodika XP se zamˇerˇ uje na kód, pro tvorbu uživatelských rozhraní žádný podpurný ˚ postup nemá. Miniprojekt je zajímavý, protože radí jak nováˇckum ˚ v týmu 42
3.4. SROVNÁNÍ VYBRANÝCH METODIK ˇ rychle ukázat nejduležitˇ ˚ ejší body metodiky. Cásteˇ cnˇe to lze pˇrirovnat k párovému programování se zkušeným partnerem nebo postupnému pˇrijímání u metodiky XP. Velká podobnost je mezi párovým programováním a blízkým programováním.
43
Kapitola 4
Pˇrípadová studie Tato kapitola obsahuje srovnání vybraných metodik pomocí rˇ ešení pˇrípadové studie. Struˇcné zadaní a okolnosti myšleného projektu jsou obsahem cˇ ásti 4.1 Výchozí podmínky. Následují ukázky rˇ ešení pomocí vybraných metodik. V poslední cˇ ásti 4.5 Srovnání životních cyklu˚ je shrnutí rozdílu˚ mezi vybranými metodikami. Kapitola se zamˇerˇ uje pˇredevším na rozdíly pˇri hledání požadavku, ˚ plánování projektu a na odlišnosti v integraci. Závˇerem ještˇe musím zduraznit, ˚ že jsem se nepokoušel projekt skuteˇcnˇe rˇ ešit, odhady pracnosti jednotlivých požadavku˚ jsou pouze tipovány bez dukladnˇ ˚ ejšího rozboru. Je proto pravdˇepodobné, že jsem nˇekde „pˇrestˇrelil“. Tato kapitola má jen ilustrovat rˇ ešení projektu vybranými metodikami, korektní cˇ asové odhady proto zde nejsou duležité. ˚ Pˇri reálném rˇ ešení by byly co možná nejpˇresnˇejší odhady klíˇcové a povˇerˇ ené role by je museli expertnˇe odhadnout.
4.1
Výchozí podmínky
Jednotlivé metodiky mají za úkol vyvinout software pro podporu správy squashových kurtu. ˚ Soukromý podnikatel (dále zákazník) zakoupil existující squashové centrum, které právˇe opravuje. Centrum chce znovu otevˇrít bˇehem jednoho mˇesíce (22 pracovních dnu), ˚ požaduje tedy software v co nejkratším možném termínu. Od dodaného software zákazník oˇcekává skladovou evidenci prodávaného doplnkoˇ vého zboží (rakety, obuv, míˇcky, . . . ), správu cˇ asové rezervace jednotlivých herních kurtu˚ a evidenci pravidelných návštˇevníku˚ kategorizovaných do ruzných ˚ skupin (profesionálové, studenti, bˇežní hráˇci, . . . ). Software musí poskytovat potˇrebné podklady pro vedení uˇcetnictví. Produkované statistiky vytíženosti kurtu˚ v závislosti na cˇ ase a ruzných ˚ skupinách hráˇcu˚ pomohou zákazníkovi pˇri volbˇe otevíracích hodin a cenové politiky. Svým pruzkumem ˚ zákazník zjistil, že hráˇci mají zájem o možnost rezervace kurtu˚ pomocí webového rozhraní. Takovou službu žádné konkurenˇcní centrum zatím neposkytuje, proto by ji zákazník chtˇel uvést na místní trh jako první hned pˇri znovuotevˇrení centra. Software bude realizovat šestiˇclenný tým zkušených vývojáˇru. ˚ Ve studii se pˇredpokládá, že složení týmu je pevnˇe dáno, protože je uvažována malá softwarová firma s jedním vývojovým týmem, a tým má s použitou metodikou již zkušenosti, což je pˇredpoklad pro efektivní použití metodik. Ve studii se tedy neuvádí procesy budování týmu a obsazování cˇ lenu˚ do rolí. 44
4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Podmínky zde schválnˇe nejsou uvedeny podrobnˇeji, nebot’ je tak lépe patrné, kdy, jak a jestli vubec ˚ metodiky podrobnosti objeví.
4.2
Extrémní programování
Studie ukazuje prubˇ ˚ eh projektu podle ideálního životního cyklu popsaného v 3.1.4 Životní ˚ kdy jsou od zákazníka zjištˇeny požadavky a je složen cyklus, zaˇcíná tedy fází Pruzkum, vývojový tým. Pruzkum ˚ Požadavky jsou od zákazníka získány pomocí uživatelských pˇríbˇehu˚ (User stories), které píše zákazník a lze je chápat jako pˇrípady užití. Pˇríklad 4.2.1 uvádí, jak by vypadal jeden takový uživatelský pˇríbˇeh v pˇrípadˇe uvažovaného squashové centra. Obsluha vybere z nabídky požadované datum, ze zobrazeného harmonogramu dne zjistí, zda je v požadovaný cˇ as volný nˇekterý z hracích kurtu. ˚ Pokud ano, rezervuje hráˇci kurt na danou dobu a informuje hráˇce o jeho rezervaci. V opaˇcném pˇrípadˇe zkouší hráˇci navrhnout rezervaci ve volném cˇ ase, který je k požadovanému nejblíže. V pˇrípadˇe zájmu, rezervuje kurt na novou dobu, jinak není provedena žádná rezervace. Když je rezervace provádˇena pro nového hráˇce, je tento hráˇc zárovenˇ vložen do evidence. Pˇríklad 4.2.1: Ukázka uživatelského pˇríbˇehu (rezervace kurtu) Konzultací mezi zákazníkem a celým týmem jsou uživatelské pˇríbˇehy doplnˇeny a vznikají karty zadání, jednu ukazuje obrázek 4.1. Zákazník urˇcuje prioritu. Typ cˇ innosti muže ˚ nabývat tˇrí hodnot: nová, opravná nebo zlepšovací. Ostatní položky jsou vyplnˇeny až v následných etapách.
Obrázek 4.1: Ukázka karty zadání 45
4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Za normálních okolností by tato etapa trvala nˇekolik týdnu, ˚ v pˇrípadˇe že by tým nemˇel zkušenosti s požadovanou technologií i nˇekolik mˇesícu. ˚ Dále se však pˇredpokládá, že software lze úspˇešnˇe realizovat pomocí technologie J2EE1 , kterou tým už dukladnˇ ˚ e zná a muže ˚ tak zaˇcít hned pracovat. Zákazníkovi pˇritom bylo vysvˇetleno, že je nereálné dodat vše do plánovaného otevˇrení centra. Zákazník tedy v této fázi specifikuje pouze klíˇcovou funkcionalitu, kterou potˇrebuje nejdˇríve a ostatní uživatelské pˇríbˇehy budou sepsány a realizovány až v dalším prubˇ ˚ ehu projektu. Celá fáze tak byla zkrácena na jeden a pul ˚ dne a zákazník zvolil jako klíˇcovou cˇ ást software, která má na starost rezervaci hracích kurtu˚ a správu hráˇcu. ˚ Projekt pokraˇcuje fází plánování, kdy jsou vybrány karty zadaní do první iterace Plánování Plánování normálnˇe zabere jeden až dva dny, v této studii je zkráceno na pul ˚ dne, z pˇredchozí etapou tedy projekt zabral zatím dva dny. Na etapu zprovonování ˇ se vedení rozhodlo vyˇclenit týden pˇred otevˇrením squashového centra. Na následující etapu iterací do uvolnˇení první verze zbývájí tedy tˇri týdny. Plánování je realizováno pomocí plánovací hry a iteraˇcní plánovací hry, které jsou vysvˇetleny v knížce Extrémní programování [12] na stranˇe 76 až 83. Vývoj (celý tým) odhadne pracnost jednotlivých karet zadání. Vedení (zde kouˇc a zákazník) setˇrídí karty podle pˇridané hodnoty pro zákazníka. Vývoj setˇrídí karty podle rizika nepˇresnosti odhadu. Vedení zvolí šíˇri zadání verze, tedy sadu karet zadání které budou implementovány. Podrobnˇejší popis prubˇ ˚ ehu plánovací hry by byl nad rámec této studie, ta je omezená na konstatování, že kouˇc rozhodl pˇred nasazením uskuteˇcnit dvˇe iterace o délce dva a jeden týden, do kterých vybral karty zadání, které jdou napˇríˇc celým prvotním software, jehož jádro má být dodáno pˇred otevˇrením centra. Do verze byly zahrnuty napˇríklad karty zadání uvedené v tabulce 4.1. Karta Rezervace kurtu˚ Evidence hráˇcu˚ Vytvoˇrení prvotního modelu2 Simulace nehotového modelu
Struˇcný popis pˇridání, rušení a pˇrehled rezervací kurtu˚ pˇridání, rušení a pˇrehled hráˇcu˚ databáze a persistence dat potˇrebná k testum ˚ ostatních cˇ ástí
Odhad (dny) 4 2 5 2
... ˇ Tabulka 4.1: Cást karet zadání vybraných do první iterace
Iterace do uvolnˇení první verze 1. Java 2 Platform, Enterprise Edition
46
4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Iterace pˇredcházející uvolnˇení první verze trvají jeden až cˇ tyˇri týdny. Tým ve této studii kvuli ˚ podmínkám (brzké otevˇrení centra) provede jen dvˇe iterace. Bˇehem první je vytvoˇrena kostra systému, trvá dva týdny. Druhá slouží k doplnˇení systému o karty zadání s nejvyšším pˇrínosem pro zákazníka, které lze v daném cˇ ase zvládnout. Na zaˇcátku každé iterace probíhá iteraˇcní plánovací hra sloužící k pˇrevedení vybraných karet zadání pro danou iteraci na úkolové karty pro programátora. Pˇríklad úkolové karty je na obrázku 4.2. Každý programátor vezme cˇ ást z karet zadání a rozebere tyto zadání na jednotlivé úkoly, které jsou napsány do úkolových karet. Pracnost jedné úkolové karty má být v rˇ ádu nˇekolika málo dnu˚ (poˇcet odhaduje tým z pˇredchozích zkušeností), pokud tedy nˇejaký úkol zabere delší cˇ as, musí být dále rozdˇelen na menší úkoly. Naopak nenároˇcné úkoly jsou slouˇceny do jedné úkolové karty.
Obrázek 4.2: Ukázka úkolové karty ˇ Casovým odhadem pˇríslušné úkolové karty pˇrebírá programátor odpovˇednost za její implementaci. Pˇri plánování iterace seˇcte každý programátor odhady na svých úkolových kartách a výsledný poˇcet násobí zátˇežovým faktorem (viz další odstavec). Když je nˇekterý programátor pˇretížen, pˇredá cˇ ást svých karet ménˇe zatíženým kolegum ˚ (již bˇehem plánování). Pokud jsou Pˇretíženi všichni, je nutné se vrátit do plánovací hry a pˇrehodnotit rozsah celé iterace. Veškeré odhady bˇehem plánovací hry i iteraˇcní plánovací hry pˇredpokládají, že programátor bude mít jen jeden odhadovaný úkol a pˇri jeho implementaci nebude rušen, vznikají tak odhady v tzv. ideálním cˇ ase. Zátˇežový faktor je urˇcen k pˇrepoˇcítání ideálního cˇ asu na kalendáˇrní, tedy skuteˇcnou délku. I pro zkušené programátory má tento faktor minimální hodnotu dva, tedy ve skuteˇcnosti jim úkol zabere alesponˇ dvakrát tolik cˇ asu, než je odhadováno, protože se bˇehem vývoje musí vˇenovat i ostatní cˇ innosti. Ve studii má tým zkušené programátory, takže hodnota jejich faktoru je dva, na první iteraci tedy mají pˇet ideálních dnu. ˚ Programátor zastávající roli kouˇce je vˇetšinou i stoparˇ em, ostatní cˇ innost ho bude více zamˇestnávat, proto na první iteraci bude mít dva ideální dny. Stejnˇe tak programátor v roli testera, který bude zákazníkovi pomáhat s psaním testu˚ funkcionality. V týmu je šest programátoru, ˚ dva ideální dny mají dva cˇ lenové, od ostatních se cˇ eká pˇet ideálních dnu. ˚ V souˇctu tedy bˇehem první iterace (deset kalendáˇrních dnu) ˚ plánuje šesticˇ lenný tým implementovat úkoly v rozsahu dvaceti cˇ tyˇr dnu. ˚ Bˇehem každého dne je implementace rˇ ízena testy, pˇríklady lze najít v knize Programo47
4.2. EXTRÉMNÍ PROGRAMOVÁNÍ ˇ vání rˇ ízené testy a v knize Agilní programování. Rešení pˇrípadové studie pomocí TDD uvádí ve své diplomové práci Tomáš Hajdin, v této studii je tedy konkrétní pˇríklad vynechán. K oblasti testování v této studii jen uvedu, že testují jen provozní metody. Napˇríklad by se otestovalo, zda nelze jeden kurt v daný okamžik rezervovat více lidem. Naopak se netestují jednoduché funkce, ve kterých je malá pravdˇepodobnost chyby. Takovými funkcemi jsou vˇetšinou set a get metody, které nastavují a cˇ tou atributy obˇektu. ˚
Zprovoznování ˇ Pˇri zprovoznování ˇ je první verze software nasazena k zákazníkovi a jsou provádˇeny optimalizace a testování. Vzhledem k tomu, že v naší studii tým tˇri týdny vyvíjel ve zcela identickém prostˇredí k dodanému zákazníkovi (projekt byl domluven vˇcetnˇe dodávky a konfigurace hardware), neexistuje pˇredchozí software k paralelnímu testování a akceptaˇcní testování probíhalo již bˇehem pˇredchozích iterací, probˇehla tato etapa bez problému. ˚ Dokonce skonˇcila o den dˇríve. Tento den využil tým k oslavˇe nasazení a k regeneraci pˇred dalším programováním.
Údržba Bˇehem údržby je provádˇen servis nasazeného software, jsou implementovány nové a dˇríve odložené karty zadání. Ve studii bude probíhat vývoj stejným zpusobem ˚ jako v pˇredchozích iteracích, pˇred nasazením. Délka iterace bude dva týdny. Provádˇený servis však sníží programátorum ˚ poˇcet ideálních dnu˚ na cˇ tyˇri. Tento poˇcet je týmem pˇredpokládán a sledováním ovˇerˇ en. Aby tým zvýšil svou efektivitu, rozhodl se kouˇc rozšíˇrit tým o další dva programátory. Takto se rozhodl již bˇehem etapy plánování, pˇred nasazením uspoˇrádal výbˇerové rˇ ízení a dva nováˇcky pomocí párového programování tým rychle zaškolil bˇehem etapy údržby. Rozšíˇrení týmu na maximální poˇcet deseti lidí by v tomto pˇrípadˇe zvýšilo neudržitelnˇe zátˇež týmu, který by zaškoloval cˇ tyˇri nové lidi.
Smrt Smrt nastává v okamžiku, kdy už zákazník nemá další požadavky. V této studii tento okamžik nikdy nenastane. Tým sice postupnˇe implementuje všechny požadované karty zadání, takže by se zdálo, že tím projekt konˇcí. Dodavatel však nadále poskytuje servis software. Díky párovému programování ví o dodaném software všechno každý programátor, opravu tedy muže ˚ realizovat kterýkoliv volný a ostatní mouhou mezitím pracovat na jiných projektech. Protože práce na software témˇerˇ ustala, je napsán krátký popis software, který poslouží jako podklady v dobˇe, kdy tým k projektu vrátí, napˇríklad k dopracování nových požadavku. ˚ 48
4.3. CRYSTAL CLEAR
4.3
Crystal Clear
V této cˇ ásti je ukázán vývoj podle cˇ ásti 3.2.4 Životní cyklus, bˇehem nˇehož jsou použity postupy z cˇ ásti 3.2.3 Postupy. Mapování Projekt zaˇcíná etapou mapování, kdy je sestaven tým (studie pˇredpokládá, že zustane ˚ složení týmu z pˇredchozích projektu˚ a této problematice se dále nevˇenuje), následuje pru˚ zkum, nastavení metodiky a bleskové plánování. Pruzkum ˚ slouží k ovˇerˇ ení, zda má projekt smysl, tedy jestli je tým pˇripraven k realizaci požadavku˚ a jestli software zvýší zákazníkuv ˚ užitek. Jsou identifikováni budoucí uživatelé software (zákazník, recepˇcní, trenéˇri a hráˇci), hlavní pˇrípady užití (rezervace kurtu, pronájem kurtu, prodej sportovního vybavení, . . . ) a požadavky na systém (webová rezervace, evidence hráˇcu, ˚ . . . ). Nastaví se prvotní parametry metodiky, které budou korigovány bˇehem zdokonalujících workshopu. ˚ Jde o spoleˇcnou domluvu týmu o rozsahu iterací a konvencí, které bude pˇri projektu dodržovat. Bˇehem bleskového plánování je normálnˇe vytvoˇren plán na další tˇri mˇesíce. Tým se rozhodne pro plánování jednoho mˇesíce, na konci kterého je otevˇreno squashové centrum. Základem jsou identifikované požadavky sepsané na bleskových plánovacích kartách. Nˇekolik ukazuje obrázek 4.3. Je na nˇem uvedeno, že za úkol „Design webu“ je zodpovˇedný Honza, protože je to cˇ len týmu s nejlepším estetickým cítˇením, návrh obrazovek proto pravidelnˇe dˇelá on. Pˇritom využívá postup optimalizace rozhraní, popsaný v knize Crystal Clear [5].
Obrázek 4.3: Ukázka bleskové plánovací karty Bleskové plánování je detailnˇe popsáno v knize Crystal Clear [5] na stranˇe 68 až 75, zde uvádím jen bodovˇe, jak vzniká plán. 1. úˇcastní se všichni, spoleˇcná zodpovˇednost 2. 15minutový brainstorming, vzniknou bleskové plánovací karty 49
4.3. CRYSTAL CLEAR 3. rozmístˇení karet, podle priority a vzájemných závislostí 4. revize karet, doplnˇení chybˇejících 5. pˇridání odhadu˚ a vývojáˇru˚ (pokud jsou nutní k danému úkolu) 6. seˇrazení karet, pˇrezkoumání závislostí 7. výbˇer bˇežící kostry, první verze 8. identifikace dalších verzí 9. optimalizace podle projektových priorit 10. poznamenání, výsledný plán Vše je na závˇer prodiskutováno na workshopu. Délka celého mapování jsou 2 dny. Dodávka a iterace Software je vyvíjen a dodáván zákazníkovi. Jedna etapa dodávky v sobˇe muže ˚ obsahovat jednu nebo víc iterací. Ve studii tým zvolil délku dodávky 1 mˇesíc a stejnou délku iterace, na konci první iterace tak zákazníkovi k otevˇrení centra dodal bˇežící kostru. Pˇri realizaci bˇežící kostry se cˇ asto stává, že je hlavní vývojáˇr pˇretížen mnoha úkoly, nebot’ je jediný v týmu, který má potˇrebné znalosti. Tým ve studii tento problém nemá, protože se skládá ze zkušených vývojáˇru, ˚ zátˇež je tedy rovnomˇernˇe rozložena. V dalším prubˇ ˚ ehu projektu pˇri zdokonalovacím workshopu se tým shodl, že bude lepší provádˇet dvˇe iterace v každé dodávce, zkusili pˇritom zkrátit délku iterace na 3 týdny. Na zaˇcátku každé iterace je vˇenováno pul ˚ dne k jejímu naplánování. Každý vývojáˇr má pˇridˇeleny dva úkoly, které má bˇehem iterace realizovat. Pracovní den Pracovní den zaˇcíná denní schuzkou ˚ (pˇrevzaté z metodiky SCRUM) na které se každý cˇ len vyjádˇrí ke své práci: •
co udˇelal pˇredchozí den,
•
co plánuje dˇelat dnes,
•
jaké má pˇrekážky.
Celý tým má tak pˇrehled, na cˇ em ostatní právˇe dˇelají a mužou ˚ je v prubˇ ˚ ehu dne požádat o radu, když dˇelají na souvisejícím problému. Pˇrípadnˇe mužou ˚ sami poradit, pokud znají postup k odstranˇení pˇrekážek. Vše se ale rˇ eší až po schuzce ˚ mezi zainteresovanými cˇ leny, schuzka ˚ tak nepˇresáhne cˇ tvrt hodiny. Bˇehem dne pak vývojáˇri opakovanˇe navrhují, implementují a testují své úkoly. Úspˇešnˇe otestované úkoly integrují do dodávaného software. Integrace tedy probíhá nˇekolikrát za den. 50
4.4. DYNAMIC SYSTEMS DEVELOPMENT METHOD Pˇredání Jde o poslední etapu, kdy je celý software už hotový a nasazený u zákazníka. Je pˇredána požadovaná dokumentace.
4.4
Dynamic Systems Development Method
Podle portálu konsorcia DSDM [7] rˇ íká metodika co se má kdy dˇelat, ale neˇríká už jak. V rˇ ešení studie mužu ˚ tedy také uvést pouze, co se v jednotlivých etapách vývojového cyklu dˇeje. Bohužel už nemužu ˚ demonstrovat jak. Když k tomu pˇridám, že jsem kvuli ˚ omezení licencí nezjistil moc detailní informace, nezbývá mi než konstatovat, že rˇ ešení studie touto metodikou je struˇcnˇeji prezentováno než pˇredešlé. Úvod projektu a studie proveditelnosti Tyto dvˇe sekvenˇcní etapy ovˇerˇ í, zda je projekt dobˇre nakonfigurován a zda lze použít metodiku DSDM. Nemužu ˚ tvrdit, že je metodika pro studii vhodná a že požadovaný software lze nad frameworkem metodiky realizovat. Budu ale dále pˇredpokládat, že metodika vhodná je a framework použít lze. Vznikají dokumenty Zpráva o proveditelnosti a Rámcový plán, ve kterém se stanoví milníky projektu. Obˇe etapy dohromady zaberou 3 dny, nebot’ studie je pro DSDM malý projekt. Obchodní studie V této etapˇe je naplánován workshop se zákazníkem a jeho zamˇestnanci, kde tým identifikuje a zkoumá obchodní procesy ve firmˇe zákazníka. V této etapˇe se získávají požadavky a navrhuje prvotní architektura. Jsou vytváˇreny následující dokumenty: •
Definice prostˇredí firmy, kde je uvedeno, že firma se skládá z majitele, trenéru˚ a recepˇcních. V dokumentu jsou mimo jiné tyto obchodní procesy: trénování hráˇcu, ˚ pronájem kurtu˚ (firmám i hráˇcum ˚ na jednotku cˇ asu), prodej a pujˇ ˚ cování sportovních potˇreb.
•
Definice architektury je prvotním návrhem aplikaˇcního software.
•
Rámcový plán pro prototyp urˇcuje strategii použitou k vývoji prototypu.
Etapa ve studii trvá 3 dny. Stanovení modelu funkcí Tato etapa je již iteraˇcní a slouží k pˇrevedení požadavku˚ do podoby modulu˚ a funkcí. Opakovanˇe se: •
identifikuje funkˇcní prototyp, 51
˚ 4.5. SROVNÁNÍ ŽIVOTNÍCH CYKL U •
stanovuje a potvrzuje harmonogram prací,
•
vytváˇrí funkˇcní prototyp
•
provádí revize prototypu.
Ve studii tak vzniknou napˇríklad modul kurty nebo modul hrᡠci s funkcemi pˇ ridej hrᡠce, smaž hrᡠce a edituj hrᡠce. Etapa trvá týden. Návrh a implementace Tato etapa se podobá pˇredchozí, opakují se kroky: •
identifikace návrhového prototypu,
•
stanovení a potvrzení harmonogramu,
•
vytvoˇrení návrhového prototypu,
•
revize prototypu.
Zde se vytváˇrí požadovaný software, je opakovanˇe navrhován, sestavován a testován. Soubˇežnˇe jsou s uživateli konzultovány a upravovány obrazovky. Etapa trvá týden. Nasazení Bˇehem této etapy je nasazen software u zákazníka. V pˇrípadˇe složitˇejšího systému muže ˚ být rozdˇelena do více iterací, ve studii bud však staˇcit jedna, trvající týden, bˇehem kterého jsou zaškoleni uživatelé. Za normálních okolností se k software pˇridává uživatelský manuál a zhodnocení projektu. Protože však za mˇesíc bylo udˇeláno relativnˇe málo z celé aplikace a uživatelé jsou zauˇcení, domluvilo se tentokrát vynechání dokumentu. ˚ Práce na projektu dále pokraˇcuje, tým se vrací k stanovení modelu funkcí a vytváˇrí další inkrementy. Z poˇcátku se nechají délky etap na 1 týdnu (každé 3 týdny zákazník získá novou verzi), pozdˇeji se protáhnou na dvojnásobek a inkrementy budou rozsáhlejší. Závˇer projektu Projekt konˇcí dodáním všech požadavku˚ a ovˇerˇ ením, že aplikace funguje efektivnˇe a splnila zákazníkovo oˇcekávání.
4.5
Srovnání životních cyklu˚
Považoval jsem za vhodné pˇred srovnáním životních cyklu˚ metodik alesponˇ cˇ ásteˇcnˇe tento cyklus ilustrovat. Z tohoto duvodu ˚ je srovnání cyklu˚ až v této kapitole 4 Pˇrípadová studie a ne v pˇredchozí 3.4 Srovnání vybraných metodik. Všechny metodiky používají iteraˇcní a inkrementální vývoj s volitelnou délkou iterace. Liší se však obdobím, kdy provádˇejí integraci. XP nˇekolikrát za den vždy po dokonˇcení 52
˚ 4.5. SROVNÁNÍ ŽIVOTNÍCH CYKL U úkolu. Crystal Clear (CC) volí bud’ stejný styl integrací jak XP, nebo je provádí po nˇekolika málo dnech. DSDM provádí integraci také v krátkých cyklech, ale až v etapˇe návrh a implementace. XP a CC tedy provádí integraci v prubˇ ˚ ehu celého projektu, DSDM jen v jedné fázi. Projektum, ˚ kde cˇ astá integrace není možná (napˇríklad pro cˇ asovou nároˇcnost), se dokáže nejlépe pˇrizpusobit ˚ CC. Naopak XP jen z velkými problémy, pravdˇepodobnˇe by neuspˇelo. Pro získávání požadavku˚ a plánování verzí používají všechny metodiky workshopy, kde se komunikací snaží ze zákazníka vytáhnout potˇrebné informace, následnˇe podle zákazníkem urˇcených priorit poskládat plán. XP používá plánovací hru, kde zákazník píše karty zadání. DSDM k tomuto slouží cˇ asové bloky a MoSCoW. CC používá bleskové plánování nebo jako alternativu zvolí zpusob ˚ metodiky XP, DSDM nebo SCRUM. Jako nejsnazší k pochopení a pˇrijetí považuji plánovací hru, bleskové plánování je huˇ ˚ re realizovatelné, ale více pˇrehledné. Metodiky DSDM a CC ve svých cyklech plánují optimalizaci rozhraní vyvíjeného software, podloženou definovanými postupy práce. Je tedy patrný duraz ˚ na vzhled a použitelnost. Oproti tomu XP klade duraz ˚ pˇredevším na fungující kód. Jistˇe se snaží, aby byl zákazník s rozhraním spokojen, žádné konkrétní postupy však nedefinuje. Srovnat lze metodiky i na základˇe velikosti týmu, kde je XP nejflexibilnˇejší, vˇetšinou zaˇcíná s malým týmem (2 programátoˇri) a podle potˇreby se rozšiˇruje na tým až o 10 cˇ lenech. U metodiky CC a DSDM má tým maximální velikost 6 cˇ lenu. ˚ Z pohledu rozsahu projektu je na tom pak nejhuˇ ˚ re CC, protože má nejmenší tým. Nejlépe je na tom DSDM, která má sice malý tým, ale jako jediná ze srovnávaných dokáže rˇ ídit i více týmu. ˚ DSDM mi pˇripadá jako metodika s nejlépe propracovanou analýzou, témˇerˇ jako u tradiˇcních pˇrístupu. ˚ Nelze se divit, protože je urˇcená pro velké softwarové firmy. Jen ty si mužou ˚ dovolit platit licence a mužou ˚ akceptovat období, kdy se vývojáˇr uˇcí a zvyká si používat framework, nepˇrináší tedy firmˇe doˇcasnˇe užitek.
53
Kapitola 5
Závˇer Hlavním cílem práce bylo získání pˇrehledu o agilních metodikách, což se mi povedlo, své postˇrehy uvádím v kapitole 2. Agilní metodiky. K dalšímu zkoumání jsem si vybral metodiky Extrémní programování, Crystal metodiky a Dynamic Systems Development Method a snažil jsem se o jejich srovnání, což se mi pˇres urˇcité obtíže uvádˇené dále podaˇrilo v kapitole 3. Vybrané agilní metodiky, kde jsou metodiky nejdˇríve popsány a následnˇe srovnány. Poslední úkol, demonstrace vybraných metodik na pˇrípadové studii, je rˇ ešený v kapitole 4. Pˇrípadová studie. Oblast agilních metodik není u nás zatím moc rozšíˇrená, proto jsem musel ve velké míˇre cˇ erpat z elektronických zdroju, ˚ odkazovaných ze stránek Aliance agilního vývoje software [1]. Další komplikací byl fakt, že metodika DSDM je omezena licencí, cˇ ímž je omezena dostupnost detailních informací o této metodice. Poslední komplikací bylo zjištˇení, že metodiky rodiny Crystal nejsou zatím kompletní. V práci jsem se tedy zamˇerˇ il hlavnˇe na nejpropracovanˇejší metodiku z rodiny, na Crystal Clear. Po vypracování této práce pˇredvídám agilním metodikám slibnou budoucnost. Jsou postavené na rozumných principech. Jejich nejvˇetší pˇredností je flexibilita, z jakou se dokáží pˇrizpusobit ˚ mˇenícím se podmínkám a požadavkum ˚ na projekt, a rychlost, z jakou dokáží dodat první omezené funkˇcní verze. Se zájmem budu i nadále sledovat dˇení v této oblasti vývoje software. Agilní metodiky lze dále zkoumat v mnoha smˇerech. Jedním je jejich postupné zdokonalování a vylepšování, aby pokrývaly širší spektrum projektu. ˚ Dále lze zkoumat možnosti spolupráce mezi agilními metodikami nebo mezi agilním a tradiˇcním pˇrístupem. Jako poslední smˇer bych uvedl zkoumání podpurných ˚ nástroju˚ agilních metodik, jakým je napˇríklad framework DSDM. Zjišt’ování technický limitu˚ by jistˇe pˇrineslo zajímavé výsledky.
54
Literatura [1] Beck, K. a Beedle, M. a Bennekum, A. a Cockburn, A. a Cunningham, W. a Fowler, M. a Grenning, J. a Highsmith, J. a Hunt, A. a Jeffries, R. a Kern, J. a Marick, B. a Martin, R. a Mellor, S. a Schwaber, K. a Sutherland, J. a Thomas, D.: Aliance agilního vývoje software . [2] Beck, K. a Beedle, M. a Bennekum, A. a Cockburn, A. a Cunningham, W. a Fowler, M. a Grenning, J. a Highsmith, J. a Hunt, A. a Jeffries, R. a Kern, J. a Marick, B. a Martin, R. a Mellor, S. a Schwaber, K. a Sutherland, J. a Thomas, D.: Manifest agilního vývoje software . [3] Kadlec, V.: Agilní programování , Computer Press, 2004, 80-251-0342-0. ˇ [4] Buchalcevová, A.: Agilní metodiky In sborník konference Objekty, Ceská zemˇedˇelská univerzita v Praze, 2002, 53-62. [5] Cockburn, A.: Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2005, 0-201-69947-8. [6] Hajdin, T.: Agilní metodiky vývoje software [Diplomová práce] , Fakulta informatiky Masarykovy univerzity v Brnˇe, 2005. [7] Portál konsorcia DSDM . [8] Metodika Rational Unified Process . [9] Fowler, M.: Refaktoring - Zlepšení existujícího kódu, Grada, 2003, 80-247-0299-1. [10] Beck, K.: Programování rˇ ízené testy, Grada, 2004, 80-247-0901-5. [11] Abrahamsson, P. a Salo, O. a Ronkainen, J. a Warsta, J.: Agile software development methods: Review and analysis, VTT Technical Research Centre of Finland, 2002, 95138-6010-8. [12] Beck, K.: Extrémní programování , Grada, 2002, 80-247-0300-9.
55
