Fontos üzenet minden tréningünkön, hogy a módszertan testreszabását kerüljük, mert nagyon veszélyes tevékenység. Az üzenet mögött az a megfigyelés áll, hogy a leggyakoribb oka a testreszabásnak az, hogy a szervezetben van egy (vagy több) rosszul működő folyamat, és ezek megváltoztatása helyett próbáljuk ezekre faragni a módszertant. Az eredmény ilyenkor egész könnyen megjósolható: természetesen bukás lesz a vége. És természetesen ilyenkor a módszertant szokták okolni a bukásért…

A fenti fontos figyelmeztetés ellenére el kell ismerni, hogy igenis vannak olyan helyzetek, amikor muszáj testreszabni a módszertant. Ilyen eset, amikor szükségessé válik a release criteria bevezetése.

Ahogy korábban már kifejtettük a Definition of Done-ról szóló bejegyzésben, a D.o.D. azon közös feltételek gyűjteménye, amit minden egyes feladatnak teljesíteni kell a készség kimondásához. Lefordítva, a D.o.D. biztosítja a Scrum azon célját, hogy a sprint végén valóban “potentially shippable product increment”-ünk legyen, tehát valóban csak üzleti kérdés legyen, hogy tényleg kiadjuk-e a terméket. Technikailag kiadásra késznek kell lennie.

No ez nem megy mindig. Elképzelhető, hogy van a kiadásnak olyan feltétele, ami pénzben vagy időben túl drága ahhoz, hogy minden sprintben végrehajtsuk. Bizonyos területeken például a kiadás feltétele lehet egy független hatóság általi jóváhagyás, vagy különleges környezeti tesztek futtatása (hőkamrák, klímakamrák, fénytesztek, stb.). Ez utóbbi természetesen sokkal gyakoribb olyan környezetben, ahol hardware fejlesztés is történik.
Mivel tehát ezek az ellenőrzések drágák és sokáig tartanak, nem férnek bele a sprintbe. Így a definition of done részének sem tekinthetjük őket. Kell tehát egy lista, ahol azokat a feladatokat gyűjtjük, amiket a kiadás előtt muszáj végrehajtani, de nem tudjuk backlogelemenként, a sprint során elvégezni. Ez a lista lesz a Release criteria.

Szerencsés esetben ez a lista nem létezik. Ugyanis ha van, akkor sérült az a cél, hogy minden sprint végén kiadható termékünk legyen. Ilyenkor legyen legalább az cél, hogy minden sprint végén, kontrollált környezetben demozható termékünk legyen, hogy a feedback lehetősége továbbra is megmaradjon.
A release criteria létének másik veszélye, hogy a sprinten kívülre szoruló feladatok, tesztek, ellenőrzések rámutathatnak hibákra, amik így a folyamat késői pontján derülnek ki, tehát drágák lehetnek. (Emlékeztetőül: a scrum egyik nagy ereje, hogy a tesztelést nem külön fázisnak, hanem a fejlesztés részének tekinti, így gyors a visszajelzés tesztelés és fejlesztés között, és mivel rövid a feedback loop, a hamar felfedezett hibákat gyorsan és olcsón lehet javítani.)
Ezek miatt tehát törekedjünk arra, hogy:

• ne legyen Release criteriánk
• ha van, legyen a lehető legrövidebb
• folyamatosan törekedjünk arra, hogy a release criteria elemeit bontsuk, és minél nagyobb részben mozgassuk át ezeket a definition of done-ba.

Lassan fél éve, hogy belekezdtünk ennek a blognak az írásába, és heti-kétheti rendszerességgel jelentkezünk friss bejegyzésekkel az agilis módszertanokról. Fontos nekünk, hogy mit gondoltok a blogról, az írásainkról, ezért kérünk benneteket, hogy szánjatok egy fél percet az alábbi rövid kérdőív megválaszolására! Köszönjük!

Create your own user feedback survey

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!

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.

Egy egyszerű trükkről szeretnénk ma mesélni: egy másfajta standup meetingről.

A napi standup a Scrum leghíresebb - leghírhedtebb eleme; a mai napig vannak vezetők, akik úgy gondolják, hogy ha néhány ember minden nap 10-15 percre körbeáll egy táblát, amin cetlik vannak, akkor ők már agilisak. Annak ellenére, hogy a módszertan ennél jóval komplexebb, a napi meeting valóban fontos elem. És bár látszólag egyszerű, mégis nagyon sokan rosszul csinálják.

A Scrum 3.0-ban eszközölt változások egyikének célja pont a napi standup meeting “megjavítása”. Az a megfigyelés van mögötte, miszerint a legtöbb csapat státuszolásra használja ezt a beszélgetést. Nem ez az eredeti cél. A standup meeting egy tervező meeting, a legkisebb, leggyakoribb rendszeres csapatszintű tervezés helyszíne. Természetesen fontos része a státusz áttekintése, de a célja ennél több: a csapattagok együtt megtervezik, kinek mit kell aznap tennie azért, hogy a csapat (és a sprint) sikeres legyen. Emiatt a régi jól ismert három kérdést is átfogalmazták, és a hivatalos menetrend már így hangzik:

• Mit csináltál az előző meeting óta, amivel segítetted a csapatot elérni a sprint célját?
• Mit tervezel csinálni a következő meetingig, amivel segíted a csapatot elérni a sprint célját?
• Van-e bármi, ami akadályoz téged vagy mást abban, hogy elérjük a sprint célját?

Kicsit színpadias, talán erőltetett, mégis fontos és érdemes így feltenni a kérdéseket, mert sokat tud segíteni a megfelelő fókusz megtalálásában. A csapat feladata nem taskokat végrehajtani. A csapat feladata elérni a sprint célját, a sprint backlogba betervezett backlogelemek leszállításával. A taskok ennek kell alárendelve legyenek.

Megesik, hogy minden fókusz és 3.0-ás standup meeting ellenére a csapat botladozik. Sikertelen, nem készülnek el backlogelemek, kimaradnak taskok, stb… Valami baj van. Ilyen esetben szoktuk azt javasolni a csapatnak, hogy próbálják ki a “másik” standup meetinget. Mi Dexteresnek hívjuk, a szimpatikus sorozatgyilkos után, akinek kalandjain 8 éven át izgulhattunk, és dilemmázhattunk: vajon azért szurkoljunk, hogy elkapják végre, vagy azért, hogy ne?
Aki ismeri a sorozatot, tudja, hogy a főhős a rendőrségen dolgozik. Némelyik epizódban látni, hogy ők is napi meetinggel kezdik a műszakot. Nem a scrumos módon csinálják azonban; tehát nem csapattagonként beszélik át a helyzetet, hanem ehelyett az ügyeken mennek sorra, valahogy így:

• Mi a legnagyobb prioritású feladatunk?
• Elkapni a baltás gyilkost.
• És elkaptuk?
• Nem.
• Akkor ki mit fog ma tenni azért, hogy elkapjuk?
• …

Ugyanez a módszer bevethető egy Scrumban dolgozó development teamnél is. A sprint backlogban szépen sorra haladva, fentről lefelé megbeszélni, melyik backlogelem hogy áll, és ha nincs kész, akkor melyik csapattag miben tud segíteni, hogy minél gyorsabban (de persze pontosan, jól, …) elkészüljön a feladat.

Az a tapasztalatunk, hogy ezzel a módszerrel sokkal könnyebb teljes backlogelemeket szállítani. Kombinálni is lehet a két verziót: a sprint első felében elindulni a klasszikus formátummal, majd a második felében áttérni a Dexteresre. Próbáljátok ki!