Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Podpora agilního vývoje softwaru ve velmi malých entitách pomocí normy ISO/IEC 29110
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Informační systémy a technologie
Autor: Bc. Vojtěch Podaný
Vedoucí diplomové práce: doc. Ing. Alena Buchalcevová, Ph.D.
Praha, prosinec 2020
Prohlášení
Prohlašuji, že jsem diplomovou práci „Podpora agilního vývoje softwaru ve velmi malých entitách pomocí normy ISO/IEC 29110“ vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze dne 7. prosince 2020 ...
Vojtěch Podaný
Poděkování
Chtěl bych velmi poděkovat vedoucí diplomové práce doc. Ing. Aleně Buchalcevové, Ph.D.
za trpělivost a rady poskytnuté během psaní této práce. Dále děkuji respondentům hodnotících rozhovorů za jejich čas a ochotu.
Abstrakt
Diplomová práce „Podpora agilního vývoje softwaru ve velmi malých entitách pomocí normy ISO/IEC 29110“ se zabývá tématem standardizace projektů vývoje softwaru řízených pomocí agilních metodik. Ve své teoretické části práce představuje agilní metodiky vývoje softwaru, řadu mezinárodních norem ISO/IEC 29110 Lifecycle profiles for Very Small Entities a její nový přírůstek, technickou zprávu 5-4: Agile Software Development Guidelines a dále původní implementační balíček Projektové řízení pro Základní profil a modelovací jazyk ArchiMate.
Hlavního cíle práce je dosaženo v praktické části práce. Zde je na základě technické zprávy ISO/IEC 29110 Part 5-4: Agile Software Development Guidelines vytvořen nový implementační balíček Agilní projektové řízení pro Základní profil skupiny norem ISO/IEC 29110 pro softwarové inženýrství a jeho model v jazyce ArchiMate.
Hlavním přínosem práce je možnost použití implementačního balíčku Agilní projektové řízení pro Základní profil skupiny norem ISO/IEC 29110 pro softwarové inženýrství pro zavedení této normy v oblasti projektového řízení do velmi malé entity zabývající se agilním vývojem softwaru.
Klíčová slova
Agilní metodiky, ArchiMate, implementační balíček Agilní projektové řízení, ISO/IEC 29110, Scrum, Základní profil
JEL klasifikace
L15, M15, O31
Abstract
The diploma thesis “Supporting the agile software development in Very Small Entities using the ISO/IEC 29110 standard” addresses the topic of standardization of software development projects managed with agile methodologies. In its theoretical part, it describes agile software development methodologies, series of international standards ISO/IEC 29110 Lifecycle profiles for Very Small Entities and its new addition, technical report 5-4: Agile Software Development Guidelines, original Project Management deployment package and ArchiMate modelling language.
The main goal of the work is achieved in its practical part where the new Agile Project Management deployment package for Basic Profile of the ISO/IEC 29110 series for Software Engineering and its model in ArchiMate are presented. The deployment package is based on the ISO/IEC 29110 Part 5-4: Agile Software Development Guidelines.
The main benefit of the work is the use of the Agile Project Management deployment package for the Basic Profile of the ISO/IEC 29110 group of software engineering for the implementation of this standard in the field of project management in a Very Small Entity engaged in agile software development.
Keywords
Agile Project Management Deployment Package, Agile Methodologies, ArchiMate, Basic Profile, ISO/IEC 29110, Scrum
JEL Classification
L15, M15, O31
Obsah
Úvod ... 12
Vymezení tématu a důvod výběru tématu ... 13
Cíle práce ...14
Použité metody ...14
Omezení práce ... 15
Cílová skupina ... 15
Předpokládané výstupy a očekávané přínosy ...16
Struktura práce ...16
1 Rešerše odborných prací a zdrojů ... 18
1.1 Odborné publikace a články ... 18
1.2 Akademické práce ... 20
1.3 Ostatní zdroje ... 21
2 Agilní metodiky vývoje softwaru ... 24
2.1 Základní principy agilního přístupu ... 24
2.2 Využití agilních metodik v současnosti ... 26
2.3 Scrum ... 27
2.3.1 Projektový tým a jeho role ... 28
2.3.2 Artefakty v metodice Scrum ... 28
2.3.3 Sprint a jeho události ... 29
2.4 Extrémní programování ... 31
3 Skupina mezinárodních norem ISO/IEC 29110 ... 33
3.1 Struktura norem ... 33
3.2 Profily norem ... 34
3.2.1 Vstupní profil ... 36
3.2.2 Základní profil ... 37
3.2.3 Střední profil ... 37
3.2.4 Pokročilý profil ... 38
3.3 Základní profil pro softwarové inženýrství ... 38
3.3.1 Role v Základním profilu ...41
3.3.2 Proces Řízení projektu ...41
3.3.3 Proces Implementace softwaru ... 44
3.4 Příručka pro agilní vývoj softwaru ... 46
3.4.1 Prvky a definice použité v Příručce pro agilní vývoj softwaru ... 48
3.4.2 Role v Příručce pro agilní vývoj softwaru ... 49
3.4.3 Procesy v Příručce pro agilní vývoj softwaru ... 52
3.4.4 Proces Agilní řízení projektu ... 53
3.4.5 Proces Agilní implementace softwaru ... 56
3.4.6 Připomínky k technické zprávě ISO/IEC 29110-5-4 ... 59
4 Implementační balíček Agilní projektové řízení pro Základní profil ...61
4.1 Implementační balíčky řady norem ISO/IEC 29110 ...61
4.2 Implementační balíček Projektové řízení ... 62
4.2.1 Popis procesů, činností, úkolů, kroků, rolí a produktů ... 63
4.2.2 Naplánování projektu... 65
4.2.3 Realizace plánu projektu ... 65
4.2.4 Hodnocení a kontrola projektu ... 66
4.2.5 Ukončení projektu ... 66
4.3 Revize českého překladu implementačního balíčku Projektové řízení pro Základní profil ... 66
4.4 Vytvoření nového implementačního balíčku Agilní projektové řízení pro Základní profil ... 67
4.4.1 Postup tvorby implementačního balíčku Agilní projektové řízení ... 67
4.4.2 Technický popis ... 68
4.4.3 Definice ... 68
4.4.4 Vztah k ISO/IEC 29110 ... 68
4.4.5 Detailní popis procesů, činností, úkolů, kroků, rolí a produktů ... 69
4.4.6 Šablony ... 70
4.4.7 Příklad ... 71
4.4.8 Kontrolní seznam ... 71
4.4.9 Nástroje ... 71
4.4.10 Odkazy na další standardy ... 74
4.4.11 Odkazy ... 74
4.4.12 Formulář pro hodnocení ... 75
5 Model implementačního balíčku Agilní projektové řízení pro Základní profil v jazyce ArchiMate ... 76
5.1 Modelovací jazyk ArchiMate ... 76
5.2 Model Základního profilu v jazyce ArchiMate ... 77
5.2.1 Mapování prvků Základního profilu do modelu v jazyce ArchiMate ... 77
5.2.2 Rozšíření modelu Základního profilu ... 78
5.3 Model implementačního balíčku Agilní projektové řízení... 79
6 Ověření použitelnosti implementačního balíčku Agilní projektové řízení ... 82
6.1 Způsob vyhodnocení ... 82
6.2 Návrh podoby rozhovoru ... 83
6.3 Představení respondentů ... 84
6.4 Poznatky z rozhovorů ... 84
6.4.1 Názor na agilní přístup k vývoji softwaru ... 85
6.4.2 Vnímání certifikací, norem, standardů ... 86
6.4.3 Rozdíl v projektovém řízení a vývoji softwaru ... 86
6.4.4 Přínos implementačního balíčku ... 87
6.4.5 Struktura a podoba implementačního balíčku... 87
6.4.6 Zdroje k pochopení balíčku ... 88
6.4.7 Prvky implementačního balíčku ... 89
6.4.8 Nejasnosti ohledně Produktového backlogu a jeho naceňování... 89
6.4.9 Praktické rady ... 90
6.4.10 Hodnotící formulář implementačního balíčku ...91
6.5 Výsledné vyhodnocení ... 93
6.5.1 Hodnocení implementačního balíčku ... 93
6.5.2 Návrhy na vylepšení implementačního balíčku ... 93
Závěr ... 95
Použitá literatura ... 97
Přílohy ... 100
Příloha A: PDSR Canvas ... 101
Příloha B: Implementační balíček Agilní projektové řízení v českém jazyce ... 104
Příloha C: Text průvodního e-mailu hodnotícího rozhovoru ... 156
Příloha D: Soupis připomínek k nové technické zprávě ISO/IEC 29110-5-4 v anglickém jazyce ... 157
Seznam obrázků
Obrázek 1 Porovnání agilního a vodopádového modelu vývoje softwaru. Zdroj:
(POTIFOB, 2020) ... 25
Obrázek 2 Obsah metodiky Scrum. Zdroj: (Menčík, 2019) ... 30
Obrázek 3 Přehled obsahu normy ISO/IEC 29110. Zdroj: autor podle (ISO/IEC JTC1 SC7 WG24, 2019 a SPI Center, 2019a) ... 35
Obrázek 4 Procesy Vstupního profilu. Zdroj: (Laporte, 2016)... 37
Obrázek 5 Procesy Základního profilu. Zdroj: (Laporte, 2016) ... 37
Obrázek 6 Procesy středního profilu. Zdroj: (Laporte, 2016) ... 38
Obrázek 7 Procesy pokročilého profilu. Zdroj: (Laporte, 2016) ... 39
Obrázek 8 Procesy Základního profilu normy ISO/IEC 29110. Zdroj: (SPI Center, 2019d) ... 40
Obrázek 9 Proces Řízení projektu Základního profilu. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2011)... 43
Obrázek 10 Proces Implementace softwaru Základního profilu. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2011) ... 47
Obrázek 11 Přehled procesu agilního řízení projektu. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2020) ... 55
Obrázek 12 Přehled procesu agilní implementace softwaru. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2020) ... 58
Obrázek 13 Činnosti procesu Řízení projektu. Zdroj: (O’Connor, 2009) ... 65
Obrázek 14 Činnosti implementačního balíčku Agilní projektové řízení. Zdroj: (autor) 69 Obrázek 15 Nástroje používané pro agilní projektové řízení respondenty průzkumu 14th Annual State of Agile. Zdroj: (Digital.ai, 2020) ... 72
Obrázek 16 Nástroje pro agilní projektové řízení doporučované respondenty průzkumu 14th Annual State of Agile. Zdroj: (Digital.ai, 2020) ... 73
Obrázek 17 ArchiMate Full Framework. Zdroj: (The Open Group, 2019) ... 77
Obrázek 18 Celkový pohled na model implementačního balíčku Agilní projektové řízení v jazyce ArchiMate. Zdroj: (autor) ... 81
Seznam tabulek
Tabulka 1 Části normy ISO/IEC 29110. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2020), v překladu (Hemžal, 2019) ... 34 Tabulka 2 Prvky Základního profilu. Zdroj: (Dlugošová, 2015) ... 40 Tabulka 3 Role Základního profilu. Zdroj: (ISO/IEC 29110 JTC1 SC7 WG24, 2011) ...41 Tabulka 4 Vstupní, interní a výstupní produkty procesu projektové řízení. Zdroj: autor dle (ISO/IEC JTC1 SC7 WG24, 2011) ... 42 Tabulka 5 Vstupní, interní a výstupní produkty procesu Implementace softwaru. Zdroj:
autor dle (ISO/IEC JTC1 SC7 WG24, 2011) ... 45 Tabulka 6 Role zahrnuté do procesu agilního řízení projektu a implementace softwaru.
Zdroj: autor dle (ISO/IEC JTC1 SC7 WG24, 2020) ... 49 Tabulka 7 Mapování rolí mezi Základním profilem ISO/IEC 29110 a rolemi v agilním prostředí. Zdroj: autor dle (ISO/IEC JTC1 SC7 WG24, 2020) ... 50 Tabulka 8 Vstupní, interní a výstupní produkty procesu agilní projektové řízení. Zdroj:
autor dle (ISO/IEC JTC1 SC7 WG24, 2020) ... 54 Tabulka 9 Vstupní, interní a výstupní produkty procesu implementace softwaru. Zdroj:
autor dle (SO/IEC JTC1 SC7 WG24, 2020) ... 57 Tabulka 10 Typický obsah implementačního balíčku. Zdroj: (ISO/IEC JTC1 SC7 WG24, 2011)...61 Tabulka 11 Produkty Základního profilu ISO/IEC 29110 použité v implementačním balíčku Projektové řízení. Zdroj: (ISO/IEC 29110) ... 63 Tabulka 12 Mapování činností mezi Příručkou pro agilní vývoj softwaru a implementačním balíčkem Agilní projektové řízení. Zdroj: autor ... 70 Tabulka 13 Mapování prvků normy ISO/IEC 29110 do notace jazyka ArchiMate (elementy). Zdroj: (Hemžal, 2019) ... 78 Tabulka 14 Mapování prvků normy ISO/IEC 29110 do notace jazyka ArchiMate (vztahy).
Zdroj: (Hemžal, 2019) ... 79 Tabulka 15 Otázky a odpovědi v hodnotícím formuláři. Zdroj: autor ...91
Seznam zkratek
AT Agile Task
CUS Customer
DevOps Přístup k vývoji software, který vyžaduje komunikaci, spolupráci a integraci mezi vývojáři a provozem informačních technologií
DSR Design Science Research
DT Development Team
IEC International Electrotechnical Commission ISO International Organization for Standardization JTC Joint Technical Comitee
PDSR Practitioner Design Science Research
PM Project Management PJM Project Manager
PO Product Owner
SC Sub-Comitee
SI Software Implementation
SM Scrum Master
TE Task Event
TL Technical Leader TR Technical Report VME Velmi malá entita
WG Working Group
WP Work Product
XP eXtreme Programming
Úvod
Jedním z hlavních aspektů úspěchu nebo naopak neúspěchu jakéhokoliv projektu je projektové řízení, tedy sada činností, které řídí a kontrolují plánování, průběh a ukončení projektu. Projekty, které mají za cíl vývoj softwaru, se v tomto ničím neliší. Software musí být implementován v relativně krátké době, musí uspokojit rychle se měnící požadavky zákazníků a musí být pořízen za rozumnou cenu (Buchalcevová, 2018). To v souhrnu činí vývoj softwaru komplexním a stále ne všechny projekty vývoje softwaru končí úspěšně (Standish Group, 2015).
Tradiční přístupy k vývoji softwaru se snaží vylepšit jednotlivé procesy tvorby softwaru pomocí velkého množství mezinárodních norem, referenčních modelů a dalších standardů a nástrojů. Tyto standardy například definují, jak má být software vyvíjen, jaké kvality má výsledný produkt dosahovat či jak má být zabezpečený. Dodržování mezinárodních norem a dalších standardů napomáhá podnikům zatraktivnit svůj produkt, protože je poskytována záruka, že bude kvalitní a uspokojí své zákazníky, a také podnikům otevírá mezinárodní trh (Buchalcevová, 2018). Pro potřeby velmi malých podniků, které jsou významné pro ekonomiky jednotlivých států, ale doposud pro ně neexistovaly vhodné nástroje, byla vytvořena řada mezinárodních norem ISO/IEC 29110 Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities, která přizpůsobuje zlepšování procesů vývoje softwaru a systému jejich specifickým byznys modelům a cílům a limitovaným finančním i lidským zdrojům (Buchalcevová, 2018).
Tato řada norem se skládá z pěti částí, které se dělí na mezinárodní normy a technické zprávy. Technické zprávy jsou dokumenty informativní povahy, které slouží v kontextu ISO/IEC 29110 jako instrukce pro zavedení profilů definovaných v mezinárodních normách. Profil lze popsat jako kolekci vybraných prvků jiných mezinárodních norem, které mají účel zlepšit procesy při vývoji softwaru ve velmi malých entitách a doložit způsobilosti těchto entit v daných činnostech (SPI Center, 2019a). V době vzniku diplomové práce je popsána skupina obecných profilů zaměřující se na ty velmi malé entity, které nevyvíjí kritický software či systémy a nejsou zatíženy žádnými neobvyklými situačními faktory.
Skupiny profilů představují kolekci jednotlivých profilů, které spolu souvisí skladbou procesů, úrovní způsobilosti nebo obojím (SPI Center, 2019a). Ze skupiny obecných profilů je ústřední Základní profil, kterému se tato práce dále věnuje.
Dalším prostředkem, jak usnadnit zavedení prvků daného profilu ISO/IEC 29110 do velmi malé entity, jsou implementační balíčky. Jde o samostatně aplikovatelné sady návodů, jak do velmi malé entity zavádět pouze vybranou oblast norem řady ISO/IEC 29110, a dále pak například modelů, formulářů či jiných artefaktů. Pro diplomovou práci je stěžejní implementační balíček Projektové řízení, který se věnuje aktivitám spojeným s projektovým managementem tak, jak je definuje technická zpráva ISO/IEC 29110 Part 5-1-2 Management and engineering guide: Generic profile group: Basic profile (O’Connor, 2009).
O jednotlivých normách řady ISO 29110, jejich profilech a implementačních balíčcích je pojednáno v samostatné kapitole této práce.
Trendem posledních let v oblasti projektového řízení vývoje softwaru jsou agilní metodiky, které oproti tradičním metodikám dovolují řídícím pracovníkům projektu i pracovnímu týmu alternativní možnosti, jak vést projekt vývoje softwaru i samotnou vývojovou činnost.
Agilní metodiky využívají iterativní nebo inkrementální životní model, který je orientován na zákazníka a vítá změny v průběhu vývoje softwaru (Buchalcevová, 2018). Tyto metodiky v současné době již nejsou jen doménou malých týmů a startupů, ale široce se uplatňují ve větších týmech a podnicích (VersionOne, 2016; Digital.ai, 2020; SPI Center, 2019b). Avšak pro tyto metodiky často chybí dostatečná báze již zmíněných referenčních modelů, norem a dalších nástrojů. To vede k jejich živelnému používání, kdy si každý pracovní tým upravuje metodiku pro své účely, některé její části vynechává nebo na ně naopak klade důraz. To v zásadě není nic špatného. Přizpůsobení postupů je v agilních metodikách dovolené a mnohdy i doporučované. Tyto úpravy ale mohou zanést zmatky a chyby do procesu řízení projektu vývoje softwaru, což může projekty zkomplikovat, prodražit či úplně paralyzovat.
Kvůli tomu může být agilní způsob vedení projektu vyhodnocen jako nevhodný i přesto, že jde jen o jeho špatnou implementaci. Definice referenčních modelů, norem a nástrojů tedy může výrazně usnadnit nalezení nejefektivnější cesty, jak s agilními metodikami pracovat.
Odstranění nepřesností a komplikací si za cíl klade připravovaná norma ISO/IEC 29110-5- 4 Agile Software Development Guidelines (Příručka pro agilní vývoj softwaru) (ISO/IEC JTC1 SC7 WG24, 2020), která mapuje prvky agilních metodik vývoje softwaru do původního Základního profilu v rámci řady norem ISO/IEC 29110 pro softwarové inženýrství. Téma rozvíjí a navazuje na něj i tato diplomová práce, jejímž cílem je podpořit agilní vývoj ve velmi malých entitách pomocí praktik z mezinárodních norem ISO/IEC 29110. Součástí cíle je vytvoření nového implementačního balíčku Agilní projektové řízení pro Základní profil pro softwarové inženýrství a jeho doplnění do modelu Základního profilu normy v jazyce ArchiMate. Přínosem je pak využitelnost nového implementačního balíčku a jeho modelu pro zavádění normy ISO/IEC 29110 zavedení a standardizaci agilního vývoje softwaru pro řízení projektů ve velmi malých entitách.
Vymezení tématu a důvod výběru tématu
Diplomová práce se zabývá technickou zprávou 5-4 Příručka pro agilní vývoj softwaru ze skupiny mezinárodních norem ISO/IEC 29110 Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (ISO/IEC JTC1 SC7 WG24, 2020), která mapuje prvky agilních metodik vývoje softwaru do Základního profilu ISO/IEC 29110 pro softwarové inženýrství. V práci je představen nový implementační balíček Agilní projektové řízení pro Základní profil normy ISO/IEC 29110, který je vytvořen podle technické zprávy 5-4 Příručka pro agilní vývoj softwaru, a také model implementačního balíčku v jazyce ArchiMate.
Důvodem pro výběr tématu je fakt, že agilní metodiky vývoje softwaru jsou moderní a široce používaný prostředek pro vedení projektů pro vývoj softwaru, ale tento způsob vývoje je podle názoru autora často nepodchycený, živelný a přináší úspěch pouze za cenu velkých ústupků. Připravovaná technická zpráva rozšiřující řadu norem ISO/IEC 29110 přináší normalizaci této oblasti a teoreticky tak dává možnost využívat agilní metodiky efektivně a standardizovaně.
Práce se zaměřuje na hlavní část technické normy ISO/IEC 29110-5-4, která představuje návod pro velmi malé entity (VME), které chtějí podpořit řízení projektu, jenž má za cíl vývoj softwaru, a využívá k tomu agilní přístup založený na metodikách Scrum a Extrémní programování. Práce se nezaměřuje na implementaci agilních přístupů do VME, které již používají Základní profil ISO/IEC 29110, kterou část 5-4 také definuje ve svých přílohách.
Cíle práce
Hlavním cílem této diplomové práce je podpora zavedení a standardizace agilního vývoje softwaru ve velmi malých entitách na základě mezinárodních norem ISO/IEC 29110 pro softwarové inženýrství. Hlavní cíl je rozdělen na pět dílčích cílů:
DC1: Představení agilních metodik vývoje softwaru, které představují celkový kontext práce.
Největší zřetel je kladen na obecné agilní principy a na agilní metodiky Extrémní programování a hlavně Scrum, ze kterých vychází technická zpráva ISO/IEC 29110 Part 5- 4: Agile Software Development Guidelines.
DC2: Představení skupiny mezinárodních norem ISO/IEC 29110 s důrazem na části 5-1-2 Management and engineering guide: Generic profile group: Basic profile (Základní profil pro softwarové inženýrství) a 5-4 Agile Software Development Guidelines (Příručka pro agilní vývoj softwaru), ze kterých práce přímo vychází. Základní principy, pojmy a struktura norem ISO/IEC 29110 jsou klíčové pro pochopení obsahu diplomové práce.
DC3: Vytvoření implementačního balíčku Agilní projektové řízení pro Základní profil ISO/IEC 29110 pro softwarové inženýrství. Balíček vychází z technické zprávy ISO/IEC 29110-5-4 a logicky navazuje na původní implementační balíček Projektové řízení pro Základní profil pro softwarové inženýrství. Balíček je vytvořen v české a anglické jazykové variantě.
DC4: Doplnění nového implementačního balíčku Agilní projektové řízení do modelu Základního profilu ISO/IEC 29110 pro softwarové inženýrství v jazyce ArchiMate. Součástí dílčího cíle je i doplnění chybějících částí původního implementačního balíčku Projektové řízení do modelu Základního profilu v jazyce ArchiMate a revize jeho dosud namodelovaných částí.
DC5: Ověření využitelnosti implementačního balíčku Agilní projektové řízení pro agilní vývoj ve velmi malé entitě na základě evaluačních rozhovorů s vybranými experty z praxe, které pomohou demonstrovat a ověřit přínos práce pro hlavní cílovou skupinu.
Použité metody
V první fázi řešení diplomové práce autor provedl analýzu literatury pro zmapování současného stavu poznání (odborných publikací a článků, akademických prací a dalších
zdrojů) týkajícího se řady mezinárodních norem ISO/IEC 29110, její aplikace na agilní metodiky vývoje a také na možnost modelování normy v jazyce ArchiMate.
Základní metodou pro řešení práce a dílčího cíle DC3 byla metoda Practitioner Design Science Research (PDSR) (Nagle, Sammon, Doyle, 2017). Tato metoda je variantou výzkumné (rigorózní) metody Design Science Research (DSR) (Kuechler & Vaishnavi, 2004/19), která je vhodná pro vytváření nových artefaktů (metod, modelů a systémů). Tato práce si klade za cíl právě vytvoření nového (aktualizovaného) artefaktu ve formě rozšířeného implementačního balíčku a jeho modelu, který poslouží více než jednomu uživateli. Nejedná se tedy o vývoj řešení pro jednoho aktéra, pro který by byly vhodnější metody softwarového inženýrství. Zároveň využití PSDR místo DSR umožňuje snížit rigoróznost metody a více akcentovat praktické použití výstupů práce. Jako základní popis práce pomocí metody PDSR slouží její PDSR Canvas, který tvoří přílohu A této práce.
Pro dosažení dílčího cíle DC4 byl použit modelovací jazyk ArchiMate (The Open Group, 2019), který umožňuje namodelovat metamodel normy ISO/IEC 29110 a následně modely jejích jednotlivých profilů a implementačních balíčků.
Pro dosažení dílčího cíle DC5 byla použita metoda polostrukturovaných řízených evaluačních rozhovorů se třemi vybranými odborníky z praxe, kteří mají úzký vztah k řízení projektů ve velmi malých entitách a používáním agilních metod vývoje softwaru.
Omezení práce
Součástí práce není pilotní projekt nasazení implementačního balíčku Projektové řízení pro Základní profil normy ISO/IEC 29110 z důvodu nedostupnosti vhodných projektů, ve kterých by autor mohl mít dostatečně vysoké postavení a rozhodující vliv.
Cílová skupina
Hlavní cílovou skupinou, kterou si diplomová práce klade za cíl oslovit, jsou řídící pracovníci vývojových projektů ve velmi malých entitách do 25 zaměstnanců (podnik nebo tým), kteří pro svůj projekt chtějí zavést nebo znormalizovat používání agilních metodik.
Druhou cílovou skupinou jsou pak studenti informatiky a další nadšenci, kteří chtějí lépe porozumět využívání agilních metodik pro vývoj softwaru.
Předpokládané výstupy a očekávané přínosy
Přínosem práce je využití implementačního balíčku Agilní projektové řízení pro Základní profil skupiny norem ISO/IEC 29110 pro softwarové inženýrství pro zavedení a standardizaci agilních metodik vývoje softwaru do velmi malé entity, která chce zavést metodiku Scrum pro řízení projektu a metodiku Extrémní programování pro vývoj softwaru, nebo tyto metodiky již využívá, ale toto použití není zcela standardizované a efektivní.
Výstupy práce jsou:
V1: Implementační balíček Agilní projektové řízení pro Základního profil ISO/IEC 29110 pro softwarové inženýrství v českém znění.
V2: Implementační balíček Agilní projektové řízení pro Základního profil ISO/IEC 29110 pro softwarové inženýrství v anglickém znění.
V3: Model Základního profilu skupiny norem ISO/IEC 29110 pro softwarové inženýrství v jazyce ArchiMate doplněný o implementační balíček Agilní projektové řízení a revidované části implementačního balíčku Projektové řízení.
V4: Ověření využitelnosti nového implementačního balíčku Agilní projektové řízení pro Základní profil v rámci ISO/IEC 29110.
V5: Soupis připomínek k nové technické zprávě ISO/IEC 29110-5-4 a chyb v této technické zprávě nalezených při zpracovávání diplomové práce.
Struktura práce
Práce je členěna do sedmi kapitol. V první kapitole je provedena analýza literatury ve formě rešerše použitých zdrojů (odborných publikací a článků, akademických prací a dalších), které se týkají řady norem ISO/IEC 29110, agilních metodik vývoje, používání těchto agilních metodik vývoje v kontextu řady norem ISO/IEC 29110, tvorby a vylepšování informačních systémů a modelovacího jazyka ArchiMate.
Ve druhé kapitole jsou představeny agilní metodiky vývoje softwaru, které tvoří obecný kontext práce. Důraz je kladen především na metodiky Scrum a Extrémní programování, ze kterých vychází technická zpráva ISO/IEC 2911-5-4: Příručka pro agilní vývoj softwaru, které se práce věnuje.
Ve třetí kapitole je představena řada mezinárodních norem ISO/IEC 29110, její profily, standardy a technické zprávy s důrazem na Základní profil pro softwarové inženýrství (část 5-1-2) a Příručku pro agilní vývoj softwaru (část 5-4), které jsou výchozími podklady pro tuto práci.
Čtvrtá kapitola se věnuje hlavnímu cíli práce, tedy podpoře agilního vývoje softwaru ve VME pomocí nového, autorem vytvořeného implementačního balíčku Agilní projektové řízení
pro Základní profil řady norem ISO/IEC 29110. V kapitole je představen původní implementační balíček Projektové řízení a popsány úpravy, které vedly k jeho aktualizované podobě.
Pátá kapitola představuje nově vytvořený model implementačního balíčku Agilní projektové řízení v jazyce ArchiMate. Tento jazyk je v kapitole představen, stejně jako možnost jeho využití pro modelaci Základního profilu řady norem ISO/IEC 29110. V této kapitole je provedena i revize původní verze modelu Základního profilu.
Šestá kapitola obsahuje ověření hlavního výstupu práce – implementačního balíčku Agilní projektové řízení – pomocí evaluačních rozhovorů. V poslední kapitole pak následuje závěrečné shrnutí a vyhodnocení práce.
1 Rešerše odborných prací a zdrojů
Jako příprava na praktické řešení této diplomové práce byla provedena analýza dostupných zdrojů s tématy: skupina mezinárodních norem ISO/ IEC 29110, projektové řízení a agilní metodiky. Pro nalezení vhodných zdrojů byl využit vyhledávač Google Scholar a portál theses.cz.
Klíčová slova pro vyhledávání zdrojů:
• ISO/IEC 29110
• ISO/IEC 29110 Agile
• ISO/IEC 29110 ArchiMate
1.1 Odborné publikace a články
Zlepšování procesů při budování informačních systémů (Buchalcevová, 2018)
Cílem této knihy je představit aktuální možnosti spojené se zlepšováním procesů při vývoji informačních systémů se zaměřením na vybrané normy, modely, rámce a metodiky, které se této oblasti dotýkají. Pro využití v této diplomové práci je klíčový popis normy ISO/IEC 29110 a agilních metodik Scrum a XP, které jsou zde i porovnány s ostatními vybranými metodikami a hodnoceny pomocí systému pro hodnocení a výběr metodik METES.Tvorba informačních systémů (Bruckner et al., 2012)
Kniha popisuje širší kontext informačních systémů a jejich návaznost na byznys systém, architekturu moderních informačních systémů včetně architektury orientované na služby a různé přístupy k vývoji a provozu těchto systémů. V knize je v kontextu této diplomové práce zajímavá především kapitola 6, ve které jsou porovnávány různé metodiky k vývoji informačního systému včetně agilního přístupu, a kapitola 11 Řízení projektů IS/ICT. Tyto kapitoly slouží jako teoretický základ pro tuto práci.
Scrum: průvodce agilním vývojem softwaru (Myslín, 2016)
Kniha popisuje agilní metodiku Scrum – její podstatu, artefakty, role, způsoby komunikace, monitorování a měření projektu a řešení nastalých problémů. Kniha slouží jako podklad pro zpracování diplomové práce a jako dodatečný zdroj pro porovnání a případné úpravy popisu Scrum metodiky v nové normě 5-4 Agile Software Development Guidelines. Scrumu je věnována i jedna z teoretických kapitol této diplomové práce – viz 2.3 Scrum.
Reinforcing Very Small Entities Using Agile Methodologies with the ISO/IEC 29110 (Muñoz et al., 2018)
Článek pojednává o studii prováděné na 4 vybraných velmi malých entitách s různou velikostí (3 až 12 členů) využívající agilního přístupu – Scrumu. Popisuje agilní metodiky, Základní principy řady norem ISO/IEC 29110, dále její přínosy, ale i problémy, na které tyto vybrané skupiny narazily během používání agilních principů podle Základního profilu v rámci ISO/IEC 29110. Cílem výzkumu bylo ověřit a potvrdit, že implementace Základního profilu normy je možná a aplikovatelná na různorodé entity vyvíjející software s tím, že pro tyto entity jde o přínos ve zlepšení kvality jejich práce, a to i za cenu drobných obtíží při zavádění. Studie slibuje další prověřování a vylepšování doporučované metodologie. Jedná se o primární kvalitativní výzkum, jehož výsledky slouží pro účely této diplomové práce jako podpůrné argumenty pro zavedení ISO/IEC 29110 pro agilní vývoj ve velmi malých entitách.
Using ArchiMate to model ISO/IEC29110 standard for very small entities (Buchalcevová, 2019)
Článek popisuje mapování prvků (procesů, artefaktů a dalších) Základního profilu normy ISO/IEC 29110 do jejího metamodelu v modelovacím jazyce ArchiMate, který je možno sdílet v podniku a prohloubit tak porozumění normy. Vyjádření normy v jazyce ArchiMate pomáhá objasnit vazby mezi procesy a artefakty popsané v normě a procesy a artefakty fungující v podnicích. K vyhodnocení tohoto mapování je použit BWW model. Jedná se o odbornou analýzu problematiky, na kterou tato diplomová práce naváže v oblasti rozšíření skupiny norem ISO/IEC 29110 pro agilní vývoj a domapuje procesy a artefakty agilního vývoje softwaru do metamodelu ISO/IEC 29110 v jazyce ArchiMate.
Průzkum stavu využívání agilních přístupů pro dodávku softwaru v České republice (SPI Center, 2019b)
Průzkum realizovaný v roce 2019, který podporuje aktuálnost problému řešeného v diplomové práci. Výzkum vyhodnocoval české týmy pracující na vývoji softwarového produktu pomocí agilních metodik a jejich postoj k agilním metodikám. Z výsledků vyplývá, že nevyužívanější agilní metodikou je SCRUM, i když týmy často přistupují k úpravě metodik dle vlastních potřeb. Projektové týmy však hodnotí řízení projektu pomocí agilního přístupu jako pozitivní a přínosné, přestože vidí na metodice i nedostatky. Tento závěr jen podporuje fakt, že zpracování agilních metodik v rámci normy bude mít smysl a může pomoci mnoha projektovým týmům. Výzkum vychází z diplomové práce Michala Menčíka (2019).
1.2 Akademické práce
Vybrány jsou akademické práce pojednávající o normě ISO/IEC 29110, a to především ty, ze kterých bude autor práce vycházet a na které bude navazovat.
Pilotní nasazení implementačního balíčku Projektové řízení Základního profilu normy ISO/IEC 29110 (Tomášek, 2017)
Diplomová práce popisuje realizaci nasazení implementačního balíčku Projektové řízení pro Základní profil skupiny norem ISO/IEC 29110 v praxi na reálném softwarovém projektu.
Dalšími dílčími cíli je korekce českého překladu implementačního balíčku Projektové řízení do češtiny a kontrola konzistence překladu s ostatními dokumenty (Základní profil normy a celkově širšího kontextu). Práce se také věnovala ověření použitelnosti balíčku v nástroji Atlassian Jira.
Pilotní nasazení implementačního balíčku Analýza požadavků na software Základního profilu normy ISO/IEC 29110 na vybraném projektu (Hemžal, 2019)
Práce si klade za cíl nasadit implementační balíček Analýza požadavků na software Základního profilu normy ISO/IEC 29110 na vybraném projektu v malé firmě čítající maximálně do 25 zaměstnanců. Pro samotnou implementaci bylo potřeba nejprve namodelovat balíček v jazyku ArchiMate. Tento model je v současnosti přístupný na stránkách SPI CENTER a je tak volně dostupný široké veřejnosti. Namodelování balíčku i samotná implementace se povedla a přispěla tak dle autora diplomové práce zlepšení zpracování požadavků na software minimálně o jednu třetinu.Kvantitativní průzkum stavu využívání agilních přístupů pro dodávku softwaru v České republice (Menčík, 2019)
Tato diplomová práce se zabývá kvalitativním výzkumem používání agilních přístupů a metodik v České republice. Samotná výzkumná zpráva je publikována na webu SPI Centra (2019b). Diplomová práce kromě výzkumné zprávy detailně popisuje i přípravu a provedení výzkumu a uvádí zásady agilního přístupu a jednotlivé agilní metodiky.
Publikace Základního profilu normy ISO/IEC 29110 v Eclipse Process Framework Composer (Dlugošová, 2014)
Hlavním přínosem práce je publikace lokalizovaného Základního profilu norem ISO/IEC 29110 pomocí nástroje Eclipse Process Framework Composer. Tento výstup je přístupný na stránkách www.spicenter.vse.cz pro širokou veřejnost, převážně pak pro české velmi malé entity. Před samotnou publikací byla provedena revize české lokalizace Základního profilu a vytvořena struktura, ve které je prezentován. Práce dále představila skupinu mezinárodních norem ISO/IEC 29110 i další způsoby zlepšování softwarových procesů.
Lokalizace Vstupního profilu normy ISO/IEC 29110 do češtiny a jeho publikace v Eclipse Process Framework Composer (Šimko, 2015)
Práce se zabývá velice podobným tématem jako Dlugošová (2014), ale se zaměřením na Vstupní profil skupiny norem ISO/IEC 29110. Práce představuje Vstupní profil, jeho strukturu a obsah. Dále pak vysvětluje i princip Unified Method Architecture a zajímavým bodem je shrnutí výhod a nevýhod nástroje Eclipse Process Framework Composer z uživatelského pohledu při tvorbě a publikaci elektronické verze Vstupního profilu.
Zlepšování softwarových procesů ve velmi malých entitách – využití normy ISO/IEC 29110 (Vodička, 2015)
Obecným tématem práce je zlepšování procesů ve velmi malých entitách, konkrétněji se pak zabývá především skupinou norem ISO/IEC 29110, jejím popisem, přínosy jejího zavedení do podniku a hodnotí stav jejího zavedení v České republice i ve světě. Práce se dále zaměřuje i na charakteristiku sítě center pro velmi malé entity a možnosti jejího rozšíření o českou pobočku, v roce 2020 je však toto Centrum pro podporu malých entit stále ve fázi příprav.
Zlepšování softwarových procesů v oblasti testování (Libík, 2011)
Diplomová práce se zabývá lokalizací implementačního balíčku Testování softwaru pro Základní profil skupiny norem ISO/IEC 29110 a jeho následném nasazení do velmi malé entity v pilotním projektu. Práce detailně popisuje jeho přípravu i samotný průběh. Tento pilotní projekt byl vyhodnocen jako úspěšný a přinesl podniku zlepšení procesů v oblasti testování.
1.3 Ostatní zdroje
Software engineering — Lifecycle profiles for Very Small Entities (VSEs) – Part 5-1-2: Management and engineering guide: Generic profile group: Basic profile (ISO/IEC JTC1 SC7 WG24, 2011)
Norma 5-1-2 z řady norem ISO/IEC 29110, která se věnuje Základnímu profilu pro softwarové inženýrství, je základním podkladem této diplomové práce. Celé normě je v této diplomové práci věnovaná podkapitola 3.3 Základní profil pro softwarové inženýrství, kde bude popsána podrobněji.
Systems and software engineering – Lifecycle profiles for Very Small Entities (VSEs) – Part 5-4: Agile Software Development Guidelines (ISO/IEC JTC1 SC7 WG24, 2020)
Tato norma je ve stadiu schvalování, ale již je oficiálním dokumentem ISO. Jde o novou technickou zprávu ze skupiny norem ISO/IEC 29110, která se zabývá postupy a metodami agilního vývoje softwaru v prostředí Základního profilu ISO/IEC 29110, a to především s použitím metodik Scrum a Extrémní programování. Popsáno je mapování elementů mezi těmito metodikami a Základním profilem. Právě zmíněné mapování je podkladem pro doplnění implementačního balíčku Projektové řízení a modelu Základního profilu normy v jazyce ArchiMate v této diplomové práci. Této technické zprávě je věnována podkapitola 3.4 Příručka pro agilní vývoj softwaru.
Deployment Package Project Management Basic Profile (O’Connor, 2009)
Implementační balíček Projektové řízení pro Základní profil v rámci řady norem ISO/IEC 29110 pro softwarové inženýrství představuje popis oblasti norem, která se věnuje řízení projektu a návod k implementaci této oblasti do podnikových procesů. Podrobnějšímu popisu balíčku je věnována podkapitola 4.2 Implementační balíček Projektové řízení.Webové stránky profesora Claude Y. Laporte (Laporte, 2016)
Webové stránky profesora Laporteho se věnují normě ISO/IEC 29110, jejím profilům, implementačním balíčkům a dalším odvozeným dílům. Pro diplomovou práci byly použity převážně jako zdroj zdarma dostupných částí normy ISO/IEC 29110 a implementačního balíčku Projektové řízení pro softwarové inženýrství. Oba tyto získané zdroje mají v práci vlastní podkapitolu.
Webové stránky SPI Center pod záštitou Vysoké Školy Ekonomické v Praze (SPI Center, 2019a)
Webové stránky jsou věnovány vhodným metodám pro realizaci softwarových produktů.
Stránky obsahují překlad normy ISO/IEC 29110 a jejich implementačních balíčků, výzkumy a doporučení pro práci s normou.
Webové stránky The Open Group (The Open Group, 2019)
Web souží jako podklad pro správnou notaci při přípravě modelů v jazyce ArchiMate v této diplomové práci.
14
thAnnual State of Agile Report (Digital.ai, 2020)
Jedná se o poslední publikovaný ročník pravidelného průzkumu společnosti Digital.ai (v minulosti CollabNet VersionOne, resp. VersionOne), který byl realizován v roce 2019.
Výzkum se dotazoval na použití agilních praktik a metodik a vyhodnocoval odpovědi více
než 1200 respondentů z různých pozic, odvětví a různě velkých společností z různých zemí světa. Z výsledků podobně jako v případě výzkumu v České republice (SPI Center, 2019b) vyplývá, že nevyužívanější agilní metodikou je scrum. Výzkum se dále zaměřuje na popis benefitů zavedení agilních praktik a metodik, které respondenti zaznamenali.
2 Agilní metodiky vývoje softwaru
Tato kapitola naplňuje dílčí cíl DC1 a představuje čtenářům agilní metodiky vývoje softwaru.
V kapitole jsou popsány základní agilní principy a poté je kladen důraz na metodiky Scrum a Extrémní programování, ze kterých vychází technická zpráva ISO/IEC 29110-5-4 Agile Software Development Guidelines, která je hlavním zdrojem práce pro namapování prvků agilních metodik vývoje do původního implementačního balíčku Projektové řízení.
Pojem agilní metodiky vývoje představuje soubor principů používaných při vývoji softwaru, které se liší od principů tradičních metodik. „Agilní vývoj je založen na iterativním a inkrementálním modelu životního cyklu, je orientován na zákazníka a vítá změny v průběhu vývoje.“ (Buchalcevová, 2018, s. 94)
Agilní metodiky se zaměřují především na to, jak pracovat s lidmi, jak docílit kvalitnějších výstupů a jak zapojit samotného zákazníka do vývojového procesu. Agilní metodiky preferují minimální, ale dostatečná pravidla pro řízení a chod projektu, spíše než detailně popsané procesy. Především se pracuje iteracemi a inkrementálním vývojem. Vývoj je rozfázován na malé funkční celky, které jsou průběžně testovány a představovány zákazníkovi, ten může pružně reagovat, zpřesňovat či měnit své požadavky, znovu je prioritizovat a diskutovat výsledný produkt. Zároveň platí, že je preferováno zákazníkovo uspokojení na konci projektu proti jeho uspokojení na začátku projektu, tedy platí, že změny jsou vítány a v průběhu projektu jsou činěny kroky, které změny umožňují a usnadňují jejich budoucí provedení (Abrahamsson et al., 2002). Agilní přístup se snaží o eliminaci zbytečné byrokracie, přílišné dokumentace a zároveň o zjednodušení procesů změny. Základním principem je dodání kvalitního softwaru (Myslín, 2016).
V tom se agilní metodiky liší od tradičních metodik a životních cyklů softwaru. Například v klasickém vodopádovém modelu vývoje softwaru se předpokládá, že se veškeré požadavky specifikují již na začátku projektu a dále by se již neměly měnit. Což se v současném stále měnícím se prostředí často nedá zajistit. Hlavním problémem vodopádového modelu je pozdní nasazení hotové aplikace. Teprve až po tomto nasazení se zjistí řada problémů, která vede k úpravám a požadavkům na změny. Tyto změny však mají často za následek přepracování původního návrhu, přeprogramování a celkové zpoždění a prodražení projektu (Buchalcevová, 2018). Viz Obrázek 1.
2.1 Základní principy agilního přístupu
Počátek agilních přístupů, na které jsou následně navázané agilní hodnoty, principy, praktiky a metodiky, se datuje kolem roku 2001, kdy skupina sedmnácti vývojářů vytvořila Agilní manifest (ANON, 2001). Tuto skupinu tvořili autoři do té doby nezávislých lehkých metodik, které vznikaly ve druhé polovině 90. let, jakými jsou například XP, Scrum, DSDM, ASD, Crystal, nebo FDD (Menčík, 2019). V manifestu došla skupina ke společnému přesvědčení, že (ANON, 2001; přeloženo dle Buchalcevová, 2018, s. 93-94):
„Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali, z tohoto pohledu dáváme přednost:
• individualitám a komunikaci před procesy a nástroji,
• fungujícímu softwaru před podrobnou dokumentací,
• spolupráci se zákazníkem před sjednáváním kontraktu,
• reakci na změnu před plněním plánu.
Obrázek 1 Porovnání agilního a vodopádového modelu vývoje softwaru. Zdroj: (POTIFOB, 2020)
Na deklaraci hodnot agilního manifestu podrobněji navazuje 12 agilních principů, které opět představují preference a doporučení. Přestože byly tyto principy definovány již před bezmála dvaceti lety, stále jsou platné (Menčík, 2019). Dvanáct agilních principů (ANON, 2001):
1) Na prvním místě je uspokojení zákazníka průběžnými a rychlými dodávkami.
2) Změnové požadavky v průběhu vývoje jsou možné.
3) Produkt je dodáván v malých přírůstcích (týdny až měsíce), které jsou ale funkční.
4) Úzká spolupráce mezi zadavateli a implementátory produktu.
5) V týmu mějme motivované jedince, podporujme je a dávejme jim důvěru.
6) Důležitá je komunikace jak vně, tak uvnitř týmu.
7) Měřítko pokroku je fungující software.
8) Agilní procesy udržují směr neustálého vývoje.
9) Důležitými prvky implementovaného řešení je i technická dokonalost a vhodný design.
10) Snaha dělat věci jednoduše.
11) Práci na architektuře, požadavcích, návrzích je vhodné dělat v týmech, které jsou samoorganizovatelné.
12) Principy fungování týmu jsou neustále upravovány dle toho, jak se týmu snaží plnit vytyčené cíle. Tým si změny navrhuje sám na základě hodnocení, které pravidelně provádí.
Na základě těchto hodnot a principů se formovala široká škála agilních praktik a metodik.
Jak již bylo zmíněno, jedny z prvních metodik byly DSDM (Dynamic Systems Development Method), ASD (Adaptive Software Development), FDD (Feature Driven Development), XP (Extreme Programming), Leans Software Development, Crystal metodiky, agilní modelování a Scrum, které měly kořeny již v devadesátých letech minulého století.
S postupem času pak význam některých zde vyjmenovaných metodik upadal, a naopak se začaly prosazovat nové metodiky, jako například OpenUP, Kanban, Scrumban – hybridní metodika kombinující Scrum a Kanban (Buchalcevová, 2018).
2.2 Využití agilních metodik v současnosti
Tato podkapitola se stručně věnuje aktuálně nejpoužívanějším agilním metodikám. Údaje zde prezentované vycházejí ze dvou průzkumů vypracovaných v roce 2019, které se zaměřují na využití agilních metodik celosvětově i na území České republiky.
V roce 2019 byl proveden poslední publikovaný průzkum State of Agile společnosti Digital.ai (2020), který pravidelně zjišťuje aktuální stav využívání agilních metodik ve světě, a také obdobný průzkum na území České republiky (SPI Center, 2019b), který zpracoval tým z Vysoké školy ekonomické v Praze v čele s Michalem Menčíkem.
Tyto dva průzkumy lze shrnout tvrzením, že v současné době je nejpoužívanější agilní metodikou pro řízení projektu jednoznačně metodika Scrum a její varianty. Metodiku Scrum samotnou používalo v roce 2019 58 % agilně řízených týmů celosvětově (Digital.ai, 2020) a 43,8 % týmů v České republice (SPI Center, 2019b). Pokud započteme i varianty Scrumu jako Scrumban a Scrum/XP, tak tuto metodiku používají více jak dvě třetiny agilních týmů jak celosvětově, tak i v České republice.
Mezi škálovatelnými agilními metodikami nachází největší uplatnění metodika SAFe, která celosvětově dosáhla 35 % výskytů z projektů, které byly řízeny pomocí škálovatelných agilních metodik (Digital.ai, 2020). Počty výskytů aplikace této metodiky rostou s růstem velikosti společnosti, jak dokazuje český výzkum, který poskytuje veřejnosti přesnější výstupy (SPI Center, 2019b). Škálovatelné metodiky nabízejí větší pokrytí procesů pro vývoj ve více týmech, na více projektech či za specifických podmínek.
V následujících kapitolách budou stručně představeny metodiky Scrum a XP, na kterých je technická zpráva ISO/IEC 29110-5-4 Agile Software Development Guidelines založena především (ISO/IEC JTC1 SC7 WG 24, 2020). Autoři této normy vybrali komplementární metodiky Scrum a XP z důvodu, že umožňují nejlépe pokrýt procesy řešené v Základním profilu ISO/IEC 29110, a to jednak Řízení projektu, které pokrývá metodika Scrum, která
byla v této podkapitole představena jako nejpoužívanější agilní metodika současnosti, tak Extrémní programování, které pokrývá procesní oblast Implementace softwaru, které se Scrum nevěnuje.
2.3 Scrum
Scrum je procesní rámec, který byl představen autory Kenem Schwaberem, Jeffem Sutherlandem a Mikem Beedlem na počátku devadesátých let 20. století, a od té je doby používán pro řízení práce na komplexních produktech. Tento rámec umožňuje zapojení a použití různých procesů a technik pro řízení projektu (Schwaber a Sutherland, 2017).
Jedná se o nejpoužívanější metodiku agilního řízení projektů, a to jak globálně, kde podle průzkumu 10th annual State of Agile Report (VersionOne, 2016) zaujímal Scrum v roce 2015 první místo mezi používanými agilními metodikami s 58 procenty a svou pozici i procentuální zastoupení si udržel i v roce 2019 (Digital.ai, 2020), tak i v českém prostoru, kde v roce 2019 představoval s 43,8 % opět jasně dominujícího vítěze mezi agilními metodikami (SPI Center, 2019b). Rovněž velmi často jsou používané upravené verze Scrumu, které jsou kombinací s jinými metodikami, tzv. hybridy. Celosvětově je tak na druhém místě nejpoužívanějších agilních praktik v roce 2015 Scrum/XP hybrid s 10 % VersionOne, 2016) a v roce 2019 s 10 % Scrumban (Digital.ai, 2020). V českém průzkumu pak druhé a třetí místo zaujímají hybridy Scrumban (14,2 %) a Waterfall/Scrum (8,3 %) (SPI Center, 2019b) V obou těchto průzkumech byli dotazování respondenti z různých odvětví, různě velkých společností i týmů, které využívaly agilní metodiky po různě dlouhou dobu. Výsledky v jednotlivých segmentech se lišily, ale ve všech z nich dominoval Scrum (VersionOne, 2016; SPI Center, 2019b).
Scrum se skládá ze samoorganizujících se scrumových týmů, v rámci kterých jsou vymezeny role, a dále pak událostí, artefaktů a pravidel, které váží jednotlivé prvky dohromady a řídí jejich vztahy (Schwaber a Sutherland, 2017). Scrum je založen na třech pilířích, které popsali Schwaber a Sutherland (2017):
1) Transparentnost – aspekty procesu, které ovlivňují jeho výstup, musí být známé a srozumitelné osobám, které jsou za tento výstup zodpovědné. Transparentnost vyžaduje společný jazyk, kterým se jednotlivé osoby domluví, a také definici hotové práce, která zajistí dokončení úkolu.
2) Kontrola (inspekce) – uživatelé Scrumu průběžně kontrolují výtvory své práce a proces, aby včas odhalili nechtěné odchylky. Tyto kontroly by ale neměly být příliš časté, aby nepřekážely v práci.
3) Adaptace – v případě, že při kontrole vyjde najevo, že jeden nebo více aspektů procesu vykazuje odchylky od očekávání nad tolerovanou mez a výsledný produkt nebude možné akceptovat, musí dojít k úpravě procesu nebo produktu. K úpravě musí dojít co nejdříve, aby se omezily případné další odchylky.
Scrum je založen na iterativním principu, kde iterace, tzv. sprinty, jsou časově ohraničené jednotky (obvykle 14 dní až měsíc, ne však delší), během kterých proběhne celý životní cyklus jedné fáze vývoje projektu. Na konci sprintu zákazník obdrží funkční software
rozšířený o požadované funkcionality. Dochází k hodnocení výstupu zákazníkem, revizi priorit a přechází se k dalšímu sprintu, ve kterém jsou požadavky zapracovány (Schwaber a Sutherland, 2017).
2.3.1 Projektový tým a jeho role
Scrum definuje v rámci projektového týmu pouze tři týmové role. To však neznamená, že by byl rozsah prací menší, v projektu řízeném pomocí metodiky Scrum se vykonávají v podstatě stejné aktivity jako v projektu řízeném tradičními metodikami, tedy jednání se zákazníkem, analýza, návrh, vývoj, testování a další. Rozdíl je však v tom, že formálně jsou tyto činnosti přiřazeny pouze třem rolím a vzniká tak potřeba řídit činnosti jinak než jen pomocí formálního členění podle role (Myslín, 2016).
Ony tři role jsou vlastník produktu (product owner), vývojový tým (development team) a Scrum master (nepřekládá se). Týmy jsou samoorganizující se a tzv. multifunkční, tedy jedinec v týmu dokáže vykonávat více než jednu činnost (Schwaber a Sutherland, 2017).
Vlastník produktu – je jediná osoba zodpovědná za maximalizaci hodnoty výsledného produktu. Má na starosti produktový backlog. Konkrétní činnosti nad backlogem může buď vykonávat sám, nebo delegovat na vývojový tým. Rozhoduje o vydání (nasazení) každého z přírůstků produktu vyvinutých Scrum týmem (Schwaber a Sutherland, 2017).
Vývojový tým – samoorganizující se multifunkční tým pracující na produktu. Tým má na starosti sprintový backlog, který průběžně upravuje. Cílem týmu je dodávat funkční přírůstky produktu, jejichž postupným zaváděním se produkt dostává do cílového stavu (Schwaber a Sutherland, 2017). Oficiálně nejsou rozlišovány konkrétní role uvnitř vývojového týmu, specializace je sice samozřejmá, ale bez formálního zařazení (Myslín, 2016).
Scrum master – odpovědný za dodržování a propagaci principů Scrumu. Pomáhá týmu rozumět Scrumu jako přístupu – jeho přínosu, teorii, pravidlům a hodnotě. Okolí týmu pomáhá porozumět, které interakce s týmem jsou přínosné a které nikoliv, a jak tyto interakce změnit, aby se maximalizovala hodnota vytvořená scrumovým týmem. Dále také moderuje jednotlivé scrumové události (Schwaber a Sutherland, 2017).
2.3.2 Artefakty v metodice Scrum
Artefakty v metodice Scrum představují práci týmu nebo hodnotu, které vnáší do projektu transparentnost a možnosti ke kontrole a adaptaci. Scrum definuje tři artefakty: produktový backlog, sprintový backlog a přírůstek (Schwaber a Sutherland, 2017).
Jako základ pro definici práce se považuje tzv. produktový backlog. Produktový backlog je soupis všeho, co chceme v rámci produktu realizovat. Soupis požadavků je prioritiziovaný, časové ohodnocený. Za produktový backlog je zodpovědný product owner, ale na jeho správě pracuje celý scrumový tým. Produktový backlog je neustále živý a dochází k jeho aktualizaci, upřesňování, definici odhadů pracnosti. Položky produktového backlogu jsou průběžně rozpracovány a upřesňovány. Jakmile je položka produktového backlogu
v takovém stavu, že ji tým včetně product ownera povauje za připravenou, je možné ji zařadit do sprintového backlogu (Schwaber a Sutherland, 2017).
Sprintový backlog je seznam funkcionality vybrané z produktového backlogu, kterou si Scrum tým dá za cíl dodat v následujících sprintu, a tím si tak stanovují cílový přírůstek dodávaný v nastávajícím období. Kromě požadované funkcionality by sprintový backlog měl obsahovat alespoň nějaký posun pro zlepšení fungování týmu (procesu). Do sprintového backlogu je možné zasahovat i v průběhu sprintu. A to díky tomu, že tým postupně dostává další a detailnější informace o vyvíjené funkcionalitě. Vlastník sprintového backlogu je výhradní scrumový tým, který jediný může backlog upravovat (Schwaber a Sutherland, 2017).
Posledním artefaktem je Přírůstek, který je definován jako součet všech položek produktového backlogu, který se povede dokončit v sprintu plus hodnoty přírůstků předchozích sprintů. Důležité je, aby přírůstek byl použitelný (Schwaber a Sutherland, 2017).
2.3.3 Sprint a jeho události
Sprint je jádrem Scrumu. Jde o předem stanovený časový úsek, obvykle ne delší než jeden měsíc, za který tým připravuje funkční, použitelný, vydatelný Přírůstek produktu. Délka sprintu je konstantní, tak jak se stanoví. Sprinty na sebe navazují. Během sprintu se konají další ceremonie – Plánování sprintu (Sprint Planning), Denní schůzky (Daily Scrums), Vyhodnocení sprintu (Sprint Review) a Retrospektiva sprintu (Sprint Retrospective) (Schwaber a Sutherland, 2017).
Cílem sprintu je vytvořit spustitelnou aplikaci, která bude validovatelná a testovatelná.
Každý sprint tedy musí být plánován tak, aby na jeho konci byl spustitelný software (Myslín, 2016).
Povolené a zakázané aktivity během sprintu dle (Schwaber a Sutherland, 2017):
- Neprovádět žádné změny, které by mohly ohrozit stanovené cíle sprintu.
- Neprovádět aktivity snižující kvalitu sprintu.
- Lze projednat, upřesnit a upřesnit rozsah sprintu na základě nabitých znalostí.
Domluvu provádí tým s product ownerem.
Scrumové události, nebo také ceremonie, mají za cíl dávat práci rámec, pravidelnost, řád.
Přispívají k tomu, aby byla práce transparentní, docházelo k pravidelnému přezkoumání a adaptaci (Schwaber a Sutherland, 2017).
Plánování sprintu (Sprint Planning)
Na ceremonii zvané sprint planning se všechny zainteresované strany domluví, co bude předmětem nadcházejícího sprintu – jaká práce a jaké cíle si tým stanoví. Zároveň je třeba, aby všichni pochopili náplň sprintu. Výsledkem je jasná představa všech, co je požadovaný přírůstek na konci sprintu (Schwaber a Sutherland, 2017).
Obrázek 2 Obsah metodiky Scrum. Zdroj: (Menčík, 2019) Průběh plánování sprintu:
1) Obsah sprintu – Vlastník produktu představuje cíl a s týmem diskutuje potřebnou funkcionalitu pro dosažení cíle – jak bude produkt fungovat, kolik času zabere implementace. Celý scrumový tým se tak snaží porozumět jeho požadavkům a uvědomit si, co za práci bude potřeba vykonat. Důležité vstupy: produktový backlog, stav produktu po posledním přírůstku, kapacita vývojového týmu, výkon vývojového týmu na základě empirické zkušenosti. Sám tým rozhoduje, kolik položek produktového backlogu jsou schopni během sprintu odbavit. Společně tak domluví cíl sprintu (Schwaber a Sutherland, 2017).
2) Příprava sprintového backlogu – vývojový tým společně definuje funkcionality, které je třeba připravit a vyvinout, aby bylo dosaženo stanoveného cíle sprintu. Cílem je definovat detailní práci minimálně na první dny sprintu. Detailní rozpad práce na další dny se pak vyjasní v průběhu sprintu (Schwaber a Sutherland, 2017).
3) Návrh řešení – po výše uvedených aktivitách by produktový tým měl být schopen vysvětlit vlastníkovi produktu a Scrum masterovi, jakým způsobem bude dosaženo cíle sprintu a jak bude vytvořen očekávaný přírůstek (Schwaber a Sutherland, 2017).
Denní schůzka (Daily Scrum)
Každodenní krátká schůzka vývojového týmu, která má za cíl sjednotit práci celého týmu a stanovení dalšího postupu na příštích 24 hodin. Odpovědnost za konání a průběh má Scrum Master, který zároveň kontroluje, aby schůzka netrvala déle než stanovený čas (obvykle 15 minut). Průběh schůzky není metodikou nijak definovaný. Tým si průběh stanovuje sám dle toho, jak mu to vyhovuje. Schůzky se účastní aktivně jen vývojový tým.
Pokud se chce účastnit ještě někdo, Scrum Master zajistí, aby do schůzky nijak nevstupoval (Schwaber a Sutherland, 2017).
Příkladem průběhu denní schůzky může být praxe autora práce. Každý den se vývojový tým ráno po příchodu všech jeho členů do kanceláře setká v zasedací místnosti a Scrum Master promítá na plátno nebo televizní obrazovku pohled na rozpracované úkolu přiřazené k jednotlivým členům týmu v nástroji Atlassian JIRA. Každý člen postupně odpovídána otázky:
1) Co jsem dělal včera?
2) Co budu dělat dnes?
3) Mám nějaké překážky nebo problémy v práci, mám otázky, které mi může pomoci vyřešit někdo jiný z týmu?
Pokud se během denní schůzky zjistí problém, nebo téma, které je potřeba detailněji probrat, zainteresované strany se bezprostředně po skončení schůzky scházejí a plánují postup vedoucí k vyřešení nastalé situace.
Vyhodnocení sprintu (Sprint Review)
Schůzka celého týmu, na které vývojový tým představuje výsledky přírůstku po právě dokončeném sprintu ostatním zainteresovaným stranám, především vlastníkovi produktu a ostatním stakeholderům. Jsou probírány dodané funkcionality, problémy, na které se během vývoje narazilo, diskutují se případné dotazy. Hodnotí se odvedená práce z pohledu času, rozpočtu a kvality. Dle dosažených výsledků se přizpůsobuje produktový backlog.
Výsledky z vyhodnocení sprintu jsou hlavním vstupem pro revizi produktového backlogu (Schwaber a Sutherland, 2017).
Retrospektiva sprintu (Sprint Retrospective)
Tým má za úkol během retrospektivy prozkoumat své vnitřní fungování v oblasti mezilidských vztahů, procesů, použitých nástrojů, a to jak se zaměřením na to, co se povedlo, tak i na to, co by bylo dobré vylepšit. Vyjmenované body vylepšení jsou seřazeny dle priorit a kroky pro vylepšení jsou zařazeny do plánu spolu s body z produktového backlogu do dalšího sprintu (Schwaber a Sutherland, 2017).
2.4 Extrémní programování
Extrémní programování (eXtreme Programming, XP) je agilní metodika určená pro malé až středně velké týmy (o 2 až 10 programátorech), které vyvíjejí software, jehož zadání se velmi často mění, nebo není na začátku projektu zcela jasné. Autory metodiky jsou Kent Beck, Ward Cunningham a Ron Jeffries, kteří ji představili veřejnosti v roce 2002 (Buchalcevová, 2018).
XP je velmi lehká metodika, která zavádí specifické praktiky jako párové programování, refaktorizaci, vývoj řízený testy, plánovací hru a další. Patří mezi nejpopulárnější metodiky zaměřené na softwarové inženýrství (Buchalcevová, 2018). Používá se především v kombinaci s agilní metodikou Scrum pro vedení projektu v hybridní metodice Scrum/XP.
V této variantě se v roce 2015 používalo XP celosvětově v 10 % projektů používajících agilní metodiky (VersionOne, 2016), v roce 2019 toto číslo poněkud pokleslo a Scrum/XP hybrid
používalo 8 % projektů (Digital.ai, 2020), v České republice pak v 4,7 % případů v roce 2019 (SPI Center, 2019b). Samostatně se XP používalo jak celosvětově, tak v ČR v cca 1-2 % případů (VersionOne, 2016; Digital.ai 2020; SPI Center, 2019b).
Na rozdíl od tradičních metodik i ostatních agilních přístupů je v Extrémním programování použita velice krátká doba iterace. V tradičních metodikách se jedná o měsíce, ve Scrumu o týdny, v XP se může jednat o nízké jednotky dnů (Myslín, 2016).
Extrémní programování definuje tyto hodnoty (Buchalcevová, 2018):
• Jednoduchost
• Komunikace
• Zpětná vazba
• Respekt
• Odvaha
Jednoduchost – programuje se jen to, co je nezbytně nutné, abychom při změně požadavků na funkcionalitu přišli o co nejméně kódu (Myslín, 2016). Zohledňují se jen aktuální požadavky, řešení se vyvíjí v malých přírůstcích (Buchalcevová, 2018).
Komunikace – je základem pro spolupráci v týmu. Komunikovat musí vývojáři, manažeři i zákazník. Nastalé problémy se řeší hned a nečeká se na další vhodnou příležitost při oficiálním setkání týmu (Myslín, 2016).
Zpětná vazba – vývoj probíhá ve velmi krátkých iteracích, během nich se neustále testuje a na konci každé z nich je zákazníkovi dodán a prezentován funkční software. Tým se také snaží prezentovat pokrok a získat zpětnou vazbu i v průběhu iterace (Buchalcevová, 2018).
Respekt – tým respektuje přání a požadavky zákazníka, zákazník respektuje znalosti a zkušenosti vývojového týmu a jeho manažerů (Buchalcevová, 2018).
Odvaha – jedná se o odvahu řešit problémy hned když nastanou a nebát se změny, která může v důsledku znamenat zahození dosavadní práce (Myslín, 2016).
Mezi praktiky Extrémního programování patří například plánovací hra, při které zákazník prezentuje požadavky na výsledný software a programátoři je rozdělují do jednotlivých úkolů a odhadují jejich pracnost. Praktikami, které XP velmi odlišují od ostatních metodik jsou společné vlastnictví kódu, kde každý vývojář může provést změnu v kódu ostatních vývojářů, což znamená, že na kód dohlíží mnoho lidí a to zvyšuje jeho kvalitu, a párové programování, kdy vývoj probíhá ve dvojici programátorů u jednoho počítače, jeden vývojář má za úkol vymyslet implementaci a druhý vymýšlí testy (Buchalcevová, 2018).
V roce 2004 představil Kent Beck druhou verzi metodiky (XP v2). V této upravené verzi je uživateli dána větší volnost a je spíše motivován než nucen k použití jejích konceptů. XP v2 již zároveň není omezena na velmi malé týmy, ale umožňuje použití Extrémního programování pro libovolně velké týmy. Dává také větší důraz na sociální aspekty vývoje softwaru, automatizaci a škálování velikosti týmů (Buchalcevová, 2018).
