Estimaciones en desarrollo de software: un juego en el que todos perdemos

Estimaciones en desarrollo de
software
...Un juego en el que todos perdemos
Romén Rodríguez Gil
@romenrg - blog.romenrg.com

Sobre mi
Estimaciones en desarrollo de Software: un juego en el que todos perdemos. Romén Rodríguez Gil (@romenrg)

Sobre mis experiencias: startups, software, productos digitales...

Sobre mi mayor aprendizaje: Vocabulary Notebook

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

1. Las estimaciones en desarrollo fallan dramáticamente

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)
● 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
1.1 Estudios sobre desviaciones (en tiempo y costes) en software

1.1 Estudios sobre desviaciones (en tiempo y costes) en software
...Siguiendo con el Chaos Report 2015
¿Estamos mejorando?

● 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
1.2 Asumamos que nunca sabemos cuánto vamos a tardar desarrollando

● 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...

● 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 describiendo durante el desarrollo
■ Los equipos cambian, cada persona tiene habilidades y conocimientos diferentes,
avanza a ritmo diferente y trabaja en equipo de forma diferente

● 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)

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

¡#~@%#! ¡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...

… cuatro días más tarde ....

Jose, está todo
listo, ¿no?
Ehhh… bueno… sí… He estado
echando horas para poder tenerlo...
Sólo faltan algunas cosas
menores… Podemos subirlo así...

… un mes más tarde ....

¡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...

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...

¡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 10 000 €...

...todos perdemos….

2. ¿Por qué creemos necesitar las estimaciones de tiempo?

2. ¿Por qué “necesitamos” estimaciones de tiempo?
2.1 Percepciones de Managers / clientes vs desarrolladores
Yo creo que tardo un par de
semanas… Digamos un mes,
por si acaso....
Ok, 160 horas de desarrollo, al
precio de facturación de la empresa
de 30€ / hora… serían 4800 €…
Bueno, pongamos 5000 € por si
acaso… Bueno, con ese precio
podemos ganar unos 1000 €
(restando gastos…)
Para facturar al
cliente calcularemos
X horas por Y€ / hora
Jose, ¿cuánto tardarías en hacer X?

… un mes más tarde....

¡Cómo que no está
terminado! ¡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...

¡Tenías que haberlo
analizado antes de darme la
estimación! ¡Ahora vamos a
perder dinero!
… 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...

...todos perdemos….

- 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
2.2 El rol de los contratos tóxicos

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

● 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
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas

● Estimación indirecta
○ 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
3.1 Team velocity + Backlog para el cálculo empírico y dinámico de fechas

● 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...)
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)
3.2 Contratos no-tóxicos: agile contracts

● Enfoques ágiles mejoran la
satisfacción
○ Proyectos pequeños
■ Fracasos: -60%
○ Proyectos medianos
■ Éxitos: +400%
○ Proyectos grandes
■ Éxitos: +600%
3.3 Resultados y satisfacción de los clientes

Why Asking Developers for Time Estimates in Software Projects Is a
Terrible Idea and How to Bypass It With Scrum
Leer más:
http://blog.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/

...todos perdemos
Centrándonos en las estimaciones de tiempo en desarrollo de software...
Recuerda:

...todos podemos ganar
Con alternativas ágiles (empíricas y dinámicas)
Recuerda:

Estimaciones en desarrollo de software: un juego en el que todos perdemos

Estimaciones en desarrollo de software: un juego en el que todos perdemos

Recommended

More Related Content

Viewers also liked

Viewers also liked(20)

Similar to Estimaciones en desarrollo de software: un juego en el que todos perdemos

Similar to Estimaciones en desarrollo de software: un juego en el que todos perdemos(20)

More from Romén Rodríguez-Gil

More from Romén Rodríguez-Gil(20)

Recently uploaded

Recently uploaded(18)

Estimaciones en desarrollo de software: un juego en el que todos perdemos