Scrum og Extreme Programming (XP) er definitivt veldig justert. Faktisk, hvis du gikk inn på et lag å gjøre ett av disse prosessene du kan ha vanskelig for å raskt avgjøre om du hadde gått inn på et Scrum team eller en XP-team. Forskjellene er ofte ganske subtile, men de er viktige. Jeg tror det er fire viktigste forskjellene mellom Scrum og XP:
- Scrum team vanligvis jobber i iterasjoner (kalt sprint) som er fra to uker til en måned lang., XP lagene som vanligvis jobber i iterasjoner som er én eller to uker lang.
- Scrum team ikke tillat endringer i deres spurter. Når sprintplanleggingsmøtet er fullført og en forpliktelse laget til å levere et sett av produktkøelementer, det settet av elementer forblir uendret gjennom slutten av sprinten. XP lagene er mye mer mottakelig for endring innen sine iterasjoner. Så lenge laget ikke har startet arbeidet med en bestemt funksjon, en ny funksjon som er av tilsvarende størrelse som kan byttes inn i XP lagets iterasjon i bytte for unstarted funksjonen.,
- Extreme Programming lag arbeide i en streng prioritering. Funksjoner som skal utvikles, er prioritert av kunden (Scrum er produkteier) og laget er pålagt å arbeide på dem i den rekkefølgen. I kontrast, Scrum product owner prioriterer produktkøen, men teamet bestemmer rekkefølgen som de vil utvikle ordrereserven elementer. Jeg har aldri sett et Scrum team ikke kan velge å jobbe på den høyeste prioritet. Og et Scrum-team vil svært sannsynlig velge å jobbe på den nest viktigste., Men på et tidspunkt en av de høyt prioriterte elementer kan ikke være en god plass for sprint under planlegging—kanskje en nøkkel person som skal jobbe på den, vil bli overbelastet med arbeid på høyere prioritet elementer. Eller kanskje er det fornuftig å jobbe på en litt lavere prioritet (la oss si at #10 på produktkøen i stedet for #6) fordi teamet skal jobbe i koden der #10 ville bli implementert.
- Scrum ikke foreskrive noen engineering praksis; XP gjør., Jeg elsker XP engineering praksis, spesielt ting som test-drevet utvikling, fokuserer på automatisert testing, par programmering, enkel design, refactoring, og så videre. Men, jeg tror det er en feil å si til team «du er self-organizing, vi stoler på deg, men du må gjøre disse spesifikke engineering praksis….»Dette sender et blandet melding til laget som fører til forvirring. Jeg elsker XP praksis, men ikke som et påbud om dem. Jeg vil lagene til å oppdage verdien på sine egne.
Disse er små og ofte subtile forskjeller mellom Scrum og XP., De kan imidlertid ha en betydelig innvirkning på laget. Min typiske råd til lagene er «start med Scrum og deretter oppfinne din egen versjon av XP.»XP praksis er fantastiske, men de fungerer best og lag forplikte seg til dem mest stridently hvis de oppdage dem selv i stedet for å ha dem mandat. Jeg hjelpe lagene gjør dette i min coaching ved å stille spørsmål som «Ville denne feilen har skjedd hvis vi hadde holdt test-drevet utvikling?»og «Ville vi ha gjort som feil hvis vi var sammenkobling?» Jeg finne sann XP til å være et lite mål i det fjerne., Hvis et lag kan ta sikte på det og traff blinken, fantastisk. Hvis ikke, men det er sannsynlig at de hacking (f.eks., refactoring uten noen automatisert testing eller TDD). Scrum er en stor bull ‘ s eye som på egen hånd, gir store forbedringer bare gjennom ekstra fokus og en tidsboks iterasjoner. Det er et godt utgangspunkt for deretter å legge XP praksis.