Ya tenía ganas de escribir este post. Hoy traigo la explicación de una práctica ágil interesante, motivadora, … ¡de lo mejor! Pelotazo en nuestros equipos y encima original… hay que leer el artículo de hoy con detalle.
La leyenda
En los equipos que tenemos en Kaleidos no hay un miembro que se dedique en exclusiva a pruebas y al aseguramiento de la calidad (QA). Entendiendo ésta como comprobar que las historias cumplen los tests de aceptación, el código que las crea, los tests unitarios, etc.
Siempre habíamos echado de menos a alguien detrás de la defensa, por si se nos escapaba algo, pero no queríamos dedicar a alguien en exclusiva. Aparte de lo aburrido que sería, va en contra de los equipos multidisciplinares.
Los intentos que hicimos con la revisión de las historias por parejas no funcionaron muy bien. No sabíamos muy bien a quién asignar la tarea y por iniciativa propia, todo el mundo pensaba que tenía mejores cosas tareas más prioritarias que hacer que probar el trabajo de otro que además se supone que funciona.
Así que con este cuadro, veíamos que llegábamos a las Revisiones de Sprint con alguna laguna y bastantes bugs.
Hasta que llegó la CAS 2011 (sí, hace más de un año) y uno de los Super-Tips que nos trajimos fue el Pirata Roberts. El detalle de la leyenda lo tenéis en el enlace, pero lo que nos atañe, es que el Pirata Roberts, siempre existió y existirá, porque cada cierto tiempo uno nuevo toma el lugar del anterior…, cada Sprint concretamente.
Update 5 de Febrero de 2013
Que sepas que si hablas con alguien de @kaleidosnet tienes que venir con la Princesa Prometida vista de casa. 🙂
Las misiones
El Pirata Roberts es un rol que rota entre todos los miembros del equipo, cambiando en cada Sprint, durante el cual tiene que realizar varias tareas, pero la más importante es que es el responsable de la calidad de lo que se está desarrollando y se va a entregar.
Cuando un miembro del equipo termina el desarrollo de una historia la pasa a «Ready for Test» y es el Pirata (como le llamamos ya de forma coloquial) el que la pasa a «Closed» antes del fin del sprint, confirmando así que cumple el comportamiento esperado. Ante cualquier error o duda se echa para atrás y se revisa.
Inmediatamente hemos aumentado la calidad del producto.
Pero el Pirata Roberts se encarga de más cosas:
- Realiza la demo de producto en el «Sprint Review».
- Gestiona la recepción de correos «monstruo» de clientes, liberando así al equipo de abrir un powerpoint con capturas de pantalla o dar de alta 50 bugs que iban dentro de un único correo.
- Realiza el «Backlog Grooming«, comprobando que las historias de lo más alto de la pila no tienen carencias graves, preparando la reunión de planificación.
- Comprueba la calidad del código y sus tests, jenkins, cobertura, etc.
- Despliega la versión en el servidor de integración, pre, o producción.
- … y cualquier tarea de gestión pesada.
Son muchas tareas posibles, pero cada equipo las adapta según su necesidad.
Los beneficios
El gran beneficiado es el producto, que llega al final del sprint mucho más probado y con menos incertidumbre.
Pero no lo es menos el propio miembro del equipo al que le toque ser Pirata. Es un gran trabajo y una gran responsabilidad, pero se compensa con el conocimiento que se obtiene de toda la aplicación al tener que probar todas las historias de un sprint, preparar la demo, responder correos, etc.
El equipo es más multidisciplinar y se disminuye el peligro del Bus Factor.
¿Cómo garantizas el QA?
¿Te parece interesante esta propuesta? Creemos que es singular en el modo rotatorio, pues esta tarea suele estar asignada a alguien. ¿Cómo lo resuelves en tu equipo?
Aprovecharé para explicar en detalle esta práctica en el Open Space QA y Agile que se realizará el próximo 16 de Febrero, ¡así que nos vemos allí!
lifetime.day.each() { enjoy() } 