Metodika agilního vývoje softwaru na OVSS ÚVT Vendula Švendová, ÚVT MU
metodiky, kterým byla vytýkána byrokratiˇ cnost, zkostnatˇ elost, neschopnost flexibilnˇ e reagovat na zmˇ eny. Tradiˇ cní programovací metodiky mají na zaˇ cátku vývoje fixnˇ e danou funkcionalitu, které se snaží dosáhnout; naproti tomu ˇ cas a zdroje jsou promˇ enné – podˇ rizují se oné funkcionalitˇ e. Agilní metodiky naopak mají pevnˇ e dané zdroje a ˇ casové úseky (tzv. iterace), bˇ ehem nichž se postupnˇ e implementují jednotlivé vlastnosti produktu dle jejich priority. Po implementaci každé vlastnosti by mˇ el být systém provozuschopný.
1 Úvod Tento ˇ clánek popisuje agilní metodiku vývoje softwaru, kterou úspˇ ešnˇ e používáme v našem týmu na Oddˇ elení vývoje systémových služeb. Agilní metodika je zp˚ usob rozvržení a ovˇ eˇ rování práce. Pˇ ri d˚ usledném dodržování jejích pravidel se lze vyhnout problém˚ um jako jsou: 1. z pohledu zákazníka:
ˇ Castá, zákazníky nevítaná, situace „uplynul termín pro dokonˇ cení, ale software je stále nefunkˇ cní, proto potˇ rebujeme více ˇ casu“ tak v agilním vývoji nem˚ uže nastat. I v pˇ rípadˇ e, že dojde ke zpoždˇ ení, stane se pouze to, že nebudou implementovány vlastnosti s nejnižší prioritou (tudíž nebude ohrožena funkˇ cnost systému).
– software vyvíjený na základˇ e sepsaných požadavk˚ u zákazníka po dokonˇ cení zákazníkovi nevyhovuje (zmˇ enily se ˇ ci pˇ ribyly požadavky) a produkt je tˇ reba pˇ retvoˇ rit; – produkt není dokonˇ cen vˇ cas a je tudíž v poˇ žadovaném case nefunkˇ cní; – produkt není dokonˇ cen v rámci rozpoˇ ctu;
Agilních metodik existuje nˇ ekolik typ˚ u (Extrémní programování, Feature-Driven Development, Dynamic Systems Development Method, Agilní modelování, SCRUM aj.) a jejich spoleˇ cné rysy byly zformulovány v roce 2001 v tzv. Manifestu agilního vývoje softwaru [1] organizací Agile Alliance [2]. Sepsání manifestu bylo inspirováno dvˇ ema hlavními myšlenkami:
2. v rámci týmu: – jednotliví ˇ clenové týmu nevˇ edí, na ˇ cem pracují jejich kolegové; – vedoucí týmu se nepotkává dostateˇ cnˇ e ˇ casto se ˇ cleny týmu a nemá každodenní ˇ cerstvé informace, jak projekt postupuje a jaké ˇ reší ˇ clenové týmu problémy. Vˇ etšina terminologie v ˇ clánku je uvedena v ˇ ceském pˇ rekladu. Nˇ ekteré pojmy jsou však ponechány v p˚ uvodní anglické podobˇ e, abychom zachovali srozumitelnost a spojitost s terminologií užívanou ve vˇ etšinou anglických textech jiných autor˚ u, stejnˇ e jako pˇ ri bˇ ežném provozu.
– umožnit zmˇ enu je mnohem efektivnˇ ejší než se jí snažit zabránit; – je tˇ reba být pˇ ripraven na nepˇ redvídatelné události, protože ty stejnˇ e nastanou. Základními body manifestu jsou: – pˇ rednost individualitám a komunikaci pˇ red procesy a nástroji; – pˇ rednost funkˇ cnímu SW pˇ red obsažnou dokumentací; – pˇ rednost spolupráci se zákazníkem pˇ red jednáním o smlouvˇ e; – pˇ rednost reakci na zmˇ enu pˇ red plnˇ ením plánu.
2 Agilní manifest Co slovo „agilní“ vlastnˇ e znamená? Podle slovníku cizích slov ˇ cilý, aktivní, horlivý. Základní urˇ cující podmínkou agility v kontextu vývoje program˚ u je možnost zmˇ eny zadání v pr˚ ubˇ ehu celého vývoje. Zákazník tedy má možnost za chodu svoje požadavky modifikovat, aniž by to mˇ elo za následek masivní pˇ retvᡠrení již provedené práce, a tím zbyteˇ cné plýtvání ˇ casem i zdroji všech zúˇ castnˇ ených.
Jinými slovy pˇ ri dodržení tˇ echto specifik se nem˚ uže stát, že zákazník není spokojen, pˇ restože je smlouva naplnˇ ena a obohacena o rozsáhlou dokumentaci.
Agilní metodiky vznikly v polovinˇ e 90. let minulého století jako reakce na tˇ ežké tradiˇ cní 1
Obrázek 1: Bajka o praseti a kuˇ reti
3 SCRUM
Mezi kuˇ rata patˇ rí – Zainteresované strany (stakeholders) – koncoví uživatelé vyvíjeného systému, investoˇ ri, manažeˇ ri firmy, která software vyvíjí.
Na našem oddˇ elení používáme jednu z agilních metodik známou jako Scrum. Samotné slovo „scrum“ (zkrácenina slova „scrummage“, do ˇ ceštiny pˇ rekládáno jako „mlýn“) je pˇ revzato ze sportovní terminologie ragby a je to zp˚ usob, jak obnovit hru po ztrátˇ e míˇ ce. Míˇ ce se zmocní ten tým, jehož ˇ clenové spolu lépe komunikují a který je tedy lépe koordinovaný. Pˇ resnˇ e to je principem Scrumu – ˇ clenové týmu spolu neustále úzce komunikují, práci si spoleˇ cnˇ e plánují a jsou pravidelnˇ e informováni o tom, jak postupuje projekt jakožto celek, na ˇ cem pracují jejich kolegové, pˇ redávají si své know-how, a tím se práce týmu výraznˇ e zefektivní. 3.1
Mezi prasata patˇ rí – Vlastník produktu – reprezentuje zájmy zákazníka, urˇ cuje priority jednotlivých vlastností produktu, pravidelnˇ e je upravuje, pˇ rijímá/odmítá výsledky práce; – Scrum vedoucí – osoba, jejímž úkolem je zajistit hladký pr˚ ubˇ eh práce – ochraˇ nuje tým pˇ red vnˇ ejšími vlivy a udržuje ho koncentrovaný na daný úkol, vynucuje dodržování všech pravidel, organizuje pravidelné sch˚ uzky, udržuje pˇ rehled o úkolech, které je nutno splnit, odhaluje vzniklé pˇ rekážky a zahrnuje je do plánu, a v neposlední ˇ radˇ e sleduje osobní problémy a konflikty mezi ˇ cleny týmu a snaží se vytvoˇ rit pˇ ríjemné pracovní prostˇ redí; – Vývojᡠri – osoby zodpovˇ edné za vytvoˇ rení vlastního produktu, vzájemnˇ e úzce spolupracující.
Tým
D˚ uležitou vlastností, která odlišuje Scrum od tradiˇ cních metodik, je zapojení zákazníka do týmu a rozhodování o prioritách implementovaných funkcionalit. Tým je rozdˇ elen na dva základní typy rolí – kuˇ rata a prasata. Jejich pojmenování vychází z bajky o kuˇ reti a praseti, kteˇ rí se rozhodnou založit restauraci a pˇ remýšlí, jak ji pojmenují. Kuˇ re pˇ rijde s nápadem „Ham&Eggs“, což se praseti nelíbí, nebot’ kuˇ rete by se proces pouze týkal, kdežto prase by bylo pˇ rímo zapojeno. Pokud by restaurace byla firma, pak kuˇ rata budou zákazníci, kteˇ rí poskytnou požadavky a prostˇ redky na uskuteˇ cnˇ ení projektu, prasata potom zamˇ estnanci firmy, kteˇ rí zapojením vlastního úsilí vytvoˇ rí produkt.
3.2 Scrum proces Celý Scrum proces probíhá ve striktnˇ e vymezených ˇ casových intervalech tzv. sprintech. Proces zaˇ cíná sepsáním požadavk˚ u zákazníka (vlastnosti produktu) a ohodnocením jejich priorit vlastníkem produktu. Na zaˇ cátku každého sprintu jsou vybrány požadavky dle priorit a v množství úmˇ erném délce sprintu (obvykle 2–4 týdny). Jak už bylo ˇ reˇ ceno v úvodu, výsledkem každého sprintu by mˇ el být provozuschopný
Konkrétnˇ e se role v týmu dˇ elí do následujících: 2
3.4 Sch˚ uzky Všechny sch˚ uzky jsou organizovány a moderovány Scrum vedoucím, který by mˇ el zajistit jejich hladký pr˚ ubˇ eh a veškeré výstupy ze sch˚ uzek zaznamenávat. 3.5 Plánování sprintu Plánování je nejd˚ uležitˇ ejší a nejdelší sch˚ uzkou, kterou je zahájen každý sprint. Úˇ castní se jej všechna prasata a možná, ne však nutná, je i úˇ cast kuˇ rat. Na této sch˚ uzce vlastník produktu pˇ redstaví Backlog a podle priorit spolu se zbytkem týmu vytvoˇ rí program nadcházejícího sprintu – Sprint Backlog. Klíˇ cové je vybrané položky d˚ ukladnˇ e rozplánovat, což zahrnuje: – každé položce pˇ ridˇ elit vlastníka z ˇ rad vývojᡠru ˚, který je zodpovˇ edný za její dokonˇ cení; – rozepsat každou položku do jednotlivých úkol˚ u, tzv. task˚ u; – ˇ casovˇ e každou položku ohodnotit.
Obrázek 2: Scrum proces
software. V každé další iteraci pak už jen pˇ ribývají vlastnosti produktu podle jejich priorit, pˇ riˇ cemž funkˇ cnost softwaru z˚ ustává zachována. Je tedy možné zavést verzování tak, že co sprint, to nová verze.
ˇ Casové ohodnocení je obzvlášt’ d˚ uležitá a obtížná ˇ cást plánování. Vˇ etšinˇ e z nás se nejednou stalo, že jsme si na nˇ ejakou práci vyhradili nadhodnocený ˇ cas s tím, že „se to musí zaruˇ cenˇ e stihnout“, a po uplynutí oné pˇ rehnané doby jsme se divili jak velké množství „se nestihlo“.
3.3
Každý ˇ clen týmu by mˇ el mít jasno, kolik hodin bude mít bˇ ehem Sprintu k dispozici (odeˇ císt dovolené, svátky, pracovní sch˚ uzky,. . . ) a z tohoto ˇ casu je tˇ reba odeˇ císt ještˇ e 30 % (pro výskyt neˇ cekaných problém˚ u).
Artefakty
Stavebními kameny Scrumu jsou tzv. položky (Backlog items). Jsou to ony zákazníkem jasnˇ e pojmenované a prioritizované vlastnosti, které by mˇ el výsledný produkt mít (napˇ r. aplikace umí na dálku zastˇ režit všechny sledované místnosti; po zastˇ režení se zelená barva místnosti zmˇ ení na modrou apod.). Každý projekt má sv˚ uj tzv. Backlog, což je seznam všech položek, které se týkají daného produktu. Na zaˇ cátku každého sprintu se z nˇ ej pak vytvoˇ rí tzv. Sprint Backlog, obsahující pouze položky urˇ cené pro daný sprint. Backlog je dynamický v závislosti na novˇ e vzniklých podnˇ etech (mohou se mˇ enit priority jednotlivých požadavk˚ u, pˇ ribývat nové,. . . ). Zde je vidˇ et zmiˇ novaný rozdíl oproti tradiˇ cním metodikám, ve kterých jsou vlastnosti výsledného produktu fixnˇ e dané, a jakékoli vyvstalé komplikace je tˇ reba podˇ rídit p˚ uvodnímu plánu, pˇ restože tˇ reba existuje daleko elegantnˇ ejší a úspornˇ ejší ˇ rešení.
Existuje nˇ ekolik metod jak správnˇ e plánovat ˇ cas urˇ cený pro ˇ rešení úkol˚ u. Samozˇ rejmˇ e platí: ˇ cím ménˇ e komplexní úkol, tím snazší je odhadnout jeho ˇ casovou nároˇ cnost, proto je tˇ reba plánovat dostateˇ cnˇ e podrobnˇ e, aby byl odhad co nejpˇ resnˇ ejší. Nejˇ castˇ eji používaná metoda pro plánování je tzv. plánovací poker, jehož pravidla jsou následující: Každý hrᡠc (ˇ clen týmu) dostane do rukou karty s hodnotami Fibonacciho posloupnosti (1, 2, 3, 5, 8, 13, 21, 34,. . . ), které symbolizují ˇ casové úseky (hodiny, dny,. . . ). Stanoví se položka, jejíž ˇ casové ohodnocení je cílem kola hry. Vývojᡠr, v dané oblasti nejzkušenˇ ejší, krátce zbytku týmu pˇ redstaví, o co se jedná, co vše je tˇ reba v dané vˇ eci udˇ elat a jaká jsou pravdˇ epodobná 3
úskalí problému. Tým má pˇ ríležitost klást dotazy a o problému diskutovat. Následnˇ e každý z týmu vybere jednu kartu, reprezentující ˇ casový odhad položky, a položí ji lícem na desku stolu. Ve chvíli kdy mají všichni odloženou kartu, karty se obrátí a odhady porovnají. Ti, kteˇ rí mají nejextrémnˇ ejší hodnoty, jsou vyzváni k od˚ uvodnˇ ení a je vyvolána nová diskuse. Postup hry se opakuje do chvíle, než se všechny odhady shodují. Výsledkem této sch˚ uzky by tedy mˇ el být konkrétní ˇ casovˇ e ohodnocený plán, který se tým zaváže splnit. Tím, že se vývojᡠri podílí na plánování, je i jejich zainteresovanost na výsledku vyšší než pˇ ri pouhém plnˇ ení úkol˚ u nadˇ rízených a jejich práce je pˇ redvídatelná a spolehlivá. 3.6
Obrázek 3: Graf Burndown
Stand Up
3.8 Retrospektiva
Tým je pravidelnˇ e informován o tom, jak postupuje práce všech jeho ˇ clen˚ u. Tak se dˇ eje na (ideálnˇ e) každodenní ranní Stand Up sch˚ uzce. Název naznaˇ cuje charakter takovýchto setkání – všichni pˇ rítomní stojí a sch˚ uzka netrvá déle než 10 minut. Úˇ cast prasat je povinná, úˇ cast kuˇ rat možná. Na programu jsou odpovˇ edi všech ˇ clen˚ u týmu na následující tˇ ri otázky:
Po Review následuje poslední sch˚ uzka sprintu, tzv. Retrospektiva. Zde se sejdou všechna prasata a spoleˇ cnˇ e zhodnotí uplynulý sprint. Všichni ˇ clenové týmu opˇ et zodpoví nˇ ekolik otázek: – Co se mi líbilo, co jsme dˇ elali dobˇ re a chci abychom v tom pokraˇ covali? – Co se mi nelíbilo a chtˇ el bych zmˇ enit? – Co by se dalo vylepšit nebo zefektivnit?
– Co jsem udˇ elal vˇ cera? – Co udˇ elám dnes? – Co mˇ e zdržuje v práci? (potˇ rebuji pomoci s ladˇ ením programu, rozbil se mi poˇ cítaˇ c, nemohu sehnat osobu XY, . . . )
Smyslem Retrospektivy je subjektivní zhodnocení sprintu ˇ cleny týmu (nikoli pouze jejich vedoucím), ˇ címž jsou zapojeni do rozhodování o procesu, každý vyjádˇ rí sv˚ uj názor, poslechne názory ostatních a spoleˇ cnˇ e se snaží vyvarovat chyb v pˇ ríštím sprintu.
Stand Up sch˚ uzka není urˇ cena k ˇ rešení problém˚ u, není to ani sbˇ er informací o tom, kdo je pozadu. Cílem je informovanost týmu o postupu celého projektu, o komplikacích, které objevil jeden ˇ clen a mohou ovlivnit práci ostatních. ˇ Casto je práce jednoho ˇ clena vázána na dokonˇ cení práce jiného a StandUp sch˚ uzky jsou chvíle, kdy se tyto informace pˇ redávají. Tým práci sám naplánoval a sám sobˇ e se zodpovídá. 3.7
3.9 Sledování pr˚ ubˇ ehu Sprintu Pr˚ ubˇ eh sprintu je zaznamenáván pomocí r˚ uzných typ˚ u graf˚ u. Nejd˚ uležitˇ ejším z nich je tzv. Burndown, viz obrázek 3. Na svislé ose je množství práce, kterou je tˇ reba bˇ ehem sprintu udˇ elat (formou procent ˇ ci hodin), na vodorovné ose ˇ cas. Lomenou ˇ cárou je vyznaˇ cen skuteˇ cný pr˚ ubˇ eh sprintu (ToDo/Total), druhá ˇ cára znázorˇ nuje ideální pr˚ ubˇ eh sprintu (Ideal), tedy rovnomˇ erné snižování množství práce. Na tomto grafu je vidˇ et, že bˇ ehem prvních dvou dní tým pracoval rychleji, od tˇ retího dne však nestíhá. To m˚ uže být zp˚ usobeno výskytem neˇ cekaných komplikací, pˇ rípadnˇ e špatným
Review
V den následující konec sprintu probˇ ehne tzv. Review sch˚ uzka. Bˇ ehem této sch˚ uzky prasata pˇ redstaví kuˇ rat˚ um výsledky své práce (v nˇ ejaké formˇ e prezentace). Jak už bylo nˇ ekolikrát zmínˇ eno, software je funkˇ cní po každém sprintu a každá novˇ e pˇ ridaná vlastnost jeho funkˇ cnost jenom rozšiˇ ruje. 4
Obrázek 4: Používaný Google Spreadsheet plánováním (což by pˇ ri dodržení výše uvedeného postupu nemˇ elo nastat). Pomocí takového grafu lze jedním pohledem zjistit, v jakém stavu projekt je. Samozˇ rejmˇ e to vyžaduje d˚ usledné každodenní zaznamenávání provedené práce do vhodného nástroje.
– Vedle Burndown grafu vytvᡠríme i grafy pro sledování ˇ cas˚ u skuteˇ cnˇ e strávených pˇ ri vývoji (ideálnˇ e by se mˇ ely shodovat s naplánovanými) a stav˚ u položek (nová, rozpracovaná, hotová, nestíhám, nenaplánovaná). – Vzhledem k vysokému procentu dohodᡠru ˚ v našem týmu poˇ rádáme Stand Up sch˚ uzky pouze každý druhý den. – Detailní rozplánování dílˇ cích ˇ cástí položek (task˚ u) je v režii vlastníka položky, který za její dokonˇ cení zodpovídá.
Pro záznam veškerých artefakt˚ u, statistik, pr˚ ubˇ eh˚ u sprint˚ u, graf˚ u existuje celá škála nástroj˚ u. My máme zkušenosti s produktem VersionOne Enterprise [3] spoleˇ cnosti VersionOne, Inc., který jsme používali rok. Vzhledem k jeho obsáhlosti a finanˇ cní nároˇ cnosti jsme se rozhodli licenci na další rok nekoupit a používáme nyní námi upravenou formu Google Spreadsheet, viz obr. 4.
Pˇ rínos: – vlastnost, kterou na zaˇ cátku sprintu naplánujeme, je na konci sprintu hotová; – pracujeme primárnˇ e na vˇ ecech, které jsou nejd˚ uležitˇ ejší; – vedoucí týmu pˇ resnˇ e ví, v jaké fázi produkt aktuálnˇ e je a které funkcionality bude na konci sprintu obsahovat; – každý ˇ clen oddˇ elení ví, na ˇ cem pracují ostatní a vzniklé problémy spoleˇ cnˇ eˇ reší.
4 SCRUM na oddˇ elení OVSS S implementací Scrumu jsme na našem oddˇ elení zaˇ cali zhruba pˇ red rokem. Poˇ cáteˇ cní nesmˇ elé kroky zahrnovaly špatnˇ e naplánované a pˇ redevším špatnˇ e pojmenované položky a ned˚ usledné dodržování pravidel. Bˇ ehem nˇ ekolika mˇ esíc˚ u jsme se však pˇ resunuli k pomˇ ernˇ e zabˇ ehnutému režimu, jehož pˇ rínos je nezpochybnitelný.
5 Závˇ er
Naše modifikace:
Scrum není jedinou agilní metodikou, ale vybrali jsme si ji, protože je relativnˇ e jednoduchá a její zavedení bylo v našem prostˇ redí rychlé a efektivní. Mezi její hlavní výhody patˇ rí zejména úzké propojení uživatele aplikace s vývojovým procesem, krátké a rychlé iterace, které pˇ rinášejí zákazníkovi hodnoty pr˚ ubˇ ežnˇ e a pomˇ ernˇ e ˇ casto, ˇ címž zvyšují jeho spokojenost.
– položky oznaˇ cujeme písmeny M, S, W (Must, Should, Would), které ještˇ e pˇ red konkrétním rozplánováním stanoví jejich prioritu. – Burndown graf aktualizujeme na tabuli na chodbˇ e, takže každý zjistí pˇ ri pˇ ríchodu do práce jediným pohledem, v jakém stavu je aktuální sprint. – Pro záznam podrobností celého sprintu jsme si upravili Google spreadsheet, který je dostupný odkudkoli pˇ res Gmail.
Nesporným pˇ rínosem je Scrum v univerzitním prostˇ redí pˇ ri zapojení student˚ u do vývoje. Díky flexibilitˇ e plánování je zaruˇ ceno, že je možno 5
proces pˇ rizp˚ usobit jejich individuálním ˇ casovým možnostem – StandUp sch˚ uzky zvládnou hravˇ e mezi výukou a v každém sprintu je jim naplánováno pouze tolik hodin, kolik mají skuteˇ cnˇ e k dispozici. Zejména pro studenty zaˇ cínající s vývojem, jsou 14denní sprinty ideálním dávkováním práce, a pro jejich nadˇ rízené výbornou možností kontroly.
Literatura [1] Manifesto for Agile Software Development. http://www.agilemanifesto.org/ [2] Agile Alliance. http://www.agilealliance.org/ [3] Versionone. http://www.versionone.com/ [4] Wikipedia. Scrum (development). http: //en.wikipedia.org/wiki/Scrum_ (development)
6
