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

Řá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á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í 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 stala publikace č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>
  
 
== Principy agilních metod ==
 
== Principy agilních metod ==
Řádek 27: Řádek 27:
 
== 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, 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" />
Řádek 42: Řádek 42:
 
* 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 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 dokumentací. Není součastí týmu. Má mít odolsnost 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 sestavá z jedinců, kteří mohou být navzájem zastupitelné a cílem kterých je dodat část funkčního softwaru na konci sprintu. Je samoorganizovaný, má vysokou motivaci. Podtýmy neexistují.<ref name=":0" />  
  
 
=== Artefakty (nástroje) a údalosti (organizace času) ===
 
=== 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 vyplňová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) '''.
 +
 +
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.
 +
 +
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-tři týdnů. Tým pracuje v průběhu sprintu se '''sprint backlogem ''', což je stanovený před začátkem sprintu 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 úkolů je hodně, tomuto meetingu předchází '''grooming '''.
 +
 
[[File:Agile Project Management by Planbox.png|thumb|321x321px]]
 
[[File:Agile Project Management by Planbox.png|thumb|321x321px]]
 +
V průběhu práce tým se 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. Ten 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ý sleduje potom, tým probírá, co se podařilo, co je nutné změnit.
 +
 +
Pro měření úspěšnosti a náročnosti práce nad projektem jsou používaný takové techniky, jak burndown chart, velocity nebo planning poker.
 +
  
 
== Agilní metody vs. tradiční přístup (waterfall) ==
 
== Agilní metody vs. tradiční přístup (waterfall) ==
Řádek 58: Řádek 70:
 
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 nad nim 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živá 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 meně fixní verzi 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í čá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>.
  
 
==Výhody a nevýhody agilních metod==
 
==Výhody a nevýhody agilních metod==

Verze z 14. 4. 2018, 17:29


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á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í)[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 stala publikace článku „The New Product Development Game“ (1986) za autorstvím Takeuchi a Nonaka.[3]

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

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.[1][2]

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í.

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)[5].

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, 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í.[1][2]

Vyplň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 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 dokumentací. Není součastí týmu. Má mít odolsnost vůči stresu a vysoké komunikační schopnosti.[1][2]

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

Tým se sestavá z jedinců, kteří mohou být navzájem zastupitelné a cílem kterých je dodat část funkčního softwaru na konci sprintu. Je samoorganizovaný, má vysokou motivaci. Podtýmy neexistují.[1]

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 vyplňová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) .

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.

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-tři týdnů. Tým pracuje v průběhu sprintu se sprint backlogem , což je stanovený před začátkem sprintu 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 úkolů je hodně, tomuto meetingu předchází grooming .

Agile Project Management by Planbox.png

V průběhu práce tým se 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. Ten 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ý sleduje potom, tým probírá, co se podařilo, co je nutné změnit.

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


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

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

Vodopadovy model.png

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 nad nim a nemůže proces ovlivnit.

Použivá 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 meně fixní verzi 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í části projektu po ukončení sprintu[6].

Výhody a nevýhody agilních metod

Výhody:

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

Nevýhody:

  • 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.


Zdroje

Reference

  1. 1,0 1,1 1,2 1,3 1,4 1,5 ŠOCHOVÁ, Zuzana a Eduard KUNCE, 2014. Agilní metody řízení projektu. Brno, Computer Press, 2014. ISBN 978-80-251-4194-6.
  2. 2,0 2,1 2,2 2,3 2,4 2,5 2,6 2,7 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. 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.
  4. 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.
  5. 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.
  6. 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.

Klíčová slova

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