Reni Friis bloghoved

Der er for lidt fokus på at undgå fejl !

Tænk sig en situation, hvor der næsten ikke blev brugt tid på test og fejlretning… tænk sig, hvis det var muligt…

At bilde sig ind, at man sparer noget ved ikke at analysere og tage hele den reelle kompleksitet ind i forberedelsen af udviklingen, er i den grad at stikke sig blår i øjnene. Det er jo den kompleksitet alle løber rundt og prøver at favne efter vi skulle have været i luften med ”den der release”.

Prøv at gennemfør en analyse af hvor meget tid I bruger i jeres udviklingsproces på henholdsvis

  • Styring af udvikling (projektledelse, koordinering, release møder, scrum møder mv)
  • Forberedelse af udvikling (analyse, design mv)
  • Opfølgning på kode (test, fejlretning mv)

Og forhold det tal til hvor meget tid der reelt bruges på at udvikle.

Mange vil blive rigtig overraskede over hvor meget tid der medgår til at lave 1 times reel tilvirkning af kode. Jeg har konkrete erfaringer med organisationer, der har en ratio på alt fra 1:4 til 1:50. DET ER DA HELT VILDT!!!!

Selvfølgelig skal der medgå noget tid til styring, analyse, design, test og fejlretning. Det er der ingen diskussion om. Men det er alligevel en tanke værd, at for 1 times reelt ”salgbart” output, medgår der mellem 4 og 50 timer…

Det vil være helt på sin plads, hvis de ledere og chefer, som har ansvaret for udviklingen havde lidt mere fokus på hvordan folk reelt arbejdede med, så de kunne fjerne noget af årsagen til, at der er så meget behov for at teste så meget, og at rette så mange fejl…

Hvad årsagen til fejlene i koden, integrationerne, opsætningerne, kørslerne mv er, er selvfølgelig forskellige fra sted til sted. Kompleksiteten er jo enorm nogle steder, så det er selvfølgelig helt utopisk at tro, at fejl slet ikke vil forekomme.

Men jeg mener altså, at der er masser af hente i at fokusere mere på at undgå fejlene, end på at blive bedre til at finde og rette dem (som også skal forekomme selvfølgelig).

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup

En ting er sikkert. Der er mange software-udviklingsprocesser mange steder der kunne forbedres meget ifht. Både produktivitet og kvalitet.

Du nævner desværre ikke hvordan man kunne gribe det an, så lad mig komme med et helt overordnet bud:

Mange organisationer gør den fejl, når de ønsker at forbedre, at de "strammer op" på processen. Indfører flere regler, gates og kontroller. Min erfaring er at det er direkte ødeløggende, både for arbejdsglæden og processen.

Hvis man i stedet løsner grebet, stoler på folk og lader dem selv beslutte hvad der er det fornuftige at gøre, både som individ og som team, så sker der dramatiske forbedringer. Giv folk noget reelt ansvar.

  • 1
  • 0
Reni Friis

Hej

Jeg er enig i forhold til at undgå at finde løsningen i øget kontrol. Derimod mener jeg, som jeg også skriver i bloggen, at man skal finde kilden til fejlene og bruge energien på at fjerne den.

Kilden kan fx være, at man
- ikke taler godt nok sammen på tværs af afdelinger, når man laver integrationer
- ikke er enige om hvor i koden hvilke features skal være
- ikke har sikret sig, at alle har samme opfattelse af, hvad der skal udvikles

Kilderne er ikke entydigt de samme alle steder jeg har set, så derfor mener jeg ikke, at man kan sige entydigt hvad en løsning på dårlig kvalitet kan være...

Reni

  • 0
  • 0
Allan Ebdrup

Der er vidst ikke nogen der kan være uenige i at det er en god ide at kigge efter de dybere årsager til at fejl opstår. A la "the five whys". Ser du da at folk ikke har lyst til det? Hvilke teknikker bruger du?

Du skriver at man ikke kan sige noget entydigt om en løsning på kvalitetsproblemer. Det er jeg helt enig med dig i. Men hvis vi skal have en interresant debat, bliver vi nød til at komme et spadestik dybere. Selvom det vil ramme ved siden af for nogle.

  • 0
  • 0
Troels Henriksen

Jeg har tænkt på noget i denne retning. Conway's Lov siger at en organisation uværgeligt producerer systemer der imiterer organisationens egen interne struktur. Vi er rimeligt på hvordan et godt programdesign ser ud, også selvom vi ikke er sikre på hvordan man når dertil hver gang: Det er noget med løs kobling, dekomposition, veldefinerede lag, testbarhed i dele, og så videre.

Mit spørgsmål er så: Giver det mening at designe sin menneskelige organisering så den imiterer egenskaberne ved det ideelle design?

Jeg er kommet på spørgsmålet efter at have overvejet hvordan open-source bevægelsen har været i stand til at konstruere noget så kompliceret som (adskillige!) styresystemer, til trods for at der ikke er nogen fast kommunikation eller egentlig struktur. Sammenlign bare med hvor galt det ofte går når højt integrerede virksomheder skal konstruere systemer af lignende kompleksitet.

Jeg tænker, at den de-centraliserede asynkrone struktur man nødvendigvis må have i et open-source projekt stemmer meget godt overens med et godt design af et større system.

  • 2
  • 0
Allan Ebdrup

Mit spørgsmål er så: Giver det mening at designe sin menneskelige organisering så den imiterer egenskaberne ved det ideelle design?

Det er et godt spørgsmål. Jeg vil mene at de nyeste trends med microservices, cross-functional teams og fx Amzons CEO Jeff Bezos regel om at intet team må være større end at de kan blive mætte af to pizzaer er eksempler på at man forsøger netop dette.

Jeg vil dog passe på med at bruge betegnelse "ideelt design", det vil være organisations-individuelt hvad der skal til for at forbedre udviklingsprocessen.

Vores egne praktiske erfaringer med at lade os inspirere af de bedste (Amazon, Netflix, Twitter, GitHub osv) og gøre det til vores eget, har skabt bemærkelsesværdige resultater.

  • 0
  • 0
Karen Lauberg Lauritsen

Reni har jo helt ret i sin pointe. Hvis digitaliseringen skal give reel værdi så skal der laves løsninger med så få fejl som muligt. Man undrer sig til tider over kvaliteten af, hvad der bliver smidt på markedet.

Helt konkret så ligger de effektive løsninger primært to steder:

1) En fornuftig behovs- og designafdækning i tæt dialog med slutbrugere/kunder som f.eks. bliver understøttet af agile udviklingsmetoder men også af den mindre kendte ITIL sub-proces Change Evaluation. Jo bedre du forstår løsningen fra starten, jo færre fejl, jo billigere...

2) En risiko baseret test tilgang, hvor indsatsen lægges der, hvor der er størst risiko for at fejl har den største konsekvens. Det kræver dog en struktureret tilgang - hvor opsplitning i mindre dele efter pizza-princippet er helt fint - men ikke nødvendigvis sikrer at hele løsningen fungerer fra A til Z. Jeg er ikke tilhænger af at slippe kontrollen helt, men er helt enig i, at det er vigtigt at dyrke det personlige ansvar og den faglige stolthed hos udviklerne.

Det er måske gamle kendinge, men idag hvor de færreste slutbrugere har tid til at rapportere fejlene, sker der bare det, at der bliver stemt med fødderne istedet. Og det var vel ikke lige det, vi ville med vores nye digitale løsning, eller hvad?

  • 0
  • 0
Søren Harder

Det er en vigtig diskussion, du åbner her. Jeg synes dog at dit perspektiv er lidt for koder-forherligende. Når du skriver '1 times reelt ”salgbart” output', så involverer det ikke det arbejde, som består i at overveje, hvad kunden har brug for og heller ikke hvorvidt det faktisk virker; ikke just "salgbart". Jeg er heller ikke sikker på at den fokus, mange har (og som jeg også synes du lægger op til) på at fange fejlen så tidligt som muligt, altid er produktiv. Nogen gange er det bedre at have synergi mellem udvikling og test, også selv om det involverer en håndfuld tilbageløb. Tilbageløbene tager måske en halv til en hel dag, mens analyse og Process-med-stort-P kan tage en uge.

Lidt provokerende kan jeg citere James Bachs modvilje med udtrykket "testautomation": 'Hvorfor taler man aldrig om kode-automation?'. I virkeligheden er det reelle arbejde at finde ud af hvad systemet skal og sørge for at det er hvad systemet gør: kodningen burde være fuldautomatisk. Det er selvfølgelig et perspektiv, der er mindst lige så forskruet, som det du anlægger, men det viser at den ratio du beregner, ikke giver mening.

Jeg tvivler ikke på at det perspektiv, du anlægger, i visse sammenhænge er det korrekte for at løse et konkret projekts konkrete problemer, men hvis man skal finde et generelt perspektiv (og det skal du jo som blogger), vil jeg nok vælge et andet.

  • 0
  • 0
Morten Jensen

Reni har jo helt ret i sin pointe. Hvis digitaliseringen skal give reel værdi så skal der laves løsninger med så få fejl som muligt. Man undrer sig til tider over kvaliteten af, hvad der bliver smidt på markedet.

Helt enig. Det tror jeg dog er fordi man ofte bruger en udviklingsproces der passer godt til normal B2B software, men passer skidt til missionskritisk software, som offentlig IT nogle gange er (NemID fx). Jeg tror det har lidt at gøre med, at det er deadlines der styrer leveringerne og ikke et kvalitetsmål (fx +85% test coverage, ingen tests må fejle). Bevares, det koster sjældent menneskeliv, "kun" tid og penge...

På min arbejdsplads udvikler vi bl.a. sikkerhedskritisk software til at styre store maskiner, og dér må deadlinen altså vige for accept-testen hvis det bliver nødvendigt. Det handler også lidt om et etisk kodeks: Jeg vil personligt ikke lægge navn til noget der kan gøre skade menneskeligt og/eller materielt, uden det er testet grundigt; heller ikke hvis jeg kommer i tidspres - men det kræver da mandsmod (m/k) at skulle gå ind til chefen og sige at man ikke kan holde sin tidsplan.
Det er en anden måde at gøre det på, og det fordyrer processen umiddelbart, men det har også forretningsværdi at man sjældent skal brandslukke fordi der opstår pludselige kritiske fejl i marken.

  • 2
  • 0
Ivo Santos

Men jeg mener altså, at der er masser af hente i at fokusere mere på at undgå fejlene, end på at blive bedre til at finde og rette dem (som også skal forekomme selvfølgelig).

Så er det jeg tænker, hvad nu hvis direktionsgangen der er problemet og ikke de andre områder?
Tænkt sig at man kan forbedre en masse blot ved at udskifte en hel bestyrelse med en hel anden, eller delvis anden, bestyrelse, udelukkende fordi der er for meget fokus på profit, det er der nok ikke mange der tænker over kunne jeg forestille mig.

  • 1
  • 0
Reni Friis

Jeg er både enig og uenig. Der kan være en kæmpe effekt af at skifte en direktion ud - og det er der også flere steder, der efter min mening kunne trænge til.... Men jeg har sjældent aldrig set et skifte på højt ledelsesniveau resultere i ret mange ændringer i den måde medarbejderne reelt udfører deres arbejde på. Det er bare ikke det, de har deres fokus på...

Det er medarbejderne, der udfører det arbejde en organisation "lever af" så der er der, der skal fokuseres, hvis der skal ændres noget ift måden hvorpå arbejdet reelt udføres...

Det fokus kommer ikke af sig selv dog... det skal efterspørges af de ledere, som leder medarbejderne. Ledernes ledere skal efterspørge og give rum til en anden måde at arbejde på... og ja... på den måde kan man sige, at det alligevel kan havne på direktionsgangen...

  • 0
  • 0
Reni Friis

Jeg må erkende at jeg ikke har nok indsigt til at respondere på den der med kode-automatisering :)

I mit indlæg står der dog - ud over det der med at holde ting op imod den "1 time salgbart arbejde", som jeg skriver - at der stadig er brug for flere af de ting, der ligger udenom. Gode snakke med brugere etc.

Faktisk mener jeg, at prototyping, hurtig udvikling (ofte med fejl) for at lære mere tidligere i processen, kan være rigtig godt. På den måde erkender man det faktum, at man i starten af en udvikling - stor som lille - ved mindst om hvordan man skal tilgå den, hvad den skal kunne etc... De fejl man laver for bevidst at lære og opbygge viden er super fint, synes jeg.

Det er de traditionelle udviklingsforløb, hvor man bare lader fejlene "køre igennem" og skynder sig så meget med koden, at man lægger en kæmpe teknologisk gæld indlejret i systemet og en kæmpe opgave til den efterfølgende test. Det er ikke fair og en rigtig dårlig ide. Synes jeg...

  • 0
  • 0
Log ind eller Opret konto for at kommentere