Excelente artículo de Johnny Ordoñez
De colección, super-recomendado
Lo copio para tener registro...
_____
La Definición de “Ready” es tan importante como la Definición de “Done”
Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie
Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.
Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.
Varios agilistas sugieren lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.
La Definición de “Ready” o DoR
Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.
¿Por qué es importante?
Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior, el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.
Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):
- Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
- Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
- Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
- De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
- Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
- Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
- Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
- Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.
Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):
- Sprint plannings más rápidos;
- Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente;
- Gestión colaborativa del backlog;
- Feedback temprano;
- Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
- Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
- Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
- Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.
Pensamientos finales
Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.
Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.
Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.
Gracias, y que la agilidad esté con Ustedes.
Johnny
No hay comentarios.:
Publicar un comentario