Mes: febrero 2017

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

El desafío de las pequeñas empresas de IT versus las grandes multinacionales

El año pasado tuve la oportunidad de trabajar por un período muy breve con un joven y talentoso ingeniero de @Fiuba. En aquel momento él trabaja para una empresa de desarrollo de software de tamaño mediano (en términos de Argentina serian unos 100 empleados). Recientemente supe que fue contratado por una empresa multinacional y eso me recordó un pasaje de mi propia carrera profesional. Al mismo tiempo me puse a pensar ¿como pueden hacer las pequeñas empresas para retener a sus talentos ante las ofertas de las grandes empresas?

En primer lugar sospecho que la cuestión no pasa por dinero/beneficios, porque creo que incluso cuando las pequeñas empresas pudieran competir (o incluso superar) las ofertas económicas de las grandes empresas, creo que hay otra serie de cuestiones mucho más influyentes. Tomo mi propio caso, cuando decidí trabajar para un gigante multinacional no lo hice por dinero sino para ganar experiencia y hacer carrera. El trabajar en una empresa grande de primer nivel mundial ofrece una serie de oportunidades/desafíos que para algunos (yo incluido) resultan sumamente atractivos.

Hace un par de días vengo pensando sobre este tema y se me ocurrieron dos estrategias posibles para competir con las grandes empresas:

  • Ser parte: conozco un par de casos de empresas pequeñas (menos de 50 empleados) que a partir de una estructura casi horizontal cuentan con mecanismos para hacer participes a su gente del rumbo de la empresa. Un caso de esto es @10Pines.  Otro caso similar pero un poco distinto es Tecso, que tiene la particularidad de ser bastante más grande (creo que son más de 200 empleados). Creo que el «ser parte» en este sentido puede resultar muy incentivo muy importante y muy difícil de lograr en las grandes empresas (aclaración: tener acciones de la empresa no necesariamente te «hace parte»)
  • Plan de carrera: este punto es justamente una de las falencias de muchas empresas chicas, no tienen planes de carrera, cosa que si suelen tener las grandes empresas. A pesar de esto creo que si las empresas chicas invirtieran en armar planes de carrera, podrían ofrecer a sus empleados alternativas incluso más interesantes que las ofrecidos por las grandes empresas. Un situación común en las grandes empresas es que a partir de cierto punto para crecer hay que ocupar una posición de gestión, o sea los planes de carrera para perfiles técnicos suelen ser muy limitados. Una empresa pequeña que me consta supo tener en algún momento un plan de carrera claramente definido y muy atractivo para gente de perfil técnico fue @Southworks.

¿Alguna otra idea o comentarios para sumar?