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. |
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Zuzi,
mohla bys trochu rozvest narocnosti na cleny tymu? Jaky je rozdil mezi “narocny” a “stredne narocny”?
Muj dojem je, ze v (R)UP clenove tymu mohou byt mene zkuseni, protoze z predchozi faze (analyza->design->programovani) prichazeji artefakty, ktere urcuji, co se v dalsi fazi ma delat (jako priklad… vyvoj a la jedna velka softwarova firma od U, co hojne pouziva studenty? 😉
Dik.
Oleg
To je asi otazkou z jake strany se na to podivas. Psala jsem to z pohledu architektury, ktera v RUP vznikne casto velmi komplexni a slozita… Ani v agilnich tymech nemusi byt vsichni experty, ale par je jich treba, zrovantak jako pro projekty RUP. Diky za komentar 🙂
Ahoj, dovolil bych si podotknout, ze tvrzeni, ze RUP je nekde mezi waterfall a Agile je ponekud nepresne. RUP je process framework, coz znamena, ze je potreba nasledovat jeden z jeho naprosto zakladnich principu, coz je “Adapt the process”. Cili pouzit takove aktivity, artefakty atd., ktere konkretnimu projektu prinesou hodnotu. RUP obsahuje spoustu veci a podle zkusenosti a mindsetu konkretniho cloveka jej lze ohnout jak na waterfall, tak na Agile. Typickou chybou lidi, kteri RUP chteji implementovat, je to, ze vezmou prilis mnoho (nebo vse), pripadne se po sve zkusenosti s waterfallem soustredi pouze na artefakty (hlavne dokumenty) a pak samozrejme neprodukuji zadnou rozumnou hodnotu a ztraceji se v administrative a byrokracii.
Pricina toho, proc RUP neni moc prijimany v agile komunite je podle me mala zkusenosti lidi s agilnim vyvojem, slabe pochopeni klicovych principu a mnozstvi ruznych tasku, guidelines, work products etc. v RUPu. Bez znalosti principu a urcite zkusenosti je nemozne efektivne vybrat podmnozinu RUPu, ktera bude s ohledem na kontext projektu (cile, rizika, omezeni, zkusenost tymu, distribuce, nasledovane standardy apod.) nejprinosnejsi.
Tohle pochopilo i IBM a to je i duvod, proc vznikl Open Unified Process (OpenUP). Ten obsahuje jednoduche jadro (klicove principy a praktiky) a je mnohem jednodussi na uchopeni. V pripade potreby dalsich detailu je vsak treba jit zpatky do RUPu, pripadne pouzit nejake dalsi pluginy od IBM, ktere zahrnuji podporu skalovatelnosti, distribuce a dalsi faktoru, ktere prispivaji ke slozitosti projektu.
Rad bych take vyzdvihl prinost risk driven milniku z Unified Procesu. Jeho faze (ktere mimochodem nemaji absolutne nic spolecneho s fazemi waterfallu, ktere jsou mapovany 1:1 s disciplinami – Req, Analysis, Design, Coding, Testing, Deployment, …), jejichz cilem je proaktivni zmirneni urcitych rizik (riziko nejasne vize, riziko slabe/nevhodne architektury atd.) poskytuji explicitni milniky pro byznys rozhodnuti (pokracovat/nepokracovat), a to samozrejme na zaklade objektivniho vyhodnoceni (otestovana demonstrovatelna funkcionalita). Prikladem muze byt Elaboration faze, kde v nasem checklistu budou veci jako architektura (ne pouze UML specifikace, ale tzv. “chodici kostra”, tj. implementace kriticke funkcionality, otestovana jak vuci funkcnim, tak i nefunkcnim pozadavkum), aktualni stav rizik (zbyvaji jeste nejaka kriticka technicka nebo byznys rizika, ktera jsme nezmirnili implementaci a demonstrovanim kritickych casti funkcionality?), jestli uz ma nas projektovy tym zabehnuty zpusob prace (jasne vedi co a jak delaji), stabilni prostredi (treba nastroje) atd. Pokud tohle neni na miste, pak je velkym rizikem pokracovat do dalsi faze (Construction). Pokud nejsme schopni napr. demonstrovat, ze ma nase architektura na konci Elaboration potrebny vykon, nebo je dostatecne bezpecna a zjistime tento problem az v pozdni fazi projektu, pak to vyusti v potrebu hodne velkeho prepracovani vysledneho produktu, coz znamena vyrazne zvyseni nakladu a potrebneho casu (coz je jednim z hlavnich duvodu, proc je pouze cca 28% uspesnych projektu a vsechny ostatni maji problemy – mrknete na Standish Group Chaos Report).
Abych to shrnul – to, na cem opravdu zalezi jsou principy a kontext. Bez jejich zohledneni mohou i skvele praktiky jako automaticke testovani nebo daily standup meetings byt kontraproduktivni. A tohle si hodne lidi bohuzel neuvedomuje, kdyz se soustredi treba jen na Scrum, ktery se zameruje pouze na leadership a requirements management a defacto pokryva pouze malou cast zivotniho cyklu (Construction). A pak jsou prekvapeni, ze jim to nefunguje v prostredi projektu citajiciho 50 lidi a distribuovaneho pres 3 zeme :o)
Hezky den :o)
Presne tak, clanek je velmi zjednodusujici, jak v oblasti RUP, tak v oblasti agilnich metodik.
Popis RUP plyne z nepochopeni a uz jen popis RUP a Agile ukazuje zjednoduseni, vzdyt oba dva jsou iterativne inkrementalni (v pravidelnych iteracich dorucuji spustitelny otestovany prirustek – inkrement) a take pozadavky jsou obema pristupy zpracovany uplne stejne.
Navic Agilni projekt nemuze byt pouze sled iteraci, to bychom potom mohli refaktorovat drsne exisutjici architekturu v kazde iteraci diky kratkozrakemu pohledu (jen tato iterace). Prave smyslem fazi v RUP je seskupit iterace do jiste skupiny, abychom meli specificky pohled na projekt, ktery v dane fazi potrebujeme. Navic architektura v Elaboration fazi musi obsahovat zakladni implementovane scenare, jinak ji nejsme schopni overit 😉
Nehlede na to, ze pokud clovek zna principy RUP (Adapt the process, balance stakeholder reqs, collaborate across teams, demonstrate the value iteratively, elevate the level of abstraction and focus on quality), tak si je presne dokaze namapovat na Agilni hodnoty (values) a principy (principles).
Ale je to samozrejme veci mindset, jak psal Marty. Clovek s tradicnim plan-driven myslenim je schopny udelat vodopad nejen z RUP, ale i ze Scrumu (ze jsme takovych projektu uz videli :))