Mejorando el flujo de trabajo a partir del burndown chart

Ayer completamos la tercera iteración del proyecto y la cosa empieza a fluir de lo lindo. Si bien veníamos cumpliendo con los compromisos asumidos el flujo de trabajo en las dos iteraciones anteriores había sido medio accidentado/abrupto como evidencia el burndown chart de la iteración 2.

Burndown chart iteración 2

En la retrospectiva de la iteración 2 tomamos conciencia de este flujo accidentado y decimos tomar medidas para mejorarlo. Principalmente intentamos tener ítems de backlog más pequeños, limitar el WIP y deployar de forma más frecuente. El resultado se puede apreciar en el siguiente gráfico.

Burndown chart iteración 3

 

A pesar de la mejora yo sigo teniendo un pequeña molestia pues no me gusta el cierre abrupto de la iteración. Este cierre es consecuencia de que terminamos a último momento el testing de la última porción de trabajo.

Ya que he compartido los gráficos quiero aprovechar también para compartir un breve análisis comparativo de los mismos:

  • Si bien ambas iteraciones tuvieron la misma duración calendario, la cantidad de días laborales en cada una, fue diferente (los días no laborales está representados por las franjas verticales de color gris más oscuro).
  • Debido al ítem anterior, el tamaño del compromiso asumido por el equipo también fue distinto: en la iteración 2 el compromiso fue de más de 50 puntos, mientras que en la iteración 3 fue de unos 40 puntos.

Preparing for IEEE Week Brazil

Preparing for IEEE Week Brazil

Next week I will be participating in the IEEE Week conference organised by the IEEE Students Chapter at University of Brasilia. In this context I will facilitate 2 activities.

On Monday 24 I will deliver a 4-hour workshop about «Modern Extreme Programming«.

On Tuesday 25 I will deliver the lecture: DevOps, myths and facts of a new paradigm.

Beyond these formal activities I expect to meet some local professors and practitioners to talk and share experiences about Software Engineering.

If you will be around and want to meet to share a talk (and a beer?) just contact me.

[OT] El día que metí un triple

Una vez más me tomo una licencia para salir de la temática usual de este blog para compartir un tema personal. Espero los habituales lectores sepan disculpar.

Por esas cosas que tiene la mente que uno no termina de entender, ayer espontáneamente recordé el primer triple que convertí en mi carrera de basquetbolista en un partido oficial. Como es un recuerdo muy grato para mi y no quisiera olvidarlo he decidido escribirlo.

Antes de ir al hecho concreto, comparto un poco de contexto. Comencé a practicar basquet cuando tenía unos 8 o 9 años pero no fue hasta los 12, cuando me sumé al CEF 31 de Marcos Paz, que comencé a competir regularmente. Si bien nunca fui alto, en aquella época era de los más altos de mi equipo. Ello sumado al hecho de que me daba mañana forcejeando cerca del aro  determinó que me tocara jugar de interno. Al mismo tiempo nunca fui un gran encestador, mi promedio de puntos por partido rondaba los 10 (aunque en una tarde muy poco usual fui el goleador de mi equipo con ¡34 puntos!).

Ahora si, el hecho en cuestión. Era el año 1996 y estábamos jugando en un triangular organizado en el club González Catán en el cual participábamos: los locales (González Catán), nosotros (CEF 31) y nuestro clásico rival: Central Norte de Laferrere. Estábamos jugando contra Central Norte, se aproximaba el final del primer tiempo e íbamos ganado. Nos tocaba atacar, quedaban unos pocos segundos en el reloj, un par de pases y la pelota llegó a mis manos cuando tan solo quedaban 2 segundos. Estaba en zona de triple y si bien la estadística no me acompañaba (nunca había metido un triple en un partido oficial) no había opción pues se acababa el tiempo, así que simplemente lancé.

La pelota entró junto con el sonido de la chicharra que anunciaba el fin del primer tiempo.

 

Ingeniería, el arte de hacer lo mejor posible con las restricciones existentes

Si no hubiera restricciones no sería ingeniería. De eso estoy seguro.

De lo que no estoy tan seguro es de que sea un arte. Tal vez sea una ciencia. No, ni lo uno ni lo otro. En fin, sea lo que sea, arte o ciencia ,o ambas, hay que hacer algo y hay que hacerlo atado a ciertas restricciones.

El siguiente punto es ¿hacer lo mejor posible? o ¿hacer lo mínimo posible? mmm, tal vez lo mínimo posible sea lo mejor posible. Creo que esto puede ser también polémico, pero al menos en la ingeniería de Software me parece bastante acertado.

Preparando Ingeniería de Software 2 @ FIUBA

Preparando Ingeniería de Software 2 @ FIUBA

Desde hace un tiempo estoy trabajando en preparar la materia Métodos y Modelos en la Ingeniería de Software 2 (95.21) perteneciente al nuevo plan de la Licenciatura en Análisis de Sistemas de la Facultad de Ingeniería de la UBA.

Formalmente el programa de la materia incluye una importante gama de temas que van desde procesos de adquisición hasta métodos de evaluación de arquitectura pasando por operaciones y sistemas de tiempo real.

La materia otorga 6 créditos y tiene una carga horaria de 6 horas semanales. Si bien aún no lo hemos hablamos explícitamente es muy posible que la materia se dicte en 2 clases semanales de 3 horas cada una.

Como primer paso tomamos el programa formal y lo desglosamos en capítulos/módulos que agrupan los principales temas.

En términos de enfoque pedagógico la idea es seguir con la misma estrategia que en la materia anterior (Métodos y Modelos en la Ingeniería de Software 1) el cual es muy similar al enfoque  que utilizo en UNTreF.

Continuará…