Az agilis világban gyakran találkozunk azzal a kifejezéssel, hogy becslés, vagy esztimáció. De mit is takar ez valójában? Mire jó és mire nem jó? Az alábbi cikkben Gellényi Ákos ezeket járja körül.

Amikor azt halljuk fejlesztés során, vagy bárhol az agilis világban, hogy becslés, nagyon sokszor asszociálunk a story pontokra, és a Scrumra. Gyakran halljuk azt a felvetést, hogy mivel „Scrumban dolgozunk, ezért a storykat pontozni kell”. Ez a gondolat viszont többszörösen is téves. Egyfelől a Scrum Guide-ban nem szerepel sem a User Story, sem a becslés fogalma. Következésképpen a story pontozás sem. A Story, és annak pontozása egy Extreme Programming elem. A másik ok, amiért a fenti felvetés hibás, az az, hogy nincs olyan az agilis világban, hogy bizonyos feladatokat, storykat kötelező lenne megbecsülni. Ez pusztán egy lehetőség, ami jól használva sokat tud segíteni.

Mire való a becslés?

De akkor mi is tulajdonképpen a becslés célja? Legyen szó User Storyról, feladatról, vagy bármi egyébről, a becsléssel első sorban a célunk az, hogy az adott dolgot, amiről beszélünk, jobban megértsük.

„De hát ebben nem segít, hogy megtippelem a méretét…”

Valóban, a méret megtippelése nem segít. Viszont a becslés a tanulásról szól, hogy beszélgessünk a storyról. (Az egyszerűség kedvéért storykra fogok hivatkozni a későbbiekben.) Az egyikünk azt mondja, ekkora, a másik azt, hogy akkora a story mérete, és máris látható, hogy valamit még legalább az egyikünk nem jól ért. Ekkor kicsit mélyebbre ásva ki fog derülni a beszélgetés során, hogy hol látjuk még máshogy a feladatot, ez hozzá fog segíteni minket ahhoz, hogy jobban megértsük, mivel is állunk szemben. Ilyenkor mindenki elmondja, hogy miért akkorának látja a feladatot, amekkorának, és ki fog derülni, hol van az eltérés. Hasznos lehet az is, hogy elővegyünk egy referencia listát, olyan storykat, amiket már leszállított a csapat, értjük őket, és utólag is egyetértünk méretüket illetően.

A becslés szempontjai

Ami nagyon fontos, hogy általában relatív becslésről beszélünk, azaz nem egzakt módon megmérjük a story méretét (pl. Időben), hanem egymáshoz viszonyítjuk őket. Ennek több oka is van. Az egyik, hogy mivel a beszélgetés által a story jobb megértése a cél, nem pedig az, hogy tűpontos leszállítási vállalásokat tegyünk, ez sokkal egyszerűbb, gyorsabb. Nem is tudunk tűpontos vállalásokat tenni, hiszen az agilis fejlesztés során jellemzően olyan dolgot hozunk létre, aminek az újdonságtartalma igen magas. Tehát nem tudjuk megmondani pontosan, hogy mennyi ideig fog tartani a munka, ráadásul az is befolyásoló tényező, hogy ki, vagy kik dolgoznak rajta. Ez nem futószalag.

A fentiekből következik, hogy az erőfeszítésre koncentrálunk, nem pedig a szükséges időre. Így előtérbe kerül a komplexitás, valamint a kockázatok feltérképezése.

Nem metrika

A becslésből kiválóan tudunk alkotni olyan mutatót, mely megmutatja a csapat aktuális sebességét. Nagyon lényeges, hogy ennek oka elsősorban az, hogy a csapat a saját munkáját értékelje. Valamint előrejelzést tudjon adni egy jövőbeli értékszállítás várható idejére. Kulcsfontosságú azonban, hogy a szervezetben azok, akik látják az előrejelzést, ne vegyék készpénznek. Hiszen a korábban említett magas innovációtartalom miatt nem lehet mindig tökéletes előrejelzést adni. Ami itt a vezetők szerepe, hogy ha egy csapat az előrejelzései alapján jelzi, hogy támogatásra van szüksége, akkor ez alapján döntést lehessen hozni a beavatkozást illetően.

Közeli élményem, amikor egy általam támogatott csapat az előrejelzései, becslései és backlogja alapján azt jelezte a vezetőségnek, hogy a korábban egyeztetett értékszállítást az eredeti határidőre nem tudják elvégezni. Mivel számokkal alátámasztották a mondandót, a vezetés egy napon belül megbeszélést tudott szervezni a szükséges stakeholderekkel. A másfél órás egyeztetés végére megállapodott a csapat és a megrendelő, hogy mi az, ami az eredeti tervből elhagyható, annak érdekében, hogy a legfontosabb elemek szállítása ne kerüljön veszélybe. Az agilis gondolkodás, és a hozzá társuló módszerek segítettek, hogy időben tudjon a szervezet cselekedni, a megrendelő elégedett maradhatott, a csapat pedig megspórolt magának egy rakás, felesleges stresszt.

Másik tipikus hiba, ha a becslésekre alapozva elvárást tűzünk ki a csapat elé, miszerint gyorsulniuk kell a szállításban bizonyos mértékben. Relatív méretekről lévén szó, egy ilyen elvárást nagyon könnyű hamisan kielégíteni, hiszen amit eddig 1 egységre becsültem, az holnaptól lehet 2 egység, és máris megvan a kitűzött cél. Éppen ezért sosem szabad az ilyen jellegű becslésekből célmetrikát kreálni. A kitűzött üzleti céloknál a becslés pusztán segít megmutatni, hogy jó úton járunk-e.

Egy későbbi cikkben kitérünk arra is, hogy milyen becslési technikák léteznek, melyiket mikor érdemes alkalmazni, milyen egyéb csapdákba futhatunk bele.