Amikor egy cég átáll az agilis módszertan szerinti működésre, mindig a komplett cégre vonatkozóan találnak ki szabályokat, amelyeket mindenkinek be kell tartania. Ritkán van rá lehetőség, hogy azokat adott projektre, csapatra lehessen igazítani. Az egyik ilyen általános agilis szabály, hogy az elkészült fejlesztéseket még az adott sprintben le is kell tesztelni – így lesz az elkészült fejlesztés teljes értékű a végfelhasználók számára.
Történt mégis, hogy amikor tesztelőként csatlakoztunk egy szoftverfejlesztőkből álló csapathoz, ők már régen beálltak a kéthetes sprintekre. Több éves tapasztalatuk volt arról, mennyi fejlesztés fér bele két hétbe – a tesztelők meg dolgozzanak, amikor akarnak, a végfelhasználók felé úgyis csak félévente, évente adtunk ki új verziókat (nesze neked agilitás).
Semmi gond, mi tesztelők rugalmasan beálltunk egy követő stratégiára, amikor az adott sprintben mindig azt teszteltük le, amit a fejlesztők az előző sprintben alkottak. Tegyük hozzá: részletesen dokumentált és rendszeresen demózott fejlesztésekről beszélünk – könnyen le tudtuk követni, hogy mi történik.
Módszertanilag nyilván vitatható, de a valóságban ez a követő stratégia nagyon jól működött. Ugyanis, ha a tesztelést mindenáron be akarjuk nyomorítani az azonos sprintekbe:
- az addigi tapasztalatok (mennyi fejlesztés fér bele egy sprintbe) elvesznek, de legalábbis lényegesen módosítani kell a tervezésen
- a fejlesztési vezetőnek a tesztelőket is felügyelnie kell („befejeztétek már?!”), és ez egyikünknek se hiányzott.
Úgyhogy a cégben kötelező agilitást a végfelhasználók érdekeit nem csorbítva, rugalmasan a csapat igényeire szabtuk. Igaz, ezt főleg azért tehettük meg, mert a fejlesztő csapat már régóta dolgozott az egyik külföldi központnak, és amíg jó munkát végeztek, addig se innen, se onnan nem szóltak bele olyan profán kérdésekbe, mint a munkaidő, a home office vagy az agilis módszertan precíz alkalmazása…