Programación extrema vs SCRUM | XP vs SCRUM
Ha habido varias metodologías de desarrollo de software diferentes utilizadas en la industria del software a lo largo de los años, como el método de desarrollo Waterfall, V-Model, RUP y algunos otros métodos lineales, iterativos y combinados lineales-iterativos. El modelo ágil (o más correctamente, un grupo de metodologías) es un modelo de desarrollo de software más reciente introducido por el manifiesto Agile para abordar las deficiencias encontradas en esas metodologías tradicionales de desarrollo de software.
Los métodos ágiles se basan en el desarrollo iterativo y utilizan los comentarios de los usuarios como principal mecanismo de control. Agile se puede llamar un enfoque centrado en las personas que los métodos tradicionales. El modelo ágil ofrece una versión funcional del producto muy temprano al dividir el sistema en subpartes muy pequeñas y manejables, para que el cliente pueda obtener algunos de los beneficios desde el principio. El tiempo de ciclo de prueba de Agile es relativamente corto en comparación con los métodos tradicionales, porque las pruebas se realizan en paralelo al desarrollo. Debido a todas estas ventajas, los métodos ágiles se prefieren sobre las metodologías tradicionales en este momento. La programación Scrum y Extreme son dos de las variaciones más populares de los métodos ágiles.
¿Qué es SCRUM?
Como se mencionó anteriormente, SCRUM es un proceso de gestión de proyectos incremental e iterativo, que pertenece a la familia de métodos ágiles. SCRUM se basa en dar una alta prioridad a la participación del cliente al principio del ciclo de desarrollo. Recomienda incorporar pruebas por parte del cliente lo antes posible y con la mayor frecuencia posible. Las pruebas se realizan en cada punto cuando se encuentra disponible una versión estable. La base de SCRUM se basa en comenzar las pruebas desde el principio del proyecto y continuar hasta el final del proyecto.
El valor clave de SCRUM es que “la calidad es responsabilidad del equipo”, que enfatiza que la calidad del software es responsabilidad de todo el equipo (no solo del equipo de pruebas). Otro aspecto importante de SCRUM es dividir el software en partes manejables más pequeñas y entregarlas al cliente muy rápidamente. Entregar un producto funcional es de suma importancia. Luego, el equipo continúa mejorando el software y entregando continuamente en cada paso importante. Esto se logra teniendo ciclos de lanzamiento muy cortos (llamados sprints) y obteniendo retroalimentación para mejorar al final de cada ciclo.
SCRUM define varios roles clave para el buen funcionamiento de un equipo de desarrollo. Son el propietario del producto (que representa al cliente y mantiene la cartera de pedidos del producto), Scrum master (que actúa como organizador y coordinador del equipo mediante la realización de reuniones de scrum, el mantenimiento de la acumulación de sprints y los gráficos quemados) y otros miembros del equipo. Un equipo puede constar de roles tradicionales, pero en su mayoría son equipos autogestionados. Los principales artefactos de Scrum son el backlog de producto / backlog de lanzamiento (lista de deseos), el backlogs de Sprint / backlogs de defectos (tareas en cada iteración), gráficos de quemado (trabajo restante vs. fecha). Las ceremonias principales de SCRUM son la reunión de la cartera de productos, la reunión de Sprint y la reunión de Retrospect.
¿Qué es la programación extrema?
Extreme Programming (abreviado XP) es una metodología de desarrollo de software que pertenece al modelo Agile. La programación extrema lleva a cabo fases en pasos continuos muy pequeños (en comparación con los métodos tradicionales). El primer pase, que toma solo un día o una semana, está intencionalmente incompleto. Para proporcionar objetivos concretos para el desarrollo del software, las pruebas automatizadas se escriben al principio. Luego, los desarrolladores hacen la codificación. La atención se centra en realizar la programación por parejas. Una vez que pasan todas las pruebas, la codificación se considera completa. La siguiente fase es el diseño y la arquitectura, que se ocupa de la refactorización del código por parte del mismo conjunto de programadores. Al final de esta fase, se presenta un producto incompleto (pero funcional) a las partes interesadas. Inmediatamente después de esto, comienza la siguiente fase (que se centra en el siguiente conjunto de características más importantes).
¿Cuál es la diferencia entre Extreme Programming y SCRUM?
Extreme Programming y SCRUM son, comprensiblemente, metodologías muy similares y alineadas. Sin embargo, existen diferencias sutiles pero importantes entre estos dos métodos. Los sprints de SCRUM duran de 2 a 4 semanas, mientras que las iteraciones típicas de XP son más cortas (duran de 1 a 2 semanas). Por lo general, los equipos SCRUM no permiten cambios en los sprints, pero los equipos XP son un poco más flexibles a los cambios dentro de las iteraciones. Por ejemplo, después de la planificación del sprint, el conjunto de elementos de ese sprint permanece sin cambios, pero una característica en la que no ha comenzado a funcionar se puede cambiar en cualquier momento por alguna otra característica en XP. Otra diferencia entre XP y SCRUM es que el orden de las características desarrolladas en XP es estrictamente priorizado por el cliente, mientras que el equipo de SCRUM decide el orden de los artículos (después de que el propietario del producto de SCRUM prioriza la acumulación de productos).
A diferencia de XP, SCRUM no establece prácticas de ingeniería. Por ejemplo, XP se basa en prácticas como el desarrollo basado en pruebas (TDD), la programación de pares, la refactorización, etc. Sin embargo, algunos creen que imponer un conjunto de prácticas a los equipos autoorganizados podría tener un impacto negativo, y esto puede considerarse una deficiencia de XP. Otro defecto de la programación extrema es que los equipos sin experiencia pueden tender a refactorizar sin pruebas automatizadas o TDD (o simplemente piratería). Por lo tanto, algunos sugieren que SCRUM es mejor para mirar fijamente (ya que trae grandes mejoras simplemente a través de iteraciones de tiempo específico) y XP es adecuado para equipos un poco maduros que han descubierto el valor de las prácticas mencionadas anteriormente (en lugar de usarlas porque se les ha pedido para hacerlo).
