Con una entrada de trabajo tremenda los sprints semanales se han ido terminando sin consecución de las metas esperadas. Cada semana con un poco más de atasco y menos objetivos cumplidos. Uno de los factores principales es que los criterios de aceptación no estaban claros y ello provoca trabajo en vano. Por falta de análisis se toman decisiones equivocadas que tienen un alto coste y una estimación imposible (estimar sin saber con precisión lo que se necesita es “duro”). Se hace muy difícil calcular el valor que se aporta al negocio y la prioridad de la tarea. Se invierte un tiempo en planificación y retrospectiva del sprint para que no se termine la tarea.
Así que hemos pensado que hasta estabilizar la situación, dejamos los sprints semanales y hacemos un sprint por cada historia de usuario. Lo primero que se hará con la historia es sacar con la máxima precisión los criterios de aceptación. Escribiremos tests end-to-end al inicio de la historia (siempre que el codigo legado nos lo permita) que validarán su consecución. Así sabremos con exactitud lo que está terminado y sabremos que funciona. Además la figura del middle-man que traduce las charlas con el cliente en historias y criterios de aceptación se diluye un poco y todo el equipo se encarga de analizar y conseguir esos criterios: Más cohesión entre análisis-negocio y desarrollo.
El equipo de QA se convierte en un cuello de botella por deficiencia del proceso (o ausencia). Decidimos que los responsables de QA tendrán un pequeño meeting diario para ver cómo van las incidencias. Los jueves se hará especial esfuerzo en probar todo para confirmar que se puede desplegar en producción.
Además dedicaremos el último pomodoro del día a probar entre todos las tarjetas que están en estado “listo para UAT” para que lleguen más filtradas al equipo de QA.
Es prioritario reducir al mínimo la distancia entre el código que hay desplegado en producción y la rama principal del control de versiones. El ideal es poder desplegar en cualquier momento la rama principal, ya que usamos ramas para funcionalidades que están sin terminar. No obstante, a veces nos gustaria desplegar aunque haya funcionalidad a medias. Por eso vamos a intentar seguir puliendo la técnica de feature branches y además añadir en alguna ocasión feature toggles.
La información del kanban al final de la semana no va a parar a ningún documento histórico ni estadístico. Esto va a cambiar ya, para que tengamos el registro más fiable posible de costes en el corto, medio y largo plazo. Me encargo yo mismo. Esta información lógicamente no será pública 🙂
La mejora contínua sigue adelante y en estas semanas hemos avanzado con paso firme en lo siguiente:
- Hay menos interrupciones. Antes de interrumpirnos entre nosotros nos preguntamos por skype o email y al terminar el pomodoro hablamos entre nosotros.
- Estamos más concienciados con probar a mano las tarjetas antes de pasarlas al equipo de QA.
- Cada día nos preocupa más la deuda técnica y pensamos más antes de programar.
- Las reuniones diarias (daily meeting) van cada vez más fluidas, tardamos entre 10 y 15 minutos.
- Las reuniones de retrospectiva son más directas y nos dan más información.
- El número de tests automáticos sigue creciendo y su calidad también. Hemos alcanzado ya los 500 tests con javascript.
- Hemos hecho varias mejoras de arquitectura sin que el cambio sea muy costoso ni traumático.
- Hablamos más unos con otros y discutimos sobre código y arquitectura en el proyector antes de lanzarnos a programar lo primero que se nos ocurre.
El camino es largo, pero vamos mejorando hacia XP. Sólo hay que seguir vigilando para no retroceder y seguir practicando la honestidad, la valentía de hacer lo que es bueno para uno mismo (y eso será lo mejor para el equipo) y el sentido común. Ser consecuentes con lo que se hace y constantes con las prácticas.