Sobre mi keynote en Agile Open Camp

El Agile Open Camp tendrá un formato Open space pero con 5 keynotes predefinidos y resulta que fui invitado para dar uno de ellos. Si bien ya había dado keynotes en el pasado, incluso en eventos más grandes, siento que este caso es distinto. En primer lugar porque tengo una gran expectativa con el evento, creo que a nivel comunidad puede marcar un hito en lo que respecta a la forma de organización. Al mismo tiempo sé que en el evento estarán presentes varios de los referentes de la comunidad lo cual en cierto modo me mete un poquito más de presión.

En lo que a temática refiere me enfocaré en DevOps, algo con lo que vengo trabajando muy fuerte en los últimos 3 años y que me parece es un tema bastante “picante” en este momento.

Finalmente me siento obligado a hacer una aclaración. Desde hace ya un tiempo que vengo “pateando en contra” de tener keynote speakers en los eventos que organizamos en la comunidad Agiles ¿Y ahora voy a ser keynote speaker? Si. La explicación de mi posición respecto de esta cuestión merece un post aparte, con lo cual por el momento me voy a limitar a decir simplemente que a pesar de ser keynote speaker no espero recibir ningún trato especial, que es justamente lo que siempre me ha molestado de los keynote speakers. Espero ser un chango más en la multitud, compartiendo los mismos espacios y actividades que el resto de los asistentes. La única diferencia será que en determinado momento tendré el honor de hablar frente a todos ellos en una sesión predefinida (en el sentido que no pasará por el marketplace del open space.)

El Configuration Manager: habilidades y conocimientos

Una empresa con la estoy trabajando actualmente tomó la decision de tener dentro de cada equipo una persona con el rol de configuration manager. Inicialmente me generó ciertas sospechas, la única persona que conocí ocupando formalmente un rol así realizaba tareas que restaban mucho más de lo que sumaban y por ello los equipos terminaban ignorándola. Al mismo tiempo los proyectos exitosos que conozco deben parte de su éxito al hecho de que el equipo maneja las tareas de configuration management de forma integral en el día a día del proyecto.

Pero luego de pensarlo más detenidamente y analizando las particularidades del contexto, me autoconvencí que tener un configuration management por proyecto podía ser una buena idea  ya que en términos generales los equipos no tenían un buen control de la configuración debido en gran parte a falta de conocimiento. Entonces la idea era que estos CM se encarguen de ayudar a los equipos a incorporar prácticas de control de la configuración.
Ya convencido de la idea me puse a pensar que habilidades y conocimientos debería tener una persona para ocupar el rol de CM tal como lo estaba planteando esta organización. Más allá de conocimientos generales de Configuration Management, que se mencionan en cualquier libro de Ingeniería de Software identifiqué los siguientes puntos:
  • Background de desarrollo / perfil técnico
  • Sólidos conocimientos del sistema de control de versiones de la organización (Git en este caso)
  • Sólidos conocimientos de la herramienta de build de la organización (Maven en este caso)
  • Conocimiento de Build Server (Jenkins en este caso)
  • Conocimiento de bash
  • Disciplina
  • Capacidad de aprendizaje
  • Capacidad de liderazgo

 

 

BDD, ATDD y SBE ¿es todo lo mismo?

En la actualidad nos encontramos con estos 3 acrónimos que en muchas ocasiones son utilizados como sinónimos y cuya diferencia no es del todo clara. Más aún, en Una Mirada Ágil los mencionamos a modo informativo sin entrar en mayor detalle pues consideramos que en esencia todos apuntan a lo mismo: la importancia central del trabajo colaborativo entre técnicos y la gente del negocio para especificar la funcionalidad a construir utilizando ejemplos concretos. Y también todas ponen el aspecto colaborativo por encima del aspecto técnico (ejecución automatizada).

Personalmente creo que las principales diferencias radican en que cada uno de estos términos surgió como consecuencia de distintas líneas de trabajo que se desarrollaron en paralelo con distintos protagonistas, todos ellos trabajando principalmente desde la industria y bajo un paradigma de desarrollo ágil. Más allá de los argumentos que pueda tener cada uno de los protagonistas para insistir con su terminología creo que adicionalmente hay una cuestión natural de “orgullo” (y posiblemente también de negocio/marketing) que en cierto modo dificulta la unificación de terminología. Como suele decirse: “Cada maestro con su librito”.

Más allá de esto quisiera dedicar algunas líneas a cada propuesta en particular:

Behaviour-Driven Development (BDD)

Este es el término posiblemente más utilizado en la actualidad, muy asociado a la familia de herramientas Cucumber y cuyo mayor referente es Dan North. El mismo North define BDD como:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. 

Resalto aquí el hecho de considerar BDD una metodología lo cual es posiblemente la mayor diferencia (a nivel de marketing al menos) con las otras técnicas.

Acceptance Test-Driven Development (ATDD)

Sin duda el punto inicial de todo esto fue TDD, cuya concepción original por Kent Beck era levemente distinta a la actual. Inicialmente Beck hablaba tanto de prueba unitarias como de usuario (customer tests en términos de XP), pero con el correr del tiempo el término TDD fue tomando una connotación unitaria, o sea, en la actualidad TDD se interpreta casi exclusivamente como UTDD (Unit Test-Driven Development). De ahí la necesidad de utilizar el término ATDD para referirse explícitamente a un ciclo de más alto nivel en el cual está involucrada la gente de negocio. Una curiosidad es que Beck en su libro TDD by Example menciona ATDD, pero como acrónimo de Application Test-Driven Development en lugar de Acceptance que es el término utilizado en la actualidad.

Specification by Example (SBE)

Este es el término impulsado por Gojko Adzic y personalmente es el que más me gusta. No porque proponga algo muy distinto, sino simplemente por la terminologia que propone. En el prefacio de su libro Specification by Example Gojko propone una terminología y explica porque la terminología alternativa comúnmente utilizada no le resulta apropiada.

Finalmente no quiero dejar de mencionar que hay algunos otros términos que también suelen utilizarse como sinónimos y que en esencia son lo mismo pero cuya popularidad es mucho menor. Entre ellos se encuentran Story Test Driven Development (STDD) y Example-Driven Development (EDD).

BDD, ATDD y SBE ¿es todo lo mismo? Si.

Breve historia de las herramientas BDD – parte 2

En un artículo anterior conté una parte historia, he aquí la otra.

Mientras que Dan North y los suyos trabajaban sobre JBehave y afines que luego llevarían al surgimiento de Cucumber, Ward Cunningham trabajaba en cuestiones relacionadas a pruebas de aceptación.

El trabajo de Cunningham se tradujo concretamente en una herramienta llamada FIT: Framework for Integration Testing, cuyos objetivos pueden resumirse como:

  • Ayudar a pensar y comunicar las necesidades que debe cubrir una aplicación de software en base a ejemplos concretos de uso
  • Probar automáticamente desde una perspectiva de negocio que una aplicación de software hace lo que efectivamente se espera de ella y que continúa haciéndolo a medida que crece en funcionalidad

Para lograr esto, FIT propone escribir los ejemplos con herramientas capaces de generar HTML (Word, Excel, etc) utilizando distintos tipos de tablas para dar cierta estructura unificada a los ejemplos y facilitar así su interpretación. Una vez escritos los ejemplos trabajando en conjunto con gente de negocio y técnicos, se escribe código Java que interpreta la tablas e interactúa con la aplicación en cuestión.

El propio Ward Cunningham escribió la primera implementación FIT en Java, mientras que tiempo después James Shore tomó la coordinación general del proyecto y colaboró en la implementación en C#.

En 2005 Ward Cunningham junto con Rick Mugridge publicaron el libro Fit for Developing Software: Framework for Integrated Tests, el cual explica de forma bastante detallada el uso de FIT.

A lo largo del tiempo han ido surgiendo diversas herramientas en el ecosistema FIT, algunas de las cuales se integran con FIT mientras que otras lo extienden. Una de las más destacadas es FitNesse, desarrollada por inicialmente por Robert Martin y que en cierto modo agrega una interface de usuario por encima de FIT permitiendo que los ejemplos sean escritos en una Wiki. De esta forma FitNesse oficia de interface de usuario y FIT de motor de ejecución. Esta combinación tuvo buena recepción en la comunidad y para 2006 David Chelimsky y Mike Stockdale ya habían publicado una implementación de FIT en C#.

Fue a partir de esa implementación en C# que en 2008 Gojko Adzic publicó el excelente libro Test Drive .NET Development with FitNesse. Si bien este libro tiene un foco técnico, el autor resalta la importancia del trabajo colaborativo en entre gente de negocio y técnicos para la identificación y especificación de ejemplos. Los siguientes libros de Gojko se centraron precisamente en estas cuestiones de colaboración dejando de lado las cuestiones técnicas.

Fuentes:

Expectativas para el nuevo cuatrimestre en FIUBA

Esta semana comenzó el cuatrimestre en FIUBA. En el curso 3 (miércoles) tenemos poco más de 40 alumnos 2 de los cuales son de intercambio (uno de Colombia y otro de Francia). Respecto del equipo docente, quedó conformado por DiegoM, PabloRM y yo, lo cual no dá prácticamente unos 15 alumnos por docente, un número no tan malo tratándose de UBA, sobre todo si tenemos en cuenta que según la política de la facultad la relación debería ser de 1 docente cada 20 alumnos.

Como de costumbre, la gran mayoría de los alumnos (~85%) son de la carrera de ingeniería informática.

En términos generales no tenemos planificadas grandes innovaciones para este cuatrimestre, pero en particular en el curso de los miércoles intentaremos realizar más actividades de programación en clase, ya que según pudimos relevar en la primera clase, muchos alumnos podrían asistir a clase con sus computadoras personales.

fiuba_2015

 

Cuando un libro te toca: #MasProductivos

Hace unos días tuve un intercambio de mails con un colega que ya al tercer mail empezó a levantar temperatura. Escribí el quinto mail del intercambio, lo releí y de repente me acordé algunas cosas que había leído en el libro #MasProductivos de @martinalaimo. Le di vueltas en mi cabeza por un par de minutos y finalmente terminé escribiendo:

“Creo que entiendo tu punto y me parece que hay algunas cosas que no comparto, pero no considero que el mail sea el medio más apropiado para intentar ponernos de acuerdo. A menos que tengas una propuesta diferente, te propongo hablar este tema mañana cuando nos veamos físicamente”

Recibí una respuesta corta y positiva. Al día siguiente, tuve la charla presencial con mi colega y rápidamente pudimos llegar a un acuerdo win-win sin ningún tipo de rispideces 😉