Fortsätt till huvudinnehåll

God utvecklarpraxis är en del av Scrum

En vanlig missuppfattning, och ibland en källa till dispyt mellan Scrum- och XP-anhängare, är att Scrum inte lägger någon vikt vid god utvecklarpraxis. I XP är det ju så tydligt: parprogrammering, kontinuerliga byggen, enhetstestning eller till och med att man driver programmerandet med testfall. Scrum tycks lite fattigt i jämförelse, här finns ju inga tvingande regler om hur man ska göra på detaljnivå.

Att Scrum inte beskriver hur utvecklingsteamet ska göra sitt jobb är inget misstag. Scrum utelämnar detaljerna, eftersom de beror på sammanhanget. Parprogrammering är till exempel en lysande idé, om inte användningen i ett givet fall resulterar i så mycket konflikter att det hela kostar mer än det smakar.

Scrum är ett ramverk, en tom struktur vars detaljer behöver fyllas i av användaren. Tack vare detta kan vi lätt förklara essensen i Scrum för nya användare, och dessa kan själva fylla i med det som behövs i deras specifika situationer. En sidoeffekt av detta är att den som inte vet vad som behöver fyllas i står sig rätt slätt.

Avvägningen står alltså, i ytterligheterna, mellan att göra en mer utförlig projektmetod som beskriver exakt vad som ska göras i varje givet fall, och att göra ett enklare ramverk som bara beskriver den övergripande strukturen och överlåter till användaren att fylla i detaljerna.

Scrum går alltså på den senare linjen. Rationals Unified Process är ett exempel på den förra, och här ser vi också riskerna med den mer utförliga approachen. Trots, eller snarare på grund av, att RUP innehåller sida upp och sida ned med bra information om mjukvaruutveckling så blir metoden oöverblickbar. Många som använder RUP har helt missat att det är en iterativ och inkrementell arbetsmetod, kanske för att man redan spenderat all sin uppmärksamhet på alla detaljer.

Även om Scrum inte beskriver detaljerna krävs det alltså att vi själva kan fylla i dem. De flesta som är insatta i lättrörlig utveckling kan nog skriva under på att seriös enhetstestning, kontinuerliga designförbättringar och frekvent integration är tekniker som man inte vill vara utan om man vill lyckas med att utveckla iterativt, inkrementellt och lättrörligt.

Redan när jag lärde mig om Scrum från Ken Schwaber 2003 tryckte han på vikten av god utvecklarpraxis. Vi frågade till exempel vad man gör om man märker att organisationen saknar tillräckliga rutiner för konfigurationshantering. Kens svar: sätt in det som hög prioritet på produktbackloggen.

Filosofen Voltaire får avsluta, för han har redan beskrivit vad det handlar om så bra som man kan hoppas göra:

"What harm can a book do that costs a hundred crowns?
Twenty volumes folio will never cause a revolution;
it is the little portable volumes of thirty sous that are to be feared."

Kommentarer

jockesara sa…
Nice, Tobias! Hade inte hittat denna blogg. Trevlig läsning!

Tänkte bara kommentera dina "ytterligheter" från artikeln. Jag tycker nämligen att XP representerar en tredje variant, nämligen att erbjuda en uppsättning arbetssätt som stödjer varandra. Det är vare sig något som försöker superdetaljera allt eller något som mest erbjuder en förbättringsbehållare. XP är för mig en verktygslåda med inbyggt nätverk, så att säga.

Jag tycker Scrum är genialt i all sin enkelhet, men jag tror ibland att XP egentligen kan vara en enklare paketering att börja med. Om det nu inte var så att TDD och parprogrammering var så lätt att misslyckas med, vill säga. :-)
Tobias Fors sa…
Tjena Jocke! Tack för besöket. Jag ser att ni är på äventyr i öst. Coooolt!

Populära inlägg i den här bloggen

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k