Son las estimaciones tan malas?

Una de las charlas que mas me gusto del Bolivian Scrum Day 2013 es la de Thomas Wallet "No estimarás" - Mensaje fuerte, no? Y creo que esta bueno para mover el bote (como dicen en 10 Pines), pero, como siempre, tenemos que tomar el mensaje con cuidado y no echarle la culpa a la herramienta, como escuche alguna vez decir a Henrik Kniberg. Es estimar realmente malo? Existen muchas situaciones donde claramente no lo es. Si yo tengo que tomar un vuelo en Viru Viru y quiero saber cuando es que debería estar en el aeropuerto, realizo una estimación de cuanto voy a tardar y cuando tendría que levantarme. Hablando de software, muchas veces necesito o me es útil tener una 'estimación' del costo de una feature (para saber si me va a alcanzar la plata - poder planear -  o para saber si las voy a construir o voy a construir otra - poder priorizar -). Entonces cuando la estimación es mala o se convierte en un problema?

- Si lo voy a hacer si o si: tiene sentido estimar algo que si o si tengo que completar? Piensen en sus tareas personales? Se ponen a pensar cuanto van a tardar en hacer algo si lo tienen q hacer si o si? Perder tiempo en estimar en estos casos es realmente eso, perderlo.

- El otro gran problema con las estimaciones es cuando se toman como un contrato y no se tiene en cuenta que son estimaciones!! Y que es díficil estimar. Y que mientras menos se entienda el problema, peor se va a estimar!!

Entonces, yo que soy un poco más moderado propongo que entendamos porque estamos estimando y que tengamos en cuenta el retorno de inversión de esta estimación. Que quiero decir con esto? Si de esta estimación no depende absolutamente nada importante de la empresa, no perdamos mucho tiempo!! (y tampoco perdamos el tiempo haciendo tests). Si por el contrario, para la empresa es muy importante, entonces 'invirtamos' más tiempo en la estimación. Preocupemosnos un poco más!!

Otro de los puntos que me llamó la atención de la charla es que el modo talibán de dejar las estimaciones es básicamente intentar tener items de mas o menos el mismo tamaño y abandonar las iteraciones, midiendo el throughput y el ciclo... Esto también me hace ruido. Yo no creo que este cambio en el ciclo de vida del proceso este relacionado con las estimaciones y si con la no utilidad de las iteraciones. Este punto me va a ser mucho más díficil de fundamentar (será porq no lo tengo tan claro), pero voy a intentarlo. Tener items del mismo tamaño siempre es bueno, en Scrum, Kanban, XP o donde quieras. Permita calcular cualquier métrica mas facilmente, permite encajar los items dentro del sprint backlog, etc. Otro punto (no relacionado, pero bueh.. lo tiro!): Samuel Crescencio dijo que en su opinion, las retrospectivas son el componente mas importante de Scrum (quizás lo dijo para exagerar la importancia de las retrospectivas..). Bueno, pues para mi el componente más importante de Scrum son las iteraciones (timeboxedas). Por que? Porque las iteraciones son las q mantienen el foco, crean el pulso del proyecto, permiten calcular la velocidad y son el enabler de la inspeccion y adaptación. Adonde voy con todo eso? (ni yo se). A q si queres dejar de estimar usando Scrum podes hacerlo. Simplemente pone un numero (aleatorio) de ítems en una iteración y dps. ajustalo en las iteraciones subsiguientes (si tenes ítems del mismo tamaño, esto debería ser muy fácil). Pero debe haber otras razones mas importantes para eliminar la iteración (o para no hacer iteraciones o Scrum si nunca hiciste). Mucha variabilidad en la capacidad del equipo.. Un equipo de desarrollo que comparte responsabilidades de producción.. hasta podría enumerar una diferencia grande en el tamaño de los ítems (haciendo q algunos no entren en la iteración), pero partimos de la base q el tamaño de los ítems es similar..Entonces quizás es a mi q se me mezcló un poco la ultima opción o no se que, pero me cuesta ver la opción de ítems del mismo tamaño + Kanban como una opción para dejar de estimar. Para mi, dejar las iteraciones tiene que tener que ver con otra cosa.


En conclusión creo que las estimaciones sigue siendo buenas, cuando se las usan para lo que son y cuando existe confianza entre las gente que realiza las estimaciones y la gente que las va a usar. Desde que leí a Alistair Cockburn, siempre dije que creo q tenemos que ser críticos y entender el porque de cada uno de los componentes/tecnicas que usamos en nuestra metodología para tener la metodología más liviana que resuelva nuestros problemas (componentes que no aportan valor o son mal usados son desperdicio). Las estimaciones pueden ser un componente que agrega valor o no. Evaluemosló.

Daré una charla en el Scrum Bolivia Day 2013!!

Si, estoy muy contento porque a fin de mes tendré la oportunidad de asistir al Scrum Bolivia Day en Santa Cruz de la Sierra, un lugar que hacer mucho tiempo quería ir! Gracias Juan por la invitación y nos vemos pronto!!

Descripción

La revolución ágil introdujo grandes cambios en todas las áreas del desarrollo de software y el area de management no fue una excepcion. Pero cuales fueron estos cambios? Cuales son los desafíos del manager en la era ágil? En esta charla abordaremos estos tópicos con el objetivo de entender mejor las responsabilidades de un manager ágil y brindaremos herramientas que los ayudaran en sus desafíos diarios. Entre los puntos incluidos están: teoría de sistemas adaptativos complejos, como crear equipos motivados y como delegar responsabilidades.