SCRUM Y XP DESDE LAS TRINCHERAS | 95
Durante las reuniones de planificación de Sprint establecemos el factor de dedicación suficientemente bajo como para tener en cuenta el tiempo que esperamos dedicar a encontrar y corregir errores del último Sprint. Con el tiempo, los equipos se han vuelto muy buenos estimando este tiempo. La métrica de velocidad ayuda mucho (ver “Cómo decide el equipo qué historias incluir en el Sprint”).
Mal enfoque – “centraos en producir cosas nuevas” Esto, a todos los efectos, significa “centraos en producir cosas nuevas en lugar de conseguir poner producción las cosas antiguas”. ¿Quién querría hacer eso? Y aun así cometimos ese error muy a menudo al principio, y estoy seguro de que muchas otras compañías lo hacen también. Es una enfermedad relacionada con el estrés. Muchos gerentes realmente no lo entienden, y cuando toda la programación termina aun se encuentran muy lejos de poner algo en producción. Al menos para sistemas complejos. Así que el gerente (o el Dueño de Producto) pide al equipo que siga incluyendo nuevas funcionalidades mientras la bolsa de código-casi-listo-para-producción va volviéndose más y más pesada, ralentizándolo todo.
No sobrecargues el eslabón más débil de tu cadena Digamos que las pruebas de aceptación son tu eslabón más lento. Tienes muy pocos encargados de pruebas, o las pruebas de aceptación tardan demasiado por la baja calidad del código. Digamos que tu equipo de pruebas puede probar como mucho 3 funcionalidades a la semana (no, no usamos “funcionalidades a la semana” como métrica; lo estoy usando únicamente como ejemplo). Y digamos que tus desarrolladores pueden desarrollar 6 nuevas funcionalidades por semana. Sería tentador para los gerentes o Dueños de Producto (o quizás incluso para el equipo) planificar el desarrollo de 6 nuevas funcionalidades a la semana. ¡No lo hagáis! La realidad os alcanzará de una u otra manera, y será doloroso. En lugar de eso, planificad 3 nuevas funcionalidades a la semana y pasad el resto del tiempo aligerando el cuello de botella de las pruebas. Por ejemplo: