Regents leveransmodell bygger på principer, som i sin tur baseras på värderingarna (Tillsammans är vi bättre, Tillit och Värdeskapande). Principer ska vara styrande och vägledande så att vanliga fallgropar undviks och ett bättre resultat uppnås.
I den här serien presenteras de principer Regent arbetar utifrån.
Vi börjar med princip nr 1, kvalitet!
Kvalitet låter väl bra! Men vad är det egentligen?
Kvalitet inom IT-projekt är luddigt. Det är kopplat till hållbarhet, flexibilitet och avsaknad av fel, men även till känslomässiga faktorer som polish och design.
För att krångla till begreppet ytterligare så är det utvecklaren anser vara hög kvalitet sällan detsamma som vad testarna, beställaren eller användarna upplever.
Är antalet buggar en definition av kvalitet? Om buggarna rättas, håller systemet då en hög kvalitet?
Regent anser att låg kvalitet är som en underliggande sjukdom. Det gör att system kräver upprepad testning och framförallt regressionstester av sådant som en gång har fungerat. Låg kvalitet gör också att ändringar tar lång tid att införa. För slutanvändarna är systemet obegripligt.
Däremot är kvalitet också kopplat till en kostnad.
Det gäller att hitta en balans så att tiden för kvalitetshöjande åtgärder står i relation till produktens livslängd, kundens förväntningar och den totala budgeten.
Ett system har ofta två faser, projekt och förvaltning, där projektet typiskt står för en bråkdel av både kostnad och kalendertid av systemets totala livslängd. För system som lever en längre tid är det bevisat att hög kvalitet ger lägre kostnad.
Detta bevis består av en studie (genomförd av Capers Jones, Measuring Software Process Improvement) baserad på 10 000 IT-projekt. Genom att fördubbla tiden för kvalitetshöjande åtgärder så har projekt levererat 20% snabbare, 20% billigare samt med 80% färre buggar i produktion.
Nu när vi vet att kvalitet är viktigt, hur kan man då göra för att höja kvaliteten?
1: Genomför en effektkartläggning.
2: Granska och skriv krav agilt. Med andra ord, kravställ arbetet i nära dialog med användare och utvecklare.
3: Parprogrammering eller kodgranskning som en naturlig del av arbetsprocessen. Målet är att det inte ska finnas en kodrad som inte minst 2 personer har varit involverad i.
4: Kontinuerlig refaktorsering och städning av kod.
5: Designmöten med alla utvecklare kring hur systemet ska byggas.
6: Testdriven utveckling
