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

 

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

 

Las dos cuestiones más desafiantes del desarrollo de software

Desarrollamos software para aportar valor a un negocio/organización. En ese sentido el desarrollo de software tiene dos cuestiones centrales que son la fuente de sus mayores complejidades: determinar lo que hay que construir y manejar de forma eficiente las necesidades de cambio. Si bien yo he enumerado estos dos temas como cuestiones disjuntas la realidad es que tienen una íntima relación. Determinar lo que hay que construir debe gran parte de su complejidad al hecho de que una vez determinado lo que se debe construir, lo mismo suele cambiar. De todas todas vayamos por parte.

Determinar lo que hay que construir

Este es un tema que se ha tratado bastante, a punto tal que se ha generado un disciplina alrededor del tema: Ingeniería de requerimientos. Hoy por hoy, luego de haber leido, reflexionado y experimentado creo que el tema puede simplificarse a dos escenarios:

1) requerimientos conocidos y estables
2) requerimientos no-conocidos y/o no estables

Nunca en 15 años de trabajo en la industria me encontré con el caso (1), pero curiosamente creo que gran parte de la bibliografía, técnicas y conocimientos de la ingeniería de requerimientos está enfocada en este tipo de escenarios. Se me ocurre que en estos escenarios puede ameritarse hacer un trabajo intenso sobre los requerimientos antes de comenzar con el desarrollo (digo esto sin estar muy convencido).

Todos mis proyectos se enmarcan en escenarios del tipo (2), en algunos casos me ha tocado desarrollar software sin tener requerimientos conocidos, simplemente teniendo una visión y un objetivo de negocio y debiendo “experimentar sobre los requerimientos”. En la gran mayoría de los proyectos en los que he participado me he encontrado con un conjunto de requerimientos cambiantes a satisfacer y ha sido precisamente esa propiedad “cambiante” la fuente de las principales fricciones del proyecto.
Para estos escenarios del tipo 2, no considero que sea útil, ni conveniente realizar un trabajo intenso sobre los requerimientos antes de comenzar el desarrollo. Al contrario, creo que la cuestión pasa por “probar” de una forma sistemática siguiendo 4 premisas:

  • Trabajo iterativo
  • Involucramiento del usuario
  • Entrega frecuente
  • Feedback continuo

Manejar de forma eficiente las necesidades de cambio

A mi parecer este solo punto justifica la gran mayoría de las prácticas técnicas de la ingeniería de software (arquitectura, diseño OO, automatización, integración continua, etc). Si uno tuviera la certeza de poder escribir una pieza de código y nunca más modificarla podría no preocuparse por escribir código claro, mantenible y testeable. Curiosamente creo que en la formación académica se hace foco en la enseñanza de las prácticas técnicas pero sin hacer suficiente foco en el por qué de su importancia. Al construir software buscamos cumplir ciertas propiedades para facilitar la evolución/cambios que el software deberá soportar. El no cumplir con dichas propiedades suele generar diversos tipos de perjuicios para el negocio.

Obviamente más allá de estas dos cuestiones hay otras miles que también son relevantes (trabajo en equipo, planificación, etc), pero a mi parecer estas dos son las que están en los primeros puestos de complejidad.