SCRUM - agilní metoda pro vývoj softwaru

SCRUM - agilní metoda pro vývoj softwaru Pavel Jirava, Květoslava Bartůňková Univerzita Pardubice, Fakulta ekonomicko-správní, Ústav systémového inženýrství a informatiky, Studentská 84, 532 10 Pardubice Email: [email protected] Abstrakt: Předložený článek je zaměřen na agilní metodiky vývoje softwaru, které se jeví jako vhodné pro projekty, kde je silný tlak na čas a kde jsou často měněny potřeby a požadavky zákazníka. Konkrétně je zde využita metodika SCRUM, která se na rozdíl od tradičních přístupů (kde je významná přípravná fáze vývoje produktu) zaměřuje na rychlý a efektivní vývoj produktu. S využitím této metody byl vytvořen software ScrumBoard. K němu je možné přistupovat přes webové rozhraní pomocí účtů s hesly. Umožňuje řídit především menší projekty a celý instalační balíček je volně stažitelný. Při tvorbě bylo využito PHP, data jsou uložena v MySQL databázi. Grafické rozhraní bylo navrženo minimalisticky pro jednoduché a intuitivní ovládání. Klíčová slova: Projekt, SCRUM, SCRUMBoard, agilní metodiky, PHP, MySQL Abstract: The presented article deals with agile methods and their use in software development. These methods show a very good application for projects that need to be created quickly, and where customers frequently change requirements. Specifically, the Scrum method was used here. Unlike traditional methods where there is strong emphasis on the initial phase of software development this method focuses on rapid and efficient product development. Using the chosen method was developed application software called ScrumBoard. It allows users to manage projects using Scrum method, which are mid-range. The application is accessible through a web interface and allows secure access via password-protected accounts. The graphical interface was designed minimalist and simple to make it user to quickly orient and intuitively handled various features. The data are stored in MySQL database. Keywords: Project, SCRUM, SCRUMBoard, agile methods, PHP, MySQL

1. Úvod Řízení projektů informačních systémů je v současné době velmi dynamickou oblastí jak z pohledu praxe tak teorie. K dispozici máme mnoho více či méně komplexních metodik řízení projektů (PRINCE2, EPMS, PMBOK a další), na trhu najdeme podpůrné softwarové prostředky pokrývající všechny fáze projektu, pro řízení podnikové informatiky existují také mnohé metodiky jako ITIL, COBIT (Gála, L., Pour, J., Toman, P., 2006). Paradoxně však stále platí, že značné procento realizovaných projektů informačních systémů (IS) končí překročením rozpočtu, zpožděním či úplným neúspěchem a ukončením projektu (Říhová, Z. 2009; Bloch, M., a kol. 2012). Proto je důležité hledat stále nové postupy a nástroje pro řízení a realizaci projektů IS. V předloženém textu se zaměříme na skupinu takzvaných agilních metodik (Goodpasture, J. C. 2010). Jedná se moderní přístupy k tvorbě informačního systému, mezi něž řadíme i tzv. SCRUM (Schwaber, K. 2004). Metoda SCRUM a její využití pro tvorbu aplikace SCRUMBoard je pak hlavní náplní příspěvku. Mimo to jsou zde rozlišeny i tradiční a agilní přístupy a představena vytvořená aplikace SCRUMBoard.

20

SYSTÉMOVÁ INTEGRACE 3/2013

SCRUM - agilní metoda pro vývoj softwaru

Cílem příspěvku je také ukázat výhody zvolené metody na reálném případu tvorby aplikačního software a pootevřít tak metodě SCRUM dveře k širšímu využití v IT odvětví respektive v řízení projektů IS v České republice (ČR).

1.1 Formulace problematiky Agilní metodiky jsou alternativním přístupem k projektům tvorby IS, jež je hojně využíván především u zahraničních IT společností, začíná si však již získávat své příznivce i v ČR (Buchalcevová, A. 2007; Buchalcevová, A. 2009b). Jednotlivé agilní metody mají specifické znaky, přesto jsou často navzájem kombinovány a je tak využíváno synergie jejich výhod.

1.2 Agilní metodiky Hlavním cílem celé skupiny těchto metod je co nejlevněji a co nejdříve dodat zákazníkovi produkt, který splňuje všechny požadavky, je kvalitní a umožňuje provádět i následnou údržbu a podporu. Vytvářet rychleji a efektivněji je hlavním požadavkem dnešní doby. Především u projektů IS či internetových projektů je největším problémem rychlost vývoje. Proto začaly být po roce 2000 prosazovány metody s co nejrychlejším vývojem softwaru (SW). Pojem agilní metoda je skupina metod, kde je hlavním měřítkem čas a kde prověření správnosti navrženého systému probíhá tak, že parciální produkt je předložen zákazníkovi a posléze je upravován na základě dodaných připomínek zákazníka. Jak již bylo zmíněno, v ČR se agilní metody začínají dostávat do podvědomí firem a odborníků na informační a komunikační technologie. Mezi agilní metody patří (Bruckner, T., Voříšek, J. a kol. 2012; Kadlec, V. 2004): SCRUM, Crystal metody, Agilní modelování (Agile Modeling), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Feature–Driven Development (FDD), Extrémní programování (Extreme Programming, XP), Lean Development. Tradiční metody vycházejí z definování požadavků na systém (funkcionalitu). Tyto požadavky byly definovány na počátku vývoje a jsou fixní (tedy neměnné), proměnné veličiny jsou zde čas a zdroje. Lze říci, co bude přesně systém umět, avšak náklady a čas nejsou předem přesně určeny (Jirava, P., 2004). Agilní metody využívají jako proměnnou veličinu požadavky, kdežto čas a náklady jsou pevně stanoveny. Mezi základní principy pro dodržování dané posloupnosti agilních metod patří plán sestavený tak, aby nové funkce mohly být do vývoje dodávány často, mnohdy i denně. Dalším důležitým principem je správná a přímá komunikace v týmu pracovníků. Jedná se o časté schůzky, které dříve odhalí existující problémy. Nepřetržitá komunikace se zákazníkem je podmínkou správného fungování agilních metod. Poslední důležitou podmínkou je aktivní komunikace ze strany budoucího uživatele s vývojovým týmem, uživatel se musí podílet jak na návrhu, tak na testování. To musí probíhat opakovaně


21

Pavel Jirava, Květoslava Bartůňková

a průběžně, vždy před implementací testovaných částí (Agile Alliance, 2010; Buchalcevová, A. 2009a; Cockburn, A. 2005).

2. SCRUM Jde o nejznámější metodu agilního programování. Vznikla na počátku devadesátých let dvacátého století a postupně se rozšířila do celého světa. Název vznikl z anglického slova „scrum“, které je využíváno v ragby. Toto slovo znamená skrumáž, nebo mlýn a je vysvětleno jako soustředění několika hráčů na jednom místě tak, aby dotlačili míč společně na požadovanou pozici. Vývojový tým si také klade za cíl „dotlačit míč“ na požadovanou pozici, a sice dokončit produkt tak, jak vyžaduje zákazník (Rubin, K. S. 2012). Místo poskytnutí kompletního a detailního popisu jak projekt vytvořit je vše ponecháno na vývojovém týmu, který dělá to nejlepší, aby byl celý projekt správně vytvořen. Postupuje se pomocí iterací, které jsou nazývány sprint. Tyto iterace trvají dva až čtyři týdny. SCRUM se hodí především pro projekty vývoje SW, pro projekty, kde jsou naléhavé a často se měnící požadavky od zákazníka na činnosti výsledného systému. Všechny pojmy, které jsou využívány v metodě SCRUM, se nepřekládají do českého jazyka, používají se pojmy jako Product Backlog, Sprint Backlog, Sprint Review, ad. (Cockburn, A. 2005; Knesl, J. 2009; Kučera, F., 2009).

2.1 Role Role účastníků ve SCRUMu se rozděluje na dvě skupiny: Pigs a Chickens. Ve SCRUMu je rozdělení do skupin Pigs a Chickens takové, že skupina Pigs zastupuje osoby, které přímo souvisí s vývojem a do skupiny Chickens patří osoby, které se přímo vývoje neúčastní, což jsou manažeři a uživatelé produktu. Podrobněji jsou role vysvětleny níže. (Schwaber, K. 2004). Dělení dle (Schwaber, K. 2004) je následující. Do skupiny Pigs tedy patří dle terminologie metody SCRUM: Product Owner, ScrumMaster,Team. A do skupiny Chickens jsou zařazeni: Managers, Stakeholders. Product Owner zastupuje zájmy všech zúčastněných, zodpovídá za priority, určuje, co bude implementováno v příštím sprintu a také určuje detaily implementace. Sleduje požadavky zákazníka, návratnost investic a spuštění plánů. List požadavků je nazýván Product Backlog a Product Owner hlídá jeho dodržování, především to, aby byla hlavní funkcionalita vyvinuta včas. Hlavní funkcí ScrumMastera je odstínit tým programátorů od okolního světa. Řeší spory, řídí vývojáře, ale také zajišťuje, aby týmu fungovalo HW vybavení, aby měli správný SW. Nejvhodnější pro tuto roli se jeví Project Manager. Nesmí však být zároveň programátorem, neboť by nemohl ostatní programátory odfiltrovávat od rušivých vlivů, protože by byl sám zranitelný. Proto autor této metody zvolil název ScrumMaster, aby nebyla tato funkce přímo spojována s tradičním Projektovým manažerem. ScrumMaster je pouze zprostředkovatel, který nedostává žádná ocenění za splněné projekty, avšak je velice důležitým mezičlánkem mezi uživatelem Product Owner a týmem (Knesl, J. 2009). Team pracuje na rozvoji požadovaných funkcí. Členové týmu jsou kolektivně zodpovědní za úspěch každé části projektu a také za úspěch projektu jako celku. Jedná se o skupinu asi 3 – 6 (někdy je uváděno do 7) osob (Sutherland, J. 2003). Členové jsou programátoři, osoby zodpovědné za řízení kvality, dokumentátoři. Pokud 22



je vývojářů více, vzniká ve SCRUMu více týmů, přičemž dělení může být takové, že jeden tým je zodpovědný za jednu skupinu funkcí a druhý za druhou skupinu, nebo může být systém rozdělen na vrstvy a každému týmu může být přidělena jedna vrstva. Managers pomáhají nastavit prostředí v okolí vývoje. Nejedná se ani o vývojáře, ani Product Owner či ScrumMastery. Pokud se hovoří o Stakeholders, jedná se o tým od zákazníka, který testuje funkce a vznáší připomínky zvenčí, během vývoje produktu. Přítomnost zákazníka je velice důležitá, může se účastnit diskuzí, zodpovídá otázky a tím se podílí na vývoji skutečně užitečného produktu (Knesl, J. 2009).

2.2 Hlavní činnosti Základním prvkem v projektování pomocí SCRUM je vyvíjený produkt. Od týmu se očekává, že na konci každého sprintu předvede část produktu nebo stav systému právě k určenému dni. Dalším důležitým nástrojem zde je Product Backlog (nevyřízený), což je seznam funkcí, které mají být přidány do vyvíjeného systému. Správcem tohoto seznamu je Product Owner, který sleduje, zda tým pracuje na funkci s nejvyšší prioritou. Nejoblíbenější a také nejcennější z pohledu funkčnosti je vytvoření Product Backlogu přímo dle krátkého popisu funkcí od uživatele či zákazníka. Na obrázku 1 je zobrazen celý průběh metody SCRUM. Na sprint navazuje vznik nové funkcionality (přírůstek), která je dále implementována v rámci sprintu (Kučera, F. 2009; Schwaber, K. 2004). Hlavní činností v této metodě je sprint. SCRUM patří mezi iterativní procesy, projekt je tak rozdělen na několik po sobě jdoucích sprintů. Všechny sprinty jsou časově omezeny, většinou trvají od dvou týdnů do jednoho měsíce. Každý sprint se skládá ze Sprint Planning Meeting , kde je vytvořen Sprint Backlog. Jedná se o seznam úkolů, které musejí být provedeny během sprintu. Během těchto setkání probíhá komunikace týmu a Product Ownera. Je rozebrán Product Backlog a jsou vybrány prvky s nejvyšší prioritou, se kterými se bude pracovat v následujícím sprintu.

Product Backlog

Sprint Backlog

Sprint Max. 30 dní Denní setkání

Pracovní přírůstek na SW

Obr. 1: SCRUM schéma (Zdroj: Project Management Research Institute. 2010) Každý člen týmu se rozhodne, kolik položek je schopen zvládnout a k tomuto číslu se zavazuje. Následně je vytvořen již zmíněný Sprint Backlog. Každý den probíhají setkání členů týmů, kterým se říká Daily Scrum Meeting. Těchto setkání se účastní Product Owner i ScrumMaster. Délka trvání těchto setkání nepřevyšuje patnáct minut. Členové týmu zde diskutují, co vytvořili předchozí den, co bude vytvořeno dnes a jsou tak identifikovány možné překážky dalšího vývoje. Každý programátor tak může sdělit


23


ostatním z týmu, že se například setkal s chybou, a proto se jeho úkol zdržel, nebo naopak vývoj šel rychleji, než očekával, proto může pracovat na dalších svých úkolech. Tato setkání pomáhají týmu při synchronizaci a vzájemné komunikaci (Kučera, F. 2009). Na konci každého sprintu probíhá Sprint Review. Tým představuje vlastnosti, které byly přidány systému během sprintu, který právě proběhl. Cílem těchto setkání je zpětná vazba od Product Ownera nebo uživatelům či zákazníkům, kteří byli pozváni k Sprint Review. Z tohoto setkání mohou vzejít změny na základě nově objevených skutečností. Ovšem také to může vést k nalezení chyb a k přezkoumání a lze také dopisovat další funkce do Product Backlogu. Na konci každého sprintu také probíhá činnost, která je nazývána Sprint Retrospective. Kromě týmu se účastní také ScrumMaster a Product Owner. Jedná se o setkání, kde probíhá zhodnocení celého minulého sprintu a diskutuje se nad otázkami, co by šlo a bylo dobré zlepšit v následujícím sprintu (Schwaber, K. 2004).

3. Vývoj aplikace SCRUMBoard Součástí této práce je vytvoření aplikace SCRUMBoard, která demonstruje použití metody SCRUM. Jedná se o nástroj, který zobrazuje využití metody na reálném projektu, a to vytvoření elektronické formy tabule SCRUMBoard. Vývoj probíhal v souladu s metodou SCRUM. Pro vývoj dané aplikace byl vybrán skriptovací jazyk PHP a databázové prostředí MySQL. Konkrétně byl zvolen SW balík EasyPHP, phpMyAdmin a vývojové prostředí NetBeans IDE.

3.1 Uživatelé Pro samotnou aplikaci jsou brány v úvahu čtyři druhy uživatelů. Do skupiny User patří programátoři, databázový specialisté, analytici, testeři ad., kteří se přímo podílejí na tvorbě aplikace. Tito uživatelé si mohou zobrazit své projekty, své sprinty a vybrat úkol, na kterém budou pracovat, tento úkol pak označit jako rozpracovaný nebo hotový. Jejich úkolem je správa reportů, které jsou vázány na daný úkol. Dalším uživatelem je ScrumMaster. Jeho úlohou je kontrolovat, spravovat a starat se o Team (Usery). Definuje sprinty a úkoly, které vytváří, čte, aktualizuje i maže. Avšak nesmí zasahovat do zobrazování hotových/rozpracovaných úkolů a také nesmí na úkolech pracovat. ScrumMaster nezasahuje do správy projektů, může je zobrazit, avšak nijak je neupravuje, nevytváří, ani nemaže, pouze může do projektu přidat či odebrat uživatele s rolí User. Další uživatel je Product Owner, ten vybírá Stories a poté definuje strukturu projektu. Definuje uživatele do týmu a jako jediný může vytvářet, editovat a mazat projekty. Také může spravovat sprinty a úkoly. Reporty lze u uživatele Product Owner pouze zobrazit. Také nesmí pracovat na žádném úkolu a nesmí ho označovat jako hotový/rozpracovaný. Posledním nutným uživatelem je Admin, který je správcem celé aplikace. Účty všech uživatelů jsou spravovány právě Adminem. Každý uživatel si může změnit osobní údaje, kromě práv, které může měnit právě Admin. Práva všech uživatelů má i Admin a to především z důvodu aktualizací, úprav a správy celé aplikace. Pro jednotlivé případy užití byly sestaveny pochopitelně i příslušné scénáře. Pro vyvíjenou aplikaci byly vytvořeny i další modely jako konceptuální, logický či fyzický model. 24



3.2 Databáze Databáze vytvořená na platformě MySQL byla nazvána „scrumboard“, jméno i heslo databáze byly nadefinovány a připojení bylo nastaveno následovně: function db_connect() { //Informace - přihlášení k databázi define("SQL_HOST", "127.0.0.1"); define("SQL_DBNAME", "scrumboard"); define("SQL_USERNAME", "scrum"); define("SQL_PASSWORD", "board"); //Přihlášení k databázi $link = mysql_connect(SQL_HOST, SQL_USERNAME, SQL_PASSWORD) or die("Nelze se připojit k databázi." . mysql_error()); mysql_select_db(SQL_DBNAME) or die("Nelze vybrat databázi.". mysql_error()); mysql_query("SET NAMES UTF8"); } Dále byly vytvořeny další databázové tabulky, jejichž počet (sedm tabulek) vychází z databázového modelu. Všechny tabulky mají primární klíč identifikátor id. Jedná se o tabulky permission, project, report, sprint, task, user, user_project.

3.3 Grafické rozhraní a funkce Vzhled výsledného grafického rozhraní je velice důležitý při vývoji každého IS nebo internetové aplikace. Vlastní grafické rozhraní bylo navrženo minimalisticky a jednoduše se v něm uživatel rychle orientoval a intuitivně ovládal jednotlivé funkce aplikace. K definici barev byl využit designer barevných schémat (Stanicek, P., 2010). Barvy byly zvoleny v odstínech modré a jako kontrastní barva byla zvolena oranžová. Oranžově jsou rozlišeny nadpisy, které udávají, kde se uživatel v danou chvíli nachází. Domovská stránka je zobrazena na obrázku 2, vidíme zde dva vytvořené „ukázkové“ projekty ScrumBoard a Testovací projekt 01.

Obr. 2 : Grafické rozhraní aplikace (Zdroj: Scrumboard, 2012) Vzhled celé aplikace byl vytvořen pomocí kaskádových stylů. Za pomocí tohoto nástroje je u vzhledu tabulek, nadpisů, odkazů a bloku textů zachována jednotnost a přehlednost. Obrazovka je rozlišena na hlavičku, tělo a patičku. V záhlaví je uvedeno jméno uživatele, který je přihlášen a poté dle práv uživatele nástroje pro zobrazování, SYSTÉMOVÁ INTEGRACE 3/2013

25


upravování a celkové využívání tabule. V těle se nachází popis samotné práce – projekty, sprinty, úkoly, reporty, ale i změna přihlašovacích údajů.

3.4 Uživatelé a bezpečnost Uživatelé jsou z hlediska práv rozděleni do čtyř skupin uvedených v kapitole 3.1 „Uživatelé“. Jejich oprávnění (user stories) jsou přesně definována a odpovídají dikci diagramů a modelů vytvořených ve fázi návrhu SW. Na obrázku 3 je zobrazen seznam uživatelů vytvořených ve vytvořené aplikaci pro modelový projekt nazvaný „ScrumBoard“. Vidíme zde všechny čtyři skupiny uživatelů (dle oprávnění) a také možnosti editací, mazání a přidávání nových uživatelů. Důležitými kritérii pro bezpečnost celé aplikace jsou funkce, které zabrání dostat se do aplikace nepovolaným uživatelům. Proto je nezbytné disponovat přihlašovacím jménem a heslem, aby bylo možné pracovat v aplikaci. Tyto jména a hesla zpočátku generuje administrátor, každý uživatel si po přidělení může přihlašovací jméno i heslo změnit. Další neméně důležitou vlastností celé aplikace je, že uživatel nemůže v adrese přepsat název stránky a dostat se na ni, pokud nemá práva k těmto funkcím. Například uživatele a jejich práva může definovat pouze Admin. Když uživatel s právy User v adrese přepíše page=administration a chce se dostat na správcovství uživatelů, rovnou je přesměrován na page=no_permission a je mu zobrazeno hlášení, že pro zobrazení požadované stránky nemá oprávnění.

Obr. 3: Uživatelé aplikace (Zdroj: Scrumboard, 2012)

4. Diskuse a závěr Vytvořený aplikační SW je nejen příkladem použití metody SCRUM (byl podle ní tvořen), ale svým obsahem a funkcemi umožňuje řídit malé a střední projekty pomocí této metody s využitím „ elektronické tabule“ SCRUMBoard. Nabízí tak nový agilní nástroj pro tvorbu IS a SW. Pro jeho funkčnost není nutné žádné zvláštní SW či HW zařízení, v podstatě postačí standardně vybavené kancelářské PC. Autoři jsou si 26



vědomi, že v současné době existují i jiné SW nástroje využívající SCRUM, které jsou robustnější a mají za sebou delší vývoj (například iceScrum, ScrumDesk). Výhodou našeho řešení je podle názoru autorů právě jeho jednoduchost a nenáročnost. Nyní je tento SW využíván při výuce projektového managementu na Univerzitě Pardubice Fakultě ekonomicko-správní jak pro denní tak dálkové studenty. Jsou jim tak demonstrovány principy agilních metod a mohou je porovnat s jinými přístupy. V komerční sféře produkt dosud nasazen nebyl, je však volně přístupný (Scrumboard aplikace, 2012) a věříme, že v budoucnosti vznikne zájem o jeho využití či rozšíření. Otázkou zůstává, jak se bude tato oblast vyvíjet. Vedle metodiky SCRUM existuje dlouhá řada další agilních nástrojů i tradičních přístupů a asi nelze předpokládat, že by jeden z nich vytlačil ostatní. Je to dáno jednak tím, že každý má nějaké specifické výhody a hodí se tak pro různé typy projektů (analogicky je to i s nevýhodami), dále mají vliv nové technologie a jejich rychlý rozvoj – přinášejí další možnosti a techniky využitelné při vývoji. V neposlední řadě hraje roli „modernost“ jednotlivých metod – obvykle je po jistou dobu některá z nich oblíbená a roste její podíl na trhu, aby byla následně vystřídána jinou. Jako rozumné se jeví využívat vícero metod a v případě potřeby je kombinovat. V současné době hraje čas při tvorbě IS a SW velmi důležitou roli. V mnoha oblastech je zásadní rychlé a kvalitní řešení doplněné značnou flexibilitou. Z tohoto hlediska je metoda SCRUM i v porovnání s tradičními metodami velmi vhodná, především pak pro menší vývojové týmy.

Poděkování Tento článek byl zpracován s podporou projektu: SGFES02/2011, Vědecko-výzkumné aktivity v oblasti "Systémové inženýrství a informatika". Software SCRUMBoard (všechny soubory) je volně stažitelný z následujícího odkazu: http://projektyusii.upce.cz/index.php/vedecke-tymy/computational-intelligence/vytvoreny-software.

Použité zdroje Agile Alliance, 2010. [online] [cit. 2012-12-14]. Dostupné na: Bartůňková, K., 2011. Využití agilních metod, SCRUM, v projektovém řízení. Diplomová práce. Univerzita Pardubice. 2011 Bloch, M., Blumberg, S. And Laartz, J., 2012. Delivering large-scale IT projects on time, on budget, and on value. [online] [cit. 2013-8-14]. Dostupné na: http://www.mckinsey.com/insights/business_ technology/delivering_largescale_it_projects_ on_time_on_budget_and_on_value Bruckner, T.; Voříšek, J.; Buchalcevová, A. a kolektiv, 2012. Tvorba informačních systémů. Praha: Grada Publishing. ISBN: 97880247415362012 Buchalcevová, A., 2009a. Metodiky budování informačních systémů. Vydání první. Praha: Oeconomica. ISBN 978-80-245-1540-3 Buchalcevová, A., 2007. Stav používání agilních metodik v ČR. Systémová integrace 13(4), s. 23–31. ISSN 1210-9479 Buchalcevová, A., 2009b. Research of the Use of Agile Methodologies in the Czech Republic. In: Barry, C., Lang, M., Wojtkowski, W., Wojtkowski, G., Wrycza, S., & SYSTÉMOVÁ INTEGRACE 3/2013

27


Zupancic, J. (eds) The Inter-Networked World: ISD Theory, Practice, and Education. New York: Springer-Verlag. ISBN 978-0387304038 Cockburn, A., 2005. Use Cases : Jak efektivně modelovat aplikace. Praha: Computer Press. ISBN 80-251-0721-3 Gála, L., Pour, J., Toman, P., 2006. Podniková informatika. Praha: Grada, 2006. ISBN 80-247-1278-4 Goodpasture, J.C., 2010. Project Management the Agile Way: Making It Work in the Enterprise. Laureldale: J. Ross Publishing. ISBN: 1604270276 Jirava, P., 2004. System development life cycle. Sci. Pap. Univ. Pardubice Ser. D, 9(1), s. 58-62. ISSN: 1211-555X Kadlec, V., 2004. Agilní programování : Metodiky efektivního vývoje softwaru. Brno: Computer Press. ISBN 80-251-0342-0 Kadlec, V., 2003. ŽIVĚ: Extrémní programování pod drobnohledem [online] [cit. 201209-5]. Dostupné na: Knesl, J., 2009. Zdroják.cz [online] [cit. 2013-08-02]. Dostupné na: Kučera, F., 2009. Zdroják.cz [online]. [cit. 2012-09-07]. Dostupné na: . Project Management Research Institute. 2010. [online] [cit. 2011-09-28]. Dostupné na: Rubin, K. S., 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston: Pearson Education - Addison-Wesley Professional. ISBN: 9780137043293 Říhová, Z., 2009. Systémová integrace jako manažerský problém při řízení projektu. Systémová integrace, 16(3), s. 26–31. ISSN 1210-9479 Schwaber, K., 2004. Agile Project Management With Scrum. United States: Microsoft Press. ISBN 978073561993 Scrumboard aplikace, 2012. Bartůňková, K., Jirava, P. [cit. 2013-08-19]. Dostupné z WWW: Stanicek, P., 2010. Color Scheme Designer 3 [online]. [cit. 2013-03-26]. Dostupné z WWW: Sutherland, J., 2003. SCRUM: Keep Team Size Under 7! [online]. [cit. 2013-09-26]. Dostupné z WWW:

JEL Classification: M15, C88

28


SCRUM - agilní metoda pro vývoj softwaru

Recommend Documents