2 helyzet, amikor a priorizálás a segítségünkre siet
Akárhány év tapasztalat, akárhány sikeres projekt van a hátunk mögött, az alábbi két dolog a tesztelési fázisban mindig sokkhatást okoz. A különbség az, hogy egy idő után már tudjuk, hogyan kezeljük a problémát.
Amikor csapatunk átállt az agilis szoftverfejlesztésre eleinte sokat küszködtünk a teszteléssel. Sehogy sem fért bele az időkeretbe, sosem tudta felvenni a lépést a közben továbbrobogó fejlesztési folyamattal. Rájöttünk, hogy maguk a fejlesztők tehetik a legtöbbet a szoftver magas minőségéért, hiszen
- ha értik a fejlesztendő funkció pontos célját, jobb kódot írnak
- ha ők írják a teszteket is, ők a legelkötelezettebbek saját hibáik javításában, ha a teszt elbukik.
Ha minden user story-hoz elkészítjük magát a programkódot és az automatizált teszt kódot is, a tesztelés egy átláthatatlan ködfelhőből egy sprintbe tervezhető, kezelhető nagyságú feladattá válik.
Nem így történt az egyik projektünknél. Csak röviden: a fejlesztés 6 héten keresztül zajlott, amit a terv szerint 2 napnyi intenzív ügyféltesztelési nap követett, ami után 4 nap lett volna a hibák és egyéb apróságok javítására. A határidőt tartani kellett: maximum 3 nap késés volt a megengedhető az ügyfél részéről.
A megrendelő 2 nap alatt közel 200 hibát írt össze, ez sokkoló volt.
Hol követtük el a hibát? - kérdeztük magunktól.
- A dizájn és specifikáció részletekig kidolgozott volt, amit a megrendelő elfogadott.
- A fejlesztési folyamatba - mint mindig - finomhangolásokat iktattunk be, a megrendelő jelenlétével, ami már jól bevált szokásunk, hasonló előnyökkel jár, mint amikor a fejlesztők a fejlesztés után azonnal tesztelik az elkészült funkciót: az esetleges félreértések tisztázhatók, valamint a fejlesztő "még melegében" tud korrigálni, még nem haladt tovább más funkciók fejlesztésével.
Amint belenéztünk az ügyfél által készített hibajegyzékbe, kicsit árnyaltabb lett a kép.
1. Rengeteg hiba "blokkoló", azaz a szoftver kiadását (a release-t) gátolja
Egy félreírást is tekinthetünk persze blokkoló hibának, hiszen más lesz tőle a mondanivaló és olyan színben tünteti fel a brandet a publikum előtt, mintha nem figyelne oda a részletekre eléggé. De nem lehet egyszerre a kiadás dátumához és a hibák "blokkoló" státuszához is ragaszkodni egyszerre, hiszen úgy sosem jut el a piacra a szoftver. Az már nem agilis, ha 100%-os tökéletességre törekszünk az első kiadásnál. Éppen attól agilis egy szoftver, hogy addig dolgozunk rajta, amíg a felhasználó számára értékes és működőképes funkció előáll és utána útjára engedjük. A csiszolgatás marad későbbre, ha a felhasználói visszajelzésekből az derül ki, hogy az legalább annyira értékes, mint egy újabb funkció kifejlesztése.
2. Új igények jelennek meg
"Tulajdonképpen mi arra gondoltunk, amikor megbeszéltük azt, hogy...", "Ide jó lenne még egy..." és hasonló mondatok a kollégáknak ismerősök lehetnek, és azt kell mondjam, szinte nincsen olyan szoftver indítás, amikor az utolsó pillanatban a megrendelő ne próbálna meg új funkciókat kigyötörni a projekt menedzserből. Fontos látni, hogy ez nagyon rizikós, de értelme sincs akkor, ha agilis a fejlesztés, hiszen akár már a következő iterációban a szoftverbe kerülhet a hőn áhított új funkció.
Megjegyzések, hogy a továbbiak érthetőek legyenek:
a., Azok után, hogy az ügyféllel a Wrike nevű - Jira-hoz hasonló - ügy- és projektkövető eszközön keresztül folyt a komunikáció és együttműködés az első pillanattól kezdve, váratlanul ért minket és szintén sokkoló volt, hogy a hibákat Google Sheets-ben vezették fel. Hiába adtak hozzá státuszokat, prioritást, komment mezőket, wetransfer linkeket: a linkek lejártak, a komment folyamban követhetetlen volt, hogy ki mondott mit és mikor, éppúgy, mint a státuszok és prioritások változtatása. Máig nem értem miért volt erre szükség, amikor egy kiváló alternatíva állt rendelkezésre, amiért ráadásul súlyos havidíjat fizet az ügyfél.
b., Az ügyfél a hibákat "blokkoló", "magas", "normál" és "alacsony" prioritásokba rendezte, ezek így oszlottak meg:
Ahhoz, hogy tisztázzuk hol állunk most és miért állunk ott, egyeztetést kezdeményeztem az ügyféllel, ahol
- rávilágítottam, hogy azért terveztünk csak 4 napos tesztelési időszakkal, mivel a projekt kezdetén tisztáztuk, hogy több alkalommal is közösen (ügyfél és Grafikarma) tesztelünk és az ügyfél által akkor kért javításokat még annak melegében, a következő napokon végezzük el, és ezeket meg is tettük
- megjegyeztem, hogy az előbbiek fényében jogosan nem számíthattunk 200 hibára
- megjegyeztem, hogy az előbbiek fényében jogosan nem számíthattunk 28 db "blokkoló" hibára, hiszen az iterációs teszteken ezek biztosan előjöttek volna, de nem jöttek, így mi (~)0 db "blokkoló" hibára készültünk, ezért újra kell priorizálni az összes hibát
- megértettem, hogy a 4 napos (vagy a 4+3 napra kiegészített) határidővel sem javítható ki közel 200 hiba, a "normál" és "alacsony" prioritású hibák megoldására nincsen esély
- megértettem, hogy 4 nappal a tervezett élesítés előtt nem jelenhetnek meg új követelmények a dokumentumban, mert az csak szigorúan az élesítéshez elengedhetetlen feladatokat tartalmazhatja.
A megrendelő elfogadta az érveimet.
Már csak a megoldásra volt szükség, hogy a kitűzött éles indítási dátum tartható legyen, miközben a lehető legtöbb hibát orvosoljuk. Ez alapvetően a priorizálás. Ezért a következőket tettem:
- az összes "normál" és "alacsony" prioritású hibát kidobtam
- az összes "blokkoló" hiba számára egy külön munkaasztalt hoztam létre a Wrike-on belül, azaz megváltunk a Google Sheets-től, hogy az aktivitások és a folyamatos kollaboráció zavartalan legyen és ne emésszen fel extra erőforrásokat
- az ügyféllel átfutottuk, hogy a "magas" prioritású hibákból melyeket lehet leminősíteni, majd a maradékot a Wrike munkaasztalhoz adtam.
A munkaasztalra a 28+77 db hibából végül 74 db került, amiket a rendelkezésre álló 4+3 napban lezártunk, így a szoftver sikeresen elindult időben.
Szerző: Csaba 
Vezető fejlesztő, Product Manager