Webtown blog

Gondolataink cikkekbe rendszerezve

null Hogyan kerüljük el, hogy az agilis szoftverfejlesztés káoszba forduljon?

Lázár Gábor

Hogyan kerüljük el, hogy az agilis szoftverfejlesztés káoszba forduljon?

Mit tudunk tenni annak érdekében, hogy például a SCRUM keretrendszer szerint szervezett szoftverfejlesztésünk ne forduljon káoszba? Nézzünk meg néhány technikát, amelyek segítenek abban, hogy magas szintű szervezettséget és ezáltal bizalmat tudjunk kialakítani.

Az agilis szemléletben szervezett szoftverfejlesztésekkel szemben az alábbi kritikák szoktak elhangzani.

  • nincsenek tervek, amelyek számonkérhetők

  • túlságosan lazák az együttműködési keretek

  • nem lehet tudni mi mikorra fog elkészülni, nincsenek határidők

  • senki nem vállal felelősséget

  • nem lehet előre tudni, hogy mi mennyibe fog kerülni

Valóban ilyen egy agilis szoftverfejlesztés?

Mivel az agilis keretrendszerek a kevésbé előíró “módszertanok” közé tartoznak, így valóban könnyen káoszba lehet taszítani egy agilis szemléletben szervezett szoftverfejlesztést.

Őszintén szólva azt hiszem, hogy nincs olyan keretrendszer, módszertan, vagy megközelítés, amelyet ne lehetne káoszba fordítani. 

Mit tudunk tenni annak érdekében, hogy például a SCRUM keretrendszer szerint szervezett szoftverfejlesztésünk ne forduljon káoszba? Nézzünk meg néhány technikát, amelyek segítenek abban, hogy magas szintű szervezettséget és ezáltal bizalmat tudjunk kialakítani.

Release stratégia

A release stratégiában jellemzően két megközelítést szoktunk alkalmazni a Webtown-nál.

A scope-driven release megközelítés arról szól, hogy meghatározható egy olyan szkóp, amely szétbontása nem életszerű. Ez azt jelenti, hogy az adott szkóp csak egyben életképes, csak egyben élesíthető. Ennek veszélye az, amikor a szkóp túlságosan nagy, így elveszítjük a sűrű release-elés lehetőségét, és a feedback loop-ok mérete drasztikusan megnő.

Azaz a scope-driven megközelítés rögzíti a szkópot a határidő meghatározása nélkül, és a fejlesztő csapat azon dolgozik, hogy ez a szkóp, ez a release mielőbb kikerüljön az éles környezetbe.

A date-driven release megközelítés esetén a release dátumát határozzuk meg, a szkópot pedig nem. Ebben az esetben a fejlesztő csapat motivációja az, hogy a lehető legtöbb fejlesztés bekerülhessen az adott release-be.

Több esetben figyeltünk meg olyat, hogy egy termékfejlesztés során változik a release stratégia, és az adott projekt adott életciklusára jellemző elvárások szerint váltottunk megközelítést.

Keretek követése

Az agilis termékfejlesztésnek sincs elapadhatatlan pénzügyi forrása. Az agilis projektekben is fontos, hogy pénzügyi kereteken belül maradjunk. Mivel az iterációk végén működő szoftvert szállítunk, melyek ráfordítása tény adatként áll rendelkezésünkre, pontos adataink lesznek ahhoz, hogy minden iteráció végén tisztában legyünk a rendelkezésre álló pénzügyi keret állapotával kapcsolatban.

Az agilis projektekben elérhető folyamatos szállítás, illetve a transzparens folyamatok lehetővé teszik, hogy a pénzügyi kereteket az első pillanattól kezdve nyomonkövethessük.

Célszerű egy kapacitás allokációval elindulni. A rendelkezésünkre álló forrásokat osszuk szét epic szinten. A mértékegység teljesen mindegy: lehet storypoint, embernap, vagy pénzösszeg; ez magát a technikát nem befolyásolja. Az ilyen típusú allokáció nem más, mint az egyes epic-ek súlyozása. Az allokációt megtehetjük ROI alapján, de akár relatív méretezés szerint is.

Miután elindul a fejlesztés, minden iterációt követően vezessük vissza a források tényleges felhasználását epic szinten. Ha nem iterációkban dolgozunk, akkor válasszunk ki egy tetszőleges, de rövid időszakot.

Ha ezt megtesszük folyamatosan lesz egy képünk arról, hogy hol tartunk a forrásaink felhasználásában. Ezen információk alapján priorizálni tudunk a product backlogban, követelményeket tudunk átgondolni, riportokat tudunk készíteni, azaz folyamatosan kezünkben tudjuk tartani a pénzügyi kontrollt, és döntéseinket ezek alapján tudjuk meghozni. 

Roadmap

Hozzunk létre roadmap-et, amely szerint vezérelni szeretnénk a termékfejlesztés, a termékverziók kiadását. A roadmap lehetőséget teremt számunkra, hogy a termékfejlesztésben résztvevőket célon tartsuk, hogy minden érintett tisztában legyen azzal, hogy mikor mit szeretnénk elérni. 

A roadmap nem egy végletekig kidolgozott szkóp és határidők gyűjteménye. Mint ahogy azt sem mondhatjuk, hogy a roadmap biztosan nem fog változni a termékfejlesztés során.

Minden iterációt követően validáljuk, mérjük vissza, hogy az előzetes terveink megfelelnek-e a valóságnak. A magasfokú transzparenciának köszönhetően egy agilis projektben nagyon gyorsan kiderül, ha a kialakított roadmap nem tartható, így szinte azonnal tudunk reagálni, döntéseket meghozni.

Kisméretű backlog elemek

A tervezési és a megvalósítási kockázatok csökkentését segíti, ha kisméretű backlog elemek mentén fejlesztjük a terméket. Ha a tervezési és a megvalósítási kockázat csökken, akkor csökken a pénzügyi kockázat is, illetve megnő a tervezhetőség szintje.

Kisméretű backlog elemekből kisebb release-ek állíthatók össze, így megnő a termékfejlesztésünk alkalmazkodóképessége azzal, hogy több release-t fogunk tudni kiadni és azokat gyorsabban tudjuk visszamérni.

Product Owner-ként eszünkbe juthat az INVEST.

Az INVEST egy acronym, mely egyike azoknak a technikáknak, amelyet Mike Cohn a “User Stories applied” című könyvében javasol.

Az INVEST-ben az S azt jelenti, hogy elég kicsi a backlog elem ahhoz, hogy a DEV team egy iterációban be tudja fejezni.

Elegendő-e csak erre figyelnünk? Nem feltétlen!

Mike Cohn könyve alapján:
A good user story should be:

  • “I” ndependent (of all others)

  • “N” egotiable (not a specific contract for features)

  • “V” aluable (or vertical)

  • “E” stimable (to a good approximation)

  • “S” mall (so as to fit within an iteration)

  • “T” estable (in principle, even if there isn’t a test for it yet)

Ha a DEV Team sebessége 20 storypoint, akkor egy 20 storypoint méretű backlog elem megfelel az INVEST-nek, viszont ekkora backlog elem már jelentős becslési bizonytalanságot is tartalmazhat, melyet érdemes lehet mérlegelni és kezelni azzal, hogy tovább bontjuk. Így csökkenthetjük a kockázatot és növelhetjük a tervezhetőséget.

Konzisztens relatív becslési képesség

Amennyiben a SCRUM Team becslést használ méretezésre, akkor szükség van egy konzisztens becslésre, becslési képességre. Mit jelent ez? Vagy mit nem? 

Nem jelenti azt, hogy a DEV Team pontosan becsül. Nem ezen van a hangsúly! A hangsúly a konzisztens szón van. Azaz a DEV Team becslési kompetenciája és motivációja elég fejlett ahhoz, hogy relatív becslési technika használatával a hasonló méretű backlog elemekre hasonló becslést adjon a termékfejlesztés során. 

Amennyiben ezeket a technikákat alkalmazzuk, akkor jó esélyünk van arra, hogy az agilis szemlélet a termékfejlesztés előnyére és nem hátrányára válik. A termékfejlesztésünkre a szervezettség és a tudatosság lesz jellemző, melyek segítségével komoly bizalmi tőkét tudunk létrehozni és fenntartani.

Kapcsolódó tartalom: