Moderní projektové řízení vzniklo jako reakce na nedostatky tradičního projektového řízení. To znamená především realizaci celého projektu v jediném dlouhém vývojovém cyklu a dlouhé rozestupy mezi přípravou projektu, sestavením zadání, plánováním a předáním projektu. Dále pak zvýšené riziko pozdní reakce na chyby, změnové požadavky a změny okolního prostředí projektu, které způsobují následné zpoždění projektu nebo vyšší náklady na jeho realizaci. (Svozilová, 2019, kap. 11.2.2)

V dynamickém prostředí vývoje softwarových projektů jsou uvedená rizika dále akcentována. Na počátku proto byly agilní metodiky využívány primárně v prostředí vývoje software a inženýrských celků, ale později začaly být využívány i v dalších oblastech a jejich přesah do tradičních projektových metodik se ukázal jako přínosný. (Křivánek, 2019, kap. 3.2)

3.1 Historický vývoj řízení softwarových projektů

James Shore (2021, kap. 1) uvádí, že v 90. letech minulého století nastala krize v oblasti vývoje softwarových projektů. V této době bylo běžné, že softwarové projekty výrazně překračovaly rozpočet i časový harmonogram a nesplňovaly požadované cíle. Podle tzv. CHAOS²⁴ reportu renomované společnosti The Standish Company z roku 1994 nesplnilo 52,7 % softwarových projektů základní kritéria na rozpočet, náklady a dodaný rozsah projektu a 31,1 % projektů bylo přímo zrušeno v některé fázi vývoje.

Tabulka 7: Shrnutí výsledků průzkumu úspěšnosti softwarových projektů

Kategorie	Podíl 1994	Podíl 2009	Hodnocení	Popis
Typ 1	16,2 %	32 %	Úspěch (success)	Na projektu byl dodržen čas, rozpočet a byly implementovány všechny požadavky na funkčnost podle úvodní specifikace.
Typ 2	52,7 %	44 %	Neúspěch (challenged)	Projekt byl dokončen, ale nebyl dodržen rozpočet, časový harmonogram anebo aplikace neobsahovala všechny požadované funkce.
Typ 3	31,1 %	24 %	Zrušení (impaired)	Projekt byl zrušen v průběhu realizace.

Zdroj: Vlastní zpracování podle The CHAOS Report. The Standish Group [online]. © 1995 The Standish Group International, Inc. [cit. 2022-02-17]. Dostupné z: https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf

Výsledky průzkumu shrnuje tabulka 7, ve které jsou projekty rozděleny na tři kategorie podle úspěšnosti včetně popisu těchto kategorií. Průzkum společnost provedla ve Spojených státech na vzorku 365 respondentů a 8 380 softwarových aplikací. Průzkum proběhl napříč obory pro společnosti různé velikosti, tj. pro malé, střední i velké firmy. (CHAOS Report, 1994, s. 2) Pro srovnání, Cobb ve své publikaci (2011, s. 10) uvádí výsledky CHAOS reportu z roku 2009, kde došlo k částečnému zlepšení. Například úspěšnost projektů se zvýšila z 16,2 % na 32 %, ale stále podle tabulky platí, že 66 % projektů nesplnilo svůj cíl.

3.1.1 Vodopádový model

Agilní metodiky ale nebyly podle Shora (2021, kap. 1) odpovědí na výše uvedené problémy s řízením projektů v oblasti informačních technologií, ale „odpovědí na odpověď“ na uvedené problémy. První reakcí velkých společností na neudržitelnou situaci byly pokusy o přesnější definici procesu vývoje, pečlivé plánování dílčích fází projektu, detailnější dokumentaci a celkově důslednější kontrolu procesu, která měla vést k vyšší úspěšnosti projektů. Podle této filozofie dílčí fáze softwarového projektu vycházejí ze životního cyklu projektu v pojetí tradičního projektového řízení a navazují na sebe ve formě „vodopádu“, viz obrázek 7.

Obrázek 7: Vodopádový model řízení softwarových projektů

Zdroj: KŘIVÁNEK, Mirko. Dynamické vedení a řízení projektů: Systémovým myšlením k úspěšným projektům. Praha 2019. Grada, kap. 4.

Obrázek 7 ilustruje využití vodopádového modelu v prostředí informačních technologií a vývoje softwarových aplikací. Podle tohoto modelu nejprve proběhne na začátku projektu sběr a specifikace požadavků, na který navazuje analýza a návrh kompletního řešení. Na návrh řešení navazuje vlastní vývoj, testování a na závěr akceptace a předání projektu. Samotný koncept vodopádového přístupu v kontextu tradičního projektového řízení pochází z 50. let, později v 70. letech tento model zdokumentoval Winston W. Royce (1970).

3.1.2 Cesta k agilnímu řízení projektů

I přes uvedená opatření se úspěšnost softwarových projektů významně nezvýšila, například podle již uvedeného CHAOS reportu a jeho aktualizací.

Jak uvádí již Brooks ve své klasické publikaci The Mythical Man-Month (1995):

„Základním omylem vodopádového modelu je očekávání, že projekt projde celým procesem vývoje pouze jedenkrát, že architektura a kvalita řešení je excelentní a vzniklé chyby jsou snadno a průběžně opravitelné v návaznosti na testování aplikace.“

Proto byly postupně představeny první jednodušší a méně omezující agilní metodiky pro vývoj aplikací jako opak komplexních na vodopádovém modelu založených metodik, například Extreme Programming (1999), Scrum (2022) a další. (Shore, 2021, kap. 1) Inspirací pro nové metodiky byly existující metodiky řízení softwaru a metodiky řízení projektů z prostředí průmyslové výroby. Z metodik řízení softwaru lze jmenovat například iterativní metodiku RUP²⁵ společnosti IBM²⁶ . Tato metodika nebude v textu dále rozebírána, její detaily jsou dobře popsány v publikaci Jacobson et. al. (1999). U metodik a postupů z prostředí řízení výroby je nejvýznamnější filozofie Lean (česky „štíhlá výroba“) automobilky Toyota, která byla později adaptována pro prostředí vývoje softwaru. Detaily a principy Leanu budou popsány v kapitole 3.2.

V druhé polovině 90. let se moderní metodiky pro vývoj aplikací postupně dostaly do popředí zájmu programátorů a vývojářů aplikací. Hlavním důvodem byly nepříliš úspěšné pokusy o řešení neudržitelné situace kolem projektového řízení vývoje aplikací pomocí metodik, založených na modelu vodopádu. Shore dále uvádí, že tyto metodiky byly z pohledu vývojářů neosobní až byrokratické a důležitější bylo dodržování procesu než schopnosti a dovednosti členů týmu. (Shore, 2021, kap. 1) Na základě zvýšeného zájmu komunity programátorů o moderní metodiky se sešla skupina předních vývojářů a tvůrců těchto metodik, aby sjednotili svůj další postup. Na základě tohoto setkání byl formulován Manifest agilního vývoje software, v originále The Agile Manifesto (Beck et al., 2001). Podrobnosti Manifestu budou diskutovány v kapitole 3.4.

3.2 Lean production

Lean (Lean production, česky také „štíhlá výroba“) označuje celkovou filozofii pro strategické řízení společnosti. Nejedná se o konkrétní metodiku projektového řízení, ale sadu principů a myšlenek. Základem Leanu je systematický přístup k zlepšování procesů ve firmě, redukce plýtvání a výroba produktů, které přináší konkrétní přidanou hodnotu pro zákazníka. Počátky štíhlé výroby spadají do první poloviny 20. století, kdy Henry Ford standardizoval proces výroby automobilů, zefektivnil výrobu a zajistil průběžný přísun materiálů podle potřeby. Tento přístup k produkci je později označován jako JIT²⁷ (viz dále).

Například Liker cituje Henryho Forda ve své knize The Toyota Way (2016, kap. 6):

„Dnešní standardizace je nutným základem, ze kterého bude vycházet zítřejší zlepšení. Pokud považujete standardizaci za to nejlepší, co dnes máme, ale zároveň počítáte s tím, že je předmětem dalšího zlepšování, někam se dostanete. Pokud považujete standardy za omezující, pokrok se zastaví.“ (přeloženo)

3.2.1 Principy Lean přístupu

Z pohledu Leanu jsou činnosti v rámci produkčního procesu rozlišovány podle hodnoty, kterou přináší pro zákazníka.

Svozilová (2011, kap. 2.1.2) rozlišuje:

• Činnosti, které přispívají k tvorbě hodnoty (tzv. value-adding).
• Činnosti, které k tvorbě hodnoty nepřispívají (non-value adding).
• Nezbytné činnosti, které k tvorbě hodnoty ale nepřispívají. Například legislativní požadavky (business-non-value-adding).
• Nepotřebné činnosti, které nepřináší žádnou hodnotu, tj. plýtvání (waste).

Cílem Lean přístupu je pak zlepšovat činnosti přínosné pro zákazníka a omezit plýtvání, tedy činnosti, které nejsou potřebné z pohledu zákazníka a výsledného produktu. Pro oblast vývoje softwarových aplikací uvádí Charles Cobb (2011, kap. 2) srovnání sedmi oblastí plýtvání ve srovnání s paralelními oblastmi z výrobního prostředí, viz tabulka 8. V tabulce jsou uvedeny dílčí oblasti plýtvání jak pro výrobu, tak pro vývoj software.

Tabulka 8: Porovnání plýtvání ve výrobě a při vývoji software

Sedm oblastí plýtvání u výroby	Sedm oblastí plýtvání při vývoji software
Nadbytečné zásoby materiálu nebo produktů	Nedokončená práce
Vyšší kvalita, než je požadováno	Nepotřebné a nadbytečné procesy
Nadprodukce (více nebo dříve, než je potřeba)	Nepotřebná a nepožadovaná funkcionalita
Zbytečná přeprava materiálu a produktů	Přepínání mezi dílčími úkoly
Čekání na další krok procesu	Čekání na další krok procesu
Nadbytečný pohyb, např. ve výrobní hale	Zpětné vracení se k úkolům
Defekty, zmetky, zbytečný odpad	Defekty, chyby, bugy

Zdroj: Vlastní zpracování podle COBB, Charles G. Making Sense of Agile Project Management: Balancing Control and Agility. New Jersey 2011. Wiley Professional Development (P&T), kap. 2.

Informace na jednotlivých řádcích tabulky spolu korelují, například nadprodukci ve výrobě odpovídá implementace nepotřebné funkcionality při vývoji aplikace. Původním autorem seznamu plýtvání je Toyota pro oblasti výroby (viz dále) a Mary Poppendieck pro oblasti vývoje software. (Cobb, 2011, kap. 2) Některé zdroje uvádí ještě osmou oblast, kterou je nevyužití plného potenciálu, schopností a dovedností zaměstnanců. (Svozilová, 2011)

Obrázek 8: Cyklus neustálého zlepšování PDCA

Zdroj: DOLEŽAL, Jan. Projektový management: Komplexně, prakticky a podle světových standardů. Praha 2016. Grada, kap. 3.4.5.

Lean metodiky typicky pracují s cyklem neustálého zlepšování a zpětné vazby, která vychází z předchozí zkušenosti s výsledným produktem. Příkladem může být Demingův cyklus neustálého zlepšování PDCA²⁸ , zobrazený na obrázku 8. Jak je patrné z obrázku, cyklus PDCA se skládá ze čtyř na sebe navazujících iterativních kroků: Plan (plánuj), Do (dělej), Act (jednej) a Check (prověř). (Doležal, 2016, kap. 3.4.5) Obdobný cyklus zpětné vazby Build-Measure-Learn (vytvoř, změř a pouč se pro příště) uvádí Ries ve své knize Lean Startup. (Ries, 2011, část 2) První ucelený systém založený na principech Lean výroby představila automobilka Toyota v 50. letech minulého století a nazvala jej Toyota Production System (TPS). Na tento systém později navázaly další filozofie a metodiky, například 5S²⁹, Six Sigma nebo Lean Six Sigma.

3.2.2 Toyota Production System

Toyota Production System je systém založený na koordinaci výroby a logistiky automobilky Toyota, včetně návaznosti celého systému na dodavatele a zákazníky. Celkové schéma systému TPS je zobrazeno na obrázku 9.

Obrázek 9: Schéma systému Toyota Production System

Zdroj: LIKER, Jeffrey K. a Karyn ROSS. The Toyota Way to Service Excellence: Lean Transformation in Service Organizations. New York 2016. McGraw-Hill Education, Prolog.

Základním kamenem systému je celková filozofie firmy Toyota a stabilita společnosti ve smyslu vysoké morálky lidí, spolehlivosti výrobních prostředků a dodržování standardizovaného systému produkce, viz dolní část obrázku se základy domu. Jádrem systému TPS je neustále zlepšování lidí i systému samotného (viz také kaizen v kapitole 3.3.1). Důležitou součástí systému jsou principy Just-in-Time a Jidoka, které jsou na obrázku zobrazeny jako pilíře. Just-in-Time znamená mít správný výrobek ve správný čas a v požadovaném počtu a nepřetržitý tok výroby, založený na taktu a systému tahu (pull). Jidoka je soubor opatření pro zvýšení kvality a předcházení chybám. Jednotlivé prvky systému se navzájem doplňují a navazují na jedinečnou kulturu společnosti Toyota. Cílem systému TPS je nejvyšší kvalita, tj. zlepšení bezpečnosti a kvality, snížení nákladů a času pro dodání a dosažení vysoké pracovní morálky. (Liker, 2016)

Cílem systému TPS je redukce ztrát a plýtvání, které jsou v systému označovány jako muda, muri a mura. Muda označuje plýtvání v sedmi hlavních oblastech výroby, viz tabulka 8 v předchozím textu. Muri znamená přetěžování strojů a lidí a upřednostňování krátkodobého řešení problémů (např. přesčasy) před jejich dlouhodobým řešením. Mura představuje nerovnováhu z pohledu času mezi požadavky zákazníků a zdroji, což typicky vede k přetěžování (muri) nebo plýtvání (muda).

Jak dále uvádí Sutherland (2014, kap. 5), označení muda, muri a mura přímo navazují na Demingův cyklus PDCA z obrázku 8:

• Krok Plan (plánuj) pomáhá odstranit muri, tj. přetěžování lidí a nástrojů.
• Krok Do (dělej) je prevencí pro mura, tj. nerovnováhu zdrojů a požadavků.
• Krok Check (prověř) pomáhá odstranit muda, tj. plýtvání a defekty.

3.2.3 Lean Startup

Později byla filozofie Lean výroby adaptována pro potřeby start-upů a vývoje softwaru v dynamickém a obtížně předvídatelným prostředí. Eric Ries představil ve své knize The Lean Startup (2011) sadu doporučení pro začínající firmy a start-upy.

Tato základní doporučení jsou:

1. Podnikatelé jsou všude (Enterpreneurs are everywhere).
2. Podnikání je řízení (Enterpreneurship is management).
3. Učení na základě zkušeností (Validated learning).
4. Efektivní zpětná vazba (Build-Measure-Learn).
5. Zodpovědnost za inovace (Innovation accountability).

Podnikatelé jsou všude: Nemusíte pracovat v garáži, abyste byli ve start-upu. Podnikání zahrnuje kohokoliv, kdo vytváří nové produkty a služby v podmínkách extrémní nejistoty. To znamená, že podnikatelé jsou všude a principy Lean startupu mohou fungovat v jakkoliv velké společnosti a v kterémkoliv oboru podnikání.

Podnikání je řízení: Start-up je nejen produkt, ale zároveň i instituce, která potřebuje nový způsob řízení specificky orientovaný na prostředí extrémní nejistoty. Jako podnikatel by měl být označen každý, kdo pracuje ve společnostech, jejichž růst je závislý na inovacích.

Učení na základě zkušeností: Start-upy existují nejen za účelem zisku a uspokojení zákazníků, ale i učení a získávání znalostí s budováním udržitelného obchodního modelu. Toto učení lze validovat prováděním experimentů, které podnikatelům umožní ověřit každý krok jejich vize.

Efektivní zpětná vazba: Základem fungování start-upu je přeměna nápadů na produkty a sledování reakce zákazníků na tyto produkty. Produkt je následně vylepšován nebo pozastaven na základě reakce zákazníků. Veškeré procesy ve start-upu jsou orientovány na co nejrychlejší zpětnou vazbu.

Zodpovědnost za inovace: Pro neustálé zlepšování výstupů je potřeba měřit pokrok, nastavovat cíle a práci.

Klíčovým principem metodiky Lean Startupu je rychlá a efektivní zpětná vazba v cyklu Build-Measure-Learn (vytvoř, změř a pouč se pro příště). V praxi to znamená nejprve úvodní identifikaci řešeného problému, následně rychlý vývoj výchozího produktu (MVP³⁰ ) a jeho představení zákazníkům pro nastartování cyklu zpětné vazby. Cílem je minimalizace času průchodu cyklem, tedy co nejrychlejší zpětná vazba. (Ries, 2011, část 2)

3.3 Lean metodiky

V dalším textu budou krátce představeny Lean metodiky a postupy Kaizen a Kanban.

3.3.1 Kaizen

Kaizen (z japonštiny 改, „kai“, změna a 善, „zen“, k lepšímu) je filozofie a metodika, jejímž cílem je neustálé každodenní zdokonalování ve všech oblastech života. (Kaizen, 2022) Základní principy kaizenu jsou zobrazeny na obrázku 10.

Obrázek 10: Základní principy kaizenu

Zdroj: Kaizen: What is KAIZEN™. Kaizen Institute [online]. © 1985-2022 Kaizen Insitute [cit. 2022-02-22]. Dostupné z: https://www.kaizen.com/what-is-kaizen.

Tyto základní principy kaizenu podle obrázku jsou:

• Poznat svého zákazníka a hodnotu pro něj (Know your customer).
• Zaměřit se na tvorbu hodnoty pro zákazníka a redukci plýtvání (Let it flow).
• Následovat akci, kde je hodnota pro zákazníka vytvářena (Go to gemba).
• Stanovit cíle a poskytnout potřebné nástroje a podporu týmu (Empower people).
• Řídit se reálnými fakty, být transparentní (Be transparent). (Kaizen, 2022)

3.3.2 Kanban

Kanban (v japonštině 看板, „cedule“) je plánovací systém, který vznikl v Japonsku pro potřeby Just-in-Time výroby v automobilovém průmyslu a později byl adaptován pro další oblasti, například pro vývoj software. Základním principem kanbanu je vizualizace úkolů pro efektivní komunikaci, omezený počet najednou řešených úkolů a neustálé iterativní vyhodnocování výstupů. (Kanban, 2022) Základním nástrojem metodiky kanban v prostředí vývoje software je kanban board, viz obrázek 11.

Obrázek 11: Kanban board

Zdroj: Jira Kanban boards. Atlassian [online]. © 2022 Atlassian [cit. 2022-02-24]. Dostupné z: https://www.atlassian.com/software/jira/features/kanban-boards

Základní sloupce pro rozdělení úkolů jsou: To do (udělat), In progress (ve vývoji), Review (probíhá kontrola) a Done (hotovo). Jednotlivé úkoly jsou podle aktuálního stavu přesouvány zleva doprava mezi sloupci. Maximální počet úkolů pro každý stav je pevně daný podle kapacitních možností týmu a zdrojů. Důvodem tohoto omezení je zajištění plynulého toku činností, minimalizace přepínání kontextu mezi rozpracovanými úkoly a omezení hromadění práce, když například počet vývojářů přesahuje počet testerů.

3.4 Manifest agilního vývoje softwaru

Manifest agilního vývoje softwaru (Beck et al., 2001) definuje základní body filozofie agilního vývoje, na kterých se jeho autoři shodli při setkání tvůrců prvních agilních metodik, jak již bylo uvedeno v kapitole 3.1.2. Základem Manifestu jsou čtyři základní hodnoty a dvanáct zásad pro agilní projektové řízení a vývoj software.

3.4.1 Základní hodnoty agilního vývoje

Manifest agilního vývoje software říká „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.

Hodnoty vlevo (tučně) jsou z pohledu agilního přístupu k vývoji softwaru významnější než hodnoty tradičního přístupu k vývoji, uvedené vpravo. To ale neznamená, že nově definované hodnoty jsou úplnou náhradou původních hodnot. Tradiční hodnoty jsou stále důležité, ale méně významné z pohledu agilního přístupu: „Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více.“ (Beck et al., 2001)

3.4.2 Základní principy agilního vývoje

Na základní hodnoty agilního vývoje aplikací navazuje dvanáct základních principů pro agilní projektové řízení a vývoj software:

1. Naší nejvyšší prioritou je vyhovět zákazníkovi včasným a průběžným dodáváním hodnotného softwaru.
2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
7. Hlavním měřítkem pokroku je fungující software.
8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
10. Jednoduchost (umění maximalizovat množství nevykonané práce) je klíčová.
11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.
12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.

Základní principy agilního řízení projektů navazují na filozofii Lean produkce, jejich cílem je omezení plýtvání, snížení rizik a zvýšení efektivity při vývoji softwaru. Manifest zároveň přidává do řízení projektů a řízení projektových týmů nový prvek dynamiky. V kontrastu s tradičním projektovým řízením jsou změnové požadavky a iterativní vývoj vítány, nikoliv odmítány. (Křivánek, 2019, kap. 3.2.1)

3.5 Agilní projektové řízení

Cobb (2011, s. 57) i Svozilová (2019, kap. 11.2.2) shodně uvádí hlavní cíle a výhody implementace agilního projektového řízení podle Jima Highsmitha (2009):

• Neustálá inovace.
• Průběžné přizpůsobování produktu.
• Zrychlené zavedení produktu na trh.
• Zvýšení přizpůsobivosti procesů a lidí.
• Zajištění spolehlivosti.

Neustálá inovace znamená, že produkt nebo jiný výstup projektu odpovídá aktuálním potřebám zákazníka v dynamicky se měnícím prostředí. Průběžné přizpůsobování produktu znamená, že je produkt připraven a schopen uspokojit i budoucí potřeby zákazníka. Zrychlené zavedení produktu na trh je důležité pro zlepšení návratnosti investice (ROI³¹) a správné načasování vstupu na trh. Zvýšení přizpůsobivosti lidí a procesů je nezbytné pro pružnější reakci na změnové požadavky i změny vnějšího prostředí projektu. Zajištění spolehlivosti produktu podporuje úspěch a ziskovost zadavatele projektu.

3.5.1 Principy agilního řízení projektů

Doležal (2016, kap. 4.3) dále rozlišuje mezi využíváním konkrétní agilní metodiky a obecnými principy agilního řízení projektů, které vypovídají o tom, jestli je daný projekt řízen agilně.

Hlavní dva principy agilního řízení projektů podle Doležala jsou:

• Inkrementální dodávky.
• Iterativní postup.

Inkrementální dodávky znamenají dodávání projektu v rámci pravidelných funkčních přírůstků, kdy se projektový tým soustředí pouze na aktuální dílčí část celého projektu a minimalizuje objem zároveň rozpracovaných požadavků. Projekt samotný je rozdělen do iterací s pevně danou stejnou délkou.

Z hlavních principů agilního řízení projektů vychází navazující principy:

• Aktivní „agilní“ přístup týmu.
• Aktivní zapojení zákazníka do projektu.
• Multifunkční týmy napříč obory a rolemi.
• Pravidelná revize požadavků a rozsahu projektu (scope).

U projektu se očekává aktivní „agilní“ přístup všech členů agilního týmu, aktivní zapojení zákazníka, multifunkční fungování členů týmu a pravidelná revize požadavků. Zákazník musí být přítomný po celou dobu vývoje kvůli zpětné vazbě projektovému týmu a průběžnému upřesňování změn a požadavků. Multifunkční fungování znamená úzkou spolupráci členů týmu v různých rolích, např. analytik a vývojář. (Doležal, 2011, kap. 4.3)

3.5.2 Metodiky agilního řízení projektů

Projekt může být podle Doležala řízen agilně i bez konkrétní projektové metodiky (2016, kap. 4.3), nicméně běžným standardem u agilního řízení projektů je využití některé z konkrétních metodik, viz dále. Životní cyklus projektu je flexibilní a zahrnuje krátké iterace. Zákazník je členem projektového týmu a v každé iteraci je zákazníkovi dodán funkční prototyp aplikace ke schválení. Každý den probíhají rychlé operativní porady pro koordinaci týmu, probíhá výměna informací a řešení problémů v týmu bez tradičního řízení a úkolování. Klíčové problémy jsou řešeny v týmu a je na ně vyhrazen dostatek času a prostoru v každém sprintu.

Nejpoužívanější metodiky agilního řízení projektů na základě agilního reportu společnosti Digital.ai pro rok 2021 (Agile Report, 2021) jsou zobrazeny na obrázku 12. Podle reportu je aktuálně nejpoužívanější metodikou Scrum (2022) s 66% podílem. Za touto metodikou následují hybridní metodiky odvozené od Scrumu: druhý v pořadí je metodika ScrumBan (Ladas, 2008) s 9 % a třetí metodika Scrum/XP³² s 6 %. ScrumBan kombinuje metodiky Scrum a Kanban, zatímco Scrum/XP kombinuje postupy metodik Scrum a Extreme Programming (1999). Report na rozdíl od textu této práce navzájem nerozlišuje Lean a agilní metodiky.

Obrázek 12: Nejpoužívanější agilní metodiky v roce 2021

Zdroj: Agile Report. 15th Annual State Of Agile Report. Digital.ai: Intelligent Value Stream Management Platform [online]. © 2021 Digital.ai Software Inc. [cit. 2022-02-20]. Dostupné z: https://digital.ai/resource-center/analyst-reports/state-of-agile-report.

Zároveň se nabízí analogie mezi Lean přístupem a agilním řízením projektů jako základními filozofiemi, ze kterých vychází konkrétní metodiky. Přehled jednotlivých metodik a jejich návaznost na Lean a agilní vývoj je uveden v tabulce 9.

Tabulka 9: Souhrnný přehled Lean a agilních metodik

Lean metodiky	Agilní metodiky
Kanban Kaizen a 5S Six Sigma Lean Six Sigma Lean startup	Scrum ScrumBan Scrum/XP Extreme Programming (XP)

Zdroj: Vlastní zpracování.

Tabulka 9 přehledně shrnuje všechny Lean a agilní metodiky, které byly uvedeny v textu této práce. V následující kapitole 3.6 bude více do detailu popsán Scrum jako nejpoužívanější metodika agilního projektového řízení.

3.6 Scrum

Scrum je metodika a framework pro rozvoj složitých systémů v dynamickém prostředí, původně využívaná pro agilní řízení a vývoj softwarových produktů. Jedná se o velmi flexibilní a přizpůsobivou agilní metodiku, ideální pro kontinuální a inkrementální dodávání inovací. Termín scrum pochází z prostředí rugby (ze „scrumage“, mlýn) a označuje situaci ve hře, kdy se tým společnými silami snaží získat a udržet míč (Doležal, 2016, kap. 4.4.1) Metodika se postupně rozšířila do dalších oborů, od inženýrství po výzkum a vývoj. S označením „scrum“ přišli jako první Hirotaka Takuchi a Ikujiro Nonaka ve svém článku The New New Product Development Game (1986) na základě výzkumu fungování týmů v inovativních společnostech ve své době, například Honda, 3M nebo Xerox. Na jejich práci navázali Jeff Sutherland a Ken Schwaber, kteří na základě uvedeného výzkumu představili metodiku Scrum pod názvem Scrum Development Process. Důležitou inspirací pro metodiku Scrum byly také principy Lean produkce a systému, používaného ve společnosti Toyota (viz kapitola 3.2.2). (Sutherland, 2014, kap. 2)

V souvislosti s metodikou Scrum budou v dalších textu preferovány anglické termíny s krátkým vysvětlením, jelikož české alternativy buď neexistují anebo se prakticky nepoužívají. Kompletní slovník termínů metodiky Scrum je dostupný v příloze A.

3.6.1 Základní přehled metodiky

Základní součásti metodiky scrum jsou týmové role, ceremonie a nástroje. Součástí Scrumu jsou sprinty, které se iterativně opakují v pevném intervalu, viz obrázek 13.

Obrázek 13: Projekt jako proces změny z počátečního stavu na cílový stav

Zdroj: DOLEŽAL, Jan. Projektový management: Komplexně, prakticky a podle světových standardů. Praha 2016. Grada, kap. 1.3.1.

Nejběžnější délka sprintu je 2 týdny. Na začátku projektu je na základě požadavků na produkt sestaven úvodní product backlog (fronta všech požadavků), který je následně aktualizován a prioritizován. Z product backlogu jsou následně požadavky zařazovány do sprint backlogu (fronty požadavků pro daný sprint) na základě priority, kterou určuje product owner (vlastník produktu). Na konci sprintu je k dispozici plně funkční přírůstek produktu, který lze prezentovat zákazníkovi a nasadit do produkčního prostředí. V průběhu sprintu se projektový tým pravidelně schází na operativních a plánovacích poradách. (Doležal, 2016, kap. 4.4.1)

3.6.2 Ceremonie a porady

Nedílnou součástí metodiky Scrum jsou základní ceremonie a každodenní komunikace mezi členy projektového týmu. Nejdůležitější ceremonií je daily (denní) stand-up. Další schůzky probíhají obvykle 1x v každém sprintu: sprint planning (plánování sprintu), demo/review a retrospective (retrospektiva). Denní stand-up probíhá každý den ve stejnou dobu před začátkem vlastní práce, trvá nejvýše 15 minut a účastní se jej projektový tým a Scrum master.

Na stand-upu každý člen týmu zodpoví tří základní otázky:

• Co jsem včera udělal/a pro dokončení sprintu?
• Co udělám dnes?
• Vím o nějaké překážce, která mě blokuje nebo omezuje v práci?

Cílem stand-upu je revidovat postup a zjišťovat potenciální překážky při rozvoji produktu (ale neřešit je na této schůzce). (Sutherland, 2014, kap. 4)

Sprint planning je určený pro naplánování požadavků pro budoucí sprint. Prioritu požadavků v backlogu určuje product owner na základě jejich přínosu pro projekt, tým pak určuje, kolik požadavků je reálně schopen zpracovat. Naplánovaný rozsah práce se v průběhu sprintu již nemění, nové požadavky jsou zařazovány do product backlogu. (Doležal, 2016, kap. 4.4.3) Na demu a review na konci sprintu produktový tým prezentuje nově dokončenou část projektu zákazníkovi. Změny jsou akceptovány na základě rozhodnutí product ownera, akceptace je vždy výhradní (ano/ne). Na závěr sprintu probíhá retrospektiva jako zpětné ohlédnutí za sprintem. Cílem této ceremonie je upřímná zpětná vazba, diskuze úspěchů a neúspěchů a návrhy na zlepšení pro další sprint. (Sutherland, 2014, kap. 7) Součástí sprintu mohou být i další schůzky, například backlog refinement a grooming pro upřesňování požadavků.

3.6.3 Projektový tým

V metodice Scrum jsou rozlišovány tři základní týmové role:

• Člen projektového týmu.
• Product owner (vlastník produktu).
• Scrum master.

Hlavním úkolem členů projektového týmu je rozvoj produktu. Projektový tým je multifunkční, jsou v něm zastoupeny všechny nezbytné role a tým je v úzkém kontaktu se zákazníkem. Doporučený počet členů týmu je 7, protože při vyšším počtu členů týmu se významně zvyšuje počet komunikačních kanálů a tím i složitost komunikace. (Brooks, 1995, s. 19) Inspiraci pro složení multifunkčního týmu lze vysledovat také u Brookse, který definoval tzv. surgical team (chirurgický tým) s předepsanými rolemi, které jsou ale zároveň vzájemně zastupitelné. (Brooks, 1995, kap. 3)

Product owner zastupuje zákazníka, poskytuje týmu specifikaci cílového produktu a je zodpovědný za akceptaci výstupů. Product owner je vlastníkem product backlogu a určuje, jaké požadavky mají prioritu na základě jejich přínosu pro zákazníka. Scrum master aktivně podporuje využívání principů metodiky a agilního vývoje, odstraňuje překážky pro rozvoj projektu a provádí údržbu Scrum nástrojů. Scrum master nemá rozhodovací pravomoce. Na rozdíl od tradičního projektového řízení také není součástí projektového týmu role projektového manažera. Důvodem je přenesení pravomocí projektového manažera na tým, kdy jsou pravomoci projektového manažera rovnoměrně rozděleny mezi výše uvedené týmové role. (Doležal, 2016, kap. 4.4.2)

3.6.4 Backlog a nástroje

Požadavky v agilním projektu jsou evidovány v product backlogu, který představuje zásobník všech informací a realizovaných požadavků. Z product backlogu jsou požadavky následně zařazovány do sprintů a sprint backlogů pro jednotlivé sprinty. Nejprve jsou zařazovány nejpřínosnější požadavky z pohledu zákazníka a následně nejvíce rizikové součásti. Zadávání požadavků probíhá ve formě tzv. user stories (příběhy uživatelů). Každá user story obsahuje zákazníka, pro kterého je změna určena, popis nové funkcionality a očekávání, které tato nová funkcionalita naplňuje. Například „Jako uživatel potřebuji předvyplnit data ze systému XY, abych ušetřil čas a eliminoval chybovost při ručním vyplnění formuláře.“ (Doležal, 2016, kap. 4.4.4) User stories mohou být dále seskupovány do větších celků, tzv. epiců.

Odhadování pracnosti user stories probíhá přes tzv. story points (body náročnosti), které představují abstraktní jednotku. Konkrétní hodnota této jednotky je vázána na konkrétní projekt a projektový tým. Cílem použití story pointů je vyhnout se při odhadování konkrétním časovým jednotkám, které vedou ke zkresleným odhadům. Pro odhadování existují různé nástroje, například plánovací poker s čísly (počty story pointů), která tvoří Fibonacciho posloupnost, tj. 1, 2, 3, 5, 8, 13 atd. Každý člen týmu skrytě vybere jedno číslo a následně probíhá diskuze nad možným řešením a složitostí požadavku, dokud nedojde ke shodě v týmu. (Sutherland, 2014, kap. 6)

Důležitým prvkem Scrumu je podobně jako v případě Kanbanu vizualizace úkolů, k tomuto účelu slouží Scrum board (tabule), burndown chart (graf tempa práce) a další grafy. Scrum board je tabule s požadavky, která je velmi podobná Kanban boardu (viz kapitola 3.3.2). Příklad Scrum boardu je zobrazen na obrázku 14.

Obrázek 14: Scrum board

Zdroj: Jira Scrum boards. Atlassian [online]. © 2022 Atlassian [cit. 2022-02-24]. Dostupné z: https://www.atlassian.com/software/jira/features/scrum-boards

Scrum board je vertikálně rozdělen do sloupců jako například To do (udělat), In progress (ve vývoji), Review (zkontrolovat) a Done (hotovo). Dílčí úkoly jsou podle stavu jejich zpracování přesouvány zleva doprava mezi sloupci. Přehled může být dále rozdělen i horizontálně, typické je rozdělení podle členů týmu nebo podle user stories.

---

²⁴ Comprehensive Human Appraisal for Originating Software.

²⁵ Rational Unified Process.

²⁶ International Business Machines.

²⁷ Just-in-Time.

²⁸ Plan-Do-Check-Act.

²⁹ Sort, Set in order, Shine, Standardize, Sustain.

³⁰ Minimum Viable Product.

³¹ Return on Investment.

³² Extreme programming.

[Strany 30-49]