VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
M o d e r n í m e t o d y ř í z e n í s o f t w a ro v ý c h p ro j e k t ů bakalářská práce
Autor: Vlastimil Dvořák Vedoucí práce: doc. Dr. Ing. Jan Voráček, CSc. Jihlava 2015
Abstrakt Předními zájmy této bakalářská práce jsou agilní metodiky řízení softwarových projektů a jejich nástroje pro řízení. Nejdříve jsou zde vysvětleny základní pojmy jako projekt, softwarový projekt, životní cykly software a metodiky. Dále pak jsou zde charakterizovány jednotlivé agilní metodiky. Poslední kapitola se zabývá nástroji a techniky v moderním řízení softwarových projektů.
Klíčová slova Projekt, agilní metodiky, kanban, scrum, extrémní programování
Abstract Another objective of this work are agile software project management methodologies and tools for their management. First, there are explained the basic concepts such as design, software design, software life cycles and methodologies. In addition, here are characterized by different agile methodologies. The last chapter deals with tools and techniques in the modern management of software projects.
Key words Project, agile, kanban, scrum, extreme programming
Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce doc. Dr. Ing. Janu Voráčkovi, CSc.
za
poskytnutí
tématu
a
možnost
vytvářet
ho
pod
jeho
vedením.
Obsah 1
Úvod.......................................................................................................................... 8 1.1
2
Struktura práce a cíle práce ................................................................................ 8
Projektové řízení ....................................................................................................... 9 2.1
Historie projektového řízení ............................................................................... 9
2.2
Definice a vlastnosti projektu........................................................................... 10
2.3
Vlastnosti projektu ........................................................................................... 10
2.4
Projektový trojimperativ .................................................................................. 10
2.5
Proces řízení projektu ....................................................................................... 11
2.6
Softwarový projekt ........................................................................................... 11
2.7
Rigorózní řízení projektů ................................................................................. 11
2.7.1 2.8
Agilní řízení projektů ....................................................................................... 13
2.8.1 3
Agilní manifest ......................................................................................... 13
Rigorózní metodiky a životní cykly vývoje software ............................................. 14 3.1
Životní cykly vývoje software ......................................................................... 14
3.1.1
Vodopád .................................................................................................... 15
3.1.2
Spirála ....................................................................................................... 16
3.2
Rigorózní metodiky.......................................................................................... 17
3.2.1 4
PMBOK .................................................................................................... 12
RUP ........................................................................................................... 18
Agilní metodiky ...................................................................................................... 20 4.1
Charakteristika agilních metodik ..................................................................... 20
4.1.1
Procesní model .......................................................................................... 20
4.2
Představení agilních metodik ........................................................................... 21
4.3
Extrémní programování (XP) ........................................................................... 22
4.3.1
Základní principy ...................................................................................... 23
4.3.2
Základní praktiky XP ................................................................................ 23
4.3.3
Procesní model .......................................................................................... 25
4.3.4
Shrnutí XP................................................................................................. 27
4.4
Dynamic Software Development Method ........................................................ 27
4.4.1
Klíčové pojmy........................................................................................... 28
4.4.2
Procesní model .......................................................................................... 28
4.5
Feature driven development ............................................................................. 30
4.5.1
Základní pojmy ......................................................................................... 30
4.5.2
Procesní model .......................................................................................... 31
4.5.3
Shrnutí FDD .............................................................................................. 33
4.6
4.6.1
Principy a nástroje .................................................................................... 34
4.6.2
Shrnutí Leanu ............................................................................................ 36
4.7
Procesní model .......................................................................................... 37
4.7.2
Shrnutí TDD ............................................................................................. 38
Scrum development process ............................................................................. 39
4.8.1
Základní pojmy: ........................................................................................ 39
4.8.2
Role ........................................................................................................... 40
4.8.3
Procesní model .......................................................................................... 40
4.8.4
Shrnutí ....................................................................................................... 42
4.9
6
Test driven development .................................................................................. 37
4.7.1 4.8
5
Lean software development ............................................................................. 33
Porovnání rigorózních a agilních metodik ....................................................... 43
Metody a nástroje pro řízení projektů ..................................................................... 45 5.1
Kanban ............................................................................................................. 45
5.2
Scrumban.......................................................................................................... 46
5.3
Nástroje a techniky používané ve Scrumu ....................................................... 48
5.3.1
Product Backlog ........................................................................................ 48
5.3.2
Story board ................................................................................................ 49
5.3.3
Taskboard.................................................................................................. 49
5.3.4
Testboard .................................................................................................. 50
5.3.5
Project burndown ...................................................................................... 50
5.3.6
Velocity trend ........................................................................................... 51
5.3.7
Estimate trend ........................................................................................... 52
5.3.8
Test trend .................................................................................................. 52
5.3.9
Sprint burndown ....................................................................................... 53
Závěr ....................................................................................................................... 54
Seznam použité literatury ............................................................................................... 55 Seznam tabulek ............................................................................................................... 57 Seznam obrázků .............................................................................................................. 58
1 Úvod Tato bakalářská práce se zabývá moderními metody řízení softwarových projektů. V současnosti jsou v projektovém řízení dva směry, které se navzájem částečně vylučují i doplňují. Prvním historicky starším směrem je rigorózní vývoj, který se snaží přistupovat k řízení softwarových projektů systematicky s řadou daných pravidel, postupů a nástrojů, aby dosáhl co nejlepšího výsledku. Druhým směrem je agilní přístup, který vznikl na základě Agilního manifestu. Tento přístup se snaží přistupovat k vývoje software méně formálně a s větší volností k co největší spokojenosti zákazníka. Oba tyto dva základní směry lze dále dělit na konkrétní metodiky, které principiálně vychází z daného projektového přístupu, avšak se od sebe mírně liší v pravidlech a procesním modelu. Dále pak v projektovém řízení existují spousty konkrétních metod, nástrojů a technik. Klasické nástroje projektového řízení však přestávají v agilním vývoji stačit, proto byly a jsou vytvářeny nástroje, které jsou agilním potřebám více přizpůsobeny.
1.1 Struktura práce a cíle práce Cílem této práce je seznámit se s moderními způsoby řízení SW projektů v návaznosti na perspektivní procesní modely a ukázat a na názorných příkladech dokumentovat současné nástroje a techniky řízení vývoje softwaru. Tato práce je rozdělená na dva celky podle cílů. První tři kapitoly se věnují prvnímu zadanému cíli. Druhá kapitola přináší úvod do projektového řízení. Jsou zde představeny základní vlastnosti projektu a oba směry projektového řízení. Třetí kapitola navazuje přímo na druhou kapitolu. Jsou zde popsány a zhodnoceny tradiční metodiky a životní cykly. Čtvrtá kapitola se věnuje přímo konkrétním agilním metodikám. Šest vybraných agilních metodik je zde charakterizováno a zhodnoceno. Na konci čtvrté kapitoly jsou shrnuty a zhodnoceny oba směry projektového řízení. Celá pátá kapitola se věnuje druhému cíli a dokumentuje na příkladech současné nástroje a techniky vývoje software. 8
2 Projektové řízení Pro pochopení současných trendů je v této kapitole představena stručná historie řízení projektů. Dále pak je popsáno, co vlastně je projekt a jaká jsou specifika softwarových projektů. Poté následuje část, která se věnuje rigorózním a agilním přístupům řízení softwarových projektů.
2.1 Historie projektového řízení V dnešní době se o projekty a projektové řízení zajímá velké množství lidí, jak v soukromé, tak v podnikové oblasti. Mohlo by se zdát, že se jedná o moderní disciplínu, avšak historie ukazuje, že řízení projektů není nic nového. Mezi první projekty lze považovat stavby, které vznikaly po staletí, jako jsou například pyramidy. Ačkoliv většina lidí má vznik moderního projektového řízení spojený s projektem Manhattan, ve kterém americká armáda vyvinula atomovou bombu. Postupem času, v padesátých a šedesátých letech minulého století se zdokonalovaly techniky a metody projektového řízení, například Ganttovy diagramy, síťové grafy a analýzy kritické cesty. Stále se však projektové řízení uplatňovalo pouze v armádě. Od sedmdesátých let minulého století, kdy se zdokonalovaly informační technologie, začaly se tvořit softwary pro řízení velkých projektů, jako například program Artemis pro řízení vývoje letadel. Časem se, díky levnějším informačním technologiím, nástroje pro řízení projektů dostaly i do podnikové sféry. S rostoucí popularitou projektového řízení vznikají i různé obory na vysokých školách, školicí střediska a dochází k vytvoření mezinárodních organizací, které určují standardy. Mezi nejznámější patří PMBOK, IPMA a PRINCE2. Historie softwarových projektů provází řada zvratů a důležitých milníků. Ze začátku se software tvořil tzv. modelem „Napiš a oprav“. To mělo za následek prodlužování a prodražování projektů a hlavně jejich špatnou kvalitu. Tím nastala softwarová krize, díky které vzniklo softwarové inženýrství s prvním životním cyklem, ze kterého později vyšel Vodopádový model. V tu dobu to byl opravdu velký přelom, ale později se ukázalo, že tento model má své nevýhody a není vždy vhodný k použití. Proto v roce 1985 vzniká Spirálový model, který řeší některé nedostatky Vodopádu. Dále pak v 90. letech vznikají metodiky určené přímo na vývoj software, v současnosti je 9
nejznámější metodika RUP. Pro řízení softwarových projektů se také začaly používat metodiky jako PMBOK a další výše zmíněné. Na přelomu tisíciletí se však začínají objevovat tzv. Agilní metodiky, které se snaží vývoj software ještě více zefektivnit. [1]
2.2 Definice a vlastnosti projektu Projekt je časově omezené úsilí vynaložené na vytvoření unikátního produktu, služby nebo výstupu. Projekty mohou mít různou velikost, může se na nich podílet jeden člověk nebo i tisíce lidí. Mohou trvat pouze jeden den nebo i dlouhé roky. Také náklady jsou různorodé. Za projekt lze považovat například stavbu rodinného domu nebo vytvoření informačního systému velké společnosti. [2]
2.3 Vlastnosti projektu
Jedinečnost - každý projekt je jedinečný, protože se provádí pouze jednou.
Dočasnost – projekt má začátek i konec.
Postupné zpracování – s přibývajícími detaily se návrh projektu stále aktualizuje a upravuje.
Nejistota – díky jedinečnosti projektu je obtížné přesně odhadnout cíle, čas, náklady, atd.
Zdroje z různých oblastí – najímání odborníků ke konzultaci. [2]
2.4 Projektový trojimperativ Popisuje, jak spolu souvisí základní elementy projektu – rozsah, čas a náklady. Každý projekt má jisté limity v těchto třech dimenzích. Projektový manažer, aby dosáhl úspěchu, musí tyto protichůdné cíle sladit dohromady. [2]
10
2.5 Proces řízení projektu
Definování – definice projektových cílů
Plánování – splnění trojimperativu
Vedení – využití manažerských schopností k řízení lidských zdrojů
Sledování – kontrola stavu a postupu prací na projektu
Ukončení – zjištění, zda je vše dokončeno [2]
2.6 Softwarový projekt Softwarové projekty patří mezi obecné projekty. Mají stejné či podobné vlastnosti jako například ve stavebnictví, ale v mnohém se liší. Největší rozdíl mezi softwarovým projektem a projektem jiného druhu je, že není fyzický, to znamená, že nemá hmotnou povahu. Software je složen z myšlenek, návrhů, pokynů a vzorců. Tvorba softwarového projektu je v podstatě poznávací činnost. Artefakty v softwarových projektech nejsou tak viditelné a pochopitelné jako v jiných projektech. Musí se vytvořit způsob, aby dané artefakty byly vidět. Některé softwarové projekty se nezdaří, protože návrhy nejsou dobře udělané. Konečný stav softwarového projektu je často mnohem více spekulativní než u jiných projektů. Máme například špatnou představu o daném softwarovém projektu nebo je naše představa jasná, ale zapomeneme ji říct někomu druhému.
2.7 Rigorózní řízení projektů Rigorózní přístup řízení projektů tvoří metodiky a standardy světového formátu jako je PMBOK, PRINCE2 a IPMA. Tyto standardy jsou specifické velmi podrobnými a formálními modely procesů. Přesně stanovují procesy, všechny požadavky a produkty, předpokládají, že tvorbu software lze přesně definovat, popsat a opakovaně realizovat. Tento přístup k řízení projektů je určitě velmi efektivní u klasických projektů např. ve stavitelství. Ale kvůli odlišné povaze softwaru, provází vývoj softwarových projektů řadou neúspěchů a problémů [1].
11
2.7.1 PMBOK Patří mezi nejstarší a nejobecnější standardu řízení projektů, která je mezinárodně uznávaná. Vydává ji Institut PMI (Project Management Institute). Snaží se popsat všechny směry projektového řízení. Je zaměřen na firmy, které dodávají svoje výrobky nebo služby pomocí projektů. Jsou zde zaznamenány nejnovější trendy projektového řízení. PMBOK obsahuje 5 základní skupin procesů a 10 oblastních znalostí, které jsou typické pro většinu projektů. 5 základních skupin procesů:
Zahájení
Plánování
Provádění
Monitorování a řízení
Zavření
10 znalostních oblastí:
Projektové řízení integrace
Projektové řízení rozsahu
Projektové řízení času
Projektové řízení nákladů
Projektový management jakosti
Projektové řízení lidských zdrojů
Projektové řízení komunikace
Projektové řízení zadávání veřejných zakázek
Projektový management zúčastněných stran [1].
12
2.8 Agilní řízení projektů Agilní řízení projektů vzniklo na základě Agilního manifestu. Důvod k tomu byl, že vývojáři považovali tehdejší vývoj softwarových projektů za neefektivní a snažili se jej co nejvíce zdokonalit. Agilní přístupy pohlížejí na vývoj softwarových projektů z jiného úhlu. Předpokládají, že vývoj softwarových projektů nelze přesně popsat, o což se právě snaží rigorózní přístupy. Vývoj softwaru provází řada změn, protože zákazník většinou neví, co bude přesně potřebovat, nebo se postupem času jeho požadavky mění. Proto by se změny neměly potlačovat, ale spíše na ně reagovat a nabízet rychlá řešení. V agilním přístupu řízení projektů se nedefinují žádné určité procesy, ale spíše principy a praktiky, které se snaží vývoj softwaru zkvalitnit. Pro agilní vývoj je velmi důležitá komunikace jak mezi zákazníkem, tak mezi členy týmu [3]. Agilní metodiky jsou dále popsány a zhodnoceny ve čtvrté kapitole.
2.8.1 Agilní manifest Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. [4]
13
3 Rigorózní metodiky a životní cykly vývoje software V této kapitole budou vysvětleny metodiky a životní cykly vývoje software. Je zde vysvětlen rozdíl mezi těmito dvěma pojmy a dále jsou představeny a zhodnoceny jednotlivé tradiční životní cykly a tradiční metodiky.
3.1 Životní cykly vývoje software Metodika a životní cyklus vývoje software jsou dva odlišné pojmy, které bývají občas považovány za stejné, je zde ale značný rozdíl. Metodika je považována za souhrn veškerých pravidel, postupů a nástrojů pro řízení softwarového projektu. Životní cyklus vývoje software je model procesu tvorby softwaru, který zobrazuje vzájemné vztahy mezi jednotlivými fázemi. Lze říci, že každou metodiku tvoří určitý životní cyklus. Životní cykly vývoje softwaru lze dělit na dvě základní skupiny a to na prediktivní životní cyklus a adaptivní životní cyklus. Prediktivní životní cyklus jasně rozčleňuje rozsah projektu, lze určit jeho harmonogram a náklady. Je věnováno spoustu času na sbírání požadavků a poté na návrh. Nevýhoda je, že delší dobu nejsou vidět hmatatelné výsledky práce. Mezi nejznámější životní cykly patří tyto modely: Vodopádový model, Spirálový model, Přírůstkový model, Prototypový model a model RAD. V této práci jsou pro přehled představeny pouze první dva. Adaptivní životní cyklus je opakem prediktivního životního cyklu. Tento životní cyklus vychází z adaptivního přístupu, protože požadavky není možné na začátku životního cyklu přesně definovat. Projekty jsou založeny na komponentách, které se postupně vytvářejí a splňují funkčnost, která odpovídá specifikacím zákazníka a časově definovaných cyklech, které mají přesně dané cílové termíny. Vývoj se řídí rizikem a je tolerantní ke změnám. Dnes se to nazývá agilní softwarový vývoj. Konkrétní životní cykly jsou popsány v kapitole o agilních metodikách. [1]
14
3.1.1 Vodopád Vodopádový model patří mezi nejstarší modely životního cyklu software. Jeho pojmenování vychází z neustálého toku (jako když teče vodopád). Vznikl v 70. letech a byl tehdy přelomem na dívání se na vývoj software, protože do té doby byl většinou používán tzv. model „Napiš a oprav“. Jednotlivé fáze vodopádového modelu se mohou lišit, ale v základní formě jde hlavně o těchto 5 fází:
Požadavky
Návrh
Implementace
Verifikace
Údržba
Obrázek 1: Vodopádový model [6]
15
Pro Vodopádový model je charakteristická sekvenčnost jednotlivých fází, to znamená, že do další fáze lze vstoupit až poté, co je předchozí fáze kompletně dokončena a uzavřena. Jestliže má být tento model úspěšně použit, musí se dlouze věnovat počátečním fázím. Hlavní principy vodopádového přístupu:
Rozdělení na fáze jdoucí postupně za sebou
Důležité je plánování, časové rozvrhy, termíny a rozpočty
Přísná kontrola po dobu životnosti projektu
Mezi výhody Vodopádového modelu patří jednoduchost, a pokud se nevyskytnou problémy, tak je i rychlý a levný. Je vhodný pro projekty, které už byly implementovány a u kterých se neočekávají výrazné změny. Nevýhodou Vodopádového modelu je, že zákazník uvidí kompletní funkční software až na úplném konci. To mívá za následek, že zákazník většinou není spokojený, protože si to představoval jinak. Dále zákazník může zjistit, že některé funkcionality už jsou pro něj naprosto zbytečné, protože uplynula delší doba od zadání požadavků. To představuje obrovské finanční a časové ztráty, protože se může začít od začátku. Další nevýhodou je obsáhlá dokumentace, která je potřebná na konci každé fáze a která nepřináší zákazníkovi žádnou užitečnou hodnotu [5] [6].
3.1.2 Spirála Spirálový model kombinuje prvky dvou přístupů, a to iterativního a prototypového. Tento model poprvé použil Barry Boehm ve svém článku „A Spiral Model of Software Development and Enhancement v roce 1986. Spirálový model je vhodný pro větší projekty, protože lépe zvládá pozdější úpravy. Pokud chceme u toho modelu přejít do další fáze, musíme zanalyzovat všechna rizika pro možné problémy. Spirálový model je rozdělen do několika částí, které se stále opakují, dokud není projekt hotov. Čtyři hlavní části životního cyklu spirálového modelu:
Analýza - určení cílů, alternativ a omezení 16
Vyhodnocení – vyhodnocení alternativ, identifikace a řešení rizik
Vývoj – vývoj a verifikace další úrovně produktu
Plánování – plánování fází, které následují
Obrázek 2: Spirálový model [9]
Spirála přinesla do vývoje softwaru dva velmi užitečné principy, a to analýzu rizik a inkrementální postup. To částečně vyřešilo některé problémy, které se vyskytovaly u Vodopádu. Důslednou analýzou rizik se výrazně snižuje chybovost a odchýlení se od požadavků. Díky inkrementálnímu postupu vzniká řada prototypů, což zákazníkovi může dokázat, že se něco děje. Ale tyto prototypy ještě není možné uvést do ostrého provozu, slouží spíše pro plánování dalších iterací. Spirála se v dnešní době používá stále méně kvůli výše zmíněným nedostatkům, ale je třeba zdůraznit, že z ní vycházejí současné principy ve vývoji software [7].
3.2 Rigorózní metodiky Metodiky vývoje software lze dělit na dvě základní skupiny. Na rigorózní a agilní. Význam slova rigorózní je přesný nebo precizní. Tento název je velmi příhodný, 17
protože tyto metodiky jsou velmi charakteristické velmi přesným a důkladným popisem všech prvků, které obsahují. Dnes už se tyto metodiky začínají nazývat tradiční, protože uplynul už nějaký čas, kdy byly jedinými metodikami, které se používali. Nejvýznamnějším zástupcem je metodika RUP, proto i ta bude stručně představena.
3.2.1 RUP RUP patří mezi metodiky vývoje softwaru, kterou vytvořila společnost Rational Software Corporation. Je to velmi rozsáhlá a komplikovaná metodika. Obsahuje velkou spoustu standardizovaných nástrojů, postupů a artefaktů. Tyto metody jsou dodávány ve formě internetových stránek, který provází tým přes všechny fáze projektu. Tato metodika je vhodná pro rozsáhlejší projekty a dokáže se přizpůsobit různým potřebám potenciálního zákazníka. Procesní model obsahuje celkem čtyři fáze. Zahájení – v této fázi se definují cíle a požadavků projektu. Příprava – tato fáze se většinou skládá ze dvou iterací. Hlavní cílem je eliminovat rizikové faktory a návrh architektury systému. Tvoří se zde podrobný plán pro další fázi konstrukce Konstrukce - tato fáze se skládá z více iterací. V každé iteraci probíhá „malý vodopád“. Předávání – tato fázi zahrnuje školení koncových uživatelů a správců systému.
18
Obrázek 3: Procesní model RUP [11]
RUP je kvůli své robustnosti spíše vhodná pro rozsáhlé projekty a týmy. Lze jej používat u všech možných softwarových projektů, hlavně u rizikových, kde je nutná velmi podrobná analýza. RUP je však natolik rozsáhlá, že vyžaduje věnovat spoustu času na školení všech zaměstnanců. Mezi nevýhody patří také, že vyžaduje velkou spoustu dokumentů, artefaktů a mezivýsledků, které nepřinášejí zákazníkovi žádnou hodnotu. Také je třeba zmínit, že RUP je placená metodika [10]
19
4 Agilní metodiky V této kapitole jsou nejdříve představeny nejznámější agilní metodiky. Dále je charakterizováno a zhodnoceno šest vybraných agilních metodik. Na konci jsou shrnuty principy, kterými se agilní metodiky vyznačují a jsou zde srovnány s rigorózními.
4.1 Charakteristika agilních metodik 4.1.1 Procesní model Jedním z hlavních znaků agilního vývoje, který se liší od rigorózního, je procesní model. Ten je založen na tom, že se vývoj softwaru rozdělí do jednotlivých iterací. Každá iterace poskytuje na konci určitou část funkcionality požadovanou zákazníkem. Pokud si vezmene Vodopádový model jako zástupce tradičního vývoje, vidíme, že vývoj probíhá v určitých fázích přesně za sebou. Požadavky uvedené na začátku projektu se v pozdějších fázích velmi těžko předělávají. Agilní přístup počítá s tím, že se změny určitě objeví. Vývoj probíhá tak, že se na začátku projektu vytvoří hrubý plán s požadavky zákazníka ve formě tzv. „uživatelských příběhů“. Pak následují postupně jednotlivé iterace, které přinášejí funkční software, s postupně vytvářenými funkcemi, který je zákazníkovi předveden. Zákazník tak vidí, že se něco děje a může ovlivnit, co se bude vytvářet v dalších iteracích. Jednotlivé procesní modely se v různých metodikách liší, ale tento zjednodušeně popsaný princip je zachován [3].
20
Obrázek 4: Vodopád vs. agilní vývoj [12]
4.2 Představení agilních metodik Agilní metodiky vychází z Agilního manifestu. Spousta z nich ale existovala v určité formě již před ním. Existuje spousta agilních metodik, zde je stručný výčet nejznámějších z nich. -
Adaptive software development
-
Agilní modelování
-
Agile unified proces
-
Crystal metodiky
-
Dynamic systems development method
-
Extrémní programování
-
Feature driven development
-
Lean software development 21
-
Scrum
-
Test driven development
Tyto metodiky lze do určité míry kombinovat. Lze používat konkrétní metody a principy obsažené v jedné metodice ve druhé. Také je třeba říct, že lze kombinovat nejen agilní metodiky mezi sebou, ale i rigorózní a agilní. To už však záleží na konkrétní společnosti či vývojovém týmu. Výčet a možnosti těchto kombinací, lze však těžko spočítat a popsat. V současnosti je ale nejvýznamnější kombinace Kanbanu a jiných metodik, zejména Scrumu (Scrumban). To však nejsou metodiky v pravém smyslu, spíše tzv. hybridy. Kanban sice bývá zařazován mezi agilní metodiky, ale je to spíše metoda a nástroj k lepší práci s procesem. Proto je Kanban a Scrumban zařazen až do páté kapitoly, kde jsou popsány nástroje a metody projektového řízení. Pro tuto práci jsem vybral celkem šest odlišných metodik, které mě nejvíce zaujali.
4.3 Extrémní programování (XP) Extrémní programování patří mezi nejznámější a nejpoužívanější agilní metodiky vůbec. Jejím autorem je Kent Beck, který vysvětlil její principy v knize Extreme Programming Explained vydanou v roce 1998. [13] Tato metodika se nazývá extrémní programování, protože osvědčené postupy ve vývoji software žene do extrémů. Např. testování kódu, integraci, návrh architektury, párové programování, revize kódu atd. Pokud se třeba nejvíce osvědčilo testování kódu, neustále se testuje. Před i po každé změně kódu, tím se zajišťuje stále správná funkcionalita. Tato metodika je založená hlavně na programovacích technikách a je nejvíce vhodná pro projekt, kde se mění neustále požadavky. Není proto vhodná pro projekty, kde je nutná pečlivá začáteční analýza, nebo kde není možné neustále testovat. Také je vhodné, aby projekt nepřesáhl počet lidí v týmu (max. 10-12). Projekt by se také měl umět rozdělit na jednotlivé části (iterace), proto je vhodný hlavně pro objektové programování. Pro tuto metodiku jsou specifické základní principy a praktiky popsané níže. Také procesní model se liší od ostatních agilních metodik.
22
4.3.1 Základní principy V extrémním programování se definují těchto pět základních principů, které by se měli co nejvíce dodržovat, pokud se chce dosáhnout jisté efektivity. Komunikace Komunikace v týmu je velmi důležitý prvek, který by se neměl podcenit a zvláště pak u extrémního programování. Komunikace je třeba mezi všemi zúčastněnými stranami. Zvláště pak se zákazníkem, který by měl být pevnou součástí týmu. Neméně důležitá je také komunikace mezi manažerem a programátorem. Zajišťuje totiž reálnou představu o stavu projektu a zjednodušuje manažerovi projektu rozhodování. Zpětná vazba Efektivní zpětné vazby se dosahuje především neustálém testováním, nebo komunikace se zákazníkem, který může říct, co vyhovuje jeho požadavkům a co ne. Jednoduchost U extrémního programování se tvoří jen to, co je zrovna potřeba a k užitku. Nevytváří se kód, který by se mohl někdy hodit a který tím pádem stěžuje práci. Požadavky se neustále mění a není možné je všechny předvídat. Odvaha Pokud se objeví nějaký problém, u kterého není vidět řešení, je třeba riskovat určitý způsob řešení, který může přinést očekávaný výsledek nebo také nemusí. Respekt Aby tým mohl správně fungovat, je třeba, aby všichni členové týmu měli respekt ke svým kolegům a hlavně k zákazníkovi.
4.3.2 Základní praktiky XP Extrémní programování má celkem 12 základních praktik (postupů) [14].
23
Plánovací hra Cílem je dosáhnout za nejkratší čas, co největší hodnoty softwaru. Vytvoření funkčních požadavků a jejich uživatelských scénářů. Určení pracnosti požadavků a stanovení jejich priorit. Malé verze Cílem je mít minimálně možný funkční systém a ten postupně po krátkých cyklech zvětšovat. Metafora Používá se pro jednodušší komunikaci v týmu. Zákazník může být laik a některé odborné pojmy, by pro něj mohli být matoucí. Vytváří se příběh, který je metaforou ke skutečnému projektu. Zákazník na pracovišti Velmi důležitý prvek, který často přináší úspěch. Zákazník specifikuje požadavky za běhu projektu a pomáhá tím k rychlejšímu procesu tvoření. Měl by to být někdo, kdo bude v budoucnu software používat nebo někdo, kdo dobře zná potřeby budoucích uživatelů. Párové programování Dva programátoři sedí u jednoho počítače. Jeden programuje a druhý přemýšlí o celkovém konceptu a souvislostech. Probíhá střídání v páru a dokonce i páry se mění. Tím se dosahuje optimalizace, protože každý může mít originální nápad, který usnadňuje řešení. Společné vlastnictví kódu Veškerý kód je sdílen celým týmem. Každý má právo na úpravu jakéhokoliv kódu, pokud uzná, že jeho řešení je lepší. Naštěstí probíhá neustálé testování, takže v případě chyb, se vše snadno opraví. Standardy pro psaní kódu Zjednodušuje se tím komunikace o zdrojovém kódu. Tyto standardy by se měli dodržovat, každý pak bude moci snadno upravovat a číst kód, který není jeho. 24
40 hodinový týden Dodržování doporučené pracovní doby. Přesčasy nejsou žádoucí, protože vedou ke snížení výkonnosti a soustředění, což se projevuje na výsledcích práce. Testování V XP patří testování do činností, které jsou vedeny do extrému. Testy se dokonce píší před samotným funkčním kódem. Podmínkou je, aby všechny testy byly 100%. Refaktorizace Refaktorizace je opět velmi důležitá praktika, která je charakteristická pro XP. Jedná se o změnu systému. Chování zůstává stejné, ale mění se nefunkční prvky. Např. jednoduchost, výkonnost. Integrace Neustále jsou postupně přidávány různé funkce. Správnost integrace opět zajišťuje testování. Jednoduchost návrhu Požadavky na software se neustále mění. Proto je třeba mít implementovány jen požadavky, které jsou skutečně chtěny. Nepotřebné funkce zbytečně zvyšují složitost software.
4.3.3 Procesní model Procesní model se skládá obvykle ze šesti fází, jak je zobrazeno na obrázku.
25
Obrázek 5: Procesní model XP [15]
Průzkum Na začátku vývoje se provádí celkový průzkum požadavků zákazníka. Jsou vytvořeny takzvané karty zadání, které popisují veškeré požadavky zákazníka na funkčnost softwaru. Tyto karty si zákazník tvoří sám. V této fázi se také provádí přibližné určení nákladů a doby trvání projektu. Plánování Po průzkumu nastává fáze plánování, při které se vyberou nejdůležitější karty zadání, a poté je naplánován jejich vývoj. Iterace do uvolnění první fáze První verze se skládá z několika iterací podle rozsahu projektu. V první iteraci je vytvořena kostra systému a v dalších iteracích jsou vytvořeny další funkce podle vybraných karet zadání. Zprovozňování Po vytvoření plánovaných iterací vzniká první verze, která je předána zákazníkovi a začíná její ostrý provoz.
26
Údržba Po nasazení první verze se zpomaluje vývoj, protože programátoři jsou zaměstnání údržbou systému. Pokud je třeba, vznikají nové verze, které implementují další funkce podle potřeby a požadavků zákazníka. Nové verze začínají vždy opět od průzkumu. Smrt Tato fáze představuje konec projektu. Jedním z důvodu může být spokojenost zákazníka a dále už nejsou žádné požadavky. Druhý důvod nastává ve fázi, kdy zákazník nemá dost finančních prostředků na pokračování v projektu. [16]
4.3.4 Shrnutí XP Tato metodika se hodí spíše pro menší projekty a týmy, protože vyžaduje velmi úzkou spolupráci a častou komunikaci mezi členy, což by se u větších týmů těžko provádělo. Je dále vhodná pro projekty, u kterých se často mění požadavky. Také je třeba, aby se jednotlivé požadavky daly co nejvíce rozdělit. XP není vhodná metodika pro projekty u kterých je důležitá důkladná analýza a kde nelze rychle provádět zpětné vazby.
4.4 Dynamic Software Development Method Metodika vznikla ve Velké Británii a jejím autorem je britské konsorcium DSDM Consorcium, které bylo založeno v roce 1984 a má 16 zakládajících členů. V roce 1995 bylo dovršena a členy konsorcia schválena prvotní verze této metodiky. V dalších letech se verze metodiky zlepšovali a podíl na tom měly také rostoucí zkušenosti z praktického užívání. Charakteristika Dynamic Software Development Method je založen na sedmi iterativních fázích. Základ DSDM se skládá ze čtyř základních složek: Vývoj softwaru je týmovou prací – do vývoje by měl být zapojen zákazník i počítačový odborní Aby měl software vysokou kvalitu, musí splňovat účel využití a být technicky zdařilí
27
Vývoj může být inkrementální – není účelné dodat všechny části najednou. Někdy je lepší dodat některé části dříve, než všechny později. Efektivní využívání zdrojů za účelem, co nejlepšího konečného výsledku pro zákazníka.
4.4.1 Klíčové pojmy Tato metodika je založena na devíti principech:
Aktivní zapojení uživatele
Tým s rozhodovacími pravomocemi
Časté dodávky produktů
Změny v průběhu vývoje
Definice požadavků na hrubé úrovni
Podpora podnikových cílů
Iterativní a inkrementální vývoj k zajištění chtěného řešení
Testování v průběhu celého životního cyklu
Týmová spolupráce
4.4.2 Procesní model Dynamic Software Development Method formuluje těchto sedm fází uskutečňovaných iterativním postupem:
Úvod projektu – nastavení správné sestavy
Studie proveditelnosti – zjišťování, zda je DSDM vhodnou metodikou pro daný projekt
Obchodní studie – obchodní procesy v doménové oblasti
Stanovení modelu funkcí – utváření a rozvíjení obchodního modelu aplikace
Návrh – navržení a zdokonalení struktury
28
Implementace – samotné vytvoření projektu
Závěr projektu – dokončení projektu a jeho správa
Obrázek 6: Procesní model DSDM [16]
Na tomto obrázku můžeme vidět schéma modelu DSDM. První fáze zaznamenává studie proveditelnosti a obchodní studie. Další tři fáze (modelování, návrh a implementace) se provádí iterativně na základě současného stavu a požadavků zákazníka. Jednotlivé fáze nejsou pevně dané, pokud se zjistí nesrovnalosti, či chyby, je možné se libovolně vrátit na námi zvolenou fázi [16].
29
4.5 Feature driven development Metodika Feature driven development byla představena v devadesátých letech minulého století Jeffem De Lucou, který řadu let pracoval v oboru vývoje softwaru a měl tak za sebou mnoho zkušeností a dokázal posoudit výhody a nevýhody dané metodiky a Peterem Coadem, který se řadí mezi nejvýznamnější odborníky ve vývoje softwaru. Pojem Feature se dá označit jako důležitá vlastnost, rys nebo znak. Cílem bylo vytvořit metodiku, která by byla jednodušší, čitelnější a efektivnější pro řízení projektů a vývoj softwaru, proto také do této metodiky vložili své nápady, názory a mnoholeté zkušenosti. Charakteristika Feature driven development je agilní a flexibilní metodika, která je založena na iterativním vývoji a vývoji, který je řízen vlastnostmi produktu a klade důraz na výsledný produkt a tím maximalizuje produkt. Snaží se lidem z různých oborů umožnit efektivní a produktivní práci, dohlíží na kvalitu a z vývojového procesu se snaží odstranit co nejvíce zmatků, nervozity a nejistoty.
4.5.1 Základní pojmy Jak už bylo v úvodu řečeno, metodika Feature driven development je založena na vlastnostech produktu, a proto nejdůležitějším klíčovým pojmem je vlastnost (feature). Vlastnost je z pohledu FDD charakterizována jako malý výsledek (malá část) užitečná z pohledu zákazníka. Charakteristiky vlastnosti jsou:
Měřitelnost – musíme být schopni posoudit, zda implementovaná vlastnost, je ta, kterou zákazník požadoval
Srozumitelnost – musíme být schopni vlastnosti porozumět, být si jisti, že víme, čeho se daná vlastnost týká, definovat ji a jednoduše jí vysvětlit.
Realizovatelnost – musíme si být jisti, že vlastnost bude možné realizovat a doba realizace bude přiměřeně dlouhá. Pokud je vlastnost příliš rozsáhlá, měli bychom ji rozčlenit do více „menších“ vlastností.
Vzhledem k tomu, že je metodika silně založena na vlastnostech, předepisuje i jejich formát: 30
<podrobnosti> Akce označuje činnost, která je uskutečňována v rámci dané vlastnosti. Předmět označuje artefakt, s nímž nakládáme, a na kterém daná akce uskutečňuje. Podrobnosti se používají pro upřesnění vlastnosti, mohou být přidána další kritéria nebo upřesnění dalších požadavků na danou vlastnost. Praktiky
Doménové objektové modelování (Domain Object Modeling),
vývoj podle užitných vlastností (Developing by Feature),
vlastnictví tříd (Individual Class Ownership),
týmy pro užitné vlastnosti (Feature Teams),
inspekce (Inspections)
pravidelné buildy (Regular Builds),
řízení konfigurací (Configuration Management),
reporting/viditelnost výsledků (Reporting/Visibility of Results).
4.5.2 Procesní model K zamezení zmatků a chaosu metodika FDD vytvořila pět procesů, které mají následující parametry: Feature driven development formuluje následujících pět procesů:
Vytvoření celkového (globálního) modelu
Vypracování podrobného seznamu vlastností
Plánování podle vlastností
Návrh podle vlastností
Implementace podle vlastností [2]
31
Obrázek 7:Procesní model FDD [16]
Vytvoření celkového (globálního) modelu V první fázi spolupracují doménoví experti a členové vývojového týmu, společně s hlavním programátorem a architektem. Vytváří základní model, který předvádí základní a obecné účely systému. Doménoví experti seznámí ostatní členy týmu s daným projektem, s jeho cíli a zaměřením. Cílem první fáze je dát členům týmu hrubou o dalších postupech projektu a vytvoření úvodního modelu. Vypracování podrobného seznamu vlastností Tato fáze je zaměřena na vypracování podrobného seznamu vlastností. Tým by se měl pokusit vytvořit co nejrozsáhlejší seznam vlastností, který by měl zohledňovat, co největší
počet
požadavků a specifikací
na
daný systém.
Vypracování
co
nejpodrobnějšího seznamu vlastností se využívají nejen model z první fáze, ale všechny dostupné informace. Na závěr probíhá spolupráce se zákazníkem – identifikace konečného výsledku. Zákazník posoudí konečný výsledek a rozhodne, zda za něj zaplatí, či nikoliv. Plánování podle vlastností V této fázi se vytváří plány pro další vývoj, jehož součástí je i datum ukončení vývoje, které bývá označováno za nejdůležitější mezní datum. Poté se rozpracovávají plány jednotlivých skupin vlastností a ke každé z nich se přiřadí vlastník. Důležité je také vytvoření pořadí, ve kterém budou vlastnosti implementovány. Návrh podle vlastností V této fázi jsou už rozpracovávány vybrané vlastnosti. Programátor vybere jednu nebo více vlastností, například podle vzájemné závislosti pro implementaci. Poté hlavní 32
programátor zahájí proces, který se zakládá na určení jednotlivých tříd, které dané vlastnosti zahrnují a kontaktování vlastníků, kteří vytvoří tým a rozhodnou o následné implementaci jednotlivých vlastností. Implementace podle vlastností Tato fáze zahrnuje činnost implementace jednotlivých vlastností. Jednotliví vlastníci jsou zodpovědní za návrh a implementaci, píší jednotlivé metody a provádí i jednotlivé testy. Jakmile je hlavní programátor spokojený s konečným výsledkem, integruje ji do systému [17] [18].
4.5.3 Shrnutí FDD Tato metodika je mnohem formálnější než ostatní, protože zpočátku projektu se více věnuje modelování celého systému a návrhu potřebných vlastností. Úzce ale spolupracuje se zákazníkem, což je velká výhoda, protože směr vývoje jde správným směrem.
4.6 Lean software development Metodika Lean software development (LSD) má původ v řízení průmyslové výroby. Metoda Lean manufacturing (štíhlá výroba) vznikla v japonské firmě Toyota po druhé světové válce. Jejím cílem bylo levnější, efektivnější a rychlejší řízení výroby aut. Hlavním cílem bylo, co nejvíce omezit plýtvání bez ztráty kvality. Metoda se snaží, aby zákazník neplatil za chyby, které způsobí firma svoji neschopností. Zákazník by měl platit, jen za to, co požadoval. Lean manufacturing byla přizpůsobena pro vývoj software v rámci agilních metod a byla nazvána Lean software development. Tato metodika se snaží identifikovat a hlavně eliminovat všechny zdroje plýtvání v průběhu celého vývojového procesu a zákazníkovi dodat produkt, který splňuje jeho požadavky. Cíle metodiky:
Vyvíjení software za třetinu času
Redukce chyb na třetinu 33
Snížení rozpočtu na třetinu
4.6.1 Principy a nástroje Koncept principu Lean zahrnuje těchto sedm principů:
Eliminovat plýtvání
Včleňovat kvalitu do vývoje
Vytvářet znalosti
Odkládat závazky
Dodávat co nejrychleji
Důvěra a respekt k lidem podílejících se na vývoji
Optimalizovat celek
Princip první: eliminace plýtvání: Základem tohoto principu je nalézt všechny relevantní zdroje plýtvání a následně je eliminovat. Dalším důležitým pojmem v tomto principu je tok – zajištění plynulého toku od požadavků k řešení. V tomto principu se mezi nástroje řadí Kano model, který identifikuje hodnoty, tzv. přesné porozumění zákazníkovi a identifikace hodnoty, kterou si představuje. Dalším nástrojem je Mapa hodnotového toku, která je zaměřena na identifikaci plýtváním. Dále potom Sada zásad pro každou oblast plýtvání, která eliminuje plýtvání.
Princip druhý: včleňovat kvalitu do vývoje: Pro větší efektivitu je třeba začleňovat kvalitu do vývoji už na začátku. Zamezuje se tím, že chyby postupují celým vývojem, ačkoliv na konci by byly stejně odstraněny. Pro tento princip se používají celkem tři skupiny nástrojů pro jednotlivé účely.
34
Účel Zpětná vazba
Nástroj Iterativní vývoj Testování
Prevence vzniku chyb
Vývoj řízený testy Automatizace Refaktorizace Nepřetržitá integrace
Disciplína při vývoji
Sada principů 5S
Tabulka 1: princip druhý
Princip třetí: Vytvářet znalosti V klasickém vodopádu je na počátku věnována spousta času ke sběru všech požadavků. Protože vývoj softwaru je nestálý a požadavky se mění, a proto přijde tato práce nazmar. Lean se snaží pomocí níže uvedených nástrojů v tabulce eliminovat tyto zbytečné ztráty [19]. Účel Podpora tvorby a sdílení znalostí
Zachycování znalostí
Nástroj Komunikace Vědecká metoda Metoda A3 Vývoj založený na souboru možností Speciální pravidla Párové programování Dokumentace Wiki systém
Tabulka 2: princip třetí [20]
Princip čtvrtý: Odkládat závazky Odkládání závazků na poslední chvíli umožňuje přizpůsobení se aktuální potřebě a současnému stavu. Umožňuje pružně reagovat na změny ve vývoji a v případě špatného rozhodnutí se vydat jinou cestou.
Účel Vytvoření tolerance ke změnám Odkládání závazných a nevratných rozhodnutí
Nástroj Iterativní vývoj Minimalizace závislostí Vývoj založený na souboru možností Neoddělovat tvorbu návrhu od implementace
Tabulka 3: princip čtvrtý [20]
35
Princip pátý: Dodávat co nejrychleji Tento princip nám říká, že je velmi výhodné dodávat zákazníkovi software po malých funkčních celcích. Tím víme, že se vývoj udává správným směrem a nejsou vytvořeny funkce, které už jsou pro zákazníka zbytečné. Účel
Nástroj
Dodávat co nejrychleji
Krátké iterace, malé dávky
Tabulka 4: princip pátý [20]
Princip šestý: Důvěra a respekt k lidem podílejících se na vývoji Pokud se bude vývojář cítit ve svém týmu motivovaný a potřebný, tak ho jeho práce bude bavit a bude více produktivní. Také je potřeba, aby se mohl vývojář na své spolupracovníky spolehnout a svěřit jim úkoly s tím, že je splní.
Účel Pravomocní pracovníci Podpora týmové práci
Nástroj Samořízené týmy Motivace Komunikace Kanban Andon Tvorba přehledů
Tabulka 5: princip šestý [20]
Princip sedmý: optimalizovat celek Pro správný vývoj nesmí fungování jednotlivých částí převážit fungování celku.
Účel Systémové myšlení Neustálé zlepšování
Nástroj Metoda pěti „Proč“? Vnímání širšího kontextu vývoje Metriky Kaizen
Tabulka 6: princip sedmý [20]
4.6.2 Shrnutí Leanu Lean nepředepisuje žádný konkrétní procesní model. Poskytuje však sedm principů, které se snaží, aby byly splněny cíle metodiky. Pro efektivní vývoj je důležité, aby se využívalo všech principů, tím vynikne síla metodiky. Pro každý princip existuje několik
36
metod a technik, které pomáhají aplikovat jednotlivé principy. Konkrétní metody lze samozřejmě používat i v jiných metodikách, ale to už záleží na jednotlivých týmech.
4.7 Test driven development V každé fázi procesu vývoje je testování důležitá část a autoři metodiky Test driven development, tedy vývoj s testováním na počátku, na to nemají jiný názor. Dokonce by se dalo říct, že testování považují za nejdůležitější a staví ho před všechny ostatní kroky a označují za základ celkového vývojového procesu. Podle autorů této metodiky je ze všeho nejdůležitější nejprve napsat test a až potom napsat zdrojový kód. Poté, co je zdrojový kód hotov, projde testem a následuje řada dalších úprav. Úprava změny kódu se nazývá refaktorizace. TDD říká, že první test, který bude vytvořen, musí selhat, jinak nedojde k implementaci funkce. Dokončení implementace proběhne až ve chvíli, kdy projde tímto testem.
4.7.1 Procesní model
Obrázek 8: Procesní model TDD [16]
Životní cyklus se skládá ze tří fází. První fází je testování, druhá fáze implementace a třetí fáze je návrh.
37
Procesy Jednotlivé fáze, se kterými vývojáři pracují, znázorňuje tento diagram:
Obrázek 9: Procesní model TDD [16]
V prvním kroku, co nejrychleji vytvoříme test, který selže na základě chybějící funkcionalitě. Spustíme všechny existující testy a přesvědčíme se, že test v kroku 1 opravdu selže. Pokud máme velké množství testů, spustíme pouze jejich podmnožiny. Nastává čas pro úpravu potřebné funkcionality (modul, funkci). Ověříme, zda zdrojový kód projde testem z kroku 1. V této fázi dochází k puštění všechno dosavadních testů nad tímto novým zdrojovým kódem. V případě velkého množství, spustíme jejich podmnožinu. Pokud nedopadne testování úspěšně, musíme testovat znovu. V posledním kroku provedeme potřebné úpravy a odstraníme případné duplicity. Zkontrolujeme, zda nebyla porušena integrita po přesunutí testu do testovací sady [16] [21].
4.7.2 Shrnutí TDD Test driven development je zajímavá metodika avšak velmi specifická. Někdy bývá součástí ostatních agilních metodik. Pro plnohodnotné použití potřebuje zkušený tým, který ji dokáže využívat. Je vhodná pro projekty, které jsou rizikové a nepotřebují se na počátku projektu věnovat příliš návrhu.
38
4.8 Scrum development process Metodika Scrum development process (dále jen Scrum) se řadí k agilním metodikám, které byly vytvořeny později. Název Scrum se používá v rugby, což by se dalo přeložit jako mlýn. Jedná se o strategii týmu dostat míč do hry. Tato metodika se snaží vidět svět objektově, proto je vhodné používat objektové modelování při jejím používání, tím vynikne její síla. Základní charakteristika Scrum se spíše řadí mezi manažerské metodiky. Snaží se zlepšovat metody a praktiky, které se používají v softwarovém inženýrství. Každý vývojář má přidělenou určitou množinu objektů, které se věnuje, na rozdíl od extrémního programování, kde každý má přístup ke všemu. Vývoj probíhá v určitém počtu časových posloupností, jejichž délka je pevně daná. Každý jeden interval se nazývá sprint a trvá průměrně jeden měsíc. Není to ale podmínka, délka sprintu záleží na rozsáhlosti projektu. Každý den probíhají tzv. Scrum meetings, které nahrazují centralizované plánování. Na těchto setkáních se probírá dosavadní pokrok, předvedení současných výsledků a samozřejmě další plánování. Scrum se do jisté míry shoduje s dalšími agilními metodikami. Je flexibilní, iterativní a snaží se včasně reagovat na nové požadavky zákazníka.
4.8.1 Základní pojmy: Scrum Jednodenní iterace v rámci Sprintu, je mnohem kratší než sprint, trvá jeden den. Na začátku každého pracovního dne se koná schůzka, tzv. Scrum Meeting. Sprint Sprint je druhý typ iterace, který trvá podle velikosti projektu. Většinou však délka trvání je jeden měsíc. Vývoj projektu probíhá obvykle ve třech až osmi sprintech. Na počátku sprintu se uskutečňuje schůzka, na které se třídí a vybírá množina požadavků, která se bude řešit. Ke konci sprintu je další schůzka Sprint review, na které se shrnuje, co se během sprintu vykonalo a co se podařilo či nepodařilo splnit. Zákazníkovi se předvádí tzv. Sprint demo. Na úplném konci probíhá retrospektiva, na které se shrnuje, jak si tým po celou dobu sprintu vedl a poukazuje na slabé a silné stránky. Backlog Ve Scrumu se dělí backlogy na dva základní druhy:
39
Product backlog a Sprint backlog. Product backlog v sobě obsahuje veškeré funkcionality a požadavky zákazníka na produkt. Odpovědnost za Product backlog má pouze Vlastník produktu, který uspořádá seznam požadavků, podle svých priorit. Tento seznam se stále mění podle potřeby a logické návaznosti. Pro každou položku je časem vytvořen uživatelský příběh, který více přibližuje požadovanou funkčnost. Sprint backlog obsahuje položky z Product backlogu. Tyto položky jsou více rozpracovány a je určen časový odhad pro její vykonání.
4.8.2 Role Scrummaster je osoba, která je odpovědná za komunikaci se zákazníkem a managementem a také zda jsou dodržovány praktiky Scrumu. Má za úkol odstraňovat všechny překážky, které zabraňují maximální míře efektivity. Na setkáních klade otázky a moderuje diskuzi. Vlastník produktu (Product Owner) odpovídá za chod projektu, řídí jeho průběh a stará se o Product backlog. Je vybrán Scrummasterem, zákazníkem a managementem.
Scrum tým (Scrum Team) je samoorganizující projektový tým, který má za úkol splnit cíle daného sprintu. Dalšími jeho úkoly je odhad pracnosti a času
4.8.3 Procesní model
Obrázek 10: Procesní model Scrum [24]
40
Postup vývoje: Vývoj se dělí na 3 základní kroky: Předehra a Dohra mají lineární průběh. Hra se skládá ze sprintů, který se iterativně opakují. Předehra
Plánování
Architektura systému a návrh
Sprinty
Vývoj
Zabalení
Revize
Hra
Dohra
Ukončení
Plánování
Předehra Plánování definuje systém. Na začátku je sestaven Product Backlog, který obsahuje všechny požadavky. Ty jsou uspořádány podle priority a logické návaznosti. Sestavuje se projektový tým, vybírají se vývojové nástroje, analyzují se rizika a zdroje. Hra Hra je nejdůležitější část celého procesu Scrum. Je iterativně opakována ve sprintech, který implementují nové funkcionality. Během jednoho sprintu probíhají všechny klasické vývojové fáze: sbírání požadavků, analýza, návrh, vývoj, testování, předání. Obsah sprintu je určený backlogem. Na začátku každého sprintu se z něj vybírá skupina požadavků, který tvoří Sprint Backlog. Tyto požadavky jsou pak během sprintu implementovány.
41
Dohra Jedná se ukončení celého vývoje. Cílem této fáze je příprava produktu pro předání zákazníkovi. Vytváří se dokumentace, testují se vazby mezi moduly[22] [23].
4.8.4 Shrnutí Scrum je jedním z nejpoužívanějších agilních metodik, který má celou řadu zásad, které řídí vývoj softwaru. Metodika je iterativní, měřitelná a inkrementální, protože se zaměřuje na zpřísnění vývojového cyklu, který je rozdělen do menších úkolů, které představují menší množství úsilí, tzv. sprinty, na rozdíl od rozsáhlého plánování, budování, testování a nasazení. Výhody: Iterativní a inkrementální metoda: umožňuje sledování pracovního postupu projektu a poskytuje mezivýsledky. Přizpůsobivost vývoje produktů: Scrum umožňuje měnit priority a požadavky. Také umožňuje rychle přidat další modifikace nebo funkce. Účast a posílení komunikace: všichni členové týmu jsou zapojeni do procesu a motivováni k tomu vyjádřit svůj názor a přispět ke všem rozhodnutím. Tým je schopen snadno komunikovat a odstraňovat překážky co nejdříve. Spolupráce: zdokonalování vztahů se zákazníky a klienty díky denní komunikaci. Zvyšování produktivity: umožňuje rychleji dodávat produkty stanovením předběžného odhadu a porovnáváním výkonnosti produktivity týmu. Nevýhody: Vyžaduje zkušený tým: obvykle se metodika Scrum používá pro malé týmy 5-8 osob. Členové týmu musí být přiděleny v rámci projektu a měli by mít dostatečnou zkušenost. Pokud tým se skládá z nováčků, může být riziko, že nebude dokončen projekt včas. Čas a náklady: po každém sprintu potřebuje sprint nové plánování. To spotřebuje hodně času, pokud je plánován delší sprint. Neočekávané problémy mohou také bránit dokončení sprintu v čas.
42
4.9 Porovnání rigorózních a agilních metodik Na základě předchozích poznatků, lze shrnout a porovnat oba směry projektového řízení v určitých oblastech. Náplň – rigorózní metodiky se více zaměřují na samotné procesy. Samotné pracovníky lze ve vývoji nahradit. Agilní metodiky považují pracovníky za klíč k úspěchu. Kvalita – rigorózní metodiky se zaměřují na vysokou kvalitu procesů a tím předpokládají, že to povede ke kvalitnímu výsledku. Naopak agilní metodiky se zaměřují na vysokou kvalitu, která bude vyhovovat zejména zákazníkovi. Změny – rigorózní metodiky se snaží změnám co nejvíce vyhnout, nebo je alespoň minimalizovat, protože přílišnými změnami se znehodnocují další plány. Agilní metodiky změny vítají a počítají s nimi, protože zákazník může alespoň přehodnotit své požadavky a zbytečně se nevytváří něco, co pro něj už v současnou chvíli nemá význam. Podrobnost – rigorózní metodiky se vyznačují vysokou podrobností všech procesů a činností v celém vývoji. Agilní metodiky předkládají většinou pouze principy a doporučení, aby nebyly vytvářeny zbytečné meziprodukty, které nemají žádný přínos. Dokumentace – v rigorózních metodikách se zpracovává velké množství dokumentace, která však zákazníkovi nepřináší žádnou hodnotu a pro vývojáře a to neoblíbená a zdlouhavá práce. V agilních metodikách se tvoří pouze minimální dokumentace (User story). Dokumentace není ani tolik potřebná, neboť tým často komunikuje se zákazníkem. Specializace lidí – v rigorózních metodikách bývají přesně definované role vývojářů, například databázový expert se stará pouze o databáze atd. V agilních metodikách je tým brán jako jeden celek, který spolu sdílí znalosti a spolupracuje. Plánování – v rigorózních metodikách se velký čas věnuje sběru požadavků a pečlivému plánování celého vývojového procesu. V agilních metodikách se většinou plánuje pouze příští iterace z důvodu, že není jisté, co zákazník může považovat vhodné. Řízení lidí – v rigorózních metodikách je pevně daná organizační struktura. Hlavní slovo zde má vždy projektový manažer, který plánuje a řídí veškerý proces. V agilních metodikách bývá většinou role projektového manažera vypuštěna. Nejlépe je to vidět ve 43
Scrumu, kde je vývojový tým složen z vlastníka produktu, Scrummastera a samoorganizovaného týmu. Projektový manažer může mít pouze podpůrnou roli k odstranění administrativních nedostatků. Komunikace – v rigorózních metodikách je komunikace převážně písemná a naopak agilní metodiky dávají přednost osobní komunikací tváří v tvář. Způsob vývoje – v rigorózních metodikách se můžeme setkat spíše s vodopádovým modelem, popřípadě s přírůstky, které ale probíhají v dlouhých iteracích. Naopak v agilních metodikách se můžeme setkat s přírůstkem, který probíhá v krátních iteracích. Vztahy se zákazníkem – v rigorózních metodikách se považuje zákazník pouze za zdroj peněz a veškeré závazky jsou velmi dobře právně ošetřeny. Zákazník je většinou přítomen pouze na začátku projektu při sběru požadavků a na konci při předávání výsledného projektu. Naopak v agilních metodikách funguje spolupráce mezi zákazníkem a vývojovým týmem na základě důvěry. Zákazník bývá, nebo je alespoň dobré, když je součástí týmu nebo pravidelně komunikuje. Technologie – v rigorózních metodikách se většinou může používat jakákoliv technologie. V agilních metodikách je využívána objektově orientovaná, neboť jde více rozdělovat do jednotlivých funkčních částí. Testování – v rigorózních metodikách probíhá testování na konci vývojového cyklu a naopak v agilních závisí na metodice, ale dalo by se říci, že probíhá neustále.
44
5 Metody a nástroje pro řízení projektů Tato kapitola se zabývá metodami a nástroji, které se využívají v moderním projektovém řízení. Některé už byly představeny v rámci jednotlivých agilních metodik.
5.1 Kanban Kanban bývá zařazován do agilních metodik, ale je to spíše technika, která se snaží zefektivnit proces, tím že vizualizuje plánované a odvedené práce. Jejím zakladatelem je Taiichi Ohno, který pracoval v Japonské firmě Toyota. Termín kanban se překládá jako viditelná deska. Kanban odstraňuje z procesu neefektivitu tím, že veškerou práci bere jako plynutí. To, co brání plynulosti procesu, odstraňuje. Pokud se omezí rozpracovaná práce, zvýší se tím kvalita. Pokud se vývojáři soustředí pouze na jeden úkol, je dosaženo vyšší kvality. Kanban je tvořen těmito pěti pravidly: 1. Vizualizace workflow 2. Limitování work-in-progress 3. Měření a řízení toku (flow) 4. Explicitní vyjádření pravidel procesu 5. Využívání modelů k rozpoznávání příležitostí a k zlepšení. Vizualizace workflow Metoda Kanban se opírá zejména o vizualizace a vizualizaci workflow. Rozdělíme Kanban tabuli (Kanban board), která je fyzická nebo elektronická, do svislých sloupců a zapíšeme do nich jednotlivé procesy. Jednotlivé Tasky zapíšeme na lístečky a ty potom rozdělíme do jednotlivých procesů podle stejné nebo podobné úrovně.
45
Limitování work-in-progress Podle metody Kanban by se nemělo dělat více věcí najednou. Fyzická tabule zapisuje limity tasku nad každý sloupec. Elektronický Kanban kontroluje WIP (work-inprogress), což je výhodou.
Měření a řízení toku Pro kontinuální zlepšování procesu, je třeba procesy měřit. K tomu slouží veličina lead time, která měří čas, za jakou dobu se jednotlivý task dostane z jednoho do druhého stavu. Průběh a vývoj toku se zobrazuje pomocí Cumulative flow diagramu. Tento diagram nám ukazuje, jestli jsou dodržovány limity WIP. Explicitní vyjádření pravidel procesu Veškerá dohodnutá pravidla, by měli být dodržována a všichni členové týmu, by k nim měli mít přístup. Využívání modelů k rozpoznávání příležitostí a k zlepšení Pro zefektivnění kanbanu je třeba používat procesní modely [25] [26] [27].
5.2 Scrumban Scrumban používá smíšené techniky Scrumu a Kanbanu. Spojuje základní vlastnosti Scrumu a flexibilitu Kanbanu. Scrumban má mírně vynucený proces, kde stanovování priorit je volitelné, ale doporučuje se při každém plánování. Také, stejně jako v Kanbanu, deska zůstane trvalá, zatímco pouze úkoly a jejich priority se mění. V Scrumbanu je práce obvykle zaměřena spíše na plánování než uvolnění, zatímco plánování ve Scrumu se provádí po každém sprintu, plánování ve Scrumbanu se provádí pouze na vyžádání. Tato metoda se používá hlavně pro rychle se rozvíjející proces jako začínající nebo projektů, které vyžadují nepřetržité tvorbu produktů, kde prostředí je dynamické.
46
Výhody: Úspora času: Scrumban využívá plánování na vyžádání, takže není nutné dělat odhad a plánování sprintu. Tým plánuje pouze tehdy, když je potřeba. Z tohoto důvodu členové týmu získají další den navíc. Kvalita: ušetřený čas na plánování umožňuje zaměřit se na kontrolu kvality a ověření, zda pracovní položka je správně vytvořená. Ušetřený čas dovolí ovládání výrobního procesu a kontrolování, zda práce je připravená do fronty připravených procesů. Minimalizace odpadu: Scrumban používá proces vyrovnávání paměti a diagramy ukazují slabiny a příležitosti procesu. To dává možnost odstranit vše, co není přidanou hodnotou pro zákazníka. Použití Scrumbanu: Rozšířená deska Vytváří se sloupce, které se skládají ze sekcí "Dělat", "Práce postupu" a "Hotovo". Sloupec " Práce postupu " může být rozdělena do více částí, poté nové sloupce ukazují konkrétní etapy procházení úkolu, proto každý vidí současný stav a úkoly jsou dokončeny co nejdříve. Nové úkoly jsou umístěny na desce, aniž by byly přiřazeny konkrétnímu členu týmu. Z tohoto důvodu jsou členové týmu schopni vybrat, na kterém úkolu by chtěli pracovat. Omezení Backlogu Na začátku je potřeba udělat seznam úkolů, vložit je do Backlogu a nastavit omezení ve sloupci „Práci postupu“. Protože Scrumban nemá pravidelné plánování schůzek, omezení se používá k implementaci plánování na požadovanou techniku. Tým bere položky z Backlogu a vkládá je do procesu, dokud nebude prázdný. Prázdná Backlog je znamení, že je třeba plánovat další úkoly. Je to lepší a snadnější pro menší plánování, které má cíl pouze několik úkolů na iteraci. Nalezení úzkých míst Pro nalezení úzkých míst je potřeba rozdělit sekci „Práce postupu“ do menších sloupců, které realizují samostatné WIP omezení. Tento přístup umožňuje objevit úzká místa, které blokují tok procesů [28].
47
5.3 Nástroje a techniky používané ve Scrumu Pro řízení softwarových projektů, která využívá agilních myšlenek, existuje v dnešní době opravdu velké množství nástrojů. Já jsem si vybral produkt od společnosti Versionone , který mě asi nejvíce zaujal, protože poskytuje komplexní a propracované nástroje pro celý vývojový proces projektu. Součástí produktu jsou také výukové videa a blogy, které pomáhají, jak pracovat s programem i jak přizpůsobit vývojový proces pro vlastní tým [29] [30.]
5.3.1 Product Backlog
Obrázek 11: Product Backlog [29]
Product Backlog slouží k uchovávání všech uživatelských příběhů (User story). Každý User story má vlastní název, ID, vlastníka, prioritu a odhad vykonání práce.
48
5.3.2 Story board
Obrázek 12: Story board [29]
Storyboard využívá metodu Kanban. Vizualizuje veškeré User story v daném sprintu. Seznam všech sloupců lze volitelně nastavit. Každý User story obsahuje stručné informace, jako například název vlastníka a odhad práce. Mezi sloupci lze položky jednoduše a libovolně přesouvat mezi sebou.
5.3.3 Taskboard
Obrázek 13: Taskboard [29]
49
Taskboard funguje na podobném principu jako Storyboard. Každý User story obsahuje jeden nebo více tasků (úloh), to vše je zobrazováno v jednotlivých řádcích. Členové týmu vidí, které tasky už jsou hotové, a které jsou potřeba ještě vykonat.
5.3.4 Testboard
Obrázek 14:Testboard [29]
Testboard je třetí nejdůležitější vizualizace Kanbanu pro sledování sprintu. Podobně jako Taskboard zobrazuje jednotlivé testy k náležícím User story.
5.3.5 Project burndown
Obrázek 15: Project burndown [29]
50
Project Burndown je graf, který zobrazuje, v jaké současné fázi se projekt nachází. Bere v úvahu všechny sprinty, které zatím byly provedeny. Horní křivka značí aktuální stav zbývajících User story, které je třeba vykonat. Dolní přímka představuje ideální stav. Na tomto obrázku je vidět, že vývoj na konci projektu sotva dosáhl jedné třetiny počtu vykonaných User story.
5.3.6 Velocity trend
Obrázek 16: Velocity trend [29]
Velocity trend vyjadřuje rychlost vývoje projektu. Na začátku sprintu se určí optimální rychlost vývoje. Tým se snaží na základě předchozích sprintů určit správnou hodnotu rychlosti. Na obrázku je vidět příklad Velocity trendu. Jednotlivé sloupce vyjadřují skutečnou rychlost v dané časové jednotce. Přímka, procházející jednotlivými sloupci představuje rychlost danou na začátku sprintu. Na tomto konkrétním obrázku je vidět, že tým dodržovat danou rychlost pouze v první časové jednotce. V dalších čtyřech časových jednotkách tým vykazoval zvýšenou rychlost, což by nebylo na škodu, ale protože v posledních dvou časových jednotkách je rychlost podstatně menší než v předchozích, je zde vidět, že práce v týmu nebyla optimálně rozložena. Proto by tým měl v dalším sprintu svoji práci více zoptimalizovat.
51
5.3.7 Estimate trend
Obrázek 17: Estimate trend [29]
Estimate trend zobrazuje celkový počet odhadů všech jednotlivých User story v rámci celého projektu. Je zde vidět lineární zvyšování počtu uzavřených odhadů, což je výhodné, protože tým se postupně zdokonaluje a získává zkušenosti pro další projekty.
5.3.8 Test trend
Obrázek 18: Test trend [29]
52
Test trend zobrazuje celkový vývoj všech testů. Lze rozlišit tři základní stavy – úspěšné, neúspěšné testy a ty, které ještě neproběhly. Na tomto konkrétním obrázku můžeme vidět, že tým procentuálně zvládal drtivou většinu testů. Ale je zde také vidět několikanásobné zvýšení počtu všech testů v průběhu času. To může značit, že se projevily velké chyby v implementace nebo v návrhu.
5.3.9 Sprint burndown
Obrázek 19: Sprint burndown [29]
Sprint burndown je graf, který zobrazuje stav zbývajících User story v čase. Princip fungování je stejný jako u Project Burndown. Na tomto konkrétním obrázku je vidět velká nerovnoměrnost v čase. V počátku je vidět rychlý vývoj, který potom začne výrazně kolísat a ke konci se od ideálního stavu značně vzdaluje.
53
6 Závěr Prvním cílem této bakalářské práce bylo seznámit se s moderními způsoby řízení SW projektů v návaznosti na perspektivní procesní modely. Myslím, že tohoto cíle bylo v práci dosaženo v rámci prvních tří kapitol. Nejdříve byly rozebrány základní pojmy a současné směry projektového řízení. Dále pak následovala kapitola, která popisovala a hodnotila tradiční směr. Ve čtvrté kapitole byly nejdříve rozebrány a popsány konkrétní agilní metodiky, následovaným rozborem a porovnáním rigorózního a agilního přístupu v řízení softwarových projektů. Možná se může zdát, že se práce až příliš zabývá rigorózním vývojem, i když jsou cílem moderní přístupy, ale podle mě je to důležité, protože agilní metodiky vznikly na základě jeho nedostatků. Druhým cílem bylo ukázat a na názorných příkladech dokumentovat současné nástroje a techniky řízení vývoje softwaru. Toho bylo dosaženo v páté kapitole. Byly zde představeny další metody a to Kanban a Scrumban Dále zde byly dokumentovány příklady v konkrétním nástroji pro řízení projektů. Agilní řízení projektů je moderní trend, který slibuje zlepšení vývoje softwarových projektů. To ale nemusí vždy platit, záleží v jisté míře na typu projektu, jeho velikosti a dalších důležitých faktorech. Agilní řízení projektů je moderní trend, který slibuje zlepšení vývoje softwarových projektů. To ale nemusí vždy platit, záleží v jisté míře na typu projektu, jeho velikosti a hlavně na lidech. Agilní přístup je velmi závislý na lidech, který jej tvoří. Také je důležitá práce se zákazníkem, který je stavěn na první místo. Má také velká rozhodovací pravomoce a projektový tým a manažer v něj mají důvěru. Myslím si, že agilní metody jsou dobře propracované a spolehlivé. Jejich velkou předností je, že se dobře přizpůsobují změnám. Podle mého názoru je agilní projektové řízení a celkově agilní metodiky je trend, který má do budoucna velký potenciál. Ale protože je řízení softwarových projektů stále poměrně nový obor, který se vyvíjí a může podstoupit ještě mnoho změn. Já osobně bych si raději vybral agilní přístup před rigorózním, neboť nabízí široké možnosti uplatnění.
54
Seznam použité literatury 1. SCHWALBE, Kathy. Řízení projektů v IT: kompletní průvodce. Vyd. 1. Brno: Computer Press, 2011, 632 s. ISBN 978-80-251-2882-4. 2. ROSENAU, M. D. Řízení projektů. 1.vyd. Praha: Computer Press, 2010. ISBN 978-80-251-1506-0. 3. ŠOCHOVÁ, Zuzana a Eduard KUNCE. Agilní metody řízení projektů. 1. vyd. Brno: Computer Press, 2014, 175 s. ISBN 978-80-251-4194-6 4. BECK, Kent, et al. Manifesto for Agile Software Development [online]. 2001 [cit. 2015-04-11]. Dostupné z WWW: http://www.agilemanifesto.org/ 5. MCCONNELL, Steve. Dokonalý kód: umění programování a techniky tvorby software. Vyd. 1. Brno: Computer Press, 2005, 894 s. ISBN 80-251-0849-x. 6. Vodopávý model, Wikipedie [online]. [cit. 2015-04-11]. Dostupné z WWW: http://cs.wikipedia.org/wiki/Vodop%C3%A1dov%C3%BD_model 7. BOEHM, Barry. SOFTWARE ENGINEERING INSTITUTE. SpiralDevelopment: Experience, Principles, and Refinements. Philadephia, PA: Carnegie Mellon University, 2000. 8. Dostupné z: http://www.sei.cmu.edu/reports/00sr008.pdf 9. Životní cyklus informačního systému, Masarykova univerzita [online]. [cit. 2015-04-11]. Dostupné z WWW: http://www.fi.muni.cz/~smid/mis-zivcyk.htm 10. RATIONAL. Rational Unified Process: Best Practices for Software development Teams. IBM. [online]. 2011 [cit. 2015-05-05]. Dostupné z: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/12 51_bestpractices_TP026B.pdf 11. Procesní model RUP, Testování softwaru [online]. [cit. 2015-04-11]. Dostupné z WWW: http://testovanisoftwaru.cz/manualni-testovani/modely-zivotniho-cyklusoftwaru/rup/ 12. NEOGLOBE CONSULTING, [online]. [cit. 2015-04-11]. Dostupné z WWW: http://www.neoglobeconsulting.com/blog/2014/3/23/why-go-agile-understandingthe-benefits-of-the-agile-method-of-development 13. BECK, Kent. Extrémní programování. 1. vyd. Praha: Grada, 2002, 158 s. Moderní programování. ISBN 80-247-0300-9. 14. Extreme Programming: A gentle introduction. Extreme Programming: A Gentle Introduction. [Online] [Citace:2015-04-11.] http://www.extremeprogramming.org/
55
15. KOTRLA, Tomáš. Agilní metodiky vývoje software. Brno, 2005. Diplomová práce. Fakulta informatiky Masarykovi univerzity v Brně. 16. KADLEC,
Václav. Agilní
programování:
metodiky efektivního
vývoje
softwaru. Vyd. 1. Brno: Computer Press, 2004, 278 s. ISBN 80-251-0342-0. 17. PALMER, Stephen R., Felsing, John M.: A Practical Guide to Feature-Driven Development (The Coad Series), Prentice Hall 2002 18. BUCHALCEVOVÁ, A., Feature driven development neopouští modelování a procesy, a přesto přináší výhody agilního vývoje. [online]. [cit. 2015-04-11]. Dostupné z WWW: http://nb.vse.cz/~buchalc/clanky/tsw2005.pdf 19. POPPENDIECK, Mary a Tom POPPENDIECK. Lean software development: an agile toolkit. 10. print. Boston: Addison-Wesley, 2006. ISBN 03-211-5078-3. 20. HEFNEROVÁ, Lucie., Lean software development. Praha, 2012. Bakalářská práce. Fakulta informatiky a statistiky Vysoké školy ekonomické v Praze. 21. BECK, Kent. Programování řízené testy. 1. vyd. Praha: Grada, 2004, 203 s. Moderní programování. ISBN 80-247-0901-5 22. KNESL, Jiří. Zdroják.cz [online] [cit. 2015-04-28]. Dostupné z WWW: http://zdrojak.root.cz/clanky/agilni-vyvoj-scrum 23. SCHWABER, Ken. Agile Project Management With Scrum. United States : Microsoft Press, 2004. 163 s. ISBN 978073561993. 24. Agile product design, [online] [cit. 2015-04-28]. Dostupné z WWW: http://www.agileproductdesign.com/blog/dont_know_what_i_want.html 25. Software Samuraj, [online] [cit. 2015-04-28]. Dostupné z WWW http://www.swsamuraj.cz/2014/03/kanban-lehky-uvod.html 26. SHALLOWAY, Alan. NET OBJECTIVES, Inc. Demystifying Kanban. Lynnwood, 2011. Dostupné z: http://www.netobjectives.com/files/resources/articles/Demystifying-Kanban.pdf
27. Emanuel, Pablo. Kanban – a success story and a humbling experience. Mythic Praxis. [Online] http://mythicpraxis.wordpress.com/2011/11/27/kanban-a-success-story-and-a-humblingexperience/.
28. Scrumban: A different way to be Agile. GAMBILL, Paul. DELOITTE DIGITAL. [online]. [cit. 2015-04-05]. Dostupné z: http://www.deloittedigital.com/us/blog/scrumban-adifferent-way-to-be-agile 29. VersioOne, http://www.versionone.com/ 30. Versioone blog, http://www.versionone.com/agile-resources/more-resources/blogs/
56
Seznam tabulek Tabulka 1: princip druhý................................................................................................. 35 Tabulka 2: princip třetí [20] ............................................................................................ 35 Tabulka 3: princip čtvrtý [20] ......................................................................................... 35 Tabulka 4: princip pátý [20] ........................................................................................... 36 Tabulka 5: princip šestý [20] .......................................................................................... 36 Tabulka 6: princip sedmý [20] ........................................................................................ 36
57
Seznam obrázků Obrázek 1: Vodopádový model [6] ................................................................................ 15 Obrázek 2: Spirálový model [9]...................................................................................... 17 Obrázek 3: Procesní model RUP [11]............................................................................. 19 Obrázek 4: Vodopád vs. agilní vývoj [12] ...................................................................... 21 Obrázek 5: Procesní model XP [15] ............................................................................... 26 Obrázek 6: Procesní model DSDM [16] ......................................................................... 29 Obrázek 7:Procesní model FDD [16] ............................................................................. 32 Obrázek 8: Procesní model TDD [16] ............................................................................ 37 Obrázek 9: Procesní model TDD [16] ............................................................................ 38 Obrázek 10: Procesní model Scrum [24] ........................................................................ 40 Obrázek 11: Product Backlog [29] ................................................................................. 48 Obrázek 12: Story board [29] ......................................................................................... 49 Obrázek 13: Taskboard [29] ........................................................................................... 49 Obrázek 14:Testboard [29] ............................................................................................. 50 Obrázek 15: Project burndown [29]................................................................................ 50 Obrázek 16: Velocity trend [29] ..................................................................................... 51 Obrázek 17: Estimate trend [29] ..................................................................................... 52 Obrázek 18: Test trend [29] ............................................................................................ 52 Obrázek 19: Sprint burndown [29] ................................................................................. 53
58
