Y un día me fui de tema y la pasé bien: Open Space BA Turismo

El jueves pasado participé como facilitador de una jornada de trabajo organizada por el área de turismo del gobierno de la Ciudad de Buenos Aires.

Si bien me he desempeñado como facilitador en distintos eventos en el pasado, todos ellos siempre habían estado relacionados de una u otra forma al desarrollo de software. Cuando María e Ingrid de Fuerza Tres me invitaron a participar de esta actividad, lo dudé 30 segundos y acepté, ya que me pareció un desafío interesante por obligarme a salir de mi zona de confort y en cierto modo probarme en un contexto distinto al que suelo trabajar. Otro punto que me motivó para participar fue el hecho de trabajar con el gobierno, algo que no suelo hacer y que me resulta interesante ya que muchas veces las iniciativas de gobierno tienen impacto en la sociedad, cosa bastante menos común en el sector privado.

La semana previa al evento tuvimos una reunión de coordinación con todos los miembros del equipo que estaría a cargo de la facilitación. Debo admitir que por un momento me sentí sapo de otro pozo ya que la mayoría del equipo procedía de campos de trabajo bastantes distintos al mío, pero a medida que comenzamos a interactuar fui sintiéndome más cómodo.

La jornada tuvo lugar en el Centro Metropolitano de diseño y los participantes eran personas del sector público y privado del área de turismo. Largamos alrededor de las 9.30 con la bienvenida de uno de los funcionarios del ministerio. Luego de ello María Mauro y yo nos encargamos de explicar la dinámica de trabajo la cual fue en cierto modo similar a la de un open space (de hecho el evento estaba titulado Open Space Turismo). Inicialmente hubo un marketplace donde para mi sorpresa los participantes (casi en su totalidad sin experiencia en open spaces) presentaron muchísimas propuestas a un ritmo que nunca me hubiera imaginado. No terminaba uno de explicar su propuesta que ya había otro tomando su lugar. Increible. Luego de ello se paso a votar las propuestas y se ubicaron en la grilla las 10 propuesta más votadas y que serían sobre las que se trabajaría continuación. Cada propuesta se trabajó en un mesa con asistencia de los interesados y la colaboración un facilitador.

open_space_turismo

La facilitación gráfica fue realizada por Patricia Mollá.

El trabajo en las mesas duró casi dos horas y estuvo enfocado en identificar acciones concretas para realizar en cada una de las temáticas en cuestión. Ya hacía el mediodía se hizo una puesta en común de lo trabajado en las mesas y otro funcionario se encargó de las palabras de clausura. Como cierre compartimos un almuerzo.

Aún tenemos pendiente como cierre del trabajo la entrega de un informe, tareas que esperamos completar esta semana.

Una vez más la dinámica de agenda abierta característica de los Open Space ha resultado exitosa, y más aún, creo que funcionó mucho mejor que en algunos otros encuentros en los que he participado.

Me sentí muy bien, me gustó mucho el trabajo con el grupo de facilitadores, la demás gente de la organización y los participantes. Creo que el todo el evento estuvo muy bien.

Finalmente quiero agradecer especialmente a Maria e Ingrid por haberme invitado a participar de esta experiencia.

acreditacion_open_space_turismo

Un programador de otro pozo

Recientemente leí un artículo escrito por Hernán Wilkilson sobre las nuevas características incluidas en la versión 8 de Java. Más allá del interesante análisis que hace Hernán, creo que son muy valiosas las ideas compartidas en la conclusión del artículo (recomiendo tomarse unos minutos para leerlo) sobre todo el llamado a los programadores a “abrir a la mente”. Profundizando en este llamado quiero sumar algunas impresiones.

Como dice la frase “el que tiene un martillo en la mano sólo ve clavos”, las herramientas que utilizamos para resolver los problemas influyen de forma determinante en las soluciones que diseñamos. Si bien ya hace años que tomé conciencia sobre este hecho, me sorprendí muchísimo cuando hace unos meses me sumé a trabajar en un proyecto Java con un equipo de experimentados programadores que en su carrera profesional habían trabajado casi exclusivamente con Java. O sea, habían usado otros lenguajes pero muy por arriba. Por mi parte, he trabajado mucho con Ruby y C#, un poco menos con Smalltalk y Javascript y muy poco con Java, Python y Php. Estas diferencias de experiencia han hecho que a la hora de plantear soluciones nos encontremos con propuestas bastante distintas. Un ejemplo de esto que me resulta muy chocante, y que es muy común en el mundo Java, es la práctica de separar datos y lógica. Esto lleva a tener clases que son simples contenedores de datos y clases que sólo tienen métodos para manipular datos contenidos en otros objetos, algo bastante anti-POO.

Creo que lo ideal para todo equipo sería contar con programadores “políglotas” pero me parece que no es algo muy común. Mi impresión es que en general las empresas muchas veces apuntan a sacar el mayor provecho de sus “recursos” y eso provoca que “los recursos” se especialicen y “encierren” en una única tecnología. Ojo, no es algo que pase sólo en las empresas, muchos veces quienes trabajan en forma independiente también deciden enfocarse/encerrarse tecnológicamente, ya sea por cuestiones de comodidad y/o rentabilidad.

Dada esta situación y desde el punto de vista de equipo creo que puede resultar interesante contar con un un programador de otro pozo, o sea, integrar en el equipo un programador que tenga experiencia en otros lenguajes/tecnologías pues puede aportar una visión diferente y enriquecer al equipo.

Agiles Argentina 2014, sesiones dia 2

Comparto aquí algunas notas de las sesiones que participé.

Software Craftsmanship

La sesión fue propuesta por Emilio Gutter quien comenzó contando el surgimiento del movimiento de software craftsmanship a partir del cual surgió un pequeño debate sobre el gap entre la formación académica y el ejercicio profesional.

En línea con esto Emilio mencionó un programa apprenticeship que están llevando a cabo en 10 Pines.

Finalmente (no tengo en claro exactamente cómo fue) terminamos hablando sobre lenguajes de programación y la inclemencia de usar C en los primeros cursos de programación.

Sesión 2: Intro XP

A pedido del público esta sesión fue una repetición de la sesión que se había dictado el día anterior, pero en esta ocasión con la participación de más gente.

Sesión 3: Prácticas Pre-Agile

Esta sesión fue un adelanto de la sesión que daremos con @dfontde en Agiles 2014. La idea, como comenté tiempo atrás, es repasar aquellas prácticas, en muchos anteriores a las prácticas ágiles, que han demostrado gran utilidad y que en muchos casos han servido de base para las prácticas ágiles. Me gustó mucho como salió la sesión.

Sesión 4: Facilitación gráfica

Decidí sumarme a esta sesión para aprender de una vez los principios de está técnica que hasta ahora siempre había tocado de oído. La sesión tuvo dos partes, una primera donde se explicó la teoría y una segunda donde la pusimos en práctica. Me vino muy bien ya que además de lo visto en la sesión me traje varios punteros para profundizar entre ellos algunos recursos de Zulma Pataroyo [1][2] una experta del tema.

 

Hasta aquí llegó mi día, lamentablemente tenía otros compromisos y me perdí la última sesión y la retrospectiva.

agiles_arg_dia_2

 

[1] http://facilitaciongrafica.com/
[2] http://pataleta.net/

ChiliProject, my favourite project management tool

About 2 years ago I started working with Tipit guys. My first task was to migrate their project management tool. At that time they were using a tool called Bugnet that was build with C# and they wanted to move to ChiliProject that was built with Ruby. I had experience with both technologies so I was a good candidate to do the job. The migration was successful and after that, we continued working together.

For almost two years I have worked in several Tipit projects and in all of them we have used ChiliProject. In all this time we have also added several new features to ChiliProject and the good news is that all these features are open source and anyone can get them from GitHub.

What I like about ChiliProject is that it provides several features beyond issue tracking, here is a brief list of the most interesting features in my opinion:

  • Ability to define different kind of issues with different fields and workflows
  • Ability to create/update issues by email
  • Ability to connect to source code repository and link commits with issues
  • Discussion Forums
  • Project roadmap definition support
  • Project calendar
  • Wikis
  • File sharing

Beyond these features, ChiliProject is a open source tool, built on Ruby on Rails and very extensible.

El cambio tecnológico más duro de mi carrera

No fue en 2002 cuando pase de hacer sitios web en Php a trabajar con la incipiente (en aquel momento) tecnología .Net.

No fue cuando en 2005 cuando tuve que programar un web server con C++.

No fue en 2009 cuando hice mis primeras experiencias en plataformas Cloud. Ni tampoco cuando pasé de Subversion a Git.

No fue cuando en 2010 cuando me metí con Ruby.

No fue cuando a fines del año pasado volví a trabajar con Php.

Fue en este último mes y medio cuando pasé de trabajar en Ruby a trabajar en Java.

Venía acostumbrado a trabajar desde la terminal con rake, usando Sublime como herramienta de edición de código e Irb como espacio de experimentación. Sinceramente me sentía muy cómo

El pasaje al mundo Java me resultó durísimo. Si bien desde 2004 siempre he estado haciendo algunas cosillas en Java, la realidad es que eran cosas más bien pequeñas o bastante específicas. Pero ahora estoy trabajando en un proyecto de una complejidad bastante mayor en el cual se utilizan diversos frameworks y componentes de infraestructura.

Por un lado el lenguaje me resulta muy incómodo, tipado estático, chequeo de excepciones, ausencia de lambdas (Java7) y una pobre implementación de generics son algunas de las cuestiones que primero vienen a mi mente.

Por otro lado Java es posiblemente de las tecnologías más pesadas que he utilizado (si, incluso más pesado que C# con Visual Studio incluido). Mi maquina (4 GB de memoria y disco de estado sólido) sufre cada vez que intento correr las pruebas de integración o iniciar una sesión de depuración.

El Eclipse si bien es muy potente, es también muy pesado y encima el esquema de shortcuts que utiliza es totalmente distinto al de la mayoría de los otros IDEs.

En fin, aquí estoy, “curtiendome” con el todo el stack enterprise de Java e intentando aportar una mirada más amplia (y “no-java”) al equipo de proyecto.

 

 

Sensaciones y opiniones sobre el próximo Agiles 2014

Este año la Conferencia Latinoamericana de Métodos Ágiles se llevará se realizará en Medellín, Colombia.

Si bien no estoy involucrado en la organización, las noticias que me llegan por el sitio y por foro ágiles me hacen pensar que será un conferencia distinta a las anteriores. En primer lugar los organizadores apuntan un evento bastante más grande que los anteriores. Los años anteriores los eventos anteriores no superaron los 500 asistentes, mientras que este año se apunta a tener unos 600. Este solo hecho tiene un gran impacto diversas cuestiones logísticas. Otro diferencia importante desde el punto de vista de los asistentes es el costo de las entradas que en este momento rozan los 160 dólares y que a partir del 10 de Septiembre superarán los 200 dólares. Hay que destacar que si bien en años anteriores el costo de las entradas era significativamente menor, en ningún caso la entrada incluyó almuerzo. Por otro lado en el sitio del evento encuentro secciones como pauta publicitaria y muestra comercial que me parecen más afines a eventos corporativos que a un evento comunitario.

Todo esto me genera sensaciones contradictorias. Por un lado un evento de 600 personas puede resultar muy enriquecedor desde el punto de vista de la cantidad de gente y la diversidad de experiencias, pero al mismo tiempo el costo de las entradas creo que puede resultar prohibitivo para estudiantes o simplemente demasiado elevado para gente no tan involucrada con la comunidad ágil. Un tema que me genera muchas expectativas es la posibilidad de contar con mayor asistencia de gente de México y países del Caribe, dada su cercanía con Colombia. En fin, son percepciones personales y más allá de ellas espero que el evento sea realmente exitoso.

Y hablando de éxito, creo que en gran medida estará dado por el contenido de las sesiones que se presenten y en ese sentido ya se encuentra abierta la convocatoria para la presentación de sesiones. Tengo ganas de presentar una sesión sobre Test automation, un tema en que vengo trabajando con bastante intensidad desde el año pasado, pero aún no he hecho tiempo de armar la propuesta.

My Agile Assessment

Continuando con la cuestión del post anterior, quiero compartir en este post como suelo manejar el tema ante la consulta: ¿Como puedo medir mi nivel de agilidad?.  La respuesta viene en partes. La primera parte es lo que plantee en el artículo anterior. Luego de eso y asumiendo que llegamos a la conclusión de que lo que buscamos es agregar valor a la organización/negocio y que pretendemos hacerlo siguiendo el marco de referencia agile, podemos pasar entonces a la segunda parte [1].

Yo creo que la adopción de agile es básicamente la adopción ciertos mindsets y prácticas asociadas. Los mindset no son fáciles de incorporar pues son en un punto una cuestión cultural y como tal requieren de cambios profundos en algunos casos y de cierto tiempo de maduración. Por eso es que recomiendo familiarizarse con los mindsets, entenderlos y al mismo tiempo enfocarse en el uso de ciertas prácticas que facilitarán/guiarán la incorporación de los mindsets. Por su parte las prácticas son acciones concretas factibles de ser medidas, mejoradas e incorporadas gradualmente. Para entender proceso de adopción de prácticas suelo utilizar el siguiente cuadro [2]:

practicas_agiles

La división entre prácticas higiénicas y de orden superior está en cierta medida inspirada en la teoría de Maslow. En este sentido es preciso primero incorporar las prácticas higiénicas para luego poder sí avanzar sobre las prácticas de orden superior. La división entre prácticas técnicas y de gestión es bastante obvia pero no hay un orden preestablecido en cuanto su adopción, o sea, existe cierta independencia entre las prácticas técnicas y las de gestión. Ejemplo: uno podría incorporar TDD (práctica técnica) independientemente del uso de retrospectivas (práctica de gestión). Por otro lado resulta imposible la implementación de continuous delivery (práctica de orden superior) sin tener integración contínua (práctica higiénica).

Volviendo al punto inicial, si pretendemos identificar el nivel de adopción ágil, un camino posible sería identificar qué prácticas tiene establecidas el equipo/organización y en base a ello identificar un nivel “de madurez” para cada uno de los cuadrantes [3]. Una posible clasificación de niveles podría consistir en:

  • Pendiente: no se utilizan las prácticas
  • Básico: se utilizan algunas prácticas pero no todas las elegidas
  • Establecido: se hace uso consistente de las prácticas elegidas

 

practicas_madurz

Una vez identificado el nivel actual, debiera de definirse un plan de acción considerando los objetivos perseguidos por la organización, pero esto ya este tema de otro artículo.

 

 

 

 

 

 

[1] Si bien el mindset agile puede aplicarse a distintos contextos, yo me voy a limitar a la construcción de software pues ese es mi campo de trabajo.

[2] La confección de este cuadro puede ser un tema de debate en si mismo. Por ello las prácticas mencionadas en este cuadros son simplemente a modo esquemático, pues faltan muchas prácticas e incluso algunas de las presentes, es debatible si están ubicadas en el cuadrante correcto.

[3] ¡Ojo! no todas las prácticas son requeridas en todos los casos. Esa es una cuestión para analizar en cada caso particular. Es por esto que yo no mediría el nivel de madurez considerando el total de las prácticas sino sólo aquellas que sean relevantes para la organización.

 

Agile Assessment

En más de una ocasión me he encontrado con gente y organizaciones intentando determinar su nivel “de agilidad”.

Cada vez que oigo hablar de esto me asaltan inicialmente una serie de preguntas como ser:

  • ¿Que entiende esta persona por “nivel de agilidad”? o más básico aún ¿qué entiende por agilidad?
  • ¿Cual es el objetivo que se persigue al querer medir el nivel de agilidad?
  • ¿Es realmente la agilidad un fin como para medirlo o es en realidad un medio?

Entiendo que lo que suele denominarse agilidad es un filosofía, un marco de referencia, un sistema compuesto por un conjunto de principios, valores y prácticas estructuradas para alcanzar un fin. Me abstraigo por un momento de la agilidad en particular para reflexionar en forma más general.

Con el fin de alcanzar un objetivo X tomo un marco de referencia Z que me propone un enfoque determinado para llegar a X. Si asumimos como válido que cuánto “más fiel” me mantenga yo al marco de referencia Z  mayor serán mis probabilidades de alcanzar X, entonces tiene sentido comparar mi estado respecto de la propuesta de Z para así poder alinearme con Z y aumentar mi probabilidades de alcanzar el objetivo X.

Llevando esta tesis al caso particular de la agilidad tenemos que la agilidad es un marco de referencia para la entrega de valor a un determinado negocio/organización. En este sentido yo podria medir mi nivel de agilidad para identificar posibles acciones que me acerquen más al marco de referencia y así aumentar el valor que entrego a mi negocio/organización.

Si uno quisiera determinar su nivel de agilidad podria en primera instancia comparar sus principios y forma de trabajo con lo propuesto en el manifiesto ágil. Esto podría resultar un poco abstracto o incluso complejo para alguien poco familiarizado con la agilidad. De ahí la pregunta que dió origen a este artículo ¿existe un assessment para determinar el nivel de agilidad? Hasta donde conozco no existe UN assessment, pero si me consta que hay varias empresas de consultoría que ofrecen entre sus servicios un assessment de tal tipo. Un ejemplo es el ofrecido por Thoughtworks, que pude hacerse gratuitamente en forma online y que a partir de 20 preguntas organizadas en 5 dimensiones, ofrece un reporte con un conjunto de recomendaciones, seguido posiblemente del contacto de un representante de ventas.

Personalmente cuando alguien me pregunta cómo determinar su nivel de agilidad, mi respuesta…..

….la compartiré en otro artículo ;-)

Actualización: segunda parte

Agile no es para todo ni todos (Open Space UY 2014)

Continuando con el relato de este evento, la segunda sesión en la que participé me resultó especialmente interesante. No recuerdo el nombre de la persona que la propuso, pero la idea era analizar algunas situaciones debatiendo cómo enfrentarlas desde los métodos ágiles. Las tres situaciones planteadas fueron:

  1. Cliente ausente
  2. Cambio de prioridades constantemente en un proyecto Scrum
  3. Miembro de equipo mala onda/desmotivado y riesgo de contagio al resto del equipo

(si bien mi descripción es sólo de una línea, en la sesión se dió un poco más de detalle sobre cada una)
Una vez planteadas las situaciones empezamos a hacer una especie de brainstorming sobre posibles estrategias para afrontarlas. Para ponerle un poquito de picante a la sesión, pedí la palabra y sin pelos en la lengua dí “mi dictamen”:

Cliente ausente => no uses métodos ágiles

Agile no es para todo,  Agile no es una bala de plata y tampoco se puede aplicar siempre, hay casos en los que no se puede o no conviene usar agile. Puede que suene muy fuerte pero la experiencia me ha demostrado que para aplicar agile deben darse ciertas condiciones de las cuales tal vez la más importante sea el involucramiento del cliente. Si tu cliente está ausente, seguramente sea mejor utilizar un proceso más tradicional, con especificaciones detalladas, entrevistas formales de relevamiento y documentos firmados. O incluso tal vez sea mejor no hacer el proyecto (si es que esta opción está disponible). Si, suena extremo pero es como suelo manejarme y estoy contento.

Cambio de prioridades contastemente => Kanban

Si trabajas con Scrum y no logras “congelar” los requerimientos del Sprint backlog podrías en primer lugar intentar trabajar con iteraciones más cortas. Si eso no es posible o no funciona, entonces tal vez no debas usar Scrum sino hay más del estilo Kanban.

Miembro de equipo mala onda/desmotivado => agile no es para todos

No tengo una solución para esto, supongo que habría que consultar a un coach “humano”, yo estoy más del lado técnico. Lo que sí tengo en claro es que Agile no es para todo el mundo. Me gusta hacer la analogía entre Agile y la forma de juego del Barcelona. Si tienes un equipo con las características del Barcelona, puedes intentar jugar como el Barcelona y posiblemente obtengas buenos resultados, pero si no tienes un equipo así, tal vez debas buscar otra forma de juego. Con agile pasa lo mismo, si tienes un equipo autoorganizado, motivado y un proyecto agile-friendly, seguramente puedas aplicar agile y obtener buenos resultados, pero si tu equipo no es capaz de autoorganizarse y tu gente no está motivada, entonces tal vez sea mejor probar con otro cosa. Claro, si hablas con un “consultor agile”, difícilmente te diga esto. Al contrario, el “consultor agile” muy probablemente te proponga intentar transformar tu equipo. ¿Es posible tal transformación? Supongo que sí. ¿es fácil? Me parece que no. Pero de algo estoy convencido: si tal transformación es posible, es con el acompañamiento de un coach/consultor ágil.

Más reflexiones sobre docencia universitaria

En 2011 cuando tomé a mi cargo la materia Elementos de Ingeniería de software en UNQ tuve que decidir cómo estructurar las clases de la materia. Por reglamento la materia tenía (y tiene) una carga horaria de 6 horas semanales de clase. Hasta ese momento la materia se dictaba en dos clases semanales, si mal no recuerdo una clase de 2 horas y otra de 4. Luego de una charla con las autoridades mis opciones eran:

  • Mantener un esquema de 2 clases semanales, ya sea de una de 2 y otra de 4 o un esquema más tradicional de 2 clases de 3 horas cada una.
  •  Cambiar a un esquema “maratónico” de una sola clase semanal de 6 horas

Una vez más el dilema: ¿comodidad del docente o “mejor aprendizaje” de los alumnos?  Quien me conoce sabe claramente que elegí la primer opción: dos clases semanales de 3 horas cada una. En parte porque dictar una clase de 6 horas me parece insalubre tanto para los alumnos como para el docente. Por otro lado estoy convencido que el aprendizaje tiene naturalmente una estructura iterativa y en ese sentido el tener más clases permite realizar más iteraciones lo cual representa más ciclos de feedback y por ende más oportunidades de mejora/aprendizaje.

¿y si la materia fuera de 4 horas semanales? Una clase de 4 horas parece bastante razonable. Si, definitivamente es más razonable, pero aún así hubiera elegido dos clases semanales pues el argumento iterativo sigue aplicando en este caso también.