Kan man lave software uden fejl?

Mange IT teams kæmper med at levere fejlfri kvalitet på en konsistent basis. Fejl og missede deadlines skaber kun stress og drama, så absolut ingen har lyst til at lave fejl. Men alligevel sker det alt for ofte. Men det behøver det ikke. Kodeordet er standardisering.

Alle – både IT chefer og IT udviklere – ønsker at udvikle software af høj kvalitet. I kraft af min rolle som IT konsulent møder jeg alligevel mange teams, som kæmper med at levere software i en kvalitet, som brugerne er glade for og som kan fastholdes år efter år.

Forklaringerne på den ringe kvalitet varierer fra “vi mangler budget til et ordentligt testmiljø” over “vi mangler tid til at skifte fra JSON-RPC til REST…”  til at handle om for stramme deadlines eller mangel på ny teknologi.

Arkitektur og teknologi er dog ikke en afgørende faktor for succes. Der findes teams, som kan levere høj kvalitet helt uden at bruge et testmiljø, og på teknologi, som andre kalder håbløs.

Min erfaring fortæller mig, at alle teams kan lykkedes med at levere høj kvalitet – dog kræver det ledelse og standardisering.

Især på standardiseringsområdet er IT-branchen stadig meget umoden og det er et problem.

Nøglen ligger i standarderne

Mange andre brancher og industrier arbejder med standarder.

Sundhedssektoren har standarder for håndvask og desinfektion af operationsudstyr – og disse standarder bliver der aldrig slækket på.

I flybranchen findes der standarder og tjeklister, så piloterne ikke selv skal “huske”, hvordan man letter og lander et fly, men i stedet følger en fast standardiseret procedure. Derved kan piloterne altid løse den komplicerede opgave fejlfrit.

Softwarebranchen mangler derimod standarder på tværs af hele branchen. Jeg ser, at de teams som faktisk arbejder efter standarder i højere grad lykkedes med at levere høj kvalitet og deri ligger nøglen til fejlfri software.

Kvalitet skal ikke være et mål, men en standard.

Skab standarder i jeres teams

Da der ikke findes en bredt vedtaget branchestandard, må hvert team selv definere en standard med de kriterier, metoder og teknikker, som de vil arbejde med.

Det kan variere meget fra team til team, hvilke elementer der er relevante at inddrage i en standard.

Her er et uddrag fra en standard, jeg har arbejdet med:

• Breaking changes må ikke forekomme.
• Alle ændringer skal gennemgå grundigt peer review.
• Alle komponenter skal have dækkende unit tests.
• Alle API endpoints skal have dækkende boundary tests.
• Paradigmer fra funktionel programmering foretrækkes frem for objekt-orienteret programmering.

Teamet som brugte denne standard var i stand til konsistent – og uden brug af et dedikeret testteam –  at levere nye features uden stop-fejl i årevis.

Ud over at sikre en konsistent kvalitet fungerer en standard også som et kommunikationsværktøj: den gør det nemt at kommunikere kvalitetsmål til eksterne interessenter, ligesom den er værdifuld når der indlemmes nye medlemmer i teamet.

Jo mere konkret standarden er, jo nemmere er det at måle arbejde imod den og jo nemmere er den at kommunikere.

Det er i øvrigt værd at bemærke, at standarden ikke behøver at være statisk – den kan udvikle sig over tid, i takt med at teamet, opgaverne eller eksterne forhold ændrer sig. Blot er det vigtigt, at der er enighed om standarden, således at man har en fælles referenceramme og fælles kvalitetsmål.

Implementering og forandringsledelse

Implementeringen af standarden er lige så vigtig som selve standarden. Her er der behov for klassisk forandringsledelse.

Dermed kan ledelsen ty til en række kendte tænkere og værktøjer. For eksempel kan man bringe John Kotters 8-trins model i spil. Se model nederst i artiklen.

Jeg hjalp et team med at implementere standarder hos en kunde sidste år. Her så jeg, hvordan de gik fra at have en hektisk udviklingsproces med fejl og frustrationer til en proces med stor forudsigelighed og deraf følgende tilfredshed og arbejdsglæde hos både teamet og øvrige interessenter.

Det opnåede de ved:

• At formulere kvalitet som en standard – en præmis for deres arbejde.
• Dagligt at inddrage standarden i deres stand-up møder og code reviews.
• At evaluere fremskridt og analysere og justere udviklingsprocessen i retrospectives.
• At benytte visuelle ledelsesværktøjer til at sikre fokus på standarden.
• At insistere på meget grundige code reviews som – udover at understøtte fejlfinding og vidensdeling – giver udviklerne lejlighed til at holde hinanden op på standarden og deres fælles løfte om kvalitet.

Teamet kickstartede forandringerne ved at indlemme konsulenter fra Copenhagen Software i teamet. Konsulenterne blev katalysatorer for forandringerne og udgjorde den kritiske masse der skulle til for at holde et kontinuerligt fokus på forandringerne.

Softwareudvikling behøver ikke at være en uordentlig proces med jævnlige fejl og mangler. Tænk på, hvad det ville betyde for dig, hvis I konsistent kunne levere software uden fejl. Hvor meget tid og drama kunne I ikke spare?

Jeg håber, at artiklen har givet dig inspiration til at arbejde med standarder i din IT afdeling og i dine teams, således at flere softwareprojekter lykkedes uden missede deadlines og fejl.