Un proyecto ágil se guía por valor no por estimación (más sobre #noEstimates)

Value is, simply, “what you want.”

Ron Jeffries, The Nature of Software Development

La estimación, y lo que deriva de ella (o lo que lleva a ella, como es el encajar proyectos en tiempos y recursos económicos), es, será y ha sido, un tema que en el mundo del software levanta muchas pasiones. Si eres de los antiguos de lugar, recordarás que este es de los temas que solemos tratar por aquí y que, históricamente, es de lo que más problemas ha traído en proyectos, siendo principal causa de fracaso, como hablamos en ¿Cuáles son los errores que más se repiten en un proyecto software? (2013).
En un proceso ágil, ya no sé si me atrevo a decir en un “proyecto” ágil, ya que la palabra “proyecto” (fecha de arranque – fecha final, con entrega final acordada o esperada) empieza a carecer de sentido en agilidad, no se elimina el “acto” de estimar, cambia, eso sí, no sólo en la manera (respecto a las estimaciones clásicas), sino que también en importancia, dejando de ser el factor principal de importancia a la hora de guiar todo, dejando paso al concepto de valor.

Valor… ¿qué valor?

El valor, que no es lo mismo que velocidad, es, curiosa y sorprendentemente, uno de los elementos más importantes a la hora de guiar un proceso ágil, uno de los menos comprendidos, de los menos tomados en cuenta, de los menos explicados y, sin embargo, es más que de vital importancia en este contexto.
El valor, sin tener una definición exacta, es, como decía Ron Jeffries, en The Nature of Software Development, “lo que tu quieres”, más concretamente, lo que esperan los usuarios potenciales del producto que estás creando. Y, como no eres adivino, puedes fallar calculando qué tiene más valor, e incluso el usuario potencial puede no tenerlo claro antes de empezar… se chequea periódicamente con el usuario, haciéndole ver entregas parciales, prototipos operativos. Con ello, el valor de algo puede cambiar.
El valor es la dirección estrategia del producto, información sobre lo que preferirían los usuarios, nos ayuda a crear prototipos y mostrarlos a usuarios potenciales.

Valor frente a estimación

Como bien decía Ron Jeffries, un proceso ágil se basa en hacer las cosas de mayor valor primero y las de menor valor luego o nunca, entregando valor pronto.
La estimación clásica, la gestión clásica, se ha basado en disponer de todos los requisitos, estimarlos y, en ocasiones, que no siempre, empezar a implementar los por prioridad (que pudiera semejarse al valor), para terminar todo en un plazo determinado y hacer una gran entrega final.
Pero recuerda, una cosa es tener un montón de requisitos, priorizarlos por valor (u otros conceptos) e ir haciéndolos y otra, mucho más ágil, es tener un conjunto de requisitos priorizarlos por valor e ir haciendo prototipos y entregas parciales, entregando prototipos que implementen sólo los ítems de mayor valor, para posteriormente volver a valorar los siguientes ítems (requisitos normalmente) a implementar.
Reduce el alcance a solo los elementos de mayor valor, hazlos, solo esos, entrégalos y chequea un nuevo alcance con los usuarios potenciales. Verás que el resultado final de esta manera de trabajar va a diferir mucho de la manera clásica, muy probablemente no acabarás implementando lo mismo, con mucha seguridad implementaras cosas que aportan valor.
Si te interesa todo esto te recomiendo complementar lo hablado con los siguientes post o, si lo prefieres, puedes venirte el 22 de octubre a las jornadas Peopleware – Agile Managemet, donde tendré el suerte de dar una ponencia sobre el tema.
¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado
Mis diapositivas sobre #NoEstimates o sobre que la estimación no sea la pieza central de un proyecto
¿Necesitamos estimaciones de proyectos software… o presupuestos?

1 comentario en “Un proyecto ágil se guía por valor no por estimación (más sobre #noEstimates)”

  1. Hola,
    Hablando de dar valor, también se puede pensar en el valor que proporciona a la compañía disponer de estimaciones, saber el tiempo que se invierte y estimar cuánto se tardaría en realizar el incremento del producto siguiente (sprint en Scrum).
    No es un tema trivial y depende siempre del contexto en el que se esté, aún así yo suelo hacer una analogía con la importancia y los beneficios que aportan el gateo (Estimar) previo a caminar (No Estimar). (http://davidfergon.github.io/2015-06-16-de-la-nada-al-todo-continuo-de-scrum-a-kanban-y-noestimates.html)
    Saludos,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba