Scrum y Extreme Programming (XP) están definitivamente muy alineados. De hecho, si entraste en un equipo haciendo uno de estos procesos, es posible que te cueste decidir rápidamente si entraste en un equipo de Scrum o en un equipo de XP. Las diferencias son a menudo bastante sutiles, pero son importantes. Creo que hay cuatro diferencias principales entre Scrum y XP:
- Los equipos Scrum normalmente trabajan en iteraciones (llamadas sprints) que duran de dos semanas a un mes., Los equipos de XP suelen trabajar en iteraciones que duran una o dos semanas.
- Los Equipos Scrum no permiten cambios en sus sprints. Una vez que se completa la reunión de planificación de sprint y se asume el compromiso de entregar un conjunto de elementos del backlog de productos, ese conjunto de elementos permanece sin cambios hasta el final del sprint. Los equipos de XP son mucho más susceptibles de cambiar dentro de sus iteraciones. Siempre y cuando el equipo no haya comenzado a trabajar en una característica en particular, una nueva característica de tamaño equivalente se puede intercambiar en la iteración del equipo de XP a cambio de la característica no iniciada.,
- Los equipos de programación extrema trabajan en un orden de prioridad estricto. Las características a desarrollar son priorizadas por el Cliente (Propietario del producto de Scrum) y el equipo debe trabajar en ellas en ese orden. Por el contrario, el propietario del producto Scrum prioriza el backlog del producto, pero el equipo determina la secuencia en la que desarrollará los elementos del backlog. Nunca he visto a un equipo de Scrum no elegir trabajar en el elemento de mayor prioridad. Y es muy probable que un equipo de Scrum elija trabajar en el segundo más importante., Sin embargo, en algún momento uno de los elementos de alta prioridad puede no ser un buen ajuste para el sprint que se planea—tal vez una persona clave que debería trabajar en él será inundado por el trabajo en los elementos de mayor prioridad. O tal vez tenga sentido trabajar en un elemento de prioridad ligeramente inferior (digamos #10 en el backlog del producto en lugar de #6) porque el equipo estará trabajando en el código donde se implementaría el #10.
- Scrum no prescribe ninguna práctica de ingeniería; XP sí., Me encantan las prácticas de ingeniería de XP, particularmente cosas como el desarrollo basado en pruebas, el enfoque en pruebas automatizadas, programación de pares, Diseño simple, refactorización, etc. Sin embargo, creo que es un error decirle al equipo «eres autoorganizado, confiamos en ti, pero debes hacer estas prácticas de ingeniería específicas….»Esto envía un mensaje mixto al equipo que causa confusión. Me encantan las prácticas de XP, pero no me gusta mandarlas. Quiero que los equipos descubran el valor por su cuenta.
estas son pequeñas y a menudo sutiles diferencias entre Scrum y XP., Sin embargo, pueden tener un profundo impacto en el equipo. Mi consejo típico para los equipos es » comienza con Scrum y luego inventa tu propia versión de XP.»Las prácticas de XP son maravillosas, pero funcionan mejor y los equipos se comprometen con ellas de la manera más estridente si las descubren ellos mismos en lugar de tenerlas encomendadas. Ayudo a los equipos a hacer esto en mi entrenamiento haciendo preguntas como: «¿habría ocurrido este error si hubiéramos estado haciendo un desarrollo impulsado por pruebas?»y» ¿habríamos cometido ese error si estuviéramos emparejados?»Me parece que la verdadera XP es un pequeño objetivo en la distancia., Si un equipo puede apuntar a eso y dar en el blanco, maravilloso. Si no, sin embargo, es probable que estén pirateando (por ejemplo, refactorizando sin ninguna prueba automatizada o TDD). Scrum es un gran ojo de buey que por sí solo trae grandes mejoras simplemente a través del enfoque adicional y las iteraciones con tiempo fijo. Ese es un buen punto de partida para luego agregar las prácticas de XP.