Sin objetivos claros en el Sprint, ¿Que podemos proponer?
«Me preocupa y lo he manifestado en las Plannings y luego en las Dailys, que nuestros Sprints no tienen objetivos claros y definidos ya que afectan nuestras estimaciones y por ende, nuestro Testing» (comentario que me hizo un amigo tester que trabaja para una empresa del exterior hace muy poco tiempo mientras nos bebíamos unas cervezas en un bar muy conocido de la ciudad de Buenos Aires)
Después de despedirnos, me puse a reflexionar sobre el comentario que me hizo y que dió origen a este artículo en el que propongo primero algunos aspectos conceptuales/prácticos vinculados con el marco Scrum que todo tester debe conocer y saber practicar, para luego abordar aspectos netamente orientados a nuestra actividad de agile testing.
¿Cómo nos podemos dar cuenta que nuestro Sprint no tiene objetivos?
Las siguientes situaciones son algunas de las que se nos pueden presentar y que las debemos tomar como señales para levantar alertas tempranas:
- No tenemos una guía para tomar decisiones.
- Todos los sprints son los mismos.
- No sé hace foco en el valor.
- No hay concepto de equipo.
- No hay flexibilidad ni creatividad.
- Hay muy pocas razones para celebrar éxitos.
- Definimos y organizamos el backlog únicamente.
Ahora bien, ¿Cómo lograr definir los objetivos entre todos los miembros del Squad?
Preguntándonos
- ¿Qué quiere lograr el equipo?
- ¿Por qué el equipo está trabajando para completar el backlog del sprint?
- ¿Por qué las partes interesadas deben cuidar y apoyar al equipo?
Si bien el Backlog nos sirve como plan del Sprint, los objetivos que hayamos definido nos permiten guiar nuestras actividades durante el Sprint y adaptarse a cualquier reajuste que haya que hacer.
Primeras recomendaciones
📌 En relación con los Objetivos
Específicos.
Sujetos a un límite de tiempo.
👉 Definimos así nuestro propósito clave.
📌 En relación con el Backlog
Tareas específicas
Resultados
👉 Deberán estás descriptas
Por otra parte, tener definidos los objetivos nos ayudan a:
- Tener más claridad en las Dailys.
- Tener una referencia para evaluar el progreso.
- Facilitar la creación del roadmap del producto al PO.
- Guiar el Sprint Planning.
- Facilitar la toma de decisiones.
Otras preguntas que tal vez te puedas estar haciendo,
¿Cómo se pueden elaborar los objetivos?
Aplicando el método SMART, y teniendo presente que los mismos deben responder rápidamente la pregunta ¿Porqué?
¿Cómo gestionar el seguimiento de los objetivos?
Utilizando alguna aplicación Cloud, colaborativa, que se pueda integrar con las herramientas y/o plataformas más comunes que usemos, que permita evolucionar con nuestro negocio y proyectos, que sea sencilla y práctica de usar, que su curva de aprendizaje sea corta y si es arancelada, evalúa muy bien sus planes y licencias de uso que muchas veces ese tema suele frenar la decisión de implementar una herramienta.
Aquí otra mención en cuanto al concepto de implementar, ya que no es sólo la instalación de la herramienta y las consideraciones del caso, sino además gestionar quiénes la usarán, con que perfiles de usuario,cómo y dónde se almacenarán los artefactos que se vayan generando, que tipos de esquema de seguridad se aplicarán para el uso de los datos, entre otros.
¿Y respecto de nuestra participación como Testers en relación con la definición de los objetivos?
- Desde el punto de vista de agile tester, puede servir que tengamos presente todo lo que podemos aportar en un proyecto ágil, dependiendo claro está, de cuán maduros estemos:
- Somos capaces de generar espacios de comunicación y trabajo, integrándonos con desarrolladores y así creando equipos multifuncionales o squads ágiles.
- Testeamos (y no escribo probamos, ¿sabrás porqué no?) en todo momento, desde el minuto 0 (léase etapas tempranas) del proyecto, y efectuando de ser posible de acuerdo con nuestro nivel de conocimiento, pruebas unitarias.
- Proponemos y procuramos testear en paralelo al desarrollo de software, para lo cual deberemos planificarlo y comunicarlo en el squad.
- Damos apoyo al equipo de responsables de negocio, ya que conocemos el alcance y criterios de aceptación de las historias de usuario, las dependencias entre las mismas a través del correspondiente mapeo diseñado que nos permite conocer la trazabilidad, los fallos y defectos por historia de usuario y sus prioridades para el negocio, y la cobertura de testing alcanzada por historia de usuario y su impacto en el negocio.
- Podemos participar en cada una de las etapas y actividades de cualquier proyecto.
- Con el debido conocimiento técnico, podemos ocuparnos de conocer el funcionamiento interno del software que se esté desarrollando para aportar más valor desde el punto de vista del control de la calidad.
- En relación con el punto anterior, podemos ocuparnos no sólo de automatizar los casos de prueba candidatos, sino además automatizar partes de procesos, aplicando determinadas técnicas y herramientas para cada caso.
- Podemos combinar técnicas de estimación para mejorar el control de la calidad del producto de software a desarrollar.
