Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1

Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1 Jakub Balada, Alena Buchalcevová Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií nám. W. Churchilla 4, 130 67 Praha 3 e-mail: [email protected], [email protected] Abstrakt: Vývoj informačních systémů se stále potýká s nízkou úspěšností, zejména u velkých komplexních systémů. Výsledkem je nedostatečná podpora ICT pro hlavní cíle podniku, jelikož nedochází k efektivnímu propojení ICT s podnikatelskou strategií. Agilní metodiky zavádí nové principy v řízení vývoje informačních systémů, které tyto problémy eliminují. Hlavním cílem článku je prokázat přínosy agilní metodiky Scrum oproti rigorózním metodikám při vývoji velkých komplexních systémů, kde se tyto metodiky zatím příliš nevyužívají. Klíčová slova: Agilní vývoj, metodika vývoje, SCRUM, řízení projektů, splnění požadavků, komplexní systém. Abstract: Information system projects still fail in a large number. Agile methodologies reached higher level of success at specific projects developed by small teams. However most of IT companies still refuse this approach at largescale projects, which often deliver low value software to business. This paper comments mostly described conditions that must be fulfilled for agile adoption and analyze limitation of agile software process with solutions which can solve these problems. Goal of this paper is to proof a benefit of Scrum adoption at large-scale projects. For this purpose project case study of Identity and Access implementation is described. This project is characterized by limitations discussed above which should avoid Scrum adoption. Nevertheless project was marked as a successful primary due to change of methodology from plan-driven to Scrum during its development. This change helped to meet all dates at a project, accelerate bugfixing and mainly to deliver functionalities which brings higher value to business. Thanks to proposed solutions of Scrum adoption this paper proves a possibility to use this methodology at large-scale projects of system development. This can lead to common usage of Scrum which will increase success rate of all information system projects types. Goal-value oriented approach leads to more effective interconnection between ICT and business goals.

1. Úvod Význam ICT pro konkurenceschopnost podniku je stále velmi důležitý. Zejména neustálý rychlý vývoj podnikatelského prostředí nutí podniky efektivně využívat možnosti ICT a pružně reagovat na změny v tomto prostředí. Současně vývoj mnoha velkých ICT projektů končí nezdarem. Například autoři knihy [1] shrnují své názory týkající se toho, za jakých podmínek může podnik získat pomocí ICT strategickou výhodu následovně: 1

Příspěvek vznikl v rámci řešení grantu GAČR 201/08/0663 - „Inovace informačních systémů podporující konkurenceschopnost podniků“

SYSTÉMOVÁ INTEGRACE 4/2010

63

Jakub Balada, Alena Buchalcevová

“Strategický význam ICT nepominul, ale není možné ho naplnit stejnými cestami jako v minulosti. Strategické výhody nelze dosáhnout pouze nasazením nové technologie. Předpokladem je unikátní a efektivní propojení ICT s podnikatelským modelem, podnikovou strukturou a podnikovými procesy, které podniku umožní zvyšovat rychlost reakce na významné události, snižovat náklady, zvyšovat kvalitu anebo poskytovat nové produkty/služby zákazníkům a získávat klíčové informace dříve, než to zvládne konkurence.“[1] Agilní principy vývoje informačních systémů mohou být právě touto novou cestou, přinejmenším v oblasti efektivní dodávky nových ICT služeb v rámci podniku. Základem agilního přístupu k vývoji IS je maximální snaha o splnění požadavků 2 zadavatele, které se zpravidla v průběhu projektu mění. Jinými slovy se jedná o neustálou snahu pomoci zadavateli zvýšit jeho konkurenceschopnost pomocí včasné dodávky služby, kterou potřebuje v daném čase. Agilní metodiky se již prosazují u vývoje menších projektů s krátkou dobou trvání. Nejpoužívanější z nich je podle světového průzkumu [6] Scrum. Využívá ho 50% respondentů, dalších 24% využívá hybrid Scrumu a XP. Obecně je agilní vývoj využit přibližně u poloviny všech projektů. Bohužel v České republice je situace odlišná. Podle posledního a pravděpodobně jediného průzkumu využití agilních metodik v ČR [5] využívá agilní metodiky méně než 10% respondentů. Podobně dopadl průzkum znalosti agilních metodik – v ČR uvedlo pokročilou či základní znalost 43% respondentů [5] oproti 93% v celosvětovém průzkumu [6]. Cílem tohoto článku je mimo jiné větší osvěta a prokázání výhod agilního vývoje a potažmo Scrumu v České republice. Obecně jsou agilní metodiky považovány za alternativu ke standardním rigorózním metodikám, které jsou nadále doporučovány pro vývoj komplexních systémů. V článku Limitations of agile software processes [7] jsou popsány podmínky a následující omezení nasazení agilních principů: omezená podpora pro vývoj v distribuovaném prostředí omezená podpora pro využití subdodavatelů omezená podpora pro vývoj znovupoužitelných produktů omezená podpora pro vývoj ve velkých týmech omezená podpora pro vývoj kritických systémů omezená podpora pro vývoj velkých komplexních systémů V závěru [7] je shrnuto, že společnosti, které vyvíjejí dlouhotrvající velké komplexní projekty, nemusí být schopné využít agilní principy v jejich aktuální podobě. Naopak analýza neúspěchů velkých projektů (např. The replacement FAA air traffic control system, the FBI virtual case file, the Navy Marine Corps Internet) ukázala jako hlavní příčinu právě vývoj podle tradiční rigorózní metodiky [8]. Hlavním kritickým faktorem úspěchu projektu je pak označován čas vývoje. Pokud je doba dodání systému splňujícího požadavky zadavatele delší než doba, za kterou se změní prostředí, ve kterém má být systém nasazen, není projekt zpravidla 2

projektem se bude dále v této práci myslet standardní dodávka ICT služby na základě smluvního vztahu mezi zadavatelem a dodavatelem; bez újmy na obecnosti se bere v úvahu dodávka od externího poskytovatele, nejedná se tedy o vývoj v rámci interního ICT útvaru 64


Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů

úspěšný. Tento problém dále rozvádí práce [9], která se zabývá obchodními aspekty vývoje velkých komplexních systémů. Rigorózní metodiky podle ní mají problém v docílení win-win modelu, kdy zadavatel dostane přesně to, co potřebuje (což nutně nemusí být to, co na začátku požadoval) a současně dodavatel splní veškerá kritéria projektu. Naopak jedním z hlavních cílů agilních metodik je pružně reagovat na změnu požadavků zákazníka tak, aby se vyvíjený systém stal jeho konkurenční výhodou. Hlavním cílem tohoto článku je ukázat přínosy agilní metodiky Scrum oproti rigorózním metodikám při vývoji komplexních informačních systémů. Výhody této metodiky pro jisté typy projektů jsou dostatečně známé, ale naším cílem je vyvrátit často uváděná omezení pro nasazení této metodiky popsaná v [7]. Nejprve stručně popíšeme metodiku Scrum, provedeme analýzu často uváděných nedostatků a omezení pro nasazení této metodiky a následně navrhneme možné postupy, jak tato omezení překonat. Současně se pokusíme prokázat přínos nasazení metodiky Scrum při vývoji informačního systému, který má většinu uváděných omezení. K tomuto účelu využijeme případovou studii nasazení metodiky Scrum v průběhu vývoje komplexního systému. Jedná se o projekt nasazení Identity a Access managementu pro společnost Telefónica O2 Czech Republic, který řídí přístupy pro více jak 18 000 zaměstnanců společnosti do desítek různých systémů. Projekt byl rozdělen do dvou hlavních fází, přičemž první byla řízena rigorózně a druhá pomocí metodiky Scrum, což umožňuje porovnat hlavní ukazatele projektu v jednotlivých fázích a prokázat úspěšnost nasazení metodiky Scrum.

2. Metodika Scrum Za zakladatele metodiky Scrum [3] jsou považováni K. Schwaber a J. Sutherland, kteří nezávisle na sobě využili principy této metodiky již v devadesátých letech minulého století. Současně jsou jedni z autorů agilního manifestu [4], ve kterém jsou definovány 4 základní hodnoty a 12 principů agilního vývoje. Manifest zní (přeloženo dle [2]): „Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji, fungujícímu softwaru před podrobnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu.“ Na základě těchto hodnot vyvinuli Scrum, který je typickou agilní metodikou. Definuje pouze pár základních artefaktů a procesů, předává kompetence samotným členům vývojového týmu a neklade takový důraz na úplnou dokumentaci. Fungující software dodávaný v pravidelných krátkých intervalech, který je připravený k nasazení u zadavatele, je hlavním cílem této metodiky, což přesně naplňuje podstatu efektivního propojení ICT se strategií podniku. Spolupráce se zadavatelem je klíčová - Scrum je založen na win-win modelu, kdy změnové požadavky nejsou problémem, ale vítanou skutečností, která pomůže zadavateli v jeho konkurenčním prostředí.


65


2.1 Proces vývoje podle metodiky Scrum Samotný proces vývoje je založený na iterativním modelu životního cyklu (obr. 1). Jednotlivé iterace se nazývají sprinty a mají vždy stejně dlouhou dobu trvání, typicky jeden měsíc. Výsledkem každého sprintu je otestovaný a hlavně nasaditelný přírůstek. V rámci každého sprintu se vyvíjejí požadavky (user stories), které jsou vydefinovány na začátku sprintu v tzv. sprint backlogu. Ten je podmnožinou product backlogu, což je kompletní soupis všech požadavků na vyvíjený software. Důležitá je prioritizace položek na product backlogu, podle které se vybírají úlohy do nejbližšího spritu, čímž je zajištěna včasná dodávka služeb, které zadavatel nejvíce potřebuje.

Obr. 1: Scrum proces (zdroj: wikipedia.org) Každý den probíhá v přesně definovaný čas tzv. „daily scrum“, kdy se sejde kompletní vývojový tým a každý člen týmu zodpoví následující 3 otázky: Které úlohy jsem řešil předešlý den? Které úlohy budu řešit dnes? Jaké vidím omezení a překážky pro řešení svých úloh? Tato pravidelná schůzka, která by neměla přesáhnout 30 minut, napomáhá komunikaci v týmu a předchází možným problémům. Současně se této schůzky mohou zúčastnit lidé zodpovědní za projekt a mít tak přehled o stavu projektu na denní bázi.

2.2 Role v rámci metodiky Scrum Pro další část práce je potřeba popsat základní 3 role, které Scrum zavádí – Product owner, Scrum master a tým. Product owner je nejdůležitější role během vývoje IS podle této metodiky. Paradoxně je velkou výhodou a ve většině případů nutností, aby tuto roli zastávala osoba od zadavatele. Zodpovědností product ownera je totiž správa product backlogu a především prioritizace jednotlivých user stories. Product owner tedy ovlivňuje výslednou podobu vyvíjeného IS a je za ní zodpovědný. Zde nacházíme velký rozdíl oproti vývoji podle rigorózní metodiky, kde je obsah dodávaného IS definován na začátku projektu a může být modifikován pouze na základě 66



změnových požadavků. Ty většinou definují různě zainteresovaní lidé na straně zadavatele a nikdo je neporovnává mezi sebou a nemá za ně finální odpovědnost. Podle metodiky Scrum může product owner přijímat požadavky během celé doby vývoje, dávat jim prioritu a podle ní je zařazovat do product backlogu. Ten může, a měl by, před každým sprintem přeprioritizovat tak, aby vždy odpovídal aktuálním potřebám zadavatele. Důsledek tohoto procesu je neprázdný product backlog na konci projektu (který může teoreticky nastat na konci libovolného sprintu). Funkčnosti, které se takto neimplementují, mají nejmenší prioritu a zpravidla již nejsou v danou chvíli potřeba. Výsledný IS tedy vždy obsahuje funkčnosti, které mají pro zadavatele největší význam v daném čase, a naopak neobsahuje takové, které mu nepřinesou dostatečnou přidanou hodnotu vůči investovaným prostředkům. Scrum master je role zodpovědná za správnou adaptaci metodiky Scrum. Vede všechny důležité schůzky v rámci vývoje a především se snaží udržet ideální podmínky pro práci týmu. Neměl by se podílet na samotném vývoji ani určovat, kdo z týmu má vyvíjet jaké úlohy ze sprint backlogu. Jeho hlavním cílem je neustálá snaha o zlepšení procesu vývoje, k čemuž slouží především tzv. sprint retrospective meeting na konci každého sprintu. Na této schůzce, které se účastní všichni lidé zainteresovaní na vývoji, se probírají možné zlepšení vývojového procesu. Scrum není evoluční metodikou pouze ve smyslu životního cyklu vyvíjeného IS, ale také ve smyslu evoluce samotného procesu vývoje podle této metodiky. Což odpovídá 5. nejvyššímu stupni zralosti procesu vývoje IS podle CMMI. Tým je skupina ICT specialistů podílejících se na vývoji daného IS. Jelikož Scrum je opakem vodopádového modelu vývoje IS, musí být v týmu po celou dobu trvání projektu zastoupeny všechny potřebné role, jako jsou analytici, designéři, vývojáři, testeři a případně další. Všechny tyto činnosti je potřeba provést v každém sprintu pro všechny úlohy na aktuálním sprint backlogu. Tým vždy sám rozhoduje o tom, kolik požadavků z product backlogu převezme do nejbližšího sprintu a tím pádem sám ohodnocuje pracnost jednotlivých user stories. Současně tím přebírá odpovědnost za daný sprint a jeho dokončení v termínu, který je striktně nepřekročitelný. Pokud nastanou během sprintu problémy ohrožující jeho dokončení v termínu a kvalitě, položky s nejmenší prioritou jsou přesunuty do dalšího sprintu. Z toho plyne důležitá vlastnost vývoje podle Scrumu, totiž že ze základních čtyř kritérií řízení projektů – kvalita, kvantita, termín, rozpočet – může být jedině kvantita potencionálně nesplněná. Podrobnější popis metodiky Scrum, především doporučený sled a obsah jednotlivých kroků v rámci sprintu je popsán v [3].

3. Využití metodiky Scrum pro vývoj komplexních IS Metodika Scrum popsaná výše je již celosvětově hojně využívána při vývoji menších IS v týmech do 10 vývojářů [6]. Jako její největší přínosy respondenti uvádějí větší možnost řídit změnové požadavky, lepší monitorování stavu projektu a efektivnější provázání IT s cíli podniku. Nicméně ani stále masovější využití pro projekty vyvíjené menšími týmy a prokazatelně větší úspěšnost tohoto přístupu [6] nevede k adaptaci této metodiky pro vývoj velkých komplexních IS. Zastánci


67


tradičních rigorózních metodik často uvádějí podmínky a omezení pro vývoj podle agilních principů [2] [7]. V další části této práce je snahou autora komentovat uváděné podmínky, které 3 musí být splněny pro možný vývoj pomocí agilních metodik a dále analyzovat uváděné omezení v nasazení Scrumu s návrhem řešení těchto problémů.

3.1 Nutné podmínky pro nasazení Scrumu V [7] je uvedeno celkem 11 podmínek, které musí být podle autorů splněny k tomu, aby mělo význam využít agilní přístup: 1. Zadavatel úzce spolupracuje s vývojáři a je v případě potřeby k dispozici. Současně face-to-face komunikace vyžaduje umístění vývojářů na jednom místě. Zapojení zadavatele do vývoje je opravdu velice důležité, nicméně může být redukováno na 3 schůzky během sprintu. To znamená přibližně 3 hodiny času klíčových osob zadavatele měsíčně. Nutnost umístění vývojářů na jednom místě bude diskutována dále v textu při řešení distribuovaného vývoje. 2. Dokumentace a modely nehrají při vývoji klíčovou roli. Scrum je zaměřen na pravidelné dodávání nasaditelného SW na konci každého sprintu počínaje prvním (což nemusí být pravidlem, někdy se uvádí tzv. sprint 0 bez nasaditelného výstupu). Vychází se z úvahy, že předveditelný a použitelný SW je názornější než obsáhlá dokumentace a modely, které se právě snaží popsat budoucí podobu výsledného díla. 3. Požadavky a prostředí se v průběhu vývoje mění. Toto považujeme nikoliv za podmínku, nýbrž pravidlo aktuálního stavu vývoje IS. Navíc i v případě přesně vyspecifikovaných požadavků bez změn a ve stálém prostředí je výhoda Scrumu v jejich prioritizaci pří vývoji a následném pravidelném nasazování. 4. Přizpůsobování procesu vývoje vede k vyšší kvalitě dodávaného IS. Scrum je evoluční metodika, při které nemusejí být přesně aplikovány veškeré procesy. Podle názoru autorů nemusí být jediným cílem optimalizace procesu vývoje vyšší kvalita dodávaného IS, ale také například vyšší velocity (počet user stories implementovaných během sprintu). 5. Vývojáři mají zkušenosti potřebné k přizpůsobování procesů. Pravdou je, že Scrum počítá se zkušenými členy týmu, kterým dává větší práva a odpovědnosti. Nicméně tato práva a odpovědnosti jsou vždy na týmu jako celku. Navíc se i v rámci Scrumu využívají praktiky z XP jako párové programování, které kromě automatické kontroly kódu přináší i výhodu jednoduššího začlenění nováčků. 6. Viditelnost do procesu a samotného stavu projektu je pouze při ukončení přírůstku a na základě několika metrik. Scrum disponuje několika metrikami, které ukazují stav sprintu i celého projektu v reálném čase. Navíc proces rozpadu user stories na jednotlivé úlohy, které si vývojáři 3

dále bude v práci rozebírána pouze metodika Scrum jako nejvyužívanější agilní metodika 68



sami vybírají a implicitně informují o jejich stavu na denní bázi, vede k možnosti sledování stavu sprintu v reálném čase. 7. Hodnocení vyvíjeného IS a samotného procesu vývoje je neformální. Na konci každého sprintu probíhá prezentace aktuálně vyvinutých funkčností včetně možnosti akceptačních testů. Pokud zadavatel postupně nasazuje jednotlivé iterace do svého prostředí, hodnocení vyvíjeného IS je na všech zainteresovaných uživatelích. Hodnocení optimalizace samotného procesu vývoje je především na týmu v rámci sprint retrospective meeting na konci každého sprintu. 8. Cílem není znovupoužitelné řešení. Metodika Scrum je taktéž využívána pro vývoj produktů, dokonce i mimo ICT [12]. Díky prioritizaci požadavků se většinou nedostane na ty, které mají nejmenší využití, a tím je dosaženo vysoké přidané hodnoty výsledného produktu, který může být nasazen u více zákazníků. 9. Náklady na změny se v průběhu projektu dramaticky nezvyšují. Opět díky priorotizaci je zajištěna dodávka služeb v pořadí podle potřeb zadavatele. Pokud je potřeba změna v již implementované funkcionalitě, zjistí se to daleko dříve než v klasickém přístupu a není potřeba měnit větší část kódu. 10. Software může být vyvíjen přírůstkově. Podle autorů je možné jakýkoliv vyvíjený SW implementovat postupně v iteracích. Navíc Scrum nerozděluje SW podle architektury, nýbrž podle funkčních požadavků. Pokud není možné dodat fungující část IS na konci prvního sprintu, je snaha předat alespoň funkční prototyp. 11. Refaktoring je dostatečná metoda pro úpravy kódu. Scrum využívá pro jakoukoliv úpravu kódu, která nepřináší nové funkčnosti právě refaktoringu. Jedná se o jeden ze základních principů agilního vývoje, který napomáhá udržovat kód jednoduchý a bezchybný. Jiné způsoby úpravy většinou vedou ke složitému a nečitelnému kódu. Jak plyne z komentářů k výše uvedeným podmínkám k zavedení Scrumu, autoři nejsou přesvědčeni, že jejich splnění je potřebné pro zavedení této metodiky. Navíc některé z těchto nutných podmínek jsou v dnešním prostředí spíše pravidlem.

3.2 Základní parametry případové studie Než budou dále navržena řešení udávaných omezení v nasazení Scrumu, je potřeba uvést základní parametry projektu, na kterém bude prezentován přínos této metodiky. Jedná se o projekt implementace Identity a Access Managementu pro společnost Telefónica O2 Czech Republic vyvíjený společností Siemens IT Solutions and Services (SIS). Jeden z autorů zastával na projektu funkci solution architekta a ve druhé fázi taktéž scrum mastera zodpovědného za adaptaci metodiky Scrum. Projekt spočíval v nasazení a customizaci řady produktů DirX, které jsou vyvíjeny mateřskou společností v Německu. Cílem řešení je správa všech zaměstnanců společnosti (cca 18.000) a jejich účtů do většiny informačních systémů ve společnosti. Hlavní výhody výsledného řešení jsou zkrácená doba zřizování přístupů pro zaměstnance, úspora práce administrátorů automatickým vytvářením


69


a rušením účtů v nejdůležitějších IS, centralizovaná správa uživatelů a jejich práv a v neposlední řadě zvýšení bezpečnosti včetně úspěšného splnění SOX auditu. Na straně dodavatele se na projektu podílely tři strany. SIS jako hlavní dodavatel, SIS Německo jako dodavatel základních produktů a Orchitech Solutions jako subdodavatel zodpovědný za uživatelskou aplikaci integrovanou do intranetu zadavatele. Sponzorem projektu na straně zadavatele bylo oddělení IT bezpečnosti. Nicméně velká část požadavků vzešla z oddělení IT provozu, které je hlavním uživatelem systému a v neposlední řadě z oddělení businessu. Jak se během projektu ukázalo, požadavky od těchto tří stran byly dosti odlišné, někdy dokonce protichůdné. Detailní specifikace požadavků, která byla přílohou smlouvy, obsahovala na 130 různých požadavků. Projekt byl rozdělen do dvou hlavních fází. První z nich začala v září 2008 a měla trvat 12 měsíců. Jejím cílem byla první verze řešení, která se měla nasadit do produkčního prostředí. Následná druhá fáze měla trvat 5 měsíců, jejím cílem bylo připojení dalších IS společnosti, jak bylo požadováno ve specifikaci. Projekt měl být tedy ukončen v únoru 2010 úspěšným nasazením druhé fáze. Od začátku projektu byla první fáze řízena standardní rigorózní metodikou, tedy během prvních 3 měsíců byly prováděny analytické schůzky s výsledným obsáhlým dokumentem popisujícím detailní design první části a stručnější design části druhé. Následovala implementace s několika kontrolními termíny pro ukázku klíčových částí řešení. Přesně podle plánu - měsíc před ukončením první fáze - bylo řešení předáno k akceptačním testům. Nicméně tyto testy odhalily velkou řadu nepochopení ve specifikaci, přestože byl předem schválen detailní design. Tyto problémy vedly k prodloužení akceptačních testů a následnému stabilizačnímu provozu. Fáze 1 byla oficiálně akceptována na konci roku 2009 se čtyřměsíčním zpožděním následována dvěmi sadami změnových požadavků. Po těchto zkušenostech zadal řídící výbor projektovému týmu úkol analyzovat příčiny nesplnění termínů a nutnosti navýšení nákladů na změnové požadavky a navrhnout taková opatření, která povedou k úspěšné realizaci druhé fáze projektu. Na základě doporučení dodavatele byla za tímto účelem schválena změna metodiky vývoje a pro druhou fázi projektu byla vybrána metodika Scrum. Tento krok vedl k úspěšné implementaci druhé části řešení ve čtyřech měsíčních sprintech, které probíhaly od června do září roku 2010. Tato fáze byla nakonec akceptována v říjnu 2010 s osmidenním zpožděním. Postup přizpůsobení metodiky Scrum a její výhody budou popsány dále.

3.3 Jak řešit deklarovaná omezení pro nasazení metodiky Scrum V této podkapitole probereme nejdůležitější omezení pro nasazení metodiky Scrum, která jsou popisována v [2] a [7], a která prozatím brání využívání Scrumu pro vývoj komplexních IS. K tomuto účelu bude taktéž využita případová studie popsaná výše.

3.3.1 Vývoj v distribuovaném prostředí Při vývoji velkých komplexních systémů se distribuovanému prostředí nelze ve většině případů vyhnout. V takovém případě již bohužel nestačí základní tabule 70



s rozdělenými úlohami ve sprintu podle jejich stavu a burndown graf pro aktuální přehled o stavu vývoje. Je nutné zvolit některý z produktů umožňující efektivní komunikaci v rámci týmu. Existují specializované produkty se šablonami přímo pro vývoj podle Scrumu (Jira, IBM Rational Team Concert apod.), nicméně na našem projektu se osvědčil jednoduchý nástroj Trac, primárně využívaný jako bug tracing system. Nevyužívali jsme jej jen na evidenci a sledování stavu jednotlivých hlášených chyb, ale také jsme pomocí něj řídili jednotlivé úlohy v rámci sprintu. Současně byl využit i modul wiki jako základní zdroj informací o projektu včetně nejdůležitějších architektonických návrhů. Každý člen týmu tak měl možnost sledovat aktuálně řešené úlohy a případně přidělovat svoje části na dočasnou dobu na jiného člena právě přes tento systém, i když spolu nebyli v jedné místnosti. Další problematickou oblastí v distribuovaném prostředí jsou daily scrums. Tyto schůzky jsou velice důležité a je potřeba je provádět za jakýchkoliv okolností. Pokud není možné zajistit účast všech členů týmu na jednom místě, přicházejí na řadu moderní telekomunikační prostředky. V našem případě se osvědčil komunikační nástroj Skype, přes který byli připojeni členové týmu z jiných lokací. Důležité je dodržovat maximální dobu schůzky, což je v tomto případě složitější. Navíc je problematičtější udržet koncentraci všech členů po celou dobu schůzky. Za tímto účelem je vhodné dodržovat doporučované pravidlo, kdy všichni účastníci mají po celou dobu schůzky stát, i když jsou sami připojeni vzdáleně. Při tomto režimu je omezena jiná práce zúčastněných, kteří se koncentrují pouze na zodpovězení 3 otázek a zbytečně tak neprodlužují celou schůzku. Důležité je také vhodné sladění pravidelného času schůzky. V ideálním případě by měla začínat vždy na začátku pracovního dne, což může být z globálního hlediska problém. V tomto případě musejí členové z lokalit, které mají větší časový posun upravit denní režim tak, aby jejich denní práce v pojetí Scrumu začínala v čas daily scrums.

3.3.2 Využití subdodavatelů Subdodavatelé musí v případě využití Scrumu taktéž adaptovat tuto metodiku. Toto je nutná podmínka, která ovšem nevylučuje využití subdodavatelů obecně. V našem případě reprezentoval subdodavatel samostatný Scrum tým, který pracoval paralelně na stejných user stories v rámci sprintu jako hlavní dodavatelský tým. Subdodavatel by měl mít svého vlastního Scrum mastera dohlížejícího na jejich vlastní proces vývoje. Důležité je vhodně rozšířit povinnosti subdodavatele v back-to-back smlouvě, která se standardně uzavírá, za účelem dodržování všech procesů v rámci sprintu, aby nebyl ohrožen jeho průběh. Další důležitou oblastí je oceňování jednotlivých user stories a jejich rozpad na jednotlivé úlohy mezi subdodavatele. Každý sprint by měl mít stejnou velocity, která musí být v tomto případě rozdělena na jednotlivé dodavatele. Problém může nastat v případě, kdy se v daném sprint backlogu nacházejí úlohy, na kterých není zainteresován subdodavatel v očekávaném rozsahu. Ideálním řešením je možnost dynamicky alokovat množství zdrojů subdodavatele v jednotlivých sprintech, aby nebyl ohrožen výběr user stories do sprint backlogu podle priorit.

3.3.3 Vývoj znovupoužitelných produktů Hlavním cílem Scrumu je dodávat služby aktuálně požadované zadavatelem. Proto je jeho hlavní přínos u zakázkového vývoje IS. Nicméně Scrum se osvědčil i u SYSTÉMOVÁ INTEGRACE 4/2010

71


produktového vývoje, například samotný vývoj DirX produktů společnosti Siemens je založen na této metodice. V takovém případě je product owner hlavní osobou zodpovědnou za vývoj produktu a jeho funkčností. Velice důležitou oblastí je přijímání požadavků na nové funkcionality, které se přidávají do product backlogu a poté do sprint backlogu. Pokud je produkt již nasazen u zákazníků, většina nových požadavků přichází z jejich strany. Všechny tyto požadavky jsou přidány do product backlogu, který musí být před každým sprintem přeprioritizován. U produktového vývoje hraje velkou roli určování priorit daných požadavků, kde hlavním kritériem je počet zákazníků, kteří požadují danou funkcionalitu. Na tomto základě musí product owner rozhodnout, zda se jedná o relevantní požadavek na produkt a bude začleněn do vývoje v rámci dalšího sprintu, nebo zdali jde o tzv. project specific functionality. V tomto případě může být funkčnost vyvinuta, ale není začleněna do samotného produktu. Stinnou stránkou produktového vývoje je nemožnost vytvoření definitivní road mapy produktu v delším horizontu, jelikož se může každý měsíc měnit. To ale na druhou stranu dává produktu větší šanci uspět v konkurenčním prostředí.

3.3.4 Vývoj ve velkých týmech Maximální doporučovanou velikostí jednoho Scrum týmu je 10 členů. Pokud se na vývoji podílí více osob, musejí být rozděleni do více týmů. Jednou ze základních technik je tzv. Scrum of Scrums [3] (obr. 2). Jednotlivé týmy mají každý svého Scrum mastera a dodržují standardní Scrum proces v rámci sprintu. Po daily scrums, které provádí každý tým zvlášť, následuje daily Scrum of Scrums. Této schůzky, která má stejný formát jako základní daily scrum, se účastní zástupci jednotlivých týmů. Odpovědi na základní otázky jsou vztažené na tým, který zastupují. Vyslaní zástupci nejsou zpravidla Scrum masteři, ti se schůzky účastní, pokud počet zúčastněných nepřesáhne 10. Scrum of Scrums schůzek se většinou účastní zástupci, kteří potřebují aktuálně řešit případné závislosti mezi jednotlivými úlohami. Na začátku sprintu jsou to převážně designéři, na konci naopak testeři.

Obr. 2: Scrum of Scrums (zdroj: [9])

72



Délka této schůzky by taktéž neměla přesáhnout 30 minut, ale narozdíl od daily scrums je potřeba vyhradit čas i na případné řešení vzniklých problémů. Současně každý Scrum of Scrums musí mít vlastního Scrum mastera, který zodpovídá za speciální backlog odpovídající issue listu na tradičně vedených projektech. Pokud je na projektu potřeba více Scrum of Scrums (vývoje se účastní více jak 100 osob), analogicky se vytvoří další stupeň, ve kterém je zástupce každého týmu nižšího stupně. To už většinou bývá samotný řídící výbor projektu.

3.3.5 Vývoj kritických systémů Vývoj systémů, na kterých může záviset lidský život, vyžaduje některé speciální praktiky. V těchto případech musí být vývoj podle Scrumu obohacen například o formální specifikaci a následnou formální verifikaci při akceptačních testech. To, v čem je Scrum přínosem u těchto typů systémů, jsou některé jeho základní agilní praktiky. Zejména test-first přístup nutí programátory nejprve napsat jednotkové testy a teprve následně začít implementovat danou funkčnost. Tento přístup odhaluje případné chyby daleko dříve a především nedává programátorům prostor nevědomky měnit přesnou specifikaci požadavku během vývoje. Programátor nejprve musí napsat test přesně odpovídající specifikaci funkčnosti a poté vyvíjet kód, dokud neprojde daným testem. Další významnou praktikou která přináší výhody při vývoji těchto typů systémů je již zmiňované párové programování, kdy druhý vývojář ve dvojici kontroluje kód, který jeho kolega zrovna vytváří..

3.3.6 Vývoj velkých komplexních systémů Možnost vývoje ve velkých případně i distribuovaných týmech byla popsána výše. Dalším často uváděným problémem pro vývoj komplexních systémů pomocí Scrumu je architektura řešení [13] [14]. Ve Scrumu, na rozdíl od rigorózních metodik, není prostor pro detailní návrh celkové architektury před zahájením implementace. Nicméně, jak je diskutováno v [13], i architektura velkých projektů může být navrhována postupně tak, jak se řeší jednotlivé požadavky. Pouze je kladen velký důraz na zkušené architekty. Pro základní návrh architektury řešení slouží sprint 0, ve kterém musí hlavní architekti definovat architektonický základ řešení. Důležité je, že nevytváří prostředí pro splnění všech požadavků na product backlogu, ale pouze těch nejzákladnějších. Cílem je zbytečně nevytvářet design a nutné prostředky pro požadavky, o kterých není jisté, že se budou v budoucnu implementovat. Architekti musí být dále součástí týmu, i když nemusí být využita veškerá jejich kapacita. Detailní analýza a design všech user stories ve sprintu jsou provedeny během prvních dvou dní daného sprintu. Při vývoji pomocí většího počtu Scrum týmů je vhodné provádět pravidelné schůzky architektů z každého týmu, kteří utvoří vlastní Scrum tým. Zejména při fázi plánování sprintu a během jeho úvodu je potřeba řešit globální architekturu nových funkčností a vazby mezi nimi.

3.4 Proces zavedení a přínosy nasazení Scrumu Případová studie popsaná výše vykazuje většinu omezení v nasazení Scrumu diskutovaných v předchozích kapitolách. Na tomto místě bude popsán proces


73


přechodu z rigorózního způsobu řízení první fáze projektu na metodiku Scrum využitou v druhé fázi a důsledky tohoto kroku. Mezi hlavní argumenty dodavatele, díky kterým řídící výbor schválil nasazení metodiky Scrum pro vývoj druhé fáze projektu, patřilo velké množství změnových požadavků během vývoje, neplnění termínů v první fázi, lepší viditelnost do stavu projektu, možnost nasazovat nové funkčnosti po jednotlivých měsících a především prokazatelné nevyužívání některých funkčností, které byly implementované v první fázi. Tento poslední bod je obecný problém, který Scrum pomáhá eliminovat. Podle Chaos Reportu 2009, který vydává The Standish Group, 50% implementovaných funkčností není nikdy použito. Je to dáno tradičním přístupem, kdy zadavatel musí na začátku projektu vyspecifikovat veškeré požadavky včetně tzv. nice to have. První fáze projektu byla definitivně ukončena v dubnu roku 2010 akceptací dvou sad změnových požadavků, nasazením řešení do produkčního prostředí zadavatele a zkušebním provozem. Tedy celých 7 měsíců po plánovaném termínu. Následovat měla druhá fáze projektu, jejíž požadavky byly podmnožinou původní detailní specifikace projektu. Jelikož projekt byl do této doby vyvíjen pomocí rigorózní metodiky, byl již vypracován hrubý design řešení, které se mělo implementovat ve druhé etapě projektu. Projekt byl od začátku smluvně dojednán jako tzv. fix-time, fix-prize, tudíž veškeré úlohy pro druhou fázi již byly v rámci nabídky a pozdější analýzy a designu ohodnoceny v člověkodnech. Řídící výbor souhlasil s dohodou, díky které se mohl obsah řešení druhé fáze projektu měnit podle aktuální potřeby zadavatele. Termín a cena zůstaly zachovány. Prvním krokem přechodu z rigorózní metodiky na Scrum je úvodní naplnění product backlogu. V našem případě se jednalo o sadu požadavků z původní specifikace druhé fáze, které byly upraveny do formy user stories. Současně již měly uvedenu časovou náročnost v člověkodnech, která ovšem byla definována na začátku projektu a v některých případech již neodpovídala získaným zkušenostem během první fáze. Nicméně vydělením pracnosti celé fáze projektu čtyřmi měsíčními sprinty nám vyšla úvodní velocity jednoho sprintu. Dále bylo nutné prioritizovat úvodní backlog pro výběr úloh pro první sprint. Tento krok byl velmi komplikovaný, jelikož byl problém definovat product ownera na straně zadavatele. Jeden z autorů, který zastával roli Scrum mastera, striktně požadoval nominování jedné osoby ze strany dodavatele. Nakonec se tuto pozici podařilo obsadit externím zaměstnancem zadavatele, který do této doby zastával funkci projektového vedoucího se zkušenostmi s vývojem tohoto typu IS. Product owner sestavil funkci vypočítávající prioritu jednotlivých user stories na základě jejich přínosu pro podnikové cíle podle jednotlivých zainteresovaných oddělení (business, bezpečnost, provoz). Pomocí této funkce prioritizoval všechny nově přicházející požadavky během celé fáze vývoje. Jednotlivé sprinty trvaly kalendářní měsíc s tím, že v posledním týdnu probíhaly akceptační testy zadavatele. Tudíž pro samotný vývoj zbývalo průměrně 16 dní. Během akceptačních testů již tým připravoval další sprint. Zejména se jednalo o kvotaci nových požadavků a analytické schůzky za účelem přípravy designu řešení nových úloh. První dva dny sprintu probíhaly verifikační schůzky nad úlohami pro daný sprint, po kterých již byl uzavřen design celého sprintu. Po této verifikaci již zadavatel striktně nesměl měnit zadání úloh v daném sprintu. Pokud takováto situace nastala, přidala se požadovaná změna na product backlog a pokud měla dostatečnou prioritu, byla zahrnuta do následujícího sprintu. První den týdne akceptačních testů byla provedena prezentace nových funkčností (sprint review) a 74



oficiálně zahájeny testy podle testovacích scénářů definovaných na začátku sprintu po verifikačních schůzkách. Pouze jednou za všechny 4 sprinty nedošlo k nasazení přírůstku v první pravidelné odstávce systému po týdnu akceptačních testů. Důvodem byl nadměrný počet reportovaných chyb, který vedl k týdennímu zpoždění nasazení nové verze. Nicméně další sprint probíhal paralelně v definovaných termínech. Jelikož současně s vývojem druhé fáze již byl systém využíván v produkčním prostředí, případné malé množství drobných chyb z testů bylo řešeno standardním problem managementem na projektu a nebránilo nasazení nové verze do produkčního prostředí. Poslední čtvrtý sprint byl akceptován v říjnu roku 2010 s osmidenním zpožděním a po zkušebním a ověřovacím provozu kompletní druhé fáze byl projekt oficiálně akceptován a ukončen v listopadu téhož roku. Projekt byl i přes neplnění termínů v jeho první fázi označen jako úspěšný a nyní probíhá jeho další rozvoj. Největším přínosem nasazení Scrumu na tomto projektu byla jednoznačně možnost definovat obsah měsíčních sprintů před jejich zahájením. Z původní specifikace druhé fáze bylo po čtyřech sprintech implementováno méně než 40% požadavků. Zbývajících 60% nahradily nově vzniklé požadavky během vývoje. Na začátku druhé fáze byl domluven postup výměny úloh na product backlogu v případě nového požadavku, kdy byl vypuštěn jiný požadavek stejné pracnosti s nejnižší prioritou. Postupem času již zadavatel uznal možnost neprázdného product backlogu na konci posledního sprintu a již pouze přidával nově požadované funkčnosti. Základem byla domluvená velocity jednotlivých sprintů vypočítaná podle původní smlouvy. Neoficiálně tedy došlo ke změně smluvního vztahu z fix-time, fix-prize smlouvy o dílo na smlouvu o dodávce jednotlivých přírůstků za fixní cenu s obsahem definovaným na jejich začátku. Nezanedbatelný je na tomto principu i přínos pro dodavatele ve smyslu fakturací po jednotlivých měsících, což má kladný vliv na cashflow. Nutnou podmínkou tohoto režimu je vzájemná důvěra mezi zadavatelem a dodavatelem přinejmenším kvůli akceptaci odhadnutých kvotací nových úloh. Dalším již zmiňovaným přínosem je splnění termínu druhé fáze projektu, čemuž nejvíce napomohlo průběžné akceptování a nasazování jednotlivých sprintů do produkčního prostředí ihned po jejich implementaci. Nikdy nebyl posunut termín prezentace nových funkčností v rámci sprintu, pouze jednou se nestihly implementovat veškeré úlohy na sprint backlogu a 2 s nejmenší prioritou byly přesunuty do dalšího sprintu, kde byly implementovány bez fakturace. Kvalita dodaného IS je těžko porovnatelná mezi oběmi fázemi, množství reportovaných chyb z akceptačních testů je srovnatelné. Nicméně Scrum napomohl k jejich identifikaci daleko dříve než při klasickém vývoji a oprava chyby tak nebyla natolik náročná vzhledem k integraci s dalšími částmi řešení. Ke stejnému závěru dospěla i studie [11] zaměřující se na porovnání kvality vyvíjeného SW mezi rigorózním přístupem a využitím Scrumu.

4. Závěr Projekty vývoje informačních systémů stále vykazují nízkou úspěšnost. Agilní metodiky se s úspěchem používají při vývoji menších systémů v malých týmech, nicméně převážná část IT společností nadále odmítá jejich zavedení u velkých SYSTÉMOVÁ INTEGRACE 4/2010

75


komplexních projektů. Tento článek komentuje omezení pro nasazení agilních metodik, které nalezneme v literatuře, analyzuje je a navrhuje postupy, jak je překonat. Současně ukazuje přínosy nasazení metodiky Scrum na reálném komplexním projektu systémové integrace, což je v rozporu s dosud uváděnými omezeními této metodiky. Projekt byl vyhodnocen jako úspěšný právě díky nasazení Scrumu během jeho vývoje. Tento krok přispěl k plnění jednotlivých termínů projektu, rychlejším opravám reportovaných chyb a zejména k implementaci funkčností, které zadavateli přinesly větší přidanou hodnotu. Díky navrženým postupům adaptace Scrumu při vývoji velkých projektů ukazuje článek širší možnosti využití této metodiky, což může do budoucna napomoci k jejímu masovějšímu využití a na základě toho dosažení vyšší úspěšnosti projektů vývoje informačních systémů. Tento stav by vedl k efektivnějšímu propojení ICT s podnikovou strategií, zejména díky flexibilní dodávce aktuálně potřebných ICT služeb.

Literatura [1]

Voříšek Jiří. Principy a modely řízení podnikové informatiky. Praha : Oeconomica, 2008. 446 s. ISBN 978-80-245-1440-6.

[2]

Buchalcevová Alena. Metodiky budování informačních systémů. 1. vyd. Praha : Oeconomica, 2009. 206 s. ISBN 978-80-245-1540-3.

[3]

Schwaber, K., Beedle, M. Agile Software Development with SCRUM. Prentice Hall, 2001. ISBN 978-0130676344.

[4]

Beck K. et al. Manifesto for Agile Software Development. 2001. [cit. 2010-10-31]. Dostupný z WWW .

[5]

Buchalcevová A., Leitl M.: Průzkum používání agilních metodik v ČR. In Objekty 2006. Praha : PEF ČZU, 2006, s. 125–136. ISBN 80-213-1568-7.

[6]

The State of Agile Development Survey. VersionOne 2009. [cit. 2010-10-31]. Dostupný z WWW http://www.versionone.com/pdf/2009_state_of_agile_ development_survey_results.pdf>.

[7]

Dan Turk, Robert France, Bernhard Rumpe. Limitations of agile software processes. In Proc. of the 3th International Conference on eXtreme Programming and Agile Processes in Software Engineering. 2002. Pages 43-46.

[8]

Peter J. Denning, Chris Gunderson, Rick Hayes-Roth. The profession of IT: Evolutionary System Development. Communications of the ACM, December 2008. Volume 51, Issue 12, Pages: 29-31.

[9]

Oualid Ktata, Ghislain Lévesque. Agile development: issues and avenues requiring a substantial enhancement of the business perspective in large projects. Proceedings of the 2nd Canadian Conference on Computer Science and Software Engineering. 2009. Pages 59-66. ISBN 978-1-60558-401-0

[10] Michael Budwig, Soojin Jeong, Kuldeep Kelkar. When user experience met agile: a case study. Proceedings of the 27th international conference 76



tended abstracts on Human factors in computing systems. 2009. Pages 3075-3084. ISBN:978-1-60558-247-4 [11] Jingyue Li, Nils B. Moe, Tore Dybå. Transition from a Plan-Driven Process to Scrum – A Longitudinal Case Study on Software Quality. Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. 2010. Article No. 13. ISBN 978-1-4503-0039-1. [12] Martin Glas, Sven Ziemer. Challenges for agile development of large systems in the aviation industry. Proceeding of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and pplications. 2009. Pages 901-908. ISBN:978-1-60558-768-4 [13] Dennis Mancl, Steven Fraser, Bill Opdyke, Ethan Hadar, Irit Hadar. Architecture in an agile world. Proceeding of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications. 2009. Pages 719-720. ISBN:978-1-60558-768-4 [14] Philippe Kruchten. Software architecture and agile software development: a clash of two cultures? Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2. 2010. Pages 497-498. ISBN:978-1-60558719-6


77

Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1

Recommend Documents