Lekce 2 - Metodiky RAD a DSDM

V minulé lekci, Úvod do metodologie vývoje softwaru, jsme si uvedli běžné problémy při vývoji softwaru a jejich možné řešení. Nyní už také víme, jaký je rozdíl mezi tradiční a agilní metodikou.

Rapid Application Development (zkráceně RAD) je metodika vývoje softwaru, která vznikla na přelomu 80. a 90. let společnosti IBM. Jedná se o formu agilní metodiky, při které probíhá méně plánování, ale více vývoje.

Metodika RAD

Vývoj softwaru pomocí metodiky RAD probíhá pomocí prototypování. Jako první nastává analýza požadavků a rychlý vývoj prototypu (někdy dokonce i více prototypů zároveň). Prototypy se vytvářejí již od rané verze softwaru a uživatelé se tak setkávají s podobou cílového řešení již brzy při vývoji. Díky zpětné vazbě od těchto uživatelů se dokáží rychle zachytit problémy z jejich strany a dokáže se na ně rychle reagovat. Pokud je už zákazník s výsledkem spokojený, nastává testování a oprava dokončeného produktu. Po všech těchto krocích je software připravený na implementaci:

Diagram procesu vývoje softwaru pomocí metodiky RAD.

Musíme se připravit na to, že uživatel nebude spokojený na 100 %. Může nastat situace, kdy si zákazník stanoví budget, do kterého se s jeho požadavky prostě nebude možné vejít. Je důležité umět najít kompromis.

Příklad

Pro lepší pochopení této metodiky si uvedeme příklad.

Mějme zákazníka, který po nás chce vytvořit aplikaci pro jeho internetový obchod. Zákazník jako již obvykle pořádně neví, co vlastně chce, a tak nám naloží pořádnou dávku požadavků, které se vejdou do jeho stanoveného rozpočtu. Kdo by taky nechtěl co nejvíce muziky za málo peněz, že? Když za našim zákazníkem po chvíli přijdeme s prototypem, uvědomí si, že o některou z dříve chtěných funkcionalit nestojí a že jsou pro jeho aplikaci zbytečné. Naopak nám řekne, že by se chtěl dát jiným směrem a my jsme tak díky prototypu zabránili zbytečné práci na něčem, o co zákazník vlastně ani neměl pořádně zájem. Díky této metodice se můžeme soustředit více na to, co zákazník doopravdy chce.

Způsob vývoje pomocí metodiky RAD je značnou výhodou oproti velmi zastaralému „utopickému“ vodopádovému vývoji, ve kterém by se při zjištění nedostatků muselo jít znovu na začátek a začínat skoro znova:

Zastaralý vodopádový model, který se dnes už nepoužívá.

Využití

RAD se využívá především na typ softwaru, který rychlý vývoj umožňuje. To znamená, že máme nějakou platformu, na kterou pomocí RAD přístupu napojujeme další části a tím se původní software stává rozsáhlejší. Takováto RAD platforma řeší velmi efektivně jednotné uživatelské rozhraní a vnitřní fungování napříč celou platformou (sdílení dat, kompatibilita a podobně). Můžete si to představit jako sadu herních kartiček, ke kterým si dokupujete různé expanze.

Výhody

Jednou z výhod RAD přístupu je zejména vyšší kvalita díky používání prototypů. Důraz je při vývoji kladen hlavně na uživatele a jeho potřeby. Celková funkcionalita tak bude odpovídat hlavně požadavkům uživatele a ten bude díky tomu spokojenější. Další výhodou je bezesporu včasná identifikace a eliminace rizik a tím i velké ušetření času. Díky těmto výhodám roste pravděpodobnost, že se projekt dokončí včas a vejdeme se do daného rozpočtu.

Nevýhody

Aby to celé neznělo moc pohádkově dobře, tak i u RAD metodiky nalezneme nevýhody.

RAD vyžaduje skoro neustálé zapojení „business“, kdy díky novým verzím prototypů vznikají i neustále nové požadavky, které je nutné řešit. Díky neustále novým prototypům může docházet k nedostatkům v návrhu. Dochází tak k neustálým drobným změnám a podcenění základní stavební architektury, kterou by mělo řešení disponovat.

Metodika DSDM

Řekli jsme si tedy, jak metodika RAD funguje, kde se využívá a jaké jsou výhody a nevýhody. Podle čeho se ale řídí? Není na škodu zmínit metodiku Dynamic Systems Development Method (Zkráceně DSDM). Tato metodika původně vznikla jako řídící struktura pro metodiku RAD a jsou si velmi podobné. Z metodiky pro vývoj softwaru se DSDM nakonec vyvinulo v agilní metodiku pro řízení projektů, které se mohou zabývat skoro čímkoliv.

Stejně jako u metodiky RAD, první nastává analýza (v tomto případě Proveditelnost a Business studie). Poté přichází na řadu vytvoření funkčního prototypu. Dále se zpracují návrhy na vylepšení, či změny a jako poslední krok je implementace samotného projektu:

Diagram procesu řešení projektu pro metodiku DSDM.

DSDM Atern je nezávislý přístup, který říká, že více projektů ztroskotá díky problémům s lidmi než s technologiemi. Atern se tak soustředí na pomoc lidem pracovat společně a efektivně k dosažení cíle. Je nezávislý na technologiích a technikách a díky tomu se nemusí vázat na řešení problémů jen v určité oblasti.

Atern obsahuje 8 principů, které směřují tým k tomu, aby projekt neselhal:

• Zaměření se na business potřeby.
• Doručení včas.
• Spolupráce.
• Nikdy neohrožovat kvalitu.
• Budování postupně a ze silných základů.
• Rozvíjení iterativně.
• Nepřetržitá a jasná komunikace.
• Prokázání kontroly.

Techniky pro řízení projektu

Timeboxing je postup pro postupné dokončení projektu za pomoci rozdělení projektu na menší části – každá část s pevným rozpočtem a časem dokončení. Jelikož je DSDM agilní přístup a my už víme, že rozsah je v tomto případě proměnný, tak je už víceméně jasné, že pokud našemu projektu dojde čas nebo peníze, musíme požadavky s nejnižší prioritou z projektu vypustit. To ovšem neznamená, že nedodáme nedokončený produkt. Podle Paretova principu 80/20 víme, že 80 % projektu pochází z 20 % požadavků. Dokud máme tedy v projektu implementováno těchto 20 %, projekt splňuje obchodní potřeby:

Ilustrativní ukázka Paretova pravidla.

Čím menší je hodnota u daného problému, tím méně křivka stoupá.

MoSCoW je zase technika pro prioritizaci požadavků. Jedná se o jednoduché MUSÍME (Must) mít, MĚLI BY JSME (Should) mít, MOHLI BY JSME (Could) mít a NEBUDEME (Won‘t) mít. Jsou to úrovně priorit pro požadavky na projekt. Můžeme je využít například v již zmíněném Timeboxingu.

Prototypování a Testování už známe z metodiky RAD. Jedná se tedy o vytváření prototypů a jejich testování uživateli. Díky tomu víme, jestli se vydáváme správným směrem a můžeme včas řešit problémy.

Workshop je schůzka všech zúčastněných stran projektu, aby spolu prodiskutovali požadavky, funkce a vzájemně si tak lépe porozuměli.

Modelování pomáhá s vizualizací a zlepšuje porozumění. Jedná se o vytvoření schématického znázornění důležitých částí projektu.

Závěr

Není pravidlem, že se metodika RAD musí řídit zrovna pomocí DSDM. DSDM a stejně tak RAD jsou pouze souborem doporučení, které pomáhají s řízením projektu a jak již padlo v minulé lekci, jedná se opravdu spíše o doporučení, než o pevně daná pravidla.

V následujícím kvízu, Kvíz - Metodologie, metodiky RAD a DSDM, si vyzkoušíme nabyté zkušenosti z předchozích lekcí.