Se viene Agiles Argentina 2014

Viernes y Sábado de la semana próxima (26 y 27 de septiembre) se llevarán a cabo las Primeras Jornadas Nacionales de Metodologías Ágiles.

Si bien el evento se realiza en Buenos Aires, la idea es poder reunir gente de todo el territorio nacional y por ello es que los organizadores han provisto un mecanismo para brindar apoyo a los asistentes de otras ciudades.

Además del hito que representa este evento por ser las primeras Jornadas Nacionales sobre el tema en Argentina, hay algunas otras particularidades que lo destacan: el evento es totalmente gratuito, es 100% en formato Open Space y el catering es auto-organizado. Esto se traduce directamente en las siguientes cuestiones:

  • No hay agenda predefinida de sesiones, la agenda es definida al comienzo del evento por las personas presentes. Esto es lo que propone el formato Open Space y aunque pueda sonar raro, puedo dar fe que funciona de maravilla. He participado en unas 20 reuniones con este formato y todas ellas han salido muy bien. Adicionalmente, para este caso particular, hay un espacio online donde los asistentes pueden ir proponiendo de forma anticipada algunas sesiones que les gustaría ocurrieran.
  • El hecho de que el catering sea auto-organizado, reduce mucho el esfuerzo de organización al mismo tiempo que permite que en cierto modo todos los asistentes contribuyan a la organización. Es este caso la forma en que se está organizando el catering es mediante una planilla online donde cada asistente anota que se compromete a llevar.
  • Aunque el evento es de dos días, no es necesario ir los dos días enteros, uno puede elegir un sólo un día o un rato cada día.

Personalmente estoy muy entusiasmado con el evento, en este momento hay unas 18o registradas.
¡Ah! me olvidaba de decirlo: si bien el evento es gratuito es necesario registrarse.

¡Nos allá allá!

AA2014-Final1

 

 

Conferencistas de ASSE 2014

Las presentaciones de los conferencista de ASSE 2014 fueron de las mejores cosas del simposio.

El primer conferencista fue Esteban Feuerstein quien dio una charla introductoria sobre Big Data en la que mencionó las diversas iniciativas de la Fundación Sadosky y el Estado Nacional para impulsar esta temática. Entre estas iniciativas se cuentan diversas oportunidades para formación de profesionales en instituciones nacionales y del exterior.

El segundo conferencista fue Juan Gabardini quien habló sobre Testing en equipos Infectados de Tests. Si bien tengo trato frecuente con Juan e incluso hemos hablado sobre el tema testing en diversas ocasiones, me gustó mucho su presentación. Creo que ha logrado articular de manera muy sólida y consistente varias de las ideas que ha validado en su trabajo de campo.

El tercer conferencista fue Alvaro Ruiz de Mendarozqueta quien hizo una excelente presentación sobre Mejora continua utilizando métodos ágiles. La presentación incluyó interesantes datos estadísticos sobre la industria local del software y las certificaciones de calidad. Luego de presentar el contexto utilizando como base las mencionadas estadísticas, presentó algunos casos de mejora continua en los que trabajó aplicando métodos ágiles.

Los slides utilizados en estas presentaciones están disponibles para descarga aquí.

Libro en mano

El miércoles pasado nos entregaron los primeros ejemplares del libro.

fotos_libro

Esta semana terminaremos de ajustar algunos detalles formales con la editorial y esperamos que a más tardar el sábado próximo el libro se encuentre disponible para el público en librerías de la Ciudad de Buenos Aires.
También está en nuestros planes contar con un medio global de distribución, pero eso llevará un poco más de tiempo.

Desarrollador y facilitador, no way

Como ya comenté en un artículo anterior, desde hace un tiempo estoy trabajando en un proyecto Java, una tecnología que no domino plenamente.

El miércoles pasado participé de una retrospectiva de este proyecto que fue facilitada por Alan y que me dejó pensando un buen rato. Ocurre que durante la retrospectiva Alan hizo dos sugerencias puntuales que yo mismo he hecho a otros equipos en reiteradas ocasiones pero que curiosamente esta vez no las sugerí a mi propio equipo.

Todo el viaje de vuelta a casa me lo pasé analizando esta cuestión y finalmente llegué a una conclusión que me convenció: mi falta de pleno dominio de Java me obliga a poner demasiada energía en cuestiones técnicas, lo que me hace perder de vista algunas otras cuestiones.

Luego de pensarlo por un par de días y de consultarlo con algunos amigos me animo a arriesgar:

Para que un desarrollador pueda ocupar el rol de facilitador en su equipo es necesario que tenga un buen dominio de las cuestiones técnicas con las que debe trabajar cotidianamente.

(posiblemente esta afirmación no tenga aplicación universal, pero definitivamente aplica a mi)

Se viene el libro….

Hace un par de días entró en imprenta el libro de ingeniería de software que empecé a escribir hace unos dos años junto a un grupo de colegas de la Fiuba.

La idea era escribir un libro sobre métodos ágiles, luego de un par de charlas refinamos el objetivo y decidimos escribir un libro sobre métodos ágiles que cubriera el proceso completo de desarrollo de software.

Una de las motivaciones para escribir el libro fue que no existen en la actualidad (o al menos no han tenido mayor difusión) libros escritos en castellano sobre métodos ágiles que cubran el proceso de completo de desarrollo de software. Los libros existentes sobre esta temática escritos en castellano están enfocados en algún aspecto particular. Por ejemplo los libros de Martín Alaimo tienen un foco humano/de gestión, mientras que el libro de Carlos Blé está enfocado en TDD. Existe un libro que cubre en gran medida el proceso completo de desarrollo software llamado Scrum y XP desde las trincheras, pero es una traducción de una obra originalmente en inglés.

Al mismo tiempo, la motivación va más allá del idioma. Los métodos ágiles ponen un foco importante en las personas y en ese sentido creemos que la idiosincrasia latinoamericana merece un libro a medida escrito por latinoamericanos.

El libro, más allá de lo que el título pueda sugerir, es un libro de ingeniería de software. De hecho la mayoría de los contenidos son parte de la materia que dictamos con @pablitosuarez en UNQ.

Todos los autores somos docentes y también trabajamos en la industria, por ello creemos que el libro puede resultar muy útil como libro de texto para el dictado de una materia y para profesionales de la industria con intenciones de conocer y experimentar con métodos ágiles.

En los próximos días compartiré algunos detalles y curiosidades del libro, por el momento les dejo una de las imágenes del libro que más me gusta.

15.1

Desarrollo de software sin “métodos ágiles”

Algo que me ha llamado poderosamente la atención en los últimos años es encontrarme con gente que trabaja utilizando métodos ágiles y que sólo conoce de métodos ágiles. Cuando uno les pregunta como trabajaban antes de comenzar a utilizar métodos ágiles, en la mayoría de los casos indican que trabajaban totalmente ad-hoc o que utilizaban un proceso tipo cascada. Esto podría explicar en gran medida porque muchas veces se hace la comparación Agile Vs. Cascada como si no existiera nada más: hay gente no conoce nada más.

Pero existe algo más, de hecho existen muchas cosas más que son utilizadas con éxito en diversos contextos. Entre esas cosas uno podria citar el Proceso Unificado y el PSP por nombrar algunas. Al mismo tiempo hay una serie de prácticas muy asociadas a agile, pero que datan de mucho antes como ser versionamiento de código y la automatización de pruebas.

En relación a esta cuestión, con @dfontde, hemos enviado una propuesta de sesión a Agiles 2014 titulada “Hay buen desarrollo sin agilidad“.

Real-world TDD

El viernes pasado me tocó trabajar en una funcionalidad relativamente simple. Dada una aplicación de gestión de proyectos que tiene la capacidad de recibir mails (chiliproject) me pidieron que le agregue la capacidad de rutear los mails de entrada a uno u otro proyecto dependiendo de cierto algoritmo. Cuando estaba por empezar a desarrollarla pensé: “este es un excelente ejemplo para mostrar el uso de TDD en un contexto real”. Entonces abrí mi software de grabación y me puse trabajar. El resultado es este video que muestra cómo resolví parte del problema usando TDD. Espero lo disfruten.

Automatización de pruebas: principios, prácticas y herramientas

Finalmente, me hice un rato y mandé mi propuesta de sesión sobre este tema a Agiles 2014. Para quienes gusten darme feedback, pueden ver la propuesta completa en el sistema de call for papers de la conferencia.

Una cuestión que no está mencionada en la propuesta es qué fue lo que me llevó a proponer una sesión sobre este tema.

Como programador y sobre todo desde que me metí en el mundo Smalltalk, las pruebas unitarias automatizadas se volvieron un artefacto imprescindible en mi trabajo. Al ser Smalltalk un lenguaje de tipado dinámico no contaba con la (falsa) seguridad que proveen los compiladores en los lenguajes de tipado estático. Por esto me sentía obligado a escribir pruebas unitarias automatizadas para tener cierto nivel de seguridad de que no estaba rompiendo mi proyecto. Tiempo más tarde cuando comencé a trabajar en la implementación de la práctica de continuous delivery tomé conciencia de que con automatizar las pruebas unitarias y de componentes no era suficiente. Fue en ese momento que comencé a meterme gradualmente en las cuestiones de automatización de pruebas de aceptación de usuario. En ese sentido trabajé con Juan Gabardini en preparar un curso de automatización de pruebas y tiempo después comencé a trabajar con Pablo Tobia (alto tester) en el armado de una materia de testing que finalmente materializamos en el curso que dictamos en FIUBA. Al mismo tiempo para ganar más experiencia de campo logré meterme a trabajar como Software Engineer in Test en un proyecto de automatización de pruebas de un sistema de facturación. Todo esto me ayudó a ganar experiencia e incorporar muchísimo conocimiento sobre esta temática.

Como de costumbre, si la sesión es aceptada en Ágiles 2014, intentaré hacer una prueba previa en uno de los encuentros de la comunidad ágile@BsAs, mm, en realidad creo que la prueba lo voy a hacer igual más allá de que sesión sea aceptada en Agiles 2014 o no.

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.