AGILNÍ PROJEKTOVÝ MANAGEMENT Jan Petrtyl, Jiří Skalický, Jiří Vacek ÚVOD Cílem tohoto článku je představit agilní projektový management a identifikovat hlavní odlišnosti oproti standardnímu projektovému managementu. 1 PROJEKTOVÝ MANAGEMENT Projektový management je manažerskou disciplinou, která má vlastní metodologii. Je zaštiťován profesními organizacemi (např. IPMA International Project Management Association, v České republice zastoupená Společností pro projektové řízení, APM Association for Project Management, PMI Project Management Institute a další), které zajišťují profesní certifikaci a odborné konference. Metody, nástroje i techniky projektového managementu jsou do jisté míry nezávislé na odvětví, ve kterém jsou aplikovány, neboť principy řízení projektů jsou použitelné napříč různými sektory (Cuthbertson in [24]; [23]) ať již jde o stavbu dálnice, uspořádání konference nebo vývoj nového produktu v automobilovém průmyslu. Projekty a jejich řízení jsou využívány v mnoha aktivitách organizací a jednotlivců, a tak není překvapením, že se teorie projektového managementu vyvíjela a vznikaly i teorie nové. Impulsem pro vznik nové teorie byl obvykle fakt, že pro řízení některých typů projektů klasická teorie nebyla optimální [27]. Mnoho autorů se snažilo kategorizovat projekty podle různých hledisek (např. [2]). Z hlediska teorie projektového managementu, která je vhodná pro jejich řízení, je možno projekty rozčlenit do čtyř kategorií [26]: Kategorie A open projekty : Projekty, jejichž produktem je systém, pro který je možno předem provést jeho analýzu a úplnou specifikaci a je možno předem specifikovat procesy realizační (pracovní) i řídící. Pro řízení těchto projektů se používá klasická teorie PM (kterou zavedl PMI). Život těchto projektů je složen z fází inicializace, plánování, realizace a ukončení. Někdy se používá výraz vodopádová koncepce. Kategorie B projekty vývojové (zpravidla vývoj software, implementace IS, ale i jiné projekty výzkumu a vývoje): Jsou to projekty, kde produkt není možno (a ani to není účelné) předem detailně specifikovat. Život projektu probíhá v iteracích. Pro řízení se používá teorie agilního projektového managementu. Metody hodnocení takových projektů jsou popsány např. v [25]. Kategorie C portfolio projektů: Pro management portfolia se používá teorie řízení portfolia projektů (Portfolio Project Management PPM). Management portfolia projektů (PPM) je úloha výběru projektů z balíku projektů, které jsou navrženy pro realizaci strategických cílů organizace (viz [26]). Kategorie D projekty komplexní: Jedná se o projekty složité/komplexní podle definice International Centre for Complex Project Management (ICCPM). Tyto projekty jsou charakteristické svou nejistotou, nejasností a neurčitostí, s dynamickými vazbami na politické a externí události [16]. 2 PROJEKTOVÝ MANAGEMENT V OBLASTI INFORMAČNÍCH TECHNOLOGIÍ Oblast informačních technologií (dále IT) tedy není z pohledu implementace nástrojů projektového managementu žádnou výjimkou, právě naopak. Informační a komunikační technologie (ICT) mají potenciál zvýšit konkurenceschopnost firem, respektive regionů i celých států (viz např. [22], [13], [14]). Platí, že vývoj ICT vykazuje vysokou míru dynamiky, ať se již jedná o programové (software SW) nebo technické (hardware HW) vybavení. Jako příklad pro ilustraci rychlého vývoje může posloužit databáze tematicky zaměřených zpráv Cloud Computing na serveru Lupa.cz }l0to/podyim 2011]. Snad ještě lépe patrná je dynamika rozvoje při pohledu na články zaměřené na elektronický obchod (tamtéž v obdobný čas). Aby bylo možné uvádět na trh stále nová, inovativní řešení a produkty, je nutné je nejdříve navrhnout, naprogramovat či zkonstruovat a otestovat. Oblast ICT, která je pro implementaci nástrojů projektového managementu více než vhodná, tak byla díky svému charakteru spouštěcím mechanismem pro inovaci metodik projektového managementu.
2.1 AGILNÍ PROJEKTOVÝ MANAGEMENT Pro výzkum a vývoj je charakteristická vysoká míra rizika či nejistoty a nemožnost na začátku projektu přesně specifikovat cílový produkt. Typickým oborem je vývoj software, kde si vývojoví pracovníci jako první uvědomili potřebu změny v řízení projektů, změny v uplatňování nástrojů a technik klasického projektového managementu. Vyčlenila se proto relativně samostatná skupina metodik tzv. agilního projektového managementu. Slovo agilní znamená, že něco je flexibilní a pohotové, takže agilní metody jsou charakteristické tím, že umožňují přežít v atmosféře neustálých změn a umožnit tak dosažení úspěchu. (Anderson in [10]). Agilní projektové řízení staví na jednoduché myšlence inkrementálního či chcete-li iteračního řízení projektu. ( ) Vše se dělá postupně po dílčích funkčních celcích, což umožňuje včas odhalit případné problémy, reagovat na ně a případně také včas zastavit či redefinovat projekt jako takový. To je ostatně také důvod, proč se tento způsob řízení projektů velice dobře etabloval v oblasti softwarového vývoje, kdy software už z principu svého fungování staví na dílčích funkčních celcích. [31]. Základní charakteristika tohoto přístupu je zachycena v tzv. manifestu agilního vývoje software: Tabulka 1: 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 tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: Jednotlivci a interakce Fungující software Spolupráce se zákazníkem Reagování na změny před procesy a nástroji před vyčerpávající dokumentací před vyjednáváním o smlouvě před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. 2.2 NĚKTERÉ METODIKY AGILNÍHO PROJEKTOVÉHO MANAGEMENTU Zdroj: [1], [18] Termín agilní projektový management je zastřešujícím pojmem pro různé vývojové metodiky [4], mezi které Hoda a kol. [15] a další autoři řadí: 1) Extreme Programming (XP) 2) Scrum 3) Crystal 4) Feature Driven Development (FDD) 5) Dynamic Systems Development Method (DSDM) 6) Adaptive Software Development (ASD) 7) Lean Software Development (LD) /doplněno dle [10]/ Některé metodiky je možné i kombinovat, vynikající výsledky přináší např. kombinace Scrum a Extreme Programming [19]. Specifičnost prostředí vývoje software zachycuje následující výrok projektového manažera jisté softwarové společnosti: Je velmi obtížné řídit vývojáře software. Nikdy nedělají to, co jim říkám, nikdy nereportují status projektu a vždy jsou pozadu za plánem a překračují rozpočet. [6] Eric D. Brown pak v souvislosti s problematikou řízení projektů reaguje: Možná není řízení softwarových vývojářů o nic obtížnější než řízení kohokoli jiného Možná, že příčinou problémů je samotný systém jejich řízení. [6]. Karelsky a Vander Voort [17] popsali hlavní rozdíly mezi klasickým a agilním přístupem. Jako hlavní slabinu metodiky klasického projektového managementu vnímají snahu eliminovat změny a vyvarovat se nejistoty. Agilní metodiky nabízejí řešení známých problémů, kterými jsou: nedokonalé odhady, překročení odhadovaných délek trvání činností, závažné problémy s produktem v téměř dokončeném stavu a např. také Ganttovy diagramy, nedostatečně reflektující realitu. Dle stejných autorů pak v popředí diskuse mají stát (1) zákazník, (2) definované rysy produktu a indikátory jejich dokončení, (3) testování, (4) iterace, (5) vývoj řízený požadovanými vlastnostmi produktu, (6) správné odhady /pro odhady pomocí metody Planning Poker viz [17]/, (7) nepřetržitá integrace, (9) dokumentace a (10) řízení rizik. Komplexní charakteristiku agilních metod přinášejí též CC Pace Systems [8]. Velmi názorným a ilustrativním příkladem, jak lze aplikovat metodiku agilního projektového managementu, je prezentace metodiky Scrum [25], přehlednou základní charakteristiku agilních metodik podává i Augustine [3].
Tabulka 2: Základní rozdíly mezi agilními a standardními metodikami Kategorie Tradiční přístup Agilní přístup Základní předpoklady Systémy jsou plně specifikovatelné, predikovatelné a mohou být vyvinuty na základě rozsáhlého plánování Zaměření Procesy Lidé Vysoce kvalitní SW může být vyvinut malými týmy, které využívají neustálého vylepšování návrhu, rychlé odezvy a změny Management Controlling / Příkazy a kontrola Zjednodušování / Vůdcovství a spolupráce Řízení znalostí Explicitní Tacitní Komunikace Formální Neformální Zapojení zákazníka Požadavky, schůze a dodávky Neustálé Vývojáři Pracují individuálně v rámci týmů Spolupracují nebo pracují ve dvojicích Organizační struktura Vývojový model Mechanistická (byrokracie, vysoký stupeň formalizace) Tradiční vodopád, spirála či jejich modifikace Organická (flexibilní, upřednostňuje kooperaci) Evoluční dodávky (iterativní, inkrementální) Technologie Jakákoli Objektově orientovaná Rysy produktu Kompletní popis Nejpodstatnější nejdříve Testování Na konci vývojového cyklu Iterativní Dokumentace Pečlivě zpracovaná Pouze, pokud je třeba Zdroj: Upraveno na základě [15], [21] Definici rozdílů mezi přístupy v tradičním a agilním projektovém řízení se ve své práci věnují též Boehm & Turner [5]: Aplikační rovina: Agilní přístupy jsou velmi proměnlivé, a to během vývoje i po jeho ukončení; projektové týmy bývají menší než při použití tradičních metodik projektového řízení. Rovina řízení: Zákazník se stává členem vývojového týmu. Doprovodná dokumentace je skromnější. Technická rovina: Požadavky jsou zachyceny méně formálním způsobem než jsou oficiální projektové dokumenty. Projektové práce jsou prováděny v krátkých inkrementálních intervalech. (Dílčí) přijetí ze strany zákazníka následuje po dílčím testování produktu, nikoli až po celkovém rozsáhlém testu. Zaměstnanci: Agilní vývojáři bývají vysoce schopnými odborníky, kteří se orientují v mnoha oblastech. V tradičním přístupu jsou do projektu zapojeni úzce zaměření specialisté (např. testeři pro fázi testování). Agilním týmům do jisté míry prospívá určitá (zdravá) míra chaosu. Karelsky a Vander Voort [17] připomínají, že klíčovou roli hrají v agilních metodikách zákazník, produktový rys a dokončení vývoje: Zákazník není vnímán pouze jako subjekt, který platí za výsledný produkt. V agilních konceptech je role zákazníka velmi důležitá, protože jsou s ním konzultována rozhodnutí (schvaluje je), zákazník definuje prioritu jednotlivých rysů produktu a odpovídá na hlavní otázky. V ideálním případě by měl být zástupce zákazníka plnohodnotným členem projektového týmu na plný úvazek. Takový přístup je důležitý proto, že na začátku často ani zákazník neví, co přesně od výsledného produktu může očekávat. Rysy produktu musejí být vždy definovány z pohledu zákazníka. Rys jako takový musí splňovat následující požadavky: (1) Je prvkem funkcionality produktu, popsaný zákazníkem jeho vlastními slovy spíše ve smyslu chování systému než v kontextu detailů implementace, (2) lze jednoznačně ověřit dokončení rysu mírou spokojenosti zákazníka a (3) rys musí být natolik užitečný, aby za něj byl zákazník ochoten zaplatit. V tom de facto tkví podstata celého agilního přístupu: tým musí mít neustále na paměti, že vyvíjí produkt a dodává řešení platícímu zákazníkovi. Ačkoli se stav, kdy jsou produkt nebo jeho části hotovy, může zdát snadno definovatelným, praxe ukázala, že je často možné setkat se s rysy, které mají status hotové hotové. V agilním projektovém managementu má slovo hotovo specifickou definici a znamená procentuální stupeň dokončení. Rys nebo produkt jsou hotovy, pokud prošly všemi testovacími fázemi, včetně schvalovacího řízení. V ideálním případě je možné použít automatického regresního testování (Pro více informací o testování SW viz např. [9]).
2.3 POSUN OD TRADIČNÍHO K AGILNÍMU PROJEKTOVÉMU MANAGEMENTU A JEHO RIZIKA Z uvedených rozdílů mezi tradičním a agilním přístupem k projektovému managementu vyplývá, že změna způsobu realizace projektů přechod k agilnímu řízení nemusí být vůbec jednoduchá [19]. Nerur, a kol. [21] identifikovali několik oblastí, kterým je nutné věnovat náležitou pozornost, protože jsou z hlediska modifikace přístupu k vývoji software velmi důležité. Jde o následující: (1) Způsob řízení a organizace tradiční role projektového manažera se musí změnit z plánovače a kontrolora na zprostředkovatele, který dokáže koordinovat společnou snahu vytvořit kvalitní produkt. (2) Lidský faktor programátoři a vývojáři se musejí naučit lépe pracovat v týmech. Doposud také platí, že metodiku agilního projektového řízení je možné použít takřka výhradně v prostředí, kde pracují nadprůměrní vývojáři. (3) Procesy přechod od procesně orientovaného přístupu k modelu, který na první místo dává lidi, může být komplikovaný. Agilní metodiky totiž kladou na první místo časté diskuse a používají plánovacích procesů, které reflektují, že všechno je nejisté. Hlavní překážkou bývá přechod na iterativní vývojový model. (4) Technologické aspekty Technologie, která se při agilním vývoji používá, je také odlišná. Některým firmám proto může působit potíže opuštění stávajících nástrojů. Jednou z doprovodných konsekvencí je i nutnost investic do nových vývojových prostředků. Obrázek 1: Základní schéma agilního vývoje software Zdroj: Vlastní zpracování na základě Mountain Goat Software in [3] Blíže k terminologii agilního projektového managementu viz např. [15]. 2.4 PODSTATNÉ FAKTORY VEDOUCÍ K ÚSPĚCHU V PROJEKTECH AGILNÍHO VÝVOJE SOFTWARE Produkty a služby, které jsou nabízeny v tržním prostředí a mají ambice být konkurenceschopné, musejí mít dostatečně vysokou přidanou hodnotu a přinášet kupujícím (zákazníkům) odpovídající užitek. V České republice se na nabídkové straně trhu pohybuje velké množství subjektů, které mezi sebou soutěží, a vytvářejí tak náročné konkurenční prostředí. V případě České republiky lze pro ilustraci využít Sektorové databáze agentury CzechInvest [12]; celkem sekce ICT k 16. srpnu 2011 obsahovala 698 firem (od dodavatelů aplikačních služeb až po vzdělání a training), kategorie Vývoj aplikací na zakázku pak 345 firem. Databáze CreditInfo v kategorii 62.01 Programování obsahovala na podzim 2011 údaje o 3.408 podnicích. Platí, že čím silnější je konkurence, tím vážnější důsledky může mít každý neúspěch. Praxe ukazuje, jak nebezpečná mohou být selhání a jak dalekosáhlé důsledky může mít systémová chyba. Pro ilustraci: diskutovaným problémem může být například bezpečnost dat uložených na internetu v tzv. cloudu. Příkladem totálního bezpečnostního selhání z nedávné doby může být případ Dropbox, kdy přihlášení uživatelé měli v jeden moment kvůli chybě v programovém kódu volný přístup k datům všech ostatních uživatelů dané služby (The New York Times Bits: Tech Talk, 23. 6. 2011 dostupné pouze přes službu itunes). Cao & Chow [10] definovali na základě rešerše odborné literatury čtyři základní oblasti, které souvisí s úspěšným dosažením cíle projektu. Těmito oblastmi jsou: (1) kvalita dodání dobrého produktu (výstupu), (2) rozsah splnění všech požadavků a cílů, (3) čas dodání požadovaného řešení včas a (4) náklady dodání produktu při respektování stanoveného finančního rámce a vynaloženého úsilí. Na základě výzkumu výše uvedených autorů, který byl realizován v rámci 109 projektů řízených pomocí agilních přístupů (celkem se šetření zúčastnilo 408 respondentů členů projektových týmů),
bylo zjištěno, že nejpodstatnějšími faktory, které ovlivňují celkový úspěch projektu, byly ty, které uvádí následující tabulka. Tabulka 3: Faktory ovlivňující podstatné znaky projektu Faktor ovlivňující významně znak projektu Kvalita Rozsah Čas Náklady Prostředí v týmu Zdatnost týmu Zapojení zákazníka Procesy projektového managementu Agilní techniky softwarového inženýrství Strategie dodání produktu Zdroj: Upraveno na základě [10] Je nutné podotknout, že interpretace dosažených výsledků je limitována několika činiteli: Vývojové týmy nepoužívaly všechny dostupné agilní metodiky, více než polovina (53 %) projektů používala k vývoji software metodiku XP, respondenti byli členy agilních asociací (jejich odpovědi tak mohly do jisté míry propagovat agilní metodiky), převažují evropské projekty (56 %), a pro výzkum byl použit relativně malý vzorek projektů. 2.5 VÝVOJ SOFTWARE V ČESKÉ REPUBLICE Vývoj software je v rámci klasifikace ekonomických činností CZ-NACE zařazen do sekce J (Informační a komunikační činnosti) 62.01 (Programování). Ministerstvo průmyslu a obchodu České republiky pravidelně zpracovává Finanční analýzu podnikové sféry, přičemž data použitá v tomto příspěvku reflektují stav za rok 2010. Ucelenější statistické údaje jsou dostupné pouze za celou sekci 62, která obsahuje již zmíněnou sekci 62.01 Programování, a dále pak sekce 62.02 Poradenství v oblasti informačních technologií, 62.03 Správa počítačového vybavení a 62.09 Ostatní činnosti v oblasti informačních technologií. I přes daná omezení (včetně relativně malého počtu zkoumaných firem 53 podniků) mají údaje jistou vypovídací hodnotu. Tabulka 4: Některé ukazatele finanční výkonnosti některých podniků z vybraných sektorů Ukazatel Hodnota v r. 2010 Hodnota v r. 2009 ROE 62 23,04 % 21,21 % ROE služby 8,31 % 7,45 % Marže 62 8,60 % 8,27 % Marže služby 4,88 % 4,35 % Vysvětlivky: ROE = rentabilita vlastního kapitálu podniků; marže = EBIT/obrat; EBIT = zisk před úroky a zdaněním; 62 = kat. Činnost v oblasti informačních technologií; služby = sekce G až N bez sekce K Zdroj: Upraveno dle [20] Z výše uvedených dat vyplývá, že výnosnost vlastního kapitálu podniků, které charakteristikou svých aktivit spadají do sekce 62, je násobně vyšší než průměrná výnosnost vlastního kapitálu firem z oblasti služeb. Sekce 62 totiž dosáhla ze všech sledovaných oblastí za rok 2010 druhé nejvyšší hodnoty ROE ze všech sledovaných odvětví, předstižena byla pouze sekcí 32 (Ostatní zpracovatelský průmysl), v níž byla průměrná hodnota ROE 23,74 %. I zisková marže je v případě IT podniků téměř dvakrát vyšší, než odpovídá celkovému průměru v kategorii služby. Česká republika je evropským velikánem v oblasti vývoje software. Ať již jde o úspěšné firmy českého původu, které nabízejí např. antivirové programy (např. AVG, Alwil aj.), nebo o centra nadnárodních korporací (Microsoft, IBM, NESS, apod.), tento sektor je pro Českou republiku důležitý a má velký rozvojový potenciál [11].
ZÁVĚR Jak vyplývá z výše komentovaných dat, vývoj sekce Informačních a komunikačních činností dosahuje z pohledu podnikové výkonnosti v České republice pozoruhodných ekonomických výsledků. Jaká je však situace z pohledu implementace a využití metodik agilního projektového řízení? V České republice působí tzv. Agilní asociace [1]. Jejím cílem je zvýšit povědomí o Agilních metodách řízení a vytvořit platformu pro sdílení informací a zkušeností z oblasti agilních metod. Buchalcevová a Leitl [7] uvádějí, že agilní metodiky se čím dál tím více rozšiřují (Augustin [3] pak na základě Forrester Research ukazuje, že v roce 2005 využívalo v USA a EU agilních metodik 14 % SW firem a dalších 19 % tak chtělo v budoucnu učinit), avšak povědomí dokonce i odborné veřejnosti o dané problematice nebylo ještě před několika lety moc velké. Uvedení autoři též poukazují na to, že [v rámci využití agilního projektového řízení] Nejde jen o plné nasazení určité agilní metodiky, ale také o kombinace jednotlivých agilních metodik anebo aplikaci agilních přístupů v rámci tradičních metodik. [7] Projektový tým však může aplikovat principy agilního vývoje, aniž by explicitně sledoval konkrétní, standardizovanou metodiku. To se také potvrdilo při diskusi autorů článku s odpovědnými pracovníky několika českých firem, které se dlouhodobě zabývají vývojem či úpravou software. Z rozhovorů vyplynulo, že agilní projektové řízení nelze aplikovat na všechny softwarové projekty, nicméně tam, kde se vývojáři setkávají s vyšší mírou nejistoty/rizika, je jeho nasazení velmi účelné a přínosné. Proto má agilní projektový management v rámci projektového managementu jako takového významnou pozici. LITERATURA [1] Agilní asociace [online]. AgilniAsociace.cz, 2011 [cit. 2011-09-10]. Dostupné na: http://agilniasociace.cz/ [2] ARCHIBALD, R., D. A Global System for Categorizing Projects. Presentations by the author at IPMA Congresses in Moscow (2003) & Budapest (2004), plus other PMI venues and following presentation in Brasilia, Brazil, Sept. 21, 2004 [3] AUGUSTINE, S. Transition to Agile Project Management [online]. AgileAlliance.org, 2007 [cit 2011-06-23]. Dostupné na: http://agile2007.agilealliance.org/downloads/handouts/augustine_474.pdf [4] BOEHM, R. E. Agile Project Management [online]. Software Composition Technologies [cit. 2011-06-23]. Dostupné na: http://kuperpresents.com/nycspin/resources/raybohem%20- %20AgileProjMgmt.pdf [5] BOEHM, B.; TURNER, R. Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison Wesley, 2005. ISBN: 978-0321186126 [6] BROWN, E.D. Agile Project Management and Product Strategy A Case Study [online]. EricBrown.com, 2007 [cit. 2011-08-23]. Dostupné na: <http://ericbrown.com/agile-projectmanagement-product-strategy-a-case-study.htm> [7] BUCHALCEVOVÁ, A.; LEITL, M. Průzkum používání agilních metodik v ČR. In: Objekty 2006. Praha: PEF ČZU, 2006. ISBN: 80-213-1568-7. [8] CC Pace Systems. Agile Project Management [online]. Ccpace.com, 2011 [cit. 2011-06-23]. Dostupné na: http://ccpace.com/resources/documents/agileprojectmanagement.pdf [9] CHILLAREGE, R. Software Testing Best Practices.[online] IBM: Center for Software Engineering, 1999 [cit. 2011-08-16]. Dostupné na: http://www.cs.ucf.edu/~turgut/courses/eel5881_sei_fall03/testingbestpractice.pdf [10] CHOW, T.; CAO D-B. A survey study of critical Access factors in agile software projects. The Journal of Systems and Software, n. 81, 2008, pp. 961 971. ISSN: 0164-1212 [11] CzechInvest: IT & Software Development in the Czech Republic [online]. CzechInvest.org, 2010 [cit. 2011-08-22]. Dostupné na: <http://czechinvest.org/data/files/ict-nahled-lock-98-en.pdf> [12] CzechInvest: Sektorové databáze - ICT [online]. CzechInvest, 2011 [cit. 2011-08-16]. Dostupné na: http://suppliers.czechinvest.org/web/gateway.nsf/g?openform&lang=cs#ict [13] European Commission. Learning From Peers/e-Business cases. Brussels: DG Enterprise and Industry, 2009. [14] European Commission. An Economic Assessment of ICT Adoption and its Impact on Innovation and Performance. Berlin/Brussels: DG Enterprise and Industry, 2008. [15] HODA, R.; NOBLE, J.; MARSHALL, S. Agile Project Management [online]. Christchurch: NZCSRC, 2008 [cit. 2011-07-01]. Available at WWW: http://nzcsrsc08.canterbury.ac.nz/site/proceedings/individual_papers/pg218_agile_project_mana gement.pdf
[16] International centre for komplex project management [online]. ICCPM.com, 2010 [cit. 2012-09- 07]. Dostupné na: http://iccpm.com/ [17] KARELSKY, M.; VANDER VOORT, M. Agile Project Management (or, Burning Your Gantt Charts) [online]. Boston: Embedded Systems Conference, 2008 [cit. 2011-07-01]. Available at WWW: <http://www.atomicobject.com/files/embeddedagilepmpaper.pdf> [18] Manifesto for Agile Software Development [online]. Agilemanifesto.org, 2011 [cit. 2011-10-09]. Dostupné na: http://www.agilemanifesto.org [19] MARTIN, R. C.; SCHWABER, K. Best Practices in Scrum Project Management and XP Agile Software Development [online]. AgileAlliance.org, 2004 [cit. 2011-08-23]. Dostupné na: http://www.objectmentor.com/resources/articles/primavera.pdf [20] Ministerstvo průmyslu a obchodu České republiky. Finanční analýza podnikové sféry 2010 [online]. Praha: MPO ČR, odbor 06500, 2011 [cit. 2011-08-10]. Dostupné na: http://www.mpo.cz/dokument89407.html [21] NERUR, S.; MAHAPATRA, R.; MANGALARAJ, G. Challenges of Migration to Agile Methodologies: Organizations must carefully assess thein readiness efore treading the path of agility. Communications of the ACM, No. 5, Vol. 48, May 2005. Pp. 73 78. ISSN: 0001-0782. [22] OECD. Measuring the Impacts of ICT Using Official Statistics. Paris: WPIIS, 2008. [23] PHILLIPS, J. IT Project Management: On Track from Start to Finish. McGraw-Hill Osborne Media. 2010. ISBN: 978-0071700463 [24] REYNOLDS, J. E-Business: A Management Perspective. Oxford: Oxford University Press, 2010. ISBN 978-0-19-921648-2. [25] SHOJAYEE, H. Scrum Master in Less Than 10 Minutes [online]. Axosoft, 2008 [cit. 2011-08-11]. Dostupné na: http://www.youtube.com/watch?v=q5k7a9yeoui [26] SKALICKÝ, J. Kategorie projektů, přístupy a teorie projektového managementu. Brno, 2010. Konference projektový management: možnost nebo nutnost [27] SKALICKÝ, J., JERMÁŘ, M., SVOBODA, J. Projektový management a potřebné kompetence. 1. vydání. Plzeň: Západočeská univerzita v Plzni, Vydavatelství, 2010. 406 stran. ISBN 978-80- 7043-975-3 [28] SPPR. Best Project Management 2011 [online]. Sppr.sk, 2011 [cit. 2011-08-22]. Dostupné na: http://www.sppr.sk/index.php/sk/pm-dokumenty/doc_download/110-best-project-management- 2011 [29] VACEK, J. Evaluation of the new product development and R&D projects. In AEDS 2007. Pilsen : University of West Bohemia, 2007. s.83-87. ISBN 978-80-7043-600-4 [30] VACEK, J. How to select the portfolio of new product development projects. In AEDS 2008. Pilsen: University of West Bohemia, 2008. s.99-106. ISBN 978-80-7043-685-1 [31] ZIKMUND, M. Agilní projektové řízení novinka stará přes 20 let [online]. Businessvize.cz, 2010 [cit. 2011-08-16]. Dostupné na: http://www.businessvize.cz/rizeni-a-optimalizace/agilniprojektove-rizeni [32] ZIKMUND, M. Agilní projektové řízení novinka stará přes 20 let [online]. Businessvize.cz, 2010 [cit. 2011-08-16]. Dostupné na: http://www.businessvize.cz/rizeni-a-optimalizace/agilniprojektove-rizeni Adresy autorů: Ing. Jan Petrtyl, Západočeská univerzita v Plzni, Fakulta ekonomická, Katedra marketingu, obchodu a služeb, petrtyl@kmo.zcu.cz doc. Ing. Jiří Skalický, CSc., Západočeská univerzita v Plzni, Fakulta ekonomická, Katedra podnikové ekonomiky a managementu, skalicky@kpm.zcu.cz doc. Ing. Jiří Vacek, Ph.D., Západočeská univerzita v Plzni, Fakulta ekonomická, Katedra podnikové ekonomiky a managementu, vacekj@kpm.zcu.cz
AGILE PROJECT MANAGEMENT Abstract In its introductory section the paper summarizes different approaches of project management to various categories of projects. The following part focuses on the main differences in traditional and agile project management and specifically on the use of agile project management in software development projects and on the transition of project management paradigm from the traditional to agile one, including some of its inherent risks and critical success factors. The final section compares financial performance of companies from selected sectors of national economy and emphasizes the importance of the SW sector in the Czech economy. Key words project management, agile project management, software development, financial performance JEL Classification M11, M15, M31