Banner

Ultima revisión 13/11/2012

Diferencias entre Scrum y XP

Scrum es un marco de trabajo iterativo e incremental que está enfocado a la gestión de procesos de desarrollo, equipos de mantenimiento de software, o en una aproximación de gestión de programas.

XP, por su parte, es una metodología de desarrollo de la ingeniería de software, formulada por Kent Beck, que considera que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son:

RolDefinición
Mantiene los procesos y trabaja de forma similar al director de proyecto. Su trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Representa a los stakeholders (interesados externos o internos). Dicho de otra manera, representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Incluye a los desarrolladores. El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
Son un grupo de personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
Son las personas que establecen el ambiente para el desarrollo del producto.

Durante cada sprint, periodo definido por cada equipo que normalmente es de entre una y cuatro semanas, el equipo crea una nueva versión de software potencialmente entregable, utilizable o usable. El conjunto de características que forma parte de cada sprint viene dado por el Product Backlog:

El Product Backlog es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Dueño del producto identifica los elementos del Product Backlog que quiere ver completados y se los transmite al equipo que determina la cantidad de ese trabajo que puede comprometerse a completar durante el sprint de se está definiendo. Mientras dure el sprint, nadie puede cambiar el Sprint Backlog (los requisitos e hitos marcados para el Sprint) o lo que es lo mismo, los requisitos quedan congelados durante el sprint.

esquema-scrum

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Características de XP

XP se basa en unos valores que son:

RolDefinición
Se simplifica todo lo que se puede para agilizar el desarrollo y facilitar el mantenimiento.
El código es entendido mejor cuanto más simple sea. Comentar dentro del código en una buena práctica de comunicación.
El cliente es parte fundamental del equipo y su opinión se conoce en tiempo real. Esto minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Realizar pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
Hay que diseñar para hoy, no para el mañana. Esto simplifica el código y se convierte en requerimientos de tiempo menores y eso hace sentir a los programadores más cómodos, pero también hay que tener en cuenta que se tendrá que reconstruir el código cuando sea necesario
No realizar cambios que hagan que las pruebas existentes fallen o demore el trabajo de los demás.

esquema-XP

Las características fundamentales son:

CaracterísticaExplicación
Pequeñas mejoras, unas tras otras.
Frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad.
Reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Conclusión

SCRUMXP
Es una metodología de desarrollo ágil basada en la administración del proyecto. Es una metodología de desarrollo que está más centrada en la programación o creación del producto.
Cada miembro de del equipo trabaja de forma indivisual. Los miembro del equipo programan en parejas.
Las ietraciones de entrega son de 1 a 4 semanas. Las ietraciones de entrega son de 1 a 3 semanas
Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca. Si funciona y está bién, se aparta y a otra cosa. Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
Trata de seguir el orden de prioridades que marca el Product Owneren el Sprint Backlog pero puede cambiarlo si es mejor para el desarrollo de la tareas. El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.