Scrum och Extreme Programming (XP) är definitivt mycket inriktade. Faktum är att om du gick in i ett lag som gör en av dessa processer kan du ha svårt att snabbt bestämma om du hade gått in på ett Scrum-lag eller ett XP-lag. Skillnaderna är ofta ganska subtila, men de är viktiga. Jag tror att det finns fyra huvudskillnader mellan Scrum och XP:
- Scrum-lag arbetar vanligtvis i iterationer (kallade sprints) som är från två veckor till en månad lång., XP-lag arbetar vanligtvis i iterationer som är en eller två veckor långa.
- Scrum-lag tillåter inte ändringar i sina sprintar. När sprint planeringsmötet är slutfört och ett åtagande gjorts för att leverera en uppsättning produkt eftersläpning objekt, den uppsättningen av objekt förblir oförändrad genom slutet av sprint. XP-lag är mycket mer mottagliga för förändring inom sina iterationer. Så länge laget inte har börjat arbeta med en viss funktion kan en ny funktion av motsvarande storlek bytas in i XP-lagets iteration i utbyte mot den ostartade funktionen.,
- extrema Programmeringsteam arbetar i en strikt prioriteringsordning. Funktioner som ska utvecklas prioriteras av kunden (scrums produktägare) och laget är skyldigt att arbeta med dem i den ordningen. Däremot prioriterar Scrum-produktägaren produktstocken, men teamet bestämmer i vilken ordning de kommer att utveckla eftersläpningsobjekten. Jag har aldrig sett ett Scrum team inte välja att arbeta på högsta prioritet objekt. Och ett Scrum-lag kommer sannolikt att välja att arbeta på det näst viktigaste., Men någon gång en av de högprioriterade punkter kanske inte är en bra passform för sprint planeras—kanske en nyckelperson som bör arbeta på det kommer att översvämmas av arbete på högre prioriterade poster. Eller kanske är det meningsfullt att arbeta med ett något lägre prioriterat objekt (låt oss säga #10 på produktstocken istället för # 6) eftersom laget kommer att arbeta i koden där #10 skulle genomföras.
- Scrum föreskriver inga tekniska metoder; XP gör det., Jag älskar XP engineering praxis, särskilt saker som testdriven utveckling, fokus på automatiserad testning, par programmering, enkel design, refactoring, och så vidare. Men jag tror att det är ett misstag att säga till laget ” du självorganiserar, vi litar på dig, men du måste göra dessa specifika tekniska metoder….”Detta skickar ett blandat meddelande till laget som orsakar förvirring. Jag älskar XP praxis men gillar inte mandat dem. Jag vill att lag ska upptäcka värdet på egen hand.
dessa är små och ofta subtila skillnader mellan Scrum och XP., De kan dock ha en djupgående inverkan på laget. Mitt typiska råd till lag är ” börja med Scrum och uppfinna sedan din egen version av XP.”XP-metoderna är underbara men de fungerar bäst och lag förbinder sig till dem mest stridigt om de upptäcker dem själva snarare än att ha dem mandat. Jag hjälper lag göra detta i min coaching genom att ställa frågor som, ” skulle detta fel har hänt om vi hade gjort testdriven utveckling?”och” skulle vi ha gjort det misstaget om vi para ihop?”Jag tycker att true XP är ett litet mål på avstånd., Om ett lag kan sikta på det och slå bull ’ s eye, underbart. Om inte, dock, de sannolikt hacking (t.ex. refactoring utan automatiserad testning eller TDD). Scrum är en stor bull ’ s eye att på egen hand ger stora förbättringar helt enkelt genom ytterligare fokus och timeboxed iterationer. Det är en bra utgångspunkt för att sedan lägga till XP-metoderna.