"[...] most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don’t understand that the pressure valve is quality and long term product sustainability and viability."
Jeg har læst det i indlægget Ken Schwaber on "Flaccid Scrum - A New Pandemic?" på Jeff Sutherlands blog. Der er også mange andre fine betragtninger, så aflæg ham et besøg.
"Kvalitet er sikkerhedsventilen" siger Jeff og/eller Ken (jeg har ikke lige gennemskuet hvem...) - jeg kommer til at tænke på dengang, hvor jeg legede med dampmaskiner som barn: De havde (mindst!) to sikkerhedsventiler, fandt jeg ud af, for selvfølgelig kørte vi dem til grænsen. Men når vi havde kørt dem så hårdt, at sikkerhedsventilen blev aktiveret, så hev vi straks brænderen ud, for det ville ellers være rent spild. Dels fordi at vi ikke kunne få den til at køre hurtigere uanset, men sandelig også fordi at det skar ned på den samlede kørselstid - al den dejlige damp, som kunne være brugt godt, fes jo bare ud igennem sikkerhedsventilen til ingen verdens nytte!
Og sådan er det vel også med udvikling: Der kommer et punkt, hvor mere pres nok medfører mere aktivitet, men ikke bedre resultater - ja, faktisk ender med at være kontraproduktivt; vi når simpelthen ikke så langt, som vi ellers ville have kunnet.
Analogien med dampmaskinerne har dog en åbenlys mangel: Med dampmaskiner kan man tydeligt se, når grænsen er nået, men hvordan ser man det i en udviklingssituation? Hvordan måler man, at man i virkeligheden er ved at lukke damp ud?
2 kommentarer:
Et af tegnene på, at der måske er tale om, at dampen er ved at fise ud gennem sikkerhedsventilen fremfor gennem stemplet (jep, jeg har også leget med dampmaskine, da jeg var barn), kunne manifestere sig som en forværring af metrikkerne - om det så er et fald i test coverage eller stigning i kompleksitet.
Det kunne vel også manifestere sig som mindre tid brugt på at rydde spørgsmål til uklare krav af vejen.
Men forudsætningen for, at man kan opdage det, er vel, at man allerede har nogle målinger, man kan sammenligne med, inden man kan høre sikkerhedsventilen hvisle.
Rasmus, først vil jeg lige undskylde den sene respons - jeg gik og overvejede, om mit svar ikke kunne blive et selvstændigt indlæg, men det må så blive en anden gang.
At måle er som oftest en god ting, specielt hvis målingen ikke er for "invasiv" - dvs. den skal ikke rigtig tage nogen opmærksomhed fra det væsentlige.
Når man måler, så skal man til gengæld altid spørge sig selv om, hvad det præcist er, at man måler - ofte vil man helst måle et, men ender med at måle noget andet. Test coverage eller kompleksitet (tænker du f.eks. på cyclomatisk komplesitet?) er vel begge indirekte mål på overspringshandlinger, og overspringshandlinger er vel det, som sker, når vi "lukker damp ud", så ideen er sådan set god nok - omend det er noget indirekte.
Man skal bare passe på to ting: 1) at ændringen i testcoverage eller kompleksistet rent faktisk skyldes en urimelig belastning, og ikke noget helt andet, og 2) at fokus ikke skifter over på testcoverage og kompleksitet i stedet for det, man i virkeligheden vil måle (de fleste er ikke dummere, end at de godt kan fuske en god coverage, hvis det betyder, at den trælse chef forsvinder ind på sit kontor igen!).
Med det sagt, så vil jeg igen understrege, at det er bedre i det mindste at prøve at skimte ud af den duggede forude, end helt at give op og lukke øjnene (i hvertfald så længe, at man ikke bliver så bange for spøgelser, at man slet ikke tør køre længere)!
Send en kommentar