Scrum y XP desde las trincheras

Aunque ya lo he leído hace algún tiempo, ahora mismo siento la necesidad de releer el libro de Henrik Kniberg “Scrum & XP from the trenches” (“Scrum y XP desde las trincheras” en su traducción al español ) en busca de ideas que aplicar para tratar de incorporarlas en las nuevos proyectos que voy a comenzar.

En este libro, disponible para su descarga gratuita, Henrik Kniberg cuenta sus propias experiencias durante la implantación de Scrum en la empresa en la que estaba trabajando. En él expone sus ideas acerca de cómo usar la metodología de desarrollo ágil Scrum.

El libro, con prólogos por parte de Jeff Sutherland y Mike Cohn, consta de los siguientes capítulos:

1. Introducción: Según el propio creador de Scrum, Ken Schwaber, Scrum no es una metodología, sino un marco de trabajo y, por tanto, no dice exactamente qué es lo que hay que hacer. Sin embargo, en este libro, Henrik Kniberg sí que dice qué es exactamente lo que él hace para aplicar Scrum. A pesar de ello, previene de que Scrum es una metodología que debe adaptarse a la situación específica de cada proyecto.


2. Cómo hacemos las pilas de producto: La pila de producto es una lista priorizada de requisitos o “historias” del cliente escritos usando su propia terminología, de forma no técnica.


3. Cómo nos preparamos para la planificación de sprint: El propietario de la pila de producto debe tener ésta ya preparada para cuando se va a planificar un sprint. El propietario debe comprender todas las historias de usuario y asignarlas una importancia.


4. Cómo hacemos la planificación de sprint: La reunión de planificación de sprint es la actividad más crítica de Scrum. La meta de esta reunión es definir un objetivo, la lista de miembros del equipo implicados, la lista de tareas que se desarrollarán, una fecha de demostración y un lugar y hora para la reunión de scrum diaria. En ellas, el propietario de producto y el equipo negocian sobre el alcance de cada sprint en base a las estimaciones y a la importancia de cada una de las historias.


5. Cómo comunicamos los sprints: Es necesario informar a todo el mundo de qué está ocurriendo en cada sprint. Para ello, después de la reunión de planificación del sprint se debe redactar una hoja de información del sprint que recoja los objetivos que se han definido. Esta hoja debe publicarse para todo el mundo.


6. Cómo hacemos las pilas de sprint: Después de la reunío de planificación de sprint y antes de la primera reunión de scrum diaria, el Scrum master debe crear la pila de sprint. La pila de sprint es la lista de tareas que se realizan durante el sprint, con gráficos de avance de estas tareas (burndown). La forma más efectiva de mostrar la pila de sprint es mediante un tablón en la pared.


7. Cómo distribuímos la sala del equipo: Las discusiones más interesantes tienen lugar de forma espontánea delante de una pizarra donse se puedan pintar diagramas o gráficos de diseño. Los miembros del equipo se pueden reunir en frente de esta pizarra y discutir sobre el diseño en cualquier momento. También es importante que los miembros del equipo se sienten junto para fomentar la comunicación entre ellos. El propietario del producto no debe estar sentado con el equipo para que no sienta la tentación de medrar en los detalles, pero debe sí estar accesible para el equipo por si surge alguna duda y hay que preguntarle. El resto de la gente no debe interferir para nada con el equipo.


8. Cómo hacemos los scrums diarios: El mejor sitio para el scrum diario es delante del tablón con la pila de scrum. Durante la reunión, que no debe durar mucho más de 15 minutos, se debe actualizar el tablón con los avances que el equipo ha realizado.


9. Cómo hacemos la demo de sprint: El hecho de tener que hacer demostraciones al final de cada sprint fuerza al equipo a tener algo hecho que mostrar y fomenta lo comunicación sobre lo que se está haciendo dentro del equipo y con otros equipos que asistan a la demostración. Las demostraciones además permiten obtener realimentación sobre el proyecto por parte del cliente.


10. Cómo hacemos las restrospectivas de sprint: La retrospectiva es la segunda tarea más importante, puesto que es la que premite mejorar. La restrospectiva es una reunión que tiene lugar al final de cada sprint donde el equipo expone sus ideas sobre qué cosas se pueden hacer mejor.


11. Descansos entre sprints: Después de cada sprint, que pueden ser muy intensos, es necesario un tiempo de descanso que permita además asimilar nuevas ideas o información.


12. Cómo hacemos la planificación de entregas y los contratos de precio fijo: En algunos casos, normalmente unidos a un contrato de precio fijo, es necesario planificar con antelación las entregas de varios sprints posteriores. Para ello el propietario del producto necesita estimaciones de las tareas incluidas en el contrato, que se deben haber realizado de forma conjunta con el equipo. En función de estas estimaciones y la velocidad del equipo se establece el plan de entregas a lo largo de los siguientes sprints. Este plan puede ser modificado a medida que surgen cambios según el proceso avanza.


13. Cómo combinamos Scrum con XP: Scrum y XP se complementan a la perfección, puesto que Scrm se centra en la gestión y la organización del proyecto y XP se centra en las prácticas de programación. Algunas de las prácticas de XP son también parte inherente de Scrum, como el concepto de equipo, sentarse juntos, las historias de usuario y el juego de la planificación. Además, hay otras prácticas de XP que se complementan con Scrum, como la programación en parejas, el desarrollo guiado por pruebas (TDD), el diseño incremental, la integración continua, la propiedad colectiva del código y su estandarización y el trabajo a un ritmo enérgico pero sostenible.


14. Cómo hacemos pruebas: Esta es la parte más difícil del desarrollo de software y la más variable entre distintas organizaciones. Es necsario realizar algún test de aceptación manual antes de dar un trabajo por realizado. Sin embargo, se puede reducir esta fase de test aumentando la calidad del código entregado y aumentando la eficiencia de las pruebas automáticas realizadas. O, incluso, incluir que algún miembro del equipo realice tareas de tester. El tester será la persona que certifique que una tarea está completamente terminada. Las pruebas de aceptación no encajan bien dentro del ciclo de un sprint, por lo que se definen ciclos de aceptación fuera del sprint.


15. Cómo manejar múltiples equipos Scrum: Los equipos demasiado grandes no se adaptan bien a las prácticas de Scrum porque la comunicación entre todos los miembros es mucho más difícil. Es preferible tener varios equipos pequeños que uno grande, si el proyecto lo permite. El número ideal de personas parece estar entre 5 y 9 personas.


16. Cómo gestionamos equipos distribuidos geográficamente: Aquí se discuten distintas formas de gesrionar equipos distribuídos, que pueden ser bien distintos equipos en localizaciones distintas o un mismo equipo con miembros distribuídos.


17. Lista de comprobación del Scrum Master: Aquí se listan las tareas administrativas del Scrum Master, tareas que debe realizar al comienzo, durante y al final de cada sprint.

Este libro es una introducción estupenda a Scrum y permite comenzar a usar esta metodología siguiendo las ideas que en él se exponen. Luego, a través de la práctica, se pueden ir perfeccionando las prácticas en base a aquello que resulte realmente valioso.

Referencias:
Scrum & XP from the trenches
Scrum y XP desde las trincheras