}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Návrh metodiky vývoje softwaru z pohledu samostatného vývojáře DIPLOMOVÁ PRÁCE Ondřej Bechný Brno, 2010

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Jan Pavlovič, Ph.D. ii

3 Poděkování Rád bych poděkoval svému vedoucímu panu RNDr. Janu Pavloviči, Ph.D. za vstřícnost, odbornou pomoc a konzultace poskytnuté během tvorby této diplomové práce. Jeho připomínky a rady mi velmi pomohly. Za podporu v průběhu celého mého studia děkuji svým rodičům. iii

4 Shrnutí Tato práce ve své první části přináší přehled existujících vývojových metodik pro tvorbu softwaru, které může použít jeden samostatný vývojář. Jsou popsány hlavní rozdíly oproti některým jiným běžným týmovým technikám. Druhá část popisuje vlastní metodiku pro vývoj software jedním vývojářem, vhodnou zejména pro akademické prostředí. Tato metodika bude demonstrována na webovém informačním systému pro zadávání a správu webových reklamních kampaní. iv

5 Klíčová slova Agile, Scrum, Extrémní programování, Feature driven development, OpenUp, PHP, Zend Framework v

6 Obsah 1 Úvod Motivace Struktura práce Současný stav vývojových metodik pro jednotlivce Proč agilní Agile Manifesto Scrum Charakteristika Role Artefakty Schůzky Vhodnost pro jednotlivce Feature Driven Development Charakteristika Procesy Role Klíčové role Podpůrné role Ostatní role Vhodnost pro jednotlivce Extrémní programování Charakteristika Aktivity Shrnutí a vhodnost pro jednotlivce OpenUp Charakteristika Role Principy Vhodnost pro jednotlivce Shrnutí Návrh vlastní metodiky Problémy při práci samostatného vývojáře Procesní rámec Role Artefakty Životní cyklus Shrnutí Extrémní programování pro jednoho Použití vhodných nástrojů Shrnutí vi

7 5 Případová studie užití metodiky Zadání Použitá řešení Sprint Sprint Backlog Burn Down Chart Sprint Retrospective Sprint Review and Planning Meeting Shrnutí Závěr Literatura A Ukázka aplikace vii

8 Kapitola 1 Úvod 1.1 Motivace Napíšu si na to program. Tuto větu musel vyřknout snad každý programátor. I když měl zřejmě na mysli samotné kódování (psaní zdrojového kódu), obsáhl svým prohlášením, možná nevědomky, celý proces vývoje software. Analýza a návrh proběhnou v okamžiku, jelikož náš programátor realizuje vlastní jednoduchý nápad sám pro sebe. Není nad čím bádat. Ovšem co dělat ve chvíli, kdy se jeden rozhodne naspat si složitější program? a co když jej netvoří pro sebe, ale pro nějakého zákazníka? V takovém případě je již nutné nějakou analýzu uskutečnit. Z ní vypracovat návrh a ten poté realizovat. a hotový výtvor předat, pokud možno bez chyb. Tedy předem otestovat. a člověk najednou stojí na počátku klasického životního cyklu softwarového projektu. Rizika a úskalí takového životního cyklu pokrývá poměrně značné množství metodik, ovšem každá z nich je zaměřena na práci v týmu. Z velké části tyto metodiky řeší týmovou práci a interakci jednotlivých členů týmu, problémy vyplývající z kooperace více lidí. Zaměřují se na malé týmy o několika členech soustředěných v jedné oblasti, na vývojáře roztroušené po celé zeměkouli i na mamutí týmy tvořené desítkami členů a často rozdělených mezi různé společnosti. Opomíjen těmito metodikami však zůstává samostatný vývojář. Jeden člověk přitom může vyvíjet velký a sofistikovaný software a při této práci nutně používá jisté stereotypy, zaběhnuté dobré zvyklosti. Tento způsob práce však žádná z metodik přímo nepodporuje nebo neobsahuje. Samostatný vývojář čelí stejným problémům jako vývojové týmy. Ve skutečnosti takovým týmem je. Stejně jako jeho kolegové v početnější skupině musí získávat informace od zadavatele, zákazníka a přetavit je v analýzu. Při tom vystupuje v roli analytika. Na základě analýzy musí navrhnout budovaný systém. Tehdy jedná jako návrhář, což v týmu může být a často bývá úplně jiný člověk, než analytik. Na základně svého návrhu začíná psát program. Opět v jiné roli. Testování samozřejmě provádí také sám. Při těchto činnostech čelí stejným problémům a rizikům neúspěchu, jako kdyby pracoval v týmu. Nemusí řešit týmovou komunikaci a podobně, ovšem vyvstávají před ním jiné problémy. Jak neztratit ze zřetel cíl a neutopit se v perfekcionalismu a ladění detailů. Jak neopomíjet testování. Jak udržet systém v původním zadání a nepřidávat novou funkcionalitu. Na toto všechno je sám a žádné kontrola či navedení na správnou cestu od jeho kolegů se mu nedostává. Podpořit právě tento způsob vývoje a pomoci se vyhnout jeho úskalím si klade za cíl tato práce. 1

9 1.2. STRUKTURA PRÁCE 1.2 Struktura práce Ve své první části se práce soustředí na prozkoumání současného stavu metodik pro jednoho vývojáře a na nalezení vhodných existujících týmových metodik. Zkoumá, které jejich části by byly jedinému vývojáři prospěšné a které jsou naopak nevhodné. V druhé části formuluje práce metodiku vlastní. Spíše se jedná o souhrn a doporučení, než o formální definici metodiky. Vlastní metodika je definována na základě průzkumu jednotlivých metodik existujících a také na vlastní zkušenosti. Navržený postup vývoje je dále znázorněn na případové studii webového informačního systému. Tato studie tvoří část třetí. Jedná se o systém pro zadávání a správu webových reklamních kampaní. Zevrubně bude probrán jeho návrh, důvody, které vedly k použití zvolených technologií i nástin průběhu jeho tvorby pomocí formulované metodiky. 2

10 Kapitola 2 Současný stav vývojových metodik pro jednotlivce Tato kapitola bude poměrně krátká. V současnosti neexistuje žádná uznávaná ani zavedená metodika vývoje software jediným samostatným vývojářem. Nejčastěji je doporučováno přizpůsobit si některou z agilních metodik. Tento neutěšený stav může mít více důvodů. Hlavní bych viděl v menším trhu, který samostatní vývojáři představují. V absolutních číslech je jejich počet menší, než počet členů všech možných vývojářských týmů. Pracují také na menších projektech. Jejich hlas proto není tolik slyšet. Samostatným vývojářem se člověk zpravidla stává po jisté době a vybaven jistými zkušenostmi. Ví proto, jak si práci zorganizovat a potýká se s problémy, které se mohou jevit vůči organizaci týmové práce jako podružnější. Navíc co člověk, to originál a proto si myslím, že kolik je na světě samostatných vývojářů, tolik bude metodik, které používají. Byt by existovalo množství sebeoficiálnějších doporučení a postupů, stejně si je každý upraví ke své potřebě a chuti. V rámci jednočlenného týmu totiž neexistuje nějaký externí tlak na jejich dodržování. 3

11 Kapitola 3 Proč agilní Tato kapitola probírá, proč byly jako zkoumaná oblast zvoleny tzv. agilní metodiky a ne metodiky klasické. Ukazuje vhodnost aplikace agilních metodik pro potřeby jednotlivce. 3.1 Agile Manifesto Spolu s rozmachem dostupnosti výpočetní techniky je na vzestupu také dostupnost softwarových řešení. Projektů v informačních technologiích je stále více a jsou dostupné širšímu spektru lidí. Bolestně se tak ukazuje, že proces vývoj software není zdaleka dokonalý. Příliš mnoho projektů končí pokud ne totálním neúspěchem, tak alespoň znatelným nedodržením termínu či překročením rozpočtu. Studie The Chaos Report [2] z roku 1995 zkoumala ve Spojených státech na vzorku IT projektů jejich úspěšnost. Výsledek byl alarmující. 31,1 % zkoumaných projektů bylo zrušeno ještě před tím, než byly dokončeny. Více než polovina (52,7 %) byla dokončena s tím, že rozpočet byl téměř dvojnásobně navýšen (navýšení rozpočtu minimálně o 89 %). Pouze 16,2 % zkoumaných projektů bylo dokončeno v termínu a v rámci původního rozpočtu. Celková ztráta v důsledku zrušení projektů byla odhadnuta na 81 miliard dolarů. V této době byly na výsluní tzv. těžké metody vývoje softwaru. Těm byla vytýkána jejich těžkopádnost, byrokratický přístup, příliš pomalá reakční doba a neefektivní využití zdrojů, tedy vývojářů. Mezi takové klasické metody patří vývojové modely vodopád, spirála č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ěnami již nepočítají. Proto je každá chyba v analytické části či změna v pozdější fázi projektu velmi nákladná a často může stát za celkovým neúspěchem. Tento stav byl podhoubím, které dalo vzniknout v devadesátých letech 20. století skupině metodik, které byly později označovány jako agilní. Mezi ně patří například SCRUM, Feature driven development, Dynamic Systems Development Method, Adaptive Software Development či Extreme Programming. V roce 2001 se 17 vývojářů sešlo v lyžařském středisku 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ě jednoduchý dokument definuje filozofii vývoje softwarových projektů, která stojí na čtyřech pilířích (volný překlad): 1. Manifesto for Agile Software Development, (listopad 2010) 4

12 3.1. AGILE MANIFESTO Lidé a jejich vztahy před procesy a nástroji. Funkční software před vyčerpávající dokumentací. Spolupráce se zákazníkem před vyjednáváním smlouvy. Reakce na změnu před rigidním dodržováním plánu. Dále toto prohlášení ustanovuje dvanáct principů agilního softwaru (volný překlad) 2 : Naší největší prioritou je uspokojit zákazníka díky včasnému a neustálému dodávání hodnotného softwaru. Vítáme změny v požadavcích, dokonce i v pozdních fázích. Agilní přístup využívá změn pro zákazníkovu vyšší konkurenceschopnost. Dodáváme funkční software často, s frekvencí několik týdnů až měsíců, preferujeme kratší časové období. Zákazník a vývojáři musí během vývoje projektu denně spolupracovat. Budujeme projekt s motivovanými jednotlivci. Vytváříme jim prostředí a podporujeme jejich potřeby a věříme, že práci zvládnou. Nejúčinnější a nejefektivnější metodou zprostředkování informací do i uvnitř týmu je osobní rozhovor. Fungující software je hlavním měřítkem pokroku. Agilní metody podporují trvale udržitelný rozvoj. Sponzoři, vývojáři a uživatelé by měli být schopni udržet vývoj stejným tempem po neomezeně dlouhou dobu. Stálé zaměření na technickou dokonalost a dobrý návrh podporují agilní přístup. Jednoduchost umění maximalizující množství práce, kterou nebylo třeba vykonat je základem. Nejlepší architektury, analýzy a návrhy vycházejí týmů, které se samy organizují. V pravidelných intervalech tým analyzuje, jak být efektivnější a tomu uzpůsobuje své chování. Jak vidno, Prohlášení o agilním vývoji vyznává odklon od byrokratických přístupů vyžadovaných tradičními metodami a soustředí se na jednotlivce v týmech a jejich individuality. Tento přístup je stále zaměřen na týmy, ale jejich jednotliví členové tu dostávají širší 2. Principles behind the Agile Manifesto, (listopad 2010) 5

13 3.2. SCRUM prostor. Stále se sice nejedná o metodiku zaměřenou na jednotlivce jako samostatného vývojáře, avšak tento přistup je z pohledu samostatného jedince mnohem lépe využitelnější, než metody předešlé. Agilní techniky rozbíjejí problém (projekt) na malé části a postupně, inkrementálně budují požadovaný systém. Takové postupné budování softwaru je nazýváno inkrementální vývoj. Jednotlivé části jsou označová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řes návrh až po testování. Výsledek je pak předložen zákazníkovi k posouzení. Tento inkrementální vývoj shledávám užitečným i pro jednotlivce, protože mu pomáhá udržet pozornost soustředěnu na jeden detail či vlastnost software. Neutopí se tak proto v přeskakování z jedné vyvíjené části na druhou s frustrujícím pocitem, že nic stále není hotovo. Agilní metodiky samozřejmě nemohou být použity všude a za všech okolností. Kupříkladu nejsou vhodné, pokud je naplněn některý z následujících předpokladů [1]: Management není agilním metodám nakloněný. Napříč celým týmem nepanuje shoda na použití agilních technik. Členové týmu nejsou fyzicky přítomni na jednom místě. Příliš velký tým (více než dvacet vývojářů). Tyto předpoklady jsou však v případě jednotlivce irelevantní, či lépe jsou implicitně splněny. Pokud je člověk sám sobě pánem, management tvoří on sám. Když už se pro použití agilních metodik rozhodne, nejen že je tomu management nakloněn, panuje také shoda napříč celým jednočlenným týmem. Fyzická odloučenost jednotlivých členů není možná, stejně tak příliš velký tým. Dále v této kapitole následuje detailní pohled na některé vybrané agilní metodiky a jejich využití, byt jen z části, pro potřeby jednotlivce. 3.2 Scrum Charakteristika Scrum není, přísně vzato, metodika vývoje softwaru. Jde spíše o agilní přístup nebo framework 3. Spoléhá na tým, který se řídí sám, přirozeně, bez nějakého dohlížejícího managementu, který by stál vývojářům za zády. Nedefinuje dokonce ani formálního vůdce týmu (tzv. team leader ), spoléhá plně na profesionalitu jednotlivých členů. Roli vedoucího týmu nahrazují v podstatě všichni jeho členové, kteří priority a další postup určují na schůzích. Vývoj je rozdělen do série jednotlivých etap, označovaných jako sprinty. Jedná se o pravidelné iterace v duchu agilního vývoje. Před začátkem každého sprintu se tým dohodne, na kterých vlastnostech budovaného softwaru bude pracovat a v průběhu této ite- 3. Introduction to Scrum An Agile Process, (listopad 2010) 6

14 3.2. SCRUM race se soustředí jen na ně. Výsledkem každého sprintu je stabilní program, připravený k předvedení či předání zákazníkovi. Obrázek 3.1: Cyklus metodiky Scrum, převzato z internetových stránek White Wall Web, (prosinec 2010) Role Scrum definuje tři role, které se podílejí na procesu vývoje. ScrumMaster Jde o osobou, která by se mohla nejvíce (byt vzdáleně) podobat vedoucímu týmu. Má na starosti blaho týmu. Odstraňuje překážky bránící vývoji a slouží jako prostředník mezi týmem a vnějším světem. Vývojáři se tak mohou soustředit lépe na své úkoly. Zároveň dohlíží na dodržování postupů Scrumu, ale také na to, aby jednotliví členové týmu nebyli přetěžováni třeba tím, že si na sebe vezmou příliš mnoho úkolů a zodpovědnosti. Product Owner Product Owner je zákazník nebo alespoň reprezentuje jeho zájmy. Určuje, které vlastnosti budou vyvíjeny během jednotlivých sprintů a stanovuje jejich priority dle nejvyššího tržního přínosu. Tyto priority může průběžně měnit, za účelem maximálního zisku. Posuzuje výsledek každého sprintu, může tedy odmítnout výsledný produkt. Jeho prostřednictvím vstupují do vývoje změny, ovšem nikoliv během jednotlivých sprintů. 7

15 3.2. SCRUM Tým Scrum tým tvoří samotní vývojáři. Optimální počet členů je mezi pěti a devíti, ale toto číslo není dogmatem. Se stoupajícím počtem členů však rostou nároky na komunikaci, jak mezi jednotlivými členy během vývoje, tak také na poradách. Praxe ukazuje, že je lepší větší týmy rozdělit do několika menších [5]. Tým se skládá z vývojářů disponujících všemi potřebných dovedností (např. návrháři uživatelského rozhraní či testeři) Artefakty Procesy Scrumu jsou podporovány a sledovány třemi tzv. artefakty. Product Backlog Jedná se o seznam všech požadavků na vyvíjený produkt, jeho požadovaných vlastností a později také změn. Je udržován a doplňován v průběhu vývoje. Jelikož agilní přístup nevyžaduje vyčerpávající počáteční analýzu, je na začátku vývoje Product Backlog naplněn základními požadavky s tím, že v během práce se každý nový požadavek do seznamu přidá. O Product Backlog se stará Product Owner. Určuje priority jednotlivých požadavků, členové týmu pak doplňují časový odhad pro každou položku. Sprint Backlog Z Product Backlogu jsou na začátku každého sprintu vybrány nejdůležitější požadavky (nebo ty s nejvyšším návratem investic) a z nich je vytvořen Sprint Backlog. Jednotlivé požadavky jsou rozděleny na menší úkoly, které jsou snadněji splnitelné. Doporučuje se, aby náročnost jednotlivých úkolů byla mezi čtyřmi a šestnácti hodinami 4. Jednotlivé úkoly nejsou přiřazovány konkrétním vývojářům, místo toho si členové týmu sami vybírají, které úkoly si vezmou na starost. Sprint Backlog tak má na starosti výhradně vývojový tým. Úkoly je možné obodovat podle náročnosti, aby se lépe konstruoval tzv. Burn Down graf. Burn Down Chart Aby bylo možné přehledně sledovat průběh jednotlivých sprintů, definuje Scrum tzv. Burn down graf. Ten zobrazuje počet dosud nesplněných úkolů v čase. Osa Y znázorňuje otevřené (nesplněné) úkoly (např. podle jejich bodů) a osa X zobrazuje datum. Graf by ideálně měl mít klesající lineární průběh. Pokud klesá moc rychle, či dokonce dosáhl nulové hodnoty Y před dosažením mezní hodnoty X (konec sprintu), je možné do probíhajícího sprintu přidat další úkoly. Pokud naopak klesá příliš pomalu, ukazuje to na zpoždění, které je možné řešit např. přesunutím některých požadavků zpět do Product Backlogu. 4. Scrum (development), (listopad 2010) 8

16 3.2. SCRUM Obrázek 3.2: Burn Down Chart, převzato z [5] Schůzky Scrum definuje tři druhy schůzek, na kterých jsou probírány různé aspekty vývoje. Daily Scrum Každodenní setkání všech členů týmu, včetně ScrumMastera a Product Ownera, které probíhá v přesně stanovenou dobu. Účastnit se můž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ěla přesáhnout 15 minut. Během schůzky členové týmu bez zbytečných okolků prozradí, na čem pracovali předešlý den a co mají v plánu dnes. Pokud jim v cestě stojí nějaké překážky, měli by je zmínit. Ve výsledku by Daily Scrum měl za včasu odhalit skryté problémy a závislosti vývoje a umožnit je odstranit. Celý tým si takto také udržuje zevrubný přehled o projektu a stavu vývoje. Sprint Planning Meeting Před začátkem každého sprintu je potřeba stanovit jeho průběh a očekávaný výsledek. K tomu slouží Sprint Planning Meeting. Product Owner představí aktualizovaný Product Backlog a spolu s členy týmu se dohodne, které vlastnosti budou implementovány během nadcházejícího sprintu. Toto plánování se děje na základě priorit a časové náročnosti jednotlivých požadavků. Tato fáze by měla zabrat nejvýše čtyři hodiny. Poté přichází na řadu další čtyřhodinový blok, kdy členové 9

17 3.3. FEATURE DRIVEN DEVELOPMENT týmy vytvářejí a upřesňují Sprint Backlog, tedy detailně plánují rozvrh budoucího sprintu dělením požadavků na jednotlivé úkoly. Výstupem tohoto setkání je tedy nový Sprint Backlog. Sprint Review Meeting Tato schůzka se koná na konci každého sprintu za účelem jeho zhodnocení a shrnutí toho, co bylo vytvořeno a co se naopak dokončit nepovedlo. Je vítána účast zákazníka, nejenom Product Ownera. Těm je předveden funkční program s novými vlastnostmi. Vše by opět nemělo přesáhnout čtyřhodinový limit. Dále následuje (již bez zákazníka) zhodnocení uplynulého sprintu jednotlivými členy vývojového týmu (tato fáze bývá někdy vyčleněna jako zvláštní schůzka Sprint Retrospective ). Cílem je zhodnotit podmínky pro práci, najít problematická místa a ta v příštím sprintu odstranit Vhodnost pro jednotlivce Metodika Scrum v duchu agilního přístupu spléhá na samostatný tým a ponechává mu poměrně volnou ruku při organizaci práce. Tím pádem nestanovuje rigidní manažerská omezení a motivační tlaky na vývojáře, což je základním předpokladem pro jeho využití jednotlivcem. Zároveň definuje dostatečně pevný rámec pro vývojové procesy. Tohoto rámce může využít i samostatný vývojář. Jako samostatná metodika však pro něj Scrum příliš vhodný není, jelikož přece jenom počítá s týmovou prací a neřeší množství problémů vyplývajících ze samoty vývojáře. Jelikož bývá často doplněn prvky Extrémního programování, je vidět, že je zde prostor pro jeho úpravy a doplnění [5]. Proto mi připadá Scrum jako dobrý základ, který by po úpravách a doplnění mohl tvořit pilíř metodiky pro vývoj jedním vývojářem. 3.3 Feature Driven Development Charakteristika Tato metodika (dále jen FDD) je dalším zástupcem z rodiny iterativních a inkrementálních metod. Tento přístup se realizuje tak, že se vývoj soustředí na jednotlivé vlastnosti tvořeného systému. Od ostatních agilních metodik se ovšem trochu odlišuje. Svého vytyčeného cíle, kterým je dodávání kvalitního software, se snaží dosáhnout odstraněním nejistoty v průběhu vývoje. Tuto redukci má umožnit důkladné plánování ještě před zahájením iterativních částí procesu. Takové plánování je bližší spíše klasickým těžkým metodikám. Ve své podstatě je však FDD metodikou agilní, jelikož naplňuje agilní prohlášení (Agile Manifesto) ve všech jeho bodech. Významnou částí FDD je již zmíněné odstraňování nejistoty z procesu tvorby. Proto se snaží jednotlivé vlastnosti jednoznačně označit tak, aby už z jejich názvu byl na první pohled patrný jejich účel. 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ředpisu může kupříkladu být: 10

18 3.3. FEATURE DRIVEN DEVELOPMENT Vygenerovat nové heslo uživateli. Zobrazit seznam faktur zákazníkovi. Vypsat seznam dílů výrobku Procesy FDD ustanovuje pět základních procesů. Výsledkem prvních tří z nich je model sytému a seznam vlastností požadovaných zákazníkem. Dva poslední procesy jsou iterativně opakovány pro jednotlivé budované vlastnosti. Tvorba procesů nemusí být jednoduchá, proto FDD zavádí prostředky, jak tento postup zjednodušit a udělat jednoznačnějším. Každý proces je vytvářen tzv. procesní šablonou ETVX, cože je zkratka slov Entry criteria (vstupní podmínky), Task definitions (definice úkolů), Verification (ověření) a exit criteria (výstupní podmínky). Entry criteria Jasně stanovené požadavky, které musí být splněny před zahájením procesu. Task definitions Seznam úkolů, které mají být během procesu splněny. Součástí každého z nich by měl být seznam rolí a pokud je to nutné, tak i podrobnější popis. Verification Určení způsobů, jak je možné daný proces ověřit. Průběh procesu je rozdělen na kontrolní body a po jejich dosažení je ověř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ýstupů procesu a jejich kvality. Po splnění těchto podmínek je možné proces označit jako ukončený. Obrázek 3.3: Procesy Feature Driven Development 11

19 3.3. FEATURE DRIVEN DEVELOPMENT Tvorba celkového modelu Během úvodního procesu vývojáři a lidé zastupující zákazníka (odborníci na oblast, které se systém týká) vytvoří jeden tým a spolu navrhnou základní kostru systému. Nad celým procesem dohlíží hlavní architekt. Dále jsou lidé rozděleni 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ář vybere nejlepší návrh a doplní jej vhodnými částmi z návrhů ostatních. Skupinky je možné personálně reorganizovat, aby nedocházelo k nežádoucí dominanci jedné z nich. Postupně je takovouto dekompozicí sestaven celkový model systému. Tento proces by měl zabrat přibližně 10 % času při prvním provádění, v dalších iteracích pak 4 %. Tvorba seznamu vlastností Na základě celkového modelu systému se v tomto kroku buduje co nejúplnější seznam požadovaných vlastností. Celá doména (oblast, které se systém týká) je rozdělena na menší celky. V těchto částech jsou pak identifikovány jednotlivé požadavky a označeny výše uvedeným předpisem akce výsledek objekt. Takto vzniká strukturovaný seznam vlastností, přičemž implementace žádné z nich by neměla zabrat víc, než dva týdny. Tvorba seznamu vlastností by měla zabrat cca 4 % času v první iteraci a 1 % v každé další. Plán podle vlastností Podle seznamu vlastností z předchozího kroku se vytvoří plán průběh vývoje. Vlastnosti či jejich nadřazené celky jsou rozdělovány mezi jednotlivé vývojové týmy, které jsou reprezentovány hlavními vývojáři. Jsou jmenováni tzv. vlastníci tříd (viz dále). Vývoj je rozdělen do milníků a je ustanoven časový odhad. Plán podle vlastností by měl vždy tvořit zhruba 2 % času. Návrh podle vlastností Tento a následující proces je opakován v každé iteraci, která typicky trvá čtrnáct dní. Hlavní programátor vybírá, které vlastnosti budou v nadcházející iteraci implementovány. Spolu s příslušnými vlastníky tříd vypracuje detailní sekvenční diagram a změny promítne do celkového modelu. Ten je tak průběžně upřesňován a zjemňován. Tvorba podle vlastností Na základě předchozí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ční, je naprogramovaná vlastnost zařazena mezi existující do funkčního celku. Návrh a tvorba podle vlastností by měly tvořit asi 77 % objemu práce. 12

20 3.3. FEATURE DRIVEN DEVELOPMENT Role FDD rozlišuje tři skupiny rolí. Jeden člověk může zastávat rolí více. Jde o snahu co nejefektivnějšího využití lidského potenciálu, kdy jsou součástí týmu pracovníci různých schopností a kvalit. Zejména podpůrné role bývají často sloučeny s jinou rolí klíčovou. Seznam rolí byl převzat z internetových stránek Stephena R. Palmera Klíčové role Project Manager Tato role je dost podobná ScrumMasterovi z metodiky Scrum. Zastřešuje administrativu a správu celého projektu a stará se, aby tým měl co nejvhodnější podmínky pro svou práci. Odstraňuje překážky bránící vývoji. Chief Architect Tento člověk 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 programů týče a také si udržovat dobrý přehled o budovaném systému jako celku. Development Manager Zastává roli jakéhosi koordinátora mezi jednotlivými vývojovými týmy. Řeší případné spory a rozdělení prostředků mezi týmy. Chief Programmer Zkušený vývojář, který vede 3 6 členný tým. Podílí se na návrhu systému v úvodních procesech a řídí vývoj svého týmu v průběhu jednotlivých iterací. Plánuje, rozděluje a koordinuje práci uvnitř svého týmu. Spolupracuje také s šéfprogramátory ostatních týmů při běžných denních úkolech a problémech. Tato role je pro úspěch projektu klíčová. Class Owner Jednotlivý vývojáři, tvořící týmy, které pracují na vývoji jednotlivých vlastností. Jsou podří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ě jejich expertizy je systém modelován a jejich informace jsou proto klíčové. 5. FDD: People, (listopad 2010) 13

21 3.3. FEATURE DRIVEN DEVELOPMENT Podpůrné role Domain Manager Vede a koordinuje skupinu doménových expertů, řeší případné názorové rozpory. Tato role se uplatňuje spíše ve větších týmech. Release Manager Tento člověk shromažd uje výkazy o jednotlivých iteracích od šéfprogramátorů, zpracovává je a předkládá Project Managerovi. Kontroluje a dokumentuje tak průběh vývoje, zejména zda je vývoj dostatečně rychlý. Language Guru Tato role je potřebná zejména v projektech, které využívají nového, dosud ne dokonale známého programovacího jazyka (myšleno z pohledu vývojářů v týmu). Musí znát dokonale použitý jazyk a už při 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ř. buildovací skripty, generování dokumentace apod.). Má na starosti také správu verzovacího systému. Toolsmith Má na starosti tvorbu malých podpůrných programů, které usnadňují práci ostatním vývojářům. Jako příklad můž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 serverů a vnitřní infrastruktury. Spravuje jednotlivá vývojová prostředí (development, testing, staging) a podílí se spolu s Build Engineerem na buildovacím procesu a publikování (deploymentu) na ostatní prostředí Ostatní role Tester Testeři mohou být součástí vývojových týmů nebo pracovat v rámci externího oddělení. Nemají však za úkol psát jednotkové testy to je práce jednotlivých programátorů! Deployer Tento člověk zajišt uje instalaci a běh vyvíjeného systému v prostředí u zákazníka. Technical Writer Tvoří uživatelskou dokumentaci. 14

22 3.4. EXTRÉMNÍ PROGRAMOVÁNÍ Vhodnost pro jednotlivce Jak již bylo řečeno výše, Feature driven development je metodikou spojující světy agilních a klasických metodik. Procesní požadavky jsou vyšší, než např. u metodiky Scrum. Důraz je kladen na důkladné modelování a seznam všech možných rolí je obdivuhodný. Toto všechno má však svůj dobrý důvod umožňuje aplikovat agilní přístup k vývoji i na velké týmy a zachovat tak rychlé produkční tempo. Přestože je možné mnoho rolí sloučit do sebe, není tato metodika jako celek pro jednotlivce příliš vhodná. Dají se z ní sice použít jen některé aspekty, např. už samotné soustředění se na jednotlivé vlastnosti a podle nich si rozvrhnout práci, nicméně jako zastřešující rámec pro jednoho vývojáře je příliš složitá. Dodržování jednotlivých pravidel vývoje příliš složité není, avšak přínos FDD spočívá zejména v koordinaci lidských sil a práci s jednotlivými týmy. Oblíbeným prostředkem při samostatné práci je tzv. přehazování klobouku. Spočívá v tom, že člověk zastává vždy jen jednu roli např. kodéra, píšícího kód. Symbolicky si tak nasadí programátorský klobouk a nesoustředí se na jiné aspekty, než na psaní kódu. Pak se jakoby přenese do role testera (imaginárně si nasadí testovací klobouk) a zaobírá se pouze testováním. Člověk může vykonávat v jedné chvíli jen tu roli, jejíž klobouk má právě nasazen. Množství rolí ve FDD však tento způsob práce činí poměrně obtížným, byt spousta rolí se uplatňuje jen v malém časovém úseku a jimi vykonávaná práce stejně musí být hotova. Nicméně takové zestručnění této metodiky mi nepřipadá pří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í Charakteristika Extrémní programování (dále XP) není možné označit za metodikou vývoje, spíše za filozofii vývoje, která vychází z agilního přístupu. Tento přístup se i v současnosti vyvíjí na základě zkušenosti. Od samého počátku je tak v podstatě koncipován: pokud něco už něco funguje, doved me to k dokonalosti. Jako ilustraci tohoto přístupu uved me třeba testování. Testování softwaru se v praxi osvědčuje, používejme jej tedy všude, kde je to možné. Stejně tak např. iterativní přístup. Funguje? Doved me jej tedy do extrému pomocí krátkých iterací. Že metody XP naplňují agilní filozofii není náhoda, ale spíše důsledek uplatňování fungujících postupů. Slovo extrémní je v názvu právě z důvodu extrémního důrazu na jednotlivé metody a jejich provádění do důsledku Aktivity XP rozlišuje čtyři aktivity, které se během celého procesu vývoje opakují Extreme Programming, Cunningham & Cunningham, Inc., (prosinec 2010) 15

23 3.4. EXTRÉMNÍ PROGRAMOVÁNÍ Programování Ze všech ostatních metodik je v XP největší důraz kladen právě 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řekladu by uvedený citát zněl: Pokud na konci dne program nefunguje a nevydělává zákazníkovi peníze, neudělali jste nic. Programování je vskutku stěžejní částí vývoje, bez které software prostě (alespoň zatím) nevznikne. XP klade důraz na jednoduchost a srozumitelnost kódu, díky které odpadá nutnost psaní dokumentace. Kód musí dodržovat předem stanovené standardy a je často refaktorován. Všichni vývojáři mají přehled o celém projektu a XP nezná něco jako vlastníka třídy z FDD. Každý musí být schopen upravit jakoukoliv část kódu. K dosažení tohoto stavu XP zavádí párové programování, což je zřejmě jeho nejznámější specifikum. U jednoho počítače tak sedí dva programátoři a pravidelně se v psaní kódu střídají. Jeden se tak soustředí na kód samotný a druhý má na paměti širší kontext okolní architektury. Práce ve dvojici také napomáhá soustředění a omezuje externí rušivé vlivy. Více hlav více ví, a tak dochází v mnohem menší míře 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áři by měli být odvážní a nebát se kód refaktorovat do podoby, která bude aktuální situaci lépe vyhovovat. Extrémnější variantou je třeba zahození celodenní práce, která uvázne na mrtvém bodě. Zkušenosti totiž ukazují, že druhý den je člověk schopen vymyslet mnohem rychleji fungující řešení. Programování ve dvojici také pomáhá zabránit akumulování znalostí systému pouze jedním člověkem. Vyrovnává také rozdíly mezi vývojáři, kdy se méně zkušený mnohem rychleji učí od svého zběhlejšího kolegy. Dvojice nejsou ustanoveny na principu monogamního manželství a tak se programátoři pravidelně mezi sebou střídají. Testování Důkladné testy jsou základním stavebním kamenem metodiky XP. Tento přístup je realizací myšlenky dělat věci nejjednodušším možným způsobem, která celé XP prostupuje. Představy zákazníka o systému jsou zhmotněny v testech a pokud jimi naprogramovaný software ke spokojenosti klienta projde, je považován za hotový. Také jednotkové testy by měly být v duchu metody Test Driven Development (vývoj řízený testy) psány před 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 testů pak umožňuje refaktoring. Plánování XP zdůrazňuje nutnost umět naslouchat potřebám zákazníka. Ve spolupráci s ním jsou na začátku projektu sestaveny tzv. User stories, které v krátké formě (klidně i jedna věta) zachycují požadavky na systém. Z nich je sestaven rámec celého projektu a na jeho základě proveden hrubý časový odhad. Dále se sestaví prioritní seznam požadavků, z něhož 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číná právě plánováním. 16

24 3.4. EXTRÉMNÍ PROGRAMOVÁNÍ Každý den se všichni vývojáři sejdou během stručné schůze, kterou je doporučeno absolvovat z motivačních důvodů ve stoje. Zákazník nebo jeho zástupce by měl být přítomen na pracovišti během celého procesu vývoje. Je možné tak provádět plánování i během krátkých iterací a není nutné jej provádět do nejmenších podrobností. Při jakýchkoliv nejasnostech během práce se může vývojář se zákazníkem poradit. Taková situace často nastává při psaní testů. 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á, čemuž napomáhá výše několikrát zmíněný refaktoring. Není žádoucí myslet příliš dopředu a připravovat sytém na všechny možné eventuální směry, kterými se další vývoj může ubírat. V praxi se ukazuje, že očekávané vlastnosti často nejsou nakonec implementovány, alespoň ne tak, jak byly očekávány. Proto je snadnější tvořit systém pružněji, jednoduše a na změnu reagovat až při jejím výskytu. Existují případy, kdy s pomocí refaktoringu byly vyvíjeny systémy bez jakéhokoliv návrhu a postupně uzpůsobovány potřebám, ale to je extrémní postup i pro samo XP Shrnutí a vhodnost pro jednotlivce Stejně jako ostatní agilní metodiky, extrémní programování zvládá změny v zadání a velmi rychle na ně dokáže reagovat. Jeden z jeho klíčových principů je dělat věci nejjednodušším možným způsobem. Na tomto místě bych rád zmínil, že stručně shrnout extrémní programování není jednoduché, nebot jde o provázaný systém, kdy jedna z jeho vlastností doplňuje jinou a výsledek je závislý na synergickém efektu. Extrémní programování je v současnosti značně populární záležitostí, dlužno říci, že však spíše salónní. Plně implementované XP je více méně vzácností. Pro praktikování XP je potřeba mít v týmu vhodné lidi otevřené novým postupům a myšlenkám, a ochotné spolupracovat s ostatními. Zavést proto kompletní a plnohodnotné XP bývá náročný úkol, který navíc nejde prosadit shora navzdory názorům jednotlivých vývojářů. Odstrašujícími příklady bývají případy posměšně označované jako téměř extrémní programování 7 I přes výše uvedené je možné některé praktiky popisované XP převzít samostatně a začlenit je do procesu vývoje. Nejlepším postupem je však použít je v rámci jiné metodiky, např. Scrum se XP velmi dobře doplňuje. Co se vhodnosti pro jednotlivce týče, je situace poněkud diskutabilní. Podle mého názoru je možné metodiku XP v tomto případě s jistými ústupky použít. Jak již však bylo naznačeno výše, jde o propletené klubko jednotlivých postupů, z nichž každý má své místo. Jednotlivec musí nutně udělat jisté ústupky. Problémem může být přítomnost zákazníka po celou dobu vývoje. To je v většině případů neefektivní. Jednotlivec nevyvíjí takovým tempem jako tým, a tak by náklady takového kroku mohly být příliš velké. Mnohem větším 7. Almost Extreme Programming, Cunningham & Cunningham, Inc., (prosinec 2010) 17

25 3.5. OPENUP problémem je však požadavek na programování v páru. To má své dobré důvody, jelikož tato technika eliminuje spoustu obtíží, do kterých se programátor dostává. Na tyto obtíže samostatný vývojář naráží o to častěji a k jejich řešení musí vynaložit úsilí jinak. Zůstává pak otázkou, zda při takovém použití se XP může nadále honosit přídomkem extrémní, jelikož jeho jednotlivé části již nejsou dodržovány do krajnosti. Slouží pak spíše jako souhrn zásad, které by měl vývoj následovat a jako návod, jak řešit jednotlivé situace, které při vývoji nastávají. 3.5 OpenUp Charakteristika OpenUp (dříve OpenUp/Basic) je otevřená (open source) metodika vývoje software, která vychází z RUP (Rational Unified Process) společnosti IBM. Jde o dalšího zástupce z řady agilních metodik, která je zaměřena spíše na menší týmy. Jedná se o iterativní přístup, který je otevřený změnám v průběhu vývoje a soustředí se na uspokojení potřeb zákazníka za použití co nejmenších nákladů. Snaží se jasně definovat problémy, které mají být řešeny a na základě jejich důkladného poznání navrhnout co nejlepší strategii vývoje. Součástí postupů OpenUp je snaha o vytvoření příjemného prostředí pro tým, kde lidé nebudou mít strach projevit svůj pohled na věc či se nebudou bát udělat chybu. Striktně vzato nejde o přesnou a konečnou metodiku, spíše o rámec, který umožní nadefinovat postup vývoje přímo na míru konkrétním podmínkám. Definuje formální náležitosti vývoje, v podstatě jako jakési základní stavební kameny a postupy, jakým mohou být tyto části propojeny v jeden celek. Tyto postupy však mohou být podle potřeby pro každý projekt jiné, jednotlivé stavební prvky vynechány či přidány nové. Takto ponechává OpenUp v duchu agilní filosofie volnou ruku při průběhu projektu, avšak umožňuje využít postupy, které se v minulosti osvědčily. OpenUp se označuje jako minimální, úplný a rozšiřitelný (minimal, complete and extensible). To znamená, že jde o lehkou, jednoduchou metodiku, která neřeší spousty okolností, které mohou při vývoji software nastat. Obsahuje však základ, který je dostatečný pro celý průběh 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řeba, je možné proces doplnit a rozšířit o další potřebné činnosti. Jak již bylo řečeno, jde o iterativní přístup. Iterace jsou rozděleny do několika úrovní. Typicky měsíční iterace procházejí stádii Inception (zahájení), Elaboration (rozpracování), Construction (vývoj) a Transition (přeměna). V každé z těchto fází projekt prochází několika zhruba týdenními iteracemi. Tyto týdenní iterace nejsou mezi stádia přesně rozděleny a záleží vždy na povaze projektu, ve které fázi potřebuje strávit více času a kde naopak stačí méně. Každodenní práce pak probíhá v tzv. mikroiteracích, které mohou trvat klidně jen v řádu hodin. Díky těmto mikroiteracím je stále vidět pokrok, což je jistě motivující. Všudypřítomnou součástí iterací je testování. To probíhá při dokončení každého úseku, změně zadání či objevení chyby. Stejně jako ostatní zde uvedené agilní metodiky OpenUp vsází na častou a důkladnou komunikaci se zákazníkem. Jeho zástupce by pokud možno měl být přítomen na pracovišti 18

26 3.5. OPENUP a podílet se zejména na plánování. Společně se členy týmu pracují na analýze, jejíž výstupem bývají v OpenUp use case diagramy či scénáře. Detailní pochopení problému a jeho rozbor je základem této metodiky. Na těchto základech je pak budována propracovaná architektura, na kterou je také kladen velký důraz. Tímto se OpenUp snaží částečně předcházet změnám v zadání a především odhalit a omezit riziko ohrožující úspěch projektu. V průběhu je vypracován Iteration Plan (plán iterací), Work Item List (seznam všech požadavků) a Risk List (seznam rizik). Identifikace a vyhýbání se riziku je typickou součástí OpenUp. Pokud se v průběhu procesu narazí na možný problém, např. nedostatečnou technologii či nutnost použít již vytvořenou aplikaci, je nutné na toto riziko určitým způsobem reagovat. Obrázek 3.4: Vrstvy OpenUp, převzato z internetových stránek Eclipse Foundation, (prosinec 2010) Role OpenUp definuje sedm základních rolí. Jeden člověk může zastávat více rolí zároveň, může je střídat např. podle toho, v jaké fázi se projekt nachází. Důležité je, že nemůže v jeden okamžik zastávat více rolí. Role jsou tedy stejně jako v metafoře uvedené u metodiky FDD 19

27 3.5. OPENUP pomyslné klobouky. Člověk může mít na hlavě v jednu chvíli pouze jeden klobouk. Jednotlivé role jsou tyto: Stakeholder Reprezentant zákazníka. Jde o někoho, kdo bude mít z projektu nějaký užitek či zisk. Analyst Osoba, která převádí vstup od zákazníka (stakeholder) na výstup v podobě analýzy. Snaží se detailně porozumět požadavkům a poté je zdokumentovat. Architect Spolupracuje s analytiky a vývojáři a určuje kostru architekturu systému. Má rozhodující slovo v klíčový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ělování úkolů mezi jednotlivé lidi. Developer Vývojář navrhuje a implementuje jednotlivé části systému, testuje je zodpovědný za jejich začlenění do stávající architektury. Často spolupracuje s architektem. Project Manager Stejně jako v ostatních metodikách má manažer projektu na starosti blaho členů týmu, aby měli 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řit co nejlepší testy a zaznamenává jejich výstupy. Spolu se zbytkem týmu pak pracuje na odstranění nalezených chyb. Any Role Každý člen týmu může vystupovat v této roli a plnit tak některé z obecných úkolů Principy Celý proces, který rámec OpenUp ustanovuje, vychází ze čtyř principů: Balance competing priorities to maximize stakeholder value Volně přeloženo jako vyvažování priorit za účelem maximalizace zisku. Tento pilíř vychází z myšlenky, že systém by měl umět to, co je požadováno a nic navíc. Snaží se udržet software přijatelně použitelný, aby se nestal přerostlou obludou, která se bude snažit umět vše, 20

28 3.5. OPENUP ale nic z toho nebude dělat pořádně. Vystupuje zde snaha implementovat to nejdůležitější, co je požadováno, aby byl rozpočet maximálně zužitkován. Průběžně zaváděné změny mohou tento status quo narušit a tak je potřeba rovnováhu mezi požadavky a omezeními systému znovu vytvořit. Takový přístup vyžaduje pochopení ze strany zákazníka a naopak vývojáři se nesmí bránit změnám. Z tohoto důvodu klade OpenUp takový důraz na architekturu systému a její pravidelnou údržbu případně změnu. Collaborate to align interests and share understanding Tento princip by se dal volně přeložit jako Spolupracovat a sdílet zájmy a porozumění. Týmy jsou tvořeny lidmi s různý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ěch, týkajících se projektu a oblasti, kterou pokrývá je dobrým předpokladem pro rychlejší a kvalitnější vývoj. Lidé jsou povzbuzováni k výměně informací jak mezi sebou v rámci jedné role (např. vývojáři), tak i zástupci zákazníka s architektem apod. Členové týmu by spolu měli často komunikovat, což je podporováno i společnou zodpovědností. Nikdo nevlastní část projektu, např. část kódu. Vztahy by neměly sklouzávat do osobní roviny a lidé by se měli snažit problém nahlédnout z perspektivy toho druhého. Focus on the architecture early to minimize risks and organize development Od počátku se soustředit na architekturu za účelem minimalizace rizika a uspořádání vývoje. Kvalitní architektura vytvořená na základě všech dostupných znalostí o problému je základem OpenUp. Předchází se tak případným rizikům, která mohou v pozdějších fázích nastat. Budovaný systém by neměl dopředu příliš počítat s případnými požadavky, je však záhodno jej budovat s ohledem na budoucí změny. To znamená, že architektura by měla být flexibilní a přístupná změnám, ale jen v obecné rovině. Systém by měl být budován na základě objektově orientovaného modelu v podobě malých a navzájem co nejméně provázaných jednotek. Tomuto přístupu napomáhá také jednotkové testování, které je součá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í řešení. Evolve to continuously obtain feedback and improve Tento princip by se dal do češtiny přeložit jako Průběžně se vyvíjet a zlepšovat pomocí zpětné vazby. V podstatě jde o shrnutí iterativního vývoje a častého vydávání funkčních verzí produktu. Na jejich základě zákazník vidí, co se vytvořilo a dále zpřesňuje zadání či přehodnocuje priority. Jak je uvedeno výše, životní cyklus projektu je rozdělen do fází. Každá z těchto fází by měla mít jasně definovaný cíl a tomu se přizpůsobí práce na jednotlivých iteracích během dané fáze. Takto je snadnější odhalovat a odstraňovat rizika či jim 21

29 3.6. SHRNUTÍ předcházet Vhodnost pro jednotlivce OpenUp je velmi volnou metodikou, která poskytuje stavební kameny, ze kterých můž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ější aspekty vývoje, pro jednotlivce může být o to vhodnější, jelikož se soustředí jen na meritum věci. Navíc jde o velmi volný rámec, který si může každý uzpůsobit k obrazu svému. Primárně je určen malým týmům, čemuž odpovídají i jeho role, které navíc mohou být vykonávány jedním člověkem. Není zde přítomen management, který by držel nad týmem bič a dodával mu tak motivaci. Vývojáři mají dost vlastní zodpovědnosti. Je proto možné všechny role delegovat na jednoho člověka. OpenUp je dost formální metodikou, přesto je dostatečně volnou v konkrétní implementaci. Poskytuje potřebné nástroje pro řízení průběhu vývoje, ale umožňuje tyto nástroje přizpůsobit potřebám. Tento formální rámec může někomu vyhovovat, jinému zase ne. Podle mého názoru je OpenUp vhodný pro méně zkušené vývojáře. Není ovšem tak jednoduchý a přímočarý jako například Scrum. Vyžaduje proto jistou investici do jeho pochopení a naučení. Na oplátku nabízí pevnou ruku, která vývojáře provede všemi fázemi projektu a umožní mu vyvarovat se chyb, kterých by se ve volnější 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č je podle mého názoru agilní filosofie tím správným přístupem pro samostatného vývojáře. Uvedl jsem a zběžně popsal několik agilních metodik a zhodnotil jejich použitelnost pro jednotlivce. Každá z těchto metodik se přirozeně soustředí na práci v týmu a řeší problémy z toho vyplývající. Zároveň však poskytují rámec, kterým se vývoj řídí a ten jako takový může být využit i jednotlivcem. Z mnou zkoumaných metodik se mi jako nevhodná pro samostatného vývojáře jeví Feature driven development. Ta se soustředí převážně na koordinaci týmové práce a je primárně zaměřena na větší týmy. Jako vhodná se mi naopak jeví metodika OpenUp, která poskytuje dostatečnou volnost implementace a od počátku počítá s malým týmem. Použitelná mi také připadá kombinace Scrum a XP, kde Scrum poskytuje dostatečně pružný rámec, který vede vývojáře v průběhu vývoje produktu a umožní mu nesklouznout k podružnostem a soustředit se na priority. Extrémní programování pak poskytuje spíše sadu doporučení, jejichž dodržování vede k vyšší produktivitě a kvalitnějšímu produktu. Použít samostatné XP pro vývoj jednotlivcem mi přijde poněkud obtížné a myslím si, že kombinace se Scrumem je z hlediska dodržování zásad vývoje bezpečnější. 22

30 Kapitola 4 Návrh vlastní metodiky Ze své povahy je individuální práce jedinečná, možná i to je jeden z důvodů, proč dosud žádná pevná metodika pro jedince nebyla stanovena. Zdálo by se, že vývojář pracující na projektu jako jediný a sám je naprostým opakem týmové práce. Ovšem při bližším pohledu bychom nalezli pojítka, která tyto dva světy sbližují. Agilní techniky se z velké části zaměřují na oblast lidské produktivity, komunikace a spolupráce. Řeší, jak práci v týmu udělat co nejefektivnější maximalizací spolupráce, ale také zvýšením výkonu každého jednotlivce. a právě tyto aspekty je možné využít i pro potřeby samostatného vývojáře. 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ář potýkat. Dále navrhnu vlastní metodiku, či postup práce, který se mi jeví vhodný spolu s doporučeními, jak zmíněné problémy eliminovat. 4.1 Problémy při práci samostatného vývojáře Mohli bychom říci, že samostatný vývojář řeší tytéž problémy jako malý tým, možná s vyjímkou každodenní komunikace. Jeho pozice je však o to těžší, protože je na to všechno sám. Velkým problémem může být nedostatek motivace k práci. Lidé (a programátoři obzvlášt, u nich tato vlastnost bývá dokonce do určité míry vyžadována) jsou povětšinou od přírody líní. Obzvláště, pokud pracují na něčem, co je nebaví, v čem nevidí smysl nebo pokud si nevěří, že zadaný úkol mohou zvládnout. Nemusí jít nutně o tak zjevné příčiny, ale už jenom jejich náznaky ovlivní výkon a přistup k práci. Jednotlivec to má o to těžší, že nad ním nestojí žádný dráb s důtkami, který by jej do práce popoháněl. Většinou jediné, co ho tlačí, je blížící se termín odevzdání. Jelikož mu tedy chybí vedení, které by na něj dohlíželo, musí být takovým manažerem sám sobě. Dalším problémem, se kterým je potřeba počítat, je nedostatek reflexe. To se může projevit například nedostatky v návrhu, kterých by si někdo jiný všiml na první pohled. To samé se týká i kódu. Pokud člověk předpokládá, že bude jediným, kdo bude kód v budoucnu číst, má tendenci psát jej co nejúsporněji. Vynechává komentáře, nedodržuje formátování textu, nepoužívá smysluplné názvy metod. To všechno nemusí být vědomá a úmyslná činnost. Jde o přirozený proces, kterému se snaží všichni vedoucí týmů a metodiky obecně předcházet. Podstata problému tady není v tom, že by kódu nerozuměl někdo cizí (i když i to může být někdy nutné), ale v tom, že mu nebude rozumět s časovým odstupem ani sám autor. Toto je celkem známý fakt, přesto dodržování jistých zásad je pro samostatného vývojáře těžší než 23

31 4.1. PROBLÉMY PŘI PRÁCI SAMOSTATNÉHO VÝVOJÁŘE pro programátora, který pracuje ve skupině. Toho každodenní kontakt s kolegy dostává do situace, kdy konzultuje své řešení s ostatními a už jen vědomí jejich přítomnosti mu připomíná, že např. i při psaní kódu nesmí myslet jen na sebe. Jak vyplynulo již z popisu agilních metodik výše, software je náchylný ke změně a ta může být nákladná. Proto jsou alespoň ve většině případů pryč doby, kdy kód musel být hlavně rychlý a úsporný. Dnes již takováto úspornost ustupuje spíše ve prospěch kvality struktury kódu, protože se očekává jeho změna v budoucnu. Za kvalitního programátora je považován ten, kdo dokáže navrhnout a napsat kód přehledně, srozumitelně a jasně, aby jej i ostatní rychle pochopili. Na programátora, píšícího samostatně a bez kontaktu s okolím však nepůsobí takové síly jako na členy týmu, aby právě pracoval právě takovýmto způsobem. Něco takového, jako je revize kódu, je pro něj jen nesplnitelný sen. Dalším oříškem plynoucím ze samoty a nepřítomnosti kolegů mohou být různé zapeklité situace, do nichž může vývojář během práce zabřednout. Pokud člověk 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čí lépe vidí. Někdy se člověk zasekne na problému klidně i po několik hodin a nedaří se mu přijít s řešením. Často však stačí, aby se na tentýž problém podíval někdo jiný a okamžitě vidí jeho řešení. Často se tak vývojář pracující samostatně může dostat do slepé uličky a strávit v ní zbytečně mnoho času. Nemusí se však jednat jen o tzv. profesionální slepotu. Člověk se může dostat do úzkých i díky problémům technického rázu. Nemá však možnost zeptat se zkušenějšího kolegy sedícího vedle. Internet tento problém částečně řeší dostupností rychlé komunikace, ale osobně poprosit kolegu o pomoc s tím, že jste schopni mu přímo ukázat svou dosavadní práci je mnohem rychlejší a také pohodlnější. Specifickým případem tohoto problému může být nedostatek komunikace se zákazníkem. Agilní metodiky počítají se klientem nebo alespoň s jeho zástupcem přítomným na pracovišti. Takovýto požadavek je pro samostatného vývojáře bohužel v drtivé většině případů nerealistický. Nebývá příliš efektivní, aby byl zástupce zákazníka neustále přítomen vývoji vedeného jedním člověkem. Pravděpodobnější variantou je spíše to, že se vývojář přesune za klientem. Ani toto však nebývá příliš častá forma spolupráce. Další potíží, se kterou je potřeba se při samostatné práci potýkat, je snaha o dokládání nepříjemných úkolů. Tento problém je obzvláště patrný díky absenci vedení dohlížejícího na práci. Člověk má tendenci věnovat se těm nejzábavnějším aspektům projektu a odkládat ty méně zábavné, avšak často velmi důležité. Jako typický příklad bych uvedl testování. Tomu se spousta vývojářů snaží vyhnout, většinou proto, že nevidí jeho přínos a podle nich je jenom zdržuje od skutečné práce. Tímto problémem trpí i celé firmy a vysvětlit přínosy testování je často velmi obtížný až nesplnitelný úkol. Pokud bude jednotlivec odsouvat nepříjemné práce na vedlejší kolej a poté je úplně vynechávat, není tu nikdo, kdo by mu připomněl jejich důležitost. Testování je zde uvedeno jen jako jeden z příkladů. Druhým by mohla být analýza. Často se stává, že člověk dostane zadání nového projektu a plný nadšení se ihned pustí do jeho realizace. Taková realizace ovšem spočívá jen v psaní kódu. I když by se to tak v akademickém prostředí nemuselo jevit, je nedostatečná nebo dokonce žádná analýza jednou z velkých bolestí, kterou vývoj software trpí. Tomu také čelí agilní metodiky důrazem na analytickou 24

32 4.1. PROBLÉMY PŘI PRÁCI SAMOSTATNÉHO VÝVOJÁŘE fázi a design budovaného systému. Tento přístup, kdy člověk okamžitě po zadání úkolu sedne ke klávesnici a začne programovat řešení je u samostatných vývojářů, zejména těch mladších, poměrně rozšířený. Anglicky bývá takový styl práce pejorativně označován jako Cowboy coding. Tento výraz souhrnně označuje hurá styl přístupu k vývoji. Nejde jen o absenci analytické fáze, ale i o výslednou kvalitu kódu, který může perfektně plnit svůj účel, ale dalšímu rozšíření klade zatvrzelý odpor. U větších projektů je tento přístup téměř nemožný a vede k neúspěchu. Dalším aspektem, který musí samostatný vývojář vzít v potaz je hospodaření s časem. Výhodou samostatnosti může být možnost určit si vlastní čas na práci. Není nutné od devíti do pěti sedět v kanceláři hodinu cesty od domova. Někomu například vyhovuje pracovat v noci a je mnohem produktivnější, než by byl v osm hodin ráno. Každý člověk vypozoruje po která období bývá nejaktivnější a je pak snadné je využít k práci. Ovšem ruku v ruce s takovou volností přicházejí i problémy. Jedním z nich může být ztráta soukromí, či spíše ztráta schopnosti rozlišovat domácí a pracovní prostředí. Člověku například tím, že pracuje z domu, splývají pracovní problémy s běžným soukromým životem a cítí se jakoby byl stále v zaměstnání. Nebo si práci rozkouskuje na celý den a není pak schopen si najít dostatek času na své osobní zájmy. Velmi často se pak lidé uchylují k nějaké formě pevné pracovní doby, kterou si sami stanoví. Občas také pracují odjinud, než z domu. V rámci akademického prostředí může být řešením například práce jen ze školy. Dalším, spíše druhotným problémem mohou být pracovní přestávky. Ty totiž většinou nejsou dodržovány ani v kolektivním prostředí. Tam je ovšem větší šance přerušení práce např. vyrušením ze strany kolegů (byt nežádoucím). a i drobné rozptýlení, byt by mělo být špatně načasováno, může v tomto směru pomoci. Často se také stává, že člověk pracující sám přestane rozlišovat důležitost a priority svých jednotlivých činností. Klasickým případem může být nabalování problémů, které vznikají během vývoje. Během řešení jednoho úkolu vývojář zjistí, že pro jeho dokončení potřebuje vytvořit či upravit jinou komponentu. Práce na této komponentě však ukáže nutnost dalšího zásahu někde jinde. a tak dále. Takto je člověk odveden ne úplně vlastní vinou od podstaty problému, který řešil. Ztratit se v takovýchto vedlejších zásazích je poměrně snadné, obzvlášt pokud je člověk perfekcionalista nebo při řešení úkol narazí na oblast, která by podle něj potřebovala vylepšit. Často tak začne ztrácet čas vývojem částí, které nejsou vůbec potřeba nebo je stačí implementovat v mnohem menším rozsahu. Neexistence zpětné vazby, zejména ze strany zákazníka činí tento problém o to naléhavějším. V týmu spolupracovníků by se poradil s kolegou či případně s někým, kdo má rozhodující slovo co se požadavků týče. Variantou tohoto problému může být nedostatečné zadání. Najednou v průběhu vývoje člověk zjistí, že neví, jak daný požadavek implementovat. Jelikož nemá okamžitou zpětnou vazbu od kolegů či zákazníka, musí bud práci přerušit nebo se pokusit odhadnou, co a jak má dělat. 25

33 4.2. PROCESNÍ RÁMEC 4.2 Procesní rámec V kapitole představující jednotlivé agilní metodiky jsem u rámce Scrum uvedl, že je za jistých úprav použitelný i pro jednotlivce. Pro mě osobně je způsob, jakým je Scrum navržen, právě tím nejlepším přístupem, jak se vyhnout některým problémům zmíněným výše a udržet si stabilní a vysoké tempo vývoje za minimální byrokratické režie. Upravený a přizpůsobený Scrum však není samospásnou metodiku, která by vyřešila všechny obtíže. Poskytuje pouze vodítko průběhem projektu a spoustu ostatních věcí ponechává k řešení vývojáři samotnému. Proto mi připadá vhodné tento rámec určující směr vývoje doplnit, zejména prvky z XP, což bude popsáno dále. Nyní přejděme k popisu samotného procesního rámce, vzniklého úpravami metodiky Scrum. Zůstává zachován iterativní proces počínající úpravami Product Backlogu a vytvořením Sprint Backlogu, dále přichází samotný sprint s denními iteracemi, jehož výstupem je funkční software. Tento cyklus samotný však není dostačující a je potřeba řešit problémy, které se u týmové práce spíše nevyskytují a Scrum je nereflektuje. Zejména absence schůzek nabourává klasické schéma Scrumu a je potřeba jej vyvážit jinak, což bude v práci dále popsáno Role K použití základů Scrumu jako prvků metodiky pro vývoj vedený jedním člověkem se přikláním díky jeho jednoduchosti a volnosti, kterou Scrum poskytuje. Již z výčtu rolí je zřejmé, že nejde o žádnou detailní techniku diktující každičký aspekt práce. Scrum definuje tři role, z nichž žádná nemá nějaké zvláštní pravomoci ani vliv nad ostatními. U přizpůsobení agilních metodik jednotlivci je jednou z výzev role zákazníka či jeho zástupce, která se u každé z nich vyskytuje. Nejinak je tomu i v případě metodiky Scrum. Ta pro tento účel zavádí roli s názvem Product Owner. Nevidím způsob, jakým může jednotlivec tuto roli nahradit. Může však absenci její přítomnosti vyvážit co nejlepším kontaktem na zákazníka či zadavatele. Dále je tedy nutné spojit dvě zbývající role, ScrumMaster a Tým, do jedné. Přestože ScrumMaster může být zároveň vývojář, bývá jeho místo v týmu specifické. K jeho zodpovědnosti patří umetat týmu cestičku, aby měli k práci co nejpříhodnější podmínky. Další jeho úlohou je dohlížet na dodržování zásad metodiky. Vývojáři se pak mohou soustředit na práci samotnou. Tato role má v metodice Scrum nezastupitelné místo a bohužel ji nelze v metodice počítající jen s jedním člověkem nahradit. Proto je třeba se pokusit její absenci vyvážit jinými prostředky. Navrhovaná metodika tedy pracuje se dvěma rolemi: Product Owner V podstatě totožná role, jakou definuje metodika Scrum. Jde o zástupce zákazníka či přímo o klienta. Vývojář Jeden jediný člověk, vykonávající všechnu práci v průběhu vývoje projektu. 26

34 4.2. PROCESNÍ RÁMEC Artefakty Metodika Scrum byla jako výchozí základ zvolena i z důvodu malého počtu nutných artefaktů. Navrhovaná metodika tyto artefakty pro své potřeby zjednodušuje natolik, aby podporovaly její procesy, ale zároveň nekladly zbytečné byrokratické překážky. Žádné další formální vstupy ani výstupy již nejsou třeba. Product Backlog Vývojář na základě analýzy a konzultace se zadavatelem sestaví Product Backlog. Nejlepším způsobem je vytvořit tento seznam požadavků na budovaný systém společným úsilím za osobní účasti zadavatele. Společně ohodnotí požadavky a vznikne tak seznam seřazený dle priorit. Vývojář může okamžitě odhadovat přibližné množství práce na jednotlivých bodech a i na základ tohoto odhadu jsou priority dále upřesňovány. Sprint Backlog Sprint Backlog obsahuje seznam požadavků z Product Backlogu, které budou implementovány v nadcházejícím sprintu. Tento dokument vytváří vývojář společně s Product Ownerem, ale do finální podoby jej dopracuje už sám vývojář. Společně vyberou z Product Backlogu úkoly a vývojář sám je pak dekomponuje na jednotlivé části, které časově ohodnotí. Tyto menší části pak tvoří budované celky, které jsou samostatně otestovány a poté začleněny do stávajícího systému. Burn Down Chart Stejně jako v metodice Scrum ukazuje Burn Down Chart průběh sprintu. Graf, kde je na ose X zanesen čas Sprintu a na ose Y časové ohodnocení všech požadavků pro aktuální sprint. Když vývojář dokončí nějaký úkol, zanese do grafu aktuální hodnotu časového ohodnocení všech nehotových úkolů v aktuálním čase. Není ovšem nutné vést graf dokonale přesně, jelikož jeho smyslem je pouze naznačení průběhu vývoje. Postačí, když z něj půjde vyčíst, zda se práce opožd uje nebo naopak předbíhá oproti ideálnímu průběhu Životní cyklus Dalším prvkem, kterým se mnou navržená metodika liší od Scrumu, jsou pochopitelně schůzky. Nemyslím tím ovšem jejich absenci, protože dodržování rozvrhu určovaného právě schůzkami určuje životní cyklus této metodiky. Dodržování těchto schůzek pomůže zajistit, že vývoj bude řízen touto metodikou. 27

35 4.2. PROCESNÍ RÁMEC Obrázek 4.1: Cyklus navržené metodiky, upraveno autorem, původní zdroj Sprint Review and Planning Meeting Po dokončení sprintu na schůzce s Product Ownerem vývojář demonstruje, co všechno se mu podařilo dokončit. Dořeší se případné nesrovnalosti, například nedokončené úkoly. Nemusí být možné uskutečnit tyto dvě fáze během jedné schůzky. Může se stát, že zadavatel chce nový systém vyzkoušet a teprve po tomto testu navrhne případné změny, nové úkoly či přehodnotí priority. Nicméně, pokud je to možné, je vhodné toto vše stihnout během jednoho setkání. V případě, že ještě žádný sprint neproběhl, tato část samozřejmě odpadá. 28

36 4.2. PROCESNÍ RÁMEC Diskuze o uplynulém sprintu a předvedení systému by mělo plynule přejít v další část, kde se na základě priorit a č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črtnutý Sprint Backlog. Ten si vývojář detailně rozpracuje už sám. Daily Sprint Po této úvodní fázi následuje první sprint. Ten bývá často specifický, protože je nutné vytvořit kostru budoucího systému. Toto obzvlášt platí v případě, kdy je software budován tzv. na zelené louce, kdy není využíván žádný framework, který by práci usnadnil. Vybudování základů projektu a jeho infrastruktury může být z pohledu Scrumu, ale i jiných metodik, poměrně nevděčná záležitost. V tomto kroku totiž s velkou pravděpodobností 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ředěn do menších úkolů rozprostřených přes celý sprint, je nutné i toto počáteční budování rozdělit do menších celků. Toto je většinou na vývojáři samotném, jelikož ne vždy bude zadavatel na potřebné technické úrovni. Z pohledu zadavatele se tak může zdát, že se i přes spoustu vynaloženého úsilí v podstatě nic neudělalo. Toto by měl vzít vývojář na vědomí a správně rozvrhnout a časově ocenit jednotlivé kroky. Měl by se také snažit zadavateli vysvětlit jejich nezbytnost. Rizikem, které zde hrozí je to, že se vývojář zaváže v prvním sprintu k implementaci více vlastností, než je ve skutečnosti schopen zvládnout. Přínos iterativního vývoje se tak vytrácí a může dojít bud k prodloužení sprintu nebo nedokončení většího množství naplánovaných úkolů. První sprint by proto měl být naplánován obzvlášt pečlivě a s dostatečnou časovou rezervou. Toto vše ovšem závisí na okolnostech konkrétního projektu a také na zadavateli samotném. Samotný průběh sprintu je plně v rukou vývojáře. Metodika Scrum diktuje každodenní setkání Daily Scrum. V týmovém pojetí je účelem tohoto krátkého setkání sdílení poznatků, odstranění problémů a distribuce znalostí o systému mezi vývojáři. Toto samozřejmě u jednoho člověka odpadá, a tak si vývojář na začátku denního cyklu pouze vybírá, který bod Sprint Backlogu bude implementovat. V drtivé většině případů je však pořadí úkolů dáno jejich prioritou. Vývojář pak takto snáze udrží pozornost na důležitých věcech a nebude mít tendenci sklouzávat k jiným úkolům. Během sprintu vývojář průběžně upravuje Burn Down Chart. Tento graf je vhodné si udržovat i při samostatné práci, jelikož je na něm přehledně vidět stav vývoje. Díky tomu je snadnější vyhnout se problémům s nedokončenými úkoly, které mohou být zavčasu převedeny zpět do Product Backlogu. Graf také poskytuje jistý motivační prvek a funguje i jako odměna. Pohled na klesající křivku poměru dokončených a nedokončených úkolů je dobrým způsobem, jak v průběhu rozsáhlého pocitu nepropadnout marnosti z toho, že vlastně nic není hotovo. Dokončené úkoly jsou okamžitě vidět a samotné odškrtávání splněných úkolů je velmi příjemnou činností. 29

37 4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO Sprint Retrospective Náplní této schůzky v metodice Scrum je shrnutí právě dokončeného sprintu a vyřešení případných nedostatků. Pokud se něco nepodařilo podle plánu, je třeba analyzovat příčiny, aby mohly být napříště odstraněny. Klasickým problémem může být nedodržení plánu sprintu s tím, že se některé úkoly nepodařilo dokončit. Je důležité se zamyslet nad tím, proč byly problematické zrovna tyto úkoly a případně takový stav začít řešit. Problémem mohlo klidně být přidělení více úkolů do sprintu, než bylo možno zvládnout. Vyřešit takovou situaci je snadné zaměřit se lépe na rozdělování úkolů do sprintů, případně přehodnotit časové odhady. Někdy však problémy ve specifické oblasti mohou ukazovat například na nedostatečnou architekturu či nevhodnost použitých řešení. Každopádně je mnohem prospěšnější odhalit příčinu budoucího rizika co nejdříve. Už jen vědomí o jeho existenci je mnohem lepší, než kdyby se objevilo v pozdější fázi, kde by následky mohly být kritické. Bohužel u samostatného vývojáře neexistují tlaky k takové činnosti ze strany týmu a zejména ScrumMastera. Je také zbytečné si za tímto účelem vyhrazovat nějaký čas na přemýšlení, co se během sprintu odehrálo. Vývojář sám nejlíp ví, co šlo špatně a proč. Přesto ponechávám tento bod jako součást metodiky zejména jako připomínku, že jisté zhodnocení uplynulého sprintu je na místě Shrnutí Z výše načrtnutého postupu práce je vidět, že nebylo nutné metodiku Scrum až tak moc přizpůsobovat a ohýbat. V podstatě zůstaly zachovány všechny typy schůzek a artefakty jsou vytvářeny téměř stejně, jako by na projektu pracoval tým lidí. Zhuštění rolí také není žádný problém. Jako klíčovou vidím pozici zákazníka či zadavatele. Tato osoba by měla být vstřícná a na projektu angažovaná, což většinou bývá. V akademickém prostředí se může jednat například o školitele, který sám nemusí být zadavatelem práce, ale v podstatě reprezentuje jeho zájmy. V takovém případě 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ěj určitá pravidla. Jde o klasický iterativní přístup, který je díky několika málo jednoduchým zásadám snadné dodržet. Už jen použití Scrumu vyřeší nebo alespoň otupí některé problémy, se kterými se musí vývojář při své práci potýkat. Pole působnosti Scrumu je rozvržení a organizaci práce. Obtíže, které vyvstávají při vývoji samotném během jednotlivých sprintů pomáhá řešit sbírka pravidel, doporučení a dobrých návyků, částečně převzatá z metodiky Extrémní programování. 4.3 Extrémní programování pro jednoho V případě 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čení, která mi připadají vhodná. Většina z těchto zásad je však zahrnuta v metodice XP. Ta mi se jako samostatná metoda nejeví pro jednotlivce příliš vhodná. Argumenty 30

38 4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO pro toto tvrzení jsou uvedeny v sekci věnované právě XP výše. Extrémní programování se ovšem vcelku podrobně zaměřuje na jednotlivé denní činnosti vývojáře. Řeší celou řadu problémů, jimž musí vývojář čelit a většina takových postupů je použitelná i mimo ucelený rámec XP. Jedním z největších bolestí samostatného vývojáře je právě jeho samota a z ní vyplývající problémy. Ty jsou zevrubně popsány v úvodu této kapitoly. XP mnoho z nich řeší zavedením párového programování. Něco takového samozřejmě nepřipadá při samostatné práci v úvahu, nicméně 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ílů mezi vývojáři, úrovní jejich znalostí obecně a povědomím o systému, je jeho vedlejším efektem větší ohleduplnost. Jak architektura tak kód samotný je mnohem lepší a prostší ústupků a různých nepřehledných míst. Je to dáno právě spoluprací od samého počátku, kdy už nezáleží jen na dobré vůli každého vývojáře psát přehledný a dobře strukturovaný kód. Člověk se pak více snaží o přehlednost a srozumitelnost už díky tomu, že je jeho kód čten a revidován už při samotném psaní. Samozřejmě není možné takového výsledku dosáhnout o samotě. Je však možné mít stále na paměti, že vytvářený kód bude někdo později čí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ěkdo později uvidí, snažíme se vytáhnout a naprogramovat danou věc co nejlépe a co nejpřehledněji umíme. Dobrým postupem je tedy psát jakoby pro druhého programátora. Můžeme jít klidně o někoho, koho známe. Při 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ě se pomocí této techniky dá udržet stabilní kvalita kódu a nepodlehnout pokušení obětovat přehlednost a čitelnost. Je velmi pravděpodobné, že se ke své práci někdy v budoucnu sami vrátíme a je téměř jisté, že si detaily pamatovat nebudeme. Proto i nám samotným pomůže přehledný a strukturovaný kód i komentáře v něm. Internetem koluje vtipné rčení, které je přisuzováno Martinu Goldingovi a ilustruje tento pří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ě přeloženo znamená něco jako: Vždy pište kód tak, jako by člověk, 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řístup je znám pod zkratkami YAGNI You ain t gonna need it (nebudeš to potřebovat) a KISS Keep it simple, Stupid (udržuj to jednoduché, hlupáku). Tyto dva pojmy jsou podle mého názoru obecně dostatečně známy a obzvlášt samostaný vývojář je musí mít stále na mysli. Nepřidávat žádné funkce navíc a implementovat jen to nejnutnější je v případě jednotlivce kritické, zejména z důvodů jeho omezených možností. Iterativní vývoj a rozdělení požadavků na jednotlivé úkoly jsou vhodnými nástroji, jak toho dosáhnout. Nicméně je zapotřebí i pevné vůle a oba zmíněné principy si neustále připomínat. 31

39 4.3. EXTRÉMNÍ PROGRAMOVÁNÍ PRO JEDNOHO Problém složitosti architektury řeší i testování (krom jiného). I když je vývojář na návrh sám, může mu v tom psaní jednotkových testů pomoci. Neříkám, že je nutné vyvíjet přímo metodou Test Driven Development (vývoj řízený testy), ale není od věci před psaním samotného kódu vytvořit několik testů. Psaním testů si ujasním, co má vytvářená komponenta umět a je velká šance, že tak omezíme přidávání nechtěné funkcionality. Pokud má být daná komponenta testovatelná, je nutné ji navrhnout tak, aby byla co nejméně závislá na okolí a případné závislosti jí mohly být zpřístupněny z venčí. Testování pomáhá udržet návrh přehlednější i tím, že komponenty, které dělají příliš mnoho věcí, jsou mnohem hůře testovatelné. Abychom napsali jednoduché a přitom úplné testy, je výhodné tvořit jednoúčelové komponenty, které mají na starosti jen jeden úkol. Jednotkové testování tak může jednotlivci pomoci při návrhu a dodržování principů 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 testů podmínky pro refaktoring. Refaktoring velmi dobrým nástrojem k udržitelnosti vývoje projektu. Umožňuje zanášet změny i v pozdějších fázích vývoje a to i změny zásadního architektonického rázu. Nejde však o jednoduchý ani samospásný postup. Chybně provedený refaktoring může vrátit vývoj klidně i o celé týdny zpět [4]. Musí být prováděn v postupných krocích a upravovaný systém musí být pokryt testy. Proto je snazší než jednou za čas kompletně změnit architekturu celého systému provádět menší změny postupně. Díky existenci jednotkových testů je možné refaktorovat jak při změně existujícího kódu, tak při implementaci nových vlastností. Častý refaktoring pomůže udržet tempo vývoje i při změnách na stejné úrovni. Další částí XP, kterou je vhodné využít, je průběžná integrace (Continuous integration). Nový kód by měl být začleněn co nejdříve do stávající struktury. Je tak možné odhalit chyby blízko místa jejich vzniku a okamžitě začít pracovat na jejich odstranění. 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ěl být stabilní, funkční software. Tento přístup opět pomůže udržet stabilní tempo vývoje a omezí vývoj nadbytečných a předem nenaplánovaných funkcionalit. Aby si samostaný vývojář udržel produktivitu, je nezbytné, aby neplýtval prostředky a netříštil své úsilí prací, kterou vykonávat nemusí. Mám na mysli další notoricky známý princip nevynalézat kolo. Jednotlivec má často nutkání všechny části budovaného software udělat sám. To však téměř vždy není nutné a je naopak vhodné využít již hotových řešení. Častým argumentem bývá, že práce s vlastními komponentami je rychlejší, protože jsou napsány přesně na míru. Tomu se dá namítat, že je téměř vždy rychlejší investovat čas do pochopení hotových řešení, jelikož v nich již bylo odhaleno množství chyb a jejich funkčnost bývá prověřena. Samostatný vývojář nemá prostředků nazbyt a je pro něj výhodnější například využít dostupný framework, než si psát vlastní. Jelikož bude stále znovu řešit problémy, které již byly 32

40 4.4. POUŽITÍ VHODNÝCH NÁSTROJŮ vyřešeny někým jiným a těžko bude tyto práce vysvětlovat zadavateli. Naopak je většinou výhodnější postavit základ na hotových řešeních, což umožní soustředit se na implementaci požadovaných vlastností. Samozřejmě ne vždy je takové vhodné řešení k dispozici. Jedním z omezujících faktorů může být také licenční politika, což ovšem zřídka kdy bývá případ akademického prostředí. Jak již bylo naznačeno výše, chybějící kontakt se zadavatelem může být nepříjemným problémem. Proto je nutné mít na zákazníka kontakt a moci s ním v případě potřeby konzultovat nejasnosti. Taková konzultace ovšem neprobíhá okamžitě a většinou nějaký čas trvá, než zadavatel odpoví. Proto je důležité snažit se otázky a případné formulovat tak, aby se na ně dalo přímo odpovědět. Např. snažit se minimalizovat ovou konverzaci na minimum psaním jasných a srozumitelných dopisů. Samostatně pracující vývojář však musí přesto počítat se zdržením. Proto by se měl snažit rozvrhnout si práci tak, aby nebyl na odpovědi od zákazníka závislý. Mám na mysli už při plánování sprintu dbát na to, že by úkoly neměly záviset bezprostředně jeden na druhém, ale aby je bylo možné paralelizovat. Stejně, jako by si je rozdělovali členové týmu. Tak se může vyhout situaci, kdy čeká na vyjádření a nemůže vůbec pokračovat v práci. 4.4 Použití vhodných nástrojů Tato podkapitola je vyčleněna zvlášt, nebot její obsah přímo nesouvisí s agilními technikami. Uvedu zde nástroje, které samostatnému vývojáři usnadní práci a opět mu pomohou vyhnout se dalším nástrahám, které na něj číhají. Organizace času Organizace času je obecně velkým problémem a častým tématem. U jednotlivce to platí obzvlášt, jelikož si všechnu práci musí určit sám a nikdo na něj nedohlíží. Pozitivem však je, že odpadají vyrušení a náhlé úkoly, které odvádějí pozornost od vývoje. Nemám ambice v této práci rozebírat hospodaření s časem a techniky, jak toho nejlépe dosáhnout jelikož se jedná o velmi širokou oblast. Nicméně z hlediska vývoje software se mi osvědčila technika zvaná Pomodoro 1. Jde o jednoduchý princip, kdy po každých 25 minutách následuje krátká přestávka a po čtyřech takových blocích přestávka delší. Tato technika pomáhá udržet pozornost a zároveň dodržování důležitých přestávek. Formátování kódu Jak bylo uvedeno v předchozí podkapitole, velkým problémem bývá nedostatečná kvalita kódu. I když jde o řešení zavedené z důvodů týmové spolupráce, přesto mi připadá vhodné i pro samostatného vývojáře. Mám na mysli tzv

41 4.4. POUŽITÍ VHODNÝCH NÁSTROJŮ štábní kulturu, č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ě dodržovat, nicméně je vhodné od nich příliš neodbočovat. Jak již bylo zmíněno, přehledný a strukturovaný kód je důležitý i v případě, že jej nikdo jiný neuvidí. Až bude třeba systém opravit nebo rozšířit, tak se dodržování pravidel pro formátování kódu bohatě vrátí. S tím souvisí i psaní vhodných komentářů. Svůdná myšlenka, že kód je přece srozumitelný na první pohled, je často mylná. Při pozdějším návratu ke kódu už může vývojář zapomenout všechny souvislosti a bude tak pracně luštit svoji vlastní práci. Není nutné dodržovat nějaké formální komentáře, např. u každého konstruktoru psát, že jde o konstruktor, nicméně třeba výjimky je dobré zmínit. Komentovat svůj vlastní kód pro sebe se v dlouhodobém horizontu jednoznačně vyplatí. Systém pro správu verzí Dalším důležitým nástrojem, který se tak na první pohled nemusí jevit, je verzovací systém. Jedním z jeho přínosů je to, že dodává vývojáři jistoty. Například při refaktoringu je v případě neúspěchu možné kód obnovit z historie. I při zkoušení nového postupu není nutné si nějak zvlášt zálohovat kód, ale je možné případné změny opět vrátit zpět. Navíc odpadají nepříjemnosti spojené s vývojem ve více lidech, jako např. řešení konfliktů v souborech, a tak je práce s verzovacím systémem snadná. Osobně se mi osvědčilo použití decentralizovaného verzovacího nástroje GIT 2. Ten je snadné provozovat pouze lokálně, jelikož ze své podstaty nevyžaduje žádné centrální úložiště. Navíc jeho možnosti větvení kódu jsou ideální pro zkoušení nových nápadů a přístupů. Automatický deployment Navržená metodika je iterativní a je doporučeno také časté začleňování nových komponent do stávajícího systému, tzv. build. Z počátku tato práce může být snadná a rychlá, ale postupem času nabírá na složitosti. Navíc jde o mechanickou a nudnou činnost, které má člověk tendenci se vyhýbat. Proto je nejlepší použít pro tento účel nějaký vhodný nástroj, který ji automatizuje. Vyplatí se takový nástroj nasadit ihned ze začátku, protože čím dříve je používán, tím více času ušetří. Ideálně by měl být deployment záležitostí zadání jednoho příkazu či jednoho kliknutí myši. Pokud je systém vyvíjen jednotlivcem, není nutné vytvářet plně automatické řešení reagující např. na změny ve verzovacím systému. Typickými zástupci takových nástrojů jsou Ant 3 nebo Maven 4. Systém pro správu projektů Během práce člověk velmi často narazí na nové problémy či jej napadne, co by se dalo vylepšit nebo změnit. Nabízí se dvě možnosti vyřešit

42 4.5. SHRNUTÍ problém okamžitě nebo si jej někam poznamenat. Okamžitá práce na takovýchto nových úkolech není většinou příliš vhodná, protože je vývojář sveden z hlavní cesty a nesoustředí se pak na původní cíl. Dělat si poznámky a vrátit se k nim později je podle mého názoru pro jednotlivce mnohem účelnější. Takový přístup svádí k tomu, aby byla poznámka napsána přímo do kódu, což bývají komentáře uvozené známými značkami TODO, FIXME apod. Toto je ovšem velmi nešt astný způsob. Málo kdy je kód zpětně procházen za účelem nalezení a odstranění takových míst. Některé robustnější programovací nástroje umí takové komentáře vyhledávat a zobrazovat v přehledu. Potom ale zdrojový kód plní i funkci poznámkového bloku, což rozhodně nebyl jeho původní účel. Navíc takové praktiky k přehlednosti kódu nepřispívají. Rychlý komentář 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ě, mimo zdrojový kód. Jako nejvhodnější se mi za tímto účelem jeví použití nějakého bug tracking systému, jako např. Trac 5 nebo podle mě velmi dobrý Redmine 6. Takový sytém umožní jednoduše a dostatečně strukturovaně shromažd ovat takové poznámky a nápady, které by měly být prověřeny či neměly zapadnout. Rozhodně doporučuji 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ějakého konkrétního úkolu. Často se stává, že vývojář řeší jeden problém po několikáté a nemůže si vzpomenout, jak na to. Není proto od věci si tvořit takovou znalostní bázi týkající se aktuálního projektu, ale klidně i bez návaznosti na něj. Z osobního pohledu považuji za výhodné mít všechny informace pohromadě. Proto mi připadá vhodné použít zmíněný systém i pro podporu metodiky Scrum. Například nástroj Redmine je k tomuto účelu po instalaci rozšíření možné použít. Agilní přístup však hlásá, že nejsou důležité nástroje, ale postupy. Je proto na každém vývojáři, jakých podpůrných prostředků využije. Proto by samostatný vývojář neměl trávit zbytečně mnoho času formálním zapisováním požadavků, když to v jeho případě není nutné. Například pro artefakty metodiky Scrum je možné velmi dobře použít i obyčejný tabulkový editor. Není problém si Burn Down Chart kreslit tužkou na papír. Použití vhodných nástrojů může dost významně samostatnému vývojáři pomoci při jeho práci. Je ovšem třeba jejich nasazení vybalancovat tak, aby byly přínosem a ne zbytečnou zátěží, které se bude člověk nakonec vyhýbat. 4.5 Shrnutí V této kapitole byly nastíněny problémy, se kterými je potřeba při samostatném vývoji počítat. Jako optimální řešení se mi jeví použít upravené části metodiky metodiky Scrum ke konstrukci procesního rámce, který pak určuje procesy vývoje. To umožní soustředit se na

43 4.5. SHRNUTÍ podstatné úkoly a zorganizovat si práci. To však není dostačující řešení, jelikož neřeší množství dalších každodenních problémů, které samostatný vývoj přináší. Proto je vhodné metodiku doplnit o další postupy, přičemž 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 důraz na testování a jednoduchou architekturu. Je možné si tak udržet stabilní tempo vývoje. Další řadu každodenních úskalí je možné řešit použitím vhodných nástrojů. Ne se všemi problémy je ale možné se vypořádat pomocí technik a nástrojů. Je nutné si vypěstovat dobré návyky a snažit se je dodržovat. Jako základ bych viděl přístup nepsat kód pro jen sebe, ale i pro ostatní. Takováto strategie může vést k úspěšnému a udržitelnému vývoji projektu samostatným vývojářem. 36

44 Kapitola 5 Případová studie užití metodiky Obsahem této kapitoly bude demonstrace použití formulované metodiky pro vývoj webového informačního systému. Přestože se jedná spíše o projekt menšího rozsahu, není zde prostor demonstrovat celý jeho průběh. Na první iteraci budou předvedeny postupy, které byly používány během celého procesu vývoje. Takový rozsah je dostačující na zevrubnou ukázku nasazení metodiky v praxi. 5.1 Zadání Náplní projektu je vytvořit webový informační systém pro zadávání a správu internetových reklamních kampaní. Systém má řešit celý životní cyklus reklamní kampaně od poptávky až po realizovanou zakázku. Internetová kampaň nabývá jednoho ze stavů kalkulace, nabídka, objednávka, realizace nebo uzavřeno. Kampaň je tvořena jednou nebo více inzertními položkami. Položka pak obsahuje termín zobrazení, umístění (stránka a pozice na stránce) a vlastní reklamní obsah (označováno jako kreativum ). V závislosti na stavu kampaně jsou jednotlivé atributy položky povinné nebo volitelné. Kreativa mohou být různých typů a každý typ definuje konkrétní atributy (např. obrázek, text, zástupný obrázek apod.). Účelem systému je umožnit vytvářet a spravovat takto definované internetové kampaně týmem obchodních zástupců a zejména nastavit pro obchodníky jasně definovaná pravidla: rezervace pozic slevy a bonusy k objednávkám omezit rozsah změn v kampani v jednotlivých fázích provize z prodeje inzerce Dále by měl 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ěl plnit zejména manažerské potřeby, vlastní výkonná činnost (vystavení faktury, zveřejnění a stažení inzerce, kontrola úhrad, zpracování statistiky kampaně) bude realizována tzv. workery, které bude možné implementovat postupně během používání 37

45 5.2. POUŽITÁ ŘEŠENÍ systému (zpočátku postačí základní implementace v podobě u odpovědné osobě). Těmito workery bude zajištěna i spolupráce s externími systémy účetnictvím WinDUO 1 a reklamním systémem OpenX Použitá řešení Systém měl být zasazen do existující infrastruktury, čemuž bylo potřeba se přizpůsobit. Nutné požadavky byly použití skriptovacího jazyka PHP 3 a databázového serveru MySQL 4. Na základě těchto požadavků jsem se rozhodl pro vývoj systému použít následující nástroje: Zend Framework 5 Jedná se o robustní open source (s otevřeným zdrojovým kódem) framework, jehož vývoj je zaštítěn společností 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ě principu MVC (Model, View, Controller, v Javě též označován jako Model 2). Ten slouží k oddělení aplikační a prezentační logiky, jejichž propojení je zejména v PHP častým jevem. Funguje ve zkratce tak, že požadavek uživatele je předán kontroleru a ten jej přetransformuje na vstupy pro modely. Modely provedou na základě vstupů požadované výpočty a výsledek předají zpět kontroleru. Ten tyto výstupy předá do vrstvy view, která je zobrazí uživateli. Výhodou tohoto frameworku je jeho modulární architektura. ZF je tvořen množstvím volně provázaných komponent, které je možné nahradit řešením třetích stran či je naopak vyjmout a použít samostatně. Tohoto rysu je během vývoje s úspěchem využito. Doctrine 2 6 Vzhledem k tomu, že systém měl používat relační databázi a využívat objektově orientovaného přístupu, bylo nutné nějakým způsobem řešit ukládání dat. Zend Framework v tomto směru poskytuje řešení založené na principu Table data gateway nebo Row data gateway. Ani jeden z těchto přístupů mi není moc blízký a u dlouhodobějších projektů jejich výhradní nasazení vede k problémům. Mnohem univerzálnější a čistější je nejen podle mého názoru přístup označovaný jako Data mapper. Zjednodušeně jde o prostředníka mezi objekty v paměti a databází [7]. Padlo tedy rozhodnutí, že bude potřeba použít nějakého ORM (objektově-relační mapování) založeného právě na tomto vzoru

46 5.2. POUŽITÁ ŘEŠENÍ Ve světě PHP není kvalitních řešení takového druhu mnoho. V době plánování byl těsně před dokončením nový projekt Doctrine 2, který měl být nástupcem již delší dobu používaného ORM Doctrine. Doctrine 2 je objektově-relační mapování, které je silně ovlivněno ORM nástrojem Hibernate 7 z prostředí platformy Java a implementací vzoru Active record z frameworku Ruby on Rails 8. Výhodou Doctrine 2 je, že mapované třídy nemusí být vyděděny z nějaké základní rodičovské třídy, jak je tomu u ostatních podobných řešení. Po správném nakonfigurování mapování je používáni tohoto nástroje vcelku jednoduché a intuitivní. Rozhodně se jedná o urychlení vývoje, i když jistá učící fáze je na počátku pochopitelně přítomna. Projekt Doctrine 2 v době plánování informačního systému ještě nebyl v produkční verzi k dispozici. Přesto bylo plánováno uvedení první produkční verze v řádu měsíců a tak jsem se rozhodl podstoupit jisté riziko a Doctrine 2 do informačního systému začlenit. Symfony Dependency Injection 9 V objektově orientovaném světě je potřeba řešit vzájemnou spolupráci mezi jednotlivými objekty. Vazba mezi nimi by měla být co nejvolnější. Toho se dosahuje aplikací principu inversion of control (obrácení řízení). Jde o to, že objekt, který ke své práci potřebuje nějaké jiné objekty si je už nevytváří sám, ale jsou mu nějakým způsobem zprostředkovány. Jedním z přístupů, jak toho dosáhnout je, dependency injection (vkládání závislostí). Díky této technice je snadné testovat jednotlivé objekty samostatně a také jejich znovupoužitelnost je výrazně vyšší. Případná záměna jednotlivých části systému je také snadná. Jako pomocníka, který usnadní práci automatickým vkládáním závislostí jsem zvolil řešení použité v PHP frameworku Symfony 10. Jedná se o kontejner, ze kterého jsou dle potřeby získávány hotové instance s již nastavenými závislostmi. Definice objektů a jejich závislostí je realizována pomocí značkovacího jazyka XML. Phing 11 Build systém Phing je PHP derivátem Java nástroje ANT 12. Tento systém umožňuje pomocí jazyka XML definovat procesy a poté je volat přes příkazovou řádku. Takové procesy mohou být např. vygenerování dokumentace ze zdrojových kódů, spuštění testů, konfigurace aplikace, smazání dočasných souborů či dokonce publikování verze na vzdálený server. Redmine 13 Navržená metodika doporučuje použití nějakého centrálního místa pro uchovávání informací o projektu. Za tímto účelem jsem využil systému pro správu projektů

47 5.3. SPRINT Redmine. Jde opět o open source řešení. V tomto systému je možné přehledně sdružovat seznam úkolů i poznámek, organizovaných podle projektů nebo v globálním kontextu. Redmine je jednoduchý, uživatelsky dostatečně přívětivý a rychlý, takže práce s ním nezdržuje. Git 14 Pro správu verzí jsem použil decentralizovaný verzovací systém Git. Jeho architektura umožňuje dělat malé a časté commity (uložení provedených změn), které je možné později spojit v jeden velký a ten publikovat. Šikovnou vlastností je také jeho větvení. Hlavní vývojová větev obsahovala aktuální kód a pokud jsem začal pracovat na nějakém novém úkolu, vytvořil jsem si z ní větev novou. Tam provedl potřebné změny a zase obě větve spojil v jednu. Takový přístup není při vývoji jedním vývojářem nutný, zejména u budování nového systému ne. Ale umožňuje rychle se vrátit do původního stavu, pokud vývojář zabloudí do slepé uličky. Dále umožňuje např. při výskytu chyby tuto chybu opravit v samostatné větvi a publikovat jako jeden celek. Git je díky svému lokálnímu charakteru také velmi rychlý a rozhodně nebyl během práce žádným zdržením. Verzovací systém Git jsem používal také při psaní textu práce, zejména jako zálohovací řešení. 5.3 Sprint Na začátku práce byl na základě požadavků popsaných výše a skic jednotlivých obrazovek budoucího systému vytvořena první verze Product Backlogu. Product Owner byl člověk velmi technicky zdatný, což se projevilo také na sestavování Backlogu. Jednotlivé položky tedy nebyly jen funkční požadavky, ale také nutné práce technického charakteru potřebné pro vytvoření kostry systému. Jako nejjednodušší mi připadalo vést Product Backlog jako sešit v tabulkovém editoru OpenOffice.org Calc 15 (dále OO Calc). Pokud byl nějaký úkol dokončen, bylo označen zelenou barvou. Položky Product Backlogu jsou definovány takto: Název Krátký výstižný název. Maximálně několik slov. Priorita Přirozené číslo, čím vyšší, tím vyšší priorita. Horní mez není nijak omezena a základní ohodnocení se provádělo po desítkách, aby bylo možné později v případě potřeby prioritu dostatečně zjemnit. Odhad Odhad doby práce, která je potřeba pro implementaci požadavku. Uváděno v celých hodinách s tím, že den práce se rovná osmi hodinám

48 5.3. SPRINT Popis Delší popis úkolu, případně místo pro doplnění poznámek. Obrázek 5.1: Product Backlog Nejprve byl sestaven seznam požadavků na aplikaci. Poté byly jednotlivé požadavky ohodnoceny podle priority a seřazeny. Tak vznikl první odhad průběhu vývoje. Dále byl každý bod ohodnocen časovým odhadem náročnosti. V této první fázi bylo velmi těžké určit přesnější odhad, jelikož na začátku se jednalo o vytvoření kostry systému. I když byl použit framework, který poskytoval MVC rámec, stále bylo potřeba do něj zakomponovat ostatní knihovny, jako Doctrine 2 a Symfony Dependency Injection kontejner. Podrobnější časové odhady v dalších fázích byly možné až po sestavení tohoto základu a tak byly stanoveny pouze vágně Sprint Backlog Během prvního sprintu měla být provedena analýza a sestavení diagramu tříd. Dále měla být vytvořena kostra systému společně se základní infrastrukturou. Poté implementovány jednoduché třídy, tzv. číselníky už s tím, že bude využita databáze. První sprint byl výjimečný a proto jeho délka byla stanovena na čtyři týdny, což je 160 hodin práce. Takto 41

49 5.3. SPRINT byl tedy sestaven první Sprint Backlog. V něm jsou jednotlivé položky dekomponovány na menší úkoly a ty rozepsány zvlášt. Délka sprintu by neměla přesáhnout dva týdny, díky problematické zpětné vazbě, kterou vývojář na Product Ownera má. Sprint Backlog byl veden pro mě co nejpohodlnějším způsobem. Nepotřeboval jsem nějaký přesný záznam průběhu práce, ale chtěl jsem evidovat, kolik mi který úkol ve skutečnosti zabral času. Zároveň bylo nutné počítat s nepřesným odhadem a mít tak možnost si u každého úkolu poznamenat, kolik času zbývá ještě do jeho dokončení. Sprint Backlog byl udržován stejně jako Product Backlog jako sešit v tabulkovém editoru OO Calc. Při dokončení práce na úkolu nebo na konci dne jsem si poznamenal počet hodin strávených prací. Pokud byl úkol dokončen, do zbývajícího času jsem napsal nulu a řádek označil pro lepší vizualizaci zelenou barvou. Pokud úkol na konci dne dokončen nebyl, dopsal jsem odhad, kolik času asi ještě práce na něm zabere. Tento údaj o tom, kolik odhadovaných hodin práce se za den skutečně podařilo dokončit, byl vynesen do Burn down grafu. Obrázek 5.2: První rozpracovaný sprint Backlog 42

50 5.3. SPRINT Burn Down Chart Tento graf má sloužit jako ukazatel průběhu vývoje v daném sprintu. Nejdříve jsem jej chtěl vést v sešitu OO Calc, kde by se automaticky aktualizoval, ale ukázalo se, že to vyžaduje příliš mnoho úsilí a ústupkům jednoduchosti. Automatizace by si vyžádala vyšší náklady na vytvoření sešitu a to se mi nechtělo před každým sprintem řešit. Navíc jsem takovou míru přesnosti ani nepotřeboval. Nakonec se mi osvědčilo použití obyčejné tužky a čtverečkovaného papíru. Od ruky jsem tak nakreslil graf, který měl na ose X počet dnů které měl sprint trvat. Osa Y představovala odhadovaný zbývající počet hodin. Každý den jsem odhadl, kolik plánovaných hodin práce bylo dokončeno a tento údaj zanesl na graf. Takovýto ručně kreslený graf mi poskytoval dostatečný přehled o průběhu sprintu Sprint Retrospective Během sprintu vyplynuly na povrch jisté nedostatky. Napoprvé se nepodařilo všechny stanovené úkoly dokončit a proto byly vráceny zpět do Product Backlogu. Jako zásadní problém jsem určil špatný časový odhad. Hodně se čas lišil u propojování externích komponent se Zend Frameworkem, kdy jsem narazil na neočekávané chování a musel jej řešit. Dále se protáhla práce s ORM nástrojem Doctrine 2, se kterým jsem nebyl dostatečně obeznámen. I když jsem s takovým zdržením počítal, přesto bylo nad očekávání větší. Jednalo se o nové a praxí neotestované řešení, ale čas strávený jeho učením se mi vrátil v průběhu vývoje a bezpochyby vrátí i na jiných projektech. Druhým faktorem, který ovlivnil průběh sprintu byla průběžná integrace. Během práce se objevovaly nové úkoly, které bylo třeba automatizovat nástrojem Phing. Ten se nepředvedl v nejlepším světle a mnoho z jeho předdefinovaných postupů bylo v tomto projektu nepoužitelných. Psát si vlastní postupy také není díky architektuře Phingu nejjednodušší. Bohužel jsem na vhodnější nástroj napsaný v jazyce PHP nenarazil. I přes tyto výtky bylo jeho nasazení v konečném důsledku velkou úsporou času. I když byly tyto obtíže spíše specifikem prvotního sprintu, během kterého byla budována kostra systému, zohlednil jsem je při plánování dalších sprintů. Pokud si měl nějaký další úkol vyžádat nové technické prostředky nebo intenzivněji využívat již existující, ponechal jsem si vždy dostatečnou časovou rezervu. Během práce také vyvstalo spoustu otázek a nejasností. Všechny jsem je poznamenával do systému Redmine a později je probral s Product Ownerem. Pokud jsem narazil na nějaký problém, který se přímo netýkal práce na aktuálním úkolu nebo mě napadlo nějaké možné vylepšení, poznamenal jsem si jej tamtéž. Později bylo možné tyto problémy probrat nebo vyřešit u úkolů, kterých se týkaly. Databáze poznámek a řešení se rozrostla také o poznatky týkající se jednotlivých komponent, zejména ORM řešení Doctrine 2, abych případně za nějaký čas nemusel znovu hledat řešení již jednou vyřešených problémů. 43

51 5.4. SHRNUTÍ Sprint Review and Planning Meeting Po dokončení sprintu následovala schůzka s Product Ownerem. Představil jsem mu funkční část sytému a referoval o průběhu sprintu. Nedokončené úkoly jsme vrátili zpět do Product Backlogu a opět zhodnotili jejich náročnost a prioritu. Poté jsme přešli k plánování dalšího sprintu. Oficiálně se tedy tato schůzka změnila na Sprint Planning Meeting. Během ní se opět 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ční systém a řešení k tomu použitá. Toto představení bylo nutné k popisu sprintu, který probíhal dle navržené metodiky. Samozřejmě že se vyskytly jisté porodní potíže, zejména co se odhadu času týče, ale přesto na ně metodika dokázala zareagovat a ošetřit je v dalších sprintech. Přestože se nejednalo o rozsáhlý projekt, skýtal jistá úskalí. Na začátku byly nedostatečně formulované požadavky. Pokud bych k práci přistoupil pouze na základě prvotního zadání, brzy by se dostavily problémy. Nebylo by dostatečně jasné, které části systému mají přednost, které vlastně nejsou podstatné a které naopak nejsou zmíněny. Díky tomu by nebyla navržena optimální architektura. Testování by bez jasnějších požadavků bylo také obtížnější. Aplikací vytvořené metodiky se dosáhlo na počátku jasně specifikovaného zadání a jeho rozdělení na dílčí úkoly. Přehled jednotlivých požadavků 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ě prostředků. Bylo by možné pozměnit zadání, technické zázemí či samotnou architekturu. V tomto případě toho však nebylo za potřebí. Předvedení funkční části systému vedlo k přehodnocení některých naplánovaných úkolů. Tím se dále ujasnilo a zjemnilo zadání. Takovým postupem nebylo plýtváno prostředky na nechtěnou funkcionalitu, která by se nejprve zdála vhodná, ale později by se ukázala jako zbytečná. Každá pozdější iterace představila funkční celek. Bylo tak možné reagovat na nové požadavky a případné slepé cesty či nepoužitelná řešení. Protože vývoj probíhal v takových iteracích, bylo riziko krachu projektu významně sníženo. Jelikož by systém dostatečně otestován, bylo možné v případě potřeby provádět refaktoring. Díky tomu bylo možné udržet si vysoké tempo vývoje a nedělat kompromisní rozhodnutí co se implementace týče. Systém byl vždy rychle přizpůsoben novým potřebám a tak se nové části dařilo vyvíjet rychle bez nutnosti hledat obezličky, jak je do stávající architektury začlenit. Takto byly v dlouhodobějším horizontu sníženy náklady na vývoj, jelikož ten probíhal v podstatě stejným tempem jako na začátku. Snímky obrazovek systému jsou uvedeny v příloze. 44

52 Kapitola 6 Závěr V úvodu práce bylo zmíněno, že práce samostatného vývojáře je, co se průběhu týče, v podstatě shodná s prací týmu lidí. Při snaze o dosažení stejných cílů naráží na totožné problémy a obtíže. Některé negativní symptomy týmové práce u něj odpadají, naopak přibývají specifické problémy spojené s prací o samotě. Přestože je metodik vývoje softwaru poměrně mnoho, žádná z nich není zaměřena na vývoj vedený osamoceným jedincem. Nalézt takovou metodiku bylo jedním z cílů této práce. Bohužel se žádnou takovou najít nepodařilo a tak přišel na řadu průzkum existujících metodik k tomuto účelu vhodných. Jako zkoumanou oblast jsem zvolil agilní metodiky, právě díky jejich důrazu na individualitu a neformální vztahy. Tyto vlastnosti je co do vhodnosti použití pro samostatného vývojáře staví před tradiční těžké, strukturované metodiky. Podhoubím těchto agilních metodik je prohlášení Agile Manifesto definující zásady, které se jeho autoři zavázali dodržovat. V práci jsem stručně popsal čtyři agilní metodiky vývoje a prozkoumal jejich vhodnost pro použití samostatným jednotlivcem. Žádnou z nich však nemohu k tomuto účelu doporučit 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čuje směr a průběh vývoje a definuje nezbytné artefakty pro podporu tohoto procesu. V metodice Scrum totiž není hnacím motorem vývoje tlak na vývojáře v podobě managementu. Vývojovému týmu je přiznávána značná volnost a spoléhá se na jeho schopnost sebeorganizace. Tím, že tedy není nutné sloučit role vedení a vývojáře pod jednu, je Scrum vhodný i pro samostatný vývoj. Rozdělení práce na úkoly, definování jejich priorit a iterační cyklus však nejsou všeobjímajícím řešením. Přestože je procesním rámcem určen průběh vývoje, stále zbývá mnoho oblastí, kde samostatný vývojář naráží na překážky. Bohužel je velmi těžké definovat nějaké oficiální postupy, které pomohou tyto překážky překonat. Navíc by navrhovaná metodika měla být dostatečně pružná, aby byla použitelná širokým spektrem vývojářů s různými požadavky a zvyklostmi. Proto dále v práci navrhuji řešení problémů se kterými se vývojáři potýkají spíše jako doporučené postupy, než závaznou metodiku. Inspirací, jak různým úskalím vývoje vývoje čelit, je Extrémní programování. To klade na každodenní práci velký vliv a absorbuje do sebe známá osvědčená řešení. Součástí návrhu vlastní metodiky jsou tedy také doporučení, jak se vypořádat s konkrétními problémy, které samostatná práce vytváří. 45

53 6. ZÁVĚR Doplňkem metodiky je také použití vhodných nástrojů. V duchu agilního přístupu se opět nejedná o seznam nutných aplikací, které je třeba používat, ale o vymezení oblastí jejich působnosti. Použití nástrojů usnadňujících vývoj je na každém člověku, práce v tomto směru pouze ukazuje, kde je jejich nasazení vhodné a proč. Poslední část práce tvoří případová studie webového informačního systému pro společnost gdi, s.r.o. 1, ve které je demonstrováno použití definované metodiky. Nejsou zde zevrubně popisovány všechny požadavky na systém ani není uveden detailní rozbor použitých technologických řešení. Budovaný systém a jeho konstrukční prvky jsou popsány natolik podrobně, aby to stačilo k demonstraci techniky vývoje. Během vývoje samotného se ukázalo, že je možné tuto metodiku s úspěchem použít. Postupy vymezené metodikou vedly ke značnému snížení rizika neúspěchu díky častému zveřejňování funkčních verzí. Nasazení metodiky také ve svém důsledku přineslo kvalitnější kód, díky čemuž probíhal vývoj stabilním tempem a začlenění změn v pozdějších fázích nebyl problém. Jsem také přesvědčen, že tempo vývoje bylo díky použití metodiky vyšší a vývoje si vyžádal méně prostředků. Důležitým úspěchem byla samozřejmě spokojenost zákazníka. Společnost gdi vytvořený informační systém používá a s jeho fungováním jsou podle mých informací zaměstnanci spokojeni. Systém je dále průběžně 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řené metodiky

54 Literatura [1] Shore, J. a Warden, S.: The Art Of The Agile Development, O REILY*, 2008, [2] Chaos, tech. report, The Standish Group, 1995, Dokument dostupný na URL (listopad 2010). 3.1 [3] Auza, J.: Top 50 Programming Quotes of All Time, Dokument dostupný na URL (prosinec 2010). 4.3 [4] Fowler, M.: Refactoring: improving the design of existing code, Addison Wesley, 2004, [5] Kniberg, H.: Scrum and XP from the Trenches, C4Media, 2007, , 3.2, [6] Extreme Programming, Cunningham & Cunningham, Inc., Dokument dostupný na URL (prosinec 2010) [7] Fowler, M.: Patterns of enterprise application architecture, Addison Wesley, 2003,

55 Příloha A Ukázka aplikace Vzhledem k citlivé povaze údajů v informačním systému jsou snímky obrazovek vytvořeny z vývojové verze, kde data a zejména finanční částky neodpovídají skutečnosti. Obrázek A.1: Snímek obrazovky se seznamem kampaní a použitým filtrem 48

56 A. UKÁZKA APLIKACE Obrázek A.2: Snímek obrazovky s přehledem reklamních zón a jejich obsazením 49

57 A. UKÁZKA APLIKACE Obrázek A.3: Původní analytický model tříd systému 50

58 A. UKÁZKA APLIKACE Obrázek A.4: Delpoyment diagram 51

59 A. UKÁZKA APLIKACE Obrázek A.5: Původní skica zadavatele s obrazovkou přehledu kampaní 52

60 A. UKÁZKA APLIKACE Obrázek A.6: Burndown Chart 53