Los peligros de no estar hecho, o preparado para ello

Listo, Listo para Hecho, Hecho 

Quiero reiterar la importancia de estar listo y llegar a hacerlo. Cuando las historias son desarrolladas y preparadas necesitan estar listas para ser implementadas antes de que comience el Sprint. El Product Owner debe trabajar con el equipo antes de tiempo para asegurarse de que las historias están listas para ser implementadas por el equipo. Deben ser claras, concisas y, lo que es más importante, viables. Un buen Product Owner debería tener suficientes historias en ese estado para llenar los dos sprints siguientes. Tanto el equipo como el Product Owner deberían dedicar 5-10% de su tiempo a preparar historias para Sprints futuros. 

Esto es lo que ocurre si las historias no están listas. El equipo estima y prevé que puede terminar historias vagas e incompletas. Pierden tiempo y energía intentando obtener claridad del Product Owner sobre el significado exacto de la historia. La gente se frustra y se enfada y corre en círculos en lugar de ponerse a trabajar. O esa historia vaga se convierte en realidad en cinco historias reales una vez que se empieza a trabajar. O se trabaja en lo equivocado, o en lo correcto de forma equivocada, lo que obliga a rehacer el trabajo. Las historias en la parte superior del Product Backlog ordenado, las historias que el equipo sacará en el siguiente Sprint, tienen que estar listas. Algunas empresas exigen una lista de comprobación detallada para determinar si una historia está "lista", no sólo más o menos lista. El simple hecho de tener las historias listas tendrá un impacto inmediato y dramático en la productividad del equipo. Pero tenga en cuenta que, aunque el Product Owner es el responsable de incluir las características y las historias en el backlog, el equipo debe trabajar con él para ayudarle a dar forma a las historias. Porque sólo entonces el equipo será capaz de estimar la cantidad de trabajo que tomará cada historia, y cuántas historias se pueden tomar en un Sprint.Los peligros de no hacer nada

 

Y eso me lleva a lo que es "hecho". En el último capítulo hablé extensamente de la importancia de una definición de "hecho". Quiero volver a enfatizarlo aquí. Si algunas personas piensan que el trabajo está hecho al final del Sprint, pero en realidad no está hecho, la gente va a tener que volver atrás y rehacer ese trabajo. Sabemos que si hay que rehacer el trabajo, se tardará al menos el doble de tiempo en hacerlo, y hemos visto que se tarda hasta veinticuatro veces más. Este tipo de desperdicio se denomina deuda técnica en el negocio del software. Son las cosas que no están hechas y que hay que hacer antes de lanzar el producto. Si no se hace desde el principio, cuando se estaba trabajando en ello para empezar, se acumulará y acumulará, hasta que no haya forma de que el equipo pueda terminar esa cantidad de trabajo antes de la fecha de lanzamiento prevista. Los directivos obligan a la gente a hacer marchas de la muerte, la calidad del software decae, la gente enferma y se deprime por la presión, la fecha se retrasa, el producto que finalmente se lanza es malo y los clientes se enfadan. Todo ello lleva a la quiebra de la empresa, a la pérdida del empleo, al hambre de los hijos y a una espiral destructiva hacia las profundidades más oscuras de la condición humana. No lo hagas, haz las cosas.

Recuerda el último libro de Jeff, "El poder del Scrum". está disponible en tapa dura y en formato electrónico en Amazon.com.