Algo que me molesta desde hace tiempo es lo común que es para muchos en la industria utilizar términos como «Scrum pero…» en un sentido peyorativo, dando a entender que los equipos sólo deben seguir el pequeño conjunto de prácticas que forman parte de Scrum. La realidad es que para que cualquier equipo ágil sea capaz de entregar repetidamente software que funcione durante un período de tiempo significativo, Scrum por sí mismo no es suficiente. Se den cuenta o no, la gran mayoría de los equipos que se llaman a sí mismos equipos Scrum están operando como un híbrido Scrum-XP, o un híbrido Scrum-Kanban-XP, donde emplean al menos un subconjunto de las prácticas técnicas que se originaron con XP.
Permítanme decir que los equipos que sólo están siguiendo las prácticas de Scrum es poco probable que tengan éxito a largo plazo, porque al menos un subconjunto de las prácticas técnicas de XP son una necesidad para el éxito continuo como un equipo de entrega ágil.
He observado que no hay suficiente gente que entienda lo que incluye y no incluye Scrum, así que vamos a empezar por ahí.
Lo que es Scrum – un conjunto de prácticas de gestión
Scrum es la aplicación del control empírico del proceso, que es una forma elegante de decir que debemos tomar decisiones basadas en la experiencia, no basadas en algún conjunto hipotético de suposiciones que no se basan en la realidad.
Simplemente, Scrum consiste en un pequeño conjunto de prácticas de gestión que tienen por objeto ayudar a los equipos a colaborar de manera efectiva y entregar el trabajo de una manera iterativa (permítanme enfatizar una vez más – hay cero prácticas técnicas en Scrum).
Para resumir brevemente el contenido de la Guía de Scrum:
- Hay un Equipo Scrum, que se compone de los desarrolladores, el Product Owner, y el Scrum Master.
- Hay Eventos Scrum, que consisten en el Sprint, la Planificación del Sprint, el Scrum Diario (también conocido como Standup Diario, en XP), la Revisión del Sprint, y la Retrospectiva del Sprint.
- Hay Artefactos Scrum, que consisten en el Backlog del Producto, el Backlog del Sprint, y el Incremento, donde un Incremento existe tan pronto como un elemento del Backlog del Sprint cumple con la Definición de Hecho.
- Hay una Definición de Hecho, donde cualquier Equipo Scrum tiene una comprensión compartida de lo que significa «hecho» para cualquier elemento del Backlog del Producto. Tenga en cuenta que en contraste con los Criterios de Aceptación, la Definición de Hecho se aplica globalmente, mientras que los Criterios de Aceptación son específicos para los elementos individuales del Product Backlog.
Lo que Scrum no es
Contrariamente a la creencia popular, ninguna de las siguientes cosas son parte de Scrum:
- Historias de usuario. Los elementos de trabajo en cualquier equipo de Scrum Product Backlog o Sprint Backlog se escriben como historias de usuario (a menudo en el formato «Como <persona/rol>, quiero <objetivo>, para que <resultado deseado>»), pero Scrum no impone ninguna construcción o formato en particular. Tenga en cuenta que las historias de usuario son parte de XP.
- Estimación. A pesar de que la gran mayoría de los equipos de Scrum realizan la estimación en algún nivel, la práctica de la estimación no es parte de Scrum.
- Velocidad. La velocidad no es parte de Scrum tampoco; la noción de velocidad del proyecto es parte de XP.
- Prácticas técnicas. Como se señaló anteriormente, no hay ninguna noción de prácticas técnicas (CI, CD, programación en pares, TDD, etc.) en Scrum. La gran mayoría de las prácticas técnicas que los equipos suelen seguir se originaron con XP.
¿Qué es la Programación Extrema?
Hace más de dos décadas que se formó el primer equipo de Programación Extrema (XP), donde se trabajó en un proyecto llamado Compensación Integral de Chrysler (C3). Los métodos que empleó ese equipo se originaron en gran medida en la década de 1980, cuando Kent Beck y muchos otros estaban experimentando con mejores formas de desarrollar software, es decir, una alternativa al enfoque de «cascada» que se había vuelto dominante en ese momento.
Hacer que el trabajo sea visual siempre ha sido una forma importante de informar sobre cómo trabajan los equipos ágiles. Por lo tanto, como una introducción a XP, recomiendo que cualquiera que quiera aprender más estaría bien servido si comienza con estos diagramas:
- Proyecto de Programación Extrema (diagrama de extremo a extremo)
- Iteración (diagrama que se centra en lo que sucede dentro de una iteración; tenga en cuenta que lo que XP llama una iteración es conceptualmente similar a lo que Scrum llama un Sprint)
- Desarrollo (diagrama que se centra en las interacciones y actividades de desarrollo)
- Propiedad Colectiva del Código (diagrama que se centra en las prácticas técnicas fundamentales)
Nota: Para un visual que combina muchos de los elementos de los diagramas anteriores en una sola página, vea Extreme Programming Overview de Bill Wake.
Lectura adicional sobre XP
Si los visuales anteriores le intrigan lo suficiente como para querer leer más sobre XP, vea las siguientes fuentes de información, que están listadas más o menos en orden de lo más corto a leer > lo más largo a leer:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (ver también Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Prácticas básicas de la programación extrema (también conocidas como los 12 XpXtudes)
- Don Wells, Las reglas de la programación extrema
- Ward Cunningham, et al.,Programación extrema (también conocida como la WikiWikiWeb)
- Ron Jeffries, ¿Qué es la programación extrema?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Referencias adicionales
Todas las referencias en esta sección son del sitio web de XP de Don Wells, a menos que se indique lo contrario.
- Los modelos ágiles son pinturas, no fotografías (todos los modelos son erróneos; algunos son útiles)
- Proverbios del Proceso Ágil (palabras para que cualquier equipo pueda vivir con ellas)
- Bill Wake, Arrange, Act, Assert (patrón para escribir pruebas unitarias)
- Bill Wake, Sudoku Solver (interesante variación de TDD)
- Bill Wake, Tests from a Hat (un enfoque creativo hacia la escritura de pruebas unitarias)
- Planes honestos (cómo se ve la estimación en la práctica)
- Gestiona tus objetivos en lugar de actividades (principales diferencias entre el desarrollo en cascada y el ágil)
- Los valores de la programación extrema (Simplicidad, Comunicación, Retroalimentación, Respeto, Valor)
- XP y Bases de Datos (un patrón basado en bases de datos de oro > plata > bronce )