Közérthetően és őszintén az agilis módszertanokról

Agile blog

No partial credit

2016. április 27. - Bodó Árpád Zsolt

Fontos, de fájdalmas kérdés: mi legyen a sprint végén a “majdnem” kész feladatokkal? Valójában ez két kérdés: automatikusan bekerüljön-e a következő sprint backlogjába, és hogyan könyveljük a pontokat?

Az első kérdés egyszerűbb. Ami nincs kész, az visszamegy a product backlogba. Fontos kimondani, hogy - bár a valóságban az esetek 98% százalékában (mérnöki has alapján végzett becslés, nem hivatalos adat) valóban a következő sprintbe kerül majd - nem kerül át automatikusan a következő sprintbe. Ennek pedig az az oka, hogy egy tudatos döntést szeretnénk kicsikarni a Product Ownerből: kell-e még neki ez a backlogelem? Egyáltalán nem biztos. Elképzelhető például, hogy a céges weblapra húsvét alkalmából animált nyuszikat kellett volna rámolni, de sajnos nem lett kész a sprintben. Mivel a következő sprint már húsvét utánra esik, semmi értelme folytatni a feladatot, egyszerűen ki kell dobni.
Életszerűbb - bár szintén fiktív - példa lehet, ha egy agilis konferencia honlapjára a “call for paper” form nem készül el a sprintben, de a következő sprint végére már lejár a jelentkezési időszak. Így kidobjuk a feature-t, és marad az emailes jelentkezési lehetőség.
Ilyen esetben természetesen, a használt verziókezelő, stb. megoldástól függően még az is elképzelhető, hogy a kidobásnak lesz költsége, így a feature befejezése helyett annak kipucolása jelenik majd meg a következő sprintben, mint feladat.

No de mi legyen a pontokkal? A “majdnem kész” backlogelem eredeti becslése mondjuk 13 pont volt, a csapat úgy érzi, hogy még kb. 5 pontnyi van belőle hátra. Mennyit ér akkor a backlogelem abban a sprintben, ahol nem sikerült befejezni?
A cím sejteti a választ: semmit. Nincs részeredmény (“no partial credit”). A majdnem kész az nincs kész. Nem eladható, nem kiadható, tehát nem ér semmit.
Már csak azért sem, mert ahogy fent olvastuk, lehet, hogy soha nem is lesz a termék része.
De van egy másik fontos oka ennek a szabálynak: azért, mert ha betartjuk ezt a szabályt és sűrűn maradnak félbe nagyobb feladatok a sprintben, csúnya lesz a csapat velocity görbéje.

Nézzük meg a lenti két mintagörbét!

chart1.png

chart2.png

Bár a trend alapján mindkét csapat fejlődik, szépen növekszik a velocity-jük, a második ábra határozottan csúnya. A csúnya görbék pedig nagyon hasznosak, mert bántják a szemünket és arra késztetnek, hogy valamin változtassunk.
Bár egy metrikát mindig könnyű kiszépíteni valódi tartalmi változás nélkül, inkább egy másik utat javaslunk. A lépései:

  • No partial credit szabály bevezetése. Ami nincs kész, az nullát ér.
  • Velocity görbe figyelése. Ha sok a tüske, akkor hiába jó a trend, valami gyanús.
  • Derítsük ki, mi az oka, hogy a csapat sűrűn bukik el nagy feladatokat. Néhány lehetőség:
    • Túl nagyok a backlogelemek
    • Sok a külső függőség
    • Rosszul becsül a csapat
    • Rosszul ütemez a csapat
    • Rossz minőségűek a backlogelemek, sok részlet a sprintben derül ki
  • Szüntessük meg az okot.

A bejegyzés trackback címe:

https://agile.blog.hu/api/trackback/id/tr998661514

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása