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

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…