¡Agiles 2017 ya tiene fecha y sede!

¡Agiles 2017 ya tiene fecha y sede!

Hace un par de días el equipo organizador anunció que la conferencia tendrá lugar los días 12, 13 y 14 de Octubre, en la sede San Joaquín de la Universidad Técnica Federico Santa Maria (Santiago de Chile).

Personalmente estoy muy entusiasmado con esta edición de Agiles, en parte porque el año pasado no asistí, pero sobre todo porque parece que esté año la conferencia será distinta.

Históricamente la conferencia ha tenido un formato bastante tradicional con 2 días de sesiones surgidas de un Call-For-Papers y un día en formato Open Space. Pero parece que este año la mayor parte de la conferencia será en formato Open Space.

Para mantenerse informado de las noticias de la conferencia pueden seguir en Twitter la cuenta @agiles2017.

Preparando AyDOO@UNTreF 2017

El sábado pasado comenzamos a trabajar en la preparación de la materia Análisis y Diseño Orientado a Objetos. En términos generales mantendremos la dinámica del año pasado con la incorporación de algunos cambios surgidos principalmente del feedback de los alumnos.

El cambio más relevante para este año es que no seré único docente de la materia, sino que este año también serán parte del equipo docente Facundo Rodríguez Arceri y Diego Fontdevila.

El año pasado estimamos una carga de trabajo semanal extra-clase de 4 horas pero los alumnos reportaron unas 10 horas promedio de dedicación (un poco exagerado a mi parecer).  Para este año veremos de regular las tareas de manera que la carga de trabajo extra-clase esté más cercana a nuestra expectativa de 4 horas que a las 10 horas reportadas por los alumnos.

Continuaremos trabajando con Java y Ruby, pero posiblemente el trabajo con Ruby lo comencemos más tempranamente.

Según hemos acordado con la coordinación, la materia la estaremos dictando los días miércoles, en el horario de 18 a 22 en la sede Lynch.

 

Taller de Continuous Delivery

Por estos días me encuentro trabajando en la preparación de un Taller sobre Continuous Delivery. El taller surgió a partir del pedido concreto de un cliente, pero obviamente armar un curso para dictarlo solo una vez no es negocio, así que seguramente agende para volver a dictarlo en un futuro (interesados contactarme ;-)).

El taller es de índole de práctica, o sea los participantes ponen manos en la masa. Para ello he preparado una imagen de máquina virtual para que los alumnos hagan los ejercicios. Hay algunos ejercicios de carácter más teórico (por ejemplo diseño de ambientes) pero la mayoría son de índole práctica orientados a herramientas (por ejemplo configurar Jenkins para hacer deploy automatizado de una aplicación en diversos ambientes).

Comparto aquí un video con un poco más de información.

Cuando el mínimo producto viable es demasiado grande

El proyecto en el que estamos trabajando es una plataforma que nuestro cliente ofrece como servicio a sus propios clientes bajo un modelo tipo “suscripción”.

Más específicamente estamos construyendo una nueva versión de esta plataforma, pues el cliente ya tiene versión que ha construido durante varios años. Más aún el cliente ya está recuperando su inversión. Las razones que lo llevan al contratar a un nuevo proveedor para hacer una nueva versión de su plataforma no vienen al caso en este artículo, pero es interesante destacar que la nueva versión no incluye nuevas funcionalidades (al menos en un principio) aunque se espera que resulte mucho más estable y escalable. Pero esta cuestiones técnicas no son precisamente lo que más me inquieta.

El tema que más me inquieta tiene que ver con la planificación. Construir un nuevo producto con toda la funcionalidad existente en el producto actual podría llevarnos más de un año. Demasiado tiempo, demasiado riesgo.

En estos días precisamente estamos trabajando con la gente de negocio para intentar identificar un estrategia que nos permita liberar al menos una parte del producto y de esa forma comenzar a tener un retorno de la inversión y mitigar los riesgos.

Continuara…

 

Tarde de revisión de papers

Tarde de revisión de papers

Ayer pasé gran parte de la haciendo revisiones de papers para el Internacional Workshop on Software Engineering Curricula for Millennials que se realizará en Buenos Aires el próximo mes de Mayo como evento satelite de la conferencia internacional de Ingeniería de Software.

La revisión de papers no es una actividad que yo realicé muy a menudo, pero es algo que realmente disfruto porque más allá de estar en rol de “evaluador” lo veo sobre todo como una oportunidad de aprendizaje. Revisar un paper implica no solo leer el paper sino sobre todo entenderlo. Adicionalmente hay que verificar referencias a otros papers, reflexionar y dar feedback. Y por supuesto: hay que dar un dictamen.

Si bien es posible que para gran parte de la comunidad científica lo más importante de la revisión sea el dictamen (aceptado o no), yo considero que lo más importante es el feedback que se le da al autor, pues si bien un paper aceptado suma para un CV, el feedback permite mejorar y eventualmente volver a intentarlo en caso que el paper no resulte aceptado.

Categorias de prácticas DevOps

Por estos días me encuentro leyendo el libro de DevOps del SEI que me compré el mes pasado. Llevo leído aproximadamente un tercio de libro y por el momento viene bien, o sea, la mayoría de las cosas ya las conocía, algunas pocas no y otras pocas no estoy seguro de compartirlas. Entre las cosas que no conocía hay una en particular que me resultó muy interesante: la categorización de las prácticas DevOps. El libro propone agrupar las prácticas en 5 categorías:

  1. Hacer al grupo de Operaciones un ciudadano de primera clase (first-class citizen).
  2. Hacer al grupo de Desarrollo responsable del manejo de los incidentes en producción
  3. Establecer un proceso formal de deployment
  4. Usar Continuous Deployment
  5. Manejar la infraestructura como código

En teoría todas las prácticas DevOps podrían caer en alguna de estas 5 categorías. A mi parecer las 3 primeras categorías son más de índole “cultural” o de proceso, mientras que las 2 últimas son más de índole técnica. En este sentido el poder hacer la distinción puede ayudar a la hora de armar un plan de adopción de DevOps.