Agilní metody projektování. Principy, role, organizace, nástroje: Porovnání verzí

m (Opravení gramatické chyby. Původně zapsáno vivinout.)
 
(Není zobrazeno 15 mezilehlých verzí od 3 dalších uživatelů.)
Řádek 2: Řádek 2:
 
[[Kategorie:Státnicové otázky UISK]]
 
[[Kategorie:Státnicové otázky UISK]]
  
'''Agilní metody''' (''agile methods'') - interaktivní způsob [https://wikisofia.cz/wiki/Metodiky_projektov%C3%A9ho_managementu,_jejich_obsah_a_smysl řízení projektů], základem kterého je průběžné dodání produktu (služby) zákaznikovi na základě jeho aktivní spolupráci s týmem, co pomáhá zajistit rychlé reagování na jakékoliv změny (buď ze strany zákazníka nebo z okolního prostředí)<ref name=":0">ŠOCHOVÁ, Zuzana a Eduard KUNCE, 2014. Agilní metody řízení projektu. Brno, Computer Press, 2014. ISBN 978-80-251-4194-6.</ref><ref name=":1">MYSLÍN, Josef, 2016. Scrum: průvodce agilním vývojem softwaru. 1. vydání. Brno: Computer Press, 2016. ISBN 978-80-251-4650-7.</ref>. Je společným názvem pro skupinu metodik, do které patří např. Scrum, Kanban nebo extrémní programování (XP). Scrum je nejpopulárnější agilní metodikou a občas je použivány jako synonimické označení pro celou skupinu těchto metod<ref name=":1" />.
+
'''Agilní metody''' (''agile methods'') - interaktivní způsob [https://wikisofia.cz/wiki/Metodiky_projektov%C3%A9ho_managementu,_jejich_obsah_a_smysl řízení projektů], základem kterého je průběžné dodání produktu (služby) zákazníkovi na základě jeho aktivní spolupráce s týmem, co pomáhá zajistit rychlé reagování na jakékoliv změny (buď ze strany zákazníka nebo z okolního prostředí)<ref name=":0">ŠOCHOVÁ, Zuzana a Eduard KUNCE, 2014. Agilní metody řízení projektu. Brno, Computer Press, 2014. ISBN 978-80-251-4194-6.</ref><ref name=":1">MYSLÍN, Josef, 2016. Scrum: průvodce agilním vývojem softwaru. 1. vydání. Brno: Computer Press, 2016. ISBN 978-80-251-4650-7.</ref>. Je společným názvem pro skupinu metodik, do které patří např. Scrum, Kanban nebo extrémní programování (XP). Scrum je nejpopulárnější agilní metodika a občas je používán jako synonymické označení pro celou skupinu těchto metod<ref name=":1" />.
  
Agilní metody ovlivněny zavedeným ve společnost Toyota tzv. Toyota Production System.
+
Agilní metody byly ovlivněny zavedením ve společností Toyota tzv. Toyota Production System.
  
Důležitým milníkem stala půblikace článku „The New Product Development Game“ (1986) za autorstvím Takeuchi a Nonaka.<ref>RIGBY, Darell K., Jeff SUTHERLAND a Hirotaka TAKEUCHI, 2016. The Secret History of Agile Innovation. In: Harvard Business Review [online]. 2016 [cit. 2018-04-14]. ISSN 0017-8012. Dostupné z: https://hbr.org/2016/04/the-secret-history-of-agile-innovation.</ref>
+
Důležitým milníkem se stala publikace článku „The New Product Development Game“ (1986) s autorstvím Takeuchi a Nonaka.
  
== Principy agilních metod ==
+
==Principy agilních metod==
  
 
Byly formulovány v roce 2001 skupinou vývojářů, kteří napsali Manifest agilního programování (''Manifesto for Agile Software Development''). Definují následující principy:
 
Byly formulovány v roce 2001 skupinou vývojářů, kteří napsali Manifest agilního programování (''Manifesto for Agile Software Development''). Definují následující principy:
Řádek 21: Řádek 21:
 
</ref>
 
</ref>
  
Předpokládá se, že osobní komunikace a schopnosti každého jedince mají větší význam a efektivitu pro práci, než předem stanovené procesy a nástroje. Dokumentace by měla být omezená jen na tu, která je skutečně potřebná (např. pro předávání znalostí a kontrolu); nemá být zbytečná a potřebuje včasnou aktualizaci. Zákazník je vnímán jako součást týmu, avšak nemusí rozumět technické specifikaci, a pro lepší výsledek a spokojenost uživatele (což je nejvyšší prioritou) je zapotřebí s nim komunikovat. Změny, které mohou být způsobeny proměnou legislativy nebo novou situaci na trhu, ovlivní předem napsaný plán, ale ve výsledku to zvýší kvalitu finálního produktu.<ref name=":0" /><ref name=":1" />
+
Předpokládá se, že osobní [[komunikace]] a schopnosti každého jedince mají větší význam a efektivitu pro práci než předem stanovené procesy a nástroje. Dokumentace by měla být omezená jen na tu, která je skutečně potřebná (např. pro [[Znalostní management a znalosti v organizacích|předávání znalostí]] a kontrolu); nemá být zbytečná a potřebuje včasnou aktualizaci. Zákazník je vnímán jako součást týmu, avšak nemusí rozumět technické specifikaci, a pro lepší výsledek a spokojenost uživatele (což je nejvyšší prioritou) je zapotřebí s ním komunikovat. Změny, které mohou být způsobeny proměnou legislativy nebo novou situací na trhu, ovlivní předem napsaný plán, ale ve výsledku to zvýší kvalitu finálního produktu.<ref name=":0" /><ref name=":1" />
  
Kromě výš popsaných čtyř hodnot autoři definovali 12 principů agilního vývoje softwaru, kterými je doporučováno řídit se. Pokud projekt je vyvíjen se sledováním těchto principů, může být považován za agilní.
+
Kromě výše popsaných čtyř hodnot autoři definovali 12 principů agilního vývoje [[Software|softwaru]], kterými je doporučováno řídit se. Pokud je projekt vyvíjen se sledováním těchto principů, může být považován za agilní.
  
== Základní struktura ==
+
==Základní struktura==
  
Agilní metody mají svůj filozofický základ (výč popsané principy), týmové role, artefakty (nástroje) a údalosti (organizace času)<ref>SCHWABER, Ken a Jeff SUTHERLAND, 2017, November. The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game [online]. 2017, [cit. 2018-04-14]. Dostupné z: http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. </ref>.
+
Agilní metody mají svůj filozofický základ (výš popsané principy), týmové role, artefakty (nástroje) a události (organizace času)<ref>SCHWABER, Ken a Jeff SUTHERLAND, 2017, November. The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game [online]. 2017, [cit. 2018-04-14]. Dostupné z: http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. </ref>.
  
=== Role ===
+
===Role===
Rozlišují se nasledujicí role: Product Owner, Scrum Master a samoorganizovaný tým.
+
Rozlišují se následující role: Product Owner, Scrum Master a samoorganizovaný tým.
  
'''Product Owner''' je člověk, který kontroluje vývoj práce, definuje vizi produktu, ale zároveň není ředitelem týmu. Jedná se o člověka, který zastupuje zákazníka, přitom to může být jak přímo zaměstnanec klientské firmy, tak i najatý externista, a tím samým stará se o to, aby požadavky a představy zákazníka ohledně produktu byly splněné. Problémem je časté pracovní přetižení.<ref name=":0" /><ref name=":1" />
+
'''Product Owner''' je člověk, který kontroluje vývoj práce, definuje vizi produktu, ale zároveň není ředitelem týmu. Jedná se o člověka, který zastupuje zákazníka, přitom to může být jak přímo zaměstnanec klientské firmy, tak i najatý externista, který se stará o to, aby požadavky a představy zákazníka ohledně produktu byly splněné. Problémem je časté pracovní přetížení.<ref name=":0" /><ref name=":1" />
  
Vyplňuje následující funkce<ref name=":0" /><ref name=":1" />:
+
Splňuje následující funkce<ref name=":0" /><ref name=":1" />:
  
* nese primární odpovědnost za projekt a práci vývojového týmu;
+
*nese primární odpovědnost za projekt a práci vývojového týmu;
* stanoví priority u funkcionalit;
+
*stanoví priority u funkcionalit;
* spravuje Product backlog (položky);
+
*spravuje Product backlog (položky);
* zabezpečuje jeho dostupnost a porozumění obsahu týmem;
+
*zabezpečuje jeho dostupnost a porozumění obsahu týmem;
* zajišťuje komunikaci se zákazníkem.  
+
*zajišťuje komunikaci se zákazníkem.
  
'''Scrum Master '''je pracovník, ovládající metodiku Scrum a tím pádem zodpovědný za porozumění a aplikaci pravidel Scrumu. Má za úkol pomáhat členům týmu s komunikací (nejen mezi sebou, ale i s druhými části podniku), sledovat principům agilu a pomoci týmu dospět k závěrům. Organizuje a moderuje jednotlivé meetingy, pomáhá s dokumentaci. Není součastí týmu. Má mít odolsnot vůči stresu a vysoké komunikační shopnosti.<ref name=":0" /><ref name=":1" />   
+
'''Scrum Master '''je pracovník ovládající metodiku Scrum, a tak je zodpovědný za porozumění a aplikaci pravidel Scrumu. Má za úkol pomáhat členům týmu s komunikací (nejen mezi sebou, ale i s druhými části podniku), sledovat principy agilu a pomoci týmu dospět k závěrům. Organizuje a moderuje jednotlivé meetingy, pomáhá s dokumentací. Není součastí týmu. Má mít odolnost vůči stresu a vysoké komunikační schopnosti.<ref name=":0" /><ref name=":1" />   
  
 
Funkce Product Ownera a Scrum Mastera nesmí plnit stejný člověk.   
 
Funkce Product Ownera a Scrum Mastera nesmí plnit stejný člověk.   
  
'''Tým '''se sestavá z jedinců, kteří mohou být navzajem zastupitelné a cílem kterých je dodat část funkčního softwaru na konci sprintu. Je samoorganizovaný, má vysokou motivaci. Členy týmu jsou navzajem zastupitelní. Podtýmy neexistují.<ref name=":0" />
+
'''Tým '''se sestává z jedinců, kteří mohou být navzájem zastupitelní a jejichž cílem je dodat část funkčního softwaru na konci sprintu. Je samoorganizovaný, má vysokou [[Motivace k pracovním činnosti – terminologické vymezení, přehled teoretických přístupů k pracovní motivaci; podstata motivačních programů v organizacích.|motivaci]]. Podtýmy neexistují.
  
=== Artefakty (nástroje) a údalosti (organizace času) ===
+
===Artefakty (nástroje) a údalosti (organizace času)===
[[File:Agile Project Management by Planbox.png|thumb|321x321px]]
+
Před zahájením práce nad projektem se dělá '''product backlog ''' - kompletní seznam úkolů, které mají být ke konci projektu udělány. Každý úkol získává prioritu, dle které jsou potom úkoly plněny (čím vyšší je priorita, tím dřív úkol bude splněn). Předem jsou stanoveny i požadavky na úkoly, které pokud jsou splněny, tak ukazují na to, že úkol je hotový - '''definition of done (DOD) '''.<ref name=":0" />
  
== Agilní metody vs. tradiční přístup (waterfall) ==
+
Pro lepší spolupráci týmu a zákazníka jsou vytvořeny '''user stories ''' - popis funkcionality, scénář, který je představen ve formě krátkých jednoznačných vět, kde uživatel v jakési roli (např. administrátor) uvádí, co chce získat a za pomoci jaké činnosti.<ref name=":0" />
  
'''Waterfall '''(vodopádový model) byl vivinut v 70. letech minulého století a je považován za tzv. tradiční model řízení projektů.
+
[[File:Agile Project Management by Planbox.png|thumb|321x321px|Model agilního vývoje projektu]]
 +
Základem pro týmovou práci je '''sprint ''' (iterace) - opakující se a omezená časová jednotka. Má fixní délku, obyčejně jde o dva až tři týdny. Tým pracuje v průběhu sprintu se '''sprint backlogem ''', což je před začátkem sprintu stanovený seznam úkolů, které by měly být ke konci sprintu splněny (úkoly pro sprint backlog jsou přebíraný z product backlogu). Ten seznam je sestaven na '''plánovacím meetingu ''', kde kromě jiného jsou stanovené cíle sprintu a odhaduje se náročnost práce. Pokud je úkolů hodně, tomuto meetingu předchází '''grooming '''.<ref name=":1" />
 +
 
 +
V průběhu práce se tým setkává každý den - ve stejnou dobu, na stejném místě, ideálně ve stoje. Každý říká o tom, co udělal, co plánuje vyplnit dnes a co se nepovedlo. Tento meeting se jmenuje '''daily stand-up '''. Měl by trvat max. 15 minut.
 +
 
 +
Po ukončení sprintu následuje '''sprint review ''', kde tým ukazuje zákaznikovi svou práci. Na '''retrospective meetingu ''', který poté následuje, tým probírá, co se podařilo a co je naopak nutné změnit.<ref name=":1" />
 +
 
 +
Pro měření úspěšnosti a náročnosti práce na projektu jsou používaný takové techniky jako burndown chart, velocity nebo planning poker.
 +
 
 +
==Agilní metody vs. tradiční přístup (waterfall)==
 +
 
 +
'''Waterfall '''(vodopádový model) byl vyvinut v 70. letech minulého století a je považován za tzv. tradiční model řízení projektů.
 +
 
 +
[[File:Vodopadovy model.png|thumb|332x332px|Waterfall - model]]
  
[[File:Vodopadovy model.png|thumb|375x375px]]
 
 
K základním charakteristikám waterfallu patří<ref name=":1" />:
 
K základním charakteristikám waterfallu patří<ref name=":1" />:
  
* Neopakovatelnost (každá probíhá jen jednou);
+
*Neopakovatelnost (každá fáze probíhá jen jednou);
* Do nové fáze jdeme jen po ukončení předchozí;
+
*Do nové fáze jdeme jen po ukončení předchozí;
* Každý jednotlivec pracuje pouze dle své specializace;
+
*Každý jednotlivec pracuje pouze dle své specializace;
* Oprava chyb a testování probíhají na konci projektu;
+
*Oprava chyb a testování probíhají na konci projektu;
* Rozsahlá dokumentace;
+
*Rozsáhlá dokumentace;
* Zákazník je zapojen do procesu vývoje minimálně - uvidí produkt až po ukončení práce nad nim a nemůže proces ovlivnit;
+
*Zákazník je zapojen do procesu vývoje minimálně - uvidí produkt až po ukončení práce na něm a nemůže proces ovlivnit.
  
Použivá se tam, kde smlouva týpu "fixed time, fixed price", procesy jsou striktně nastavené a proces vývoje je předvidatelný<ref name=":1" />.
+
Používá se tam, kde je smlouva typu "fixed time, fixed price", procesy jsou striktně nastavené a proces vývoje je předvídatelný<ref name=":1" />.
  
Agilní metody, které byly vyvinuty jako reakce na potřeby vývojářů, jsou meně fixní verzi waterfallu a jsou rozšiřené o takové prvky, jako např. komunikace se zákazníkem, reakce na změny a průbežné dodávání části projektu po ukončení sprintu<ref>STOICA, Marian, Bogdan GHILIC-MICU, Marinela MIRCEA a Cristian USCATU, 2016. Analyzing Agile Development – from Waterfall Style to Scrumban. In: Informatică Economică [online]. 2016, 20(4), 5-14 [cit. 2018-04-14]. ISSN 1842-8088. DOI: https://doi.org/10.12948/issn14531305/20.4.2016.01.</ref>.
+
Agilní metody, které byly vyvinuty jako reakce na potřeby vývojářů, jsou méně fixní verzí waterfallu a jsou rozšířené o takové prvky jako např. komunikace se zákazníkem, reakce na změny a průběžné dodávání částí projektu po ukončení sprintu<ref>STOICA, Marian, Bogdan GHILIC-MICU, Marinela MIRCEA a Cristian USCATU, 2016. Analyzing Agile Development – from Waterfall Style to Scrumban. In: Informatică Economică [online]. 2016, 20(4), 5-14 [cit. 2018-04-14]. ISSN 1842-8088. DOI: https://doi.org/10.12948/issn14531305/20.4.2016.01.</ref>.
  
 
==Výhody a nevýhody agilních metod==
 
==Výhody a nevýhody agilních metod==
  
'''Výhody:'''
+
'''Výhody:'''<ref name=":0" /><ref name=":1" /><ref>RIGBY, Darell K., Jeff SUTHERLAND a Hirotaka TAKEUCHI, 2016. Embracing Agile. In: Harvard Business Review [online]. 2016 [cit. 2018-04-14]. ISSN 0017-8012. Dostupné z: https://hbr.org/2016/05/embracing-agile.</ref>.
  
spokojenost zákazníka (uživatele);
+
*spokojenost zákazníka (uživatele);
rychlé dodání funkčního produktu;
+
*rychlé dodání funkčního produktu;
komunikace a feedback;
+
*komunikace a feedback;
efektivita;
+
*efektivita;
díky rychlým změnám se zvyšuje konkurenceschopnost
+
*zvýšená konkurenceschopnost díky rychlým změnám.
  
'''Nevýhody:'''
+
'''Nevýhody:'''<ref name=":1" />.
  
nehodí se pro velké projekty;
+
*nehodí se pro velké projekty;
je zapotřebí aktivní účast všech stakeholderů;
+
*je zapotřebí aktivní účast všech stakeholderů;
potřeba specifické firemní kultury a podpory top-managementu;
+
*potřeba specifické firemní kultury a podpory top-managementu;
lidé jako kamen úrazu;
+
*lidé jako kamen úrazu;
změny způsobují zvýšení náročnosti.
+
*změny způsobují zvýšení náročnosti.
  
 +
==Odkazy==
  
== Zdroje ==
+
===Reference===
 +
<references />
  
=== Reference ===
+
===Externí odkazy===
<references />
+
 
 +
*[https://www.agilealliance.org/ Agile Alliance]
 +
*[https://agilniasociace.cz/ Agilní asociace: Sdružení příznivců Agilních metod]
 +
*[https://explore.versionone.com/state-of-agile/ VersionOne - každoroční mezinárodní výzkum o agilních metodách]
 +
 
 +
===Související články===
 +
 
 +
*[[Metodiky projektového managementu, jejich obsah a smysl]]
 +
*[[Řízení lidských zdrojů na projektech, OBS]]
 +
*[[Znalostní management a znalosti v organizacích]]
  
=== Klíčová slova ===
+
===Klíčová slova===
 
projektový management, metodiky projektového managementu, řízení projektu, agilní metody
 
projektový management, metodiky projektového managementu, řízení projektu, agilní metody

Aktuální verze z 11. 1. 2021, 17:20


Agilní metody (agile methods) - interaktivní způsob řízení projektů, základem kterého je průběžné dodání produktu (služby) zákazníkovi na základě jeho aktivní spolupráce s týmem, co pomáhá zajistit rychlé reagování na jakékoliv změny (buď ze strany zákazníka nebo z okolního prostředí)[1][2]. Je společným názvem pro skupinu metodik, do které patří např. Scrum, Kanban nebo extrémní programování (XP). Scrum je nejpopulárnější agilní metodika a občas je používán jako synonymické označení pro celou skupinu těchto metod[2].

Agilní metody byly ovlivněny zavedením ve společností Toyota tzv. Toyota Production System.

Důležitým milníkem se stala publikace článku „The New Product Development Game“ (1986) s autorstvím Takeuchi a Nonaka.

Principy agilních metod

Byly formulovány v roce 2001 skupinou vývojářů, kteří napsali Manifest agilního programování (Manifesto for Agile Software Development). Definují následující principy:

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[3]

Předpokládá se, že osobní komunikace a schopnosti každého jedince mají větší význam a efektivitu pro práci než předem stanovené procesy a nástroje. Dokumentace by měla být omezená jen na tu, která je skutečně potřebná (např. pro předávání znalostí a kontrolu); nemá být zbytečná a potřebuje včasnou aktualizaci. Zákazník je vnímán jako součást týmu, avšak nemusí rozumět technické specifikaci, a pro lepší výsledek a spokojenost uživatele (což je nejvyšší prioritou) je zapotřebí s ním komunikovat. Změny, které mohou být způsobeny proměnou legislativy nebo novou situací na trhu, ovlivní předem napsaný plán, ale ve výsledku to zvýší kvalitu finálního produktu.[1][2]

Kromě výše popsaných čtyř hodnot autoři definovali 12 principů agilního vývoje softwaru, kterými je doporučováno řídit se. Pokud je projekt vyvíjen se sledováním těchto principů, může být považován za agilní.

Základní struktura

Agilní metody mají svůj filozofický základ (výš popsané principy), týmové role, artefakty (nástroje) a události (organizace času)[4].

Role

Rozlišují se následující role: Product Owner, Scrum Master a samoorganizovaný tým.

Product Owner je člověk, který kontroluje vývoj práce, definuje vizi produktu, ale zároveň není ředitelem týmu. Jedná se o člověka, který zastupuje zákazníka, přitom to může být jak přímo zaměstnanec klientské firmy, tak i najatý externista, který se stará o to, aby požadavky a představy zákazníka ohledně produktu byly splněné. Problémem je časté pracovní přetížení.[1][2]

Splňuje následující funkce[1][2]:

  • nese primární odpovědnost za projekt a práci vývojového týmu;
  • stanoví priority u funkcionalit;
  • spravuje Product backlog (položky);
  • zabezpečuje jeho dostupnost a porozumění obsahu týmem;
  • zajišťuje komunikaci se zákazníkem.

Scrum Master je pracovník ovládající metodiku Scrum, a tak je zodpovědný za porozumění a aplikaci pravidel Scrumu. Má za úkol pomáhat členům týmu s komunikací (nejen mezi sebou, ale i s druhými části podniku), sledovat principy agilu a pomoci týmu dospět k závěrům. Organizuje a moderuje jednotlivé meetingy, pomáhá s dokumentací. Není součastí týmu. Má mít odolnost vůči stresu a vysoké komunikační schopnosti.[1][2]

Funkce Product Ownera a Scrum Mastera nesmí plnit stejný člověk.

Tým se sestává z jedinců, kteří mohou být navzájem zastupitelní a jejichž cílem je dodat část funkčního softwaru na konci sprintu. Je samoorganizovaný, má vysokou motivaci. Podtýmy neexistují.

Artefakty (nástroje) a údalosti (organizace času)

Před zahájením práce nad projektem se dělá product backlog - kompletní seznam úkolů, které mají být ke konci projektu udělány. Každý úkol získává prioritu, dle které jsou potom úkoly plněny (čím vyšší je priorita, tím dřív úkol bude splněn). Předem jsou stanoveny i požadavky na úkoly, které pokud jsou splněny, tak ukazují na to, že úkol je hotový - definition of done (DOD) .[1]

Pro lepší spolupráci týmu a zákazníka jsou vytvořeny user stories - popis funkcionality, scénář, který je představen ve formě krátkých jednoznačných vět, kde uživatel v jakési roli (např. administrátor) uvádí, co chce získat a za pomoci jaké činnosti.[1]

Model agilního vývoje projektu

Základem pro týmovou práci je sprint (iterace) - opakující se a omezená časová jednotka. Má fixní délku, obyčejně jde o dva až tři týdny. Tým pracuje v průběhu sprintu se sprint backlogem , což je před začátkem sprintu stanovený seznam úkolů, které by měly být ke konci sprintu splněny (úkoly pro sprint backlog jsou přebíraný z product backlogu). Ten seznam je sestaven na plánovacím meetingu , kde kromě jiného jsou stanovené cíle sprintu a odhaduje se náročnost práce. Pokud je úkolů hodně, tomuto meetingu předchází grooming .[2]

V průběhu práce se tým setkává každý den - ve stejnou dobu, na stejném místě, ideálně ve stoje. Každý říká o tom, co udělal, co plánuje vyplnit dnes a co se nepovedlo. Tento meeting se jmenuje daily stand-up . Měl by trvat max. 15 minut.

Po ukončení sprintu následuje sprint review , kde tým ukazuje zákaznikovi svou práci. Na retrospective meetingu , který poté následuje, tým probírá, co se podařilo a co je naopak nutné změnit.[2]

Pro měření úspěšnosti a náročnosti práce na projektu jsou používaný takové techniky jako burndown chart, velocity nebo planning poker.

Agilní metody vs. tradiční přístup (waterfall)

Waterfall (vodopádový model) byl vyvinut v 70. letech minulého století a je považován za tzv. tradiční model řízení projektů.

Waterfall - model

K základním charakteristikám waterfallu patří[2]:

  • Neopakovatelnost (každá fáze probíhá jen jednou);
  • Do nové fáze jdeme jen po ukončení předchozí;
  • Každý jednotlivec pracuje pouze dle své specializace;
  • Oprava chyb a testování probíhají na konci projektu;
  • Rozsáhlá dokumentace;
  • Zákazník je zapojen do procesu vývoje minimálně - uvidí produkt až po ukončení práce na něm a nemůže proces ovlivnit.

Používá se tam, kde je smlouva typu "fixed time, fixed price", procesy jsou striktně nastavené a proces vývoje je předvídatelný[2].

Agilní metody, které byly vyvinuty jako reakce na potřeby vývojářů, jsou méně fixní verzí waterfallu a jsou rozšířené o takové prvky jako např. komunikace se zákazníkem, reakce na změny a průběžné dodávání částí projektu po ukončení sprintu[5].

Výhody a nevýhody agilních metod

Výhody:[1][2][6].

  • spokojenost zákazníka (uživatele);
  • rychlé dodání funkčního produktu;
  • komunikace a feedback;
  • efektivita;
  • zvýšená konkurenceschopnost díky rychlým změnám.

Nevýhody:[2].

  • nehodí se pro velké projekty;
  • je zapotřebí aktivní účast všech stakeholderů;
  • potřeba specifické firemní kultury a podpory top-managementu;
  • lidé jako kamen úrazu;
  • změny způsobují zvýšení náročnosti.

Odkazy

Reference

  1. 1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 ŠOCHOVÁ, Zuzana a Eduard KUNCE, 2014. Agilní metody řízení projektu. Brno, Computer Press, 2014. ISBN 978-80-251-4194-6.
  2. 2,00 2,01 2,02 2,03 2,04 2,05 2,06 2,07 2,08 2,09 2,10 2,11 MYSLÍN, Josef, 2016. Scrum: průvodce agilním vývojem softwaru. 1. vydání. Brno: Computer Press, 2016. ISBN 978-80-251-4650-7.
  3. BECK, Kent et al., 2001. Manifesto for Agile Software Development [online]. 2001 [cit. 2018-04-14]. Dostupné z: http://agilemanifesto.org/iso/cs/manifesto.html.
  4. SCHWABER, Ken a Jeff SUTHERLAND, 2017, November. The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game [online]. 2017, [cit. 2018-04-14]. Dostupné z: http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf.
  5. STOICA, Marian, Bogdan GHILIC-MICU, Marinela MIRCEA a Cristian USCATU, 2016. Analyzing Agile Development – from Waterfall Style to Scrumban. In: Informatică Economică [online]. 2016, 20(4), 5-14 [cit. 2018-04-14]. ISSN 1842-8088. DOI: https://doi.org/10.12948/issn14531305/20.4.2016.01.
  6. RIGBY, Darell K., Jeff SUTHERLAND a Hirotaka TAKEUCHI, 2016. Embracing Agile. In: Harvard Business Review [online]. 2016 [cit. 2018-04-14]. ISSN 0017-8012. Dostupné z: https://hbr.org/2016/05/embracing-agile.

Externí odkazy

Související články

Klíčová slova

projektový management, metodiky projektového managementu, řízení projektu, agilní metody