I tre år har et Scrum-team udviklet på Saxo Banks community website TradingFloor.com. Undervejs er teamet gået fra en langsommelig release-proces til nul fejl og lige så mange releases, som forretningen ønsker.
En af de store udfordringer i Scrum er at finde ud af, hvad man stiller op med test. Udviklingen af websitet TradingFloor.com var ingen undtagelse. Scrum Master Brian Fischer fortæller:
”Før i tiden overdrog udviklingsteamet den afsluttede leverance til test, men når test-teamet havde gjort deres arbejde, tog det for lang tid at få resultatet retur til udviklingsteamet og få rettet fejlene.”
Dette hang blandt andet sammen med de klassiske testeres knapt så agile mindset. I Scrum er det ikke usædvanligt, at kravene ændrer sig lidt undervejs. Dermed ændrer produktet sig, inden testerne skal i gang, men en klassisk tester skal have meget præcise specifikationer for at kunne udføre sit arbejde. Brian Fischer og Head of IT WEB Kasper Fehrend havde derfor brug for en ny type tester.
”Ikke bare en tester, men en, der koordinerer, at forudsætningen for, at kvaliteten er i orden, er til stede. En, der går hen og snakker med udvikleren om, hvordan opgaven bliver løst, så han ved, hvordan den skal testes,” siger Kasper Fehrend.
Tidligere tænkte han, at testere skulle være et par friske øjne uden forudsætninger, der bare kunne lave test. Men det fungerede ikke. Erfaringen har vist, at det er meget vigtigt, at testeren selv kan skrive kode, så han forstår, hvordan produktet er blevet skabt.
”Det har været lidt af en erkendelse at nå dertil,” siger Kasper Fehrend.
4,5 times test på 15 min.
I dag er Kasper Fehrends testere dem, der ved allermest om applikationerne. Den nye tilgang til test har betydet, at teamet på 10 mand kun behøver én tester, hvor et team af den størrelse normalt ville have tilknyttet tre eller fire testere.
Udviklerne bliver dog også pålagt et ansvar for at sikre, at kvaliteten, de leverer, er høj nok til at kunne sættes direkte i produktion.
”Udviklerne skal selv teste, at deres feature er i orden. De skal ikke forvente, at der er nogen efter dem, der verificerer, at det, de har lavet, er godt nok,” siger Brian Fischer.
Lige nu er teamet ved at afslutte en større milestone. I den forbindelse sætter testkoordinatoren nogle testsessioner op, hvor han beder hele teamet af udviklere teste en bestemt feature grundigt igennem i 15 min.
”På den måde har vi kunnet hæve kvaliteten væsentligt,” siger Brian Fischer.
Samlet bliver det til 4,5 timers test udført på et kvarter. De udviklere, der ikke kender til featuren, trykker alle de forkerte steder. Resultaterne skrives ind i et dokument, så testkoordinatoren kan vurdere resultatet. Kasper Fehrend tilføjer:
”Det er virkelig effektivt og giver en meget større effekt, end vi havde forudset. Det er måske lidt Scrum-nørdet, men det er interessant at få den vinkel til at virke, for det her med test har virkelig været en hård nød at knække.”
Langt færre fejl
I lang tid var release en lige så hård nød at knække som testproblemet.
”Vi er på tredje version af TradingFloor nu. Version 2 er stadig et fy-ord hos mange af vores udviklere og hos mig selv, for hver eneste gang, vi releasede, var risikoen for fejl høj,” fortæller Kasper Fehrend.
For at håndtere problemerne begyndte Kasper Fehrend og Brian Fischer at implementere et sæt retningslinjer kaldet Continuous Delivery. Det er ikke en del af Scrum, men retningslinjerne passer godt til den agile metode. Formålet var at flytte fejlfinding helt hen til udviklerens skrivebord. Det kan man gøre i et lidt større setup vha. automatiserede test og automatiserede gateways: Når udvikleren tjekker noget ind, ryger det ikke ud i produktion, før det har været en tur igennem fejlfindingsmøllen. Kasper Fehrend forklarer:
”Det at release er den ultimative feedback: Virkede det, eller virkede det ikke?
Hvis du kan flytte den oplevelse så tæt hen på udvikleren som muligt, får du rettet fejlene med det samme. Vi har ønsket så meget feedback som muligt, og det har øget kvaliteten.”
På TradingFloor-projektet har kombinationen af Scrum og en generel forbedring af agile processer kraftigt reduceret mængden af fejl.
”Kritiske fejl er reduceret til tæt på nul. Mængden af ting, som fejler live, er for-svindende lille. Problemer med release er elimineret. Og det fra at have været et område, hvor vi i dårlige perioder brugte 30-40 % af tiden på at rette fejl,” siger Kasper Fehrend.
Endnu en bonus ved den nye leverance-model er hurtigere releases. Tidligere tog det typisk to til fire uger, fra koden var afsluttet, til den nye funktion kunne gå live. I dag er teamet i stand til at release ca. én gang om ugen – eller oftere, hvis forretningen ønsker det.
