Estimación de un prototipo
Cómo evaluar un prototipo: se trata de un producto diseñado para el aprendizaje, no para su uso. Cómo evitar que lo que se ha creado con fines de prueba acabe convirtiéndose en el código de producción que nadie había previsto.
La historia cuyo resultado es «ahora sabemos qué hay que construir», y no «ya lo hemos construido».
Un prototipo se diseña con el objetivo de aprender, no para su uso. La idea es responder a una pregunta —¿resulta adecuada esta interacción?, ¿es escalable este enfoque?, ¿resistirá esta API?— con la suficiente rapidez como para que pueda cambiar de rumbo antes de comprometerse con él. Los equipos que estiman los prototipos de la misma forma que estiman las funcionalidades obtienen una cifra que financia un tipo de trabajo inadecuado.
El otro modo de fracaso es justo lo contrario: diseñar un prototipo de dimensiones reducidas, lanzar algo que «simplemente funcione» lo suficiente y, a continuación, pasar ese mismo prototipo a producción porque el calendario se ha adelantado. El prototipo que acaba convirtiéndose en el producto es el código más costoso de toda la base de código, ya que nadie tuvo en cuenta las partes que faltan.
Lo que se dice en la sala
Ingeniero: «Puedo preparar algo en un par de días».
Introducción: «¿Cuál es la pregunta que estamos tratando de responder?»
PM: «¿Esto se va a mostrar a los clientes o es solo para uso interno?»
Titular: «Si la respuesta es sí, ¿lo desechamos y lo reconstruimos?»
Ingeniero: «Nunca lo tiramos».
Preguntas que conviene plantearse antes de votar
- ¿A qué pregunta responde el prototipo y cómo sabremos que tenemos una respuesta?
- ¿Solo para uso interno o ante los clientes?
- Se descarta por defecto — ¿y el equipo está comprometido con ello?
- ¿Cuál es el plazo establecido y qué ocurre al finalizarlo?
- Si funciona, ¿cuál es el proceso desde el prototipo hasta el código de producción?
La actitud del ingeniero de «nunca lo desechamos» es el verdadero riesgo: asigne un presupuesto al prototipo como parte de la solución y plantee la fase de producción como un proyecto independiente, de modo que la opción de desecharlo no se imponga por defecto.
Diseñe un prototipo que refleje la respuesta, no el producto final, y planifique la reconstrucción antes de que el calendario se lo imponga.
Al igual que la estimación de un pico de investigación, el resultado final es el conocimiento; trátelos de la misma manera. Consulte los errores habituales en el Planning Poker sobre cómo la investigación puede colarse en la historia, así como los demás ejemplos prácticos de estimación.