Začínáte projekt a nevíte kterou metodu zvolit? Zkusím se podívat na jednotlivé metody detailněji. Tradiční Waterfall vypadá ideálně. Nejprve si navrhnete, co budete dělat, pak řeknete jak, pak to uděláte, otestujete. Ideální. Snadné. Jen bohužel realita je vždy jiná. Výsledek ukážete zákazníkovi, a on se zatváří zklamaně, řekne, že tohle si nepředstavoval, či že tohle nikdy nechtěl a ať to předěláte. Vás pak na jedné straně čeká dlouhý refactoring a předělávání, a k tomu zákazník, který je nervózní že aplikaci stále nemá. Na druhé straně jsou dlouhé diskuze se zákazníkem, že v jeho původních požadavcích to bylo jinak či nebylo vůbec. A že tento refactoring musí zaplatit extra. Nic neobvyklého, a nic co by se jen blížilo spokojenosti na obou stranách.
Proto vznikl Rational Unified Process (RUP), který si uvědomuje, že není možné celou aplikaci napsat v jednom sekvenčním procesu – ostatně stejně se tak nikdy v reálu nedělo – a že jednotlivé fáze jsou více či méně přítomny periodicky v průběhu celého procesu. RUP se dá v podstatě považovat za pokus přiblížit Waterfall reálnému světu. Pokus to byl dobrý, nicméně spokojenosti zákazníka moc nepřispěl. Návrh vede často k velice komplexní a náročné architektuře, která ztěžuje případný refactoring. Navíc jednotlivé fáze jsou extrémně detailně specifikované, tedy libovolné změna vyžaduje i dlouhý čas na přepsání všech modelů a diagramů.
Asi nikoho nepřekvapí, že budu na tomto místě doporučovat agilní metody. Na rozdíl od předchozí metody, která vsadila na dobrý návrh, jsou agilní metody orientovány na změnu. Návrh by měl být co nejjednodušší, iterace dostatečně krátké, aby se omezilo riziko refactoringu. Navíc zákazník, který vidí každé dva týdny jednu feature a může se k ní přímo vyjádřit, je potom v daleko horší situaci když na konci projektu chce něco jinak. Agilní metody omezují návrh a dokumentaci na nutné minimum, nicméně na druhé straně zapojují testování hned na začátek návrhu (TDD), zavádí automatické testování a kontinuální integraci. Agilní metody jsou navíc založené na spolupráci, a to jak v rámci týmu tak i externě se zákazníkem, což je činí o dost efektivnější.
Na závěr přidávám krátkou tabulku s porovnáním jednotlivých metod:
|
|
Waterfall |
RUP |
Agile |
|
|
Sekvenční |
Inkrementální |
Iterativní |
|
|
Jasně definované requirementy. |
Počítá s mírnou změnou requirementů. |
Requirementy se konzultují se zákazníkem v průběhu. |
|
|
Specifikace se nemění |
Specifikace se nemění v rámci inkrementu. |
Specifikace se nemění v rámci sprintu. |
|
|
Jednotlivé fáze (analýza, design, testování, …) jsou oddělené a sekvenční. |
Jednotlivé fáze (analýza, design, testování, …) jsou oddělené, ale běží paralelně. |
Nerozděluje projekt na jednotlivé fáze. Každá úloha obsahuje všechny fáze (analýza, design, testování, …). |
|
|
Striktně definovaný proces, který nepočítá s žádnou změnou. |
Složitý, use-case driven, architecture-centric proces. |
Metodologie založená na rychlé reakci na změnu a spolupráci (interní i externí). |
|
|
Jednotlivé fáze jsou zdokumentované |
Snaha mít vše do detailu zdokumentované. |
Dokumentace jen v nejnutnější míře, jednoduchý designe, hlavní metrikou je spokojenost zákazníka. |
|
R I Z I K A |
· Nespokojenost zákazníka (něco jiného než chtěl) · Dlouhý refactoring · Nepřesné odhady |
· Příliš složitá a náročná architektura · Dlouhý refactoring · Nepřesné odhady |
· Náročný na komunikaci a kooperaci · Musí odpovídat firemní kultuře |
|
P O U Ž I T Í |
Jasně definovaný a dobře specifikovaný projekt kdy změna je vysoce nepravděpodobná. Zákazník musí perfektně vědět, co chce dopředu. Náročný na zkušenosti jednotlivých engineerů. |
Komplexní systémy vyžadující detailní dokumentaci a náročnou architekturu. Změna požadavků je nepravděpodobná. Náročný na zkušenosti jednotlivých engineerů. |
Projekt pro běžné zákazníky co často úplně přesně nevědí, co chtějí. Požadavky se mohou měnit v rámci projektu. Cílem je spokojený zákazník. Střední nároky na zkušenosti týmu. |