VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
Agilní metody řízení vývoje softwaru bakalářská práce
Autor: Jakub Markus Vedoucí práce: Doc. Ing. Dr. Jan Voráček, CSc. Jihlava 2014
Abstrakt Předními zájmy této práce jsou agilní metodiky softwarového vývoje a trendy v této oblasti. Cílem práce je ukázat vhodné nástroje pro řízení projektů podle agilního přístupu a diskutovat možnosti jejich využití. Za tímto účelem jsou navrženy a zpracovány experimenty na systémově dynamickém simulačním modelu a následně jsou v diskuzi vyhodnoceny výsledky těchto experimentů.
Klíčová slova systémová dynamika, modelování systémů, agilní vývoj, simulace, projektové řízení
Abstract Zde bude anotace práce anglicky. Head interests of the paper are agile methodologies of software development and modern trends in the field. The aim of this bachelor’s theses is to investigate appropriate tools for project management according to agile approach and to discusse their usability. There are several test cases on system dynamics simulation model designed and performed for this reason. Results of the tests are discussed to evaluate the process.
Keywords system dynamics, system modeling, agile development, simulation, project management
Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Doc. Ing. Dr. Janu Voráčkovi, CSc. za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.
Obsah 1
Úvod.......................................................................................................................... 8
2
Agilní metodiky v softwarovém vývoji .................................................................... 9 2.1
Stručná historie agilního přístupu ...................................................................... 9
2.2
Přehled agilních metodik.................................................................................. 10
2.2.1
Spirálový model ........................................................................................ 10
2.2.2
Iterační vývoj ............................................................................................ 10
2.2.3
Inkrementální vývoj .................................................................................. 10
2.2.4
Prototypování ............................................................................................ 10
2.2.5
RAD - Rapid Application Development ................................................... 11
2.2.6
RUP - Rational Unified Process ............................................................... 11
2.2.7
Scrum ........................................................................................................ 11
2.2.8
Extrémní programování ............................................................................ 12
2.3
3
2.3.1
Lean software development ...................................................................... 14
2.3.2
Kanban ...................................................................................................... 14
2.3.3
Scrum-ban ................................................................................................. 15
2.4
Vhodnost agility v životním cyklu software .................................................... 15
2.5
Nevýhody agilního přístupu ve vývoji ............................................................. 17
Modelování systémové dynamiky .......................................................................... 18 3.1
4
5
Manifest agilního programování a trendy současnosti..................................... 12
Kroky aplikace systémové dynamiky .............................................................. 18
3.1.1
Příčinný smyčkový diagram – Causal Loop Diagram (CLD) .................. 19
3.1.2
Diagram stavů a toků – Stock and Flow Diagram (SFD) ......................... 20
3.2
Použití simulačního modelu ............................................................................. 21
3.3
Software pro modelování systémové dynamiky .............................................. 22
Simulační model softwarového projektu ................................................................ 23 4.1
Části modelu..................................................................................................... 23
4.2
Uživatelské rozhraní......................................................................................... 24
4.3
Pracovní cyklus modelu ................................................................................... 25
4.4
Agilita v modelu ............................................................................................... 26
4.5
Sledované metriky............................................................................................ 26
Citlivostní analýza .................................................................................................. 28 5.1
Míra chybovosti ............................................................................................... 28
5.2
Minimální čas k objevení chyby ...................................................................... 30
5.3
Relativní úsilí vyžadované k přepracování úkolu ............................................ 31
5.4
Minimální čas potřebný k přepracování úkolu ................................................. 32
6
5.5
Průměrná doba na jeden úkol ........................................................................... 34
5.6
Maximální povolený přesčas............................................................................ 35
5.7
Zhodnocení citlivosti ........................................................................................ 36
Případové studie ...................................................................................................... 38 6.1
6.1.1
Studie č. 1 ................................................................................................. 39
6.1.2
Studie č. 2 ................................................................................................. 39
6.1.3
Studie č. 3 ................................................................................................. 40
6.1.4
Studie č. 4 a č. 5 ........................................................................................ 40
6.1.5
Výsledek konverze .................................................................................... 40
6.2
7
Konverze dat do modelu .................................................................................. 38
Analýza scénářů ............................................................................................... 40
6.2.1
Projektový scénář – Nezkušený tým ......................................................... 41
6.2.2
Test robustnosti modelu ............................................................................ 44
Závěr ....................................................................................................................... 47
Seznam použité literatury ............................................................................................... 49 Seznam obrázků .............................................................................................................. 52 Seznam tabulek ............................................................................................................... 53 Přílohy............................................................................................................................. 54 1
Základní nastavení simulačního modelu................................................................. 54
1 Úvod Oxford Dictionaries charakterizuje použití slova agilní (“agile”) v návaznosti na metody projektového řízení a hlavně vývoje software, jako rozdělení úkolů na krátké fáze vývoje a časté přehodnocování a přizpůsobení plánů ve vývoji software.[1] Agilní metody tedy cílí na obratnější vývojový cyklus a na lepší komunikaci se zákazníkem. Agilita ve vývojové procesu sice dovede významně vylepšit parametry projektu při zachování minimálně stejné kvality, ale na druhou stranu zavádění těchto metod není zcela triviální a tomuto tématu musí být věnována velká pozornost. Agilní metody jsou úspěšně zaváděny ve větších i menších podnicích nebo projektech a proto se parametry jednotlivých nasazení mohou významně lišit. Nalezení správného nastavení metodik je rozsáhlou problematikou, proto mohou vznikat při tomto procesu chyby, které mohou mít za následek finanční ztrátu nebo způsobit neúspěch celého projektu. Agilní metody jsou tedy bezesporu trendem současného softwarového vývoje a proklientského přístupu, což se odráží v zájmu autora o tuto problematiku a také je hlavní motivací pro zpracování této práce. Práce si dává za úkol několik cílů: 1. Seznámit se s problematikou agility ve vývoji SW od úvodní motivace až po nejnovější trendy 2. Ukázat a dokumentovat moderní manažerské nástroje, podporující agilní vývoj softwarových aplikací 3. Zvolit vhodný manažerský nástroj a využít jej pro demonstraci možností daného přístupu na ukázkových příkladech a diskutovat jeho použitelnost v praxi. Těžiště práce je zaměřeno na třetí z výše uvedených cílů, a proto je mu věnováno nejvíce prostoru. Text této části by měl čtenáři poskytnout hodnotnou informace o využití moderních analyticko - manažerských nástrojů.
8
2 Agilní metodiky v softwarovém vývoji 2.1 Stručná historie agilního přístupu První výskyt inkrementálních metod softwarového vývoje, které mohou být považovány za předchůdce agilních metod, vycházel z potřeby odstranit těžkopádnost a chybovost vodopádového modelu při vývoji velkých systémů, můžeme sledovat již od 50. let 20. století. Pro posun technologií v tomto období je významným hráčem společnost IBM a tedy není divu, že na její půdě vznikaly publikace, které navrhovaly použití jisté míry agility při použití iterací ve vývoji. Konkrétně to jsou práce Roberta Glasse, Winstona Royce, Harlana Millse a dalších. Na začátku 70. let Tom Gilb začal publikovat koncepty Evolučního projektového managementu, které se vyvinuly v metodiku nazývanou Competitive Engeneering, a v dalších letech do konce sedmdesátých let tuto metodologii, její praktiky a výhody široce propagoval ve svých přednáškách po celých Spojených státech. V osmdesátých letech popisuje Barry Boehm ve své práci "A Spiral Model of Software Development and Enhancement" spirálový model, který se vyznačuje tím, že při každé iteraci ve vývojovém cyklu stanovuje rizika dalšího postupu a snaží se eliminovat jejich vznik a dopad pro výsledný produkt.[2] Dalšími přístupy s kořeny v osmdesátých letech jsou například metodika iteračního a inkrementálního vývoje, která je součástí i pozdějších metodik, prototypování, jako metodika, která předpokládá silné zapojení zadavatele do vývoje produktu a Rapid application development, která prosazuje minimální plánování ve prospěch rychlého vývoje prototypu. Všechny tyto metodiky mají některé věci společné a navzájem se prolínají. Jako protiváha proti náročným vodopádovým metodám, které se vyznačují velkou regulací a striktní a blízkou kontrolou vývoje, se v polovině devadesátých let objevují takzvané lehké agilní vývojové metody. Tyto jsou označovány svými tvůrci jako návrat k vývojovým metodám, které se používaly v raných stadiích historie vývoje software. Mezi těmito metodikami jsou Rational Unified Process od IBM, Scrum, Extrémní programování a další.
9
V následujícím textu se budeme blíže věnovat popisu výše jmenovaných metodik. Jednotlivé metodiky se spolu prolínají a doplňují, není je proto možné od sebe zcela oddělit.
2.2 Přehled agilních metodik 2.2.1 Spirálový model Spirála je jedním z prvních přístupů, který můžeme zpětně považovat za agilní. Někdy je chybně chápán jako opakující se vodopádový model. V modelu se opakují čtyři fáze, reprezentované čtyřmi kvadranty v kartézské soustavě, přičemž tyto jsou: určení cílů, identifikace a řešení rizik, implementace a testování, souhlas s řešením a dalším postupem. V těchto fázích neprobíhá vždy stejná akce, ale závisí na určených cílech. Tedy v první iteraci může být cílem určení klíčových požadavků na systém, ve druhé pak koncept řešení a podobně. [3]
2.2.2 Iterační vývoj Iterační přístup k vývoji softwaru je základní metodou, která se prolíná skoro všemi dále zmiňovanými postupy a přístupy. Hlavní myšlenkou je postupné přibližování k výsledku pomocí cyklů. Tedy v prvním cyklu je navržen základní design a v každé další obrátce se postupně formuje výsledný systém nebo produkt. [2]
2.2.3 Inkrementální vývoj Inkrementální model vývoje počítá s rozložením problému na menší části a tyto pak postupně (nebo částečně paralelně) řeší. V každé iteraci vývoje pak přidává menší hotové části - inkrementy až do složení celku. [2]
2.2.4 Prototypování Stejně jako při vývoji v jiných odvětvích výroby je prototypování postaveno na vývoji prototypu, který si uživatel vyzkouší a zkontroluje, jestli jsou splněny klíčové požadavky. Při dalším vývoji je tak zahrnuta i zpětná vazba uživatele a případné další požadavky. Jestliže je to nutné probíhá prototypování v iteracích.
10
2.2.5 RAD - Rapid Application Development RAD se skládá ze čtyř fází. V první fázi je nutné dohodnout základní požadavky na produkt a jeho klíčové vlastnosti. Druhou fází je uživatelský návrh. V této fázi spolu komunikují uživatelé a analytici systému. Zásadní snahou je rychle předat uživateli omezeně fungující model a podle zpětné vazby uživatele upravovat vlastnosti a požadavky na software. Model se poté upraví a uživatel se opět vyjadřuje k jeho funkcím. Třetí fází je konstrukce systému podle modelu z předchozí fáze. I v této fázi se uživatel úzce podílí na vývoji a může navrhovat změny ve funkčnosti. Poslední fází je pak finální testování a nasazení systému. Výhodou této metodiky je rychlost a přesnost funkcí systému díky zapojení uživatele do vývoje. [4]
2.2.6 RUP - Rational Unified Process RUP je iterativní metodika vyvinutá firmou Rational, nyní jednou z divizí IBM. Metodika se soustředí na pečlivé modelování a testování všech komponent vyvíjeného systému. Důraz je kladen především na kvalitu. Proces vývoje podle RUP má čtyři základních fáze, přičemž některé mohou více či méně běžet paralelně. V každé fázi pak iteračně probíhá návrh nebo implementace systému. Metodika vyžaduje poměrně rozsáhlou dokumentaci hlavně v porovnání s jinými metodami. Vhodná je především pro rozsáhlé a komplexní problémy. [5]
2.2.7 Scrum Metodika Scrum je široce oblíbená a používaná. Jejím základem je rozdělení vývojového procesu na iterace, v metodice nazývané jako sprinty. Metodika se soustředí na komunikaci uvnitř menších vývojových týmů, které mají dané složení rolí. Sprint je časově omezené úsilí o dosažení cíle, který je určen na začátku každého sprintu a na konci je zhodnocen, přičemž se musí určit, jestli a do jaké míry se cíle dosáhlo a co z toho vyplývá pro další sprint. V rámci sprintu, který trvá obvykle dva týdny (časové období je pochopitelně volitelné), se konají každodenní krátké porady uvnitř týmu, kde každý člen odpovídá na dvě klíčové otázky: “Co jsem udělal včera?” a “Co budu dělat dnes?”. Jestliže se vyskytne nějaký problém při řešení rozdělených úkolů, vedoucí týmu toto řeší až po skončení porady. Dalšími modifikacemi metodiky se dosahuje 11
spolupráce více týmů a tedy velkých pracovních kolektivů, kde na porady chodí pouze jeden člen za celý tým (takzvaný Scrum of Scrums). [6]
Obrázek 1: Nákres principu metodiky SCRUM
2.2.8 Extrémní programování Slovo extrémní v názvu metodiky je odvozeno od praktiky provádění kroků v tradičním vývojovém modelu v extrémním množství nebo čase. Tato snaha se odráží ve velkém důrazu na porozumění v rámci všech členů zapojených do vývoje a také na neustálou kontrolu prováděných kroků pomocí jednotkových testů, testů integrity, akceptačních testů a podobně. V rámci této metodiky je často využíváno párového programování nebo jiných technologií pro psaní správného a srozumitelného kódu. Nejvíce prostředků je investováno do rychlého posunu po menších inkrementech, které implementují nejvíce potřebné prvky systému, místo rozsáhlého plánování a vývoje vlastností, které nejsou potřeba v krátkodobém časovém horizontu. Tyto přístupy se pak odráží v relativně rychlém vývoji, ale jejich nevýhodou může být složitější přepracování již hotových komponent výsledku. [7]
2.3 Manifest agilního programování a trendy současnosti V únoru 2001 se ve městě Snowbird v Utahu, USA konalo setkání 17 vývojářů, kteří diskutovali o problematice lehkých vývojových metod. Výstupem pak je Manifest
12
agilního programování, dokument, který je dnes považován za základní tezi pro používání agilních metod. Někteří z autorů Manifestu pak založili neziskovou organizaci Agile alliance, která poskytuje dalším vývojářům platformu pro vývoj podle principů a zásad manifestu. Znění manifestu jak je publikováno na agilemanifesto.org[8]: Manifest Agilního vývoje software Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick
© 2001, výše zmínění autoři Toto prohlášení může být volně kopírováno v jakékoli formě, ale pouze v plném rozsahu včetně této poznámky. Z výše uvedených bodů vyplývá: 4. Práce jednotlivce a interakce mezi vývojáři je velice důležitá. S tím souvisí i techniky jako párové programování, tedy práce dvou vývojářů na jedné pracovní stanici, nebo kolokace, což je umisťování souvisejících pracovníků na jedno 13
místo pro lepší a efektivnější komunikaci o problému. 5. Fungující software je důležitější a cennější než prezentace a dokumentace k němu. 6. Všechny požadavky nemusí být známy nebo je těžké je všechny určit na začátku projektu, proto je nutné do vývoje zahrnout i neustálou diskuzi se zákazníkem. 7. Pružná reakce na nový problém, je lepší než striktní dodržování stanoveného plánu. Současný vývoj softwaru je značně ovlivněn rychlostí evoluce poptávky po nových produktech. Stěžejními požadavky jsou tedy rychlost reakce na změnu a cena. Z tohoto důvodu se stále více používají agilní metody při vývoji nových produktů a stávají se tak nejpoužívanějším přístupem. Z moderních agilních metod následujících principy Manifestu agilního programování jsou popsány tyto: Lean software development, Kanban a Scrum-ban. Pro jejich vlastnosti a široké možnosti nasazení jsou tyto v současné době velmi často používané.
2.3.1 Lean software development Základem štíhlého vývoje (lean=štíhlý) je myšlenka eliminace plýtvání, tedy že jakýkoliv hodnota, která není přínosem je považována za odpad a jako taková se musí odstranit. Dalšími pilíři jsou bezprostřední komunikace mezi členy týmu, pokud možno bez nezbytně nutné dokumentace, každodenní krátké porady o postupu práce, rozhodovaní co nejpozději je to možné (udělat rozhodnutí, až když je to nutné, do té doby sbírat informace) a dodání výsledku (mezivýsledku v jednotlivých inkrementech) co nejdříve to jde. Díky tomuto systému vývoje bez zbytečných odboček od cesty k cíli je možné rychle reagovat na změny a zároveň udržet pouze strukturu nutnou k dosažení výsledku, což je velmi efektivní. [9]
2.3.2 Kanban Kanban nemá žádnou sadu kroků vedoucích k vytvoření produktu, ale spíše je to styl vývoje pomocí přehledné vizualizace a rozdělení úkolů uvnitř týmu a sada pravidel pro nastavení vnitřních parametrů pro předcházení přetížení členů týmu. Metodika řídí postup práce tak, aby nedocházelo k čekání na nedokončené akce, ale aby docházelo k 14
přerozdělování úkolů podle momentální potřeby a zmenšil se tak čas potřebný k produkci výsledku vývoje. [10][11] Metodika, v kontextu vývoje software, je úzce svázána s metodikou Lean software development a také je možné je do určité míry považovat za ekvivalentní.
2.3.3 Scrum-ban Kombinace metod Kanbanu a Scrum dal vzniknout metodice Scrum-ban, která v sobě nese výhodou obou těchto přístupů. Scrum-ban na rozdíl od Scrum nemá časově limitované sprinty, ale využívá jeho komunikačních nástrojů. Od Kanbanu pak přejímá metody vizualizace a pravidla pro vytěžování členů týmu. Díky těmto vlastnostem je pak flexibilnější vůči nečekaným požadavkům na produkt. [12]
Obrázek 2: Porovnání počtu pravidel a požadavků v metodikách SW vývoje [13]
2.4 Vhodnost agility v životním cyklu software Všechny agilní metodiky, ať už výše popsané nebo ne, počítají s větším či menším zapojením klienta, tedy příjemce výsledného produktu, do samotného procesu výroby. Díky tomu jsou tyto metodiky schopny produkovat kvalitní software, který přesně odpovídá požadavkům klienta a slouží k jeho plné spokojenosti.
15
Použití agilního přístupu však nemusí být vždy nutně přínosné, proto je důležitá role managementu v rozhodování, jaký přístup pro daný projekt zvolit. Další otázkou pak je problém správného nastavení agilního procesu, neboť jak dokazuje následující obrázek, přílišná míra agility může vyústit v neúspěch projektu, který je v našem případě reprezentován na počtu nedetekovaných chyb v produktu.
Obrázek 3: Ukázka chybného nastavení agilního procesu [14]
Vhodným nastavením, ale můžeme snížit počet nedetekovaných chyb.
Obrázek 4: Ukázka vhodného nastavení agilního procesu [14]
Dalším faktorem pro nasazení agilního přístupu je povaha projektu. Jestliže má projekt pevně nastavená kritéria vstupů a výstupů, pak není nutná úzká spolupráce s klientem. 16
Příkladem takového případu může být vývoj systému pro rozšifrování zpráv, vstupem je šifrovaná zpráva a výstupem zpráva rozšifrovaná, tedy prototyp s částečnou funkčností nečeká nic jiného než požadavek na plnou funkčnost, ale žádné změněné požadavky. To, jestli výrobce takového systému ve své vnitřní struktuře použije agilní metody při vývoji, je pochopitelně čistě na jeho rozhodnutí.
2.5 Nevýhody agilního přístupu ve vývoji Přes všechny výhody v rychlosti a snížení chybovostí v průběhu vývoje podle agilních zásad má agilní přístup samozřejmě i své nevýhody. Některé z nich jsou diskutabilní, protože mohou být způsobeny chybnou nebo nedostatečnou aplikací zásad konkrétní metodiky anebo špatným řízením celého projektu, přesto jsou zde uvedeny jako možnost, která může nastat. Jako nevýhody uvedeme:
Časová náročnost pro klienta - každá metodika agilního vývoje předpokládá úzké zapojení klienta do procesu vývoje a to v určování požadavků i průběžném testování. V případě nepochopení tohoto závazku klientem se může projekt dostat projekt do problémů s čekáním na zpětnou vazbu a tedy do celkového zpoždění nebo i neúspěchu projektu.
Ztráta celkového cíle - V případě častých nebo nekoncepčních požadavků ze strany klienta se může stát, že výrobce roztříští pozornost mezi méně důležité nebo v konečné fázi nepoužívané cíle a celkový cíl projektu se ztratí. Tento problém řeší jednotlivé metodiky po svém a vyžaduje trénované vedoucí, kteří si jsou vědomi podobných problémů.
Počáteční odhad požadavků na zdroje - Vzhledem k nekompletním požadavkům na začátku projektu je velice těžké odhadnout celkový čas a finanční i jiné náklady na vývoj, zvláště pro nezkušené týmy. Na druhou stranu úspěšné týmy, které používají agilní metodiky, obvykle dodávají produkt včas a v rámci nákladů. Rozhodujícím faktorem je opět zkušenost.
Změna myšlení - použití agilních metodik je v mnoha případech ve prospěch vývojáře i klienta. Vyžaduje však změnu myšlení v rámci vývojového návrhu, plánování a komunikaci, což může být ztěžujícím faktorem vývoje. 17
3 Modelování systémové dynamiky Systémová dynamika jako vědní disciplína se zabývá chováním a vývojem systémů v čase. Metodika se snaží nahlížet na systémy z různých úhlů pohledu a tedy co nejvíce objektivně. Systémová dynamika poskytuje různé nástroje a postupy pro vytváření modelů, které lépe odpovídají realitě a umožňují lepší predikci modelovaných situací v reálném světě. Počátky systémové dynamiky sahají do 50. let 20. století a jsou přímo spjaty s osobou Dr. J. W. Forrestera z Massachussetts Institute of Technology, který tuto metodologii rozvinul a použil pro modelování průmyslových systémů. Později se systémová dynamika aplikovala na další odvětví včetně ekonomických studií, sociálních věd a současně i jako manažerský nástroj pro řízení projektů a to včetně softwarových projektů.[15] S tímto konstatováním je třeba se zmínit o tom, co je myšleno pojmem systém. Systém je účelově definovaná množina prvků a vazeb mezi nimi, které dohromady určují vlastnosti celku. [16] Z uvedené definice vyplývá nutnost chápat celou problémovou doménu uceleně a objektivně, tedy nejen jako soubor samostatných procesů, ale jako navzájem interagujících členů, kdy tyto interakce mají vliv na celkový výstup systému. Systémové pojetí problematiky řízení projektů není nová, i když ne moc široce využívaná myšlenka, protože vyžaduje určitou změnu myšlení nad daným problémem a tato změna není jistě triviální. Modelování systémové dynamiky je nástroj, který umožňuje
manažerům
zkoumat
chování
modelovaného
systému,
s
různou
parametrizací, kontinuálně v čase.
3.1 Kroky aplikace systémové dynamiky Aplikací systémové dynamiky máme zde na mysli postup, který vede k vytvoření simulačního modelu.[17] Sled kroků je následující: 1. Definice problému 2. Definice systémových prvků modelu 18
3. Mentální model 4. Formalizace modelu 5. Tvorba simulačního modelu Definice problému, tedy účelu modelu, je pochopitelně zásadním krokem při tvorbě simulačního modelu. Je třeba vyřešit, jaké budou hranice modelovaného systému a při tom určit, které proměnné mají být zahrnuty v modelu, a které z nich budou v systému vnitřní a vnější. Pro definici se využívá diagram hranic. Definováním účelu modelu jsme taktéž schopni udržet soustředění na modelovaný problém a tedy předejít přílišnému zjednodušení reality nebo naopak přílišnému detailu. Po definování hranic systému je nutné promyslet a navrhnout rozdělení modelu na logické celky, identifikovat všechny složky a určit klíčové pojmy zahrnuté v modelu. Pro všechny prvky je nutné určit jednotky a to tak aby dávaly v daném kontextu smysl. Dalším krokem je tvorba mentálního modelu. Pro tvorbu tohoto modelu se využívají především dva nástroje – příčinný smyčkové diagram a diagram toků. Bližší popis těchto nástrojů je zpracován níže. Na mentální model navazuje formalizace modelu, tedy proces zápisu vztahů mezi prvky a proměnnými modelu pomocí rovnic. Některé proměnné mohou mít nelineární charakter, tyto lze obvykle modelovat pomocí tzv. grafových funkcí, které odráží závislost hodnoty proměnné na čase atp. Po sestavení a vyřešení všech závislostí je možné model sestavit v nějakém softwarovém nástroji a vytvořit tak simulační model. V tomto kroku bychom také měli určit hodnoty konstant a počáteční nastavení proměnných. Také je nutné určit časový horizont simulace (určuje, jak dlouho simulace poběží), časový krok (o kolik se má posunout čas během iterace) a zvolit integrační metodu (některé simulační prostředí nabízí Eulerovu i různé metody Runge-Kutta)[18].
3.1.1 Příčinný smyčkový diagram – Causal Loop Diagram (CLD) Příčinný smyčkový diagram se používá k ilustraci závislosti jedné entity na další, které ovlivňují výchozí entitu a tedy k popisu struktury modelu. Skládá se z entit (uzly) a vztahů mezi nimi. Rozlišujeme dva druhy vztahů, kde oba vyjadřují změnu a to s 19
pozitivní nebo negativní tendencí. Vztahy jsou vyjádřeny obvykle orientovanou šipkou a někdy i s ohodnocením tendence - „o“ nebo „-“ pro opačnou (angl. „opposite“), negativní a „s“ nebo „+“ pro stejnou (angl. „same“), pozitivní[19]. Změna ve smyčce se nemusí projevit okamžitě, ale až s nějakým zpožděním. Některé reakce na změnu se mohou projevit například díky charakteru prvků v modelu, jako jsou hladiny a toky.
Obrázek 5: Ukázka příčinné smyčky[26]
3.1.2 Diagram stavů a toků – Stock and Flow Diagram (SFD) Diagram stavů a toků vychází z příčinného smyčkového diagramu a poskytuje kvantitativní pohled na chování systému. Stavem je myšlen prvek, jehož hodnota se kumuluje nebo vyčerpává v čase. Můžeme si jej představit jako nádrž, do které přitéká nebo odtéká voda. Tok je prvek, který určuje míru změny hladiny stavu. Lze si jej přestavit jako ventil mezi nádržemi, který může být více či méně otevřený na základě nějaké podmínky.[19] Příklad diagramu stavů a toků níže je součástí modelu, který je používán v pozdější fázi textu.
20
Obrázek 6: Ukázka diagramu stavů a toků [24]
3.2 Použití simulačního modelu Po dokončení simulačního modelu je nutné tento správně nakalibrovat a provést validaci. Kalibrace je nastavení parametrů (proměnné a konstanty) modelu na příslušné hodnoty. Tyto hodnoty jsou obvykle naměřeny v reálném systému, který modelujeme. V případě vývoje software je to například chybovost, která vyjadřuje míru chyby vytvořené vývojářem za čas nebo doba práce na jednom úkolu, která je mediánem naměřených hodnot trvání úkolů. Validace modelu je ověření, že model funguje správně, tedy že jsme vytvořili model, který odpovídá námi sledovanému systému. Validaci obvykle provádíme porovnáním výsledků nakalibrované simulace s naměřenými daty. Dále můžeme provést citlivostní analýzu modelu, při které zjistíme, jaké parametry modelu způsobují největší odchylku v hodnotách výstupních metrik. Některé softwarové nástroje používané pro tvorbu modelů již obsahují možnost provádět citlivostní analýzu a tím tento proces usnadňují. Další kapitolou je používání modelu pro simulaci a experimentování. Toto se obvykle děje podle předem daných scénářů, které jsou běžně rozděleny na tři varianty a to například kritický, reálný a ideální. 21
3.3 Software pro modelování systémové dynamiky Od samého počátku využívání modelů pro simulaci systémové dynamiky se vzhledem k výpočetní náročnosti používají k tomuto účelu speciálně vyvinuté jazyky a software, který umožňuje snadnější vytváření simulačních modelů. Spoustu těchto modelů je také zdarma dostupných online a to i přímo od výrobců daných simulačních prostředí nebo od institucí, které se touto problematikou zabývají. Následující přehled zachycuje některé používané prostředí v oblasti[20]. 1. DYNAMO – je původní jazyk používaný pro modelování od konce 50. let, v současné době se jmenuje Dynamo PLUS 2. Powersim – všestranný software pro vytváření systémově dynamických modelů, převážně z ekonomické oblasti 3. Vensim – široce používaný software od společnosti Ventana systems inc., umožnuje tvorbu modelů v integrovaném grafickém prostředí 4. ithink/Stella – dva softwarové produkty od společnosti isee systems inc., oba v podstatě totožné, Stella je určena pro výuku a ithink pro business prostředí, software umožňuje vytvářet SFD a z něj vyprodukovat simulační model 5. Forio Simulate – online prostředí, které umožňuje tvorbu simulací, obsahuje i možnost spouštět uživatelsky vytvořené simulace, využívá se i pro výukové účely 6. InsightMaker – online nástroj pro tvorbu, spouštění a sdílení simulačních modelů 7. RunTheModel – web pro spouštění simulací vytvořených v prostředí AnyLogic7 Je jistě dobré zmínit, že pro nástroje z našeho výčtu, které nejsou online, je možné nalézt volně dostupné modely a to jako doplněk k literatuře, která se systémovou dynamikou zabývá nebo přímo na webech výrobců jednotlivých prostředí. (reference na modely)[21][22][23]
22
4 Simulační model softwarového projektu Z předcházející kapitoly vyplývá, že cest k modelování systémové dynamiky a využívání jejich výsledků k predikci v agilním softwarovém vývoji je více. Model, vybraný pro tuto práci, není původní prací, ale byl zveřejněn v práci "Modeling Agile Development: When is it Effective?"[24], kterou publikoval Karim Chichakly z firmy isee systems, inc. Z tohoto důvodu je model vytvořen ve formátu pro software od této firmy a tak i zde budeme používat tento nástroj a to konkrétně isee Player v10.0.5. Důvodem volby tohoto modelu je jeho šířka zájmu a úroveň detailu, které se odráží v implementaci mnoha projektových parametrů, doplňujících projektových procesů a přívětivého uživatelského rozhraní. Dalším, a neméně důležitým, faktorem pro výběr je také vhodnost modelu pro simulaci námi zvolené agilní metodiky – Lean Kanban. Je dobré poznamenat, že model i aplikace jsou dostupné zdarma online.
4.1 Části modelu Model se skládá z 9 logických modulů, kde každý představuje jinou oblast simulace: 1. Rework cycle – simuluje cyklus nutnosti přepracování úkolů v projektu a jako takový je jádrem celé simulace, princip tohoto modulu je podrobněji popsán v dalším textu 2. Staff – modeluje proces najímání nových a odchod stávajících pracovníků v projektu a také proces zvyšování jejich kvalifikace, vzhledem k potřebám této práce se nevyužívá 3. Errors on errors – stará se o simulaci vzniku chyb na již přepracovaných úkolech 4. Schedule pressure – simuluje vliv časové tísně na chod projektu 5. Schedule slip – simuluje posun oproti plánu projektu 6. Overtime – představuje vliv přepracování na efektivitu a vznikající chyby v průběhu vývoje 7. Rework/Metrics – skládá se ze dvou simulací, přepočítává kumulativní metriky v projektu 23
8. Phasing – zpracovává nastavení agilního chování v simulaci 9. Totals – vypočítává kumulativní hodnoty metrik v modelu
4.2 Uživatelské rozhraní Základními ovládacími prvky rozhraní modelu jsou přepínače, které umožňují nastavit moduly nebo části modulů, které se použijí při simulaci. Následující grafika zobrazuje náhled na tyto základní ovládací prvky.
Obrázek 7: Základní rozhraní simulačního modelu [24]
Pákové přepínače slouží k zapnutí/vypnutí do jisté míry samostatných částí modelu. Po řadě jsou to: 1. precedence switch – úkoly jsou řešeny od začátku ve stále stejném pořadí nebo se v průběhu práce objevují prioritně vyšší požadavky 2. vary staff switch – zapíná modul pro nabírání a odchod pracovníků 3. errors on errors switch – umožňuje simulaci vytváření chyb na chybách 4. schedule pressure switch – zapíná vliv časového tlaku na produktivitu 5. experience dilution switch – umožňuje simulovat různé úrovně zkušenosti pracovníků a postupné zvyšování jejich pracovní zkušenosti 6. follow budget switch – ovládá chování týmu vzhledem k nastavenému rozpočtu 7. agile switch – zapíná agilní chování modelu 8. schedule slip switch – povoluje časový skluz projektu proti plánu 24
9. uncertain requirements switch – ovládá nastavení módu nejistých požadavků 10. overtime switch – zapne režim práce přesčas Další přepínače na nákresu jsou přepínače technik používaných ve vývoji podle agilních metodik. Tyto jsou přímo závislé na pákovém přepínači agile switch. V případě, že je vypnutý nemají tyto dílčí přepínače na simulaci žádný vliv. Zapnutím těchto přepínačů ovlivňujeme počet vznikajících chyb při vývoji. 1. test first switch 2. reviews switch 3. frequent release switch 4. kiss switch (keep it smart simple) 5. automated test switch Zbývající sada tří přepínačů (no priority, rework priority, original work priority) určuje pořadí úkolů při práci na projektu mezi opravou chyb, původními požadavky nebo, zda na tomto nezáleží.
4.3 Pracovní cyklus modelu Tento modul je hlavní součástí simulace a hraje tak nejdůležitější roli v celém modelu. Následující nákres představuje hlavní fragment modelu, který se stará o simulaci řešení úkolů a generováním chyb, které je třeba opravit.
Obrázek 8: Jádro simulačního modelu v isee Playeru [24]
25
Cyklus začíná přidáváním práce do systému, tedy postupné zvyšování počtu úkolů, které se je nutné zpracovat v jednotlivé fázi (pro danou metodiku fáze=dílčí cíl). Tento počet se zachycuje kontejneru Original Work to Do. Část těchto úkolů je považována za správně zpracovanou, v závislosti na momentálním stavu simulace, a je převáděna do kontejneru Work Done. Zbylá, komplementární část úkolů je považována za zpracovanou chybně a jako taková se přesunuje do kontejneru Undiscovered Rework. Z tohoto kontejneru se úkoly přesouvají v závislosti na rychlosti objevování chyb vývojovým týmem do kontejneru Rework to Do, odkud se opět v závislosti na procentuální chybovosti přesunuje do kontejnerů Work Done a Undiscovered Rework. Závěrečnou fází cyklu je přesouvání správně provedené práce zákazníkovi, který je zde reprezentován kontejnerem Previous Work Done.
4.4 Agilita v modelu Model v agilním režimu (zapnutí agile switch) simuluje práci metodiky Lean Kanban. Způsob jakým se tato metodika projevuje v modelu, je ten, že celkový počet úkolů v projektu je rozdělen na počtem vyvíjených fragmentů, které jsou postupně doručovány. Tímto krokem se vlastně rozdělí projekt na několik menších podprojektů, mezi kterými se přenáší rozpracované úkoly z předcházející fáze do další. Návaznost úkolů na sebe a přesun lidských zdrojů, jako základní principy zvolené metodiky, jsou zajištěny samotnou povahou modelu. Tyto vlastnosti se pochopitelně promítají i do vodopádového režimu.
4.5 Sledované metriky Sledování průběhu projektu budeme sledovat na základě veličin, které jsou rozděleny na dvě kategorie. Kvantitativní metriky 1. Produktivita – ukazuje, jak se vyvíjí produktivita týmu v čase 2. Průběh práce na úkolech – ukazuje postup práce ve fázích 3. Celkově dokončených úkolů – kumulativní metrika, zobrazuje nabývání hotové práce v celém projektu
26
4. Celkové úkoly navíc – kumulativní metrika pro zobrazení vývoje úkolů k přepracování v projektu 5. Nezjištěné úkoly navíc – zobrazuje vývoj generování úkolů navíc, které ještě nejsou známy vývojovému týmu 6. Celkové náklady – kumulativní metrika pro počet člověkodnů strávených na projektu 7. Dokončení projektu – určuje čas dokončení prací Kvalitativní metriky 1. Efekt přesčasů na chybovost – zobrazuje vliv práce v přesčasech na podíl chyb 2. Přetížení pracovníků – ukazuje kolik pracovníků je třeba v daném okamžiku 3. Podíl chyb – ukazuje vývoj poměru mezi správně dokončenou prací a úkoly, které bude třeba přepracovat Uvedené metriky mají nejlepší vypovídací hodnotu o průběhu projektu. Model umožňuje sledovat více metrik než tyto výše uvedené, ale ty vždy závisí na námi vybraných metrikách a nemají tedy příslušnou vypovídací hodnotu.
27
5 Citlivostní analýza V rámci citlivostní analýzy budeme zkoumat vliv vybraných parametrů na metriky délka projektu a počet úkolů, které bylo třeba přepracovat. Parametry rozumíme vstupní hodnoty a metrikami výstupy o průběhu vývojového procesu. Pro chod simulace je klíčových několik parametrů, pro které chceme vyhodnotit míru jejich vlivu na projekt. Důvod k výběru právě těchto parametrů je jejich ovlivnitelnost pro projektového manažera. Po řadě jsou to: 1. Míra chybovosti 2. Minimální čas k objevení chyby 3. Relativní úsilí vyžadované k přepracování úkolu 4. Minimální čas potřebný k přepracování úkolu 5. Průměrné doba na jeden úkol 6. Maximální povolený přesčas Záměrně jsme vypustili parametry, jejichž vliv na projekt je přímo jasný. Příkladem takového parametru je počet pracovníků v týmu. Navíc je počet pracovníků často fixní a změna vyžaduje vysoké náklady. Simulaci budeme spouštět se zapnutými přepínači precedence switch, agile switch a overtime switch ostatní přepínače jsou vypnuté. Všechny parametry jsou nastaveny na počáteční hodnoty (přehled v příloze 1), pouze měřený parametr se mění. Pro potřeby přehlednosti jsou některé simulace provedeny v intervalu 0-60 dní, 0-120 dní a 180 dní. Tam, kde by delší interval neměl smysl, jsme použili kratší, aby byly lépe patrné rozdíly mezi jednotlivými běhy simulace.
5.1 Míra chybovosti Nastavení rozsahu: 0,00 – 1,00 (0 – 100%) Počet běhů: 5
28
Úkoly k přepracování 500 450 400
Počet úkolů
350 300 250 200 150 100 50
180
173
165
158
150
143
135
128
120
113
105
98
90
83
75
68
60
53
45
38
30
23
15
8
0
0
Čas (den) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 9: Vývoj počtu úkolů v čase, test citlivosti na míru chybovosti
Ukončení projektu Číslo běhu
Čas (den)
1
27,375
2
42,000
3
74,000
4
176,500
5
∞
Tabulka 1: Test citlivosti na míru chybovosti, ukončení projektu
29
Míra chybovosti je jistě jeden ze zásadních faktorů v modelu. Čas ukončení projektu nelineárně stoupá a to až do té míry, že neskončí vůbec. U počtu úkolů k přepracování sledujeme také nelineární nárůst. Je logické, že při nulové chybovosti není co opravovat a proto projekt doběhne v nejkratším možném čase. Naopak pro 100% chybovost se musí opravovat vše a to stále dokola, takže projekt se nikdy nedokončí.
5.2 Minimální čas k objevení chyby Nastavení rozsahu: 0 – 2 (den) Počet běhů: 5 Úkoly k přepracování 25
Počet úkolů
20
15
10
5
60
56
53
49
45
41
38
34
30
26
23
19
15
11
8
4
0
0
Čas (den) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 10: Vývoj počtu úkolů v čase, test citlivosti na minimální čas k objevení chyby
Ukončení projektu Číslo běhu
Čas (den)
1
30,625
2
32,625
30
3
33,875
4
33,875
5
33,875
Tabulka 2: Test citlivosti na minimální čas k objevení chyby, ukončení projektu
Parametr minimálního času nemá na délku projektu nebo počet vygenerovaných příliš velký vliv. Tento stav je způsoben i postupným zpracováním objevených chyb, proto se rozdíly v nastavení parametru projevují až ke konci projektu. V tomto testu pozorujeme snižující se vliv až k nule. V absolutních číslech se změna tohoto parametru promítla do celkově vygenerovaných úkolů přepracování pouze v řádu desetin.
5.3 Relativní úsilí vyžadované k přepracování úkolu Nastavení rozsahu: 0,1 – 1,00 Počet běhů: 5 Úkoly k přepracování
25
Počet úkolů
20
15
10
5
0 2 4 6 9 11 13 15 17 19 21 23 26 28 30 32 34 36 38 40 43 45 47 49 51 53 55 57 60
0
Čas (dny) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 11: Vývoj počtu úkolů v čase, test citlivosti na relativní úsilí k přepracování
31
Ukončení projektu Číslo běhu
Čas (den)
1
31,750
2
31,875
3
32,750
4
33,250
5
33,875
Tabulka 3: Test citlivosti na relativní úsilí k přepracování, ukončení projektu
Význam tohoto parametrů spočívá v určení náročnosti přepracování úkolu. Hodnota 1 tedy znamená stejnou náročnost jako běžný úkol. Parametr je možné, a má to v některých případech jistě smysl, zvyšovat, ale v našem případě vycházíme z úvahy, že stejná náročnost jako v případě běžného úkolu je maximální. Spodní hranici zvoleného intervalu jsme nastavili na nejmenší možnou hodnotu. Hodnota 0 nemá při tomto parametru význam, protože by určovala fakt, že se přepracováním vůbec nezabýváme. Výsledek testu je takový, že lineární změna parametru má víceméně lineární odezvu ve vygenerovaných úkolech. Na grafu úkolů k přepracování můžeme pozorovat ne zcela stejné rozestupy v počtu úkolů, tento stav je promítnutím drobných nepřesností při zaokrouhlování ve výpočtech. Rozdíly jsou patrné hlavně kvůli tomu, že absolutní změna počtu úkolů k přepracování se pohybuje okolo hodnoty 1.
5.4 Minimální čas potřebný k přepracování úkolu Nastavení rozsahu: 0,1 – 3,0 (den) Počet běhů: 5
32
Úkoly k přepracování 35 30
Počet úkolů
25 20 15 10 5
60
58
55
53
50
48
45
43
40
38
35
33
30
28
25
23
20
18
15
13
10
8
5
3
0
0
Čas (dny) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 12: Vývoj počtu úkolů v čase, test citlivosti na minimální čas k přepracování úkolu
Ukončení projektu Číslo běhu
Čas (den)
1
31,750
2
33,250
3
35,875
4
39,875
5
45,125
Tabulka 4: Test citlivosti na minimální čas k přepracování úkolu, ukončení projektu
Charakter tohoto parametru jej umožňuje libovolně zvyšovat, ale změny v úkolech se projevují pomaleji. Rychlejší a významnější je změna délky vývoje projektu. Při porovnávání citlivosti parametru je nutné zvážit délku a význam testovaného intervalu,
33
protože změny v rámci desetin se významně neprojevují, ale přitom může být náročné jich vůbec v praxi dosáhnout.
5.5 Průměrná doba na jeden úkol Nastavení rozsahu: 0,1 – 5,00 (den) Počet běhů: 5 Úkoly k přepracování 25
Počet úkolů
20
15
10
5
120
115
110
105
100
95
90
85
80
75
70
65
60
55
50
45
40
35
30
25
20
15
5
10
0
0
Čas (dny) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 13: Vývoj počtu úkolů v čase, test citlivosti na průměrnou dobu na jeden úkol
Ukončení projektu Číslo běhu
Čas (den)
1
33,250
2
34,500
3
57,625
34
4
84,000
5
110,500
Tabulka 5: Test citlivosti na průměrnou dobu na jeden úkol, ukončení projektu
V grafu úkolů k přepracování pozorujeme závislost vysoké produktivity, při nastavení nižší hodnoty délky práce na úkolu, na vyšší počet vygenerovaných chyb. Tato závislost ztrácí význam při zvýšení délky, která způsobuje nižší produktivitu. Toto chování je způsobeno přepínačem overtime switch a odráží komplexitu modelu. V tomto případě je však nutné tento efekt zanedbat a soustředit se výhradně na dobu ukončení projektu, která se významně prodlužuje se zvyšujícím časem nutným pro dokončení úkolu. Tento parametr je z logiky věci možné neustále zvyšovat a proto je interval, na kterém proběhl tento test citlivosti pouze demonstrativní, ale i přesto význam tohoto parametru dobře vystihuje.
5.6 Maximální povolený přesčas Nastavení rozsahu: 0,1 – 1,00 (den) Počet běhů: 5 Úkoly k přepracování 25
15 10 5 0 0 2 4 6 9 11 13 15 17 19 21 23 26 28 30 32 34 36 38 40 43 45 47 49 51 53 55 57 60
Počet úkolů
20
Čas (dny) Běh č.1
Běh č.2
Běh č.3
Běh č.4
Běh č.5
Obrázek 14: Vývoj počtu úkolů v čase, test citlivosti na maximální povolený přesčas
35
Ukončení projektu Číslo běhu
Čas (den)
1
33,250
2
33,500
3
33,875
4
33,875
5
33,875
Tabulka 6: Test citlivosti na maximální povolený přesčas, ukončení projektu
Horní hranice intervalu tohoto testu byla zvolena jako demonstrace dvakrát delší pracovní doby. Z grafu úkolů k přepracování ovšem vyplývá postupné snížení produktivity při práci přesčas až do té míry, že změna parametrů nemá vliv ani na jednu ze sledovaných metrik. Parametr nevýznamně ovlivňuje délku práce na projektu, ale více se projeví ve vygenerovaných chybách.
5.7 Zhodnocení citlivosti Z analýzy citlivosti modelu jasně vyplývá, že model je nejcitlivější na míru chybovosti v projektu. Další parametry mohou mít na průběh vývojového procesu nemalý vliv, ale jejich nastavení na mezní hranice je diskutabilní z hlediska používané domény a logické vazby na další parametry, příkladem takového parametru je průměrná doba na jeden úkol. Způsob ovlivnění hodnot jednotlivých parametrů je objektem řízení rizik. Míra chybovosti jako necitlivější parametr s sebou nese i největší riziko záporného vlivu na projekt. Zvrátit tento stav je možné mnoha způsoby. Obecným doporučením je najímání zkušených pracovníků a kontinuální zvyšování jejich kvalifikace. Dalšími nástroji může být využití automatizovaných testů, testování v průběhu vývoje a inspekce kódu. Simulací tohoto případu se věnujeme v dalším textu.
36
Výše zmíněnými kroky lze také ovlivnit druhý testovaný parametr a snížit jej tak na nejnižší možnou hodnotu. Parametry relativního úsilí na přepracování úkolu a času potřebného k přepracování úkolu lze ovlivnit používáním agilních metodik, které k tomuto účelu přímo směřují. Průměrná doba na vypracování úkolu přímo souvisí s počtem úkolů a nelze říci, která varianta je lepší, ale obecně platí, že delší čas úkolu nahrává ztrátě cíle a tedy riziku vyšší nutnosti přepracování úkolů. Z hlediska štíhlého vývoje je také dobré snížit rozptyl doby na vypracování úkolu, což vede na doporučení dekomponovat práci na stejně náročné úkoly. Práce přesčas má dle našeho měření negativní vliv na projekt, tedy řešením by mohl být zákaz práce přesčas. Tato situace ale není zcela přesná. Určitá míra práce přesčas může mít kladný vliv na produktivitu, ale tento efekt nesmí být převážen mírou chybovosti v přesčasech. Problematika také souvisí s únavou pracovníků, která může způsobit ještě vyšší míru chybovosti.
37
6 Případové studie 6.1 Konverze dat do modelu Tato kapitola se zabývá nastavením modelu popsaného v předchozí kapitole podle hodnot z praxe [25]. Práce se zabývá porovnáním projektů řízených podle vodopádového paradigmatu a podle metodiky Scrum a diskuzí získaných dat s teorií. V práci autor prezentuje reálná data o provedených pracích na podnikovém produktu, a proto jsou tyto vhodné pro demonstraci kalibrace simulačního modelu. Pro naše potřeby využijeme hodnoty naměřené z procesů, které proběhly podle metodiky vodopád. Naměřená data shrnuje následující tabulka. Případ
Plánovaný čas (h)
Skutečný čas (h)
Počet úkolů
1.
100
141
29
2.
112
166
20
3.
53
66
8
4.
34
34
11
5.
88
88
35
Tabulka 7: Naměřená projektová data
Podle naměřených dat nastavíme model a experimentálně zjistíme hodnotu parametru chybovosti, která odpovídá naměřeným datům. Průměr takto zjištěných hodnot potom označíme za celkovou chybovost měřeného vývojářského týmu v daných projektech. Vzhledem k tomu, že data jsou měřena v hodinách a náš model pracuje na bázi dnů, je nutné tyto časové jednotky mezi sebou převést (předpokládáme pracovní den 8h). Pro převod použijeme následující vztahy mezi veličinami v modelu a naměřenými daty. PUM = PU PCU = P/PU
38
CDU = SC/PCU PCUM = 8/PCU Kde: PU – počet úkolů PUM – počet úkolů v modelu P – naplánovaná doba (h) PCU – průměrný čas na úkol (h) SC – skutečný čas (h) CDU – celkem dokončených úkolů PCUM – průměrný čas na úkol v modelu (den) Model spustíme v základním nastavení pouze se zapnutým přepínačem Precedence switch, poběží tedy v režimu podle metodiky vodopád. Parametr initial work to do nastavíme na hodnotu PUM a parametr average task duration na hodnotu PCUM. Poté budeme spouštět model a hledat správné nastavení parametru NE3(míra chybovosti) tak, aby metrika Cumulative Work Done (celkově dokončené úkoly) byla rovna hodnotě CDU. Následující tabulky shrnují vypočtené a zjištěné hodnoty pro jednotlivé případy.
6.1.1 Studie č. 1 PU = 29 = PUM
PCU = 3,45
P = 100
CDU = 42
SC = 144
PCUM = 0,43
Míra chybovosti: 0,36 Tabulka 8: Data a výsledky případu č. 1
6.1.2 Studie č. 2 PU = 20 = PUM
PCU = 3,45
39
P = 112
CDU = 33
SC = 166
PCUM = 0,7
Míra chybovosti: 0,33 Tabulka 9: Data a výsledky případu č. 2
6.1.3 Studie č. 3 PU = 8 = PUM
PCU = 6,625
P = 53
CDU = 10
SC = 66
PCUM = 0,83
Míra chybovosti: 0,17 Tabulka 10: Data a výsledky případu č. 3
6.1.4 Studie č. 4 a č. 5 Tyto dvě případové studie mají vyrovnaný plán a skutečný čas. Z toho vyplývá míra chybovosti 0,00 pro obě.
6.1.5 Výsledek konverze Průměrem výše vypočtených chybovostí spočítáme celkovou míru chybovosti týmu vývojářů, kteří pracovali pro danou společnost. Tuto hodnotu můžeme dále používat pro experimenty. Celková míra chybovosti: 0,172
6.2 Analýza scénářů Pro experimentování s modelem jsme navrhli scénář situace, která může nastat při vývoji. Experiment se snaží ukázat využití simulačního modelu pro plánování kroků,
40
které zlepší stav navržený ve scénáři a to ovlivněním jiných faktorů podílejících se na běhu projektu. Druhý experiment se zabývá testem robustnosti modelu a to přidáním náhodné složky do parametrů modelu, provedením simulace tohoto v praxi běžného jevu a jeho diskuzí ukážeme, jak se s tímto případem model vypořádá. Při experimentech předpokládáme použití metodiky Lean Kanban.
6.2.1 Projektový scénář – Nezkušený tým Na projektech nejmenovaného podniku pracuje tým zkušených vývojářů. Z různých důvodů chce část týmu odejít a tak je vedení nuceno najmout nové méně zkušené vývojáře a snaží se nastavit vývojový proces tak, aby byla minimalizován dopad personální změny. Simulace původního stavu Nejdříve nasimulujeme stávající situaci. Nastavení modelu shrnuje následující tabulka, které zachycuje změny proti základnímu nastavení modelu. Parametr
Hodnota
Precedence switch
zapnuto
Errors on errors switch
zapnuto
Experience dilution switch
zapnuto
Agile switch
zapnuto
Schedule pressure switch
zapnuto
Follow budget switch
zapnuto
Initial experienced staff
6 Tabulka 11: Nastavení původního stavu
Z výsledků simulace nás zajímají dvě hodnoty: 41
Celkově dokončených úkolů – 126
Doba ukončení projektu – 31,25 dní
V dalších krocích se budeme snažit těmto hodnotám přiblížit i při jiné personální skladbě týmu. Simulace nového stavu Nyní budeme simulovat situaci se stejnými parametry kromě nastavení parametrů ovlivňujících personální obsazení. Model rozlišuje zkušenost vývojářů do dvou kategorií a to na zkušené a nové. Noví vývojáři se časem stávají zkušenými a dříve než se jimi stanou, pracují s částečnou produktivitou proti zkušeným vývojářům. Parametr
Hodnota
Initial experienced staff
4
Inital new staff
2 Tabulka 12: Změna parametrů v situaci s novými vývojáři
Změna v personálním rozložení se na sledovaných metrikách projevily následovně:
Celkově dokončených úkolů – 148
Doba ukončení projektu – 42,50 dní
42
1,2
1
Produktivita
0,8
0,6
0,4
0,2
60
58
55
53
50
48
45
43
40
38
35
33
30
28
25
23
20
18
15
13
10
8
5
3
0
0 noví vývojářiČas (den) zkušení vývojáři
Obrázek 15: Průběh produktivity v týmu se zkušenými a novými vývojáři
Srovnání produktivity týmu v původní a novém stavu projektového týmu ukazuje následující graf. Řešení nové situace Dalším krokem je snaha o snížení rozdílu ve výsledcích předchozích simulací a to hlavně jejich vlivu na čas dokončení projektu. Pro řešení situace můžeme využít několik nástrojů. Prvním nástrojem může být využití nástrojů zlepšujících kvalitu procesu. V našem modelu jsou reprezentovány přepínači test first switch, reviews switch, frequent release switch, kiss switch a automated test switch. Nasazení těchto technik se neobejde bez nákladů a to jak časových tak finančních, zároveň se neobejde bez dodatečného úsilí v projektu. V tomto případě budeme uvažovat pouze zvýšené úsilí a to zvýšením počtu úkolů v projektu. Graf podílu chyb ukazuje, že v případě zapnutí vylepšení kvality je menší podíl chyb v projektu a tedy je nutné opravovat méně úkolů a celý projekt skončí dříve. Projekt bez vylepšení skončí za 41,75 dní a s vylepšením se situace zlepší na 31,75 dní a to i přesto, že se zvýšil počet úkolů, které se mají vykonat o 10% na 110 úkolů.
43
0,6 0,5
Podíl chyb
0,4 0,3
0,2 0,1
60
58
55
53
50
48
45
43
40
38
35
33
30
28
25
23
20
18
15
13
8
10
5
3
0
0
Čas (den) bez vylepšení
s vylepšením
Obrázek 16: Průběh podílu chyb v projektu s a bez použití prostředků zvýšení kvality
Druhým možným krokem k řešení může být najmutí více nových vývojářů než kolik je odchozích zkušených vývojářů. Aplikací kombinace navržených řešení dosáhneme efektu zkrácení doby vývojového procesu nezkušeného týmu. Náklady na tyto úpravy nejsou zanedbatelné, ale v praxi se rozloží do více projektů a nelze je tedy brát jako prvoplánovou ztrátu, ale spíše jako investici do inovací a kvality.
6.2.2 Test robustnosti modelu Demonstrativním experimentem je simulace případu kdy klíčový parametr modelu vykazuje částečně náhodné chování. Přidáním šumu se snažíme dojít k chování, které je bližší reálnému procesu. Náhodnou složku jsme přidali do dvou parametrů a to do produktivity a podílu chyb. V reálném procesu je běžné, že průběh procesu je zatížen šumem, který má v tomto případě maximální velikost 5%. Simulaci s náhodnou složkou budeme porovnávat se simulací bez tohoto faktoru. Provedením simulací můžeme ukázat průběh podílu chyb a produktivity. 44
1,2
1
Produktivita
0,8
0,6
0,4
0,2
55
60
55
60
50
45
40
35
30
25
20
15
10
5
0
0
Čas (den) bez šumu
včetně šumu
Obrázek 17: Test robustnosti - porovnání průběhu produktivity v projektu
0,6
0,5
0,3
0,2
0,1
50
45
40
35
30
25
20
15
10
5
0 0
Podíl chyb
0,4
Čas (den) bez šumu
včetně šumu
Obrázek 18: Test robustnosti - porovnání průběhu podílu chyb v projektu
45
Přidání šumu přineslo efekt na zvýšení doby potřebné k dokončení projektu ze 46,5 dnů na 47,875 dnů. Průběh projektu však tato změna neovlivnila, jak je patrné z grafu průběhu práce na projektu.
30
25
Dokončené úkoly
20
15
10
5
60
55
50
45
40
35
30
25
20
15
10
5
0
0
Čas (den) bez šumu
včetně šumu
Obrázek 19: Test robustnosti - porovnání průběhu práce na projektu
Experiment tak ověřil odolnost modelu vůči běžným náhodným jevům bez nepředvídatelného chování.
46
7 Závěr Celkově práce splnila své cíle a poskytuje parametry stanovené v úvodu a může být úvodem do problematiky použití simulačních modelů pro plánování a testování vhodnosti plánovaných rozhodnutí pro projektové manažery. V první části práce jsem popsal motivaci a vývoj v oblasti agilního přístupu k softwarovému vývoji. Sestavil jsem přehled agilních metodik, popsal způsob, jakým aplikují myšlenky agilního přístupu, načrtl směr vývoje v budoucnu a diskutoval vhodnost použití a případné problémy, které s sebou přináší zavádění agilních metodik. Výsledkem srovnání je tvrzení, že agilní metodiky přinášejí kvalitativní zlepšení do procesu vývoje, ale vyžadují určité úsilí ke změně myšlení v kontextu řízení i procesu samotného a pochopitelně s sebou přináší úskalí ve formě chybného nastavení procesu. Jejich použití může být zpočátku problematické, ale výhody ve formě úspěšnosti projektů převažují. Ve druhé části práce jsem se seznámil s pojmem modelování systémové dynamiky. Jsou diskutovány výhody systémového přístupu a důvody, proč je vhodné používat simulace k rozhodování a predikci následků změn v projektovém řízení. V dalším textu je popsán postup vytváření simulačního modelu včetně jeho validace a kalibrace. Nakonec jsem srovnal softwarové nástroje pro vytváření simulačních modelů. Vytvoření simulačního modelu je časově a v praxi i finančně náročná a komplexní problematika, která vyžaduje systémové myšlení, dostatečné analytické schopnosti a zkušenosti. Validní a správně nakalibrovaný simulační model poskytuje hodnotné informace a jeho používání může zabránit finančním ztrátám nebo odhalit chování, které nemusí být patrné bez použití systémové dynamiky. Pro demonstraci možností simulačních modelů jsem vybral model, který simuluje vývoj softwarového produktu podle metodiky Lean Kanban, a zároveň umožňuje i simulaci vývoje podle metodiky vodopád, protože jeho původní účel byl ve srovnání efektivity agilního přístupu proti tradičnímu přístupu. Model je dostatečně komplexní, a proto jsme se rozhodli jej použít i pro potřeby této práce. Nejdříve jsem popsal prostředky, které model poskytuje pro parametrizaci simulace a vybral vhodné metriky, které je třeba sledovat. 47
Následně jsem provedl citlivostní analýzu vybraného modelu, diskutoval důsledky vyplývající z výsledků pro projektové manažery a navrhl možná manažerská řešení simulovaných situací. V případové studii jsem nejdříve navrhl způsob konverze dat z praxe do používaného modelu. Postup zahrnuje přepočet získaných dat na parametry v modelu a dále použití simulace pro získání hodnoty míry chybovosti, která je zásadním faktorem v používaném systému, čímž jsem ukázal jeden z možných způsobů využití modelu v praxi. Další podkapitola případové studie se věnuje ukázce simulace možné situace, do které se dostal tým vývojářů, a diskutuje návrh řešení pro danou situaci. Prvním krokem v experimentu byla simulace původního stavu. Poté jsem simuloval nový stav a oba porovnal. Poté jsem simulací aplikace manažerských kroků dosáhl eliminace vlivu změny mezi původním a novým stavem a diskutoval jsem provedení manažerských kroků a jejich úskalí. Posledním experimentem je test robustnosti. Tímto testem jsem ověřil odolnost modelu vůči částečně náhodnému chování, které je běžným jevem v praxi. Do modelu jsem přidal 5% šum do výpočtu produktivity a podílu chyby a porovnáním simulací se stavem bez náhodného vlivu jsem ověřil, že model se chová předvídatelně i při přidání náhodné složky, i když drobný vliv na výsledek projektu má. Při dalším rozvoji problematiky by bylo přínosné sesbírat více dat z praxe a následně provádět další komplexnější experimenty a porovnat jejich výsledky s reálnými daty. Také by bylo vhodné zpracovat i model pro jiné agilní metodiky a provádět specifičtější experimenty pro dané metodiky.
48
Seznam použité literatury 1. Agile: definition of agile in Oxford dictionary (British & World English). In: Oxford Dictionaries [online]. [cit. 2014-02-01]. Dostupné z: http://www.oxforddictionaries.com/definition/english/agile 2. LARMAN, Craig a Victor R. BASILI. IEEE COMPUTER SOCIETY. Iterative and Incremental Development: A Brief History. 2003. Dostupné z: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larmanand-basili-ieee-computer.pdf 3. BOEHM, Barry. SOFTWARE ENGINEERING INSTITUTE. Spiral Development: Experience, Principles, and Refinements. Philadephia, PA: Carnegie Mellon University, 2000. Dostupné z: http://www.sei.cmu.edu/reports/00sr008.pdf 4. GOTTESDIENER, Ellen. RAD Realties: Beyond the hype and how RAD really works. Application Development Trends. 1995. Dostupné z: http://www.ebgconsulting.com/Pubs/Articles/RAD_Realities_Beyond_the_Hyp e_Gottesdiener.pdf 5. RATIONAL. Rational Unified Process: Best Practices for Software development Teams. IBM. [online]. 2011 [cit. 2014-02-05]. Dostupné z: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/ 1251_bestpractices_TP026B.pdf 6. SCHWABER, Ken a Jeff SUTHERLAND. SCRUM.ORG. Scrum Guide. Dostupné z: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide-CS.pdf#zoom=100 7. Extreme Programming: A gentle introduction. Extreme Programming: A Gentle Introduction. [Online] [Citace: 5. 2 2014.] http://www.extremeprogramming.org/. 8. Manifesto for Agile Software Development. [online]. 2001. vyd. [cit. 2014-0205]. Dostupné z: http://agilemanifesto.org/iso/cs/
49
9. POPPENDIECK, Mary a Tom POPPENDIECK. Lean software development: an agile toolkit. 10. print. Boston: Addison-Wesley, 2006. ISBN 03-211-5078-3. 10. SHALLOWAY, Alan. NET OBJECTIVES, Inc. Demystifying Kanban. Lynnwood, 2011. Dostupné z: http://www.netobjectives.com/files/resources/articles/Demystifying-Kanban.pdf 11. VACANTI, Daniel a Bennet VALLET. AGILE ALLIANCE. Actionable Metrics at Siemens Health Services. 2014. Dostupné z: http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemens HealthServices.pdf 12. Scrumban: A different way to be Agile. GAMBILL, Paul. DELOITTE DIGITAL. [online]. [cit. 2014-02-04]. Dostupné z: http://www.deloittedigital.com/us/blog/scrumban-a-different-way-to-be-agile 13. SKARIN, Henrik Knibert a Forewords by Mary Poppendieck ANDERSON. Kanban and Scrum: making the most of both. S.l.: C4Media, Inc, 2010. ISBN 978-055-7138-326. 14. Simulation: Agile Software Development. FORIO SIMULATE. [online]. 2014 [cit. 2014-02-04]. Dostupné z: http://forio.com/simulate/k.e.v.oorschot/agilesoftware-development/run/#p=page1 15. Introduction to System Dynamics. THE CREATIVE LEARNING EXCHANGE. [online]. 2014 [cit. 2014-05-03]. Dostupné z: http://www.clexchange.org/resources/historysd.asp 16. DOLEŽAL, Jan, Pavel MÁCHAL a Branislav LACKO. Projektový management podle IPMA. 1. vyd. Praha: Grada, 2009, 507 s. Expert (Grada). ISBN 978-80-247-2848-3. 17. BURIANOVÁ, Eva. SIMULACE DYNAMICKÝCH MODELŮ S VYUŽITÍM METOD SYSTÉMOVÉ DYNAMIKY. 2007. Dostupné z: http://www.ki.fpv.ukf.sk/projekty/kega_3_4029_06/iski2007/papers/Burianova. pdf. Ostravská univerzita v Ostravě. 18. MILDEOVÁ, Stanislava a Viktor VOJTKO. Systémová dynamika. Vyd. 1. Praha: Oeconomica, 2003, 120 s. ISBN 80-245-0626-2. 19. MADACHY, Raymond J. Software process dynamics. Piscataway, NJ: IEEE Press, c2008, xxiii, 601 p. ISBN 978-047-1274-551.
50
20. The Field of System Dynamics: Modeling and Simulation. SYSTEM DYNAMICS SOCIETY. [online]. 2011. vyd. [cit. 2014-04-25]. Dostupné z: http://www.systemdynamics.org/what_is_system_dynamics.html#modeling 21. MADACHY, Raymond J. Software Process Dynamics: Models. [online]. [cit. 2014-04-20]. Dostupné z: http://csse.usc.edu/softwareprocessdynamics/models.html 22. Appendix D: Available Models. [online]. [cit. 2014-04-20]. Dostupné z: http://sunset.usc.edu/classes/cs599_99/models.html 23. FIDDAMAN, Tom. MetaSD Model Library: A system dynamics model archive. [online]. 2013 [cit. 2014-05-20]. Dostupné z: http://models.metasd.com/ 24. CHICHAKLY, Karim. Modeling Agile Development: When is it Effective?. Proceedings of the 2007 System Dynamics Conference, Boston, MA, 2007. Dostupné z: http://www.systemdynamics.org/conferences/2007/proceed/papers/CHICH380.p df 25. NOVOTNÝ, Tomáš. Řízení životního cyklu softwarového produktu: teorie a praxe. Jindřichův Hradec, 2011. Diplomová práce. Fakulta managementu Vysoké školy ekonomické v Praze Jindřichův Hradec. Vedoucí práce doc. Ing. Dr. Jan Voráček, CSc. 26. OTTO, Marc. STRUCTURAL ANALYSIS TOOL – VENSIM PLE [online]. 2013, 2013-11-23 [cit. 2014-05-20]. Dostupné z: http://www.marcotto.de/structuralanalysis-tool-vensim-ple/
51
Seznam obrázků Obrázek 1: Nákres principu metodiky SCRUM ............................................................. 12 Obrázek 2: Porovnání počtu pravidel a požadavků v metodikách SW vývoje [13] ....... 15 Obrázek 3: Ukázka chybného nastavení agilního procesu [14] ...................................... 16 Obrázek 4: Ukázka vhodného nastavení agilního procesu [14] ..................................... 16 Obrázek 5: Ukázka příčinné smyčky[26] ....................................................................... 20 Obrázek 6: Ukázka diagramu stavů a toků [24] ............................................................. 21 Obrázek 7: Základní rozhraní simulačního modelu [24] ................................................ 24 Obrázek 8: Jádro simulačního modelu v isee Playeru [24] ............................................ 25 Obrázek 9: Vývoj počtu úkolů v čase, test citlivosti na míru chybovosti ...................... 29 Obrázek 10: Vývoj počtu úkolů v čase, test citlivosti na minimální čas k objevení chyby ........................................................................................................................................ 30 Obrázek 11: Vývoj počtu úkolů v čase, test citlivosti na relativní úsilí k přepracování 31 Obrázek 12: Vývoj počtu úkolů v čase, test citlivosti na minimální čas k přepracování úkolu ............................................................................................................................... 33 Obrázek 13: Vývoj počtu úkolů v čase, test citlivosti na průměrnou dobu na jeden úkol ........................................................................................................................................ 34 Obrázek 14: Vývoj počtu úkolů v čase, test citlivosti na maximální povolený přesčas . 35 Obrázek 15: Průběh produktivity v týmu se zkušenými a novými vývojáři .................. 43 Obrázek 16: Průběh podílu chyb v projektu s a bez použití prostředků zvýšení kvality 44 Obrázek 17: Test robustnosti - porovnání průběhu produktivity v projektu .................. 45 Obrázek 18: Test robustnosti - porovnání průběhu podílu chyb v projektu ................... 45 Obrázek 19: Test robustnosti - porovnání průběhu práce na projektu ............................ 46
52
Seznam tabulek Tabulka 1: Test citlivosti na míru chybovosti, ukončení projektu ................................. 29 Tabulka 2: Test citlivosti na minimální čas k objevení chyby, ukončení projektu ........ 31 Tabulka 3: Test citlivosti na relativní úsilí k přepracování, ukončení projektu ............. 32 Tabulka 4: Test citlivosti na minimální čas k přepracování úkolu, ukončení projektu .. 33 Tabulka 5: Test citlivosti na průměrnou dobu na jeden úkol, ukončení projektu .......... 35 Tabulka 6: Test citlivosti na maximální povolený přesčas, ukončení projektu .............. 36 Tabulka 7: Naměřená projektová data ............................................................................ 38 Tabulka 8: Data a výsledky případu č. 1 ........................................................................ 39 Tabulka 9: Data a výsledky případu č. 2 ........................................................................ 40 Tabulka 10: Data a výsledky případu č. 3 ...................................................................... 40 Tabulka 11: Nastavení původního stavu ......................................................................... 41 Tabulka 12: Změna parametrů v situaci s novými vývojáři ........................................... 42
53
Přílohy 1 Počáteční nastavení simulačního modelu V tabulce je zachycen základní stav modelu, jak je zmiňován výše v práci. Parametr
Hodnota
Parametr
Hodnota
SE1
0,50
PF2
1,0
SE2
0,75
PF3
0,0
SE3
1,00
TP3
1,0
SP1
0,50
initial work to do
100
SP2
0,75
time to develop fatigue
6.0
SP3
1,00
time to gain experience
24
IN1
0,35
average task duration
1,0
IN2
0,50
maximum overtime allowed
0.5
RN1
0,65
average time to hire
4
RN2
0,50
imputed cost per day of overrun
10
NE1
0,05
initial experienced staff
4
NE2
0,10
average time to transfer/fire
1
NE3
0,15
willingness to slip
1,0
NP1
0,90
maximum staff level
25
NP2
0,85
willingness to hire
1,0
NP3
0,95
overtime delay
1,0
NP4
1,00
estimated rework fraction
0,4
SI1
0,80
minimum time to perform rework
0,25
SI2
0,90
minimum time to discover rework
1,0
UR1
0,15
maximum effect of fatigue on productivity
0,5
UR2
0,20
relative effort required for rework
1,0
IC
10
maximum effect of fatigue on productivity
0,3
PH1
4
relative effort required for rework
1,0
PH2
1
incremental error fraction of experienced staff
0,0
PF1
0,4
maximum effect of overtime on productivity
0,5
initial scheduled completion date
25
maximum effect of fatigue on error fraction
0,5
initial new staff
0
54
