Scrum en Extreme Programming (XP) zijn zeker erg uitgelijnd. In feite, als je liep in op een team doen van een van deze processen zou het moeilijk kunnen zijn om snel te beslissen of je had gelopen in op een Scrum team of een XP-team. De verschillen zijn vaak heel subtiel, maar ze zijn belangrijk. Ik denk dat er vier belangrijke verschillen zijn tussen Scrum en XP:
- Scrum teams werken meestal in iteraties (sprints genoemd) die van twee weken tot een maand lang zijn., XP-teams werken meestal in iteraties die één of twee weken lang zijn.
- Scrum teams staan geen wijzigingen toe in hun sprints. Zodra de sprint planningsvergadering is voltooid en een toezegging is gedaan om een set Product backlog items te leveren, blijft die set items onveranderd tot het einde van de sprint. XP teams zijn veel meer vatbaar voor verandering binnen hun iteraties. Zolang het team niet is begonnen met het werken aan een bepaalde functie, kan een nieuwe functie van gelijke grootte worden omgezet in de iteratie van het XP-team in ruil voor de unstarted functie.,
- Extreme Programmeerteams werken in een strikte volgorde van prioriteit. De te ontwikkelen functies worden geprioriteerd door de klant (Scrum ‘ s producteigenaar) en het team moet er in die volgorde aan werken. De Scrum-producteigenaar geeft daarentegen prioriteit aan de productachterstanden, maar het team bepaalt de volgorde waarin zij de achterstanden zullen ontwikkelen. Ik heb nog nooit een Scrum team zien kiezen om niet te werken aan het hoogste prioriteit item. En een Scrum team zal zeer waarschijnlijk kiezen om te werken aan de tweede belangrijkste., Echter, op een gegeven moment een van de hoge prioriteit items misschien niet een goede pasvorm voor de sprint wordt gepland—misschien een belangrijke persoon die zou moeten werken aan het zal worden overspoeld door het werk aan hogere prioriteit items. Of misschien is het zinvol om te werken aan een iets lagere prioriteit item (laten we zeggen #10 op de product backlog in plaats van #6) omdat het team zal werken in de code waar #10 zou worden geïmplementeerd.
- Scrum schrijft geen technische praktijken voor; XP wel., Ik hou van de XP engineering praktijken, in het bijzonder dingen als test-driven ontwikkeling, de focus op geautomatiseerde testen, paar programmering, eenvoudig ontwerp, refactoring, enzovoort. Ik denk echter dat het een vergissing is om tegen het team te zeggen: “Je bent zelforganiserend, we vertrouwen je, maar je moet deze specifieke technische praktijken doen….”Dit stuurt een gemengde boodschap naar het team dat verwarring veroorzaakt. Ik hou van de XP praktijken, maar hou niet van het mandateren van hen. Ik wil dat teams de waarde zelf ontdekken.
Dit zijn kleine en vaak subtiele verschillen tussen Scrum en XP., Ze kunnen echter een grote impact hebben op het team. Mijn typische advies aan teams is ” begin met Scrum en verzin dan je eigen versie van XP.”De XP-praktijken zijn geweldig, maar ze werken het beste en teams committeren zich aan hen de meest opvallende als ze ontdekken ze zelf in plaats van het hebben van hen gemandateerd. Ik help teams dit te doen in mijn coaching door vragen te stellen als: “zou deze bug zijn gebeurd als we testgedreven ontwikkeling hadden gedaan?”en” zouden we die fout hebben gemaakt als we zouden paren?”Ik vind true XP een klein doelwit in de verte., Als een team daarop kan richten en de roos raken, geweldig. Zo niet, dan zijn ze waarschijnlijk hacken (bijvoorbeeld refactoring zonder enige geautomatiseerde testen of TDD). Scrum is een grote bull ‘ s eye die op zijn eigen brengt grote verbeteringen gewoon door de extra focus en de timeboxed iteraties. Dat is een goed uitgangspunt voor het toevoegen van de XP praktijken.