Este documento discute las fallas comunes en las estimaciones de tiempo para el desarrollo de software. Señala que los estudios muestran que las estimaciones suelen estar muy por debajo del tiempo real que toma completar un proyecto de software. También explora por qué se sienten necesarias las estimaciones a pesar de sus fallas recurrentes y propone alternativas como el uso de la velocidad del equipo y los ciclos iterativos para lograr una estimación más realista y dinámica.
1. Estimaciones en desarrollo de
software
...Un juego en el que todos perdemos
Romén Rodríguez Gil
@romenrg - www.romenrg.com
2017
2. Sobre mi
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3. Sobre mis experiencias: startups, software, productos digitales...
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
4. Sobre mi mayor aprendizaje: Vocabulary Notebook
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
5. Estimaciones en desarrollo de
software
...Un juego en el que todos perdemos
Romén Rodríguez Gil
@romenrg - www.romenrg.com
2017
6. Contenido
1. Las estimaciones en desarrollo de software fallan dramáticamente
1.1. Estudios sobre desviaciones (en tiempo y costes) en software
1.2. Asumamos que nunca sabemos cuánto vamos a tardar desarrollando
1.3. Las graves consecuencias de las estimaciones de tiempo
2. ¿Por qué creemos necesitar las estimaciones de tiempo?
2.1. La percepción de los managers / clientes frente a la de los desarrolladores
2.2. El rol de los contratos tóxicos
2.3. La falacia de comparar proyectos
3. Alternativas con las que todos ganamos
3.1. Team velocity + Backlog para el cálculo empírico y dinámico de fechas
3.2. Contratos no-tóxicos: agile contracts
3.3. Resultados y satisfacción de los clientes
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
7. 1. Las estimaciones en desarrollo fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
8. 1. Las estimaciones fallan dramáticamente
● Desde los años 90 muchos plasman una desagradable realidad
○ Harvard Business Review:
■ Why Your IT Project May Be Riskier Than You Think (resumen InfoQ) - 2011
● Proyectos IT: sobrecoste de 400% y obtener sólo 25% de beneficios
esperados
○ Chaos Reports (Standish Group)
■ Informe de 2015 (resumen InfoQ)
● > 10 000 proyectos analizados
● El 71% de los proyectos software son definidos como fracasos
○ Tiempos, costes y resultados no son los esperados
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.1 Estudios sobre desviaciones (en tiempo y costes) en software
9. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.1 Estudios sobre desviaciones (en tiempo y costes) en software
...Siguiendo con el Chaos Report 2015
¿Estamos mejorando?
10. 1. Las estimaciones fallan dramáticamente
● Coding, Fast and Slow: Developers and the Psychology of Overconfidence
○ Primera experiencia de Dan Milstein
■ [...] The account manager explained, in rough form, what the client was looking for, we
talked it out, and I said, “That should be about 3 weeks of work.”
“Sounds good,” he said. And so I got to coding.
How long do you imagine this project took? Four weeks? Maybe five?
Um, actually: three months. [...]
○ Tras años intentando no volver a estar tan equivocado, Dan llega a la conclusión de que
siempre está tan equivocado… y se da cuenta de que, por lo general, todos lo estamos
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.2 Asumamos que nunca sabemos cuánto vamos a tardar desarrollando
11. 1. Las estimaciones fallan dramáticamente
● Crear software es complejo, abstracto y cambiante
○ Escribir software requiere entender algo a un nivel tan preciso que nos permita decir a un
ordenador cómo hacerlo.
■ Ese detalle no lo tenemos al hacer una análisis inicial, ni de lejos.
■ Para analizar con ese nivel de detalle tan preciso
● acabaríamos desarrollando gran parte del software para “analizarlo”
● sería tremendamente costoso e inflexible
● y desde luego no tendría la utilidad que se pretende de “análisis” ni “estimación”
● llegado a este punto sería más lógico desarrollar el software directamente...
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.2 Asumamos que nunca sabemos cuánto vamos a tardar desarrollando
12. 1. Las estimaciones fallan dramáticamente
● Crear software es complejo, abstracto y cambiante
○ Cuando analizamos requerimientos por primera vez
■ Siempre hay partes que no comprendemos del todo
■ Hay partes que el propio cliente no comprende del todo
■ No podemos conocer las tecnologías al 100%
■ Cada problema requiere tecnologías, librerías o desarrollos propios diferentes
● Y esto lo vamos descubriendo durante el desarrollo
■ Los equipos cambian, cada persona tiene habilidades y conocimientos diferentes,
avanza a ritmo diferente y trabaja en equipo de forma diferente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.2 Asumamos que nunca sabemos cuánto vamos a tardar desarrollando
13. 1. Las estimaciones fallan dramáticamente
● Lo más grave: desarrolladores que se creen sus estimaciones
○ Cualquier desarrollador que haya trabajado al menos unos meses, ha vivido el caos de las
estimaciones. Sin embargo, la mayoría siguen creyéndose capaces de estimar y buenos
estimadores
○ ¿Por qué se siguen creyendo los desarrolladores sus estimaciones?
■ Al terminar no cuantifican el tiempo real que les ha costado
■ No comparan el tiempo real con el “estimado” inicialmente
■ Trabajan en varias cosas a la vez, con lo que se desconoce la dedicación a cada una
■ Si es evidente la desviación se echan balones fuera (problemas externos, etc…)
■ Se quieren cumplir los deseos de managers / clientes
■ Se cede a la presión de grupo por parecer rápido (o no parecer lento)
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.2 Asumamos que nunca sabemos cuánto vamos a tardar desarrollando
14. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Jose, me dijiste que
tendríamos lista la nueva
versión en un mes… Quedan
4 días, ¿ya estará casi, no?
Ehhh… bueno…
espero poder tenerlo,
como sea...
1.3 Las graves consecuencias de las estimaciones de tiempo
15. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
¡#~@%#! ¡Que no llego! Nada, dejo de hacer
tests, yo creo que lo que queda es fácil… Sólo
falla en casos raros… lo subo así mismo y si
hace falta ya lo corregiré… Esto es complejo
de entender… pero bueno, los diagramas ya
los haré en otro momento… Uhm, ¿qué
nombre le poco a esta variable? Bah, “var
pepe” está bien, no perdamos tiempo...
1.3 Las graves consecuencias de las estimaciones de tiempo
16. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
… cuatro días más tarde ....
1.3 Las graves consecuencias de las estimaciones de tiempo
1. Las estimaciones fallan dramáticamente
17. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Jose, está todo
listo, ¿no?
Ehhh… bueno… sí… He estado
echando horas para poder tenerlo...
Sólo faltan algunas cosas
menores… Podemos subirlo así...
1.3 Las graves consecuencias de las estimaciones de tiempo
18. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
… unos días después de
la subida ....
1.3 Las graves consecuencias de las estimaciones de tiempo
1. Las estimaciones fallan dramáticamente
19. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
¡Jose! ¡¿Pero qué demonios
has hecho?! Hay usuarios
que no pueden acceder y
otros a los que se les han
corrompido sus datos...
Ehhh… bueno… había
algunos casos raros…
Pero ya es mala suerte...
...Enseguida lo arreglo...
1.3 Las graves consecuencias de las estimaciones de tiempo
20. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.3 Las graves consecuencias de las estimaciones de tiempo
Pufff… ¡Este código no lo entiendo ni yo
mismo!… A saber en qué casos falla esto… No
hay ningún test…
¿Qué demonios era la variable “pepe”?
¿Cómo era el flujo de ejecución de este código?
Ojalá tuviera algún diagrama o descripción...
21. 1. Las estimaciones fallan dramáticamente
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
1.3 Las graves consecuencias de las estimaciones de tiempo
¡A ver qué le digo a los clientes!... ¡Este tío
es un inútil! Si me hubiera dicho que que era
un plazo imposible hubiéramos esperado,
pero con esta cagada ya hemos perdido
más de 3 000 usuarios, lo que tiene un
impacto económico mayor de 150 000 €...
22. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
...todos perdemos….
1.3 Las graves consecuencias de las estimaciones de tiempo
1. Las estimaciones fallan dramáticamente
23. 2. ¿Por qué creemos necesitar las estimaciones de tiempo?
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
24. 2. ¿Por qué “necesitamos” estimaciones de tiempo?
2.1 Percepciones de Managers / clientes vs desarrolladores
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Yo creo que tardo un par de
semanas… Digamos un mes,
por si acaso....
Ok, son 160h de desarrollo, a los
35 €/h que facturamos serían 5600
€… Pongamos 6000 €. Con este
proyecto podríamos tener unos
1500 € de beneficio para la
empresa. ¡Presentaré la oferta!
Para facturar al
cliente calcularemos
X horas por Y€ / hora
Jose, ¿cuánto tardarías en hacer X?
25. 2.1 Percepciones de Managers / clientes vs desarrolladores
2. ¿Por qué “necesitamos” estimaciones de tiempo?
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Oferta aceptada.
...Un mes más tarde...
26. 2. ¿Por qué “necesitamos” estimaciones de tiempo?
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
¡Cómo que no está
terminado aún! ¡Dijiste que
estaría para final de mes!
Se ha complicado... Estuve varios días con
un bug inesperado de una librería, varios
días más analizando una API externa que
no estaba documentada como debería... Y
además hemos tenido problemas con
dependencias transitivas… Necesito al
menos dos o tres semanas más...
2.1 Percepciones de Managers / clientes vs desarrolladores
27. 2.1 Percepciones de Managers / clientes vs desarrolladores
2. ¿Por qué “necesitamos” estimaciones de tiempo?
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
…Pero es que hasta que no me he puesto
a desarrollar no han ido surgiendo los
problemas… Son demasiadas variables
a tener en cuenta como para preverlas...
¡Tenías que haberlo
analizado antes de darme la
estimación! ¡Ahora no solo se
esfuma nuestro margen, sino
que vamos a perder dinero!
28. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
...todos perdemos….
2.1 Percepciones de Managers / clientes vs desarrolladores
2. ¿Por qué “necesitamos” estimaciones de tiempo?
29. 2. ¿Por qué “necesitamos” estimaciones de tiempo?
- Pretenden fijarlo todo
- Precio
- Tiempo
- Alcance
- Pero no sabemos qué va a ocurrir
- Hay mucha incertidumbre
- Cosas que no comprendemos
- Cosas que el cliente aún desconoce
- Complicaciones imprevistas
- Tecnologías variables y desconocidas
- Equipo variable y no “copiable
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
2.2 El rol de los contratos tóxicos
30. 2. ¿Por qué “necesitamos” estimaciones de tiempo?
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Agente, ¿cuánto tiempo tardarán en
encontrar al ladrón? Si al último lo
cogieron en 2 días, para este deberían
bastarles 36 horas, que ya tienen
experiencia...
Edison, eso que dice de crear algo
que nos ilumine por la noche sin
fuego ¿cuánto tardará en inventarlo?
Tampoco debe ser tan complicado
partiendo de una vela...
Doctor, ¿cuánto queda para
recuperarme de la fractura de peroné?
Para el esguince de tobillo fue sólo
una semana y con la fractura llevo ya
1 mes… ¡Su productividad ha bajado!
2.3 La falacia de comparar proyectos: no hay dos casos iguales
31. 3. Alternativas con las que todos ganamos
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
32. 3. Alternativas con las que todos ganamos
● Productos, no proyectos
○ Es un error ver “proyectos” software como algo con un inicio y un fin cerrados
○ Casi todo software que desarrollamos se convierte en un producto con un largo ciclo de vida
■ Sus funcionalidades evolucionan
■ Los sistemas con los que interactúa cambian
■ Se detectan errores
■ Queremos adaptarlo a nuevas tecnologías o realidades
● Confianza y colaboración
● Ciclos cortos, iterativos e incrementales
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Cambios de enfoque clave (importante)
33. 3. Alternativas con las que todos ganamos
● Estimación indirecta
○ Team Velocity en puntos de esfuerzo
■ Práctica introducida por XP (eXtreme Programming)
■ Funcionalidades descritas como Historias de Usuario, estimadas en Puntos de Esfuerzo
■ La clave: desacoplar “tamaño”/“peso” de una funcionalidad del tiempo de desarrollo
● El margen de error es más natural, no hablamos de tiempo sino tamaño relativo
○ Product Backlog
■ Práctica introducida por Scrum
■ Tenemos una lista priorizada de las funcionalidades (historias de usuario) a desarrollar
○ Sprint
■ Periodo de desarrollo de X funcionalidades
■ Usualmente 15 días o 1 mes
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas
34. 3. Alternativas con las que todos ganamos
● Estimación indirecta
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas
5
2
8
3
13
5
2
8
2
Backlog de producto estimado en
puntos de esfuerzo (1 bloque = 1 funcionalidad)
...
5
8
5
5
2
3
2
3
2
8
3
3
Sprint N-3: 18
Sprint N-2: 15
Sprint N-1: 16
Empíricamente
vemos que el
equipo tiene una
velocity de 16
puntos de esfuerzo
por sprint (media
del histórico)
Como cada sprint
son 15 días,
podemos hacer
estimaciones
inversas con el
backlog
35. 3. Alternativas con las que todos ganamos
● Estimación indirecta
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas
5
2
8
3
13
2
8
2
Funcionalidad que queremos
estimar (Fx)
...
5
2
8
3
13
2
8
Sprint N+1: 15
Sprint N+2: 16
Sprint N+3
Basados en la
velocity del equipo
(16 puntos / sprint),
existen elementos
previos en el backlog
para 2 sprints
completos antes de
abordar el elemento
elegido (Fx).
Probablemente Fx
estará desarrollado
en 3 sprints. Es decir
45 días (15 días /
sprint x 3 sprints)
5
5
36. 3. Alternativas con las que todos ganamos
● Estimación indirecta (resumen)
○ Inicialmente estimamos todo el Backlog en Puntos de Esfuerzo
■ Tomando como referencia las Historias de Usuario más pequeñas o mayores
■ Mantenemos estas estimaciones consistentes
○ Sprints
■ Al planificar un sprint
● El equipo añade el número de Historias que cree ser capaz de terminar
■ Al finalizar un sprint
● Veremos cuántos puntos de esfuerzo hemos podido realizar
● En los primeros es normal que varíen los puntos de esfuerzo que realizamos
● Tras varios sprints convergerá en una cifra similar cada sprint: Team Velocity
○ Conocienciendo nuestra Team Velocity, el total de puntos de nuestro backlog y la
duración de cada sprint, podremos estimar la fecha de lanzamiento
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas
37. ● No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies
○ Conclusión del artículo de Dan Milstein
■ Tras aprender que no es posible estimar en software
■ Lo importante es ayudar al cliente
● Aprender qué quiere realmente
● Ayudarle a recabar datos sobre el mercado
● Ayudarle a recabar datos sobre la efectividad de las funcionalidades
● Desarrollar funcionalidades pequeñas
○ Priorizadas por el valor que aportan al negocio
○ Al final Dan está hablando de enfoques ágiles
■ Ir a la raíz del problema, aprender constantemente, desarrollo iterativo-incremental,
facturar por dedicación (2 semanas de dedicación a X...)
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3. Alternativas con las que todos ganamos
3.2 Contratos no-tóxicos: agile contracts
38. 3. Alternativas con las que todos ganamos
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
3.2 Contratos no-tóxicos: agile contracts
● ¿Existen contratos / enfoques alternativos? “Agile contracts”
○ “Esconder Agile”
■ Emplear métodos ágiles internamente y prever desviaciones dinámicamente
○ No cure, no pay
■ Sólo se cobra si se soluciona el problema
● Riesgo del proveedor para asumir inversión y controlar alcance
○ Time & Materials
■ Ej: Se cobra por hora trabajada + “suplidos”
○ Rolling contracts
■ Precio fijado por sprint
■ Producto iterativo-incremental como resultado de cada sprint
■ Renovación automática tras cada sprint
■ Money for nothing, change for free (variación propuesta por Jeff Sutherland)
39. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
● Enfoques ágiles mejoran la
satisfacción
○ Proyectos pequeños
■ Fracasos: -60%
○ Proyectos medianos
■ Éxitos: +400%
○ Proyectos grandes
■ Éxitos: +600%
3. Alternativas con las que todos ganamos
3.3 Resultados y satisfacción de los clientes
40. Estimaciones en desarrollo de
software
...Un juego en el que todos perdemos
Romén Rodríguez Gil
@romenrg - www.romenrg.com
2017
41. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
Why Asking Developers for Time Estimates in Software Projects Is a
Terrible Idea and How to Bypass It With Scrum
Leer más:
http://www.romenrg.com/blog/2015/09/28/why-asking-developers-for-time-estimates
-in-software-projects-is-a-terrible-idea-and-how-to-bypass-it-with-scrum/
42. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
...todos perdemos
Centrándonos en las estimaciones de tiempo en desarrollo de software...
Recuerda:
43. Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)
...todos podemos ganar
Con alternativas ágiles (empíricas y dinámicas)
Recuerda:
44. Estimaciones en desarrollo de
software
...Un juego en el que todos perdemos
Romén Rodríguez Gil
@romenrg - www.romenrg.com
2017