Az előző részben (itt) írtunk a Scrum Projektekkel kapcsolatos legfontosabb tudnivalókról, a terminológiáról és röviden arról is, hogy hogyan is néz ki nagy vonalakban egy tervezés. Most egy olyan témáról fogunk írni, ami önmagában megérdemel egy külön bejegyzést: A becslés.

Minden projekt életében előbb-utóbb eljön az a rettegett pillanat, amikor a fejlesztőcsapatnak becsülnie kell egy feladatot vagy egy projektet. A fejlesztők jellemzően nem szeretik, mert sokszor úgy kell ezt megtenniük, hogy a projekt maga, és így a feladat is alul-definiált, a menedzserek meg azért nem szeretik, mert végtelen fejfájást okoz a becslések jellegükből eredő pontatlansága és később azok betartása.

Legyen szó bármilyen jellegű projektről, a kivitelezőnek mindig meg kell becsülni, hogy a rájuk bízott feladatok mekkora idő és / vagy energia befektetésével járnak majd. Ez így van a szoftverfejlesztésben is. A becslés maga teljesen független a használt munkamódszertől, agilis és hagyományos környezetben is elengedhetetlen része a szoftver-fejlesztésnek. Mindössze arról van szó, hogy csak a használt mértékegységek és a technikák különböznek a módszereken belül.

Tradicionális vízesés modellben általában a projektek modulra, szerencsésebb esetben munkacsomagokra (work package) bontását követően a fejlesztőcsapatok órában vagy napban becsülik meg a feladatokat, amelyeket ezután külön-külön összeadnak és így jön ki egy összesített óraszám, amit kommunikálni lehet a menedzsment felé vagy megrendelő esetén értékesíteni. Ennek eggyel jobb verziója, amikor a fejlesztőcégnél elég érett projekt menedzserek dolgoznak és használnak például Critical Path technikát (A becslési technikákról szóló bejegyzésünkben erre még visszatérünk) a projekt lefolyásának modellezésére, kalkulálva az erőforrások elérhetőségével, egy-egy feladaton lévő float-al és úgy általában a feladatok egymáshoz való viszonyulásával. Ha az adott csapat még használ 3 pontos becsléseket és vizsgálnak Béta eloszlást is, az pedig már maga a mennyország. Ezeknek a legfőbb problémája, hogy rengeteg munkát és időt igényelnek mind a menedzsment részéről, mind a fejlesztőcsapat részéről, illetve a megrendelőnek is nehéz átadni, ezért sokszor ezek a technikák idővel elkopnak és maradnak a tarthatatlan és pontatlan becslések.

A Scrum ezzel szemben egy másik megközelítést használ. A becslést a Scrum csapatok nem órákban készítik el, hanem a Scrum esetén a feladatok párhuzamára szolgáló story-kat ún. story pontok-ban (SP) becsülik meg. A különbség a hagyományos órában / napokban való becsléssel szemben, hogy a csapatoknak nem azt kell megbecsülniük, hogy egy-egy feladat elkészítése mennyi időt vesz igénybe, hanem azt, hogy mennyi erőfeszítést igényel majd a feladat egy másikhoz képest. A story pontok így inkább egy relatív mértékegységként fogják megmutatni, hogy nagyjából mekkora befektetést igényel a csapat részéről a feladat elvégzése. Lényegében egy absztrakcióról van szó. Ez önmagában mind szép és jó, de minden cég pénzből él és a story pontokat nem lehet direktben átváltani pénzre, azaz időre. (Hiszen az idő = pénz). Ahhoz, hogy az agilis módszertanok mentén működő cégek ezt át tudják váltani időre, ahhoz egy másik mértékegység is szükséges, mégpedig az előző részben kifejtett csapatsebesség (velocity). A csapatsebesség adja meg, hogy egy sprint alatt az adott csapat mekkora kapacitással rendelkezik és ebből kifolyólag hány story pontot tud elvégezni. Ez már egy sokkal értelmezhetőbb metrika arra, hogy az adott csapat egy előre meghatározott időintervallumban (Scrum esetén általában 1-2-4 hét) mit tud elvégezni. Ha egy megrendelőnek azt mondjuk, hogy az adott feature 13 story pont az nem mond semmit, de ha már azt mondjuk neki, hogy egy 2 hetes sprint alkalmával 5 darab ilyet tud megcsinálni a csapat, az már sokkal közelebb áll egy ember gondolkodásához.

Nagyon fontos megjegyezni, hogy a story pontok és az idő között semmiféle összefüggés sincs! Ebbe a hibába rengeteg kezdő fejlesztőcsapat beleesik. Ugyanakkor az is igaz, hogy valamilyen formában az idő akkor is belekerül a becslésekbe, de ezt inkább a következő képzeletbeli beszélgetés illusztrálja a legjobban két fejlesztő között:
„Lehet, hogy neked 4 óra, nekem meg 8 óra megcsinálni ezt a feladatot, de mindketten egyetértünk abban, hogy az eddig becsült feladatokat figyelembe véve ez egy 13 story pontos feladat.”
Scrum esetén a story pontok előre meghatározott értékkészletből dolgoznak és jellemzően egy módosított Fibonacci sorozatot használ, így az értékkészlet a következő számokból áll: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Ezekkel a számokkal a fejlesztőcsapat képes kompenzálni a projekt komplexitásából és a várható erőfeszítéssel kapcsolatos bizonytalanságokra, amelyet a fenti beszélgetés ismét jól illusztrál. Itt is igaz az, hogy minél nagyobb a becsült SP egy adott story-ra annál magasabb a bizonytalanság és ebből eredően a kockázat. Ezekben az esetekben további kifejtést vagy felbontást igényel a feladat.

A becslés pontossága

Az emberek sajnos, nem jók a becslésekben (a jóslásban pedig még rosszabbak), ezért az, hogy mennyire pontos a becslés már önmagában is nehezen megfogható. Ez viszont nem jelenti azt, hogy nem kell törekedni rá, hiszen rengeteg technika van arra, hogy ezt a problémát hogyan hidaljuk át.
Amikor becslések pontosságáról beszélünk általában 3 szintet különböztetünk meg, amelyek növekvő sorrendben a következőek: Nagyságrendi (Rough Order of Magnitude), Előzetes (Preliminary) és Végső (Definitive). Ezeket tudományos körökben sorrendben 1-5ig osztályozzák, de fordított sorrendben. Tehát a magasabb szám az alacsonyabb pontosságot jelöl. Ebben a formában az 5. osztályú becslés a nagyságrendi becslés és így tovább. Általában a 3. osztályú előzetes becslés már elegendő ahhoz, hogy budgetet lehessen számolni belőle, főleg azért is, mert általában a projekt elején még alacsonyabb definiáltsági szint is várható, ez lényegében elkerülhetetlen. Ezt az alábbi ábra szemlélteti.

Bizonytalansági kúp

Ezen az ábrán kiválóan látszik, hogy az idő előre haladtával csökken a bizonytalanság, és növekszik a becslések pontossága.
A legtöbb projektnél viszont jellemzően nincs idő eljutni az 1. osztályú becslésekig és nem is célszerű, hiszen az ehhez szükséges projekt-definiáltsági szintet már csak akkor szokták elérni a csapatok, amikor már közel készen van a projekt – vagy legalábbis a munka egy elég jelentős része már elkészült.
Scrum esetén egy relatív méretezésről beszélünk. Amikor becslések pontosságáról van szó sokkal egyszerűbb egymáshoz képest viszonyítani a feladatokat. Ez főleg akkor igaz, amikor nem tudjuk pontosan, hogy egy feladat pontosan mekkora csak sejteni tudjuk. A story pontok pontosan erre a problémára adnak megoldást, mivel az értékkészlet előre definiált, így nagyon rövid idő alatt kialakul a csapatban, hogy egy adott story mekkora volument képvisel, és ezután egymáshoz is lehet őket hasonlítani. Pl. ha egy regisztrációs oldal létrehozását 13 pontra becsülte a csapat, akkor egy kosár oldal működésének a létrehozásánál juthat arra a csapat, hogy nagyjából 2-3-szor akkora, így a módosított Fibonacci sorozatban a 40 van hozzá a legközelebb. Egy jó tanács az ilyen esetekre, hogy érdemes a projekt elején kiválasztani egy olyan story-t, amiről tudja a csapat, hogy pontosan mekkora (mert már többször is megcsinálták, és pontosan tudják) és ahhoz viszonyítani a többi feladatot is a kezdetekben.

A story pontok jellemzően három aspektust vesznek figyelembe:

  • Komplexitás: Biztos benne a csapat, hogy meg tudja oldani, de még akkor is ki kell találniuk.
  • Erőfeszítés: Ez lényegében a feladat nagysága. Hiába tudja a csapat, hogy pontosan mit kell csinálni, akkor is még meg kell csinálni és ez időbe telik.
  • Bizonytalanság: Ezek azok a dolgok, amiket nem tud a csapat, vagy esetleg csak sejt, de nem tud pontosan. A projekt előre haladtával ezek eltűnnek vagy ha nem kezelik őket megfelelően, ezekből lehetnek a projekt kudarcok.

Ahogy a bejegyzés elején említettük a Scrum esetén a becslés következő lépcsője a csapatsebesség megállapítása. Kezdő vagy frissen összeállt csapatoknál ez sokkal nehezebb, mint a már régóta együtt dolgozó csapatoknál, mivel az előbbi esetben még nem állnak rendelkezésre historikus adatok. A legegyszerűbb módszer a „tegnapi időjárás” (Yesterday’s weather) technika, aminek a lényege, hogy az első pár sprint során egy intelligens becslést kell tenni a csapat várható sebességére, és aszerint bevállalni a feladatokat, és az első 3 sprint végeztével egy átlagot vonni az eredményekből. Az így kapott eredmény lesz a csapat sebessége. Érdemes ezt a technikát akkor is használni, ha a már összeszokottabb csapatokról van szó, mert az idők folyamán változhat a csapatok sebessége, hiszen rengeteg tényezőből tevődik össze.

Összegzés

Mindent összevetve nem létezik tökéletesen pontos becslés, és valamilyen szinten kontra-produktív is erre törekedni. Minden csapatnak ki kell választania egy olyan technikát, amelyről úgy gondolja, hogy működik és ezt az technikát fejleszteni és folyamatosan felülvizsgálni. A csapatok így folyamatosan javítani tudják az ezzel kapcsolatos tudásukat és építeni a historikus adataikat, annak érdekében, hogy később egy hasonló feladat esetén már pontosabban lássák, hogy mekkora erőfeszítést fog igényelni. A következő részben ezekről a becslési technikákról fogunk írni mind vízesés mind Scrum oldalról.