Consideraciones para habilitar el homeworking

El homeworking es una de las prácticas que a mi parecer está ganando gran popularidad en los ambientes informáticos. En particular en Buenos Aires existe hoy en día una gran demanda de profesionales informáticos y varias empresas «ofrecen como beneficio» la posibilidad de hacer homeworking 1 o 2 días por semana. Personalmente me gusta mucho el homeworking, yo soy bastante organizado y realmente logro ser muy productivo trabajando desde casa, sumado al hecho que me ahorro tiempo de viaje y caos de tránsito. Pero al mismo tiempo creo que es un cuestión que no debe tomase a la ligera.

Para empezar considero que el homeworking no es para todos. Ni para todos los proyectos, ni para todas las personas, ni para todas las organizaciones.

Hay proyectos en los que se requiere que la gente esté físicamente junta, tal vez no todo el tiempo, pero si en determinados momentos/temporadas (típicamente al comienzo del proyecto).

Al mismo tiempo, si una organización pretende habilitar el trabajo homeworking debe proveer cierta infraestructura para hacerlo posible, me refiero a cuestiones como algún sistema para conferencias online (skype, hangout, etc), acceso remoto a los servicios/servidores de la organización (ambiente de test, servidor de integración, sistema de tickets, etc, etc).

Finalmente respecto de las personas, es necesario saber organizarse y tener cierto nivel de autonomía en el trabajo. Este último punto no es trivial, pues la autonomía requiere ciertos conocimientos, tanto del contexto/organización como también de las tecnologías a utilizar.

Por otro lado hay un «anti-patrón» que he visto en varias ocasiones: tomar el homeworking como «obligación»: «yo los miércoles trabajo desde casa» cuando en realidad me parece que debería ser algo más del estilo «yo los miércoles intento trabajar desde casa, pero si el proyecto/contexto lo requiere vemos como manejarlo (obviamente procurando no perder el beneficio 😉 )«.

Chat no mata mail

En el último año he visto muchos equipos comenzar a utilizar herramientas de chat comunitario. Slack, Campfire, HipChat y Gitter son algunas con las que tuve la oportunidad de trabajar. Algunos equipos suelen utilizar este tipo de herramientas como medio de reemplazo del mail, integrando con las mismas todas la notificaciones y reemplazando así aquellas notificaciones que tradicionalmente se recibían por  mail.

Si bien me parece que estas herramientas pueden resultar útiles para determinadas situaciones creo que de ninguna manera reemplazan al mail. En mis proyecto me gusta siempre contar con lista de correo independientemente que se cuente o no con una herramienta de chat comunitario.

Personalmente me resulta mucho más cómodo el uso del mail para mantener discusiones asíncronas las cuales a mi parecer no resulta cómodo manejarlas vía chat. El chat me parece genial para mantener discusiones en vivo cuando uno requiere interacción inmediata pero no para estos casos de respuestas no urgentes y tardías. Al mismo tiempo tengo la sensación que entrar a un chat y ponerse a revisar mensaje viejos es extremadamente incómodo.

Voy a ejemplificar con algunos casos para los que considero que una lista de mail resulta mucho más apropiada que el chat.

  • Discusiones de refactoring: estoy codeando y veo a la pasada algo que no me cierra y que me parece merecería un refactor pero que no es trivial de realizar. Entonces planteo la discusión por mail pues no es algo urgente. De esa forma cada uno puede responderlo cuando lo considere apropiado y una vez lograda una decisión vemos de agendarlo para trabajar en una iteración futura (posiblemente con una charla presencial de por medio)
  • Diseño de producto: similar al caso anterior pero desde la perspetiva de producto, se me ocurre que se podría agregar/modificar una funcionalidad, entonces inicio una discusión por mail con el Product Owner y el equipo para ir hablando el tema antes de llegar a la próxima planning.
  • Intercambio de información con miembros externos al equipo: tengo que avisar a mi comunidad de usuarios que se realizará una tarea de mantenimiento de la aplicación, entonces mando un mail con este aviso y pongo en copia oculta la lista de correo del equipo desarrollo. De esta forma el equipo tiene presente la tarea de mantenimiento y está al tanto que los usuario ya fueron notificados.

En forma resumida mi opinión es: Chat no mata mail.

Más de 10 años de blogging

Ayer por casualidad caí en la cuenta de que hace 10 años que escribo este blog, aunque no siempre estuvo hosteado aquí. Actualmente este blog está hosteado en WordPress, pero antes de llegar aquí pasó por otras plataformas.

Mi primer blog lo empecé a escribir en 2006 con el fin de llevar una bitácora de mi trabajo en mi tesis de grado, por ello el blog estaba dedicado a cuestiones de Programación Orientada a Aspectos. Ese primer blog estaba hosteado en Blogger.

Un par de meses después, mientras trabajaba en Microsoft empecé a escribir un segundo blog en el cual escribía principalmente sobre cuestiones relacionadas a mi actividad profesional en Microsoft (la difusión de tecnología .Net) y de vez en cuando colaba alguna que otra entrada sobre cuestiones de agilidad.

En mi paso por Snoop y Southworks también escribí algunas entradas en sus respectivas plataformas de blogging.

Cuando finalmente me mudé a WordPress, traje conmigo las entradas de mis blogs anteriores.

A lo largo de estos 10 años también he ido alternando el idioma. En algún momento se me había dado por escribir en inglés, simplemente para practicar mi escritura en ese idioma. Luego, cuando empecé a dedicar la mayor parte de mi escritura a cuestiones de agilidad, me pareció importante escribir en castellano, pues en aquel momento escaseaba el contenido sobre agilidad en castellano. Actualmente escribo casi todo el tiempo en castellano y dejo el inglés para algunas situaciones muy particulares como cuando asisto a conferencias fuera de Latam.

A los largo de estos años la cantidad de visitantes del blog ha ido en aumento, pero sinceramente no es algo que me preocupe, pues en la mayoría de los casos escribo para mismo, ya sea a modo de recordatorio de como resolver un determinado tema o bien como bitácora de los proyectos en  los que voy participando.

Al día de hoy este blog cuenta con 763 artículos y en los últimos años he tenido un promedio de publicación de ~100 artículos/año, lo cual representa algo asi como un artículo cada 3,6 días. Nada mal, aunque a pesar de la práctica aún no estoy conforme con la calidad de mi escritura.

Este año tengo pensado volver a trabajar en un investigación, con lo cual sospecho que la la cantidad de entradas puede llegar a estar por encima del promedio.

 

Convocatoria de autores para el libro del AOC 2016

La semana pasada me informaron que mi postulación para el AOC había sido aceptada, con lo cual está confirmada mi participación en la conferencia.

La propuesta que envié como parte de mi postulación era para escribir un libro similar al del año pasado pero dando una vuelta de rosca sobre el contenido. El libro que escribimos (y publicamos) el año pasado era un compendio de experiencias.

Este año me gustaría que el libro sea un compendio de técnicas. Creo que existen en la actualidad diversas técnicas comúnmente utilizadas en el desarrollo de software que no están (hasta donde yo sé) formalmente documentadas en castellano. Me vienen a la mente técnicas como Impact Mapping y Mob-Programming. Al mismo tiempo creo que todo equipo luego de alcanzar cierto grado de «madurez» empieza a generar sus propias técnicas/prácticas/costumbres que bien pueden resultar de utilidad para la comunidad de practicantes. Me vienen a la mente el Delivery Map usábamos en Southworks y el ApplicationStatus que suelo utilizar en mis aplicaciones.

Por otro lado también quisiera hacer un cambio en la dinámica, me gustaría que este año lleguemos a la conferencia con todos los capítulos ya escritos, de manera que el tiempo dedicado en la conferencia sea para tareas de edición y revisión.

Con este artículo abro la convocatoria de autores para este segundo libro. Los interesados en sumarse a esta iniciativa por favor contactarse conmigo.

Nuevo proyecto: java, micro-servicios y entrega continua

Esta semana empecé a trabajar en un nuevo proyecto. Se trata de una aplicación que una empresa desarrolló para uso interno hace ya varios años y que ahora quiere»productizarla» para ofrecerla a terceros y montar un esquema de Software As A Service. Es ahí donde entro yo para dar una mano en «la productización» colaborando en cuestiones de refactoring de arquitectura, tareas de automatización, monitoreo y ajustes en el proceso de desarrollo.

La aplicación nació como un monolito Grails que fue evolucionando a lo largo de los años incorporando nuevas funcionalidades, en este momento está corriendo sobre Grails 2.5. Recientemente se decidió pasar a una arquitectura de micro-servicios construidos con Spring Boot sobre Java 8.

Más allá de las cuestiones técnicas, hay algunos issues a nivel de dinámica de trabajo. Si bien el equipo trabaja en un esquema tipo Scrum, el testing de la aplicación lo realiza otro sector de la empresa y es testing manual. Esto genera importantes delays en el release, ya que muchas veces se llega al final de la iteración y no se puede pasar a producción pues hay funcionalidades no testeadas.

Continuará…

Iniciativa de Software Craftsmanship en Buenos Aires

El movimiento de Software Craftsmanship (SC) surgió hace un par de años y al igual que ocurre con el movimiento ágil cuesta poner una fecha «de fundación». Si bien el manifiesto de Software Craftsmanship data de 2009, algunas publicaciones al respecto son bastante anteriores: Software Craftsmanship: The new Imperative (2001) y The Pragmatic Programmer (1999).

El movimiento de SC ha tenido un gran crecimiento en los últimos años y varias conferencias han potenciado su difusión. Entre estas conferencias destaca sin duda SoCraTes (Software Craftsmanship and Testing Conference) la cual desde 2010 se ha replicado en distintos países (Alemania, UK, Bélgica, Francia, España)

En paralelo con el crecimiento de este movimiento han surgido también algunas críticas/debates que han sido muy resumidos por Martin Fowler en su artículo Craftsmanship and the Crevasse.

Hasta donde tengo conocimiento no existe hoy por hoy en Buenos Aires un espacio comunitario que trate sobre este movimiento. Al mismo tiempo dada la cercanía de este tema con agile, creo que podría ser interesante reflotar los encuentros mensuales de Agiles@BuenosAires para hacer algunas actividades de Software Craftsmanship. Manos a la obra.

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

 

Automatización de pruebas en AS400, fin de la historia

Como mencioné tiempo atrás, en octubre comencé a trabajar en un proyecto para automatizar pruebas de una aplicación RPG/AS400. He completado mi participación en el proyecto, logramos dejar una arquitectura de pruebas funcionando con un par de casos automatizados, ahora está en manos del propio equipo de desarrollo continuar agregando nuevos casos.

El siguiente gráfico resume la arquitectura implementada:

test_as400

La arquitectura está armada de forma tal que un tester puede agregar fácilmente nuevos casos sin tener que meterse mucho en el código. Algo de código obviamente va a ser necesario escribir pero por la forma en que todo quedó armado (con template methods) es realmente poco lo que hay que codear.

Los casos de pruebas se generan con FitNesse y luego el gluecode/driver utiliza dos librerías de IBM: una para invocar funciones nativas en AS400 que se encargan de hacer el setup del ambiente con los datos iniciales y otra para la creación de las colas MQ y para leer/escribir en dichas colas.

Como la aplicación y los tests están codeados en distintas tecnología y almacenados en distintos repositorios, el servidor de integración continua (jenkins) quedó configurado para correr el set de tests ante cada commit y también en forma periódica 3 veces al día.

Estoy conforme con el resultado de nuestro trabajo, al mismo tiempo creo que fue un lindo desafío que me permitió aprender un poquito del mundo AS400. Ahora está en manos del codear más pruebas y sacar valor al trabajo realizado.