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.