Estimaciones en desarrollo de software, versión 2017

Estimaciones en desarrollo de software...Un juego en el que todos perdemos

Romén Rodríguez Gil@romenrg - www.romenrg.com

2017

http://twitter.com/romenrg

http://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




2017



Contenido

1. Las estimaciones en desarrollo de software fallan dramáticamente1.1. Estudios sobre desviaciones (en tiempo y costes) en software1.2. Asumamos que nunca sabemos cuánto vamos a tardar desarrollando1.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 desarrolladores2.2. El rol de los contratos tóxicos2.3. La falacia de comparar proyectos

3. Alternativas con las que todos ganamos3.1. Team velocity + Backlog para el cálculo empírico y dinámico de fechas3.2. Contratos no-tóxicos: agile contracts3.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) - 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


1.1 Estudios sobre desviaciones (en tiempo y costes) en software

https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar

https://www.infoq.com/news/2011/10/risky-it-projects

https://www.infoq.com/articles/standish-chaos-2015



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

http://blog.hut8labs.com/coding-fast-and-slow.html


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




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



… unos días después de la subida ....





¡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 150 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, 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?




Oferta aceptada.

...Un mes más tarde...



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





…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!


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

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


Cambios de enfoque clave (importante)


● 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



5283

135282

Backlog de producto estimado en puntos de esfuerzo (1 bloque = 1 funcionalidad)

...

585

5232

3283

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


● Estimación indirecta



5283

13

282

Funcionalidad que queremos estimar (Fx)

...

528

313

28

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


● 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



● 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

http://blog.hut8labs.com/no-deadlines-for-you.html



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)

https://www.youtube.com/watch?v=oAyIJReSAJo&list=PLhE6PVDdZ3dLSS42FLcwYLcH3pldS71MT&index=1


● 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



2017




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/




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



2017



Estimaciones en desarrollo de software, versión 2017

Business

Transcript of Estimaciones en desarrollo de software, versión 2017