Mendelova univerzita v Brně Provozně ekonomická fakulta Nástroj pro projektové řízení s podporou agilních metodik vývoje Diplomová práce Vedoucí práce: Ing. Michael Štencl, Ph.D. Bc. Lukáš Krakovský Brno 2012
2
Děkuji Ing. Michaelu Štenclovi, Ph.D. za odborné vedení a cenné rady poskytnuté v průběhu vypracování této diplomové práce. Poděkování za nezaplatitelné poznatky a zkušenosti z praxe patří společnosti Quality Management s.r.o., především Mgr. Michalovi Severinovi, bez kterého by tato práce nemohla vzniknout. Dále děkuji svým nejbližším, kteří mi dodávali neustálou podporu a jejihc pozitivní vliv přispěl ke všem mým úspěchům.
Prohlašuji, že jsem tuto dilomovou práci vyřešil samostatně dle pokynů vedoucího a za použití zdrojů, které jsou uvedeny v závěru práce. V Brně dne 17. května 2012...
5 Abstract Krakovský, L. Tool for project management with support of agile development methodologies. Brno, 2012 This diploma thesis describes the proposal and implementation tool to support of project management with a focus on agile development methodologies, in an environment of a particular company. It analyzes the current situation in the area of agile methodologies and the development process of the company. The design will provided tool to support of project management based on the principles of agile methodologies. It will also allow the user to define her own methodology. And then it will allow the user to define actual implementation. Keywords Agile methodologies, project management, tool, software development, SharePoint, SCRUM Abstrakt Krakovský, L. Nástroj pro projekotvé řízení s podporou agilních metodik vývoje. Brno, 2012 Diplomová práce se zabývá návrhem a implementací nástroje pro podporu projektového řízení se zaměřením na agilní metodiky vývoje, v prostředí konkrétní společnosti. Analyzuje současnou situaci v oblasti agilních metodik a procesu vývoje dané společnosti. V rámci práce bude stanoven návrh nástroje pro podporu projektového řízení vycházející z principů agilních metodik. Dále bude definována vlastní metodika práce, na jejímž základě bude provedena samotná implementace nástroje. Klíčová slova Agilní metodiky, projekotvé řízení, nástroj, vývoj softwaru, SharePoint, SCRUM
OBSAH 6 Obsah 1 Úvod a cíl práce 8 1.1 Úvod.................................... 8 1.2 Cíl práce.................................. 9 2 Současný stav řešené problematiky 11 2.1 Agilní metodiky.............................. 11 2.1.1 Základní charakteristika..................... 11 2.1.2 Porovnání agilních a rigorózních metodik............ 13 2.1.3 Stručný přehled nejběžnejších agilních metodik........ 14 2.2 Společnost Quality Management s.r.o.................. 14 2.2.1 Současná situace v oblasti řízení projektů........... 14 2.2.2 Základní charakteristika metodik SCRUM a KANBAN.... 15 2.2.3 Vývojový tým........................... 17 2.2.4 Používané artefakty....................... 18 2.2.5 Proces a fáze vývoje....................... 20 2.3 Srovnání nástrojů podporující agilní vývoj............... 22 2.4 Důvody vedoucí k implementaci vlastního nástroje.......... 23 2.5 Neformální specifikace.......................... 24 3 Metodika práce 26 3.1 Formální specifikace systému...................... 26 3.1.1 Vymezení uživatelských rolí................... 26 3.1.2 Funkční požadavky........................ 26 3.1.3 Nefunkční požadavky....................... 30 3.2 Metodika vlastního vývoje........................ 32 3.3 Implementační prostředky........................ 34 3.3.1 ASP.NET............................. 38 3.3.2 Microsoft SharePoint Designer 2007............... 38 3.3.3 Microsoft Visual Studio 2008.................. 39 3.3.4 Microsoft Visio 2010....................... 39 3.3.5 Programovací jazyk C#..................... 39 3.3.6 Microsoft Reporting Services.................. 39 3.3.7 MS Windows Server....................... 40 3.3.8 UML................................ 40 3.3.9 Selenium............................. 40 4 Vlastní práce 41 4.1 Struktura aplikace............................ 41 4.1.1 Datová vrstva........................... 41 4.1.2 Aplikační vrstva......................... 43 4.1.3 Uživatelské rozhraní....................... 43 4.2 Implementace systému.......................... 49
OBSAH 7 4.2.1 User Dashboard.......................... 49 4.2.2 Projekty.............................. 50 4.2.3 Sprinty.............................. 51 4.2.4 Požadavky............................ 54 4.2.5 Úkoly............................... 56 4.2.6 Kalendář............................. 56 4.2.7 Informace a upozornění..................... 57 4.2.8 Osobní poznámky........................ 58 4.2.9 Číselníky............................. 58 4.2.10 Reporting............................. 59 4.2.11 Verzování dokumentů a položek................. 60 4.2.12 Knihovna dokumentů...................... 60 4.2.13 Správa systému.......................... 61 4.2.14 Uživatelské role.......................... 62 4.2.15 Zabezpečení aplikace....................... 62 4.2.16 Testování............................. 63 5 Diskuze 64 6 Závěr 66 7 Literatura 67
1 ÚVOD A CÍL PRÁCE 8 1 Úvod a cíl práce 1.1 Úvod V současné době je tržní prostředí charakteristické svou dynamikou a rychlou proměnlivostí. Ekonomika je stále více orientovaná na znalosti, kratší životní cyklus produktu, inovace a rychlý technologický pokrok. Na změny kolem nás je třeba nejen reagovat, ale dokonce změny vyvolávat, a tak získat náskok před konkurencí. V oblasti informačních technologií to znamená, že do jejich vývoje a provozu je třeba stále častěji zapracovávat různé změny. Klíčovou oblastí IT je tvorba softwaru. Různé postupy a přístupy k vývoji softwaru, se rozvíjely a nadále rozvíjejí ruku v ruce s rozvojem využívaných technologií. Důležitost a význam správně zvoleného přístupu pro vývoj daného softwaru, potvrzují výsledky z průzkumu v projektu CHAOS 1 roce 2009 a výsledky z průzkumu realizovaného Scottem W. Ambrelem 2 v roce 2010. V případě prvně zmíněného průzkumu je neúspěch u projektů více jak 65% (bez návratnosti na konkrétní metodiku). Jedná se především o projekty, které nesplnily následující tři kritéria: projekt nebyl dokončen ve stanovený čas, nebyl dokončen v rámci stanoveného rozpočtu a dokonce u některých projektů nebyly splněny ani požadované vlastnosti na systém. Ve druhém případě průzkum uvádí, že za neúspěch většiny projektů mohou rigorózní metodiky a řízení projektů způsobem ad-hoc. V současných podmínkách přestávají vyhovovat tradiční rigorózní metodiky vývoje a stále více se začínají prosazovat metodiky agilní. Jedná se zejména o metodiky založené na myšlence, kdy hlavní cestou k úspěchu, je vyvinout daný systém co nejrychleji, řešení prezentovat zákazníkovi a na základě zpětné vazby jej patřičně upravit. Především u rozsáhlejších projektů se software vyvíjí převážně týmově, musí být kvalitnější, musí být k dispozici rychleji a vyžaduje údržbu i v době dávno po svém nasazení. Všechny tyto aspekty výrazně ovlivňují celý proces vývoje a požadavky na něj. Většina firem zabývající se vývojem softwarových produktů již před časem pochopila, že bez určitého řádu, vymezených pravidel a určitých firemních postupů je vývoj většinou velmi neefektivní. Společně s rostoucí popularitou agilních metodik vývoje se pro jejich podporu na trhu objevuje stále více softwarových aplikací na podporu řízení projektů, ať už distribuovaných komerčně či zdarma. Agilní vývoj nutně nevyžaduje používání podpůrných nástrojů pro řízení projektů, ale v případě správně zvoleného nástroje, který danou metodiku efektivně podporuje je tato kombinace pro většinu firem velkým přínosem a výhodou. Firmy, vyvíjející software tak stojí před nelehkým úkolem, vybrat a následně zavést metodiku vhodnou pro vlastní specifické prostředí, případně zvolit efektivní nástroje pro jejich podporu. Zavedení správné metodiky v kombinaci 1 Výsledky průzkumu dostupné z http://www1.standishgroup.com/newsroom/chaos_2009.php 2 Výsledky z průzkumu dostupné z http://www.ambysoft.com/surveys/success2010.html
1.2 Cíl práce 9 s vhodně zvolenými podpůrnými nástroji, může pro danou firmu znamenat značný přínos jak z krátkodobého tak i dlouhodobého hlediska. Jednou z takových firem je i společnost Quality Management s.r.o., která se zabývá především vývojem software, zejména pak tvorbou informačních systémů a s problematikou vývoje se potýká dnes a denně. V důsledku dynamického rozvoje zakázek, časové náročnosti řešených projektů a rostoucímu počtu nových požadavků, se ve zmíněné společnosti začaly postupem času, vyskytovat v rámci řešených projektů znepokojují problémy. Problémy spočívaly především v prodlevách při dodání smluvených funkcionalit, snížení kvality implementovaných komponent, nečekaném nárůstu rozsahu práce a přetěžování zaměstnanců. Vzniklá situace přivedla vedoucí pracovníky společnosti k rozhodnutí, provést analýzu současné situace v oblasti vývoje. Následně navrhnout vhodné prostředky, které napomohou k zlepšení situace v oblasti vývoje software a celkově ve způsobu řízení projektů. Na základě provedené analýzy byly v rámci vývoje zavedeny principy agilních metodik. S ohledem na množství požadavků a situace kdy je řešeno více projektů současně, vedení společnosti rozhodlo o zavedení podpůrného nástroje, který by celý proces vývoje usnadnil. Podpůrný nástroj by měl do procesu vývoje vnést především lepší přehled a kontrolu nad současnou situací, zároveň by měl podporovat principy a pravidla agilních metodik. Vedení společnosti, nejdříve uvažovalo o nasazení nějakého již existujícího nástroje. Následovalo období, kdy společnost ve svém prostředí testovala různé nástroje vhodné pro daný účel, ovšem z různých důvodů jako např.: nedostatek vhodných funkcí, neintuitivní uživatelské rozhraní, nebo nevhodná licenční politika, došlo vedení společnosti k závěru, že nejlepším řešením bude navrhnout a implementovat nástroj vlastní. Konkrétní důvody pro implementaci vlastního nástroje a celkový rozbor vzniklé situace budou blíže specifikovaný v kapitole popisující současný stav řešené problematiky. Požadovaný nástroj by měl být především jednoduchý, přehledný, nepřetržitě dostupný a hlavně schopný podporovat vývojové procesy dané společnosti. Právě problematika související s návrhem a implementací nástroje pro podporu projektového řízení s podporou agilních metodik vývoje, bude hlavním tématem této diplomové práce, jejíž konkrétní cíle budou detailně specifikovány v následující kapitole. 1.2 Cíl práce Hlavním cílem diplomové práce, je implementovat pro společnost Quality Management s.r.o., nástroj podporující projektové řízení se zaměřením na agilní metodiky vývoje. Pro dosažení stanoveného cíle, bude řešení obsahovat analýzu současného stavu v oblasti vývoje zmíněné společnosti. Na základě identifikovaných klíčových vlastností procesu vývoje a analýze funkcionalit dostupných nástrojů v oblasti projektového řízení, budou definovány formální požadavky na vyvíjený nástroj. Dále bude stanovena vlastní metodika pro tvorbu výsledné aplikace, ze které bude vycházet
1.2 Cíl práce 10 samotná implementace nástroje pro podporu projektového řízení. Výsledné řešení bude posléze ověřeno základní sadou automatizovaných testů. Závěrem práce budou zhodnoceny přínosy, ale i nedostatky implementovaného nástroje, jeho využití v praxi a možnosti dalšího rozvoje. Struktura diplomové práce se bude kromě úvodu a závěrečného hodnocení, skládat ze tří hlavních částí. V první části bude charakterizován současný stav v oblastech řešené problematiky. Druhá část bude věnována vlastní metodice vývoje, nástrojům využitých pro dosažení stanoveného cíle a formální specifikaci požadavků na vyvíjený nástroj. Třetí část prezentuje dosažené výsledky a tím poskytne základ pro závěrečné zhodnocení výsledného řešení.
2 SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY 11 2 Současný stav řešené problematiky 2.1 Agilní metodiky Název agilní metodiky vznikl z anglického slova Agile, který podle slovníku cizích slov znamená čilý, aktivní, horlivý. Agilní neboli lehké metodiky se začaly objevovat v polovině 90. let 20. století jako reakce na rigorózní neboli těžké metodiky, které bývaly často kritizovány za jejich obtížnou regulovanost a především pomalost. Začátkem roku 2001 v americkém Utahu, sepsalo 17 softwarových inženýrů dokument, nesoucí název Manifest agilního vývoje softwaru. Hlavním důvodem vzniku manifestu, bylo jasné vymezení definice a přístupy vývoje známé dnes pod názvem Agilní metodika vývoje software. Rozvojem a propagací agilních přístupů se zabývá, především nezisková organizace Agile Aliance, kterou založili někteří z autorů manifestu. Organizace Agile Ailance pořádá po celém světě konference zabývající se problematikou agilních metodik, z nichž za nejvýznamnější lze považovat konferenci Agile. V současnosti můžeme agilní metodiky vnímat jako plnohodnotný a úspěšný způsob vývoje softwaru a lze předpokládat, že do budoucna se bude tento trend dále rozvíjet. 2.1.1 Základní charakteristika V dnešní době existuje mnoho různých agilních metodik. Všechny vycházejí ze stejných principů: rychlý vývoj, kolektivní práce, spolupráce v týmu, komunikace se zákazníkem a především schopností přizpůsobit se během celého životního cyklu projektu. Agilní metodiky většinou rozdělují jednotlivé požadavky na menší části s minimálním plánováním a dlouhodobé plánování přímo nezahrnují. Harvey Maylor ve své knize uvádí: kvalitní plánování je z dlouhodobého hlediska nemožné a spolehlivé jsou pouze předpovědi na krátký časový rozsah (Maylor, 2010). Využívají zejména iterativního přístupu vývoje s velmi krátkými iteracemi, které trvají přibližně od jednoho týdne do jednoho měsíce. Každá z iterací zahrnuje tým lidí pracujících na vývoji včetně plánování, analýzy požadavků, návrhu, kódování, testování funkcionalit a přijímacích testů. Na závěr iterace je nová verze produktu demonstrována zákazníkovi, který poskytne zpětnou vazbu. Zpětná vazba od zákazníka minimalizuje riziko v případě, že prezentovaná část projektu dopadne neúspěchem. Pokud taková situace nastane je možné dané nedostatky pozměnit a rychle se přizpůsobit požadovaným změnám. Dalším úkolem zákazníka nebo jejich zástupců je spolupráce na dokumentaci a tvorbě požadavků. Jedna iterace nemusí přinést mnoho nové funkcionality, principem je aby vznikla nová verze s minimálním počtem chyb a následně po jejím odprezentování byla uznána zákazníkem. V agilních metodikách složení týmu nebere příliš velký zřetel na korporační hierarchii. Tým se vytváří většinou podle pravidel použité metodiky a její členové
2.1 Agilní metodiky 12 převezmou odpovědnost za úkoly, které musí být vykonány. Principem je, že komunikace v týmu by měla probíhat převážně tváří v tvář. Celý tým by měl pracovat na jednom stanovišti nedaleko od sebe, tím se komunikace výrazně zlehčuje. Každý tým by měl mít ve svém středu osobu, která reprezentuje zákazníka, aby vývojáři měli k dispozici odpovědi na své případné otázky týkající se vyvíjeného systému. Většina agilních metodik využívá rutinu a formální denní sešlosti mezi jednotlivými členy týmu. V krátkém briefingu si členové týmu navzájem oznamují, jakou činnost vykonali od poslední schůzky, co mají v plánu dál a jestli narazili na nějaké problémy. Výhodou častých briefingů je možnost řešit problémy téměř okamžitě potom, co nastanou. Dalším významným faktorem je psychologie práce ve skupině. Agilní metodiky považují motivaci lidí ve skupině za klíčový předpoklad pro úspěch celého projektu. Proto se agilní metodiky zaměřují především na pracovní prostředí, zajištění podpory pro všechny členy týmu a jejich komunikaci jak mezi sebou tak i se zákazníkem. Z pohledu agilních metodik mají lidé větší význam, než dodržené postupy, produkované dokumenty nebo používané nástroje. Václav Kadlec ve své knize Agilní programování Metodiky efektivního vývoje software uvádí, že mezi zásadní principy agilních metodik, patří (Kadlec, 2004): Iterativní a inkrementální vývoj s krátkými iteracemi: plán je sestaven tak, že nové funkce se dodávají často (i denně). Zákazník je průběžně konfrontován s novými konfiguracemi. Výhodou tohoto přístupu je skutečnost, že zákazník pořád vidí, v jakém stavu je vývoj a na jakých funkcionalitách tým zrovna pracuje. Nemůže se tak stát, že by na konci dostal něco jiného, než očekává. Kromě tohoto nedostane výrobek až na samotný konec ve formě velkého třesku. Důraz na přímou, osobní komunikaci v týmu: stejně jako v jiných sociálních skupinách, i v pracovních týmech je původcem nejzávažnějších problémů nefungující komunikace. Agilní přístupy se pokoušejí integrovat komunikaci přímo do procesu jako jeho nedílnou součást (časté schůzky, párové programování apod.). Výhodou je dřívější odhalení problémů, a to jak uvnitř týmu (analytik se s programátorem nemá rád), tak i v samotném projektu (programátor má ve svém modulu chybu, ale bál se jí přiznat kvůli strachu z ponížení před ostatními). Nepřetržité sepjetí a komunikace se zadavatelem, resp. uživatelem: zákazník by ideálně měl být členem vývojového týmu, měl by komunikovat s vývojovým týmem, spolupodílet se na návrhu a spolurozhodovat o testech. Rigorózní, opakované, průběžné automatizované testování: vzhledem k častým změnám systému je nutné průběžně ověřovat jeho správnost. Testy by měly být automatizované a měly by být napsány dokonce před implementací testovaných částí. Vzhledem ke zrychlovaným fázím analýzy a návrhu
2.1 Agilní metodiky 13 je testování zhola nezbytné a je jediným jistým prostředkem zachování kvality aplikace. 2.1.2 Porovnání agilních a rigorózních metodik Jak již bylo zmíněno v úvodu této práce, dle výsledku průzkumu realizovaného Scottem W. Amblerem, softwarové projekty vyvíjené tradičním způsobem selhávají častěji, než projekty vyvíjené za pomoci metodik agilních. Jednou z hlavních příčin neúspěchu může být, že většina tradičních metodik příliš spoléhala na schopnost definovat přesně své požadavky již na první schůzce a dále pak víra v to, že klient v průběhu realizace nezmění své požadavky. Vývojové týmy se následně velmi často setkávali s potížemi ve fázi předvádění produktu klientovi, kdy považují daný projekt za hotový. Konkrétně se jedná o moment, kdy ze strany klienta vyzní slova takto jsme si to rozhodně nepředstavovali. V případě že tato situace opravdu nastane, projekt se rázem může vrátit zpět na začátek vývoje, jenže s výraznou změnou tým již vyčerpal většinu přidělených finančních prostředků a zároveň také času během, kterého měl být projekt dokončen. Hlavní posun agilních metodik od rigorózních spočíval v odlišném přístupu k procesu samotného vývoje. Zatímco rigorózní metodiky kladly velký důraz na tzv. těžké procesy jako např.: definice formálních náležitostí projektu, tvorba dokumentace, detailní specifikace požadavků v začátcích vývoje. Na druhé straně agilní přístupy nabízejí spíše jednoduché techniky a nástroje, zabývající se převážně problematikou komunikace, spolupráce, flexibilní odezvou na změnu a efektivitou samotného vývoje. Obrázek 1: Srovnání agilních a tradičních přístupů
2.2 Společnost Quality Management s.r.o. 14 2.1.3 Stručný přehled nejběžnejších agilních metodik Během let bylo vyvinuto velké množství agilních metodik, řídících se na základě principů Manifestu agilního vývoje. Nové metody se neustále vyvíjí, některé jsou původní, jiné vycházejí ze starších agilních metodik. Mezi nejznámější agilní metodiky bych zařadil následující výčet: SCRUM Development Process Extrémní programování (Extreme Programming, XP) Adaptivní vývoj softwaru (Adaptive Software Development) Vlastnostmi řízený vývoj (Feature-Driven Development) Lean Development Crystal metodiky (Crystal Methodologies) Dynamic System Development Method Testy řízený vývoj (Test-Driven Development) 2.2 Společnost Quality Management s.r.o. Společnost Quality Management s.r.o., je mladá a moderní softwarová firma, která se zabývá především vývojem informačních systémů a poskytováním poradenských služeb související s řízením podniku a oblastí kvality. Společnost byla založena v roce 2010 a v současnosti působí především v České republice. Hlavní sídlo společnosti se nachází v Brně. Ve společnosti pracuje v současné době 7 zaměstnanců. Především v důsledku dynamického rozvoje zakázek a časové náročnosti řešených projektů lze v blízké budoucnosti očekávat nárůst zaměstnanců, především v oblasti vývoje. Firma se zabývá primárně implementací podnikového ERP systému DIRECTIS, který nabízí jako svůj hlavní produkt, ale svým klientům poskytuje také možnost zakázkového vývoje informačních systému šitých na míru. Všechny softwarové produkty společnosti jsou postaveny na platformě technologie Microsoft SharePoint, díky čemuž je zajištěná také plná integrace s nástroji Microsoft Office. Společnost se snaží klást velký důraz na sledování aktuálních trendů v oblasti své činnosti, pracovat na neustálém zlepšování svých produktů a vycházet jak ze zkušeností vlastních, tak svých klientů. 2.2.1 Současná situace v oblasti řízení projektů V nynější době řeší společnost Quality Management s.r.o. jeden hlavní projekt a to vývoj ERP systému DIRECTIS, jehož moduly se neustále rozrůstají a práce na projektu se odhaduje minimálně na další rok. Současně probíhají v rámci možností další zakázkové projekty s různou časovou náročností na implementaci.
2.2 Společnost Quality Management s.r.o. 15 Již v úvodu práce bylo nastíněno, že se společnost začala koncem roku 2011 potýkat s určitými problémy v oblasti vývoje. Problémy vznikly především na základě dynamického rozvoje zakázek, větší časové náročnosti řešených projektů a rostoucímu počtu nových požadavků. Vzniklá situace vedla ke: snížení kvality a zvýšení chybovosti implementovaných komponent, prodlevám při dodání smluvených funkcionalit, neočekávanému růstu rozsahu práce, přetěžování zaměstnanců. Zmíněné důvody přiměly společnost k rozhodnutí změnit a zmodernizovat proces vývoje. Začátkem roku 2012, byly na základě předcházející analýzy aplikovány do procesu vývoje principy metodiky SCRUM v kombinaci s prvky metodiky KANBAN. Se zavedením nové metodiky se situace v oblasti projektového řízení sice zlepšila, ovšem i nadále přetrvávaly určité problémy. Problémy spočívaly v tom, že se v některých chvílích pracovalo současně na více projektech a množství požadavků bylo stále velké, stával se proces vývoje místy nepřehledný. V tomto období využívala společnost pouze vlastní, jednoduchý webový nástroj, který umožnil evidovat požadavky a dokumenty související s vývojem. Bohužel možnosti nástroje neodpovídaly náročnosti řešených projektů a principům agilního vývoje. Například (Rosenau, 2010) uvádí: Používat počítačový software k řízení projektů není totéž jak efektivně řídit projekt. Nicméně s pomocí tohoto softwaru může vývojový tým odvést lepší práci. S ohledem na zmíněné aspekty, se vedení společnosti rozhodlo pro zavedení kvalitního nástroje, který by podporoval celý proces vývoje a zároveň principy využívaných agilních metodik SCRUM a KANBAN. Vedení společnosti nejdříve uvažovalo o nasazení již existujícího nástroje. Následovalo období, kdy společnost vybrané nástroje testovala ve svém prostředí, ale v závěru došla k názoru, že žádný z poskytovaných nástrojů přesně neodpovídá požadavkům společnosti. Výsledky z analýzy nástrojů a konkrétní důvody vedoucí k implementaci vlastního nástroje budou uvedeny v následujících kapitolách 2.3 a 2.4. Nejdříve však budou detailně představeny principy vybraných agilních metodik v návaznosti na prostředí procesu vývoje uvedené společnosti. 2.2.2 Základní charakteristika metodik SCRUM a KANBAN SCRUM Development Process SCRUM Development Process patří do rodiny agilních metodik, jejímž hlavním cílem je především zvýšení efektivity při vývoji softwaru. První nástin metodiky SCRUM byl představen Kenem Schwaberem a Mikem Beedlem v roce 1995, ovšem oficiálního představení se dočkal až v roce 2002. Samotný název SCRUM není zkratkou, jak by mohlo vyplívat z názvu často uváděného velkými písmeny, ale výraz používaný v Rugby. Vznik názvu popsal ve své knize Václav Kadlec následovně. ázev me-
2.2 Společnost Quality Management s.r.o. 16 todiky vznikl a anglického slova Scrum, jehož význam spadá do rugby a označuje skrumáž, mlýn, projevující se kumulací několika (typicky mnoha) hráčů na jednom místě za účelem společného dotlačení míče na požadovanou pozici. Paralela s vývojem softwaru je jednoznačná: cílem vývojového týmu není nic jiného než dotlačení míče na požadovanou pozici, tedy dokončení aplikace v podobě, jakou vyžaduje zákazník. Celý vývojový proces si v metafoře metodiky SCRUM lze představit jako rugbyový zápas a vítězstvím není nic jiného nežli spokojený zákazník (Kadlec, 2004). Scrum ve své podstatě není metodika, ale pouze rámec (framework), na jehož základě může vývojový tým použít techniky a procesy, které se mu již osvědčili (Schwaber, 2010). Může se tedy zdát, že existuje mnoho různých variant SCRUMU, v podstatě se však jedná o stále stejný SCRUM Framework, který používá pouze jiné vnitřní procesy a techniky. SCRUM můžeme považovat převážně za manažerskou metodiku, rozhodně se nejedná o žádný konkrétní návod jak programovat a nedefinuje konkrétní postupy či nástroje. Zabývá se převážně problematikou komunikace, spolupráce, flexibilní odezvou na změnu a efektivitou samotného vývoje. Stejně jako většina předchozích metodik i SCRUM vychází z principů: flexibility, iterativního vývoje, pravidelných dodávek prototypů nebo částí aplikace, následným sbíráním zpětné vazby od zákazníka a snahou adekvátně reagovat na změny během průběhu vývoje. Především komunikace a dobré vztahy se zákazníkem mají na agilní proces vývoje velmi pozitivní vliv (Aalst a kol., 2009). SCRUM v kombinaci s metodikou KANBAN Počátky metodiky KANBAN koření podobně v Japonsku. KANBAN je metodika, která předepisuje naprosté minimum technik a tím ponechává vývojovému týmu maximální volnost. Metodika KANABAN vychází podle (Kniberg, Skarin 2010) ze tří základních vlastností: Vizualizace pracovního toku tzv. Workflow - Požadavky na systém se rozepíší na jednotlivé úkoly. Úkoly se napíšou na karty a posléze přilepí na tabuli či nástěnku. Úkoly jsou na tabuli členěny do sloupců podle jednotlivých fází pracovního toku. Přiřazení limitů pro jednotlivé fáze pracovního toku. Měření průměrného času dokončení jedné položky tzv. Lead time. U metodiky KANBAN se vztahuje omezení na množství práce k dané fázi pracovního postupu, oproti tomu SCRUM jej vztahuje k aktuální iteraci. Mezi další rozdíly patří zejména absence mnohých prvků vyskytující metodiky SCRUM v metodice KANBAN, jedná se např. o: časové odhady, určení priority u úkolů, definice rolí (KANBAN nedefinuje žádné role).
2.2 Společnost Quality Management s.r.o. 17 Metodiku KANBAN je vhodné využít především na projekty, u kterých lze dopředu předvídat velmi častou a rychlou úpravu požadavků. Metodika SCRUM neumožňuje změnu požadavků v průběhu sprintu, ale až po jeho dokončení, tím je zajištěna nerušenost a soustředěnost týmu. Obvykle je tato vlastnost velmi ceněna, ale v případě některých projektů, může být spíše na škodu. Velmi často se při spojení zmíněných metodik využívá aspekt, kdy je v rámci sprintu umožněno měnit požadavky. Velmi oblíbenou technikou KANBANU, která je v rámci metodiky SCRUM velmi populární, představuje lepení karet s úkoly na tabuli či nástěnku rozdělenou na sloupce. Rozčlenění sloupců může být kupříkladu následující: To-Do, probíhající, hotové. Tato technika velmi zvyšuje přehlednost řešených požadavků. 2.2.3 Vývojový tým Vývojový proces společnosti rozlišuje ve svém pracovním týmu celkem šest specifických rolí vycházejících z principů metodiky SCRUM. Následující popis jednotlivých rolí vychází od autorů metodiky tak, jak uvedli v (Schwaber, Beedle 2010). Scrum Master Scrum Master je odpovědný za celý proces vývoje. Dohlíží na dodržování pravidel a principů v souladu s praktikami metodiky Scrum. Má na starost komunikaci s vývojáři, zákazníkem a managementem. Hlavním úkolem Scrum Mastera je zajistit plynulý proces vývoje a popřípadě odstranit vzniklé překážky. Pokud Scrum Master není schopen vzniklé problémy odstranit sám, musí zajistit kompetentní osobu, která daný problém dokáže odstranit. Vlastník produktu (Product Owner) Vlastník produktu je role stojící na rozhraní někde mezi zákazníkem a dodavatelem. Do role je zvolen na základě společného rozhodnutí Scrum Mastera, Zákazníka a Managementu. Má hlavní slovo při rozhodování o položkách v Product Backlogu. Zodpovídá především za aktuální stav Product Backlogu a zajišťuje jeho dostupnost ostatním členům vývojového týmu. Vlastník produktu by měl striktně dodržovat zákaz přidávání položek v průběhu sprintu. Požadavky na systém se sice mohou často měnit, nebo přidávat ale pouze v rámci Product Backlogu, když nejsou zařazeny v probíhajícím sprintu. Scrum tým (Scrum Team) Scrum tým je hlavní vývojová síla, která především implementuje požadované funkcionality. Tým by se měl sám organizovat a jeho hlavním úkolem je splnit cíle daného sprintu v určeném čase. Dalšími úkoly týmu je spoluúčast na výběru požadavků z Product Backlogu daného sprintu, odhad pracnosti a času potřebného k implemen-
2.2 Společnost Quality Management s.r.o. 18 taci dané vlastnosti, sestavení časového plánu řešení a nacházení překážek narušující průběh vývoje. Zákazník (Customer) Zákazník nebo se podílí především na sestavování seznamu položek v Product Backlogu. Dalším jeho úkolem je poskytnout zpětnou vazbu na základě prezentace systému či některé jeho části. Management Mezi hlavní kompetence Managementu patří především obchodní jednání a uzavírání smluv. Svou roli hraje také při důležitých rozhodnutí, které mohou ovlivnit celý projekt. Podílí se na sestavování požadavků, cílů celého projektu i jednotlivých etap. 2.2.4 Používané artefakty V rámci procesu vývoje, využívá zmíněná společnost určité artefakty, které vychází z principů metodiky SCRUM a detailně jsou představeny v následujícím textu. Sprint Sprint je základní stavební jednotkou metodiky SCRUM a první typ iterace. Délka trvání jednoho sprintu se ve v procesu vývoje uvedené společnosti povětšinou pohybuje v rozmezí jednoho týdne až jednoho měsíce. Celkový počet sprintů se různí v závislosti na projektu. Každému sprintu předchází tzv. Sprint Planning Meeting, kde se definují úkoly a cíle pro daný sprint. Podle (Kniberg, 2007) by měl výstup plánovací schůzky obsahovat následující výčet prvků: cíl sprintu (slovní popis hlavního požadovaného výsledku), sprint backlog (požadavky, které se budou v rámci sprintu řešit), datum zahájení a ukončení sprintu, termín prezentace, čas a umístění pravidelných denních schůzek, složení vývojového týmu. Úkoly se určí na základě požadavků umístěných v Product Backlogu. Jednotlivé požadavky jsou vybírány podle logických celků a především priority určené zákazníkem. Požadavky vybrané do daného sprintu jsou následně přesunuty do Sprint Backlogu. Vývojový tým následně odhaduje pracnost jednotlivých úkolů a naplánuje průběh prací. Na konci sprintu se opět koná schůzka celého týmu Sprint Review, kde se proberou události vzniklé v průběhu sprintu, požadavky které se podařilo splnit popřípadě
2.2 Společnost Quality Management s.r.o. 19 nesplnit a důvody vedoucí k vzešlým situacím. Nejdůležitější částí závěru každého sprintu je prezentace dosažených výsledků a to jak vzájemně v rámci vývojového týmu tak především zákazníkovi. Product Backlog Product backlog v sobě soustředí požadavky na funkcionalitu systému. Zodpovědnost za Product Backlog nese především vlastník produktu (Product Owner). Product Backlog se v průběhu celého vývoje může měnit. Zákazník vždy přiřazuje definovaným požadavkům určitou prioritu. Z důvodu přehlednosti je Product Backlog roztříděn podle logických a funkčních celků. Pořadí v jakém budou požadavky v jednotlivých sprintech řešeny, určuje vývojový tým ve spolupráci se Scrum Masterem s přihlédnutím na prioritu určenou zákazníkem. Product backlog by měl podle (Cohn, 2009) dodržovat zásady DEEP: Detailed appropriately spolu s rostoucí prioritou položek, a tedy i zvyšující se pravděpodobností jejich brzkého zařazení do Sprintu, roste i podrobnost rozpracovanosti. Z počátku se jedná o rozsáhlé uživatelské příběhy tzv. eposy ty se postupně s rostoucí prioritou zpřesňují. Estimated každé položce je určen předběžný odhad pracnosti a nejen seznam pracovních činností. Emergent Product Backlog se mění během celého průběhu vývoje. Prioritized položky, které by měli přinést systému největší hodnotu, mají nejvyšší prioritu. Release Backlog Release Backlog seskupuje požadavky z Product Backlogu, potřebné pro určité vydání tzv. Release. Sprint Backlog Na začátku každého sprintu jsou vybrány požadavky, které budou v rámci tohoto sprintu řešeny a jsou přeneseny do Sprint Backlogu. Položka přiřazená do Sprint Backlogu se následně rozpracuje do větších detailů a je jí přiřazen určitý časový odhad. Výhodou Sprint Backlogu je detailnější pohled na poměr doposud odvedené či naopak neodvedené práce. Daily Scrum Daily Scrum je denní schůzka týmu tzv. Scrum Meeting. Schůzku vede Scrum Master a účastní se jí celý vývojový tým. Na každé schůzce jsou jednotlivým členům týmům pokládaný tři základní otázky.
2.2 Společnost Quality Management s.r.o. 20 Co jsi včera udělal? Co máš v plánu dělat dnes? Vyskytly se nějaké problémy? Díky takto krátkým iteracím je celý tým neustále informován o dosavadním průběhu vývoje a je schopen rychle reagovat na vzniklé problémy. Doba trvání jedné schůzky by neměla přesáhnout více jak hodinu času. V rámci společnosti není striktně dodržováno pravidlo každodenní schůzky, ale schůzky jsou svolávány na základě požadavku Scrum Mastera či členů Scrum týmu. User Story User story je požadavek, ve kterém zákazník jednou nebo více větami definuje určitou vlastnost, které chce v daném systému dosáhnout. Všechny User Stories jsou dále zpracovány Vlastníkem produktu s možnou konzultací ostatních členů vývojového týmu a posléze zařazeny do seznamu Product Backlog. Obrázek 2: Iterace v rámci metodiky SCRUM (Buchalcevová, 2009) 2.2.5 Proces a fáze vývoje Samotný proces vývoje je postaven především na základě metodiky SCRUM a dle jejich principů rozděluje proces vývoje na tři hlavní fáze: předehra, hra a dohra. První a třetí fáze probíhají lineárně a prostřední fáze hra, se iterativně opakuje v rámci jednotlivých sprintů.
2.2 Společnost Quality Management s.r.o. 21 Předehra Fáze předehry se dělí na dva hlavní kroky: prvním je Plánování a druhým je Návrh a architektura. Plánování v sobě zahrnuje tvorbu Product Backlogu, obsahujícího všechny doposud známe požadavky na systém. Požadavky mohou být definovány zákazníkem, nebo členy vývojového týmu. Zákazník přiřadí prioritu definovaným požadavkům a vývojový tým následně odhadne úsilí potřebné k jejich implementaci. Tyto odhady jsou v počátcích většinou nepřesné, všechny hodnoty se v průběhu vývoje upravují a zpřesňují podle aktuální situace. Požadavky se následně setřídí podle logických a funkčních celků v závislosti na jejich určené prioritě. Mezi další úkoly procesu plánování patří: sestavit projektový tým, definovat vývojové nástroje, vymezit zdroje a určit postup pro schválení výsledného produktu. Návrh a architektura definuje vytvářený systém na vysokém stupni abstrakce. Jako základ systému je možné považovat již vytvořený Product Backlog. Provádí se analýza, ve které se řeší především: prostředí zadavatele, jeho obchodní procesy a studium všech relevantních dokumentů. Na závěr jsou tvořeny předběžné plány pro obsah jednotlivých verzí systému. Hra Fáze hry je hlavní částí procesu vývoje a právě zde je implementován samotný produkt. Hra je členěna do sprintů, které probíhají iterativně. Jejich počet a délka je různá v závislosti na konkrétním projektu. Délka jednoho sprintu se, zpravidla pohybuje v rozmezí jednoho týdne až jednoho měsíce. V rámci sprintu probíhají klasické fáze vývoje: sbírání požadavků, analýza, návrh, vývoj, testování, prezentace, popřípadě předání. Na začátku každého sprintu zákazník společně s vývojovým týmem vybere požadavky, které budou v rámci daného sprintu implementovány. Vývojový tým následně provede detailní analýzu vybraných požadavků, odhadne jejich časovou náročnost a určí plán pro jejich tvorbu. Na závěr každého sprintu jsou dosažené výsledky prezentovány zákazníkovi a na základě jejich zpětné vazby, jsou popřípadě zaznamenány návrhy na změnu funkcionality. Důležitou součástí každého sprintů jsou denní schůzky Daily Scrum, kde vývojový tým řeší otázky typu: co bylo od poslední schůze uděláno, co se dělat bude a jestli se nevyskytly nějaké problémy. Dohra Fáze dohry nastává v okamžiku, kdy je celý projekt kompletně zpracovaný. V této fázi se vytvoří finální verze produktu. Provede se finální integrace a závěrečné testování. V této fázi je také dokončena podstatná část dokumentace, která se v průběhu vývoje příliš neřeší, posléze je předána zákazníkovi.
2.3 Srovnání nástrojů podporující agilní vývoj 22 Obrázek 3: Fáze vývoje metodiky SCRUM 2.3 Srovnání nástrojů podporující agilní vývoj Agilní vývoj výslovně nevyžaduje používání speciálních podpůrných nástrojů. Metodiky agilního vývoje lze využívat i s použitím běžného textového editoru, systému indexních karet pro zaznamenání požadavků, nebo jen obyčejný papír a tužku. Nicméně v případě kdy členové týmu nejsou úplně v pravidelném denním styku, řeší se více projektů současně, nebo množství požadavků roste a neustále se mění, může se vývojový tým ocitnout v situaci, kdy přestane mít přehled nad průběhem své práce a nastane chaos. Takovým situacím je možné předejít, použitím vhodného nástroje pro podporu agilního vývoje, který bude evidovat všechny potřebné informace o řešených projektech v aktuálním stavu. V současnosti je na softwarovém trhu k dispozici mnoho takových nástrojů. Ovšem s jejich rostoucím počtem, roste také problém volby vhodného nástroje, který by nejlépe vyhovoval prostředí dané společnosti. Cílem této kapitoly bude stručné seznámení s výsledky analýzy nástrojů pro podporu agilního vývoje. Než budou prezentovány výsledky samotné analýzy, je důležité zmínit skutečnost, že hlavním kritériem společnosti při výběru nástroje byla nejnižší možná cena. Proto byly porovnávány především tzv. komunitní verze nástrojů (Community Tools). Komunitní verze, značí většinou produkt stejného typu, ale s určitými omezeními. Jejich výhodou oproti standardním verzím těchto nástrojů je fakt, že jsou většinou distribuovány zdarma nebo za nízký poplatek. Výsledky analýzy budou prezentovány formou přehledné tabulky, kde budou srovnány zvolená kritéria nad vybranými produkty. Zvolená kritéria uvedená v porovnávací tabulce byla vybrána na základě specifických požadavků společnosti a bu-
2.4 Důvody vedoucí k implementaci vlastního nástroje 23 dou rozdělena do tří hlavních sekcí. Obecné obecná kritéria produktu. Funkcionalita přehled poskytovaných funkcí. Vlastní dojem zde bude uvedeno číselné hodnocení vybraných kritérií, které bude reprezentovat vlastní názor na kvalitu nástroje. Hodnotící stupnice bude mít rozmezí od 0 do 5 bodů. Větší počet bodů představuje lepší kvalitu daného kritéria. Analyzovány byly nástroje od společností Rally Software, VesrionOne, Target- Process a Jira. Obrázek 4: Srovnání nástrojů s podporou agilního vývoje 2.4 Důvody vedoucí k implementaci vlastního nástroje Z tabulky uvedené v předcházející kapitole, která porovnává jednotlivé nástroje sice vyplývá že většina produktů poskytuje požadovanou funkcionalitu, ovšem uživatelská přívětivost, přehlednost, a konkrétní řešení dané funkcionality neodpovídalo představám vedení společnosti. Spokojenost se zmíněnými aspekty je v tabulce jasně prezentována v části vlastní hodnocení, kde jsou většinou uvedeny průměrné až podprůměrné hodnoty. Výjimku představoval pouze produkt od společnosti Jira, který byl mimochodem částečnou inspirací při tvorbě vlastní aplikace, ovšem ani on nebyl nakonec vybrán. Mezi hlavní důvody, které vedly společnost k rozhodnutí, implementovat vlastní nástroj můžeme zařadit následující aspekty.
2.5 Neformální specifikace 24 Vysoká cena licenční politika u plných tzv. Enterprie verzí uvedených produktů byla příliš nákladná. Počet uživatelů u všech produktů není možné, aby s nástrojem pracovalo více než 10 uživatelů. Jelikož, má společnost Quality Management s.r.o. v plánu rozšířit počet zaměstnanců podílejících se na vývoji produktů, není počet uživatelů z dlouhodobého hlediska dostačující. Počet projektů většina zmíněných nástrojů neumožňuje pracovat s více jak jedním projektem současně. Nemožnost dalšího rozšíření nástroje není možné v případě nutnosti rozšířit či upravit dle specifických požadavků procesu vývoje uvedené společnosti. 2.5 Neformální specifikace Jak již bylo zmíněno v úvodu práce, hlavní cíl spočívá v implementaci nástroje, který bude ve společnosti Quality Management s.r.o. podporovat řízení projektů a to především proces vývoje. V následujících odstavcích budou nastíněny základní požadavky na systém, které vznikly po konzultaci s vedením společnosti. Zadavatel požaduje nástroj, který bude jednoduchý, intuitivní, vnese větší přehled do aktuální situace vývoje a především zefektivní projektové řízení. Nástroj bude realizován jako webová aplikace, která bude funkční a dostupná z kteréhokoliv počítače s přístupem k internetu, nebo firemního intranetu. Nástroj bude v maximální možné míře podporovat definovaný proces vývoje, jehož principy vycházejí z agilních metodik SCRUM a KANBAN. Kritéria, zohledněná při návrhu nástroje, zahrnují: definovanou strukturu vývojového týmu a využívané artefakty uvedené v kapitolách 2.2.3 a 2.2.4. Nástroj bude sloužit především pro evidenci projektů, a sledování jejich průběhu vývoje. Ke každému projektu bude možné přiřadit libovolné množství požadavků na vyvíjený systém. V rámci projektu budou iterativně zadávány sprinty, do kterých se přenesou aktuálně vybrané požadavky pro implementaci. Požadavek představuje funkcionalitu vyvíjeného systému zapsanou v jazyce srozumitelném zákazníkovi. Z důvodů přehlednosti a usnadnění vývoje, bude možné požadavek detailně rozvrhnout a rozdělit na drobnější úkoly. Nástroj umožní k evidovaným požadavkům a jejich úkolům určit odpovědné osoby. Sprint je první typ iterace, který se pravidelně opakuje a lze do něj přiřadit libovolné množství požadavků. V rámci každého sprintu bude možné uchovat informace o první plánovací schůzce a závěrečném vyhodnocení sprintu. Velimi důležitou součástí systému bude tzv. User Dashboard, který bude představovat pohled aktuálně přihlášeného uživatele. V tomto zobrazení uvidí uživatel pohromadě všechny projekty, sprinty, úkoly, upozornění a další užitečné informace, související právě s jeho osobou. Mezi další požadavky na implementaci vyvíjeného nástroje patří především:
2.5 Neformální specifikace 25 Knihovna dokumentů umožňující v systému evidovat dokumenty související s vývojem. Kalendář, který bude představovat komplexní řešení pro správu času a informací. Osobní poznámky, kam může uživatel zapsat libovolný postřeh, určený pouze jemu. Informace nebo upozornění, které může vytvořit uživatel pro ostatní členy týmu. Vyhledávání libovolného datového obsahu v aplikaci. Filtrování dat nad evidovanými seznamy (Projekty, Požadavky, Úkoly, Sprinty atd.). Možnost tvorby různých pohledů nad zobrazenými daty. Integrace s produkty MS Office. Grafické znázornění, průběhu vývoje v rámci jednotlivých sprintů. Reporty, reprezentující statické informace a přehledy z evidovaných položek systému. Neformální specifikace představuje pouze základní popis požadovaných vlastností systému, detailně jsou všechny požadavky na systém popsány v následující kapitole s názvem Formální specifikace systému.
3 METODIKA PRÁCE 26 3 Metodika práce 3.1 Formální specifikace systému 3.1.1 Vymezení uživatelských rolí Definice uživatelských rolí systémů vyplývá především z rolí používaných v samotném procesu vývoje společnosti, jejichž význam byl podrobně definován v kapitole 2.2.3. Konkrétně budou v systému figurovat následující uživatelské role: Administrátor, Management, Scrum Master, Vývojář, Vlastník produktu, Zákazník. Přesné definice oprávnění pro jednotlivé uživatelské role budou uvedeny v kapitole Vlastní práce, kde jsou prezentovány dosažené výsledky. 3.1.2 Funkční požadavky Projekty Základním prvkem systému je položka projekt, se kterou budou přímo či nepřímo souviset všechny další komponenty aplikace. Systém umožní správu jednotlivých projektů, což zahrnuje možnost jejich vytváření editaci, změnu příslušného stavu, ukončení nebo popřípadě definitivní odstranění. Jednotlivé projekty o sobě budou evidovat patřičné informace jako např.: název, stručný popis, kódové označení, důležité časové termíny, seznam členů vývojového týmu nebo informace o zákazníkovi. Uživatelé si mohou prohlížet přehled všech projektů a jejich detail, díky čemuž mají přístup k potřebným informacím a přehled o aktuální situaci. K projektu bude možné přiřadit libovolný počet sprintů a požadavků. Dalším důležitým aspektem bude vlastní knihovna dokumentů každého projektu. V knihovně budou evidovány všechny dokumenty a grafické návrhy související s daným projektem. Požadavky (Backlog) V seznamu požadavky neboli tzv. Baclogu budou evidovány všechny funkční požadavky vyvíjených produktů. Každý projekt bude mít svůj samostatný seznam požadavků. Po vytvoření požadavku se vyplní základní údaje, které se v průběhu vývoje aktualizují. Po vytvoření požadavku se nejdříve definuje stručný význam požadavku, priorita, řešitelé, předběžný odhad, termín splnění a agenda zastupující
3.1 Formální specifikace systému 27 logický celek, pod který daný požadavek spadá. Požadavky budou rozděleny na tři hlavní kategorie, podle situace ve které se momentálně nachází. Ihned po vytvoření bude požadavek umístěn v kategorii Product Backlog, po zařazení do sprintu v kategorii Sprint Backlog a v momentě kdy je připraven pro nasazení v kategorii Release Backlog. Požadavek může být pro větší přehlednost rozdělen na více úkolů. Požadavek bude obsahovat několik specifických atributů, které budou v průběhu vývoje aktualizovány buď uživatelem, nebo automaticky. Konkrétně se jedná o atributy: Zbývající odhad, Počet odpracovaných hodin, Hotovo (bude určeno procentuálně) a Stav, ve kterém se požadavek aktuálně nachází. Následující výčet prezentuje další funkcionality týkající se artefaktu požadavky. Možnost připojit dokumentové přílohy. Uživatelé systému mohou přidat libovolný počet svých komentářů. Verzování jednotlivých požadavků, při změně či aktualizaci dat. Úkoly Jednotlivé úkoly jsou vázány k požadavku řešeného projektu. Jejich hlavním smyslem je logické rozdělení požadavku na menší části, a tak jeho implementaci usnadnit a zpřehlednit. Za každý úkol je odpovědná pouze jedna osoba, která jej patřičným způsobem řeší. Po vytvoření úkolu se nejdříve definuje stručný popis požadavku, stav či odpovědný pracovník. Uživatel řešící úkol, postupně v průběhu implementace aktualizuje hodnoty atributů: Zbývající odhad, Počet odpracovaných hodin, Hotovo (bude určeno procentuálně). Na základě zmíněných atributů se budou automaticky aktualizovat stejné atributy evidované u nadřazeného požadavku. Následující výčet prezentuje další funkcionality týkající se artefaktu úkoly. Možnost připojit dokumentové přílohy. Uživatelé systému mohou přidat libovolný počet svých komentářů. Verzování jednotlivých úkolů, při změně či aktualizaci dat. Sprinty Sprint je základním stavebním kamenem metodiky SCRUM a jedná se o první typ iterace, který se pravidelně opakuje. V rámci každého projektu bude možné zadat libovolný počet sprintů. Na začátku každého sprintu se určí cíl sprintu, definují se informace o termínu zahájení, ukončení a předpokládané prezentaci výsledků. Dále se stanoví členové vývojového týmu, kteří se sprintu zúčastní a vyberou se požadavky, které budou v rámci sprintu řešeny. Ke každému sprintu bude možné přidat a uchovat informace o první plánovací schůzce sprintu (Sprint Planning Meeting) a o závěrečném vyhodnocení sprintu (Sprint Review Meeting). V rámci sprintu budou evidovány údaje o jeho průběhu, konkrétně o zbývajícím časovém odhadu, odpracovaném čase a množstvím dokončené práce odhadované v procentech.
3.1 Formální specifikace systému 28 Důležitou komponentu bude představovat pracovní prostředí, které uživatelům usnadní aktualizaci požadavků v průběhu sprintu. Uživatelské rozhraní bude vycházet z principů metodiky KANBAN, konkrétně z vizualizace pracovního toku (Workflow), kdy jsou jednotlivé požadavky rozděleny do sloupců podle jejich stavu. Sloupce budou rozděleny následovně: nezahájeno, probíhá, dokončeno. Ke každému sprintu bude možné připojit libovolný počet dokumentových příloh. BurnDown Chart BurnDown Chart je zobrazovací prvek, který navazuje na sprint projektu. Jeho hlavním úkolem je znázornit průběh práce daného sprintu v závislosti na čase. Hodnoty zobrazované v grafu budou denně aktualizovány automaticky nebo na pokyn uživatele. UserDasboard Specifické zobrazení aktuálně přihlášeného uživatele na titulní straně aplikace. V tomto zobrazení uvidí uživatel pohromadě v přehledném rozložení všechny projekty, sprinty, požadavky, úkoly, osobní poznámky, plánované akce, upozornění a další užitečné informace související právě s jeho osobou. Zobrazení umožní rychlý přístup ke všem potřebným položkám a jejich případné editaci. Hlavním cílem ovládacího prvku je poskytnout uživateli rychlý přehled o stavu právě probíhajících činnostech. Kalendář Kalendář, který bude představovat komplexní řešení pro správu času a informací. Cílem kalendáře bude zachytit všechny plánované aktivity jako např.: schůzky, dovolenou, důležité termíny a další různé činnosti. Knihovna dokumentů Knihovna dokumentů umožní v systému evidovat dokumenty různých formátů jak v textové tak grafické podobě. Po vytvoření projektu se automaticky vygeneruje do knihovny dokumentů jeho samostatná složka. Ve složce projektu bude možné soubory ukládat do libovolné struktury. Mezi další funkce knihovny dokumentů patří možnosti. Uzavření dokumentu v případě jeho probíhající úpravy. Evidence metadat souvisejících s dokumentem. Verzování dokumentu.