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.

Reflexiones sobre la Enseñanza de la Ingeniería de software

En mi actividad profesional cotidiana me desempeño como ingeniero de software ocupando distintos roles y realizando distintas tareas dependiendo de las particularidades del proyecto de turno. Por ello cuando en 2011 tomé a mi cargo la materia Elementos de Ingeniería de Software en la Universidad Nacional de Quilmes busqué una dinámica de dictado de la materia que efectivamente pudiera preparar a los alumnos para desempeñarse profesionalmente en esta disciplina.

Personalmente considero que la ingeniería de software es una actividad naturalmente industrial, y en este sentido me parece fundamental que su enseñanza tenga un enfoque práctico puesto que la ingeniería de software teórica resulta insuficiente para el ejercicio profesional de la disciplina.

Curiosamente mi formación  en Fiuba no tuvo este enfoque. Como alumno tuve un conjunto de materias de índole más bien teórica y  tiempo después otras materias de tipo taller donde se suponía ponía en práctica la teoría aprendida tiempo atrás. Esto me parece perjudicial para el alumno, pues a la hora de estudiar la teoría, la misma se aprende “en el aire” sin ponerla en práctica. Luego, tiempo más tarde se cursa un taller, pero al llegar al taller uno ya se olvidó de la teoría “supuestamente aprendida”. Exactamente esto me pasó con el tema de estimación: en una materia me enseñaron los diversos métodos de estimación pero nunca me pidieron estimar, simplemente me pidieron describirlos en un examen escrito. Tiempo después cuando cursé el taller y tuve que estimar, tuve que volver a estudiar los métodos y fue ahí, a la hora de aplicarlos, que me surgieron mil dudas. Algo similar me ocurrió con las cuestiones de testing y calidad.

Otra curiosidad de mi carrera (y que también se repite en otras casas de estudio) es que cursé en primera instancia una materia de análisis y luego una de diseño, como si fueran dos actividades disjuntas (un punto sin duda debatible). Hasta ese momento carecía de una visión general del proceso de desarrollo de software, cosa que aprendí tiempo más tarde en la materia de gestión. Creo que resulta muy dificil (y poco conveniente) enseñar técnicas de análisis y diseño sin contar con el marco general de un proceso de desarrollo. En este sentido me parece interesante el enfoque de la Universidad Nacional de Quilmes, donde primero se ofrece una materia introductoria a la Ingeniería de Software que brinda al alumno una visión general de la disciplina, con un enfoque muy práctico y luego en siguientes cuatrimestres se ofrecen materias específicas para cada actividad: Ingeniería de requerimientos, Gestión de proyectos, Arquitectura de software, etc, etc.

Respecto del enfoque práctico, en concreto creo que es necesario hacer el ejercicio de construir/extender un pieza de software de cara a poner en práctica toda la teoría y técnicas enseñadas, tengo la sensación que enseñar ingeniería de software a partir de lecturas, cuestionarios y ejercicios conceptuales es insuficiente para formar profesionales de la informática y como dije antes el hacer estas actividades en materias separadas no me parece apropiado.

Creo que algunas de estas cuestiones han sido consideradas en el nuevo plan de la Licenciatura en Sistemas de la FIUBA (aunque no estoy seguro de hasta que punto). Espero también que estas cuestiones sean consideradas en el próximo plan de estudios de la carrera de Ingeniería Informática de FIUBA.

 

 

 

Cierre de cuatrimestre en UNQ (2015-2)

Un nueva cursada a ha terminado. Más allá de algún accionable menor surgido del feedback del cuatrimestre anterior no hicimos cambios relevantes este cuatrimestre.

Tuvimos 15 inscriptos (entre ellos 1 recursante) de los cuales 2 abandonaron la materia mientras que los otros 13 restante completaron la materia y aprobaron.

La nota promedio de aprobación fue 8.4/10 y el grado de conformidad de los alumnos con la nota obtenido fue 4.2/5.

La evaluación general de los alumnos según la encuesta anónima de cierre de la materia fue de 8.9.

A diferencia de cuatrimestres anteriores, en la retrospectiva de cierre de la materia no surgieron puntos relevantes (tal vez sea porque utilizamos una dinámica de retrospectiva nueva). Más aún algunos de los pocos puntos que surgieron, tuvieron opiniones distintas, o sea: algunos alumnos los consideraron como cosas a cambiar mientras que otros los consideraron como puntos importantes a mantener. Entre los pocos puntos que tomamos para mejorar/probar están:

  • Mejorar el feedback de las katas
  • Programar alguna kata en clase
  • Hacer alguna review online durante el desarrollo del TP final

Personalmente confirmo una vez más mi sensación de que realmente hemos logrado una muy buena materia en el sentido de que me hemos logrado una dinámica que nos ha permitido ayudar a los alumnos a incorporar nuevos conceptos y herramientas para su desarrollo profesional y académico.

Comparto aquí la foto de cierre y algunos de los videos de los TP finales:

eis_unq_20152