Novinky

Na projektu pro nového klienta, který jsem dostal přidělený, bylo „jasné“ zadání: do půl roku musí fungovat nová JAVA aplikace, kdy její čtyři části mají přesně stanovené milníky předání (navázáno na business zákazníka). Rámcový odhad projektu byl v řádu stovek MDs, s termíny nebylo možné hnout, neexistovala analýza a návrh řešení a času ubíhal.

S ohledem na tyto okolnosti jsme se interně rozhodli využít některých prvků agilního vývoje. To znamená, že jsme se neřídili čistě agilní metodikou (SCRUM, XP, …), ale využívali jsme některé obecné body, které se nám jevily jako vhodné s ohledem na přísné termíny a vágní úvodní zadání. Mezi vybrané prvky patřilo:

• Scope jednotlivých etap rozdělený na epicy a ty dále na tasky
• Paralelní analýza a vývoj
• Denní stand-upy
• Týdenní plánování a „sprinty“
• Celý tým v jedné místnosti
• Co tři týdny demo klientovi

Zasmluvnění v režimu FTFP celého projektu bylo provedeno až po ukončení vývoje první etapy a před jejím předáním k akceptačnímu testování klientovi. Díky odloženému zasmluvnění a intenzivní komunikaci s klientem v průběhu realizace se podařilo získat přesnější povědomí o pracnostech a rozsahu prací jednotlivých oblastí, což umožnilo realističtěji nacenit celý projekt.

Pozitiva

• Celý tým měl přehled o vývoji na projektu, kdo na čem dělá a jaké má problémy
• Rychlé reakce na paralelní běh analýzy a programování
• Změnové požadavky oproti původnímu rámcovému scope se zapracovávaly v průběhu detailní analýzy a nebylo třeba na každou změnu vypisovat change-request

Nevýhody plynoucí ze zvoleného přístupu

• Vyšší administrativní náročnost (denní standupy a zvýšená komunikace mezi členy týmu)
• Občasné programové úpravy v již hotových částech kódu (díky nekompletní analýze před zahájením programování se někdy musely upravit již existující části kvůli vazbám, které dříve nebyly zřejmé)
• Krátká délka sprintu (v rámci sprintu se většinou vyvinuly funkcionality; ty se v dalším sprintu testovaly a opravovaly chyby, tzn. většina úkolů byla otevřená přes dva sprinty).

Díky získaným zkušenostem hodnotím rozhodnutí zvolit některé prvky agilního vývoje místo klasického waterfallu jako velice přínosné, které umožnily dodat klientovi v uvedeném termínu to, co skutečně potřeboval a méně důležité části bylo možné přesunout na později. V příštím podobném projektu bych se pokusil vtáhnout klienta víc do projektu, aby se účastnil denních stand-upů a měl širší povědomí o dění na projektu než jen z formálního týdenního statusu.