Mes: enero 2016

3 semanas de proyecto

El miércoles pasado se cumplieron 3 semanas/iteraciones desde que empecé a trabajar en mi proyecto actual. En estas semanas creo que hemos hecho algunos avances importantes respecto al producto y a la forma de trabajo:

  • Mejoramos «el teamwork»
    • ahora el equipo se sienta todo junto en la misma mesa
    • dimos un par de pasos para integrar a los miembros con asignación part-time (testing y UX)
    • creamos una lista de correo que tiene bastante vida y que nos permite estar más comunicados principalmente los días que hacemos homeworking
  • Respecto de los aspectos técnicos del proceso de desarrollo
    • tenemos 2 ambientes de testing: uno para tests automatizados y otro para tests manuales
    • agregamos tests automatizados
    • automatizamos el deployment a los distintos ambientes
    • empezamos a desplegar la aplicación en forma frecuente
    • ordenamos el versionado del producto agregando release notes y tags en los repositorios
  • Finalmente respecto del producto
    • hicimos un refactoring de arquitectura que gradualmente nos permite movernos de una arquitectura monolítica a una esquema de microservicios
    • como consecuencia del refactoring mejoró la estabilidad del producto

Personalmente estoy contento con como venimos avanzando y con los desafios que aún nos quedan por delante.

Continuará…

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.