}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Návrh metodiky vývoje softwaru z pohledu samostatného vývojáˇre D IPLOMOVÁ PRÁCE
Ondˇrej Bechný
Brno, 2010
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: RNDr. Jan Pavloviˇc, Ph.D. ii
Podˇekování Rád bych podˇekoval svému vedoucímu panu RNDr. Janu Pavloviˇci, Ph.D. za vstˇrícnost, odbornou pomoc a konzultace poskytnuté bˇehem tvorby této diplomové práce. Jeho pˇripomínky a rady mi velmi pomohly. Za podporu v prubˇ ˚ ehu celého mého studia dˇekuji svým rodiˇcum. ˚
iii
Shrnutí Tato práce ve své první cˇ ásti pˇrináší pˇrehled existujících vývojových metodik pro tvorbu softwaru, které muže ˚ použít jeden samostatný vývojáˇr. Jsou popsány hlavní rozdíly oproti nˇekterým jiným bˇežným týmovým technikám. Druhá cˇ ást popisuje vlastní metodiku pro vývoj software jedním vývojáˇrem, vhodnou zejména pro akademické prostˇredí. Tato metodika bude demonstrována na webovém informaˇcním systému pro zadávání a správu webových reklamních kampaní.
iv
Klíˇcová slova Agile, Scrum, Extrémní programování, Feature driven development, OpenUp, PHP, Zend Framework
v
Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . 1.2 Struktura práce . . . . . . . . . . . . . . . . . . 2 Souˇcasný stav vývojových metodik pro jednotlivce 3 Proˇc agilní . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Agile Manifesto . . . . . . . . . . . . . . . . . . 3.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Charakteristika . . . . . . . . . . . . . . 3.2.2 Role . . . . . . . . . . . . . . . . . . . . . 3.2.3 Artefakty . . . . . . . . . . . . . . . . . . 3.2.4 Schuzky ˚ . . . . . . . . . . . . . . . . . . 3.2.5 Vhodnost pro jednotlivce . . . . . . . . 3.3 Feature Driven Development . . . . . . . . . . 3.3.1 Charakteristika . . . . . . . . . . . . . . 3.3.2 Procesy . . . . . . . . . . . . . . . . . . . 3.3.3 Role . . . . . . . . . . . . . . . . . . . . . 3.3.3.1 Klíˇcové role . . . . . . . . . . . 3.3.3.2 Podpurné ˚ role . . . . . . . . . 3.3.3.3 Ostatní role . . . . . . . . . . . 3.3.4 Vhodnost pro jednotlivce . . . . . . . . 3.4 Extrémní programování . . . . . . . . . . . . . 3.4.1 Charakteristika . . . . . . . . . . . . . . 3.4.2 Aktivity . . . . . . . . . . . . . . . . . . 3.4.3 Shrnutí a vhodnost pro jednotlivce . . . 3.5 OpenUp . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Charakteristika . . . . . . . . . . . . . . 3.5.2 Role . . . . . . . . . . . . . . . . . . . . . 3.5.3 Principy . . . . . . . . . . . . . . . . . . 3.5.4 Vhodnost pro jednotlivce . . . . . . . . 3.6 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . 4 Návrh vlastní metodiky . . . . . . . . . . . . . . . . 4.1 Problémy pˇri práci samostatného vývojáˇre . . 4.2 Procesní rámec . . . . . . . . . . . . . . . . . . . 4.2.1 Role . . . . . . . . . . . . . . . . . . . . . 4.2.2 Artefakty . . . . . . . . . . . . . . . . . . 4.2.3 Životní cyklus . . . . . . . . . . . . . . . 4.2.4 Shrnutí . . . . . . . . . . . . . . . . . . . 4.3 Extrémní programování pro jednoho . . . . . . 4.4 Použití vhodných nástroju˚ . . . . . . . . . . . . 4.5 Shrnutí . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 3 4 4 6 6 7 8 9 10 10 10 11 13 13 14 14 15 15 15 15 17 18 18 19 20 22 22 23 23 26 26 27 27 30 30 33 35 vi
5 Pˇrípadová studie užití metodiky . . . . . . . . . . 5.1 Zadání . . . . . . . . . . . . . . . . . . . . . . 5.2 Použitá rˇ ešení . . . . . . . . . . . . . . . . . . 5.3 Sprint . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Sprint Backlog . . . . . . . . . . . . . . 5.3.2 Burn Down Chart . . . . . . . . . . . . 5.3.3 Sprint Retrospective . . . . . . . . . . 5.3.4 Sprint Review and Planning Meeting 5.4 Shrnutí . . . . . . . . . . . . . . . . . . . . . . 6 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . A Ukázka aplikace . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
37 37 38 40 41 43 43 44 44 45 47 48
vii
Kapitola 1
Úvod 1.1
Motivace
„Napíšu si na to program.“ Tuto vˇetu musel vyˇrknout snad každý programátor. I když mˇel zˇrejmˇe na mysli samotné kódování (psaní zdrojového kódu), obsáhl svým prohlášením, možná nevˇedomky, celý proces vývoje software. Analýza a návrh probˇehnou v okamžiku, jelikož náš programátor realizuje vlastní jednoduchý nápad sám pro sebe. Není nad cˇ ím bádat. Ovšem co dˇelat ve chvíli, kdy se jeden rozhodne naspat si složitˇejší program? a co když jej netvoˇrí pro sebe, ale pro nˇejakého zákazníka? V takovém pˇrípadˇe je již nutné nˇejakou analýzu uskuteˇcnit. Z ní vypracovat návrh a ten poté realizovat. a hotový výtvor pˇredat, pokud možno bez chyb. Tedy pˇredem otestovat. a cˇ lovˇek najednou stojí na poˇcátku klasického životního cyklu softwarového projektu. Rizika a úskalí takového životního cyklu pokrývá pomˇernˇe znaˇcné množství metodik, ovšem každá z nich je zamˇerˇ ena na práci v týmu. Z velké cˇ ásti tyto metodiky rˇ eší týmovou práci a interakci jednotlivých cˇ lenu˚ týmu, problémy vyplývající z kooperace více lidí. Zamˇerˇ ují se na malé týmy o nˇekolika cˇ lenech soustˇredˇených v jedné oblasti, na vývojáˇre roztroušené po celé zemˇekouli i na mamutí týmy tvoˇrené desítkami cˇ lenu˚ a cˇ asto rozdˇelených mezi ruzné ˚ spoleˇcnosti. Opomíjen tˇemito metodikami však zustává ˚ samostatný vývojáˇr. Jeden cˇ lovˇek pˇritom muže ˚ vyvíjet velký a sofistikovaný software a pˇri této práci nutnˇe používá jisté stereotypy, zabˇehnuté dobré zvyklosti. Tento zpusob ˚ práce však žádná z metodik pˇrímo nepodporuje nebo neobsahuje. Samostatný vývojáˇr cˇ elí stejným problémum ˚ jako vývojové týmy. Ve skuteˇcnosti takovým týmem je. Stejnˇe jako jeho kolegové v poˇcetnˇejší skupinˇe musí získávat informace od zadavatele, zákazníka a pˇretavit je v analýzu. Pˇri tom vystupuje v roli analytika. Na základˇe analýzy musí navrhnout budovaný systém. Tehdy jedná jako návrháˇr, což v týmu muže ˚ být a cˇ asto bývá úplnˇe jiný cˇ lovˇek, než analytik. Na základnˇe svého návrhu zaˇcíná psát program. Opˇet v jiné roli. Testování samozˇrejmˇe provádí také sám. Pˇri tˇechto cˇ innostech cˇ elí stejným problémum ˚ a rizikum ˚ neúspˇechu, jako kdyby pracoval v týmu. Nemusí rˇ ešit týmovou komunikaci a podobnˇe, ovšem vyvstávají pˇred ním jiné problémy. Jak neztratit ze zˇretel cíl a neutopit se v perfekcionalismu a ladˇení detailu. ˚ Jak neopomíjet testování. Jak udržet systém v puvodním ˚ zadání a nepˇridávat novou funkcionalitu. Na toto všechno je sám a žádné kontrola cˇ i navedení na správnou cestu od jeho kolegu˚ se mu nedostává. Podpoˇrit právˇe tento zpusob ˚ vývoje a pomoci se vyhnout jeho úskalím si klade za cíl tato práce. 1
1.2. STRUKTURA PRÁCE
1.2
Struktura práce
Ve své první cˇ ásti se práce soustˇredí na prozkoumání souˇcasného stavu metodik pro jednoho vývojáˇre a na nalezení vhodných existujících týmových metodik. Zkoumá, které jejich cˇ ásti by byly jedinému vývojáˇri prospˇešné a které jsou naopak nevhodné. V druhé cˇ ásti formuluje práce metodiku vlastní. Spíše se jedná o souhrn a doporuˇcení, než o formální definici metodiky. Vlastní metodika je definována na základˇe pruzkumu ˚ jednotlivých metodik existujících a také na vlastní zkušenosti. Navržený postup vývoje je dále znázornˇen na pˇrípadové studii webového informaˇcního systému. Tato studie tvoˇrí cˇ ást tˇretí. Jedná se o systém pro zadávání a správu webových reklamních kampaní. Zevrubnˇe bude probrán jeho návrh, duvody, ˚ které vedly k použití zvolených technologií i nástin prubˇ ˚ ehu jeho tvorby pomocí formulované metodiky.
2
Kapitola 2
Souˇcasný stav vývojových metodik pro jednotlivce Tato kapitola bude pomˇernˇe krátká. V souˇcasnosti neexistuje žádná uznávaná ani zavedená metodika vývoje software jediným samostatným vývojáˇrem. Nejˇcastˇeji je doporuˇcováno pˇrizpusobit ˚ si nˇekterou z agilních metodik. Tento neutˇešený stav muže ˚ mít více duvod ˚ u. ˚ Hlavní bych vidˇel v menším trhu, který samostatní vývojáˇri pˇredstavují. V absolutních cˇ íslech je jejich poˇcet menší, než poˇcet cˇ lenu˚ všech možných vývojáˇrských týmu. ˚ Pracují také na menších projektech. Jejich hlas proto není tolik slyšet. Samostatným vývojáˇrem se cˇ lovˇek zpravidla stává po jisté dobˇe a vybaven jistými zkušenostmi. Ví proto, jak si práci zorganizovat a potýká se s problémy, které se mohou jevit vuˇ ˚ ci organizaci týmové práce jako podružnˇejší. Navíc co cˇ lovˇek, to originál a proto si myslím, že kolik je na svˇetˇe samostatných vývojáˇru, ˚ tolik bude metodik, které používají. Byt’ by existovalo množství sebeoficiálnˇejších doporuˇcení a postupu, ˚ stejnˇe si je každý upraví ke své potˇrebˇe a chuti. V rámci jednoˇclenného týmu totiž neexistuje nˇejaký externí tlak na jejich dodržování.
3
Kapitola 3
Proˇc agilní Tato kapitola probírá, proˇc byly jako zkoumaná oblast zvoleny tzv. agilní metodiky a ne metodiky klasické. Ukazuje vhodnost aplikace agilních metodik pro potˇreby jednotlivce.
3.1
Agile Manifesto
Spolu s rozmachem dostupnosti výpoˇcetní techniky je na vzestupu také dostupnost softwarových rˇ ešení. Projektu˚ v informaˇcních technologiích je stále více a jsou dostupné širšímu spektru lidí. Bolestnˇe se tak ukazuje, že proces vývoj software není zdaleka dokonalý. Pˇríliš mnoho projektu˚ konˇcí pokud ne totálním neúspˇechem, tak alesponˇ znatelným nedodržením termínu cˇ i pˇrekroˇcením rozpoˇctu. Studie The Chaos Report [2] z roku 1995 zkoumala ve Spojených státech na vzorku 8 360 IT projektu˚ jejich úspˇešnost. Výsledek byl alarmující. 31,1 % zkoumaných projektu˚ bylo zrušeno ještˇe pˇred tím, než byly dokonˇceny. Více než polovina (52,7 %) byla dokonˇcena s tím, že rozpoˇcet byl témˇerˇ dvojnásobnˇe navýšen (navýšení rozpoˇctu minimálnˇe o 89 %). Pouze 16,2 % zkoumaných projektu˚ bylo dokonˇceno v termínu a v rámci puvodního ˚ rozpoˇctu. Celková ztráta v dusledku ˚ zrušení projektu˚ byla odhadnuta na 81 miliard dolaru. ˚ V této dobˇe byly na výsluní tzv. „tˇežké“ metody vývoje softwaru. Tˇem byla vytýkána jejich tˇežkopádnost, byrokratický pˇrístup, pˇríliš pomalá reakˇcní doba a neefektivní využití zdroju, ˚ tedy vývojáˇru. ˚ Mezi takové klasické metody patˇrí vývojové modely vodopád, spirála cˇ i prototypování. Tyto modely vycházejí z toho, že je možné veškeré požadavky definovat v první fázi vývoje a s dalšími zmˇenami již nepoˇcítají. Proto je každá chyba v analytické cˇ ásti cˇ i zmˇena v pozdˇejší fázi projektu velmi nákladná a cˇ asto muže ˚ stát za celkovým neúspˇechem. Tento stav byl podhoubím, které dalo vzniknout v devadesátých letech 20. století skupinˇe metodik, které byly pozdˇeji oznaˇcovány jako „agilní“. Mezi nˇe patˇrí napˇríklad SCRUM, Feature driven development, Dynamic Systems Development Method, Adaptive Software Development cˇ i Extreme Programming. V roce 2001 se 17 vývojáˇru˚ sešlo v lyžaˇrském stˇredisku v Utahu, USA a spolu dali dohromady prohlášení publikované pod názvem Manifest pro Agilní vývoj softwaru 1 . Tento vcelku krátký a ve své podstatˇe jednoduchý dokument definuje filozofii vývoje softwarových projektu, ˚ která stojí na cˇ tyˇrech pilíˇrích (volný pˇreklad): 1.
Manifesto for Agile Software Development, http://agilemanifesto.org/ (listopad 2010)
4
3.1. AGILE MANIFESTO •
Lidé a jejich vztahy pˇred procesy a nástroji.
•
Funkˇcní software pˇred vyˇcerpávající dokumentací.
•
Spolupráce se zákazníkem pˇred vyjednáváním smlouvy.
•
Reakce na zmˇenu pˇred rigidním dodržováním plánu.
Dále toto prohlášení ustanovuje dvanáct principu˚ agilního softwaru (volný pˇreklad) 2 : •
Naší nejvˇetší prioritou je uspokojit zákazníka díky vˇcasnému a neustálému dodávání hodnotného softwaru.
•
Vítáme zmˇeny v požadavcích, dokonce i v pozdních fázích. Agilní pˇrístup využívá zmˇen pro zákazníkovu vyšší konkurenceschopnost.
•
Dodáváme funkˇcní software cˇ asto, s frekvencí nˇekolik týdnu˚ až mˇesícu, ˚ preferujeme kratší cˇ asové období.
•
Zákazník a vývojáˇri musí bˇehem vývoje projektu dennˇe spolupracovat.
•
Budujeme projekt s motivovanými jednotlivci. Vytváˇríme jim prostˇredí a podporujeme jejich potˇreby a vˇerˇ íme, že práci zvládnou.
•
Nejúˇcinnˇejší a nejefektivnˇejší metodou zprostˇredkování informací do i uvnitˇr týmu je osobní rozhovor.
•
Fungující software je hlavním mˇerˇ ítkem pokroku.
•
Agilní metody podporují trvale udržitelný rozvoj. Sponzoˇri, vývojáˇri a uživatelé by mˇeli být schopni udržet vývoj stejným tempem po neomezenˇe dlouhou dobu.
•
Stálé zamˇerˇ ení na technickou dokonalost a dobrý návrh podporují agilní pˇrístup.
•
Jednoduchost – umˇení maximalizující množství práce, kterou nebylo tˇreba vykonat – je základem.
•
Nejlepší architektury, analýzy a návrhy vycházejí týmu, ˚ které se samy organizují.
•
V pravidelných intervalech tým analyzuje, jak být efektivnˇejší a tomu uzpusobuje ˚ své chování.
Jak vidno, Prohlášení o agilním vývoji vyznává odklon od byrokratických pˇrístupu˚ vyžadovaných tradiˇcními metodami a soustˇredí se na jednotlivce v týmech a jejich individuality. Tento pˇrístup je stále zamˇerˇ en na týmy, ale jejich jednotliví cˇ lenové tu dostávají širší 2.
Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html (listopad 2010)
5
3.2. SCRUM prostor. Stále se sice nejedná o metodiku zamˇerˇ enou na jednotlivce jako samostatného vývojáˇre, avšak tento pˇristup je z pohledu samostatného jedince mnohem lépe využitelnˇejší, než metody pˇredešlé. Agilní techniky rozbíjejí problém (projekt) na malé cˇ ásti a postupnˇe, inkrementálnˇe budují požadovaný systém. Takové postupné budování softwaru je nazýváno „inkrementální vývoj“. Jednotlivé cˇ ásti jsou oznaˇcovány jako „iterace“. Každá iterace je pak samostatným vývojovým procesem, který prochází všemi fázemi vývoje, od analýzy pˇres návrh až po testování. Výsledek je pak pˇredložen zákazníkovi k posouzení. Tento inkrementální vývoj shledávám užiteˇcným i pro jednotlivce, protože mu pomáhá udržet pozornost soustˇredˇenu na jeden detail cˇ i vlastnost software. Neutopí se tak proto v pˇreskakování z jedné vyvíjené cˇ ásti na druhou s frustrujícím pocitem, že nic stále není hotovo. Agilní metodiky samozˇrejmˇe nemohou být použity všude a za všech okolností. Kupˇríkladu nejsou vhodné, pokud je naplnˇen nˇekterý z následujících pˇredpokladu˚ [1]: •
Management není agilním metodám naklonˇený.
•
Napˇríˇc celým týmem nepanuje shoda na použití agilních technik.
•
ˇ Clenové týmu nejsou fyzicky pˇrítomni na jednom místˇe.
•
Pˇríliš velký tým (více než dvacet vývojáˇru). ˚
Tyto pˇredpoklady jsou však v pˇrípadˇe jednotlivce irelevantní, cˇ i lépe – jsou implicitnˇe splnˇeny. Pokud je cˇ lovˇek sám sobˇe pánem, management tvoˇrí on sám. Když už se pro použití agilních metodik rozhodne, nejen že je tomu management naklonˇen, panuje také shoda napˇríˇc celým jednoˇclenným týmem. Fyzická odlouˇcenost jednotlivých cˇ lenu˚ není možná, stejnˇe tak pˇríliš velký tým. Dále v této kapitole následuje detailní pohled na nˇekteré vybrané agilní metodiky a jejich využití, byt’ jen z cˇ ásti, pro potˇreby jednotlivce.
3.2
Scrum
3.2.1
Charakteristika
Scrum není, pˇrísnˇe vzato, metodika vývoje softwaru. Jde spíše o agilní pˇrístup nebo framework 3 . Spoléhá na tým, který se rˇ ídí sám, pˇrirozenˇe, bez nˇejakého dohlížejícího managementu, který by stál vývojáˇrum ˚ za zády. Nedefinuje dokonce ani formálního vudce ˚ týmu (tzv. „team leader“), spoléhá plnˇe na profesionalitu jednotlivých cˇ lenu. ˚ Roli vedoucího týmu nahrazují v podstatˇe všichni jeho cˇ lenové, kteˇrí priority a další postup urˇcují na schuzích. ˚ Vývoj je rozdˇelen do série jednotlivých etap, oznaˇcovaných jako „sprinty“. Jedná se o pravidelné iterace v duchu agilního vývoje. Pˇred zaˇcátkem každého sprintu se tým dohodne, na kterých vlastnostech budovaného softwaru bude pracovat a v prubˇ ˚ ehu této ite3. Introduction to Scrum – An Agile Process, http://www.mountaingoatsoftware.com/topics/scrum (listopad 2010)
6
3.2. SCRUM race se soustˇredí jen na nˇe. Výsledkem každého sprintu je stabilní program, pˇripravený k pˇredvedení cˇ i pˇredání zákazníkovi.
Obrázek 3.1: Cyklus metodiky Scrum, pˇrevzato z internetových stránek White Wall Web, http://blog.whitewallweb.com (prosinec 2010)
3.2.2
Role
Scrum definuje tˇri role, které se podílejí na procesu vývoje. ScrumMaster Jde o osobou, která by se mohla nejvíce (byt’ vzdálenˇe) podobat vedoucímu týmu. Má na starosti blaho týmu. Odstranuje ˇ pˇrekážky bránící vývoji a slouží jako prostˇredník mezi týmem a vnˇejším svˇetem. Vývojáˇri se tak mohou soustˇredit lépe na své úkoly. Zárovenˇ dohlíží na dodržování postupu˚ Scrumu, ale také na to, aby jednotliví cˇ lenové týmu nebyli pˇretˇežováni tˇreba tím, že si na sebe vezmou pˇríliš mnoho úkolu˚ a zodpovˇednosti. Product Owner Product Owner je zákazník nebo alesponˇ reprezentuje jeho zájmy. Urˇcuje, které vlastnosti budou vyvíjeny bˇehem jednotlivých sprintu˚ a stanovuje jejich priority dle nejvyššího tržního pˇrínosu. Tyto priority muže ˚ prubˇ ˚ ežnˇe mˇenit, za úˇcelem maximálního zisku. Posuzuje výsledek každého sprintu, muže ˚ tedy odmítnout výsledný produkt. Jeho prostˇrednictvím vstupují do vývoje zmˇeny, ovšem nikoliv bˇehem jednotlivých sprintu. ˚ 7
3.2. SCRUM
Tým Scrum tým tvoˇrí samotní vývojáˇri. Optimální poˇcet cˇ lenu˚ je mezi pˇeti a devíti, ale toto cˇ íslo není dogmatem. Se stoupajícím poˇctem cˇ lenu˚ však rostou nároky na komunikaci, jak mezi jednotlivými cˇ leny bˇehem vývoje, tak také na poradách. Praxe ukazuje, že je lepší vˇetší týmy rozdˇelit do nˇekolika menších [5]. Tým se skládá z vývojáˇru˚ disponujících všemi potˇrebných dovedností (napˇr. návrháˇri uživatelského rozhraní cˇ i testeˇri).
3.2.3
Artefakty
Procesy Scrumu jsou podporovány a sledovány tˇremi tzv. artefakty. Product Backlog Jedná se o seznam všech požadavku˚ na vyvíjený produkt, jeho požadovaných vlastností a pozdˇeji také zmˇen. Je udržován a doplnován ˇ v prubˇ ˚ ehu vývoje. Jelikož agilní pˇrístup nevyžaduje vyˇcerpávající poˇcáteˇcní analýzu, je na zaˇcátku vývoje Product Backlog naplnˇen základními požadavky s tím, že v bˇehem práce se každý nový požadavek do seznamu pˇridá. O Product Backlog se stará Product Owner. Urcˇ uje priority jednotlivých požadavku, ˚ cˇ lenové týmu pak doplnují ˇ cˇ asový odhad pro každou položku. Sprint Backlog Z Product Backlogu jsou na zaˇcátku každého sprintu vybrány nejduležitˇ ˚ ejší požadavky (nebo ty s nejvyšším návratem investic) a z nich je vytvoˇren Sprint Backlog. Jednotlivé požadavky jsou rozdˇeleny na menší úkoly, které jsou snadnˇeji splnitelné. Doporuˇcuje se, aby nároˇcnost jednotlivých úkolu˚ byla mezi cˇ tyˇrmi a šestnácti hodinami 4 . Jednotlivé úkoly nejsou pˇriˇrazovány konkrétním vývojáˇrum, ˚ místo toho si cˇ lenové týmu sami vybírají, které úkoly si vezmou na starost. Sprint Backlog tak má na starosti výhradnˇe vývojový tým. Úkoly je možné obodovat podle nároˇcnosti, aby se lépe konstruoval tzv. Burn Down graf. Burn Down Chart Aby bylo možné pˇrehlednˇe sledovat prubˇ ˚ eh jednotlivých sprintu, ˚ definuje Scrum tzv. Burn down graf. Ten zobrazuje poˇcet dosud nesplnˇených úkolu˚ v cˇ ase. Osa Y znázornuje ˇ otevˇrené (nesplnˇené) úkoly (napˇr. podle jejich bodu) ˚ a osa X zobrazuje datum. Graf by ideálnˇe mˇel mít klesající lineární prubˇ ˚ eh. Pokud klesá moc rychle, cˇ i dokonce dosáhl nulové hodnoty Y pˇred dosažením mezní hodnoty X (konec sprintu), je možné do probíhajícího sprintu pˇridat další úkoly. Pokud naopak klesá pˇríliš pomalu, ukazuje to na zpoždˇení, které je možné rˇ ešit napˇr. pˇresunutím nˇekterých požadavku˚ zpˇet do Product Backlogu.
4.
Scrum (development), http://en.wikipedia.org/wiki/Scrum_%28development%29 (listopad 2010)
8
3.2. SCRUM
Obrázek 3.2: Burn Down Chart, pˇrevzato z [5] 3.2.4
Schuzky ˚
Scrum definuje tˇri druhy schuzek, ˚ na kterých jsou probírány ruzné ˚ aspekty vývoje.
Daily Scrum Každodenní setkání všech cˇ lenu˚ týmu, vˇcetnˇe ScrumMastera a Product Ownera, které probíhá v pˇresnˇe stanovenou dobu. Úˇcastnit se muže ˚ kdokoliv, ovšem pouze výše uvedení mají právo mluvit, lidé mimo tým zde mohou být jen jako pozorovatelé. Délka setkání by nemˇela pˇresáhnout 15 minut. Bˇehem schuzky ˚ cˇ lenové týmu bez zbyteˇcných okolku˚ prozradí, na cˇ em pracovali pˇredešlý den a co mají v plánu dnes. Pokud jim v cestˇe stojí nˇejaké pˇrekážky, mˇeli by je zmínit. Ve výsledku by Daily Scrum mˇel za vˇcasu odhalit skryté problémy a závislosti vývoje a umožnit je odstranit. Celý tým si takto také udržuje zevrubný pˇrehled o projektu a stavu vývoje. Sprint Planning Meeting Pˇred zaˇcátkem každého sprintu je potˇreba stanovit jeho prubˇ ˚ eh a oˇcekávaný výsledek. K tomu slouží Sprint Planning Meeting. Product Owner pˇredstaví aktualizovaný Product Backlog a spolu s cˇ leny týmu se dohodne, které vlastnosti budou implementovány bˇehem nadcházejícího sprintu. Toto plánování se dˇeje na základˇe priorit a cˇ asové nároˇcnosti jednotlivých požadavku. ˚ Tato fáze by mˇela zabrat nejvýše cˇ tyˇri hodiny. Poté pˇrichází na rˇ adu další cˇ tyˇrhodinový blok, kdy cˇ lenové 9
3.3. FEATURE DRIVEN DEVELOPMENT týmy vytváˇrejí a upˇresnují ˇ Sprint Backlog, tedy detailnˇe plánují rozvrh budoucího sprintu dˇelením požadavku˚ na jednotlivé úkoly. Výstupem tohoto setkání je tedy nový Sprint Backlog. Sprint Review Meeting Tato schuzka ˚ se koná na konci každého sprintu za úˇcelem jeho zhodnocení a shrnutí toho, co bylo vytvoˇreno a co se naopak dokonˇcit nepovedlo. Je vítána úˇcast zákazníka, nejenom Product Ownera. Tˇem je pˇredveden funkˇcní program s novými vlastnostmi. Vše by opˇet nemˇelo pˇresáhnout cˇ tyˇrhodinový limit. Dále následuje (již bez zákazníka) zhodnocení uplynulého sprintu jednotlivými cˇ leny vývojového týmu (tato fáze bývá nˇekdy vyˇclenˇena jako zvláštní schuzka ˚ „Sprint Retrospective“). Cílem je zhodnotit podmínky pro práci, najít problematická místa a ta v pˇríštím sprintu odstranit. 3.2.5
Vhodnost pro jednotlivce
Metodika Scrum v duchu agilního pˇrístupu spléhá na samostatný tým a ponechává mu pomˇernˇe volnou ruku pˇri organizaci práce. Tím pádem nestanovuje rigidní manažerská omezení a motivaˇcní tlaky na vývojáˇre, což je základním pˇredpokladem pro jeho využití jednotlivcem. Zárovenˇ definuje dostateˇcnˇe pevný rámec pro vývojové procesy. Tohoto rámce muže ˚ využít i samostatný vývojáˇr. Jako samostatná metodika však pro nˇej Scrum pˇríliš vhodný není, jelikož pˇrece jenom poˇcítá s týmovou prací a neˇreší množství problému˚ vyplývajících ze samoty vývojáˇre. Jelikož bývá cˇ asto doplnˇen prvky Extrémního programování, je vidˇet, že je zde prostor pro jeho úpravy a doplnˇení [5]. Proto mi pˇripadá Scrum jako dobrý základ, který by po úpravách a doplnˇení mohl tvoˇrit pilíˇr metodiky pro vývoj jedním vývojáˇrem.
3.3
Feature Driven Development
3.3.1
Charakteristika
Tato metodika (dále jen FDD) je dalším zástupcem z rodiny iterativních a inkrementálních metod. Tento pˇrístup se realizuje tak, že se vývoj soustˇredí na jednotlivé vlastnosti tvoˇreného systému. Od ostatních agilních metodik se ovšem trochu odlišuje. Svého vytyˇceného cíle, kterým je dodávání kvalitního software, se snaží dosáhnout odstranˇením nejistoty v pru˚ bˇehu vývoje. Tuto redukci má umožnit dukladné ˚ plánování ještˇe pˇred zahájením iterativních cˇ ástí procesu. Takové plánování je bližší spíše klasickým „tˇežkým“ metodikám. Ve své podstatˇe je však FDD metodikou agilní, jelikož naplnuje ˇ agilní prohlášení (Agile Manifesto) ve všech jeho bodech. Významnou cˇ ástí FDD je již zmínˇené odstranování ˇ nejistoty z procesu tvorby. Proto se snaží jednotlivé vlastnosti jednoznaˇcnˇe oznaˇcit tak, aby už z jejich názvu byl na první pohled patrný jejich úˇcel. Tohoto ideálu bohužel není snadné vždy dosáhnout. Zavedený formát pojmenování je „akce“ „výsledek“ „objekt“. Instancí takového pˇredpisu muže ˚ kupˇríkladu být: 10
3.3. FEATURE DRIVEN DEVELOPMENT •
Vygenerovat nové heslo uživateli.
•
Zobrazit seznam faktur zákazníkovi.
•
Vypsat seznam dílu˚ výrobku.
3.3.2
Procesy
FDD ustanovuje pˇet základních procesu. ˚ Výsledkem prvních tˇrí z nich je model sytému a seznam vlastností požadovaných zákazníkem. Dva poslední procesy jsou iterativnˇe opakovány pro jednotlivé budované vlastnosti. Tvorba procesu˚ nemusí být jednoduchá, proto FDD zavádí prostˇredky, jak tento postup zjednodušit a udˇelat jednoznaˇcnˇejším. Každý proces je vytváˇren tzv. procesní šablonou „ETVX“, cože je zkratka slov „Entry criteria“ (vstupní podmínky), „Task definitions“ (definice úkolu), ˚ „Verification“ (ovˇerˇ ení) a „eXit criteria“ (výstupní podmínky).
Entry criteria Jasnˇe stanovené požadavky, které musí být splnˇeny pˇred zahájením procesu. Task definitions Seznam úkolu, ˚ které mají být bˇehem procesu splnˇeny. Souˇcástí každého z nich by mˇel být seznam rolí a pokud je to nutné, tak i podrobnˇejší popis. Verification Urˇcení zpusob ˚ u, ˚ jak je možné daný proces ovˇerˇ it. Prubˇ ˚ eh procesu je rozdˇelen na kontrolní body a po jejich dosažení je ovˇerˇ ována jejich správnost. Tak je možné odhalit chyby a nedostatky blízko místu jejich vzniku. eXit criteria Definice požadovaných výstupu˚ procesu a jejich kvality. Po splnˇení tˇechto podmínek je možné proces oznaˇcit jako ukonˇcený.
Obrázek 3.3: Procesy Feature Driven Development
11
3.3. FEATURE DRIVEN DEVELOPMENT
Tvorba celkového modelu Bˇehem úvodního procesu vývojáˇri a lidé zastupující zákazníka (odborníci na oblast, které se systém týká) vytvoˇrí jeden tým a spolu navrhnou základní kostru systému. Nad celým procesem dohlíží hlavní architekt. Dále jsou lidé rozdˇeleni do menších skupinek a každá z nich pracuje na jednom konkrétním výseku systému, všechny skupinky na stejném. Poté hlavní vývojáˇr vybere nejlepší návrh a doplní jej vhodnými cˇ ástmi z návrhu˚ ostatních. Skupinky je možné personálnˇe reorganizovat, aby nedocházelo k nežádoucí dominanci jedné z nich. Postupnˇe je takovouto dekompozicí sestaven celkový model systému. Tento proces by mˇel zabrat pˇribližnˇe 10 % cˇ asu pˇri prvním provádˇení, v dalších iteracích pak 4 %. Tvorba seznamu vlastností Na základˇe celkového modelu systému se v tomto kroku buduje co nejúplnˇejší seznam požadovaných vlastností. Celá doména (oblast, které se systém týká) je rozdˇelena na menší celky. V tˇechto cˇ ástech jsou pak identifikovány jednotlivé požadavky a oznaˇceny výše uvedeným pˇredpisem „akce“ „výsledek“ „objekt“. Takto vzniká strukturovaný seznam vlastností, pˇriˇcemž implementace žádné z nich by nemˇela zabrat víc, než dva týdny. Tvorba seznamu vlastností by mˇela zabrat cca 4 % cˇ asu v první iteraci a 1 % v každé další. Plán podle vlastností Podle seznamu vlastností z pˇredchozího kroku se vytvoˇrí plán pru˚ bˇeh vývoje. Vlastnosti cˇ i jejich nadˇrazené celky jsou rozdˇelovány mezi jednotlivé vývojové týmy, které jsou reprezentovány hlavními vývojáˇri. Jsou jmenováni tzv. vlastníci tˇríd (viz dále). Vývoj je rozdˇelen do milníku˚ a je ustanoven cˇ asový odhad. Plán podle vlastností by mˇel vždy tvoˇrit zhruba 2 % cˇ asu. Návrh podle vlastností Tento a následující proces je opakován v každé iteraci, která typicky trvá cˇ trnáct dní. Hlavní programátor vybírá, které vlastnosti budou v nadcházející iteraci implementovány. Spolu s pˇríslušnými vlastníky tˇríd vypracuje detailní sekvenˇcní diagram a zmˇeny promítne do celkového modelu. Ten je tak prubˇ ˚ ežnˇe upˇresnován ˇ a zjemnován. ˇ Tvorba podle vlastností Na základˇe pˇredchozího detailního návrhu jsou implementovány jednotlivé vlastnosti. Kód je otestován jednotkovými tesy a provádí se také inspekce kódu. Pokud je vše funkˇcní, je naprogramovaná vlastnost zaˇrazena mezi existující do funkˇcního celku. Návrh a tvorba podle vlastností by mˇely tvoˇrit asi 77 % objemu práce.
12
3.3. FEATURE DRIVEN DEVELOPMENT 3.3.3
Role
FDD rozlišuje tˇri skupiny rolí. Jeden cˇ lovˇek muže ˚ zastávat rolí více. Jde o snahu co nejefektivnˇejšího využití lidského potenciálu, kdy jsou souˇcástí týmu pracovníci ruzných ˚ schopností a kvalit. Zejména podpurné ˚ role bývají cˇ asto slouˇceny s jinou rolí klíˇcovou. Seznam rolí byl pˇrevzat z internetových stránek Stephena R. Palmera 5 . 3.3.3.1 Klíˇcové role Project Manager Tato role je dost podobná ScrumMasterovi z metodiky Scrum. Zastˇrešuje administrativu a správu celého projektu a stará se, aby tým mˇel co nejvhodnˇejší podmínky pro svou práci. Odstranuje ˇ pˇrekážky bránící vývoji.
Chief Architect Tento cˇ lovˇek má poslední a rozhodující slovo v otázkách týkajících se modelování a návrhu systému. Musí mít velmi dobré znalosti a schopnosti co se modelování softwarových programu˚ týˇce a také si udržovat dobrý pˇrehled o budovaném systému jako celku.
Development Manager Zastává roli jakéhosi koordinátora mezi jednotlivými vývojovými ˇ týmy. Reší pˇrípadné spory a rozdˇelení prostˇredku˚ mezi týmy.
Chief Programmer Zkušený vývojáˇr, který vede 3 – 6 cˇ lenný tým. Podílí se na návrhu systému v úvodních procesech a rˇ ídí vývoj svého týmu v prubˇ ˚ ehu jednotlivých iterací. Plánuje, rozdˇeluje a koordinuje práci uvnitˇr svého týmu. Spolupracuje také s šéfprogramátory ostatních týmu˚ pˇri bˇežných denních úkolech a problémech. Tato role je pro úspˇech projektu klíˇcová.
Class Owner Jednotlivý vývojáˇri, tvoˇrící týmy, které pracují na vývoji jednotlivých vlastností. Jsou podˇrízeni Chief Programmerovi.
Domain Expert Reprezentace zákazníka. Jde o lidi s znalostí problematiky, pro kterou se systém vyvíjí. Na základˇe jejich expertizy je systém modelován a jejich informace jsou proto klíˇcové.
5. FDD: People, http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/FDDPeople.html (listopad 2010)
13
3.3. FEATURE DRIVEN DEVELOPMENT 3.3.3.2 Podpurné ˚ role Domain Manager Vede a koordinuje skupinu doménových expertu, ˚ rˇ eší pˇrípadné názorové rozpory. Tato role se uplatnuje ˇ spíše ve vˇetších týmech. Release Manager Tento cˇ lovˇek shromažd’uje výkazy o jednotlivých iteracích od šéfprogramátoru, ˚ zpracovává je a pˇredkládá Project Managerovi. Kontroluje a dokumentuje tak prubˇ ˚ eh vývoje, zejména zda je vývoj dostateˇcnˇe rychlý. Language Guru Tato role je potˇrebná zejména v projektech, které využívají nového, dosud ne dokonale známého programovacího jazyka (myšleno z pohledu vývojáˇru˚ v týmu). Musí znát dokonale použitý jazyk a už pˇri návrhu potvrdit jeho vhodnost pro konkrétní vývoj. Build Engineer Stará se o tzv. build proces (sestavení celého systému) a o všechny automatizované procesy s tím související (napˇr. buildovací skripty, generování dokumentace apod.). Má na starosti také správu verzovacího systému. Toolsmith Má na starosti tvorbu malých podpurných ˚ programu, ˚ které usnadnují ˇ práci ostatním vývojáˇrum. ˚ Jako pˇríklad mužeme ˚ uvést konverzi dat ze zdroje poskytnutého zákazníkem do databáze, kterou využívá budovaný systém. System Administrator Systémový administrátor má za úkol údržbu serveru˚ a vnitˇrní infrastruktury. Spravuje jednotlivá vývojová prostˇredí (development, testing, staging) a podílí se spolu s Build Engineerem na buildovacím procesu a publikování (deploymentu) na ostatní prostˇredí. 3.3.3.3 Ostatní role Tester Testeˇri mohou být souˇcástí vývojových týmu˚ nebo pracovat v rámci externího oddˇelení. Nemají však za úkol psát jednotkové testy – to je práce jednotlivých programátoru! ˚ Deployer Tento cˇ lovˇek zajišt’uje instalaci a bˇeh vyvíjeného systému v prostˇredí u zákazníka. Technical Writer Tvoˇrí uživatelskou dokumentaci. 14
3.4. EXTRÉMNÍ PROGRAMOVÁNÍ 3.3.4
Vhodnost pro jednotlivce
Jak již bylo rˇ eˇceno výše, Feature driven development je metodikou spojující svˇety agilních a klasických metodik. Procesní požadavky jsou vyšší, než napˇr. u metodiky Scrum. Duraz ˚ je kladen na dukladné ˚ modelování a seznam všech možných rolí je obdivuhodný. Toto všechno má však svuj ˚ dobrý duvod ˚ – umožnuje ˇ aplikovat agilní pˇrístup k vývoji i na velké týmy a zachovat tak rychlé produkˇcní tempo. Pˇrestože je možné mnoho rolí slouˇcit do sebe, není tato metodika jako celek pro jednotlivce pˇríliš vhodná. Dají se z ní sice použít jen nˇekteré aspekty, napˇr. už samotné soustˇredˇení se na jednotlivé vlastnosti a podle nich si rozvrhnout práci, nicménˇe jako zastˇrešující rámec pro jednoho vývojáˇre je pˇríliš složitá. Dodržování jednotlivých pravidel vývoje pˇríliš složité není, avšak pˇrínos FDD spoˇcívá zejména v koordinaci lidských sil a práci s jednotlivými týmy. Oblíbeným prostˇredkem pˇri samostatné práci je tzv. pˇrehazování klobouku. Spoˇcívá v tom, že cˇ lovˇek zastává vždy jen jednu roli – napˇr. kodéra, píšícího kód. Symbolicky si tak nasadí programátorský klobouk a nesoustˇredí se na jiné aspekty, než na psaní kódu. Pak se jakoby pˇrenese do role testera ˇ (imaginárnˇe si nasadí testovací klobouk) a zaobírá se pouze testováním. Clovˇ ek muže ˚ vykonávat v jedné chvíli jen tu roli, jejíž klobouk má právˇe nasazen. Množství rolí ve FDD však tento zpusob ˚ práce cˇ iní pomˇernˇe obtížným, byt’ spousta rolí se uplatnuje ˇ jen v malém cˇ asovém úseku a jimi vykonávaná práce stejnˇe musí být hotova. Nicménˇe takové zestruˇcnˇení této metodiky mi nepˇripadá pˇríliš vhodné a mohlo by vést k jejímu obcházení a tím by ztrácela smysl.
3.4
Extrémní programování
3.4.1
Charakteristika
Extrémní programování (dále XP) není možné oznaˇcit za metodikou vývoje, spíše za filozofii vývoje, která vychází z agilního pˇrístupu. Tento pˇrístup se i v souˇcasnosti vyvíjí na základˇe zkušenosti. Od samého poˇcátku je tak v podstatˇe koncipován: pokud nˇeco už nˇeco funguje, doved’me to k dokonalosti. Jako ilustraci tohoto pˇrístupu uved’me tˇreba testování. Testování softwaru se v praxi osvˇedˇcuje, používejme jej tedy všude, kde je to možné. Stejnˇe tak napˇr. iterativní pˇrístup. Funguje? Doved’me jej tedy do extrému pomocí krátkých iterací. Že metody XP naplnují ˇ agilní filozofii není náhoda, ale spíše dusledek ˚ uplatnování ˇ fungujících postupu. ˚ Slovo extrémní je v názvu právˇe z duvodu ˚ extrémního durazu ˚ na jednotlivé metody a jejich provádˇení do dusledku. ˚ 3.4.2
Aktivity
XP rozlišuje cˇ tyˇri aktivity, které se bˇehem celého procesu vývoje opakují6 .
6. Extreme Programming, Cunningham & Cunningham, Inc., http://c2.com/cgi/wiki?ExtremeProgramming (prosinec 2010)
15
3.4. EXTRÉMNÍ PROGRAMOVÁNÍ Programování Ze všech ostatních metodik je v XP nejvˇetší duraz ˚ kladen právˇe na programování. Jak uvádí Kent Beck, zakladatel této metodiky: „At the end of the day, if the program doesn’t run and make money for the client, you haven’t done anything.“ [6] Ve volném pˇrekladu by uvedený citát znˇel: „Pokud na konci dne program nefunguje a nevydˇelává zákazníkovi peníze, neudˇelali jste nic.“ Programování je vskutku stˇežejní cˇ ástí vývoje, bez které software prostˇe (alesponˇ zatím) nevznikne. XP klade duraz ˚ na jednoduchost a srozumitelnost kódu, díky které odpadá nutnost psaní dokumentace. Kód musí dodržovat pˇredem stanovené standardy a je cˇ asto refaktorován. Všichni vývojáˇri mají pˇrehled o celém projektu a XP nezná nˇeco jako vlastníka tˇrídy z FDD. Každý musí být schopen upravit jakoukoliv cˇ ást kódu. K dosažení tohoto stavu XP zavádí párové programování, což je zˇrejmˇe jeho nejznámˇejší specifikum. U jednoho poˇcítaˇce tak sedí dva programátoˇri a pravidelnˇe se v psaní kódu stˇrídají. Jeden se tak soustˇredí na kód samotný a druhý má na pamˇeti širší kontext okolní architektury. Práce ve dvojici také napomáhá soustˇredˇení a omezuje externí rušivé vlivy. Více hlav více ví, a tak dochází v mnohem menší míˇre k situacím, kdy jeden programátor na dlouho uvázne na problému. Tomuto stavu brání další postup, který XP podporuje. Vývojáˇri by mˇeli být odvážní a nebát se kód refaktorovat do podoby, která bude aktuální situaci lépe vyhovovat. Extrémnˇejší variantou je tˇreba zahození celodenní práce, která uvázne na mrtvém bodˇe. Zkušenosti totiž ukazují, že druhý den je cˇ lovˇek schopen vymyslet mnohem rychleji fungující rˇ ešení. Programování ve dvojici také pomáhá zabránit akumulování znalostí systému pouze jedním cˇ lovˇekem. Vyrovnává také rozdíly mezi vývojáˇri, kdy se ménˇe zkušený mnohem rychleji uˇcí od svého zbˇehlejšího kolegy. Dvojice nejsou ustanoveny na principu monogamního manželství a tak se programátoˇri pravidelnˇe mezi sebou stˇrídají.
Testování Dukladné ˚ testy jsou základním stavebním kamenem metodiky XP. Tento pˇrístup je realizací myšlenky dˇelat vˇeci nejjednodušším možným zpusobem, ˚ která celé XP prostupuje. Pˇredstavy zákazníka o systému jsou zhmotnˇeny v testech a pokud jimi naprogramovaný software ke spokojenosti klienta projde, je považován za hotový. Také jednotkové testy by mˇely být v duchu metody Test Driven Development (vývoj rˇ ízený testy) psány pˇred zahájením práce na kódu samotném. Potom se píše kód tak, aby prošel testy, nic víc. Dokonalá sada testu˚ pak umožnuje ˇ refaktoring.
Plánování XP zduraz ˚ nuje ˇ nutnost umˇet naslouchat potˇrebám zákazníka. Ve spolupráci s ním jsou na zaˇcátku projektu sestaveny tzv. „User stories“, které v krátké formˇe (klidnˇe i jedna vˇeta) zachycují požadavky na systém. Z nich je sestaven rámec celého projektu a na jeho základˇe proveden hrubý cˇ asový odhad. Dále se sestaví prioritní seznam požadavku, ˚ z nˇehož jsou dále vybírány ty, které mají být v aktuální iteraci implementovány. Iterace samotné jsou krátké a každá z nich zaˇcíná právˇe plánováním. 16
3.4. EXTRÉMNÍ PROGRAMOVÁNÍ Každý den se všichni vývojáˇri sejdou bˇehem struˇcné schuze, ˚ kterou je doporuˇceno absolvovat z motivaˇcních duvod ˚ u˚ ve stoje. Zákazník nebo jeho zástupce by mˇel být pˇrítomen na pracovišti bˇehem celého procesu vývoje. Je možné tak provádˇet plánování i bˇehem krátkých iterací a není nutné jej provádˇet do nejmenších podrobností. Pˇri jakýchkoliv nejasnostech bˇehem práce se muže ˚ vývojáˇr se zákazníkem poradit. Taková situace cˇ asto nastává pˇri psaní testu. ˚ Návrh Návrh (v originále „design“) systému vyvíjeného pomocí metodiky XP musí dodržovat jeho základní princip, kterým je jednoduchost. Architektura systému musí být jednoduchá a srozumitelná, cˇ emuž napomáhá výše nˇekolikrát zmínˇený refaktoring. Není žádoucí myslet pˇríliš dopˇredu a pˇripravovat sytém na všechny možné eventuální smˇery, kterými se další vývoj muže ˚ ubírat. V praxi se ukazuje, že oˇcekávané vlastnosti cˇ asto nejsou nakonec implementovány, alesponˇ ne tak, jak byly oˇcekávány. Proto je snadnˇejší tvoˇrit systém pružnˇeji, jednoduše a na zmˇenu reagovat až pˇri jejím výskytu. Existují pˇrípady, kdy s pomocí refaktoringu byly vyvíjeny systémy bez jakéhokoliv návrhu a postupnˇe uzpusobovány ˚ potˇrebám, ale to je extrémní postup i pro samo XP. 3.4.3
Shrnutí a vhodnost pro jednotlivce
Stejnˇe jako ostatní agilní metodiky, extrémní programování zvládá zmˇeny v zadání a velmi rychle na nˇe dokáže reagovat. Jeden z jeho klíˇcových principu˚ je dˇelat vˇeci nejjednodušším možným zpusobem. ˚ Na tomto místˇe bych rád zmínil, že struˇcnˇe shrnout extrémní programování není jednoduché, nebot’ jde o provázaný systém, kdy jedna z jeho vlastností doplnuje ˇ jinou a výsledek je závislý na synergickém efektu. Extrémní programování je v souˇcasnosti znaˇcnˇe populární záležitostí, dlužno rˇ íci, že však spíše salónní. Plnˇe implementované XP je více ménˇe vzácností. Pro praktikování XP je potˇreba mít v týmu vhodné lidi otevˇrené novým postupum ˚ a myšlenkám, a ochotné spolupracovat s ostatními. Zavést proto kompletní a plnohodnotné XP bývá nároˇcný úkol, který navíc nejde prosadit shora navzdory názorum ˚ jednotlivých vývojáˇru. ˚ Odstrašujícími pˇríklady bývají pˇrípady posmˇešnˇe oznaˇcované jako „témˇerˇ extrémní programování“ 7 I pˇres výše uvedené je možné nˇekteré praktiky popisované XP pˇrevzít samostatnˇe a zaˇclenit je do procesu vývoje. Nejlepším postupem je však použít je v rámci jiné metodiky, napˇr. Scrum se XP velmi dobˇre doplnuje. ˇ Co se vhodnosti pro jednotlivce týˇce, je situace ponˇekud diskutabilní. Podle mého názoru je možné metodiku XP v tomto pˇrípadˇe s jistými ústupky použít. Jak již však bylo naznaˇceno výše, jde o propletené klubko jednotlivých postupu, ˚ z nichž každý má své místo. Jednotlivec musí nutnˇe udˇelat jisté ústupky. Problémem muže ˚ být pˇrítomnost zákazníka po celou dobu vývoje. To je v vˇetšinˇe pˇrípadu˚ neefektivní. Jednotlivec nevyvíjí takovým tempem jako tým, a tak by náklady takového kroku mohly být pˇríliš velké. Mnohem vˇetším
7. Almost Extreme Programming, Cunningham & Cunningham, Inc., http://c2.com/cgi/wiki?AlmostExtremeProgramming (prosinec 2010)
17
3.5. OPENUP problémem je však požadavek na programování v páru. To má své dobré duvody, ˚ jelikož tato technika eliminuje spoustu obtíží, do kterých se programátor dostává. Na tyto obtíže samostatný vývojáˇr naráží o to cˇ astˇeji a k jejich rˇ ešení musí vynaložit úsilí jinak. Zustává ˚ pak otázkou, zda pˇri takovém použití se XP muže ˚ nadále honosit pˇrídomkem extrémní, jelikož jeho jednotlivé cˇ ásti již nejsou dodržovány do krajnosti. Slouží pak spíše jako souhrn zásad, které by mˇel vývoj následovat a jako návod, jak rˇ ešit jednotlivé situace, které pˇri vývoji nastávají.
3.5
OpenUp
3.5.1
Charakteristika
OpenUp (dˇríve OpenUp/Basic) je otevˇrená (open source) metodika vývoje software, která vychází z RUP (Rational Unified Process) spoleˇcnosti IBM. Jde o dalšího zástupce z rˇ ady agilních metodik, která je zamˇerˇ ena spíše na menší týmy. Jedná se o iterativní pˇrístup, který je otevˇrený zmˇenám v prubˇ ˚ ehu vývoje a soustˇredí se na uspokojení potˇreb zákazníka za použití co nejmenších nákladu. ˚ Snaží se jasnˇe definovat problémy, které mají být rˇ ešeny a na základˇe jejich dukladného ˚ poznání navrhnout co nejlepší strategii vývoje. Souˇcástí postupu˚ OpenUp je snaha o vytvoˇrení pˇríjemného prostˇredí pro tým, kde lidé nebudou mít strach projevit svuj ˚ pohled na vˇec cˇ i se nebudou bát udˇelat chybu. Striktnˇe vzato nejde o pˇresnou a koneˇcnou metodiku, spíše o rámec, který umožní nadefinovat postup vývoje pˇrímo na míru konkrétním podmínkám. Definuje formální náležitosti vývoje, v podstatˇe jako jakési základní stavební kameny a postupy, jakým mohou být tyto cˇ ásti propojeny v jeden celek. Tyto postupy však mohou být podle potˇreby pro každý projekt jiné, jednotlivé stavební prvky vynechány cˇ i pˇridány nové. Takto ponechává OpenUp v duchu agilní filosofie volnou ruku pˇri prubˇ ˚ ehu projektu, avšak umožnuje ˇ využít postupy, které se v minulosti osvˇedˇcily. OpenUp se oznaˇcuje jako minimální, úplný a rozšiˇritelný (minimal, complete and extensible). To znamená, že jde o lehkou, jednoduchou metodiku, která neˇreší spousty okolností, které mohou pˇri vývoji software nastat. Obsahuje však základ, který je dostateˇcný pro celý prubˇ ˚ eh projektu a jen s tímto základem samotným je možné dovést vývoj ke zdárnému konci. Pokud je potˇreba, je možné proces doplnit a rozšíˇrit o další potˇrebné cˇ innosti. Jak již bylo rˇ eˇceno, jde o iterativní pˇrístup. Iterace jsou rozdˇeleny do nˇekolika úrovní. Typicky mˇesíˇcní iterace procházejí stádii Inception (zahájení), Elaboration (rozpracování), Construction (vývoj) a Transition (pˇremˇena). V každé z tˇechto fází projekt prochází nˇekolika zhruba týdenními iteracemi. Tyto týdenní iterace nejsou mezi stádia pˇresnˇe rozdˇeleny a záleží vždy na povaze projektu, ve které fázi potˇrebuje strávit více cˇ asu a kde naopak staˇcí ménˇe. Každodenní práce pak probíhá v tzv. mikroiteracích, které mohou trvat klidnˇe jen v rˇ ádu hodin. Díky tˇemto mikroiteracím je stále vidˇet pokrok, což je jistˇe motivující. Všudypˇrítomnou souˇcástí iterací je testování. To probíhá pˇri dokonˇcení každého úseku, zmˇenˇe zadání cˇ i objevení chyby. Stejnˇe jako ostatní zde uvedené agilní metodiky OpenUp vsází na cˇ astou a dukladnou ˚ komunikaci se zákazníkem. Jeho zástupce by pokud možno mˇel být pˇrítomen na pracovišti 18
3.5. OPENUP a podílet se zejména na plánování. Spoleˇcnˇe se cˇ leny týmu pracují na analýze, jejíž výstupem bývají v OpenUp use case diagramy cˇ i scénáˇre. Detailní pochopení problému a jeho rozbor je základem této metodiky. Na tˇechto základech je pak budována propracovaná architektura, na kterou je také kladen velký duraz. ˚ Tímto se OpenUp snaží cˇ ásteˇcnˇe pˇredcházet zmˇenám v zadání a pˇredevším odhalit a omezit riziko ohrožující úspˇech projektu. V prubˇ ˚ ehu je vypracován Iteration Plan (plán iterací), Work Item List (seznam všech požadavku) ˚ a Risk List (seznam rizik). Identifikace a vyhýbání se riziku je typickou souˇcástí OpenUp. Pokud se v prubˇ ˚ ehu procesu narazí na možný problém, napˇr. nedostateˇcnou technologii cˇ i nutnost použít již vytvoˇrenou aplikaci, je nutné na toto riziko urˇcitým zpusobem ˚ reagovat.
Obrázek 3.4: Vrstvy OpenUp, pˇrevzato z internetových stránek Eclipse Foundation, http://epf.eclipse.org/wikis/openup/ (prosinec 2010)
3.5.2
Role
OpenUp definuje sedm základních rolí. Jeden cˇ lovˇek muže ˚ zastávat více rolí zároven, ˇ muže ˚ je stˇrídat napˇr. podle toho, v jaké fázi se projekt nachází. Duležité ˚ je, že nemuže ˚ v jeden okamžik zastávat více rolí. Role jsou tedy stejnˇe jako v metafoˇre uvedené u metodiky FDD 19
3.5. OPENUP ˇ pomyslné klobouky. Clovˇ ek muže ˚ mít na hlavˇe v jednu chvíli pouze jeden klobouk. Jednotlivé role jsou tyto:
Stakeholder Reprezentant zákazníka. Jde o nˇekoho, kdo bude mít z projektu nˇejaký užitek cˇ i zisk.
Analyst Osoba, která pˇrevádí vstup od zákazníka (stakeholder) na výstup v podobˇe analýzy. Snaží se detailnˇe porozumˇet požadavkum ˚ a poté je zdokumentovat.
Architect Spolupracuje s analytiky a vývojáˇri a urˇcuje kostru – architekturu systému. Má rozhodující slovo v klíˇcových architektonických otázkách a snaží se odhalit rizika plynoucí z použitých technologií. Spolu s manažery se podílí na plánování projektu a rozdˇelování úkolu˚ mezi jednotlivé lidi.
Developer Vývojáˇr navrhuje a implementuje jednotlivé cˇ ásti systému, testuje je zodpoˇ vˇedný za jejich zaˇclenˇení do stávající architektury. Casto spolupracuje s architektem.
Project Manager Stejnˇe jako v ostatních metodikách má manažer projektu na starosti blaho cˇ lenu˚ týmu, aby mˇeli optimální podmínky pro práci, komunikuje se zástupci zákazníka a snaží se, aby tým co nejlépe fungoval.
Tester Snaží se najít a vytvoˇrit co nejlepší testy a zaznamenává jejich výstupy. Spolu se zbytkem týmu pak pracuje na odstranˇení nalezených chyb.
Any Role Každý cˇ len týmu muže ˚ vystupovat v této roli a plnit tak nˇekteré z obecných úkolu. ˚
3.5.3
Principy
Celý proces, který rámec OpenUp ustanovuje, vychází ze cˇ tyˇr principu: ˚
Balance competing priorities to maximize stakeholder value Volnˇe pˇreloženo jako „vyvažování priorit za úˇcelem maximalizace zisku“. Tento pilíˇr vychází z myšlenky, že systém by mˇel umˇet to, co je požadováno a nic navíc. Snaží se udržet software pˇrijatelnˇe použitelný, aby se nestal pˇrerostlou obludou, která se bude snažit umˇet vše, 20
3.5. OPENUP ale nic z toho nebude dˇelat poˇrádnˇe. Vystupuje zde snaha implementovat to nejdu˚ ležitˇejší, co je požadováno, aby byl rozpoˇcet maximálnˇe zužitkován. Prubˇ ˚ ežnˇe zavádˇené zmˇeny mohou tento status quo narušit a tak je potˇreba rovnováhu mezi požadavky a omezeními systému znovu vytvoˇrit. Takový pˇrístup vyžaduje pochopení ze strany zákazníka a naopak vývojáˇri se nesmí bránit zmˇenám. Z tohoto duvodu ˚ klade OpenUp takový duraz ˚ na architekturu systému a její pravidelnou údržbu pˇrípadnˇe zmˇenu. Collaborate to align interests and share understanding Tento princip by se dal volnˇe pˇreložit jako „Spolupracovat a sdílet zájmy a porozumˇení“. Týmy jsou tvoˇreny lidmi s ruznými ˚ znalostmi a dovednostmi. Je proto nutné tyto rozdíly smazávat a podporovat týmového ducha a spolupráci. Sdílení znalostí jak technických, tak zejména tˇech, týkajících se projektu a oblasti, kterou pokrývá je dobrým pˇredpokladem pro rychlejší a kvalitnˇejší vývoj. Lidé jsou povzbuzováni k výmˇenˇe informací jak mezi sebou v rámci jedné role (napˇr. vývojáˇri), tak i zástupci zákazníka s architektem apod. ˇ Clenové týmu by spolu mˇeli cˇ asto komunikovat, což je podporováno i spoleˇcnou zodpovˇedností. Nikdo nevlastní cˇ ást projektu, napˇr. cˇ ást kódu. Vztahy by nemˇely sklouzávat do osobní roviny a lidé by se mˇeli snažit problém nahlédnout z perspektivy toho druhého. Focus on the architecture early to minimize risks and organize development „Od poˇcátku se soustˇredit na architekturu za úˇcelem minimalizace rizika a uspoˇrádání vývoje“. Kvalitní architektura vytvoˇrená na základˇe všech dostupných znalostí o problému je základem OpenUp. Pˇredchází se tak pˇrípadným rizikum, ˚ která mohou v pozdˇejších fázích nastat. Budovaný systém by nemˇel dopˇredu pˇríliš poˇcítat s pˇrípadnými požadavky, je však záhodno jej budovat s ohledem na budoucí zmˇeny. To znamená, že architektura by mˇela být flexibilní a pˇrístupná zmˇenám, ale jen v obecné rovinˇe. Systém by mˇel být budován na základˇe objektovˇe orientovaného modelu v podobˇe malých a navzájem co nejménˇe provázaných jednotek. Tomuto pˇrístupu napomáhá také jednotkové testování, které je souˇcástí OpenUp. Jednotlivé komponenty tak mohou být znovu použity a nebo není nutné je vyvíjet vlastními silami, ale integrovat existující rˇ ešení. Evolve to continuously obtain feedback and improve Tento princip by se dal do cˇ eštiny pˇreložit jako „Prubˇ ˚ ežnˇe se vyvíjet a zlepšovat pomocí zpˇetné vazby“. V podstatˇe jde o shrnutí iterativního vývoje a cˇ astého vydávání funkˇcních verzí produktu. Na jejich základˇe zákazník vidí, co se vytvoˇrilo a dále zpˇresnuje ˇ zadání cˇ i pˇrehodnocuje priority. Jak je uvedeno výše, životní cyklus projektu je rozdˇelen do fází. Každá z tˇechto fází by mˇela mít jasnˇe definovaný cíl a tomu se pˇrizpusobí ˚ práce na jednotlivých iteracích bˇehem dané fáze. Takto je snadnˇejší odhalovat a odstranovat ˇ rizika cˇ i jim 21
3.6. SHRNUTÍ pˇredcházet.
3.5.4
Vhodnost pro jednotlivce
OpenUp je velmi volnou metodikou, která poskytuje stavební kameny, ze kterých muže ˚ být položen základ pro vývoj jakéhokoliv softwarového projektu. I když jde o základní rámec, který pokrývá ty nejnutnˇejší aspekty vývoje, pro jednotlivce muže ˚ být o to vhodnˇejší, jelikož se soustˇredí jen na meritum vˇeci. Navíc jde o velmi volný rámec, který si muže ˚ každý uzpu˚ sobit k obrazu svému. Primárnˇe je urˇcen malým týmum, ˚ cˇ emuž odpovídají i jeho role, které navíc mohou být vykonávány jedním cˇ lovˇekem. Není zde pˇrítomen management, který by držel nad týmem biˇc a dodával mu tak motivaci. Vývojáˇri mají dost vlastní zodpovˇednosti. Je proto možné všechny role delegovat na jednoho cˇ lovˇeka. OpenUp je dost formální metodikou, pˇresto je dostateˇcnˇe volnou v konkrétní implementaci. Poskytuje potˇrebné nástroje pro rˇ ízení prubˇ ˚ ehu vývoje, ale umožnuje ˇ tyto nástroje pˇrizpusobit ˚ potˇrebám. Tento formální rámec muže ˚ nˇekomu vyhovovat, jinému zase ne. Podle mého názoru je OpenUp vhodný pro ménˇe zkušené vývojáˇre. Není ovšem tak jednoduchý a pˇrímoˇcarý jako napˇríklad Scrum. Vyžaduje proto jistou investici do jeho pochopení a nauˇcení. Na oplátku nabízí pevnou ruku, která vývojáˇre provede všemi fázemi projektu a umožní mu vyvarovat se chyb, kterých by se ve volnˇejší metodice mohl dopustit. OpenUp s sebou také nese jistou režii, byt’ se ji snaží minimalizovat.
3.6
Shrnutí
V této kapitole jsem rozebral, proˇc je podle mého názoru agilní filosofie tím správným pˇrístupem pro samostatného vývojáˇre. Uvedl jsem a zbˇežnˇe popsal nˇekolik agilních metodik a zhodnotil jejich použitelnost pro jednotlivce. Každá z tˇechto metodik se pˇrirozenˇe soustˇredí na práci v týmu a rˇ eší problémy z toho vyplývající. Zárovenˇ však poskytují rámec, kterým se vývoj rˇ ídí a ten jako takový muže ˚ být využit i jednotlivcem. Z mnou zkoumaných metodik se mi jako nevhodná pro samostatného vývojáˇre jeví Feature driven development. Ta se soustˇredí pˇrevážnˇe na koordinaci týmové práce a je primárnˇe zamˇerˇ ena na vˇetší týmy. Jako vhodná se mi naopak jeví metodika OpenUp, která poskytuje dostateˇcnou volnost implementace a od poˇcátku poˇcítá s malým týmem. Použitelná mi také pˇripadá kombinace Scrum a XP, kde Scrum poskytuje dostateˇcnˇe pružný rámec, který vede vývojáˇre v prubˇ ˚ ehu vývoje produktu a umožní mu nesklouznout k podružnostem a soustˇredit se na priority. Extrémní programování pak poskytuje spíše sadu doporuˇcení, jejichž dodržování vede k vyšší produktivitˇe a kvalitnˇejšímu produktu. Použít samostatné XP pro vývoj jednotlivcem mi pˇrijde ponˇekud obtížné a myslím si, že kombinace se Scrumem je z hlediska dodržování zásad vývoje bezpeˇcnˇejší.
22
Kapitola 4
Návrh vlastní metodiky Ze své povahy je individuální práce jedineˇcná, možná i to je jeden z duvod ˚ u, ˚ proˇc dosud žádná pevná metodika pro jedince nebyla stanovena. Zdálo by se, že vývojáˇr pracující na projektu jako jediný a sám je naprostým opakem týmové práce. Ovšem pˇri bližším pohledu bychom nalezli pojítka, která tyto dva svˇety sbližují. Agilní techniky se z velké cˇ ásti zamˇeˇ rˇ ují na oblast lidské produktivity, komunikace a spolupráce. Reší, jak práci v týmu udˇelat co nejefektivnˇejší maximalizací spolupráce, ale také zvýšením výkonu každého jednotlivce. a právˇe tyto aspekty je možné využít i pro potˇreby samostatného vývojáˇre. V této kapitole bych rád shrnul poznatky získané vlastní zkušeností a studiem agilních metodik. Nastíním problémy, se kterými se musí samostatný vývojáˇr potýkat. Dále navrhnu vlastní metodiku, cˇ i postup práce, který se mi jeví vhodný spolu s doporuˇceními, jak zmínˇené problémy eliminovat.
4.1
Problémy pˇri práci samostatného vývojáˇre
Mohli bychom rˇ íci, že samostatný vývojáˇr rˇ eší tytéž problémy jako malý tým, možná s vyjímkou každodenní komunikace. Jeho pozice je však o to tˇežší, protože je na to všechno sám. Velkým problémem muže ˚ být nedostatek motivace k práci. Lidé (a programátoˇri obzvlášt’, u nich tato vlastnost bývá dokonce do urˇcité míry vyžadována) jsou povˇetšinou od pˇrírody líní. Obzvláštˇe, pokud pracují na nˇecˇ em, co je nebaví, v cˇ em nevidí smysl nebo pokud si nevˇerˇ í, že zadaný úkol mohou zvládnout. Nemusí jít nutnˇe o tak zjevné pˇríˇciny, ale už jenom jejich náznaky ovlivní výkon a pˇristup k práci. Jednotlivec to má o to tˇežší, že nad ním nestojí žádný dráb s dutkami, ˚ který by jej do práce popohánˇel. Vˇetšinou jediné, co ho tlaˇcí, je blížící se termín odevzdání. Jelikož mu tedy chybí vedení, které by na nˇej dohlíželo, musí být takovým manažerem sám sobˇe. Dalším problémem, se kterým je potˇreba poˇcítat, je nedostatek reflexe. To se muže ˚ projevit napˇríklad nedostatky v návrhu, kterých by si nˇekdo jiný všiml na první pohled. To samé se týká i kódu. Pokud cˇ lovˇek pˇredpokládá, že bude jediným, kdo bude kód v budoucnu cˇ íst, má tendenci psát jej co nejúspornˇeji. Vynechává komentáˇre, nedodržuje formátování textu, nepoužívá smysluplné názvy metod. To všechno nemusí být vˇedomá a úmyslná cˇ innost. Jde o pˇrirozený proces, kterému se snaží všichni vedoucí týmu˚ a metodiky obecnˇe pˇredcházet. Podstata problému tady není v tom, že by kódu nerozumˇel nˇekdo cizí (i když i to muže ˚ být nˇekdy nutné), ale v tom, že mu nebude rozumˇet s cˇ asovým odstupem ani sám autor. Toto je celkem známý fakt, pˇresto dodržování jistých zásad je pro samostatného vývojáˇre tˇežší než 23
ˇ PRÁCI SAMOSTATNÉHO VÝVOJÁ RE ˇ 4.1. PROBLÉMY P RI pro programátora, který pracuje ve skupinˇe. Toho každodenní kontakt s kolegy dostává do situace, kdy konzultuje své rˇ ešení s ostatními a už jen vˇedomí jejich pˇrítomnosti mu pˇripomíná, že napˇr. i pˇri psaní kódu nesmí myslet jen na sebe. Jak vyplynulo již z popisu agilních metodik výše, software je náchylný ke zmˇenˇe a ta muže ˚ být nákladná. Proto jsou alesponˇ ve vˇetšinˇe pˇrípadu˚ pryˇc doby, kdy kód musel být hlavnˇe rychlý a úsporný. Dnes již takováto úspornost ustupuje spíše ve prospˇech kvality struktury kódu, protože se oˇcekává jeho zmˇena v budoucnu. Za kvalitního programátora je považován ten, kdo dokáže navrhnout a napsat kód pˇrehlednˇe, srozumitelnˇe a jasnˇe, aby jej i ostatní rychle pochopili. Na programátora, píšícího samostatnˇe a bez kontaktu s okolím však nepusobí ˚ takové síly jako na cˇ leny týmu, aby právˇe pracoval právˇe takovýmto zpusobem. ˚ Nˇeco takového, jako je revize kódu, je pro nˇej jen nesplnitelný sen. Dalším oˇríškem plynoucím ze samoty a nepˇrítomnosti kolegu˚ mohou být ruzné ˚ zapeklité situace, do nichž muže ˚ vývojáˇr bˇehem práce zabˇrednout. Pokud cˇ lovˇek v kolektivu narazí na problém, je velmi snadné se obrátit na kolegy o pomoc. Více hlav více ví a také více oˇcí lépe vidí. Nˇekdy se cˇ lovˇek zasekne na problému klidnˇe i po nˇekolik hodin a neˇ daˇrí se mu pˇrijít s rˇ ešením. Casto však staˇcí, aby se na tentýž problém podíval nˇekdo jiný ˇ a okamžitˇe vidí jeho rˇ ešení. Casto se tak vývojáˇr pracující samostatnˇe muže ˚ dostat do slepé uliˇcky a strávit v ní zbyteˇcnˇe mnoho cˇ asu. Nemusí se však jednat jen o tzv. profesionální ˇ slepotu. Clovˇ ek se muže ˚ dostat do úzkých i díky problémum ˚ technického rázu. Nemá však možnost zeptat se zkušenˇejšího kolegy sedícího vedle. Internet tento problém cˇ ásteˇcnˇe rˇ eší dostupností rychlé komunikace, ale osobnˇe poprosit kolegu o pomoc s tím, že jste schopni mu pˇrímo ukázat svou dosavadní práci je mnohem rychlejší a také pohodlnˇejší. Specifickým pˇrípadem tohoto problému muže ˚ být nedostatek komunikace se zákazníkem. Agilní metodiky poˇcítají se klientem nebo alesponˇ s jeho zástupcem pˇrítomným na pracovišti. Takovýto požadavek je pro samostatného vývojáˇre bohužel v drtivé vˇetšinˇe pˇrípadu˚ nerealistický. Nebývá pˇríliš efektivní, aby byl zástupce zákazníka neustále pˇrítomen vývoji vedeného jedním cˇ lovˇekem. Pravdˇepodobnˇejší variantou je spíše to, že se vývojáˇr pˇresune za klientem. Ani toto však nebývá pˇríliš cˇ astá forma spolupráce. Další potíží, se kterou je potˇreba se pˇri samostatné práci potýkat, je snaha o dokládání nepˇríjemných úkolu. ˚ Tento problém je obzvláštˇe patrný díky absenci vedení dohlížejícího ˇ na práci. Clovˇek má tendenci vˇenovat se tˇem nejzábavnˇejším aspektum ˚ projektu a odkládat ty ménˇe zábavné, avšak cˇ asto velmi duležité. ˚ Jako typický pˇríklad bych uvedl testování. Tomu se spousta vývojáˇru˚ snaží vyhnout, vˇetšinou proto, že nevidí jeho pˇrínos a podle nich je jenom zdržuje od skuteˇcné práce. Tímto problémem trpí i celé firmy a vysvˇetlit pˇrínosy testování je cˇ asto velmi obtížný až nesplnitelný úkol. Pokud bude jednotlivec odsouvat nepˇríjemné práce na vedlejší kolej a poté je úplnˇe vynechávat, není tu nikdo, kdo by mu pˇripomnˇel jejich duležitost. ˚ ˇ Testování je zde uvedeno jen jako jeden z pˇríkladu. ˚ Druhým by mohla být analýza. Casto se stává, že cˇ lovˇek dostane zadání nového projektu a plný nadšení se ihned pustí do jeho realizace. Taková realizace ovšem spoˇcívá jen v psaní kódu. I když by se to tak v akademickém prostˇredí nemuselo jevit, je nedostateˇcná nebo dokonce žádná analýza jednou z velkých bolestí, kterou vývoj software trpí. Tomu také cˇ elí agilní metodiky durazem ˚ na analytickou 24
ˇ PRÁCI SAMOSTATNÉHO VÝVOJÁ RE ˇ 4.1. PROBLÉMY P RI fázi a design budovaného systému. Tento pˇrístup, kdy cˇ lovˇek okamžitˇe po zadání úkolu sedne ke klávesnici a zaˇcne programovat rˇ ešení je u samostatných vývojáˇru, ˚ zejména tˇech mladších, pomˇernˇe rozšíˇrený. Anglicky bývá takový styl práce pejorativnˇe oznaˇcován jako „Cowboy coding“. Tento výraz souhrnnˇe oznaˇcuje „hurá styl“ pˇrístupu k vývoji. Nejde jen o absenci analytické fáze, ale i o výslednou kvalitu kódu, který muže ˚ perfektnˇe plnit svuj ˚ úˇcel, ale dalšímu rozšíˇrení klade zatvrzelý odpor. U vˇetších projektu˚ je tento pˇrístup témˇerˇ nemožný a vede k neúspˇechu. Dalším aspektem, který musí samostatný vývojáˇr vzít v potaz je hospodaˇrení s cˇ asem. Výhodou samostatnosti muže ˚ být možnost urˇcit si vlastní cˇ as na práci. Není nutné od devíti do pˇeti sedˇet v kanceláˇri hodinu cesty od domova. Nˇekomu napˇríklad vyhovuje pracovat v noci a je mnohem produktivnˇejší, než by byl v osm hodin ráno. Každý cˇ lovˇek vypozoruje po která období bývá nejaktivnˇejší a je pak snadné je využít k práci. Ovšem ruku v ruce s takovou volností pˇricházejí i problémy. Jedním z nich muže ˚ být ztráta soukromí, cˇ i spíše ˇ ztráta schopnosti rozlišovat domácí a pracovní prostˇredí. Clovˇeku napˇríklad tím, že pracuje z domu, splývají pracovní problémy s bˇežným soukromým životem a cítí se jakoby byl stále v zamˇestnání. Nebo si práci rozkouskuje na celý den a není pak schopen si najít dostatek cˇ asu na své osobní zájmy. Velmi cˇ asto se pak lidé uchylují k nˇejaké formˇe pevné pracovní doby, kterou si sami stanoví. Obˇcas také pracují odjinud, než z domu. V rámci akademického prostˇredí muže ˚ být rˇ ešením napˇríklad práce jen ze školy. Dalším, spíše druhotným problémem mohou být pracovní pˇrestávky. Ty totiž vˇetšinou nejsou dodržovány ani v kolektivním prostˇredí. Tam je ovšem vˇetší šance pˇrerušení práce napˇr. vyrušením ze strany kolegu˚ (byt’ nežádoucím). a i drobné rozptýlení, byt’ by mˇelo být špatnˇe naˇcasováno, muže ˚ v tomto smˇeru pomoci. ˇ Casto se také stává, že cˇ lovˇek pracující sám pˇrestane rozlišovat duležitost ˚ a priority svých jednotlivých cˇ inností. Klasickým pˇrípadem muže ˚ být nabalování problému, ˚ které vznikají bˇehem vývoje. Bˇehem rˇ ešení jednoho úkolu vývojáˇr zjistí, že pro jeho dokonˇcení potˇrebuje vytvoˇrit cˇ i upravit jinou komponentu. Práce na této komponentˇe však ukáže nutnost dalšího zásahu nˇekde jinde. a tak dále. Takto je cˇ lovˇek odveden ne úplnˇe vlastní vinou od podstaty problému, který rˇ ešil. Ztratit se v takovýchto vedlejších zásazích je pomˇernˇe snadné, obzvlášt’ pokud je cˇ lovˇek perfekcionalista nebo pˇri rˇ ešení úkol narazí na oblast, ˇ která by podle nˇej potˇrebovala vylepšit. Casto tak zaˇcne ztrácet cˇ as vývojem cˇ ástí, které nejsou vubec ˚ potˇreba nebo je staˇcí implementovat v mnohem menším rozsahu. Neexistence zpˇetné vazby, zejména ze strany zákazníka cˇ iní tento problém o to naléhavˇejším. V týmu spolupracovníku˚ by se poradil s kolegou cˇ i pˇrípadnˇe s nˇekým, kdo má rozhodující slovo co se požadavku˚ týˇce. Variantou tohoto problému muže ˚ být nedostateˇcné zadání. Najednou v prubˇ ˚ ehu vývoje cˇ lovˇek zjistí, že neví, jak daný požadavek implementovat. Jelikož nemá okamžitou zpˇetnou vazbu od kolegu˚ cˇ i zákazníka, musí bud’ práci pˇrerušit nebo se pokusit odhadnou, co a jak má dˇelat.
25
4.2. PROCESNÍ RÁMEC
4.2
Procesní rámec
V kapitole pˇredstavující jednotlivé agilní metodiky jsem u rámce Scrum uvedl, že je za jistých úprav použitelný i pro jednotlivce. Pro mˇe osobnˇe je zpusob, ˚ jakým je Scrum navržen, právˇe tím nejlepším pˇrístupem, jak se vyhnout nˇekterým problémum ˚ zmínˇeným výše a udržet si stabilní a vysoké tempo vývoje za minimální byrokratické režie. Upravený a pˇrizpuso˚ bený Scrum však není samospásnou metodiku, která by vyˇrešila všechny obtíže. Poskytuje pouze vodítko prubˇ ˚ ehem projektu a spoustu ostatních vˇecí ponechává k rˇ ešení vývojáˇri samotnému. Proto mi pˇripadá vhodné tento rámec urˇcující smˇer vývoje doplnit, zejména prvky z XP, což bude popsáno dále. Nyní pˇrejdˇeme k popisu samotného procesního rámce, vzniklého úpravami metodiky Scrum. Zustává ˚ zachován iterativní proces poˇcínající úpravami Product Backlogu a vytvorˇ ením Sprint Backlogu, dále pˇrichází samotný sprint s denními iteracemi, jehož výstupem je funkˇcní software. Tento cyklus samotný však není dostaˇcující a je potˇreba rˇ ešit problémy, které se u týmové práce spíše nevyskytují a Scrum je nereflektuje. Zejména absence schuzek ˚ nabourává klasické schéma Scrumu a je potˇreba jej vyvážit jinak, což bude v práci dále popsáno. 4.2.1
Role
K použití základu˚ Scrumu jako prvku˚ metodiky pro vývoj vedený jedním cˇ lovˇekem se pˇrikláním díky jeho jednoduchosti a volnosti, kterou Scrum poskytuje. Již z výˇctu rolí je zˇrejmé, že nejde o žádnou detailní techniku diktující každiˇcký aspekt práce. Scrum definuje tˇri role, z nichž žádná nemá nˇejaké zvláštní pravomoci ani vliv nad ostatními. U pˇrizpusobení ˚ agilních metodik jednotlivci je jednou z výzev role zákazníka cˇ i jeho zástupce, která se u každé z nich vyskytuje. Nejinak je tomu i v pˇrípadˇe metodiky Scrum. Ta pro tento úˇcel zavádí roli s názvem „Product Owner“. Nevidím zpusob, ˚ jakým muže ˚ jednotlivec tuto roli nahradit. Muže ˚ však absenci její pˇrítomnosti vyvážit co nejlepším kontaktem na zákazníka cˇ i zadavatele. Dále je tedy nutné spojit dvˇe zbývající role, „ScrumMaster“ a „Tým“, do jedné. Pˇrestože ScrumMaster muže ˚ být zárovenˇ vývojáˇr, bývá jeho místo v týmu specifické. K jeho zodpovˇednosti patˇrí „umetat týmu cestiˇcku“, aby mˇeli k práci co nejpˇríhodnˇejší podmínky. Další jeho úlohou je dohlížet na dodržování zásad metodiky. Vývojáˇri se pak mohou soustˇredit na práci samotnou. Tato role má v metodice Scrum nezastupitelné místo a bohužel ji nelze v metodice poˇcítající jen s jedním cˇ lovˇekem nahradit. Proto je tˇreba se pokusit její absenci vyvážit jinými prostˇredky. Navrhovaná metodika tedy pracuje se dvˇema rolemi:
Product Owner V podstatˇe totožná role, jakou definuje metodika Scrum. Jde o zástupce zákazníka cˇ i pˇrímo o klienta. Vývojáˇr Jeden jediný cˇ lovˇek, vykonávající všechnu práci v prubˇ ˚ ehu vývoje projektu.
26
4.2. PROCESNÍ RÁMEC 4.2.2
Artefakty
Metodika Scrum byla jako výchozí základ zvolena i z duvodu ˚ malého poˇctu nutných artefaktu. ˚ Navrhovaná metodika tyto artefakty pro své potˇreby zjednodušuje natolik, aby podporovaly její procesy, ale zárovenˇ nekladly zbyteˇcné byrokratické pˇrekážky. Žádné další formální vstupy ani výstupy již nejsou tˇreba.
Product Backlog Vývojáˇr na základˇe analýzy a konzultace se zadavatelem sestaví Product Backlog. Nejlepším zpusobem ˚ je vytvoˇrit tento seznam požadavku˚ na budovaný systém spoleˇcným úsilím za osobní úˇcasti zadavatele. Spoleˇcnˇe ohodnotí požadavky a vznikne tak seznam seˇrazený dle priorit. Vývojáˇr muže ˚ okamžitˇe odhadovat pˇribližné množství práce na jednotlivých bodech a i na základ tohoto odhadu jsou priority dále upˇresnovány. ˇ Sprint Backlog Sprint Backlog obsahuje seznam požadavku˚ z Product Backlogu, které budou implementovány v nadcházejícím sprintu. Tento dokument vytváˇrí vývojáˇr spoleˇcnˇe s Product Ownerem, ale do finální podoby jej dopracuje už sám vývojáˇr. Spoleˇcnˇe vyberou z Product Backlogu úkoly a vývojáˇr sám je pak dekomponuje na jednotlivé cˇ ásti, které cˇ asovˇe ohodnotí. Tyto menší cˇ ásti pak tvoˇrí budované celky, které jsou samostatnˇe otestovány a poté zaˇclenˇeny do stávajícího systému. Burn Down Chart Stejnˇe jako v metodice Scrum ukazuje Burn Down Chart prubˇ ˚ eh sprintu. Graf, kde je na ose X zanesen cˇ as Sprintu a na ose Y cˇ asové ohodnocení všech požadavku˚ pro aktuální sprint. Když vývojáˇr dokonˇcí nˇejaký úkol, zanese do grafu aktuální hodnotu cˇ asového ohodnocení všech nehotových úkolu˚ v aktuálním cˇ ase. Není ovšem nutné vést graf dokonale pˇresnˇe, jelikož jeho smyslem je pouze naznacˇ ení prubˇ ˚ ehu vývoje. Postaˇcí, když z nˇej pujde ˚ vyˇcíst, zda se práce opožd’uje nebo naopak pˇredbíhá oproti ideálnímu prubˇ ˚ ehu.
4.2.3
Životní cyklus
Dalším prvkem, kterým se mnou navržená metodika liší od Scrumu, jsou pochopitelnˇe schuzky. ˚ Nemyslím tím ovšem jejich absenci, protože dodržování rozvrhu urˇcovaného právˇe schuzkami ˚ urˇcuje životní cyklus této metodiky. Dodržování tˇechto schuzek ˚ pomuže ˚ zajistit, že vývoj bude rˇ ízen touto metodikou.
27
4.2. PROCESNÍ RÁMEC
Obrázek 4.1: Cyklus navržené metodiky, upraveno http://en.wikipedia.org/wiki/File:Scrum_process.svg
autorem,
puvodní ˚
zdroj
Sprint Review and Planning Meeting Po dokonˇcení sprintu na schuzce ˚ s Product Ownerem vývojáˇr demonstruje, co všechno se mu podaˇrilo dokonˇcit. Doˇreší se pˇrípadné nesrovnalosti, napˇríklad nedokonˇcené úkoly. Nemusí být možné uskuteˇcnit tyto dvˇe fáze bˇehem jedné schuzky. ˚ Muže ˚ se stát, že zadavatel chce nový systém vyzkoušet a teprve po tomto testu navrhne pˇrípadné zmˇeny, nové úkoly cˇ i pˇrehodnotí priority. Nicménˇe, pokud je to možné, je vhodné toto vše stihnout bˇehem jednoho setkání. V pˇrípadˇe, že ještˇe žádný sprint neprobˇehl, tato cˇ ást samozˇrejmˇe odpadá. 28
4.2. PROCESNÍ RÁMEC Diskuze o uplynulém sprintu a pˇredvedení systému by mˇelo plynule pˇrejít v další cˇ ást, kde se na základˇe priorit a cˇ asového odhadu vyberou ty požadavky, které budou implementovány v nadcházejícím sprintu. Výstupem je upravený Product Backlog a naˇcrtnutý Sprint Backlog. Ten si vývojáˇr detailnˇe rozpracuje už sám. Daily Sprint Po této úvodní fázi následuje první sprint. Ten bývá cˇ asto specifický, protože je nutné vytvoˇrit kostru budoucího systému. Toto obzvlášt’ platí v pˇrípadˇe, kdy je software budován tzv. na zelené louce, kdy není využíván žádný framework, který by práci usnadnil. Vybudování základu˚ projektu a jeho infrastruktury muže ˚ být z pohledu Scrumu, ale i jiných metodik, pomˇernˇe nevdˇecˇ ná záležitost. V tomto kroku totiž s velkou pravdˇepodobností nebude implementováno mnoho požadované funkcionality, ale vznikne spíše jen prototyp budoucího systému. Jelikož je vývoj podle metodiky Scrum soustˇredˇen do menších úkolu˚ rozprostˇrených pˇres celý sprint, je nutné i toto poˇcáteˇcní budování rozdˇelit do menších celku. ˚ Toto je vˇetšinou na vývojáˇri samotném, jelikož ne vždy bude zadavatel na potˇrebné technické úrovni. Z pohledu zadavatele se tak muže ˚ zdát, že se i pˇres spoustu vynaloženého úsilí v podstatˇe nic neudˇelalo. Toto by mˇel vzít vývojáˇr na vˇedomí a správnˇe rozvrhnout a cˇ asovˇe ocenit jednotlivé kroky. Mˇel by se také snažit zadavateli vysvˇetlit jejich nezbytnost. Rizikem, které zde hrozí je to, že se vývojáˇr zaváže v prvním sprintu k implementaci více vlastností, než je ve skuteˇcnosti schopen zvládnout. Pˇrínos iterativního vývoje se tak vytrácí a muže ˚ dojít bud’ k prodloužení sprintu nebo nedokonˇcení vˇetšího množství naplánovaných úkolu. ˚ První sprint by proto mˇel být naplánován obzvlášt’ peˇclivˇe a s dostateˇcnou cˇ asovou rezervou. Toto vše ovšem závisí na okolnostech konkrétního projektu a také na zadavateli samotném. Samotný prubˇ ˚ eh sprintu je plnˇe v rukou vývojáˇre. Metodika Scrum diktuje každodenní setkání Daily Scrum. V týmovém pojetí je úˇcelem tohoto krátkého setkání sdílení poznatku, ˚ odstranˇení problému˚ a distribuce znalostí o systému mezi vývojáˇri. Toto samozˇrejmˇe u jednoho cˇ lovˇeka odpadá, a tak si vývojáˇr na zaˇcátku denního cyklu pouze vybírá, který bod Sprint Backlogu bude implementovat. V drtivé vˇetšinˇe pˇrípadu˚ je však poˇradí úkolu˚ dáno jejich prioritou. Vývojáˇr pak takto snáze udrží pozornost na duležitých ˚ vˇecech a nebude mít tendenci sklouzávat k jiným úkolum. ˚ Bˇehem sprintu vývojáˇr prubˇ ˚ ežnˇe upravuje Burn Down Chart. Tento graf je vhodné si udržovat i pˇri samostatné práci, jelikož je na nˇem pˇrehlednˇe vidˇet stav vývoje. Díky tomu je snadnˇejší vyhnout se problémum ˚ s nedokonˇcenými úkoly, které mohou být zavˇcasu pˇrevedeny zpˇet do Product Backlogu. Graf také poskytuje jistý motivaˇcní prvek a funguje i jako odmˇena. Pohled na klesající kˇrivku pomˇeru dokonˇcených a nedokonˇcených úkolu˚ je dobrým zpusobem, ˚ jak v prubˇ ˚ ehu rozsáhlého pocitu nepropadnout marnosti z toho, že vlastnˇe nic není hotovo. Dokonˇcené úkoly jsou okamžitˇe vidˇet a samotné odškrtávání splnˇených úkolu˚ je velmi pˇríjemnou cˇ inností.
29
4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO Sprint Retrospective Náplní této schuzky ˚ v metodice Scrum je shrnutí právˇe dokonˇceného sprintu a vyˇrešení pˇrípadných nedostatku. ˚ Pokud se nˇeco nepodaˇrilo podle plánu, je tˇreba analyzovat pˇríˇciny, aby mohly být napˇríštˇe odstranˇeny. Klasickým problémem muže ˚ být nedodržení plánu sprintu s tím, že se nˇekteré úkoly nepodaˇrilo dokonˇcit. Je duležité ˚ se zamyslet nad tím, proˇc byly problematické zrovna tyto úkoly a pˇrípadnˇe takový stav zaˇcít rˇ ešit. Problémem mohlo klidnˇe být pˇridˇelení více úkolu˚ do sprintu, než bylo možno zvládnout. Vyˇrešit takovou situaci je snadné – zamˇerˇ it se lépe na rozdˇelování úkolu˚ do sprintu, ˚ pˇrípadnˇe pˇrehodnotit cˇ asové odhady. Nˇekdy však problémy ve specifické oblasti mohou ukazovat napˇríklad na nedostateˇcnou architekturu cˇ i nevhodnost použitých rˇ ešení. Každopádnˇe je mnohem prospˇešnˇejší odhalit pˇríˇcinu budoucího rizika co nejdˇríve. Už jen vˇedomí o jeho existenci je mnohem lepší, než kdyby se objevilo v pozdˇejší fázi, kde by následky mohly být kritické. Bohužel u samostatného vývojáˇre neexistují tlaky k takové cˇ innosti ze strany týmu a zejména ScrumMastera. Je také zbyteˇcné si za tímto úˇcelem vyhrazovat nˇejaký cˇ as na pˇremýšlení, co se bˇehem sprintu odehrálo. Vývojáˇr sám nejlíp ví, co šlo špatnˇe a proˇc. Pˇresto ponechávám tento bod jako souˇcást metodiky zejména jako pˇripomínku, že jisté zhodnocení uplynulého sprintu je na místˇe.
4.2.4
Shrnutí
Z výše naˇcrtnutého postupu práce je vidˇet, že nebylo nutné metodiku Scrum až tak moc pˇrizpusobovat ˚ a ohýbat. V podstatˇe zustaly ˚ zachovány všechny typy schuzek ˚ a artefakty jsou vytváˇreny témˇerˇ stejnˇe, jako by na projektu pracoval tým lidí. Zhuštˇení rolí také není žádný problém. Jako klíˇcovou vidím pozici zákazníka cˇ i zadavatele. Tato osoba by mˇela být vstˇrícná a na projektu angažovaná, což vˇetšinou bývá. V akademickém prostˇredí se muže ˚ jednat napˇríklad o školitele, který sám nemusí být zadavatelem práce, ale v podstatˇe reprezentuje jeho zájmy. V takovém pˇrípadˇe je pak jeho role stejná, jako v klasickém Scrumu. Podle mého názoru je Scrum vhodným rámcem, který udržuje vývoj konzistentní a vnáší do nˇej urˇcitá pravidla. Jde o klasický iterativní pˇrístup, který je díky nˇekolika málo jednoduchým zásadám snadné dodržet. Už jen použití Scrumu vyˇreší nebo alesponˇ otupí nˇekteré problémy, se kterými se musí vývojáˇr pˇri své práci potýkat. Pole pusobnosti ˚ Scrumu je rozvržení a organizaci práce. Obtíže, které vyvstávají pˇri vývoji samotném bˇehem jednotlivých sprintu˚ pomáhá rˇ ešit sbírka pravidel, doporuˇcení a dobrých návyku, ˚ cˇ ásteˇcnˇe pˇrevzatá z metodiky Extrémní programování.
4.3
Extrémní programování pro jednoho
V pˇrípadˇe této podkapitoly je její název trochu podobný titulku v bulvárním deníku. Nebudu zde rozebírat použití extrémního programování pro vývoj jednotlivcem, ale uvedu doporuˇcení, která mi pˇripadají vhodná. Vˇetšina z tˇechto zásad je však zahrnuta v metodice XP. Ta mi se jako samostatná metoda nejeví pro jednotlivce pˇríliš vhodná. Argumenty 30
4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO pro toto tvrzení jsou uvedeny v sekci vˇenované právˇe XP výše. Extrémní programování se ˇ ovšem vcelku podrobnˇe zamˇerˇ uje na jednotlivé denní cˇ innosti vývojáˇre. Reší celou rˇ adu problému, ˚ jimž musí vývojáˇr cˇ elit a vˇetšina takových postupu˚ je použitelná i mimo ucelený rámec XP. •
Jedním z nejvˇetších bolestí samostatného vývojáˇre je právˇe jeho samota a z ní vyplývající problémy. Ty jsou zevrubnˇe popsány v úvodu této kapitoly. XP mnoho z nich rˇ eší zavedením párového programování. Nˇeco takového samozˇrejmˇe nepˇripadá pˇri samostatné práci v úvahu, nicménˇe stojí za to se nad tím pozastavit a zamyslet. Párové programování je do extrému dovedený princip sdílení kódu a znalostí. Mimo stírání rozdílu˚ mezi vývojáˇri, úrovní jejich znalostí obecnˇe a povˇedomím o systému, je jeho vedlejším efektem vˇetší ohleduplnost. Jak architektura tak kód samotný je mnohem lepší a prostší ústupku˚ a ruzných ˚ nepˇrehledných míst. Je to dáno právˇe spoluprací od samého poˇcátku, kdy už nezáleží jen na dobré vuli ˚ každého vývoˇ jáˇre psát pˇrehledný a dobˇre strukturovaný kód. Clovˇek se pak více snaží o pˇrehlednost a srozumitelnost už díky tomu, že je jeho kód cˇ ten a revidován už pˇri samotném psaní. Samozˇrejmˇe není možné takového výsledku dosáhnout o samotˇe. Je však možné mít stále na pamˇeti, že vytváˇrený kód bude nˇekdo pozdˇeji cˇ íst a bude se jej snažit pochopit. Pokud víme, že nepíšeme jen pro sebe „do šuplíku“, ale že náš kód nˇekdo pozdˇeji uvidí, snažíme se vytáhnout a naprogramovat danou vˇec co nejlépe a co nejpˇrehlednˇeji umíme. Dobrým postupem je tedy psát jakoby „pro druhého programátora“. Mužeme ˚ jít klidnˇe o nˇekoho, koho známe. Pˇri samotné práci máme na mysli, že mu výsledný kód ukážeme a píšeme a strukturujeme jej tak, aby jej pochopil. Toto není nic snadného, nicménˇe se pomocí této techniky dá udržet stabilní kvalita kódu a nepodlehnout pokušení obˇetovat pˇrehlednost a cˇ itelnost. Je velmi pravdˇepodobné, že se ke své práci nˇekdy v budoucnu sami vrátíme a je témˇerˇ jisté, že si detaily pamatovat nebudeme. Proto i nám samotným pomuže ˚ pˇrehledný a strukturovaný kód i komentáˇre v nˇem. Internetem koluje vtipné rˇcení, které je pˇrisuzováno Martinu Goldingovi a ilustruje tento pˇrístup: „Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.“ [3]. Volnˇe pˇreloženo znamená nˇeco jako: „Vždy pište kód tak, jako by cˇ lovˇek, který jej bude jednou upravovat, byl násilnický psychopat, který zná vaši adresu.“
•
V duchu XP je také vhodné snažit se udržet návrh co nejjednodušší. Takový pˇrístup je znám pod zkratkami YAGNI „You ain’t gonna need it (nebudeš to potˇrebovat)“ a KISS „Keep it simple, Stupid (udržuj to jednoduché, hlupáku)“. Tyto dva pojmy jsou podle mého názoru obecnˇe dostateˇcnˇe známy a obzvlášt’ samostaný vývojáˇr je musí mít stále na mysli. Nepˇridávat žádné funkce navíc a implementovat jen to nejnutnˇejší je v pˇrípadˇe jednotlivce kritické, zejména z duvod ˚ u˚ jeho omezených možností. Iterativní vývoj a rozdˇelení požadavku˚ na jednotlivé úkoly jsou vhodnými nástroji, jak toho dosáhnout. Nicménˇe je zapotˇrebí i pevné vule ˚ a oba zmínˇené principy si neustále pˇripomínat. 31
4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO •
Problém složitosti architektury rˇ eší i testování (krom jiného). I když je vývojáˇr na návrh sám, muže ˚ mu v tom psaní jednotkových testu˚ pomoci. Neˇríkám, že je nutné vyvíjet pˇrímo metodou Test Driven Development (vývoj rˇ ízený testy), ale není od vˇeci pˇred psaním samotného kódu vytvoˇrit nˇekolik testu. ˚ Psaním testu˚ si ujasním, co má vytváˇrená komponenta umˇet a je velká šance, že tak omezíme pˇridávání nechtˇené funkcionality. Pokud má být daná komponenta testovatelná, je nutné ji navrhnout tak, aby byla co nejménˇe závislá na okolí a pˇrípadné závislosti jí mohly být zpˇrístupnˇeny z venˇcí. Testování pomáhá udržet návrh pˇrehlednˇejší i tím, že komponenty, které dˇelají pˇríliš mnoho vˇecí, jsou mnohem huˇ ˚ re testovatelné. Abychom napsali jednoduché a pˇritom úplné testy, je výhodné tvoˇrit jednoúˇcelové komponenty, které mají na starosti jen jeden úkol. Jednotkové testování tak muže ˚ jednotlivci pomoci pˇri návrhu a dodržování principu˚ jednoduchosti. Nejde však jen o to. Krom testování samotného, kdy jsme si jisti, že systém funguje tak, jak má, poskytuje dobrá sada testu˚ podmínky pro refaktoring.
•
Refaktoring velmi dobrým nástrojem k udržitelnosti vývoje projektu. Umožnuje ˇ zanášet zmˇeny i v pozdˇejších fázích vývoje a to i zmˇeny zásadního architektonického rázu. Nejde však o jednoduchý ani samospásný postup. Chybnˇe provedený refaktoring muže ˚ vrátit vývoj klidnˇe i o celé týdny zpˇet [4]. Musí být provádˇen v postupných krocích a upravovaný systém musí být pokryt testy. Proto je snazší než jednou za cˇ as kompletnˇe zmˇenit architekturu celého systému provádˇet menší zmˇeny postupnˇe. Díky existenci jednotkových testu˚ je možné refaktorovat jak pˇri zmˇenˇe exisˇ tujícího kódu, tak pˇri implementaci nových vlastností. Castý refaktoring pomuže ˚ udržet tempo vývoje i pˇri zmˇenách na stejné úrovni.
•
Další cˇ ástí XP, kterou je vhodné využít, je prubˇ ˚ ežná integrace (Continuous integration). Nový kód by mˇel být zaˇclenˇen co nejdˇríve do stávající struktury. Je tak možné odhalit chyby blízko místa jejich vzniku a okamžitˇe zaˇcít pracovat na jejich odstranˇení. Je velmi frustrující na konci sprintu zjistit, že systém jako celek nefunguje. V duchu XP by na konci každého dne mˇel být stabilní, funkˇcní software. Tento pˇrístup opˇet pomuže ˚ udržet stabilní tempo vývoje a omezí vývoj nadbyteˇcných a pˇredem nenaplánovaných funkcionalit.
•
Aby si samostaný vývojáˇr udržel produktivitu, je nezbytné, aby neplýtval prostˇredky a netˇríštil své úsilí prací, kterou vykonávat nemusí. Mám na mysli další notoricky známý princip „nevynalézat kolo“. Jednotlivec má cˇ asto nutkání všechny cˇ ásti budovaného software udˇelat sám. To však témˇerˇ vždy není nutné a je naopak vhodné ˇ využít již hotových rˇ ešení. Castým argumentem bývá, že práce s vlastními komponentami je rychlejší, protože jsou napsány pˇresnˇe na míru. Tomu se dá namítat, že je témˇerˇ vždy rychlejší investovat cˇ as do pochopení hotových rˇ ešení, jelikož v nich již bylo odhaleno množství chyb a jejich funkˇcnost bývá provˇerˇ ena. Samostatný vývojáˇr nemá prostˇredku˚ nazbyt a je pro nˇej výhodnˇejší napˇríklad využít dostupný framework, než si psát vlastní. Jelikož bude stále znovu rˇ ešit problémy, které již byly 32
˚ 4.4. POUŽITÍ VHODNÝCH NÁSTROJ U vyˇrešeny nˇekým jiným a tˇežko bude tyto práce vysvˇetlovat zadavateli. Naopak je vˇetšinou výhodnˇejší postavit základ na hotových rˇ ešeních, což umožní soustˇredit se na implementaci požadovaných vlastností. Samozˇrejmˇe ne vždy je takové vhodné rˇ ešení k dispozici. Jedním z omezujících faktoru˚ muže ˚ být také licenˇcní politika, což ovšem zˇrídka kdy bývá pˇrípad akademického prostˇredí. •
4.4
Jak již bylo naznaˇceno výše, chybˇející kontakt se zadavatelem muže ˚ být nepˇríjemným problémem. Proto je nutné mít na zákazníka kontakt a moci s ním v pˇrípadˇe potˇreby konzultovat nejasnosti. Taková konzultace ovšem neprobíhá okamžitˇe a vˇetšinou nˇejaký cˇ as trvá, než zadavatel odpoví. Proto je duležité ˚ snažit se otázky a pˇrípadné formulovat tak, aby se na nˇe dalo pˇrímo odpovˇedˇet. Napˇr. snažit se minimalizovat e-mailovou konverzaci na minimum psaním jasných a srozumitelných dopisu. ˚ Samostatnˇe pracující vývojáˇr však musí pˇresto poˇcítat se zdržením. Proto by se mˇel snažit rozvrhnout si práci tak, aby nebyl na odpovˇedi od zákazníka závislý. Mám na mysli už pˇri plánování sprintu dbát na to, že by úkoly nemˇely záviset bezprostˇrednˇe jeden na druhém, ale aby je bylo možné paralelizovat. Stejnˇe, jako by si je rozdˇelovali cˇ lenové týmu. Tak se muže ˚ vyhout situaci, kdy cˇ eká na vyjádˇrení a nemuže ˚ vubec ˚ pokraˇcovat v práci.
Použití vhodných nástroju˚
Tato podkapitola je vyˇclenˇena zvlášt’, nebot’ její obsah pˇrímo nesouvisí s agilními technikami. Uvedu zde nástroje, které samostatnému vývojáˇri usnadní práci a opˇet mu pomohou vyhnout se dalším nástrahám, které na nˇej cˇ íhají.
Organizace cˇ asu Organizace cˇ asu je obecnˇe velkým problémem a cˇ astým tématem. U jednotlivce to platí obzvlášt’, jelikož si všechnu práci musí urˇcit sám a nikdo na nˇej nedohlíží. Pozitivem však je, že odpadají vyrušení a náhlé úkoly, které odvádˇejí pozornost od vývoje. Nemám ambice v této práci rozebírat hospodaˇrení s cˇ asem a techniky, jak toho nejlépe dosáhnout jelikož se jedná o velmi širokou oblast. Nicménˇe z hlediska vývoje software se mi osvˇedˇcila technika zvaná Pomodoro 1 . Jde o jednoduchý princip, kdy po každých 25 minutách následuje krátká pˇrestávka a po cˇ tyˇrech takových blocích pˇrestávka delší. Tato technika pomáhá udržet pozornost a zárovenˇ dodržování duležitých ˚ pˇrestávek. Formátování kódu Jak bylo uvedeno v pˇredchozí podkapitole, velkým problémem bývá nedostateˇcná kvalita kódu. I když jde o rˇ ešení zavedené z duvod ˚ u˚ týmové spolupráce, pˇresto mi pˇripadá vhodné i pro samostatného vývojáˇre. Mám na mysli tzv. 1.
http://www.pomodorotechnique.com
33
˚ 4.4. POUŽITÍ VHODNÝCH NÁSTROJ U „štábní kulturu“, cˇ ili pravidla pro psaní a formátování kódu. Podle mé zkušenosti je velmi vhodné si stanovit a dodržovat pravidla pro formátování kódu vždy. Není nutné je rigidnˇe dodržovat, nicménˇe je vhodné od nich pˇríliš neodboˇcovat. Jak již bylo zmínˇeno, pˇrehledný a strukturovaný kód je duležitý ˚ i v pˇrípadˇe, že jej nikdo jiný neuvidí. Až bude tˇreba systém opravit nebo rozšíˇrit, tak se dodržování pravidel pro formátování kódu bohatˇe vrátí. S tím souvisí i psaní vhodných komentáˇru. ˚ Svudná ˚ myšlenka, že kód je pˇrece srozumitelný na první pohled, je cˇ asto mylná. Pˇri pozdˇejším návratu ke kódu už muže ˚ vývojáˇr zapomenout všechny souvislosti a bude tak pracnˇe luštit svoji vlastní práci. Není nutné dodržovat nˇejaké formální komentáˇre, napˇr. u každého konstruktoru psát, že jde o konstruktor, nicménˇe tˇreba výjimky je dobré zmínit. Komentovat svuj ˚ vlastní kód pro sebe se v dlouhodobém horizontu jednoznaˇcnˇe vyplatí. Systém pro správu verzí Dalším duležitým ˚ nástrojem, který se tak na první pohled nemusí jevit, je verzovací systém. Jedním z jeho pˇrínosu˚ je to, že dodává vývojáˇri jistoty. Napˇríklad pˇri refaktoringu je v pˇrípadˇe neúspˇechu možné kód obnovit z historie. I pˇri zkoušení nového postupu není nutné si nˇejak zvlášt’ zálohovat kód, ale je možné pˇrípadné zmˇeny opˇet vrátit zpˇet. Navíc odpadají nepˇríjemnosti spojené s vývojem ve více lidech, jako napˇr. rˇ ešení konfliktu˚ v souborech, a tak je práce s verzovacím systémem snadná. Osobnˇe se mi osvˇedˇcilo použití decentralizovaného verzovacího nástroje GIT 2 . Ten je snadné provozovat pouze lokálnˇe, jelikož ze své podstaty nevyžaduje žádné centrální úložištˇe. Navíc jeho možnosti vˇetvení kódu jsou ideální pro zkoušení nových nápadu˚ a pˇrístupu. ˚ Automatický deployment Navržená metodika je iterativní a je doporuˇceno také cˇ asté zacˇ lenování ˇ nových komponent do stávajícího systému, tzv. „build“. Z poˇcátku tato práce muže ˚ být snadná a rychlá, ale postupem cˇ asu nabírá na složitosti. Navíc jde o mechanickou a nudnou cˇ innost, které má cˇ lovˇek tendenci se vyhýbat. Proto je nejlepší použít pro tento úˇcel nˇejaký vhodný nástroj, který ji automatizuje. Vyplatí se takový nástroj nasadit ihned ze zaˇcátku, protože cˇ ím dˇríve je používán, tím více cˇ asu ušetˇrí. Ideálnˇe by mˇel být deployment záležitostí zadání jednoho pˇríkazu cˇ i jednoho kliknutí myši. Pokud je systém vyvíjen jednotlivcem, není nutné vytváˇret plnˇe automatické rˇ ešení reagující napˇr. na zmˇeny ve verzovacím systému. Typickými zástupci takových nástroju˚ jsou Ant3 nebo Maven4 . Systém pro správu projektu˚ Bˇehem práce cˇ lovˇek velmi cˇ asto narazí na nové problémy cˇ i jej napadne, co by se dalo vylepšit nebo zmˇenit. Nabízí se dvˇe možnosti – vyˇrešit 2. 3. 4.
http://git-scm.com http://ant.apache.org http://maven.apache.org
34
4.5. SHRNUTÍ problém okamžitˇe nebo si jej nˇekam poznamenat. Okamžitá práce na takovýchto nových úkolech není vˇetšinou pˇríliš vhodná, protože je vývojáˇr sveden z hlavní cesty a nesoustˇredí se pak na puvodní ˚ cíl. Dˇelat si poznámky a vrátit se k nim pozdˇeji je podle mého názoru pro jednotlivce mnohem úˇcelnˇejší. Takový pˇrístup svádí k tomu, aby byla poznámka napsána pˇrímo do kódu, což bývají komentáˇre uvozené známými znaˇckami „TODO“, „FIXME“ apod. Toto je ovšem velmi nešt’astný zpu˚ sob. Málo kdy je kód zpˇetnˇe procházen za úˇcelem nalezení a odstranˇení takových míst. Nˇekteré robustnˇejší programovací nástroje umí takové komentáˇre vyhledávat a zobrazovat v pˇrehledu. Potom ale zdrojový kód plní i funkci poznámkového bloku, což rozhodnˇe nebyl jeho puvodní ˚ úˇcel. Navíc takové praktiky k pˇrehlednosti kódu nepˇrispívají. Rychlý komentáˇr má navíc tendenci být málo popisný a tedy v budoucnu nesrozumitelný. Proto je dobré tyto poznámky shromažd’ovat na jednom místˇe, mimo zdrojový kód. Jako nejvhodnˇejší se mi za tímto úˇcelem jeví použití nˇejakého „bug tracking“ systému, jako napˇr. Trac5 nebo podle mˇe velmi dobrý Redmine6 . Takový sytém umožní jednoduše a dostateˇcnˇe strukturovanˇe shromažd’ovat takové poznámky a nápady, které by mˇely být provˇerˇ eny cˇ i nemˇely zapadnout. Rozhodnˇe doporuˇcuji mít jediné místo, kde jsou shromažd’ovány informace o projektu. Do takového systému je dobré si zapisovat i poznámky, které nemají povahu nˇejaˇ kého konkrétního úkolu. Casto se stává, že vývojáˇr rˇ eší jeden problém po nˇekolikáté a nemuže ˚ si vzpomenout, jak na to. Není proto od vˇeci si tvoˇrit takovou znalostní bázi týkající se aktuálního projektu, ale klidnˇe i bez návaznosti na nˇej. Z osobního pohledu považuji za výhodné mít všechny informace pohromadˇe. Proto mi pˇripadá vhodné použít zmínˇený systém i pro podporu metodiky Scrum. Napˇríklad nástroj Redmine je k tomuto úˇcelu po instalaci rozšíˇrení možné použít. Agilní pˇrístup však hlásá, že nejsou duležité ˚ nástroje, ale postupy. Je proto na každém vývojáˇri, jakých podpurných ˚ prostˇredku˚ využije. Proto by samostatný vývojáˇr nemˇel trávit zbyteˇcnˇe mnoho cˇ asu formálním zapisováním požadavku, ˚ když to v jeho pˇrípadˇe není nutné. Napˇríklad pro artefakty metodiky Scrum je možné velmi dobˇre použít i obyˇcejný tabulkový editor. Není problém si Burn Down Chart kreslit tužkou na papír. Použití vhodných nástroju˚ muže ˚ dost významnˇe samostatnému vývojáˇri pomoci pˇri jeho práci. Je ovšem tˇreba jejich nasazení vybalancovat tak, aby byly pˇrínosem a ne zbyteˇcnou zátˇeží, které se bude cˇ lovˇek nakonec vyhýbat.
4.5
Shrnutí
V této kapitole byly nastínˇeny problémy, se kterými je potˇreba pˇri samostatném vývoji pocˇ ítat. Jako optimální rˇ ešení se mi jeví použít upravené cˇ ásti metodiky metodiky Scrum ke konstrukci procesního rámce, který pak urˇcuje procesy vývoje. To umožní soustˇredit se na 5. 6.
http://trac.edgewall.org/ http://www.redmine.org/
35
4.5. SHRNUTÍ podstatné úkoly a zorganizovat si práci. To však není dostaˇcující rˇ ešení, jelikož neˇreší množství dalších každodenních problému, ˚ které samostatný vývoj pˇrináší. Proto je vhodné metodiku doplnit o další postupy, pˇriˇcemž inspirativním zdrojem je Extrémní programování. Záleží na každém, jaké vývojové postupy si osvojí. Jako nezbytný základ však považuji klást duraz ˚ na testování a jednoduchou architekturu. Je možné si tak udržet stabilní tempo vývoje. Další rˇ adu každodenních úskalí je možné rˇ ešit použitím vhodných nástroju. ˚ Ne se všemi problémy je ale možné se vypoˇrádat pomocí technik a nástroju. ˚ Je nutné si vypˇestovat dobré návyky a snažit se je dodržovat. Jako základ bych vidˇel pˇrístup nepsat kód pro jen sebe, ale i pro ostatní. Takováto strategie muže ˚ vést k úspˇešnému a udržitelnému vývoji projektu samostatným vývojáˇrem.
36
Kapitola 5
Pˇrípadová studie užití metodiky Obsahem této kapitoly bude demonstrace použití formulované metodiky pro vývoj webového informaˇcního systému. Pˇrestože se jedná spíše o projekt menšího rozsahu, není zde prostor demonstrovat celý jeho prubˇ ˚ eh. Na první iteraci budou pˇredvedeny postupy, které byly používány bˇehem celého procesu vývoje. Takový rozsah je dostaˇcující na zevrubnou ukázku nasazení metodiky v praxi.
5.1
Zadání
Náplní projektu je vytvoˇrit webový informaˇcní systém pro zadávání a správu internetových reklamních kampaní. Systém má rˇ ešit celý životní cyklus reklamní kampanˇe od poptávky až po realizovanou zakázku. Internetová kampanˇ nabývá jednoho ze stavu˚ kalkulace, nabídka, objednávka, realizace nebo uzavˇreno. Kampanˇ je tvoˇrena jednou nebo více inzertními položkami. Položka pak obsahuje termín zobrazení, umístˇení (stránka a pozice na stránce) a vlastní reklamní obsah (oznaˇcováno jako „kreativum“). V závislosti na stavu kampanˇe jsou jednotlivé atributy položky povinné nebo volitelné. Kreativa mohou být ruzných ˚ typu˚ a každý typ definuje konkrétní atributy (napˇr. obrázek, text, zástupný obrázek apod.). Úˇcelem systému je umožnit vytváˇret a spravovat takto definované internetové kampanˇe týmem obchodních zástupcu˚ a zejména nastavit pro obchodníky jasnˇe definovaná pravidla: •
rezervace pozic
•
slevy a bonusy k objednávkám
•
omezit rozsah zmˇen v kampani v jednotlivých fázích
•
provize z prodeje inzerce
Dále by mˇel systém vizualizovat aktuální obsazení inzertních ploch s jejich stavem (obsazeno, rezervováno, volno) a umožnit správu souvisejících databází (zákazníci, archiv kreativ). Systém by mˇel plnit zejména manažerské potˇreby, vlastní výkonná cˇ innost (vystavení faktury, zveˇrejnˇení a stažení inzerce, kontrola úhrad, zpracování statistiky kampanˇe) bude realizována tzv. „workery“, které bude možné implementovat postupnˇe bˇehem používání 37
ˇ 5.2. POUŽITÁ REŠENÍ systému (zpoˇcátku postaˇcí základní implementace v podobˇe emailu odpovˇedné osobˇe). Tˇemito workery bude zajištˇena i spolupráce s externími systémy – úˇcetnictvím WinDUO1 a reklamním systémem OpenX2 .
5.2
Použitá rˇešení
Systém mˇel být zasazen do existující infrastruktury, cˇ emuž bylo potˇreba se pˇrizpusobit. ˚ Nutné požadavky byly použití skriptovacího jazyka PHP3 a databázového serveru MySQL4 . Na základˇe tˇechto požadavku˚ jsem se rozhodl pro vývoj systému použít následující nástroje:
Zend Framework5 Jedná se o robustní open source (s otevˇreným zdrojovým kódem) framework, jehož vývoj je zaštítˇen spoleˇcností Zend Technologies Ltd. Tato firma se podílí na vývoji jádra samotného PHP a je garantem budoucího vývoje tohoto frameworku. Zend Framework (dále jen ZF) je postaven na základˇe principu MVC (Model, View, Controller, v Javˇe též oznaˇcován jako Model 2). Ten slouží k oddˇelení aplikaˇcní a prezentaˇcní logiky, jejichž propojení je zejména v PHP cˇ astým jevem. Funguje ve zkratce tak, že požadavek uživatele je pˇredán kontroleru a ten jej pˇretransformuje na vstupy pro modely. Modely provedou na základˇe vstupu˚ požadované výpoˇcty a výsledek pˇredají zpˇet kontroleru. Ten tyto výstupy pˇredá do vrstvy view, která je zobrazí uživateli. Výhodou tohoto frameworku je jeho modulární architektura. ZF je tvoˇren množstvím volnˇe provázaných komponent, které je možné nahradit rˇ ešením tˇretích stran cˇ i je naopak vyjmout a použít samostatnˇe. Tohoto rysu je bˇehem vývoje s úspˇechem využito. Doctrine 26 Vzhledem k tomu, že systém mˇel používat relaˇcní databázi a využívat objektovˇe orientovaného pˇrístupu, bylo nutné nˇejakým zpusobem ˚ rˇ ešit ukládání dat. Zend Framework v tomto smˇeru poskytuje rˇ ešení založené na principu „Table data gateway“ nebo „Row data gateway“. Ani jeden z tˇechto pˇrístupu˚ mi není moc blízký a u dlouhodobˇejších projektu˚ jejich výhradní nasazení vede k problémum. ˚ Mnohem univerzálnˇejší a „ˇcistˇejší“ je nejen podle mého názoru pˇrístup oznaˇcovaný jako „Data mapper“. Zjednodušenˇe jde o prostˇredníka mezi objekty v pamˇeti a databází [7]. Padlo tedy rozhodnutí, že bude potˇreba použít nˇejakého ORM (objektovˇe-relaˇcní mapování) založeného právˇe na tomto vzoru. 1. 2. 3. 4.
http://www.winduo.cz http://www.openx.org http://php.net http://www.mysql.com/
38
ˇ 5.2. POUŽITÁ REŠENÍ Ve svˇetˇe PHP není kvalitních rˇ ešení takového druhu mnoho. V dobˇe plánování byl tˇesnˇe pˇred dokonˇcením nový projekt Doctrine 2, který mˇel být nástupcem již delší dobu používaného ORM Doctrine. Doctrine 2 je objektovˇe-relaˇcní mapování, které je silnˇe ovlivnˇeno ORM nástrojem Hibernate7 z prostˇredí platformy Java a implementací vzoru Active record z frameworku Ruby on Rails8 . Výhodou Doctrine 2 je, že mapované tˇrídy nemusí být vydˇedˇeny z nˇejaké základní rodiˇcovské tˇrídy, jak je tomu u ostatních podobných rˇ ešení. Po správném nakonfigurování mapování je používáni tohoto nástroje vcelku jednoduché a intuitivní. Rozhodnˇe se jedná o urychlení vývoje, i když jistá uˇcící fáze je na poˇcátku pochopitelnˇe pˇrítomna. Projekt Doctrine 2 v dobˇe plánování informaˇcního systému ještˇe nebyl v produkˇcní verzi k dispozici. Pˇresto bylo plánováno uvedení první produkˇcní verze v rˇ ádu mˇesícu˚ a tak jsem se rozhodl podstoupit jisté riziko a Doctrine 2 do informaˇcního systému zaˇclenit. Symfony Dependency Injection9 V objektovˇe orientovaném svˇetˇe je potˇreba rˇ ešit vzájemnou spolupráci mezi jednotlivými objekty. Vazba mezi nimi by mˇela být co nejvolnˇejší. Toho se dosahuje aplikací principu „inversion of control (obrácení rˇ ízení)“. Jde o to, že objekt, který ke své práci potˇrebuje nˇejaké jiné objekty si je už nevytváˇrí sám, ale jsou mu nˇejakým zpusobem ˚ zprostˇredkovány. Jedním z pˇrístupu, ˚ jak toho dosáhnout je, „dependency injection (vkládání závislostí)“. Díky této technice je snadné testovat jednotlivé objekty samostatnˇe a také jejich znovupoužitelnost je výraznˇe vyšší. Pˇrípadná zámˇena jednotlivých cˇ ásti systému je také snadná. Jako pomocníka, který usnadní práci automatickým vkládáním závislostí jsem zvolil rˇ ešení použité v PHP frameworku Symfony10 . Jedná se o kontejner, ze kterého jsou dle potˇreby získávány hotové instance s již nastavenými závislostmi. Definice objektu˚ a jejich závislostí je realizována pomocí znaˇckovacího jazyka XML. Phing11 Build systém Phing je PHP derivátem Java nástroje ANT12 . Tento systém umožnuje ˇ pomocí jazyka XML definovat procesy a poté je volat pˇres pˇríkazovou rˇ ádku. Takové procesy mohou být napˇr. vygenerování dokumentace ze zdrojových kódu, ˚ spuštˇení testu, ˚ konfigurace aplikace, smazání doˇcasných souboru˚ cˇ i dokonce publikování verze na vzdálený server. Redmine13 Navržená metodika doporuˇcuje použití nˇejakého centrálního místa pro uchovávání informací o projektu. Za tímto úˇcelem jsem využil systému pro správu projektu˚ 7. 8. 10. 12.
http://www.hibernate.org http://rubyonrails.org/ http://www.symfony-project.org http://ant.apache.org
39
5.3. SPRINT Redmine. Jde opˇet o open source rˇ ešení. V tomto systému je možné pˇrehlednˇe sdružovat seznam úkolu˚ i poznámek, organizovaných podle projektu˚ nebo v globálním kontextu. Redmine je jednoduchý, uživatelsky dostateˇcnˇe pˇrívˇetivý a rychlý, takže práce s ním nezdržuje. Git14 Pro správu verzí jsem použil decentralizovaný verzovací systém Git. Jeho architektura umožnuje ˇ dˇelat malé a cˇ asté „commity“ (uložení provedených zmˇen), které je možné pozdˇeji spojit v jeden velký a ten publikovat. Šikovnou vlastností je také jeho vˇetvení. Hlavní vývojová vˇetev obsahovala aktuální kód a pokud jsem zaˇcal pracovat na nˇejakém novém úkolu, vytvoˇril jsem si z ní vˇetev novou. Tam provedl potˇrebné zmˇeny a zase obˇe vˇetve spojil v jednu. Takový pˇrístup není pˇri vývoji jedním vývojáˇrem nutný, zejména u budování nového systému ne. Ale umožnuje ˇ rychle se vrátit do puvodního ˚ stavu, pokud vývojáˇr zabloudí do slepé uliˇcky. Dále umožnuje ˇ napˇr. pˇri výskytu chyby tuto chybu opravit v samostatné vˇetvi a publikovat jako jeden celek. Git je díky svému lokálnímu charakteru také velmi rychlý a rozhodnˇe nebyl bˇehem práce žádným zdržením. Verzovací systém Git jsem používal také pˇri psaní textu práce, zejména jako zálohovací rˇ ešení.
5.3
Sprint
Na zaˇcátku práce byl na základˇe požadavku˚ popsaných výše a skic jednotlivých obrazovek budoucího systému vytvoˇrena první verze Product Backlogu. Product Owner byl cˇ lovˇek velmi technicky zdatný, což se projevilo také na sestavování Backlogu. Jednotlivé položky tedy nebyly jen funkˇcní požadavky, ale také nutné práce technického charakteru potˇrebné pro vytvoˇrení kostry systému. Jako nejjednodušší mi pˇripadalo vést Product Backlog jako sešit v tabulkovém editoru OpenOffice.org Calc15 (dále OO Calc). Pokud byl nˇejaký úkol dokonˇcen, bylo oznaˇcen zelenou barvou. Položky Product Backlogu jsou definovány takto: Název Krátký výstižný název. Maximálnˇe nˇekolik slov. Priorita Pˇrirozené cˇ íslo, cˇ ím vyšší, tím vyšší priorita. Horní mez není nijak omezena a základní ohodnocení se provádˇelo po desítkách, aby bylo možné pozdˇeji v pˇrípadˇe potˇreby prioritu dostateˇcnˇe zjemnit. Odhad Odhad doby práce, která je potˇreba pro implementaci požadavku. Uvádˇeno v celých hodinách s tím, že den práce se rovná osmi hodinám. 15. http://www.openoffice.org/product/calc.html
40
5.3. SPRINT
Popis Delší popis úkolu, pˇrípadnˇe místo pro doplnˇení poznámek.
Obrázek 5.1: Product Backlog Nejprve byl sestaven seznam požadavku˚ na aplikaci. Poté byly jednotlivé požadavky ohodnoceny podle priority a seˇrazeny. Tak vznikl první odhad prubˇ ˚ ehu vývoje. Dále byl každý bod ohodnocen cˇ asovým odhadem nároˇcnosti. V této první fázi bylo velmi tˇežké urˇcit pˇresnˇejší odhad, jelikož na zaˇcátku se jednalo o vytvoˇrení kostry systému. I když byl použit framework, který poskytoval MVC rámec, stále bylo potˇreba do nˇej zakomponovat ostatní knihovny, jako Doctrine 2 a Symfony Dependency Injection kontejner. Podrobnˇejší cˇ asové odhady v dalších fázích byly možné až po sestavení tohoto základu a tak byly stanoveny pouze vágnˇe. 5.3.1
Sprint Backlog
Bˇehem prvního sprintu mˇela být provedena analýza a sestavení diagramu tˇríd. Dále mˇela být vytvoˇrena kostra systému spoleˇcnˇe se základní infrastrukturou. Poté implementovány jednoduché tˇrídy, tzv. cˇ íselníky už s tím, že bude využita databáze. První sprint byl výjimeˇcný a proto jeho délka byla stanovena na cˇ tyˇri týdny, což je 160 hodin práce. Takto 41
5.3. SPRINT byl tedy sestaven první Sprint Backlog. V nˇem jsou jednotlivé položky dekomponovány na menší úkoly a ty rozepsány zvlášt’. Délka sprintu by nemˇela pˇresáhnout dva týdny, díky problematické zpˇetné vazbˇe, kterou vývojáˇr na Product Ownera má. Sprint Backlog byl veden pro mˇe co nejpohodlnˇejším zpusobem. ˚ Nepotˇreboval jsem nˇejaký pˇresný záznam prubˇ ˚ ehu práce, ale chtˇel jsem evidovat, kolik mi který úkol ve skuteˇcnosti zabral cˇ asu. Zárovenˇ bylo nutné poˇcítat s nepˇresným odhadem a mít tak možnost si u každého úkolu poznamenat, kolik cˇ asu zbývá ještˇe do jeho dokonˇcení. Sprint Backlog byl udržován stejnˇe jako Product Backlog jako sešit v tabulkovém editoru OO Calc. Pˇri dokoncˇ ení práce na úkolu nebo na konci dne jsem si poznamenal poˇcet hodin strávených prací. Pokud byl úkol dokonˇcen, do zbývajícího cˇ asu jsem napsal nulu a rˇ ádek oznaˇcil pro lepší vizualizaci zelenou barvou. Pokud úkol na konci dne dokonˇcen nebyl, dopsal jsem odhad, kolik cˇ asu asi ještˇe práce na nˇem zabere. Tento údaj o tom, kolik odhadovaných hodin práce se za den skuteˇcnˇe podaˇrilo dokonˇcit, byl vynesen do Burn down grafu.
Obrázek 5.2: První rozpracovaný sprint Backlog
42
5.3. SPRINT 5.3.2
Burn Down Chart
Tento graf má sloužit jako ukazatel prubˇ ˚ ehu vývoje v daném sprintu. Nejdˇríve jsem jej chtˇel vést v sešitu OO Calc, kde by se automaticky aktualizoval, ale ukázalo se, že to vyžaduje pˇríliš mnoho úsilí a ústupkum ˚ jednoduchosti. Automatizace by si vyžádala vyšší náklady na vytvoˇrení sešitu a to se mi nechtˇelo pˇred každým sprintem rˇ ešit. Navíc jsem takovou míru pˇresnosti ani nepotˇreboval. Nakonec se mi osvˇedˇcilo použití obyˇcejné tužky a cˇ tvereˇckovaného papíru. Od ruky jsem tak nakreslil graf, který mˇel na ose X poˇcet dnu˚ které mˇel sprint trvat. Osa Y pˇredstavovala odhadovaný zbývající poˇcet hodin. Každý den jsem odhadl, kolik plánovaných hodin práce bylo dokonˇceno a tento údaj zanesl na graf. Takovýto ruˇcnˇe kreslený graf mi poskytoval dostateˇcný pˇrehled o prubˇ ˚ ehu sprintu.
5.3.3
Sprint Retrospective
Bˇehem sprintu vyplynuly na povrch jisté nedostatky. Napoprvé se nepodaˇrilo všechny stanovené úkoly dokonˇcit a proto byly vráceny zpˇet do Product Backlogu. Jako zásadní problém jsem urˇcil špatný cˇ asový odhad. Hodnˇe se cˇ as lišil u propojování externích komponent se Zend Frameworkem, kdy jsem narazil na neoˇcekávané chování a musel jej rˇ ešit. Dále se protáhla práce s ORM nástrojem Doctrine 2, se kterým jsem nebyl dostateˇcnˇe obeznámen. I když jsem s takovým zdržením poˇcítal, pˇresto bylo nad oˇcekávání vˇetší. Jednalo se o nové a praxí neotestované rˇ ešení, ale cˇ as strávený jeho uˇcením se mi vrátil v prubˇ ˚ ehu vývoje a bezpochyby vrátí i na jiných projektech. Druhým faktorem, který ovlivnil prubˇ ˚ eh sprintu byla prubˇ ˚ ežná integrace. Bˇehem práce se objevovaly nové úkoly, které bylo tˇreba automatizovat nástrojem Phing. Ten se nepˇredvedl v nejlepším svˇetle a mnoho z jeho pˇreddefinovaných postupu˚ bylo v tomto projektu nepoužitelných. Psát si vlastní postupy také není díky architektuˇre Phingu nejjednodušší. Bohužel jsem na vhodnˇejší nástroj napsaný v jazyce PHP nenarazil. I pˇres tyto výtky bylo jeho nasazení v koneˇcném dusledku ˚ velkou úsporou cˇ asu. I když byly tyto obtíže spíše specifikem prvotního sprintu, bˇehem kterého byla budována kostra systému, zohlednil jsem je pˇri plánování dalších sprintu. ˚ Pokud si mˇel nˇejaký další úkol vyžádat nové technické prostˇredky nebo intenzivnˇeji využívat již existující, ponechal jsem si vždy dostateˇcnou cˇ asovou rezervu. Bˇehem práce také vyvstalo spoustu otázek a nejasností. Všechny jsem je poznamenával do systému Redmine a pozdˇeji je probral s Product Ownerem. Pokud jsem narazil na nˇejaký problém, který se pˇrímo netýkal práce na aktuálním úkolu nebo mˇe napadlo nˇejaké možné vylepšení, poznamenal jsem si jej tamtéž. Pozdˇeji bylo možné tyto problémy probrat nebo vyˇrešit u úkolu, ˚ kterých se týkaly. Databáze poznámek a rˇ ešení se rozrostla také o poznatky týkající se jednotlivých komponent, zejména ORM rˇ ešení Doctrine 2, abych pˇrípadnˇe za nˇejaký cˇ as nemusel znovu hledat rˇ ešení již jednou vyˇrešených problému. ˚ 43
5.4. SHRNUTÍ 5.3.4
Sprint Review and Planning Meeting
Po dokonˇcení sprintu následovala schuzka ˚ s Product Ownerem. Pˇredstavil jsem mu funkˇcní cˇ ást sytému a referoval o prubˇ ˚ ehu sprintu. Nedokonˇcené úkoly jsme vrátili zpˇet do Product Backlogu a opˇet zhodnotili jejich nároˇcnost a prioritu. Poté jsme pˇrešli k plánování dalšího sprintu. Oficiálnˇe se tedy tato schuzka ˚ zmˇenila na Sprint Planning Meeting. Bˇehem ní se opˇet vybraly úkoly pro nadcházející sprint a stanovila jeho délka. Tentokrát už byl sprint zkrácen na dva týdny, tedy 80 hodin odhadované práce.
5.4
Shrnutí
Tato kapitola popsala budovaný informaˇcní systém a rˇ ešení k tomu použitá. Toto pˇredstavení bylo nutné k popisu sprintu, který probíhal dle navržené metodiky. Samozˇrejmˇe že se vyskytly jisté porodní potíže, zejména co se odhadu cˇ asu týˇce, ale pˇresto na nˇe metodika dokázala zareagovat a ošetˇrit je v dalších sprintech. Pˇrestože se nejednalo o rozsáhlý projekt, skýtal jistá úskalí. Na zaˇcátku byly nedostateˇcnˇe formulované požadavky. Pokud bych k práci pˇristoupil pouze na základˇe prvotního zadání, brzy by se dostavily problémy. Nebylo by dostateˇcnˇe jasné, které cˇ ásti systému mají pˇrednost, které vlastnˇe nejsou podstatné a které naopak nejsou zmínˇeny. Díky tomu by nebyla navržena optimální architektura. Testování by bez jasnˇejších požadavku˚ bylo také obtížnˇejší. Aplikací vytvoˇrené metodiky se dosáhlo na poˇcátku jasnˇe specifikovaného zadání a jeho rozdˇelení na dílˇcí úkoly. Pˇrehled jednotlivých požadavku˚ pomohl zadavateli ujasnit si zadání a zejména stanovit priority. Pokud by se po první iteraci ukázalo, že budovaný systém není životaschopný, nedošlo by k velké ztrátˇe prostˇredku. ˚ Bylo by možné pozmˇenit zadání, technické zázemí cˇ i samotnou architekturu. V tomto pˇrípadˇe toho však nebylo za potˇrebí. Pˇredvedení funkˇcní cˇ ásti systému vedlo k pˇrehodnocení nˇekterých naplánovaných úkolu. ˚ Tím se dále ujasnilo a zjemnilo zadání. Takovým postupem nebylo plýtváno prostˇredky na nechtˇenou funkcionalitu, která by se nejprve zdála vhodná, ale pozdˇeji by se ukázala jako zbyteˇcná. Každá pozdˇejší iterace pˇredstavila funkˇcní celek. Bylo tak možné reagovat na nové požadavky a pˇrípadné slepé cesty cˇ i nepoužitelná rˇ ešení. Protože vývoj probíhal v takových iteracích, bylo riziko krachu projektu významnˇe sníženo. Jelikož by systém dostateˇcnˇe otestován, bylo možné v pˇrípadˇe potˇreby provádˇet refaktoring. Díky tomu bylo možné udržet si vysoké tempo vývoje a nedˇelat kompromisní rozhodnutí co se implementace týˇce. Systém byl vždy rychle pˇrizpusoben ˚ novým potˇrebám a tak se nové cˇ ásti daˇrilo vyvíjet rychle bez nutnosti hledat obezliˇcky, jak je do stávající architektury zaˇclenit. Takto byly v dlouhodobˇejším horizontu sníženy náklady na vývoj, jelikož ten probíhal v podstatˇe stejným tempem jako na zaˇcátku. Snímky obrazovek systému jsou uvedeny v pˇríloze.
44
Kapitola 6
Závˇer V úvodu práce bylo zmínˇeno, že práce samostatného vývojáˇre je, co se prubˇ ˚ ehu týˇce, v podstatˇe shodná s prací týmu lidí. Pˇri snaze o dosažení stejných cílu˚ naráží na totožné problémy a obtíže. Nˇekteré negativní symptomy týmové práce u nˇej odpadají, naopak pˇribývají specifické problémy spojené s prací o samotˇe. Pˇrestože je metodik vývoje softwaru pomˇernˇe mnoho, žádná z nich není zamˇerˇ ena na vývoj vedený osamoceným jedincem. Nalézt takovou metodiku bylo jedním z cílu˚ této práce. Bohužel se žádnou takovou najít nepodaˇrilo a tak pˇrišel na rˇ adu pruzkum ˚ existujících metodik k tomuto úˇcelu vhodných. Jako zkoumanou oblast jsem zvolil agilní metodiky, právˇe díky jejich durazu ˚ na individualitu a neformální vztahy. Tyto vlastnosti je co do vhodnosti použití pro samostatného vývojáˇre staví pˇred tradiˇcní „tˇežké“, strukturované metodiky. Podhoubím tˇechto agilních metodik je prohlášení „Agile Manifesto“ definující zásady, které se jeho autoˇri zavázali dodržovat. V práci jsem struˇcnˇe popsal cˇ tyˇri agilní metodiky vývoje a prozkoumal jejich vhodnost pro použití samostatným jednotlivcem. Žádnou z nich však nemohu k tomuto úˇcelu doporuˇcit bez dalších úprav. Proto jsem se pokusil sestavit metodiku vlastní. Tato metodika vychází ze dvou zkoumaných, metodiky Scrum a Extrémního programování. Scrum jsem použil jako inspiraci pro procesní rámec, který urˇcuje smˇer a prubˇ ˚ eh vývoje a definuje nezbytné artefakty pro podporu tohoto procesu. V metodice Scrum totiž není hnacím motorem vývoje tlak na vývojáˇre v podobˇe managementu. Vývojovému týmu je pˇriznávána znaˇcná volnost a spoléhá se na jeho schopnost sebeorganizace. Tím, že tedy není nutné slouˇcit role vedení a vývojáˇre pod jednu, je Scrum vhodný i pro samostatný vývoj. Rozdˇelení práce na úkoly, definování jejich priorit a iteraˇcní cyklus však nejsou všeobjímajícím rˇ ešením. Pˇrestože je procesním rámcem urˇcen prubˇ ˚ eh vývoje, stále zbývá mnoho oblastí, kde samostatný vývojáˇr naráží na pˇrekážky. Bohužel je velmi tˇežké definovat nˇejaké oficiální postupy, které pomohou tyto pˇrekážky pˇrekonat. Navíc by navrhovaná metodika mˇela být dostateˇcnˇe pružná, aby byla použitelná širokým spektrem vývojáˇru˚ s ruznými ˚ požadavky a zvyklostmi. Proto dále v práci navrhuji rˇ ešení problému˚ se kterými se vývojáˇri potýkají spíše jako doporuˇcené postupy, než závaznou metodiku. Inspirací, jak ruzným ˚ úskalím vývoje vývoje cˇ elit, je Extrémní programování. To klade na každodenní práci velký vliv a absorbuje do sebe známá osvˇedˇcená rˇ ešení. Souˇcástí návrhu vlastní metodiky jsou tedy také doporuˇcení, jak se vypoˇrádat s konkrétními problémy, které samostatná práce vytváˇrí. 45
ˇ 6. Z ÁV ER
Doplnkem ˇ metodiky je také použití vhodných nástroju. ˚ V duchu agilního pˇrístupu se opˇet nejedná o seznam nutných aplikací, které je tˇreba používat, ale o vymezení oblastí jejich pu˚ sobnosti. Použití nástroju˚ usnadnujících ˇ vývoj je na každém cˇ lovˇeku, práce v tomto smˇeru pouze ukazuje, kde je jejich nasazení vhodné a proˇc. Poslední cˇ ást práce tvoˇrí pˇrípadová studie webového informaˇcního systému pro spoleˇcnost „gdi, s.r.o.“ 1 , ve které je demonstrováno použití definované metodiky. Nejsou zde zevrubnˇe popisovány všechny požadavky na systém ani není uveden detailní rozbor použitých technologických rˇ ešení. Budovaný systém a jeho konstrukˇcní prvky jsou popsány natolik podrobnˇe, aby to staˇcilo k demonstraci techniky vývoje. Bˇehem vývoje samotného se ukázalo, že je možné tuto metodiku s úspˇechem použít. Postupy vymezené metodikou vedly ke znaˇcnému snížení rizika neúspˇechu díky cˇ astému zveˇrejnování ˇ funkˇcních verzí. Nasazení metodiky také ve svém dusledku ˚ pˇrineslo kvalitnˇejší kód, díky cˇ emuž probíhal vývoj stabilním tempem a zaˇclenˇení zmˇen v pozdˇejších fázích nebyl problém. Jsem také pˇresvˇedˇcen, že tempo vývoje bylo díky použití metodiky vyšší a vývoje si vyžádal ménˇe prostˇredku. ˚ Duležitým ˚ úspˇechem byla samozˇrejmˇe spokojenost zákazníka. Spoleˇcnost gdi vytvoˇrený informaˇcní systém používá a s jeho fungováním jsou podle mých informací zamˇestnanci spokojeni. Systém je dále prubˇ ˚ ežnˇe vylepšován a rozvíjen, stále za použití testované metodiky. Nasazení v praxi a spokojenost zákazníka hodnotím jako významný ukazatel životaschopnosti vytvoˇrené metodiky.
1.
http://www.gdi.cz
46
Literatura [1] Shore, J. a Warden, S.: The Art Of The Agile Development, O’REILY*, 2008, 0-59652767-5. 3.1 [2] Chaos, tech. report, The Standish Group, 1995, Dokument dostupný na URL http://www.projectsmart.co.uk/docs/chaos-report.pdf (listopad 2010) . 3.1 [3] Auza, J.: Top 50 Programming Quotes of All Time, Dokument dostupný na URL http://epf.eclipse.org/wikis/openup/ (prosinec 2010) . 4.3 [4] Fowler, M.: Refactoring: improving the design of existing code, Addison–Wesley, 2004, 0-201-48567-2. 4.3 [5] Kniberg, H.: Scrum and XP from the Trenches, C4Media, 2007, 978-1-4303-2264-1 . 3.2.2, 3.2, 3.2.5 [6] Extreme Programming, Cunningham & Cunningham, Inc., Dokument dostupný na URL http://c2.com/cgi/wiki?ExtremeProgramming (prosinec 2010) . 3.4.2 [7] Fowler, M.: Patterns of enterprise application architecture, Addison–Wesley, 2003, 0321-12742-0. 5.2
47
Pˇríloha A
Ukázka aplikace Vzhledem k citlivé povaze údaju˚ v informaˇcním systému jsou snímky obrazovek vytvoˇreny z vývojové verze, kde data a zejména finanˇcní cˇ ástky neodpovídají skuteˇcnosti.
Obrázek A.1: Snímek obrazovky se seznamem kampaní a použitým filtrem
48
A. U KÁZKA APLIKACE
Obrázek A.2: Snímek obrazovky s pˇrehledem reklamních zón a jejich obsazením
49
A. U KÁZKA APLIKACE
Obrázek A.3: Puvodní ˚ analytický model tˇríd systému
50
A. U KÁZKA APLIKACE
Obrázek A.4: Delpoyment diagram
51
A. U KÁZKA APLIKACE
52 Obrázek A.5: Puvodní ˚ skica zadavatele s obrazovkou pˇrehledu kampaní
A. U KÁZKA APLIKACE
Obrázek A.6: Burndown Chart
53
