• Embed Doc
  • Copy Link
  • Readcast
  • Collections
 
Tobias Fors
som använt, infört och lärt ut Scrum tilldussintals företag och hundratals personer sedan 2003är en av Sveriges mest erfarna scrumkonsulter ochCertified Scrum Trainer för amerikanska Scrum Alliance.
tobias.fors@citerus.se
Klart och oklart– om Scrum och kvalitet
Ett av nyckelvärdena i Scrum är att undvika att försöka öka hastigheten genom att görakontraproduktiva kompromisser med produktens interna kvalitet. Tobias Fors har tagit entitt på varför kvaliteten på insidan av mjukvaran ibland får ge vika i utvecklingsprojekt, ochvilka konsekvenser det kan få.
Kvalitet är ett begrepp som väcker känslor. Ordet kvalitet kan användas som ett moraliskt slagträ, som i“Du är ju inte intresserad av kvalitet”. Omvänt fungerar också. “Inget mer
nslipande, nu är det fulhacksom gäller”, som jag 
ck höra av en projektledare en gång.Den typen av helt öppna försök att öka farten genom att reducera den interna produktkvaliteten är nog ganska ovanliga, tack och lov. Vanligare är att saker som läsbar kod och design som går att underhållablir lidande e
ersom kompromisser med dessa egenskaper ses som den enda snabba vägen framåt. Omtid, kostnad och omfång är
 xerade i en ouppnåelig målbild måste någon annan parameter ge vika. Dåblir det kvaliteten som får böja sig.Det farliga med att använda kvaliteten som ett styrverktyg är att det resulterar i extremt svårförutsägba-ra konsekvenser. Konsekvenserna är svåra att förutsäga av minst två anledningar. Dels kan det dröjainnan de manifesterar sig, så när de väl dyker upp är det sällan uppenbart vad som orsakat dem, ochdärför svårt att veta hur man ska angripa dem. Dels hopar sig problemen inte med en långsam linjärtakt, utan snabbt och icke-linjärt - med andra ord blir det snabbt värre när det väl blir värre.Systemtänkare har ett namn för det fenomen som inträ
 
ar när vi prutar på kvaliteten för att öka has-tigheten. De kallar det för “shi
ing the burden”, och det fungerar så här: ett symptom på ett problemuppenbarar sig, och det är tydligt att något måste göras. Två olika lösningsalternativ
nns tillgängliga,det ena med en uppenbart snabbare e
 
ekt än det andra. Detta alternativ ger en mer eller mindre ome-delbar lindring av symptomen. Det andra alternativet går på djupet, och angriper själva källan till pro-blemet, men har den svagheten att det tar längre tid att genomföra. O
a väljer vi det snabbare, ytligare,alternativet. När vi på det sättet lindrar symptomen minskar vi också trycket att gå på djupet och lösa
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling
!
Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors
www.citerus.se
1
 
grundorsaken till problemet - problemet är ju ur världen just nu, och vi har andra mer akuta saker attägna oss åt. Som om inte detta vore nog har den snabba lösningen o
a en side
 
ekt - den minskar o
a vår förmåga att ta oss an det underliggande problemet.Ett exempel kan vara följande. Tänk dig att du lever ett aktivt liv med en fullbokad kalender, men ty- värr då och då drabbas av ryggont - en inte helt ovanlig situation. Du vet att du borde gå till botten med problemet, trä
 
a en doktor, kanske träna mer och stressa mindre, men att göra alla de sakerna kräverbåde tid och energi som du inte har just nu. Istället äter du en kra
full smärtstillare när värken slår till,och den ger dig lindring nästan omedelbart. När väl det onda är borta för tillfället försvinner dina tan-kar på att du borde trä
 
a en doktor, och du kan ta dig an din fulla kalender med ny kra
. Värktablettenhar en bie
 
ekt också. Ju o
are du äter den, desto lägre blir din tolerans för att ha ont i ryggen, vilket gördig ännu mer benägen att snabbt äta en värktablett när du får ont, och ju snabbare du äter tabletten,desto snabbare försvinner inte bara ryggvärken, utan också dina tankar om att verkligen gå till bottenmed problemet.“Shi
ing the burden”-fenomenet är en typ av beroendemönster. På samma sätt som vi kan bli beroendeav värktabletter när vi egentligen bordestressa mindre kan vi bli beroende avandra saker. En sådan sak är att användakvalitetsgenvägar som ett sätt att snab-ba upp utvecklingsarbetet. Det funge-rar nämligen utmärkt. En kort stund.På lång sikt är det en förödande strate-gi, av samma anledning som det ärdumt att använda värktabletter för o
a.Att bli beroende av att sänka kvalitetenför att öka hastigheten är något som sker över en längre tid.Tänk dig att du jobbar i ett projekt. Ni har ont om tid i projektet, men leveransdatumet kan inte änd-ras. Inte heller kan leveransens omfång ändras, och budgeten ligger fast sedan länge. Något måste göras,men vad? Utan att egentligen fatta ett explicit beslut börjar ni skära ned på aktiviteter som att städa ikoden, att tänka igenom era designbeslut och att testa det ni bygger. Det ger resultat snabbt. Ni hinnermed
er saker än vanligt de närmaste veckorna. Er signal till omvärlden är tydlig. Hann ni med
er sa-ker än vanligt i den här sprinten borde ni kunna göra det i nästa också, och det visar sig stämma. Dis-kussionen om att projektet hade problem börjar nu dö ut - ni har ju visat vad ni går för. De som sattetryck på er har fått vatten på sin kvarn, det behövdes ju vare sig en kapning i omfånget eller mer tid och pengar. Allt som behövdes var lite gammalt gott jädrar anamma.Tyvärr blir glädjen inte så långvarig. I nästa iteration tar ni som vanligt på er ett rejält sjok arbete, pluslite till (utmanande mål är ju bra). Men den här gången blir det inte som tidigare. När ni ska implemen-
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling
!
Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors
www.citerus.se
2
På samma sätt som vi kan bli beroendeav värktabletter när vi egentligen bordestressa mindre kan vi bli beroende avandra saker. En sådan sak är att användakvalitetsgenvägar som ett sätt att snabbaupp utvecklingsarbetet.
 
tera den nya funktionaliteten stöter ni på patrull. Stora delar av koden är kopierad istället för återan- vänd, och ni måste lösa samma problem på
era olika ställen. När ni försöker lösa problemen märker niatt nya problem dyker upp på till synes helt orelaterade platser i koden. De dyker upp i en sådan takt attni snart förstår att ni orsakat många
er defekter som ni ännu inte upptäckt. Vissa saker ni tar er anklarar ni inte av att avsluta över huvud taget, så ni blir tvungna backa ur vissa ändringar ni påbörjat.Resultatet är förödande. Från toppfart tillsnigelfart på kort tid, men ni förstår vadsom har hänt. För varje genväg ni tog ökadekomplexiteten i produkten en smula. I bör- jan ledde det inte till några större problem,och e
ersom ni minskat på testningen föratt kunna bygga
er funktioner kunde dessasmå problem smita mellan springorna. Allte
ersom de blev
er ökade problemen ty- värr snabbare och snabbare. Varje ny ökning av komplexiteten interagerade med tidigare försämringarså att e
 
ekten blev icke-linjär. Det var därför ni blev så överraskade när problemen plötsligt verkadehopa sig.Nu när ni äntligen insett vad ni ställt till med vill ni sänka tempot och återställa kvaliteten i produkten.Dessvärre har ert laborerande med kvaliteten fått en bie
 
ekt. De ni jobbar åt har lärt sig att om man berom högre hastighet så får man det. När ni försöker förklara vad som hänt stirrar de bara förblu
 
at på er.Ni har ju bevisat
era gånger tidigare att ni kan hålla ett högt tempo. Uppenbarligen, säger man, har niha
vissa tillfälliga problem den senaste tiden, men ni har ju visat tidigare att det går att lösa om ni gerer sjutton på det. Håglösa kavlar ni upp tröjärmarna och beger er tillbaks till era arbetsplatser.Historien kanske låter överdriven, och det är den i varje fall i en aspekt. I normala fall tar det mångamånader innan problemen med kvalitetsskulden blir så tydliga att man inser att något måste göras - ochdå är det ibland redan försent.Ett av målen med Scrum är att förhindra att vi hamnar i denna prekära situation till att börja med. Det-ta är anledningen till att vi trycker så hårt på att de
niera ett tydligt och överenskommet klarkriterium. Vårt mål är att hålla kvalitetsribban högt, så att vi undviker att hamna i den dåliga kvalitetens nedåtspi-ral.Klarkriteriet är inte statiskt, utan behöver förädlas över tiden. Ett team som precis börjat användaScrum kanske är nöjda om den första sprinten resulterar i lite mjukvara som man hjälpligt testat manu-ellt, särskilt om det är mer än vad man åstadkommit det senaste året. Det är en bra start, men om pro- jektet ska kunna leverera en kvalitetsprodukt i tid måste man snart höja ribban och inkludera mer am-bitiös testning och automatisering i klarkriteriet. Detta kallar vi för “det växande klarkriteriet” - mankan alltid bli lite mer klar redan vid sprintens slut.
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling
!
Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors
www.citerus.se
3
I normala fall tar det många månaderinnan problemen med det vi kan kallakvalitetsskulden blir så tydliga att maninser att något måste göras - och dåär det ibland redan försent.
of 00

Commenting has been disabled.