Categoría: agile

¡Que lindo es ser Product owner en estas condiciones!

Como ya he comentado, he estado trabajando con un par de alumnos de FIUBA en la construcción de un sistema de corrección de trabajos prácticos. A lo largo del proyecto he ocupado diversos roles: director, consultor, tester, etc, pero sin duda el que más tiempo he ocupado y que más he disfrutado es el rol de Product Owner.

Es la primera vez que ocupo este rol y ¡que linda experiencia me ha resultado! Creo que en gran medida esta satisfacción se debe a que el equipo (los alumnos en este caso) han sabido contentarme, no solo construyendo un producto que satisface mis necesidades, sino que también han logrado que el trabajo sea fácil de llevar. ¿De qué estoy hablando? De cosas en un punto simples u obvias pero que no siempre se dan. Puntualmente, han entregado un producto de valor, han sabido adaptarse a los cambios pedidos, me han dado visibilidad completa y contínua del estado y el avance del proyecto y en líneas general han facilitado mucho mi trabajo como product owner.

Agile no funciona con equipos grandes

Simplemente porque no existen equipos grandes. Seamos realista, 50 personas trabajando en un en una sala no son un equipo, son simplemente un amontonamiento de gente. Un equipo es mucho más que un amontonamiento de gente, basta con mirar los equipos deportivos, donde la mayoría no supera los 10 integrantes.

¿Esto implica que no pueden hacerse proyectos grandes? De ninguna manera, si un proyecto por la cuestión que sea require de 50 programadores, entonces simplemente habrá que particionar el proyecto de manera que puede ser desarrollado por 10 equipo de 5 integrantes cada uno.

Inclusión de métodos ágiles en las carreras de informática

En este post quiero tratar un tema que estuve trabajando la semana pasada en los talleres que participé en Medellín.
Según mi visión, a la hora de diseñar una carrera de informática existen distintas alternativas para incluir los métodos ágiles. En una simplificación extrema podriamos hablar de un enfoque conservador y otro innovador.

El enfoque conservador podria consistir simplemente en agregar una materia sobre métodos ágiles (posiblemente hacia el final de la carrera) y mantener el resto del plan sin mayores modificaciones.

Por otro lado, el enfoque innovador sería repensar la carrera completa incluyendo temas de agilismo en diversas materias. De esta forma se podría incluir Scrum en la materia de gestión de proyectos, TDD en las materias de diseño/programación, BDD y User Stories en las materias de análisis/requerimientos y así sucesivamente.

Si bien el enfoque innovador puede parecer más difícil de implementar, la realidad es que no siempre es así. Un claro ejemplo es lo que ocurre en FIUBA. Si bien los planes de estudio actuales no hacen referencia explícita a métodos ágiles, varios profesores han incluido temas de métodos ágiles en sus respectivas materias por iniciativa propia. Claro está, que esto es pura informalidad ya que la inclusión de los temas está sujeta por completo a la iniciativa de cada docente. Pero también es cierto que es una implementación «rápida», ya que no require de todo el trámite burocrático que puede implicar el modificar un plan de estudios. En FIUBA los temas de agilismo se empezaron a dictar hace ya más de 6 años por iniciativa de algunos docentes. Hoy por hoy, más docentes se han sumado a esta iniciativa y los nuevos planes de estudio (que están en proceso de aprobación) ya incluyen formalmente estos temas que en la realidad se vienen dictando hace varios años.

Cómo hacer pruebas automáticas sin xUnit

Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.

Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.

  • Arrange: es la preparación de todo lo necesario para realizar la prueba
  • Act: es la ejecutación de la prueba
  • Assert: es verificación de que el resultado obtenido es acorde a lo esperado

De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente

public void verificar(boolean expresion){
  if(!expresion)
    throw new RuntimeException();
}

Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.

public void deberiaCrearseVacio(){
  // arrange & act
  ArrayList array = new ArrayList();
  // assert
  verificar(array.size()==0);
}

Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.

Agilizando Medellín

Por estos dias me encuentro en Medellín dictando un par de talleres sobre adopción de métodos ágiles en la academia. Esta actividad es una iniciativa de Ruta N, un organismo creado conjuntamente por la alcaldía de Medellín y otras organizaciones (tanto del sector público como privado) para promover el desarrollo de negocios innovadores basados en tecnología.

Esta iniciativa tiene como objetivo promover/facilitar la inclusión de los métodos ágiles en los planes de estudio de las carreras de informática. De la iniciativa estan participando 6 universidades entre las que se encuentran la Universidad Nacional de Colombia, la Universidad de Medellín y el Politécnico Colombiano.

Continuará…

Sistema de gestión de trabajos prácticos

A mediados del año pasado se me acercaron dos alumnos de FIUBA, con la intención de que los dirigieran en el desarrrollo de su trabajo profesional de fin de carrera. La propuesta que traían no me convenció, pero en lugar de decirles que no, les hice una contra oferta y trabajar en una idea que tenia en mente desde hace un tiempo: una herramienta de gestión para de trabajos prácticos de programación. La idea no era del todo novedosa, pues ya había en nuestra misma facultad dos materias que ya tenian un sistema similar. Al mismo tiempo, puse una seria de condiciones respecto del producto final y de la forma de trabajo:

En cuanto al producto, pedí las siguientes cuestiones

  • Pruebas unitarias y de aceptación automatizadas
  • Alto porcentaje de cobertura
  • Cumplimiento de las convenciones de código del lenguaje utilizado
  • Implementación con tecnologias abiertas

Respecto de la forma de trabajo les pedí:

  • Enfoque iterativo incremental con iteraciones semanales
  • Proceso de trabajo tipo Scrum
  • Visibilidad contínua

Con buen criterio los muchachos se tomaron un par de dias para pensarlo y finalmente aceptaron.

Hoy al cabo de 21 iteraciones, estamos a punto de salir en producción. Estamos arrancando el cuatrimestre y vamos a utilizar el sistema para gestionar los dos primeros trabajos prácticos de este cuatrimestre.

En próximos post compartiré más detalles del proyecto.

Agile en la academia, mi experiencia

En este tema tenemos dos cuestiones:

  1. La aplicación de técnicas agile en la enseñanza (más allá de cual sea la materia de estudio)
  2. La enseñanza de agile como un enfoque de la ingeniería de software.

En mi caso tengo experiencia en ambas cuestiones.

En Algoritmos y Programación 3 (Universidad de Buenos Aires) nuestro foco de estudio es la programación orientada a objetos pero incluimos en el programa de la materia algunas prácticas comunes en el movimiento agile como ser TDD e integración contínua. Esto se debe a que en la actualidad no concebimos la construcción de software orientado a objetos sin el uso de estas prácticas.

Por otro lado, en Elementos de Ingeniería de Software (Universidad Nacional de Quilmes) el enfoque de ingeniería que enseñamos es el enfoque Agile. Es necesario mencionar que el objetivo de esta materia es proveer, a un técnico en programación, herramientas suficientes para llevar adelante el desarrollo de un sistema de software. La discusión de porqué el enfoque Agile y no otros, es tema de otro post. Al mismo tiempo la forma en que se dicta la materia tiene varias técnicas de agiles como ser:

  • La materia se encuentra dividida en iteraciones, al final de cada una los alumnos presentan un entregable y se realiza un retrospectiva sobre la forma en que se ha dictado la materia
  • El entregable puede ser un informe, software, un documento de diseño o una evaluación
  • Los alumnos se auto organizan para llevar adelante las distintas asignaciones
  • Cada alumno lleva un backlog de sus tareas, que es priorizado por el docente y estimado por cada alumno
  • Si al final de la iteración el entregable de un alumno no cumple con el criterio de done previamente acordado, entonces el docente puede decidir:
    • «cancelar el proyecto», lo que básicamente significa que el alumno ha pedido la materia)
    • agregar al backlog items distintos o adicionales para compensar/suplir el entregable incompleto

Asimismo hay dos cuestiones que nos parecen centrales más allá del enfoque agile:

  • Los proyectos de software se desarrollan dia a dia y eso mismo hacemos en la materia. Hay que trabajar todas las semanas. Esto resulta en ocasiones «chocante» para los alumnos que muchas veces están acostumbrados a simplemente asistir a clase y sólo trabajar/estudiar la semana previa a un exámen. 
  • Un factor importante para el éxito de cualquier proyecto es la comunicación y el manejo de expectativas. Durante toda la materia hacemos mucho incapié en esto. Por eso, si un alumno piensa no asistir a una clase, tiene la obligación de avisar previamente al resto de la clase. No hace falta que dé explicaciones, simplemente decir «No asistiré a clase». Esto permite que el docente puede planificar mejor las actividades de la clase sabiendo con cuantos alumnos contará.

Aqui dejo algunos links a posts anteriores que agregan más información sobre lo mencionado aquí:

Nota: este post surgió a partir de una consulta de mi colega Juan Gabardini quien me mencionó una iniciativa de gobierno de Medellín para la enseñanza de método ágiles en las universidades. Gracias Juan.

Proyecto CMS, flujo diario de trabajo

Alrededor de las 8 de la mañana, enciendo la máquina, inicio sesión y lo primero que hago es ver las novedades, pues dado que tenemos un equipo en India que trabaja a contrahorario es muy común iniciar el día con noticias de progreso. Entonces abro el cliente de correo y un navegador para loguearme en Campfire, la herramienta de chat colectivo. La ventana de Campfire queda abierta todo el dia. Voy leyendo los correos del proyecto, si es que hay alguno y voy contestando.

Una vez al tanto de las novedades, abro una terminal y actualizo mi repositorio local: git pull. Abro otra ventana del navegador para ver que todo esté en orden en el build server (Jenkins). En otra ventana del explorador abro la herramienta de gestión (Chili).

Con esto ya estoy listo para empezar a codear, inicio Rubymine y manos a la obra.

A las 10 de la mañana, inicio sesión en Vydeo para conectarme a la stand up global del proyecto, la cual dura entre 10 y 15 minutos. Luego  inicio GoToMeeting para hablar  con mi sub-equipo, esta reunión suele durar un poco más pues hablamos algunas cuestiones de diseño o hacemos troubleshooting de algún impedimento. Al finalizar esta reunión, ya tengo en claro el trabajo de mi dia, asi que envio un mail a la lista de proyecto contando brevemente mis compromisos.

El resto del día transcurre como una seguidilla de Pomodoros interrumpida solamente por 40 minutos para el almuerzo. Dependiendo de las funcionalidades en desarrollo, puede que hagamos una sesión de pair programming usando Google Hangout. Las funcionalidades en general las desarrollo haciendo TDD. Cada vez que termino una funcionalidad, corro todas las pruebas unitarias (que son alrededor de 1500) y si todo está bien, subo el código al repositorio común lo cual dispara el proceso de integración. Si la integración es exitosa, entonces disparo un despligue a al ambiente de preview para que quien guste pueda ver la nueva funcionalidad agregada. Finalmente actualizo el estado de la funcionalidad en la herramienta de gestión.

Si la funcionalidad desarrollada requirió algún cambio de impacto relevante en el resto de la aplicación (un cambio en la base de datos por ejemplo) envio un mail a la lista de proyecto avisando de esto y si corresponde también documento el tema en la wiki del proyecto.

Al final del día, envio un mail a la lista de proyecto resumiendo el estado de los compromisos asumidos para el día y comentando también mis siguientes pasos.

Proyecto CMS, día #17 – Fin

Era el gran día: la salida en producción, pero no fué. El producto está listo, ha pasado las pruebas, pero el cliente ha decido posponer la salida en producción por cuestiones de negocio.

De forma simplificada podemos decir que el sistema construido reemplaza a un sistema existente y que en este momento el negocio está cerrando un ciclo. El cliente ha considerado conveniente que el ciclo de negocio actual se complete con el sistema «viejo» y recien poner en funcionamiento el sistema nuevo al finalizar el ciclo. Dado que el ciclo de negocio termina la semana próxima, el aplazo de la salida en producción no debiera ser mayor a una semana.

Más allá de esto, mañana haremos el cierre formal del release.

Dado que estamos cerrando una etapa, es un momento apropiado para hacer un retrospectiva, pero resulta un contexto un tanto complejo dada la distribución del equipo. Asi que siguiendo la recomendación de @jgabardini, he propuesto que cada sub-equipo haga su propia retrospectiva y luego compartamos los resultados y coordinemos los action items.

De ahora en más ya no escribiré los avances diarios, sino sólo los hechos relevantes como la salida en producción, los resultados de la retrospectiva, etc.

Espero hayan disfrutado de este relato de un proyecto real. Fin.

Webcast AgilVen: Interesante experiencia

Como habia mencionado anteriormente, ayer hicimos un webcast con la comunidad ágil de Venezuela (agilven). Entre los moderadores estuvimos RickC, yo y los locales GustavoB y PabloLis.

La experiencia me resulto muy interesante. La dinámica fue simple: previo al evento habilitamos un espacio para preguntas (basado en google moderator) y luego durante el evento fuimos respondiente dichas preguntas. Al mismo tiempo la audiencia podia postear más preguntas vía Twitter utilizando el #agilven. Hablamos sobre TDD, CI, relaciones con los clientes, motivación y restrospectivas entre otros.

Un detalle no menor, es que el webcast lo hicimos con Google Hangout + Streamming via YouTuve, lo permitió que toda la sesión quedara publicada y disponible para todo el mundo: http://www.youtube.com/embed/Hzq9-B1jBuU.

Fue mi primera vez en una experiencia de este tipo y me gustó tanto que ya hablamos con Rick de repetirla periódicamente con distintas comunidades.