Extractos 3 - del libro SCRUM Y XP DESDE LAS TRINCHERAS de Henrik Kniberg

Por qué insistimos en que todos los equipos hagan retrospectivas 

Lo más importante de las retrospectivas es asegurarse de que tienen lugar. Aun así, todo el mundo coincide en que las retrospectivas son extremadamente  útiles. De hecho, yo diría que la retrospectiva es el segundo evento más importante de Scrum (siendo el primero la reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para mejorar! 

Difundiendo las lecciones entre los equipos

Reglas importantes para la persona que actúa como “puente de conocimiento”:

• Debería ser bueno escuchando. 

• Si la retrospectiva es poco activa, debería estar listo para realizar preguntas simples pero bien apuntadas para estimular la discusión dentro del grupo. Por ejemplo, “si pudierais rebobinar y hacer este Sprint otra vez desde el día 1, ¿qué haríais de forma diferente?” 

• Debe estar dispuesto a pasar tiempo visitando todas las retrospectivas de todos los equipos. 

• Debería tener algún tipo de autoridad, de forma que pueda actuar sobre las sugerencias que estén fuera del control del propio equipo.

Descansos entre Sprints 

Como mínimo, intentamos que la retrospectiva y la subsiguiente reunión de planificación de Sprint no ocurran el mismo día. Todo el mundo debería tener al menos una buena noche de sueño sin Sprint antes de comenzar el siguiente Sprint.

Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación. Esa es la razón de que funcionen tan bien juntas: tratan de áreas diferentes y se complementan entre ellas. 

Ritmo sostenible / trabajo enérgico

Hace cosa de un año uno de nuestros equipos (el más grande) estaba trabajando un número insalubre de horas extra. La calidad de la base de código era pésima y habían pasado la mayor parte del tiempo apagando fuegos. El equipo de pruebas (que también estaba haciendo horas extra) no tenía ninguna 

posibilidad de hacer aseguramiento de la calidad en condiciones. Nuestros usuarios estaban enfadados y la prensa nos estaba devorando vivos. Después de unos meses conseguimos disminuir las horas de trabajo a un nivel decente. La gente comenzó a trabajar en horarios normales (excepto durante 

algunas crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron notablemente. Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.

Cómo hacemos pruebas 

Nuestra experiencia nos dice que eso rara vez funciona. Habrán errores graves. Si la calidad tiene algún valor para ti, es necesario algún tipo de fase de pruebas de aceptación manuales. Se trata de que encargados de pruebas dedicados que no son parte del equipo machaquen el sistema con ese tipo de pruebas que el equipo de Scrum no pudo imaginar, o no tuvo tiempo de hacer o no contaban con el hardware necesario para implementar. Los encargados de pruebas acceden al sistema en la forma exacta en la que los usuarios finales lo harán, lo que significa que debe hacerse manualmente (asumiendo que tu sistema sea para usuarios humanos).

Así que ¿cómo maximizamos la calidad del código desarrollado por el equipo Scrum? Bueno, hay muchas maneras. He aquí dos que nos funcionan muy bien: 

• Incluir encargados de pruebas en el equipo Scrum - Me parece una buena práctica aunque las empresas consideren que no es necesario.

• Hacer menos cosas en cada Sprint.

El encargado de pruebas es quien da el visto bueno.

Un bonito efecto secundario de esta práctica es que el equipo tiene ahora una persona que está perfectamente preparada para organizar la Demo del Sprint.