Differences

This shows you the differences between two versions of the page.

--- statnice:vyvoj:otazka25 [18.05.2008 11:47] – xvalo07
+++ statnice:vyvoj:otazka25 [30.05.2008 21:19] (current) – formátování xvalo07
@@ Line 11: / Line 11: @@
 ===== Teorie =====
-Agilní metodiky vývoje se začaly objevovat na konci devadesátých let minulého století v mnoha rozličných formách jako reakce na to, že většina softwarových projektů nekončila včas, v rámci rozpočtu, případně nedodala zákazníkovi to, co očekával. To bylo způsobeno mnoha faktory a každá metodika se je snažila vyřešit jinak.
+Tradiční rigorózní metodiky vývoje softwaru přestávají v prostředí neustálých změn vyhovovat a začínají se prosazovat agilní metodiky. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru a jsou propagovány zejména díky Alianci pro agilní vývoj softwaru. Zatímco ve světě se agilní metodiky stále více prosazují, v české praxi se nedočkaly většího rozšíření a dokonce se ani nedostaly do obecného povědomí odborníků v oblasti IS/ICT.
-Agilní metodiky - novinka pro třetí tisíciletí
+Agilní metodiky se v poslední době stále používají na projektech v zahraničí. Nejde jen o plné nasazení určité agilní metodiky, ale také o kombinace jednotlivých agilních metodik a nebo aplikaci agilních přístupů v rámci tradičních metodik. Na základě oficiálních „veřejných“ metodik vznikají individuální varianty.
-Na začátku 21. století se objevil nový fenomén na poli metodik vývoje softwaru – agilní metodiky. Za výchozí dokument těchto metodik můžeme považovat “Manifest pro agilní softwarový vývoj” od Kenta Becka či Alistaira Cockburna. Podle nich můžeme agilní metodiky definovat jako metodiky snažící se o lepší vývoj softwaru.
+Situace v Česku je ale poněkud jiná. Agilním metodikám jsou věnovány přípěvky na odborných konferencích a také odborná česká literatura se snaží této oblasti věnovat viz například [3], [5]. Přesto se v české praxi zatím agilní metodiky nebo firemní standardy odvozené od agilních metodik nedočkaly většího rozšíření. Tento článek podává informaci o průzkumu zaměřeném na využívání agilních metodik v českých firmách, který byl realizován v roce 2006 v rámci zpracování diplomové práce ing. Marka Leitla [6].
-Dosahují toho především upřednostňováním jednotlivců a komunikace v týmu místo procesů a nástrojů. Dávají přednost funkčnímu softwaru před komplexními specifikacemi. Preferují spolupráci se zákazníky před dlouhými dohady nad smlouvami a upřednostňují rychlou odezvu na změny před slepým plněním plánů. Agilní metodiky považují stávající metodiky jako např. Unified Process za příliš “těžkotonážní”. Naproti tomu samy sebe označují jako “lehkotonážní”. Uvedená terminologie je založena zejména na skutečnosti, že stávající metodiky jsou příliš orientovány na dodržování spousty přednastavených postupů a pravidel, což vede k zatěžování vývojového týmu a vzdaluje ho od vytvoření vysoce kvalitního produktu splňujícího požadavky na náklady, čas, kvalitu a rozsah.
+Změny technologií a ekonomického prostředí, ke kterým v posledních letech dochází, vyvolávají potřebu rychlého zavedení IS/ICT a jeho přizpůsobování měnícím se podmínkám. Tradiční rigorózní metodiky vývoje softwaru přestávají v takových podmínkách vyhovovat a začínají se prosazovat agilní metodiky. Jedná se o různé metodiky, které vznikaly od druhé poloviny 90. let a které prosazují myšlenku, že jedinou cestou, jak prověřit správnost navrženého systému, je vyvinout jej (nebo jeho část) co nejrychleji, předložit zákazníkovi a na základě zpětné vazby jej upravit. [3] Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru a jsou propagovány zejména díky Alianci pro agilní vývoj softwaru.
-Agilní metodiky si kladou za cíl “polidštit” vývoj softwaru. Chtějí se více soustředit na dosažení primárního cíle a méně se zabývat formalismem. Mezi agilní metodiky SCRUM, Crystal Light či extrémní programování (XP). Popularita agilních metodik, zejména extrémního programování, v posledních letech výrazně vzrostla, agilní metodiky se staly fenoménem, který nelze jednoduše odbýt mávnutím ruky. Proto jsou nově do tradičních metodik jejich autory zapracovávány i principy agilního vývoje - skutečnost, že lze něco takového provést, pka jen dokazuje vzájemnou kompatibilitu obou přístupů.
+===== Manifest =====
-Další metodikou je SCRUM, česky mlýn v ragby. V textu je opět vysvětlena charakteristika metodiky, zvláště pak odlišnosti od XP. Poté se autor věnuje Lean Developementu, který má svůj původ v japonském automobilovém průmyslu a klade si za cíl vyvíjet software za třetinu obvyklého času s třetinovým rozpočtem a s třikrát menším množstvím chyb. Hodně zajímavé a poučné počtení.
+Agilní metodiky jsou samotnými autory označovány jako metodiky, které umožňují vytvořit řešení velmi rychle a optimálně a toto řešení dovolují pružně přizpůsobovat. Jedná se o několik metodik, z nich nejpopulárnější je takzvané extrémní programování (XP). Agilní přístup (AP) byl s velkým nadšením přijat v komunitě programátorů pracujících s OOP. Představitelé těchto přístupů z celého světa v roce 2001 vydali společný dokument „Agile Manifesto“ a vytvořili alianci pro „agilní vývoj softwaru“. [AP 2001, Beck 2003, Beck 2002]
-Čtvrtou metodikou je Feature Driven Development, po kterém přichází netradiční Test Driven Development. Nelíbil se mi příklad postavený na webové stránce psané v PHP. Myslím, že lépe by posloužilo nějaké API. Ve zbytku třetí části knihy autor stručně popisuje metodiky Crystal, Adaptive Software Development a Dynamic Software Development Method.
+Tento [[http://agilemanifesto.org/|manifest]] deklaruje následující priority (citace z [AP 2001]):
-Příklady:
+> Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Dáváme přednost:
+>   - individualitám a komunikaci před procesy a nástroji,
+>   - provozuschopnému softwaru před obsažnou dokumentací,
+>   - spolupráci se zákazníkem před sjednáváním kontraktu a
+>   - reakci na změnu před plněním plánu.
-Extrémní programování
+Mezi základní rysy agilních metodik patří:
-Přitom různé metodiky kladou na tyto rysy různý důraz. Například, jedna z nejznámějších agilní metodik, extrémní programování, některé z nich dotahuje skutečně „do extrému“. V extrémním programování je např. jedinou psanou dokumentací sám programový kód, kde se ale klade důraz na jeho velkou čitelnost a jednoduchost. Současně dochází prakticky denně k uvolňování nové funkčnosti pro zákazníka.
-Scrum
-DSDM
-Crystal Clear
-Feature Driven Development
-http://agilemanifesto.org/
-Mezi tyto rysy patří:
   - důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem
   - důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka
@@ Line 48: / Line 38: @@
   - důraz na výslednou hodnotu pro zákazníka před dokumenty a papírováním
-Buchalcevová Alena
+===== Metodiky =====
+Pod hlavičku agilních metodik můžeme zařadit následující metodiky a přístupy:
+==== Extrémní programování ====
+[[wp>Extreme_Programming|extrémní programování]]
-Tradiční rigorózní metodiky vývoje softwaru přestávají v prostředí neustálých změn vyhovovat a začínají se prosazovat agilní metodiky. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru a jsou propagovány zejména díky Alianci pro agilní vývoj softwaru. Zatímco ve světě se agilní metodiky stále více prosazují, v české praxi se nedočkaly většího rozšíření a dokonce se ani nedostaly do obecného povědomí odborníků v oblasti IS/ICT. Tento článek podává informaci o průzkumu zaměřeném na využívání agilních metodik v českých firmách, který byl realizován v rámci zpracování diplomové práce v roce 2006.
+Přitom různé metodiky kladou na tyto rysy různý důraz. Například, jedna z nejznámějších agilní metodik, extrémní programování, některé z nich dotahuje skutečně „do extrému“. V extrémním programování je např. jedinou psanou dokumentací sám programový kód, kde se ale klade důraz na jeho velkou čitelnost a jednoduchost. Současně dochází prakticky denně k uvolňování nové funkčnosti pro zákazníka.
+==== Scrum ====
-Změny technologií a ekonomického prostředí, ke kterým v posledních letech dochází, vyvolávají potřebu rychlého zavedení IS/ICT a jeho přizpůsobování měnícím se podmínkám. Tradiční rigorózní metodiky vývoje softwaru přestávají v takových podmínkách vyhovovat a začínají se prosazovat agilní metodiky. Jedná se o různé metodiky, které vznikaly od druhé poloviny 90. let a které prosazují myšlenku, že jedinou cestou, jak prověřit správnost navrženého systému, je vyvinout jej (nebo jeho část) co nejrychleji, předložit zákazníkovi a na základě zpětné vazby jej upravit. [3] Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru a jsou propagovány zejména díky Alianci pro agilní vývoj softwaru. Pod hlavičku agilních metodik můžeme zařadit následující metodiky a
+[[wp>Scrum_(development)|Scrum]]
+==== DSDM ====
-přístupy:
+[[wp>Dynamic_Systems_Development_Method|DSDM]]
-  * Dynamic Systems Development Method (DSDM),
+==== Crystal metodiky ====
-  * Adaptive Software Development ( ASD),
-  * Feature–Driven Development (FDD),
-  * Extrémní programování (Extreme Programming, XP),
-  * Lean Development,
-  * Scrum ,
-  * Crystal metodiky,
-  * Agilní modelování (Agile Modeling).
-Agilní metodiky se v poslední době stále používají na projektech v zahraničí. Nejde jen o plné nasazení určité agilní metodiky, ale také o kombinace jednotlivých agilních metodik a nebo aplikaci agilních přístupů v rámci tradičních metodik. Na základě oficiálních „veřejných“ metodik vznikají individuální varianty.
+==== Feature Driven Development ====
-Situace v Česku je ale poněkud jiná. Agilním metodikám jsou věnovány přípěvky na odborných konferencích a také odborná česká literatura se snaží této oblasti věnovat viz například [3], [5]. Přesto se v české praxi zatím agilní metodiky nebo firemní standardy odvozené od agilních metodik nedočkaly většího rozšíření. Tento článek podává informaci o průzkumu zaměřeném na využívání agilních metodik v českých firmách, který byl realizován v roce 2006 v rámci zpracování diplomové práce ing. Marka Leitla [6].
+[[wp>Feature_Driven_Development|Feature Driven Development]]
-Agilní metodiky
+==== Adaptive Software Development ( ASD) ====
-Agilní metodiky jsou samotnými autory označovány jako metodiky, které umožňují vytvořit řešení velmi rychle a optimálně a toto řešení dovolují pružně přizpůsobovat. Jedná se o několik metodik, z nich nejpopulárnější je takzvané extrémní programování (XP). Agilní přístup (AP) byl s velkým nadšením přijat v komunitě programátorů pracujících s OOP. Představitelé těchto přístupů z celého světa v roce 2001 vydali společný dokument „Agile Manifesto“ a vytvořili alianci pro „agilní vývoj softwaru“. [AP 2001, Beck 2003, Beck 2002]
+==== Lean Development ====
-  Tento manifest deklaruje následující priority (citace z [AP 2001]):
+==== Agilní modelování (Agile Modeling) ====
-Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Dáváme přednost:
-  * individualitám a komunikaci před procesy a nástroji,
-  * provozuschopnému softwaru před obsažnou dokumentací,
-  * spolupráci se zákazníkem před sjednáváním kontraktu a
-  * reakci na změnu před plněním plánu.
-Přestože doposud uvedená informace o agilním přístupu vypadá krajně podezřele, tak agilní přístup má v praxi dobré výsledky, což můžeme potvrdit i my1. Autoři agilních metodik jsou většinou pro věc nadšení, ale také velmi vzdělaní lidé. Někteří z nich odborně publikují i v oblasti formálních technik a jiných metod řízení projektů, což dokladuji například i citace Amblera a Becka v tomto textu.
+===== Přednosti agilních metodik =====
 Agilní přístup má velké přednosti v malých týmech, které mohou pravidelně komunikovat se zákazníkem/zadavatelem. Nezbytnou nutností pro úspěch je ale mít zajištěné:
   * technickou podporu týmu (vývojové prostředí, které umožňuje práci s komponentami, inkrementální kompilaci, refaktoring, evidence a sdílení kódu, metriky a v neposlední řadě testování) a
   * koordinovaný a průběžný kontakt se zadavatelem/zákazníkem.
-Agilní přístupy nelze použít u velmi velkých projektů, kde se naráží nejvíce na nedostatek průběžného kontaktu se zadavateli a na potřebu projekt plánovat.
+Autoři agilních metodik jsou většinou pro věc nadšení, ale také velmi vzdělaní lidé. Někteří z nich odborně publikují i v oblasti formálních technik a jiných metod řízení projektů, což dokladuji například i citace Amblera a Becka v tomto textu.
+===== Kritika =====
-Podrobný popis agilních metodik s důrazem na extrémní programování je obsahem samostatné kapitoly sekce tohoto textu.
+Agilní přístupy nelze použít u velmi velkých projektů, kde se naráží nejvíce na nedostatek průběžného kontaktu se zadavateli a na potřebu projekt plánovat.
-Příčina sporu
 Příčina vzniku agilních metodik je samotnými autory popisována jako selhání rigorózních metodik. Příčinu jejich selhání vysvětlují v nepotřebné dokumentaci, zbytečném kreslení diagramů a vůbec v provádění aktivit, které oddalují „opravdové“ programování. Jako lék nabízejí tyto zdržující aktivity nedělat vůbec a soustředit se jen na vlastní tvorbu softwaru.
@@ Line 102: / Line 82: @@
 Další problém spočívá ve schopnosti rigorózních metodik správně, účinně a rychle zachytit, analyzovat a zobrazit zadání od uživatelů. K modelování se dnes téměř výhradně používá UML. V kapitole 4.2.2 byla diskutována jeho nedostatečná podpora úvodních fází modelování. AP je totiž také odpovědí na to, že UML nepodporuje dobře úvodní analýzu. Proto AP radí raději žádnou analýzu zadání nedělat a místo toho řešit projekt po částech a pravidelně spolupracovat s uživatelem. Bohužel vinou nedostatků rigorózních metodik je dnes AP prakticky úspěšné i v oblastech, kde by uživatelé byli schopni a dokonce by preferovali na začátku projektu formulovat požadavky – nebo jejich podstatnou část. Ale protože je v UML obtížné je srozumitelně modelovat, tak se raději nemodeluje vůbec a přistupuje se k AP, přičemž uživatelé musí průběžně komunikovat během vývoje. Toto je problém větších projektů, například specifických aplikací pro business, systémů pro řízení technologií (v telekomunikačním průmyslu nebo distribuce energií), atd. Ve všech těchto oblastech je třeba projekty plánovat a zadání je z podstatné části známé předem.
+=========================================================
+Podrobný popis agilních metodik s důrazem na extrémní programování je obsahem samostatné kapitoly sekce tohoto textu.
+Příčina sporu
+========================================
+Agilní metodiky vývoje se začaly objevovat na konci devadesátých let minulého století v mnoha rozličných formách jako reakce na to, že většina softwarových projektů nekončila včas, v rámci rozpočtu, případně nedodala zákazníkovi to, co očekával. To bylo způsobeno mnoha faktory a každá metodika se je snažila vyřešit jinak.
+Agilní metodiky - novinka pro třetí tisíciletí
+Na začátku 21. století se objevil nový fenomén na poli metodik vývoje softwaru – agilní metodiky. Za výchozí dokument těchto metodik můžeme považovat “Manifest pro agilní softwarový vývoj” od Kenta Becka či Alistaira Cockburna. Podle nich můžeme agilní metodiky definovat jako metodiky snažící se o lepší vývoj softwaru.
+Dosahují toho především upřednostňováním jednotlivců a komunikace v týmu místo procesů a nástrojů. Dávají přednost funkčnímu softwaru před komplexními specifikacemi. Preferují spolupráci se zákazníky před dlouhými dohady nad smlouvami a upřednostňují rychlou odezvu na změny před slepým plněním plánů. Agilní metodiky považují stávající metodiky jako např. Unified Process za příliš “těžkotonážní”. Naproti tomu samy sebe označují jako “lehkotonážní”. Uvedená terminologie je založena zejména na skutečnosti, že stávající metodiky jsou příliš orientovány na dodržování spousty přednastavených postupů a pravidel, což vede k zatěžování vývojového týmu a vzdaluje ho od vytvoření vysoce kvalitního produktu splňujícího požadavky na náklady, čas, kvalitu a rozsah.
+Agilní metodiky si kladou za cíl “polidštit” vývoj softwaru. Chtějí se více soustředit na dosažení primárního cíle a méně se zabývat formalismem. Mezi agilní metodiky SCRUM, Crystal Light či extrémní programování (XP). Popularita agilních metodik, zejména extrémního programování, v posledních letech výrazně vzrostla, agilní metodiky se staly fenoménem, který nelze jednoduše odbýt mávnutím ruky. Proto jsou nově do tradičních metodik jejich autory zapracovávány i principy agilního vývoje - skutečnost, že lze něco takového provést, pka jen dokazuje vzájemnou kompatibilitu obou přístupů.
+Další metodikou je SCRUM, česky mlýn v ragby. V textu je opět vysvětlena charakteristika metodiky, zvláště pak odlišnosti od XP. Poté se autor věnuje Lean Developementu, který má svůj původ v japonském automobilovém průmyslu a klade si za cíl vyvíjet software za třetinu obvyklého času s třetinovým rozpočtem a s třikrát menším množstvím chyb. Hodně zajímavé a poučné počtení.
+Čtvrtou metodikou je Feature Driven Development, po kterém přichází netradiční Test Driven Development. Nelíbil se mi příklad postavený na webové stránce psané v PHP. Myslím, že lépe by posloužilo nějaké API. Ve zbytku třetí části knihy autor stručně popisuje metodiky Crystal, Adaptive Software Development a Dynamic Software Development Method.
 ===== Praxe =====
 FIXME