wiki.valek.net

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 25. Agilní metodiky vývoje SW ======

Charakterizujte agilní metodiky vývoje SW, na jakých principech jsou založeny. Jmenujte některé agilní metodiky. Jaké jsou jejich přednosti a nedostatky? 
===== Úloha =====
**Předpoklady:** 
Jste vedoucím projektu vývoje IS/ICT objektově-orientovaným způsobem.

**Zadání:**
  * Jaká kritéria použijete pro volbu metodiky? 
  * Jaké budou kritické faktory úspěchu projektu při použití dané metodiky?

===== Teorie =====
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 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.

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

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. 

===== Manifest =====
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]

Tento [[http://agilemanifesto.org/|manifest]] deklaruje následující priority (citace z [AP 2001]):

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

Mezi základní rysy agilních metodik 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
  - týmovou spolupráci a samoorganizaci týmů
  - co nejčastější předávání hotové práce
  - vítání změn jako příležitosti být lepší
  - důraz na výslednou hodnotu pro zákazníka před dokumenty a papírováním

===== 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í]]

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 ====

[[wp>Scrum_(development)|Scrum]]
==== DSDM ====

[[wp>Dynamic_Systems_Development_Method|DSDM]]
==== Crystal metodiky ====

==== Feature Driven Development ====

[[wp>Feature_Driven_Development|Feature Driven Development]]

==== Adaptive Software Development ( ASD) ====

==== Lean Development ====

==== Agilní modelování (Agile Modeling) ====

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

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

S tímto tvrzením však nelze souhlasit. Pokud se podíváme na jiné oblasti inženýrských aktivit (stavebnictví, strojírenství, …), tak uvidíme, že se všude plánuje, analyzuje, dokumentuje, prototypuje, testuje atd. Proč by tedy měla být oblast tvorby softwaru výjimečná? 

Základní myšlenka potřebnosti „rigorózních“ metodik nemůže být špatná. I v softwarovém inženýrství je potřeba projekty plánovat, řídit, analyzovat zadání atp. Na druhou stranu je pravda, že v mnoha případech „rigorózní“ přístup nevede k lepšímu, rychlejšímu a levnějšímu výsledku, než při nasazení AP. 

Rigorózní metodiky pro vývoj s pomocí OOP mají za sebou dlouhý vývoj. Většinou vznikly postupnou změnou z klasických strukturovaných metodik. Dnes používané metodiky mají svůj původ ve výzkumu a zkušenostech s tvorbou softwaru pomocí OOP v 90. letech. Zde jsou příčiny, proč nesplňují očekávání a selhávají. Zároveň se zde skrývá vysvětlení, proč došlo ke vzniku AP. Příčiny jsou dvě:

První spočívá ve změně stylu programování, jak byla popsány v kapitole 3.2.1. Rigorózní metodiky selhávají proto, že se nedostatečně vyrovnaly se změnou nástrojů a technik pro programování a implementaci. Jednoduše řečeno; rigorózní metodiky stále dostatečně nezaznamenaly výraznou kvalitativní změnu ve způsobu tvorby programů a stále předpokládají, že ve fázi implementace je jen potřeba z celkového modelu úlohy vyprodukovat zdrojový kód, který se dodá kompilátoru k překladu. Vývojáři proto oprávněně hledí s nedůvěrou na rigorózní metodiky, když na jedné straně vyžadují tvorbu perfektního konceptuálního modelu a na druhé straně nevyužívají možnosti, které mají dnešní vývojové prostředí. Naproti tomu AP nejen umožňuje, ale přímo vyžaduje plnou podporu vlastností nových vývojových prostředí a navíc  bez potřeby modelování.

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