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() } 
Hola Antonio, ¡gran post!, se agradece y mucho.
No me ha quedado claro si un integrante de un equipo se pone en modo «Pirata» durante todo un sprint o durante todo el desarrollo del proyecto o si el papel de pirata se rota a lo largo del sprint entre los integrantes del equipo.
Thanks!
Hola César:
Efectivamente, el puesto de Pirata es rotario entre todos los miembros del equipo, cambiando en cada Sprint.
Actualicé esa parte del post:
«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.»
¡Gracias por tus comentarios! 🙂
Gracias, a lo mejor era muy temprano para mi cerebruuu 🙂
Aclarado y me parece una gran idea.
Saludos.
Hola Antonio,
No termino de entender por qué repartís en este rol «Pirata Roberts» tareas que en Scrum las asume el Dueño de Producto (la gestión del backlog fundamentalmente) y otras que asume el equipo de desarrollo (revisiones de código, despliegues…). Entiendo que estáis adaptando Scrum a vuestras necesidades y realidades, pero ojo con esto porque si no quedan claras las responsabilidades sobre los artefactos se puede ver afectado el ritmo sostenible. «El uno por el otro y la casa por barrer» 😉
Un cordial saludo,
JMB
Hola JM, gracias por el comentario:
El Pirata no gestiona el backlog, comprueba que las historias del top estén bien escritas y pregunta las dudas. De hecho es una tarea super light, no todos los miembros del equipo son capaces de ver si la historia es un marrón escondido.
La gestion, la priorizacion,la creación, la redacción,… son del cliente y/o miembro/s avanzado del equipo incluído (o con ayuda) de UX, no creo que pueda ser individual y rotatorio.
En cambio tareas más mecánicas como el despliegue de la versión del sprint en integración, o comprobar el nivel de cobertura sí que puede ser rotatorio.
Esta semana queremos añadir una revisión del código nuevo de manera más profunda para detectar carencias técnicas que puedan pasar desapercibidas, como una retro técnica. Y vemos que lo tiene que hacer un perfil senior en la tecnología.
Gracias y un saludo!
Antonio
[…] más sobre el Pirata leyendo este post del kaleider Antonio de la […]
La forma de llevar a cabo la idea es muy chula y divertida, os felicito por la creatividad!
El fondo me suena a solución de compromiso, la verdad… Y un wip-limit en la columna de testing, después de desarrollo? Podéis ver qué historias/funcionalidad habéis encontrado sin terminar, cuales no pasan la demo o la aceptación y evolucionar vuestra definición de terminado y la de *ready* que parece que también hay que revisar!!!! Además de métricas de calidad :o)
Con el enfoque *pirata* creo que se oscurecen algunos temas en los que puede trabajar todo el equipo en conjunto para mejorar 🙂
Hola Jorge:
Gracias por tu gran comentario, me encanta el debate que está saliendo de este post.
Has dado en el clavo, el WIP limit es real, el Pirata tiene que empezar a probar nada más que se terminen historias para que no le pille el toro.
Pero por la experiencia que estamos teniendo vemos que es muy beneficioso para salirte de tu zona de confort y preparar una demo de toda la aplicación. Además al ser rotatorio todos pasan por ello.
El resto de tareas que comentas está claro que van bajando de prioridad y como comento en la respuesta a JMBeas algunas son light y las debe hacer el equipo.
Gracias de nuevo y un saludo,
Antonio
[…] https://adelatorrefoss.wordpress.com/2013/02/04/pirata-roberts […]
Hola Antonio,
me gusta la idea que habéis propuesto. Respecto lo que dice Jose Manuel, si es cierto que, adaptar Scrum a nuestras necesidades es fundamental, pero sí hay que dejar las responsabilidades claras, sobre todo para que no hagan dos lo mismo o algo se quede sin hacer.
Me gusta que haya una persona encargada de preparar el despliegue. En mis proyectos hay un token de mantenimiento por Sprint, el que soluciona incidencias, apaga fuegos y prepara los despliegues. Pero la validación la hace el equipo, artículo que tengo pendiente publicar 🙂
Me preocupa, una cosa, ¿le da tiempo a una persona a hacer todas las validaciones? ¿qué pasa cuando no le da tiempo y alguna historias peligran? ¿El equipo ve al Pirata como un respaldo si algo no lo hace del todo bien? en plan, bueno esto lo dejo así, que si o vale ya me lo dirá él…
Sería muy interesante que nos vayas contando cómo madura y evoluciona este Pirata.
Gracias por compartir la idea!!
Hola Vanesa:
Empezando por el final, creemos que la idea del Pirata está bastante madura y estable, pues lleva con nosotros 1 año y medio y es un rol más en los equipos.
Respecto a que si lo ven como un apoyo, la respuesta es no. La persona que termina una historia debe hacerlo al 100%, nunca contar con la revisión del Pirata como una fase más. De hecho, dar trabajo al Pirata está mal visto. 🙂
Y si le da tiempo? Pues depende del sprint. Algunos tiene que empezar muy pronto y otros no hace falta. Pero en todo caso, está pendiente de las historias que van terminando para ir probándolas. Calculamos una dedicación del 20-30 % por sprint.
Saludos!
Antonio
[…] Otra forma de abordar la calidad y validación del producto, es designando a una persona en concreto, esto es lo que hace Kaleidos y su Pirata Roberts. […]
[…] más sobre el Pirata leyendo este post del kaleider Antonio de la […]
[…] Otra forma de abordar la calidad y validación del producto, es designando a una persona en concreto, esto es lo que hace Kaleidos y su Pirata Roberts. […]
[…] sobre el pirata Roberts en un interesante post de Antonio de la Torre hace ya bastantes […]