Publikujeme

Nacházíte se zde: Úvodní stránka > Publikujeme > Blog > Očima projekťáka: Využití agilních prvků na projektu

Očima projekťáka: Využití agilních prvků na projektu

Očima projekťáka: Využití agilních prvků na projektu 123

Jak se popasovat se složitým projektem rychle a kvalitně, když zadání zní: 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). S termíny není možné hnout, neexistuje analýza a návrh řešení a čas ubíhá.

Sdílej na sociálních sítích:

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

Jako SW podporu jsme využili plug-in Agile v JIRA, kde jsme přehledně viděli stav jednotlivých úkolů/epiců ve sprintech, jejichž týdenní spouštění bylo provázáno se statusem klienta, kde se rozhodovalo, na čem se bude pracovat. Tímto přístupem jsme byli schopni rychle reagovat na připomínky a změny od klienta a v případě potřeby „čůrat, kde byl větší požár“.

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.

Autor: Petr Jančík

Přejít na začátek stránky

Mapa stránek

© Copyright 1998-2014 AMI Praha a.s., powered by AMIGO CMS