Cierre de cuatrimestre en Algo3

Este cuatrimestre afrontamos algunos nuevos desafíos, a partir de ciertos cambios en el equipo docente.

Uno de los cambios fue el horario de dictado de la materia. Las clases  teóricas pasaron a la tarde (16 hs) y lo mismo hicimos con el curso de los miércoles. Posiblemente por influencia de este cambio tuvimos una interesante variación en la cantidad de alumnos de los diferentes cursos de práctica. Generalmente el curso de los miércoles (que solía dictarse a las 19 hs) era el que menos alumnos tenía (~20), sin embargo este cuatrimestre movimos el curso a las 16 hs y tuvimos ~ 55 alumnos.

Otro de los cambios que hicimos fue en las clases teóricas, donde Carlos decidió experimentar un poco más en profundidad con algunas técnicas de educación centrada en el alumno. Creemos que eso ayudó a mejorar las clases pues recibimos comentarios positivos de los alumnos al respecto.

En las prácticas de los miércoles generalizamos una estrategia que yo venía utilizando desde hace un tiempo: guiar el desarrollo del trabajo práctico final con escenarios de prueba. El trabajo práctico final se hace con lenguaje Java, trabajando en grupo junto a un docente tutor y dura unas 5 semanas en las que se espera que los alumnos trabajen de forma continua demostrando avance semanal.

leyen

El TP final de este cuatrimestre fue un juego del tipo Carmen San Diego

En una época solíamos pedirle a los alumnos que las primeras semanas se concentrarán en el diseño haciendo diagramas UML y luego de tener un modelo del dominio base, recién entonces pasaran al código. Con el correr del tiempo eso ha ido cambiando. Ya desde el año pasado comencé a guiar a mis grupos especificando semana a semana un conjunto de casos de prueba a resolver de manera que funcionaran como “pruebas de aceptación” y que los guiaran en la implementación incremental de la aplicación.

Otra práctica que hemos establecido por completo en el curso de los miércoles es el uso de Jenkins como servidor de integración continua para el desarrollo de los trabajos finales. El uso de Jenkins en conjunto con Ant y algunas otras herramientas más, nos permitieron obtener ciertas métricas sobre el código de los alumnos al mismo tiempo que les facilitó la integración del trabajo a cada equipo.

Mé

Métricas de un trabajo final

Al terminar el cuatrimestre, además de la clásica retrospectiva hicimos una encuesta online anónima para obtener algunos números concretos de manera de poder medir la mejora de un cuatrimes a otro. Entre el feedback que recogimos destaco los siguientes puntos:

  • (a mejorar) Que las correcciones del TP1 sean entregadas antes de rendir el primer parcial
  • (a mejorar) Actualizar el template del proyecto ant para incluir la ejecución de la aplicación
  • (mantener) Clases participativas y juegos de rol
  • (mantener) Videos complementarios de explicación sobre las herramientas
  • (mantener) Jenkins

 

retro-algo3

Post-its de la retro

 

Clasificación de herramientas para automatizar pruebas de funcionales

Las pruebas funcionales son las que típicamente hace un tester, que más le importa al usuario y sería ideal definir en conjunto con él, pues estas pruebas interactúan con el SUT desde la perspectiva del usuario. Son pruebas que Marrick clasifica como Business Facing.

Para este tipo de pruebas es muy relevante la forma en que las herramientas permiten expresar la prueba, ya que dado que son “pruebas de usuario”, dependiendo de la forma en este planteado el proyecto podríamos querer que estas pruebas sean escritas por el usuario.
En este sentido es que las herramientas para automatizar este tipo de pruebas han adoptado distintos enfoques:

  • Record and Play: permiten “grabar” la interacción del usuario con el SUT para luego reproducirlo. Con este tipo de herramienta, básicamente se ejecuta manualmente 1 una vez cada caso de prueba mientras la herramienta va grabando la interacción de manera que la misma y una completada la grabación las pruebas pueden repetirse tantas veces como se guste de forma automática. Un ejemplo de este tipo de herramientas es SeleniumIDE.
  • Keywork-Driven: este tipo de herramientas permiten definir las pruebas utilizando un conjunto de palabras claves par estructurar la prueba. Luego es necesario escribir cierto código (glue code) para vincular la prueba (expresada con palabras claves específicas) y el SUT. En esta categoría de herramientas entra toda la familia de Cucumber.
  • Data-Driven: este tipo de herramientas permiten especificar la prueba a partir de condiciones expresadas en tablas. Cada tabla es interpretada por por cierto código (glue code) que permite la interacción con el SUT. Las herramientas de la familia Fitnesse entran en este grupo.

Si bien muchas veces las herramientas pueden utilizarse de diversas formas, en general suelen ser concebidas para ser utilizadas de una forma particular (una silla es concebida para sentarse, sin embargo en ocasiones es posible utilizarla para elevar nuestra altura como si fuera una escalera). En este sentido cada herramienta puede verse más orientada con alguno de los grupos mencionados, pero ello no quita que la podamos usar de forma distinta.

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.

Nuevo proyecto, full Java

Esta semana comencé a trabajar en un nuevo proyecto que va a requerir que me meta con Java en profundidad. El proyecto consiste en el desarrollo de lo que podríamos denominar un Middleware, básicamente una aplicación que permite integrar aplicaciones.

Equipo de 3 personas, iteraciones de 2 semanas, Jira, Slack, Git, Jenkins, Maven, Spring, Camel, Eclipse, JUnit, Mockito y algunas otras cosillas.

Continuará…

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.

Curso: Aprendiendo a programar con Python

Durante el segundo cuatrimestre de este año voy estar dictando este curso de introducción a la programación. El mismo surge de una iniciativa conjunta del FIUBA y el programa EmplearTec.

Tanto la currícula como en enfoque de enseñanza del curso están basados en el curso de Algoritmos y Programación 1 (FIUBA) de Rosita Wachenchauzer, del cual fui parte hace algunos años. Esto implica que quienes tomen el curso deberán asistir a dos clases semanales de 3 horas cada una y deberán dedicar otras tantas horas para estudio extra clase.

Los interesados pueden encontrar más información y detalles de la inscripción en la página de FIUBA.

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

Reportes en Jenkins

Si bien últimamente vengo trabajando muy felizmente con Travis, una de las funcionalidades que extraño mucho son los reportes. Cuando trabajo con Jenkins suelo hacer que mis jobs de CI muestren diversos reportes.

Hay dos estrategias para mostrar reportes en Jenkins:

  1. Utilizar las capacidades de reporting de Jenkins, ya sea nativas o con plugins, o bien
  2. Hacer que cada herramienta que forma parte del build genere sus propios reportes y luego simplemente hacer que Jenkins provea acceso a dichos reportes.

Un ejemplo del primer caso es el plugin de Cucumber-jvm que genera un reporte como el de la figura 1.

cucumber_jenkins

Figura 1

Un ejemplo similar pero usando la segunda estrategia sería ejecutar cucumber especificando que genere output HTML y luego usar el plugin Sidebar link de Jenkins para linkear el reporte generado por cucumber. En figura 2 se ve un caso de esta estrategia donde Jenkins provee links un reporte de features generado por cucumber y otro de coverage generado por SimpleCov. La figura 3 muestra cómo configurar los links a los reportes una vez instalado el plugin.

reportes_jenkins

Figura 2

 

sidebar_links

Figura 3

 

Taller (experimental) de Testing

Hace varios de meses comenzamos a trabajar con mi colega Pablo Tobia en el armado de la un materia de Testing. Leímos, experimentamos, debatimos, hablamos con otros colegas y finalmente decidimos pasar a la acción: vamos a dictar un Taller de testing. El objetivo central de este taller es obtener feedback de lo que hemos armado para poder refinarlo de cara a presentarlo formalmente como una materia. A continuación comparto un poco más de información en forma de “Preguntas frecuentes” para los posibles interesados.

¿Qué duración tiene? Son 4 clases de 3 horas cada una. Adicionalmente al tiempo de clase se espera que los alumnos dediquen cierto tiempo (entre 1 y 2 horas semanales) a la realización de algunas prácticas.

¿Qué costo tiene el curso? Ninguno, es gratuito aunque posiblemente le pidamos a los alumnos algún tipo de contraprestación como por ejemplo traer alimentos para donar a un comedor comunitario o algo por el estilo.

¿Cuando se dicta? Aún no lo tenemos del todo definido pero la idea es hacerlo durante Julio aprovechando que no hay clases. Seguramente sea un día por semana a partir de las 18 o 19 horas.

¿Da créditos para la carrera? No, el taller es absolutamente extra-curricular.

¿Qué conocimiento previo necesito? El taller es muy práctico y está orientado a la automatización, con lo cual se espera que todo alumno pueda programar. En principio trabajaremos con Java y Ruby. Si no sabes de ninguno de estos lenguajes y crees que puedes darte maña para aprenderlos, no hay problema, pero nosotros no vamos a explicar Java ni Ruby. Al mismo tiempo, son necesarios cierto conocimiento de aplicaciones web (http, html, etc) y de metodologías de desarrollo de software.

¿Cuál es el temario del curso? En forma resumida podemos decir que veremos algunas cuestiones conceptuales, varias cuestiones de índole práctica y diversas herramientas como ser Cucumber, Fit, Watir, RSpec, JUnit, CasperJS y Selenium.

¿Cómo me anoto? Si estas interesado participar, te pedimos que completes este formulario.