La Definition of Ready: ventajas y peligros
Menos utilizada que la Definition of Done, la Definition of Ready es empleada por algunos equipos para determinar qué Product Backlog Items pueden incluirse en una iteración.
Puedes imaginar la Definition of Ready como un portero grande y fuerte que está frente a la puerta de la próxima iteración. Al igual que un portero que solo deja entrar a ciertas personas al club (los jóvenes, modernos y bien vestidos), la Definition of Ready solo deja entrar ciertas User Stories en la iteración.
Y al igual que un club puede decidir por sí mismo a quién dejan entrar los porteros y a quién no, cada equipo u organización puede decidir cuál es su Definition of Ready. No existe una Definition of Ready universalmente válida para todos los equipos.
Un modelo para la Definition of Ready
¿Qué tipo de Stories podría dejar entrar nuestro portero en la iteración? Por ejemplo, podría dejar entrar Stories que cumplan estos o similares criterios:
Las condiciones de satisfacción para la Story respectiva se han establecido completamente.
La Story ha sido estimada y tiene un tamaño máximo establecido. Si el equipo trabaja con Story Points, por ejemplo, los miembros del equipo establecen una cantidad determinada de Story Points y solo permiten que se incluyan en la iteración las Stories que correspondan a esa cantidad o sean menores. Frecuentemente este tamaño máximo es aproximadamente la mitad de la Velocity del equipo.
El diseñador de interfaz de usuario ya ha creado un mock-up o el diseño completo para las pantallas relacionadas con la Story.
Las dependencias externas han sido eliminadas, sin importar si se trata de dependencias internas o externas al equipo.
Una Definition of Ready define las precondiciones
Una Definition of Ready permite al equipo establecer criterios que deben cumplirse antes de que una Story pueda ser incluida en una iteración. El objetivo es prevenir problemas antes de que tengan la oportunidad de surgir.
Decir que solo se pueden incluir en una iteración Stories hasta un tamaño máximo determinado evita, por ejemplo, que se comience una Story demasiado grande para completarse en una sola iteración.
Igualmente, no permitir que entre en la iteración ninguna Story que tenga dependencias externas puede proteger contra que esas dependencias pongan en peligro la Story o toda la iteración si el otro equipo no logra cumplir su compromiso.
Imagina, por ejemplo, que tu equipo a veces depende de que otro equipo complete primero una parte del trabajo. Tus User Stories solo pueden completarse si el otro equipo ha terminado su trabajo, y además a tiempo para que tu equipo pueda integrar esas cosas.
Si ese equipo ya ha dejado tirado a tu equipo regularmente porque no terminaron algo a tiempo cuando lo habían prometido, sería lógico que tu equipo decidiera no incluir más en una iteración Stories con dependencias no resueltas con el otro equipo.
Una Definition of Ready que establezca que todas las dependencias externas deben estar resueltas antes de que una Story pueda incluirse en la iteración podría tener sentido para un equipo así.
Una Definition of Ready no siempre es una buena idea
Algunas reglas de nuestro portero son evidentemente una buena idea. Por ejemplo, no tengo problema si un equipo decide que no se pueden incluir en una iteración Stories por encima de un tamaño determinado.
Sin embargo, algunas reglas que veo frecuentemente en la Definition of Ready pueden causar problemas: problemas grandes. Déjame explicarlo.
La Definition of Ready es como la puerta de entrada a la iteración. Se establecen reglas y nuestro portero se encarga de que solo entren Stories que cumplan esas reglas.
Si entre esas reglas se incluye que algo debe estar completado al 100% antes de que una Story pueda entrar en la iteración, la Definition of Ready se convierte en un paso bastante grande hacia un enfoque secuencial de Stage-Gate. Esto impide que el equipo sea ágil.
Una Definition of Ready puede conducir a Stages y Gates
Permíteme explicar esto brevemente. Un enfoque Stage-Gate se caracteriza por una serie de etapas (stages) para el desarrollo. Además, en el enfoque Stage-Gate se definen puertas (gates) o checkpoints. Los trabajos solo pueden pasar de una etapa a la siguiente cuando atraviesan una puerta.
Cuando yo era pequeño, mi madre usaba un enfoque Stage-Gate para la cena. Solo recibía postre si había terminado de comer. No podía comer la cena y el postre al mismo tiempo.
Para expresarlo con un ejemplo del desarrollo de productos, imagina un proceso con etapas separadas de diseño y codificación. Para pasar de la etapa de diseño a la de codificación, los trabajos deben pasar por una puerta de revisión de diseño. La puerta debe asegurar la completitud y el rigor del trabajo en la etapa anterior.
Si ahora una Definition of Ready incluye una regla de que algo debe estar terminado antes de que otra cosa pueda comenzar, esto lleva al equipo peligrosamente cerca de un proceso Stage-Gate. Y eso afectará la capacidad del equipo para ser ágil. Un enfoque Stage-Gate es simplemente otra palabra para un proceso cascada.
Los equipos ágiles deben practicar el desarrollo simultáneo
En cuanto una cosa no puede comenzar hasta que otra esté terminada, el trabajo del equipo ya no puede realizarse de forma simultánea. La realización simultánea de trabajos es uno de los indicadores más evidentes de que un equipo es ágil. Un equipo ágil siempre debería realizar un poco de análisis, diseño, pruebas y codificación al mismo tiempo. Al incorporar puertas en el proceso de desarrollo, se impide exactamente eso.
Los equipos ágiles deberían practicar el desarrollo simultáneo, donde las diferentes actividades para entregar software funcional se solapan. Actividades como el análisis, el diseño, la escritura de código y las pruebas nunca ocurrirán completamente al mismo tiempo, y ese no es el objetivo. El objetivo es que estas actividades se solapen lo máximo posible.
Al requerir que ciertas actividades estén al 100% terminadas en un enfoque Stage-Gate, se impide que otras actividades puedan comenzar. Y una Definition of Ready puede llevar directamente a un enfoque Stage-Gate de este tipo si se incluyen tales reglas en la Definition of Ready.
Por esta razón, recomiendo a la mayoría de los equipos que no trabajen con una Definition of Ready. A menudo es un esfuerzo innecesario. Y lo que es aún peor, puede ser un gran y peligroso paso atrás hacia un proceso cascada.
En algunos casos, sin embargo, una Definition of Ready puede resolver problemas y, por tanto, valer la pena usarla.
Usar correctamente la Definition of Ready
Para usar con éxito la Definition of Ready, debes evitar reglas que establezcan que algo debe estar al 100% terminado antes de que una Story pueda entrar en la iteración, quizás con la excepción de dependencias de determinados equipos o proveedores. Además, deberías optar por directrices en lugar de reglas en tu Definition of Ready.
Aquí tienes un ejemplo de una regla que el equipo debería reformular: "Cada Story debe tener mock-ups detallados para todas las pantallas nuevas."
Una regla así representa una puerta. Impide que los trabajos se realicen de forma simultánea. Un equipo con esta regla no puede vivir el desarrollo simultáneo. Mientras no se haya elaborado un diseño detallado para cada Story, no hay trabajo al otro lado de la puerta.
La mejor variante sería: "Si una Story incluye pantallas nuevas importantes, se deben haber creado previamente mock-ups suficientes de las nuevas pantallas para que el equipo pueda resolver las preguntas y problemas restantes durante la iteración."
Pequeño cambio, gran efecto en la Definition of Ready:
1. La regla se convierte en una directriz.
2. Al decir que los mock-ups solo necesitan ser suficientes en lugar de estar terminados, permitimos trabajos simultáneos.
Estos dos cambios aportan algo más de subjetividad al uso de una Definition of Ready. Le seguimos diciendo al portero que queremos gente joven, moderna y bien vestida en nuestro club. Sin embargo, le damos más libertad para decidir por sí mismo qué significa realmente "bien vestido".
Este texto proviene del blog de Mike Cohn y fue traducido al español.
