Forskelle Mellem Scrum og Extreme Programming

Scrum og Extreme Programming (XP) er helt sikkert meget på linie. Faktisk, hvis du gik ind på et hold, der udførte en af disse processer, har du måske svært ved hurtigt at beslutte, om du havde gået ind på et Scrum-team eller et .p-team. Forskellene er ofte ret subtile, men de er vigtige. Jeg tror, at der er fire hovedforskelle mellem Scrum og .p:

1. Scrum-hold arbejder typisk i iterationer (kaldet sprints), der er fra to uger til en måned lang., XP-hold arbejder typisk i iterationer, der er en eller to uger lange.
2. Scrum – hold tillader ikke ændringer i deres sprints. Når sprintplanlægningsmødet er afsluttet, og der er forpligtet sig til at levere et sæt produktefterslæb, forbliver det sæt varer uændret gennem slutningen af sprinten. XP-hold er meget mere modtagelige for at ændre sig inden for deres iterationer. Så længe holdet ikke er begyndt at arbejde på en bestemt funktion, kan en ny funktion af tilsvarende størrelse byttes til XP-holdets iteration i bytte for den ikke-startede funktion.,
3. ekstreme programmeringshold arbejder i en streng prioriteret rækkefølge. Funktioner, der skal udvikles, prioriteres af kunden (Scrums produktejer), og teamet er forpligtet til at arbejde på dem i den rækkefølge. Derimod prioriterer Scrum product o .ner product Backloggen, men teamet bestemmer i hvilken rækkefølge de vil udvikle Backloggen. Jeg har aldrig set et Scrum-team, der ikke vælger at arbejde på det højeste prioriterede emne. Og et Scrum-team vil meget sandsynligt vælge at arbejde på det næstvigtigste., Imidlertid, på et tidspunkt er et af de højt prioriterede emner muligvis ikke en god pasform til sprinten, der planlægges—måske vil en nøgleperson, der skal arbejde på det, blive oversvømmet af arbejde med emner med højere prioritet. Eller måske giver det mening at arbejde på et lidt lavere prioriteret emne (lad os sige #10 på produkt Backloggen i stedet for #6), fordi teamet vil arbejde i koden, hvor #10 ville blive implementeret.
4. Scrum foreskriver ikke nogen ingeniørpraksis; XP gør det., Jeg elsker XP teknisk praksis, især ting som test-drevet udvikling, fokus på automatiseret test, par-programmering, enkelt design, refactoring, og så videre. Jeg synes dog, det er en fejl at sige til teamet “du er selvorganiserende, vi stoler på dig, men du skal udføre disse specifikke ingeniørpraksis….”Dette sender en blandet besked til holdet, der skaber forvirring. Jeg elsker practicesp praksis, men kan ikke lide mandat dem. Jeg vil have hold til at opdage værdien på egen hånd.

disse er små og ofte subtile forskelle mellem Scrum og .p., De kan dog have en dybtgående indflydelse på holdet. Mit typiske råd til teams er “start med Scrum og opfinde derefter din egen version af .p.”XP-praksis er vidunderlige, men de fungerer bedst, og hold forpligter dem mest hårdt, hvis de opdager dem selv snarere end at have dem mandat. Jeg hjælper teams med at gøre dette i min coaching ved at stille spørgsmål som: “ville denne fejl være sket, hvis vi havde lavet testdrevet udvikling?”og” ville vi have begået den fejl, hvis vi parrede?”?? Jeg finder truepp at være et lille mål væk i afstanden., Hvis et hold kan sigte mod det og ramme tyrens øje, vidunderligt. Hvis ikke, men de er sandsynligvis hacking (f ref refactoring uden nogen automatiseret test eller TDD). Scrum er en stor plet, der alene bringer store forbedringer blot gennem det ekstra fokus og timebo .ed iterationer. Det er et godt udgangspunkt for derefter at tilføje practicesp-praksis.