Cómo mejoré mis estimaciones

Las estimaciones son un desafió cotidiano para muchos equipos de desarrollo de software pero curiosamente hay mucho material y de larga data sobre este tema. Sin embargo cada vez que me cruzo con equipos y personas que tienen dificultades para hacer estimaciones precisas, les pregunto si estudiaron el tema y la respuesta que suelo obtener es: no. Es como que mucha gente se resigna a que sus estimaciones sean muy imprecisas o esperan que mágicamente sus estimaciones mejoren.

Más allá del comportamiento de “la gente” hay que destacar un punto ¿que es lo que nos enseñan en la universidad sobre estimación? En mi caso tuve 1 clase sobre estimación y fue 100% teórica. Lo único que saqué de esa clases fue una lista de nombres de métodos de estimación, pero sin siquiera entender seriamente las diferencias entre ellos. Más aún, nunca en toda la carrera tuve un ejercicio específico de estimación.

Obviamente con esa formación escasa, yo también tuve dificultades con las estimaciones, pero en un momento decidí estudiar el tema seriamente y eso me ayudó mucho. Estudié diversos métodos de estimación y los puse en práctica. Conté puntos de función, utilicé software de estimación (como Construx Estimate), CoCoMo, Planning Pocker, Dephi (y sus variantes), estudié probabilidad, estadística y otras N yerbas relacionadas. Y hasta escribí un capítulo de un libro sobre estimaciones. Hoy en día estoy muy conforme con mis estimación ya que tengo un desvió menor al 10%.

Analicemos la cuestión un momento. El problema parece ser que uno estima que algo llevará tiempo TE y se pone a hacerlo y termina llevando TR, siendo TR >> TE. Ojo si fuera TR << TE, la estimación también sería “mala”. Lo que uno pretende es que TE ~ TR ¿hasta que punto es aceptable la diferencia entre TE y TR? Dependen del contexto y del objetivo de la estimación. Pero eso será tema de un futuro artículo, ahora voy a referirme a cuestiones más generales.

A mi parecer en la gran mayoría de los casos la situación es que el tiempo real es bastante mayor al tiempo inicialmente estimado (TR >> TE), pero en mucho casos el problema no está en la estimación sino en la ejecución. Muchas veces no nos dedicamos de lleno a la tarea sino que mientras hacemos la tarea seguimos viendo twitter, o contestando mail, o leyendo whatsapp. También es común que aparezca alguna otra tarea imprevista de mayor prioridad y entonces dejamos colgada la tarea X. Este “task switching” es extremadamente perjudicial y termina impactando en el tiempo real que nos lleva la tarea sobre todo si no llevamos un registro de las interrupciones.

Más allá de la precisión de la estimación, gran parte del problema radica en la ejecución.

¿Cómo podemos hacer entonces para mejorar la ejecución? Para mi aquí hay dos puntos claves:

  • Llevar registro de las tareas, los tiempos y las interrupciones para tener números concretos que nos muestren como es la realidad
  • Planificar el trabajo en pequeños incrementos, procurando que en principio ninguna tarea exceda un par de horas de trabajo.

Planificar el trabajo en pequeños incrementos ayuda a disminuir las interrupciones y mejorar la ejecución

Volviendo al tema concreto de la estimación, algo concreto que suelo hacer es combinar diversas técnicas de estimación, pero eso será parte de otro artículo.

Continuará…

Cierre de segundo cuatrimestre 2018 en UNTreF

Ayer cerramos el cuatrimestre de la materia Ingeniería de Software. Fue un cuatrimestre un poco atípico, pues a mediado de cuatrimestre no nos gustó como estaba fluyendo la materia y por ello hicimos un ajuste importante en la planificación. Creemos que con esto logramos corregir el rumbo y finalmente cerramos la materia satisfactoriamente. Comparto algunos números del cuatrimestre.

  • Inscriptos: 9
  • Aprobados: 9
  • Nota promedio de aprobación: 7,6
  • Evaluación general de la materia: 8.4
  • Trabajos/tareas individuales: 10
  • Trabajos grupales: 1 (6 iteraciones)
  • Dedicación semanal promedio extra-clase: 11 horas (desvío 5)
Foto de WaldoG en el after-class luego del cierre de la materia

Jornadas Universitarias de Sistemas de Información en Salud

La semana pasada estuve participando por primera vez de estas jornadas. organizadas por el Hospital Italiano de Buenos Aires.

Me tocó abrir el track de Ingeniería de Software con una chala que titulé “La última milla: del final de la iteración a la puesta en producción“.  La idea fue:

En la actualidad es común organizar el desarrollo de software siguiendo un enfoque ágil con iteraciones cortas. En línea con esto muchos equipos han decidido trabajar con Scrum como marco de referencia. Sin embargo, el tiempo transcurrido entre el fin del desarrollo de una funcionalidad y la puesta en producción de la misma sigue siendo un impedimento para la entrega continua de valor. En esta sesión repasamos algunos de los problemas típicos que enfrentan los equipos para recorrer esa “última milla” y veremos prácticas y herramientas utilizadas en la actualidad para allanar los impedimentos y optimizar el flujo de valor.

Más allá de mi charla, tuve la oportunidad de escuchar algunas otras exposiciones que me resultaron muy interesantes. Definitivamente voy a agregar este evento a mi calendario anual de conferencias.

Las diapositivas que utilicé en mi charla están disponibles aquí.

Repensando los trabajos prácticos

Si analizamos los trabajos prácticos que suelen hacerse en las carreras de informática como si fueran proyectos, veríamos que en general están planteados en términos de:

  • Alcance fijo: el docente define todo lo que hay que hacer y no negociable
  • Tiempo fijo: el docente indica la fecha de entrega, la cual generalmente tampoco es negociable
  • Esfuerzo variable: el docente no fija el esfuerzo que debe invertirse para completar el trabajo. Esto suena razonable, ya que habiendo fijado las otras dos variables es de esperar que esta sea ajustable.

Todos los trabajos prácticos que hice durante mi carrera de grado y postgrado fueron así y por lo que suelo hablar con mis alumnos, esto sigue siendo así. Duramente mucho años en las materias que estuve como docente también usábamos esta estrategia pero desde hace unos años hemos cambiado.

Actualmente en las dos materias de ingeniería de software que dicto utilizamos una estrategia distinta:

  • Esfuerzo fijo: les pedimos a los alumnos una dedicación semanal de 6 horas efectivas, extra clase por persona
  • Tiempo fijo: trabajamos durante 3 iteraciones, cada una de 1 semana de duración
  • Alcance variable: hay una lista de ítem/funcionalidades priorizadas y cada equipo estima y asume un compromiso en base a lo que consideran que podrán completar. Incluso si llegan a completar el compromiso, no tienen “penalización” de nota

Y particularmente en este cuatrimestre hicimos un primer trabajo práctico con las modalidad previamente descripta y tenemos un segundo trabajo práctico planteado de forma distinta:

  • Alcance fijo: está definido el conjunto de funcionalidades a completar
  • Tiempo variable: cada equipo decide cuando tiempo tomará para completar las funcionalidades. Trabajamos en iteraciones de duración fija, pero equipo decide la cantidad de iteraciones que utilizará. Idealmente creemos que el trabajo puede completarse 2 iteraciones, pero les damos a los alumnos la posibilidad de utilizar 4 o incluso 5 iteraciones
  • Esfuerzo variable: cada equipo elige cuanto esfuerzo pondrá en cada iteración. De esa forma en una iteración dada que coincida con fecha de examen de otra materia podrían poner poco esfuerzo y luego compensarlo en una iteración posterior.

Personalmente estoy muy convencido y contento con la estrategia TEfAv (tiempo y esfuerzo fijos, alcance variable). Y tengo mucha expectativa con este nuevo experimento de AFTEV (alcance fijo, tiempo y esfuerzo variable).

Primeras Jornadas de Ingeniería de Software del Uruguay (notas personales)

Los pasados martes y miércoles estuve participando de este evento. Tuve el honor de dar el keynote del martes. Hablé sobre un tema de moda que conozco con bastante profundidad: DevOps. Las diapositivas de mi exposición están disponibles aquí.

Entre las exposiciones que me resultaron más interesantes estuvieron:

  • La de Federico Toledo quien contó experiencias en pruebas de performance.
  • La de Guilherme Travassos, un reconocido académico brasilero, quien expuso sobre “Using validation sessions based on technology probe in software development to innovation
  • La de Jorge Corral que habló sobre la exportación de servicio de IT a USA
  • La de Nicolás Jodal,  quien habló sobre los desafíos de 30 años de evolución de Genexus (producto desarrollado por su empresa).

Más allá de las exposiciones hubo una mesa redonda de la que participaron varios referentes de la industria uruguaya del Software en la que se destacó la presencia de la Ministra de Industria Carolina Cosse.

Agradezco a Diego Valespir, Cecilia Apa y al resto del equipo organizador por la haberme invitado y los felicito por el gran evento realizado.

Primeras Jornadas de Ingeniería de Software del Uruguay

Los días 16 y 17 de Octubre se realizarán en Uruguay las Primeras Jornadas de Ingeniería de Software y tengo el honor de haber sido invitado como orador.

En ese contexto estaré hablando sobre unos de los temas “calientes” de la actualidad: DevOps. Concretamente el título de mi disertación será “DevOps, myths and facts of a new paradigm“. También estaré dando un taller enfocado en Test-Driven Development, Continuous Integration y Pair-Programming.

Las jornadas son de entrada libre y gratuita pero es necesario registrarse. Pueden encontrar más información en la página del evento y siguiendo la cuenta oficial de twitter.

¿Queres aprender sobre escalabilidad de Software?

La gente Auth0 ha comenzado una iniciativa que ha dado en llamar Engineering BootCamp de la cual estoy siendo parte. En términos concretos esta iniciativa consiste en una serie de entrenamientos de entre 20 y 30 horas con un enfoque “hands-on” (algo así como 20% de teoría y 80% de práctica).

El primer entrenamiento será sobre escalabilidad y se llevará a cabo a comienzos de Febrero en las oficinas de Auth0 en Buenos Aires. La participación es totalmente gratuita pero como los cupos son limitados, los interesados deben completar un formulario de postulación y a continuación resolver un pequeño ejercicio de programación. La idea es que este ejercicio nos ayude a asegurar cierto nivel mínimo de conocimiento en los participantes.

Los interesados pueden encontrar más información y completar su postulación aquí. No se dejen estar que la postulación termina hoy (viernes 12).