Comparando el enfoque tradicional, con el ágil con estimaciones y con el #noEstimates

Quizá recuerdes que hace no mucho tiempo tratamos en un post el tema de no estimar a la hora de hacer software (el #noestimates), tema extensible a crear cualquier otro tipo de producto del conocimiento. Concretamente, aquel post era el de ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado.
Por la inquietud, curiosidad, miedos y movimiento que está tomando el tema (te recomiendo leer antes el post anterior), he estado haciendo en estos días una tabla que compara los que podríamos decir que son los tres enfoques actuales: tradicional, ágil con estimaciones y ágil sin estimaciones (o #noestimates)
He encontrado algunos documentos interesantes (como este) que intentan explicar las diferencias entre los tres enfoques. Pero al final ninguno me convencía del todo y he hecho yo una tabla.
 

TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #NOESTIMATES
Métricas típicas de seguimiento de proyecto Tiempo Real vs Tiempo Estimado.% de avance (ese típico del Gantt) Velocidad (trabajo completado por Sprint), Puntos Historia Valor entregado. Historias de Usuario completadas, Lead Time, Cycle Time (aquí puedes encontrar qué son el lead y el cycle) 
 Acuerdos“cliente” – “proveedor” La estimación inicial se convierte en un compromiso a largo plazo (meses, años), en tiempo, precio y alcance Compromisos por Sprint (semanas) Entrega continua. Flujo continuo de entrega de valor. Los acuerdos están en la ordenación por valor de aquello a realizar y en intentar reducir los tiempos de elaboración (el cycle time, desde que se empieza a trabajar en una tarea hasta que se termina) 
Modelo, framework, ciclo de vida de referencia Ciclo de vida en Cascada Ciclo de vida iterativo e incremental con iteraciones cortas. Framework tipo Scrum  Kanban (te dejo un post del tema)
 Modelo contractual Proyecto cerrado o llave en mano (que mal suena lo de llave en mano, parece que vas a comprar una casa)  Pago por Sprint o iteración. Pago por tiempo. Pago por historias de usuario completadas Pago por valor (historia de usuario) entregada
Flexibilidad al cambio Muy poca. Se cierran requisitos al principio, se estima, se cierra tiempo, alcance. Esto se pone en contrato y nadie quiere cambiar nada Salvo causa mayor, se intenta que no haya cambio de alcance dentro del Sprint (semanas) Se intenta sólo no cambiar una historia o tarea empezada, el resto se puede a cambiar en cualquier momento

 

1 comentario en “Comparando el enfoque tradicional, con el ágil con estimaciones y con el #noEstimates”

  1. Me gusta mucho el post. Además, nos hemos encontrado ahora con un proyecto que «pensamos» encaja con el modelo de #NOESTIMATES.
    Resulta que el cliente tiene claro a donde quiere llegar, pero por el camino ni ellos ( ni claramente nosotros ) saben qué se van a encontrar. Quieren construir, pero según como vaya siendo la construcción, le irán añadiendo trozos nuevos por aquí, trozos por alla ….
    Por tanto, el «tradicional» documento word con los requisitos del programa, hitos del proyecto, y las «perras» que cuesta esto, no nos sirve.
    De hecho empezamos a escribir el word, como buenos escritores que somos, pero es inútil, sólo sirve para dar una idea general al cliente de qué va a tener al final, pero no sabemos ni cuanto va a durar, ni por ende, cuanto va a costar.
    Después de leer el post, puedo entender el hecho de que se hagan entregas y se pague por ellas, pero no entendemos cómo podemos convencer al cliente de que «Oye, te vamos a entregar un trocito del proyecto, no es lo que tu quieres, para eso falta mucho, pero es lo único que te puedo dar, empieza a usarlo y ya hablamos. Además, pagame por esto que lleva trabajo».
    No se, si hay algo que se me ha escapado que nos puede ayudar, pero estoy en la oscuridad mas absoluta.

Deja un comentario

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

Share This
Ir arriba