Notas de mis actividades en Colombia

Por estos días me encuentro en Girardot, una bonita ciudad ubicada a unas 2 horas al sur de Bogotá. Estoy participando de diversas actividades enmarcadas en el Foro de Ingeniería en Sistemas organizado por la Universidad Piloto al cual fue invitado por gentileza de ingeniero Elkin Forero.

La primer actividad que facilité fue una sesión de Programación Orientada a Objetos en la cual hice un breve repaso de los hitos que han marcado la evolución del paradigma y sus implementaciones. (diapositivas aquí)

Otra sesión, ya un poco más avanzada fue un taller de TDD, del que participaron alumnos de la carrera de sistemas. Trabajamos con Java, JUnit y Eclipse. Me gustó mucho como salió la sesión. El código del ejemplo inicial está disponible aquí.

Aprovechando mi visita a la región, el ingeniero Wilson Gordillo me invitó a realizar una ponencia en la Universidad de Cundinamarca. Asistieron a dicha actividad unos 180 alumnos y docentes de distintas instituciones. En este caso hablé sobre la definición de “proyecto exitoso” y la visión de los métodos ágiles al respecto (diapositivas aquí). Luego de la disertación hicimos la dinámica de la fábrica de aviones de la que participaron unas 80 personas y que nos permitió reflexionar sobre cuestiones como spikes, estimación y definition of done.

Aún me quedan por realizar algunas actividades más antes de mi regreso a casa, entre ellas la continuación del taller de TDD que comienza en breves minutos.

Continuará…

 

Preparandome para XP 2015

A fin de mes voy a estar viajando a Helsinki para participar de la conferencia XP 2015, donde además de disfrutar de la conferencia como asistente, estaré participando como orador/facilitador dos sesiones.

La primera de ellas es una sesión del tipo Technical Demo en la que estaré mostrado Octopush, una herramienta open source que desarrollamos con la gente de OLX para orquestrar deployments en contextos de entrega continua.

La segunda sesión que estaré facilitando es un taller de Behaviour-Driven Development. El taller está dividido en partes, la primera con foco en el flujo de trabajo y en las cuestiones de colaboración/comunicación y la segunda con foco en las cuestiones técnicas. Para esto último utilizaremos una máquina virtual con todas las herramientas ya instaladas de cara a poder utilizar mejor el tiempo del taller y no perder tiempo en instalación y configuración.

xp2105

Sobre el libro de experiencias Ágiles

En una de las sesiones del open space del Agile Open Camp propuse escribir un libro de experiencias contando casos de utilización de métodos ágiles en proyectos reales. La idea venía rondando en mi cabeza desde hacía ya bastante tiempo, creo que desde que leí el libro Anthology de la gente de ThoughtWorks, allá por 2009. Este libro no me pareció deslumbrante, pero me gustó y lo que más me llamó la atención fue su formato: el libro es básicamente un compendio de artículos de diversos autores, donde cada capítulos esto totalmente independiente del resto. Al mismo tiempo la escritura de Construcción de software, me generó muchas ganas de seguir escribiendo pero de forma más liviana (escribir este libro nos llevó unos 2 años) experimentando con alguna plataforma de autoedición.

El formato inmersivo del AOC me pareció ideal para hacer hacer un especie de hackaton de escritura, así que llegado el momento hice la propuesta.

De esta forma fue que el sábado 18 en el contexto del AOC,  justo antes de la cena nos sentamos a escribir la primera tanda de casos. Para el momento de la cena y en apenas 2 horas ya teníamos la primera versión cruda de 6 casos. Luego a lo largo de la semana fueron llegando más capítulos. Finalmente este último fin de semana trabajamos en la revisión/corrección y demás detalles de publicación. Para la escritura utilizamos lenguaje Markdown y trabajar coordinamos utilizamos GitHub. Finalmente para la edición, seguimos la sugerencia de Martín Salías y utilizamos la plataforma GitBook.

El resultado de este experimento es un libro gratuito que reúne 15 relatos de agilistas Argentinos. Algunos relatos cuentan prácticas/técnicas que funcionaron y otros cuentan prácticas/técnicas que no funcionaron lo cual también considero de gran valor.

Como coordinador/editor quiero agradecer a todos los autores que se sumaron a la iniciativa de este experimento. También quiero destacar y agradecer el impecable trabajo de revisión realizado por Thomas Wallet y la inagotable creatividad de Mauro Strione en el diseño de la portada creada sobre la base de una foto de Pablo Tortorella.

El libro está disponible para descarga gratuita en diversos formatos en: http://nicopaez.gitbooks.io/libroagileaoc2015/

Ejercicio de estimación

Un cuestión que siempre me hizo ruido de mi formación en FIUBA es el hecho de que en la materia que estudie métodos de estimación nunca me hicieron aplicarlos, o sea nunca me hicieron estimar, ¡cuac! Terminé la materia y sabía “los algoritmos de estimación” de memoria, pero en el contexto de la materia no los había aplicado nunca. Por suerte para esa altura de mi vida, ya tenía unos cuantos años de trabajo en la industria, con lo cual ya conocía algunos de los métodos vistos e incluso ya los utilizaba en mi trabajo diario.

Siendo consciente de esa falencia en mi formación, cuando comencé a dictar Ingeniería de Software en UNQ, me ocupe de incluir en la materia una clase práctica de estimación. El ejercicio que suelo utilizar para esa práctica se llama La fábrica de aviones y lo aprendí en un taller de Agiles 2009 en Florianópolis, Brasil.

El foco del ejercicio está en estimar la velocidad de un equipo y requiere simplemente varias hojas de papel tamaño a4 (~10 hojas por alumno). Describo a continuación la dinámica:

  1. Se divide a los alumnos en grupo5 (~5 por grupo)
  2. Cada grupo representa un fábrica de aviones y se les pide que indiquen que cantidad de aviones puede construir en un lapso de 10 minutos
  3. La forma de los aviones queda a criterio de cada grupo, pero deben asegurarse que el diseño elegido pueda volar X cantidad de metros (suelo pedir 5 metros)
  4. Se pide que cada avión cumpla con ciertos criterios estéticos: numéro de serie en las alas, nombre del equipo constructor a ambos lados, 2 puertas (una cada lado) y 6 ventanas (3 de cada lado). Todo esto se dibuja con lapicera en cada avión.
  5. Explicada la consigna se les pide a los alumnos que indiquen que cantidad de aviones pueden generar en 10 minutos. Difícilmente pueden hacer una estimación “razonable” sin haber generado al menos un avión. Si los alumnos toman conciencia de eso y aplican lo visto en la materia, deberian pedir una iteración para hacer un spike: generar un par de prototipos de avión y ver cuales son las implicancias de construirlos.
  6. Se les da entonces 1 iteración para generar algunos prototipos. Al final de la misma deben entregar el prototipo que copiarán las siguiente iteraciones y deben decir también que cantidad de aviones se comprometen a entregar al final de la siguiente iteración (básicamente tienen que estimar su velocidad).
  7. A partir de aquí se realizan iteraciones verificando al final de cada una que los aviones entregados cumplan con las condiciones previamente indicadas (3 y 4). Sólo se contabilizan aquellos aviones que cumplan con todas las condiciones, incluyendo el volar al menos X distancia.
  8. Luego de 3 iteraciones se ve que la velocidad del equipo se estabiliza.

Algunas variantes que pueden utilizarse sobre esta dinámica básica son:

  • Trabajar sobre las condiciones de aceptación y poner el foco en el Definition of Done
  • Modificar los equipo o la duración de las iteraciones para evidencias como eso afecta a la velocidad

Si alguno de los lectores llega a utilizar está dinámica me gustaría que me comentara los resultados.

Mis notas sobre AOC 2015

El fin de semana pasado participé del Agile Open Camp 2015. Como ya había mencionado, el evento se llevó a cabo en la Estancia del Carmen ubicada en las afueras de Bariloche.

Sin duda en varios aspectos este evento fue el mejor evento que participé en mi vida. Paisaje, logística, contenido, emotividad, actividades sociales y recreativas son algunos de las aspectos destacados del evento.

Creo que fue clave el hecho de que los participantes estuviéramos alojamos en el mismo lugar de la conferencia y al mismo tiempo que el lugar estuviera reservado (casi) exclusivamente para el evento. Esto permitió realizar diversas actividades “extra programa” luego de finalizadas las sesiones “formales” como ser juegos, espacios de meditación y guitarreadas hasta bien entrada la noche. Una de esas actividades extra formales fue la escritura de un libro (tema que compartiré en otro post).

Entre los momentos que más me impactaron están:

  • La visita al Invap, una empresa del estado dedicada a desarrollos de alta tecnología: radares, satélites, reactores nucleares, etc.
  • La charla Héctor Otheguy gerente general del Invap
  • El espíritu colaborativo que se vivió a la largo del todo el evento incluso en cuestiones casi domésticas como poniendo y levantando la mesa, preparando la comida y sirviéndola cuando estuvo lista
  • El exquisito cordero que comimos el sábado a la noche seguido de un fogón que incluyó guitarra, armónica, canciones y payadas.
  • La charla de Alan a la orilla del lago Gutiérrez con los cerros y el bosque de fondo
  • El cierre del evento con palabras emotivas de los organizadores y el entusiasmo de todos los participantes

Más allá de todas estas estas cuestiones también hubo un sesiones de open space que tuvieron muy buena repercusión como ser: el dojo de retrospectivas facilitado por Thomas Wallet, la sesión sobre trabajo remoto facilitada por Mariano Szklanny, la sesión de juegos facilitada por David Canteros, el elefante Agile de los muchachos de Invap, el taller de organizaciones de Martín Salías, la sesión de organizaciones horizontales de los muchachos de Grupo Esfera, el taller de identidad de Pablitux y Rodrigo Monelos y podría seguir un rato más.

Analizando el evento desde una perspectiva comunitaria creo que definitivamente ha marcado un hito:

  • Por un lado (hasta donde tengo registro) fue el primer evento “inmersivo”  y organizado en forma abierta por la comunidad ágil de Argentina . Me refiero al hecho de estar todos juntos, todo el día, por 3 días (en mi caso me levanté siempre alrededor de las 8 y siempre me acosté después de la 1)
  • Por otro lado fue un evento grande (3 días con fuertes implicancias de logística y unos 70 participantes) y fue auto organizado por los propios participantes con el liderazgo de un grupo de entusiastas locales que fueron los que tuvieron la idea del evento.

Mis felicitaciones para el core del grupo de organizadores: 

Les dejo aquí algunas fotos memorables:

aoc_summary_1 aoc_summary_2 aoc_summary_3 aoc_summary_4

Agiles 2015: llamado a presentación de sesiones

Hace un par de días abrimos el llamado a presentación de sesiones para Agiles 2015. Me alegra mucho el hecho de que ya hemos recibo 6 propuestas y apenas pasaron 3 dias desde que comenzamos con la difusión.

Tal como había mencionado en algún artículo anterior, este año tenemos algunas novedades respecto del proceso de evaluación/selección de sesiones. En primer lugar estamos pidiendo que cada propuesta venga acompañada de un video de 3 minutos donde el autor de la sesión haga una invitación a participar de la misma. Esto tiene un doble objetivo: por un lado ver como se expresa el autor, escucharlo hablar y por otro lado tener material para difundir el evento una vez la sesión haya sido seleccionada para el evento.

Otro novedad es que hemos incluido explícitamente una instancia de feedback en la cual el grupo de evaluadores de la conferencia se compromete a dar feedback concreto a los autores para que estos puedan mejorar así su propuesta y aumentar las chances de que su sesión sea seleccionada.

En tercer lugar hemos agrupado los temas de interés en 3 grupos (temas técnicos, de gestión y extra-software) asignando a cada uno un coordinador que se encargará de responder consultas de los autores, coordinar el proceso de evaluación de las propuestas de su track y finalmente coordinar el armado de la grilla del track. Al igual que en años anteriores, también es posible que toda persona de la comunidad vea las propuestas y envíe feedback a los autores por medio del sistema

Finalmente, la última novedad tiene que ver con la aplicación que estamos usando para gestionar el envío/revisión/evaluación de sesiones. Estamos estrenando una aplicación creada a medida que comenzamos a codear en Agiles 2014 y que luego @fdibartolo se encargó de completar. Para ser sinceros, Fer la codeó casi de cero pues en Agiles 2014 apenas si llegamos a armar la estructura y definir algunas entidades. ¡Grande Fer!

Bueno gente, esto es todo por ahora, los invito a poner manos a la obra y enviar sus propuestas. Aquí está el detalle del llamado y aquí está el sistema para enviar sus propuestas (y también para ver las propuestas ya subidas).

opencall_home

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

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:

DevOps ¿es un realmente un rol?

Érase una época en que las organizaciones operaban como silos, con un área de desarrollo por un lado y una área de operaciones/infraestructura por otro. Estas dos áreas no sólo hablaban poco entre ellas sino que incluso en algunos casos guardaban cierto rencor entre sí. Programadores y Sysadmins enfrentados mutuamente como Vampiros y Hombres-Lobo, porque obviamente más allá de las diferencias que ellos percibían, para todo el resto de la organización eran más o menos lo mismo: gente rara del área de TI.

La adopción de métodos ágiles en las áreas de desarrollo ayudó que los desarrolladores se acercarán más al negocio y al resto de las áreas de la organización. Agile fue algo así como la sustancia que permite a Blade exponerse la luz solar y vivir más como humano que como Vampiro. Pero en la gran mayoría de los casos la fórmula de Blade no tuvo efecto en los Hombres-Lobo, quienes quedaron aún más aislados del resto de la organización.

En varias organziaciones la cuestión se puso aún más interesante cuando los equipos usando agile pretendieron salir a producción en forma frecuente. Tradicionalmente los pasajes a producción ocurrian cada un par de meses y era entonces cuando la relación entre Programadores y Sysadmins alcanzaba los picos máximos de tensión. Ahora los programadores agile pretendián ir a producción cada 2 semanas y encima contaban con el apoyo (y el entusiasmo) de la gente de negocio. Para los Hombres-Lobo esto era demasiado: ahora los Vampiros tenian el apoyo de Blade y los humanos.

Y como suele ocurrir en todas las guerras, el mayor perjudicado con todo esto era el pueblo (que en este caso era la organización). Fue en este contexto donde surgió el la iniciativa de DevOps como una propuesta para acercar a los programadores y los sysadmins y lograr que cada uno trabajé consciente de la existencia y responsabilidades del otro. Es aquí donde las implementaciones de DevOps divergen en dos estrategias.

Por un lado algunas organzaciones generan un nuevo rol al que denominan DevOp con el objetivo de mediar entre programadores y sysadmins. Si bien creo que inicialmente esta estrategia puede ayudar mejorar la situación, creo que no es más que un remiendo. Estos DevOps cuentan generalmente con habilidades técnicas mixtas, o sea son una especie de Hombre-Lobo-Vampiro y en última instancia son un bicho raro más a los ojos del resto de la organización.

Por otro lado, algunas otras organizaciones ven DevOps como una transformación en la organización mediante la cual programadores y sysadmins dejan de lado su egoísmo para trabajar colaborativamente unos con otros (al mejor estilo Saga Crepúsculo parte 3) de cara a lograr una feliz convivencia con los humanos y el resto de la organización.

Personalmente me inclino por esta segunda estrategia de DevOps aunque reconozco que en ciertos casos la primera estrategia puede resultar beneficiosa siempre y cuando quienes ocupen el rol de DevOps cuenten con habilidades blandas (gestión, facilitación, etc) más allá de las habilidades técnicas.

Nobleza obliga: la analogía con Vampiros y Hombres-Lobo está tomada de un artículo publicado por Jeff Atwood en su blog CodingHorror.com.