Érdekes dolgot figyeltem meg az elmúlt hetekben, amit Vagabond kollégával való chatelésem közben el is neveztem story-point inflációnak. Más is biztosan megfigyelte már, de én tőlük függetlenül tettem ezt (egy ideje már látszott, de csak most gyorsult fel igazán) és beszélgettünk róla, így addig törtem a fejem, amíg leírtam ide.

A dolog lényege az,  hogy az ügyfélnél most van egy kis fennakadás a fejlesztés menetében, mert nagyon egy helyen dolgozik minden csapat és emiatt nehezebb a forráskódot jólfésült állapotban tartani és kissé lelassultunk. Előfordul az ilyesmi, de kicsit hosszabb ideje tart ez a lassulás és a vezetőségnek lépnie kellett valamit. Esetünkben az törpént, hogy kisebb storykkal dolgozunk és minden nap szeretnének látni 1-2-3 pontnyi haladást a chartokon, hogy visszatérjünk a régi kerékvágásba és termeljük be a pontokat ahogy kell. Mivel a lényegi problémákhoz nem lett hozzányúlva (túl sok dev dolgozik, túl kicsi részén az alkalmazásnak), ezért a fejlesztés továbbra is ugyanazzal a maximálisan elérhető sebességgel halad, amit így produkálni bírunk, de hamarosan ismét a megfelelő mértékre ugrott fel a velocity anélkül, hogy láthatóan gyorsult volna  a munka. Hogy miért? A megkövetelt extrateljesítmény arra késztette a deveket, hogy alkalmazkodjanak és inkább felülesztimálják a feladatot, minthogy túl kevés pontot hozzon egy napi munka. Azaz inflálódtak a pontjaink és már nem takarnak akkora bonyolultságot mint régen. Hogy mennyit változtak? Nos a képlet nagyon egyszerű:

Adott az elvárt pontszám: x(abszolút érték)

Adott a leadni képes teljesítmény: y(relatív érték)

Tehát az  infláció mértéke: x/y*100. Honnan tudjuk meg az y-t? Az első iterációk pontszámából, abból a fázisból, mielőtt bevezettük az új módszert és nem volt nyomás a deveken, hogy megadott mennyiségű pontot hozzanak. Ez az y persze csak arra az időszakra érvényes, ami két módszertani, fejlesztői környezet vagy egyéb változtatás közt eltelt. Minden ilyen változtatáskor újra kell számolni az első iterációk alapján, mert utána megint hozzáigazodik az elvárásokhoz. Minél tapasztaltabb csapattal dolgozunk, annál gyorsabban adaptálódnak

A magam részéről annyit fűznék hozzá, hogy ha jó a PM, akkor a devek teljesítménye körülbelül ugyanakkora minden iterációban (pár pontos kilengésektől eltekintve), ha nem nyúlunk a fejlesztői környezethez és koncepcióhoz. Ezt akármekkorára vágjuk vagy trükközzük, ugyanannyi marad. Ha mégis kevésnek gondoljuk, akkor meg kell találni azokat a pontokat, ahol az elakadás van, de semmiképp sem erőltethetünk az emberekre egy mesterséges munkatempót, mert hazudni fognak a főnökeiknek. Nem szándékosan persze, de attól még borulnak a grafikonok…

A történet tanulsága igen általános: sose próbálkozz felületi kezeléssel, hanem szánj időt arra, hogy kiderítsd a valódi okot.