Agilní vývoj: Úvod

Text tohoto seriálu vychází z práce Jiřího Knesla o řízení agilních týmů pro BIBS. – pozn.red.

Software lze vyvíjet celou řadou způsobů. Ať už se jedná o tzv. Waterfall model (klasický přístup, od analýzy přes návrh a betaverze k finálnímu produktu) nebo o agilní metodiku, je nutné, aby manažer tým analytiků, vývojářů a testerů koordinoval, bral v potaz zájem klienta a zároveň kladl důraz na kvalitu a produktivitu samotných pracovníků. Protože jsou světy agilních a neagilních týmů poměrně oddělené a zároveň velmi komplexní, zaměříme se na jednu z oblastí. Tedy na agilní metodiky, jejich vliv na produktivitu a také na to, jak agilní metodiky v týmu podporovat.

Agilní metodika a Agilní technika

Přestože se tyto termíny často zaměňují, nebo dokonce považují za totéž, ve skutečnosti se jedná o rozdílné (jakkoliv propojené) oblasti s naprosto rozdílnými významy.

Agilní metodika je způsob rozvržení a ověřování práce. Cílem Agilní metodiky bývá lepší organizace práce. Odlišné Agilní metodiky vedou k odlišným produktům, protože považují jiné aspekty produktu za klíčové. Liší se i přístup ke změně zadání. Možnost změny zadání je ale určující podmínkou Agile:

“Agile is the ability both to create and respond to change in order to profit in a turbulent business environment.”

Agilní technika je naproti tomu konkrétní postup, který se většinou týká samotných vývojářů. Cílem těchto technik bývá zvýšení produktivity práce, odstranění chyb, kvalitnější software nebo přesnější dodržení specifikace. Agilní techniky jsou od metodik oddělitelné. Cílem Agilní techniky bývá kvalitnější produkt.

Rozdíly mezi agilní metodikou a technikou:

• Agilní metodika se zaměřuje na organizaci práce bez ohledu na to, zda se ve firmě vyvíjí software, nebo se jedná o jinou oblast, kde lze agilní řízení uplatnit.
• V agilní metodice je kladen důraz na možnost změny, agilní technika nic takového nevyžaduje.
• Agilní metodika se týká nejen vývojářů, ale i managementu.
• Agilní technika je konkrétní činnost (především vývojáře, může se ale týkat i například klienta).

Agilní metodiky i agilní techniky historicky vycházejí z Agile Manifesto. Tento manifest vznikl na bázi dlouholetých zkušeností špičkových vývojářů, analytiků zdola nahoru. Tedy managementu navzdory. Přesto se postupy z něj vycházející osvědčily, protože řeší následující problémy:

• Ubude práce manažera a tým přitom zlepší svou výkonnost. Jeden manažer je schopen uřídit více zaměstnanců, větší produkt, nebo se více zaměřit na kvalitu. Ať už je to povahou sebeřízení, tím, že se nepíší mrtvé dokumenty nebo tím, že manažer má stejně v průběhu iterace omezené pravomoci.
• Je předem známo, kolik práce je tým schopen udělat (v časovém rozsahu jedné iterace). To proto, že z minulosti je známo, jaká je rychlost v jednotlivých iteracích. Protože se zároveň dělají časové odhady na co nejkratší úkoly, je možné řídit rychlost týmu.
• Změny zadání za běhu (což je například pro klasický Waterfall model naprosto neřešitelný problém)
• Zrychlení doručování produktu od vývojáře k zákazníkovi (protože klientovi produkt doručujete po každém běhu – zákazník se navíc často účastní běhu firmy)
• Garance kvality (pomocí automatizovaných testů)
• Odstranění třecích ploch mezi produktem a vývojáři.
• Omezení rigidních procesů ve prospěch komunikace (jakkoliv Agile proti dobře nastaveným procesům nejdou – pouze omezují ty procesy, které brání efektivitě, komunikaci a agilnímu přístupu k práci)

Fáze celého projektu v agilních metodikách

1. Nultá iterace – první krátká analýza a naprogramování nějaké základní činnosti. V agilním týmu nejde příliš o to, co se v této části bude implementovat. Podmínkou je, aby na konci byl hotový kousek aplikace, který se dá předvést (tedy i klientovi).
2. Analýza změny (výběr toho, co se bude implementovat, analýza a designování změn).
3. Samotná implementace požadované vlastnosti (či vlastností).
4. Předvedení klientovi.
5. Pokud není produkt hotov, zpět na bod 2.
6. Pokud ano, následuje údržba, rozvoj (rovněž v iteracích).

Body 2–4 se označují jako jedna iterace. Tyto body se opakují tak dlouho, dokud není vývoj ukončen (úspěchem, odložením projektu, proto, že dojdou peníze, změnou priorit klienta).

Fáze jednotlivých iterací

Jak jsme si uvedli v předchozím textu, samotná iterace se skládá z analýzy, implementace a předvedení klientovi, přesně v tomto pořadí. Nyní si jednotlivé iterace rozebereme, protože právě v nich tráví tým nejvíc času.

Analýza změny

V této fázi dostane analytik (nebo celý tým) k dispozici priority klienta pro další iteraci. Právě v tuto chvíli se rozjíždí analýza. Někdy se předem ví, co se bude vyvíjet příštích několik iterací nebo zůstaly nedokončené práce z předchozí iterace. Pak se smí zohlednit i úpravy pro lepší kompatibilitu s dalšími změnami. Je stanoveno, které práce se mají provést.

V této fázi se používá velmi často prototypování, aby se vyjasnilo, jak má vypadat výsledek. Analytici (a programátoři) upravují model tak, aby vyhovoval změně. Rovněž se připravují akceptační testy, změny datových modelů, úpravy a přidávání (či mazání) logiky, úpravy pomocných knihoven atd. Samotná analýza sice nezabere příliš mnoho času, ale nemělo by se kvůli ní příliš otálet. (Pro případného zájemce o hlubší informace je vhodná např. přednáška Scotta W. Amplera, pravděpodobně největšího guru agilních metod, na IANA Local Conference 2007)

Implementace změny

V této části se plně uplatňuje samořízení týmu. Rolí manažera je pravidelně kontrolovat plnění úkolů, komunikovat změny do další iterace, odstraňovat problémy, které brání vývojářům při práci. Agilní přístup roli manažera zásadně omezuje na rovnocenné postavení s týmem, kde všichni společně pracují na jedné věci, a to na dodržení obsahu na čas.

V této části má manažer méně nutné práce s týmem. Zároveň je tato sekce nejdelší. Týmy jsou často tak dobře sebeřízené, že se dokonce role manažera redukuje na 1 hodinu denně (a to tehdy, kdy manažer zastává jednu z přímo zainteresovaných rolí – sebeřízení, přistoupí-li klient na platby za iteraci, může vést k tomu, že je manažer v týmu nadbytečný).

Předvedení zákazníkovi

Pravidlem je, že zákazníkovi se ukazuje pouze skutečně dokončená práce, všechny nehotové vlastnosti se musí skrýt z grafického rozhraní pryč. Zákazník tedy musí mít před sebou viditelné změny (když ne změny v rozhraní, pak se může například jednat o urychlení aplikace apod.). O všech nedodělcích tedy zákazník ví. V této části by měl zákazník zhodnotit změny za daný běh a vybrat, co se bude implementovat dál.

V příštích dílech se podíváme podrobněji na metodiku Scrum, na metodiku Getting Real a na některé Agilní techniky.