Dårlig ytelse og robusthet koster. Her har kommersielle systemer, og miljøer, lenge vært drivende for utviklingen av verktøy og metodikker for å drive med teknisk test. Det er ikke så rart da dårlig ytelse, robusthet og sikkerhet kan bety kroken på døra – folk har blitt utålmodige, og er ikke redde for å prøve ut andre løsninger. Men det offentlige kommer sakte men sikkert etter. Store medieoppslag skal ha sin del av æren her. For førstesideoppslag med logo og negativ omtale, gjør sitt for at direktører og ledere nå stiller spørsmål om ikke-funksjonelle krav. Det er bra.
Så var det dette med metodikken da. Metodikken er som sagt grunnmuren, og styrer i stor grad hvordan prosjekter fungerer og i ytterste grad hvor suksessrike de er. Store ord, jeg vet. Vannfall, og vannfall med innslag av Scrum, er beroligende. Man tegner ferdig kartet, og så starter man å gå. Scrum er litt mindre håndfast, og skumlere å forholde seg til for etablerte organisasjoner. La oss se de opp mot hverandre i god gammeldags sammenligning! Jeg lister her opp gode og dårlige sider ved de to, slik jeg ser – og har opplevd dem.
Vannfall
+ Forutsigbart (i teorien)
+ Grundig analyse og design kan spare tid senere i prosjektløpet
– Ofte ikke komplett og testbart før sent i prosjektet
– Ytelsestester gir lite utbytte sent i utviklingsløp
Smidig/Scrum
+ Man får fort levert fungerende funksjonalitet
+ Raskere å få levert fikser
+ Utviklere kan merge inn i inneværende sprint
+ Alle har sprint friskt i minne, som gir mindre overhead
+ Tid til flere iterasjoner
+ Design- og arkitekturfeil er billigere å rette
– Smidig betyr ofte i bevegelse, som gir hyppige endringer på grensesnitt og applikasjoner
Det som ofte skjer i prosjekter som kjører vannfall, eller vannfall med smidige innslag, er at man ikke har satt av tid til tekniske tester før sent i sprint/leveranse. Da sitter den stakkars ytelsestesteren der med en liten uke på seg til å planlegge, utvikle, gjennomføre, analysere og komme med en lite overraskende rapport om dårlig ytelse. Da ender det med etterleveranser/hurtigmigreringer, nedskalert utrulling osv osv. Ikke bra! Det er ikke nok for kunde å komme med en bestilling på en rapport på rikets tilstand sent i løpet, for deretter å bli stresset og iverksette dyre tiltak.
Tips og triks for suksess
Først og fremst; tørk av deg det gliset. Det finnes ingen lettvint «tre-enkle-steg-for-å-lykkes-med-ytelse». Å sikre kvaliteten til systemet sitt med tanke på ytelse, robusthet og sikkerhet koster. Det krever at organisasjonen som kravstiller er moden nok til å se utfordringene, og være villig til å gjøre noe med det. Dessverre har mange kravstillere og arkitekter funksjonalitet som første prioritet. God ytelse starter i løsning, med kunde som pådriver. Få målbare krav, som: «Applikasjonen skal takle 100 påloggede brukere uten nedgang i ytelse», «Ved plutselig avbrudd mellom komponent A og B, så skal normaltilstand gjenopptas når kontakt gjenopprettes». Gi konkrete krav! Ikke «Det forventes akseptabel ytelse under kjernetid» eller «Applikasjonen må være robust».
Hvis man har et stort prosjekt bestående av flere team, og man sliter med ytelsen under utvikling, så trekk utviklere ut fra de forskjellige teamene og par disse sammen med tekniske testere. Dette letter byrden på de resterende utviklerne, og man kan få fokusert på både ytelse og funksjonalitet. Slike team er lette å opprette og oppløse.
Lever brukerhistorier med fokus på ytelse. Ha testere som tør å se i databasen, og som kan snakke på samme nivå som utviklere og tekniske arkitekter.
Få ytelse og robusthet inn i ryggmargen på utviklingsprosjektet! Snakk om det på allmøter. Heng opp grafer og fun-facts på kaffemaskiner. Få folk interessert!
