Categoría: agile

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.

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.

Open Space UY 2014

Ayer estuve participando de un Open Space organizado por la comunidad ágil de Uruguay. El mismo se llevó a cabo en las instalaciones de la Universidad Católica de Uruguay.

La logística fue impecable, las instalaciones de la universidad resultaron muy adecuadas y el evento contó con varios sponsors lo que permitió contar con almuerzo y coffe breaks a pesar de tratarse de un evento gratuito.

Luego de unas palabras iniciales de Ariel (@scrumjedi), la facilitación del marketplace estuvo a cargo de @pablolis y el facilitación del cierre estuvo a cargo Martín Mari.

No tengo el número exacto de sesiones, pero había 4 slots horarios y unas cinco salas, por lo que estimo que debe haber habido unas 20 sesiones.

Gracias AgileUY, fue un gran evento y lo disfruté muchísimo.

PD: en los próximos días voy estar posteando sobre las sesiones en las que participé.

 

MiriadaX: cursos online gratuitos en castellano

Reciente descubrí MiriadaX, una plataforma al estilo Coursera, pero que agrupa Universidad de España. Cuenta con una gran cantidad de cursos de diversos temas que varian desde Economia y Finanzas hasta Turismo y Salud pasando por Informática e Innovación.

Para hacer una prueba de esta plataforma y aprovechando que ya estoy por terminar el curso de Android decidí anotarme en un curso de agilidad llamado Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI El mismo tiene una duración de 1 mes y una carga estimada de trabajo de 5o horas.

En un mes les cuento que tal el curso y la plataforma.

Continuous Delivery en Olx

Hace aproximadamente un año comencé a trabajar en un proyecto de implementación de continuous delivery en Olx. Mi rol dentro de dicho proyecto era el de facilitador colaborando principalmente con Diego Garber, release manager de Olx y product owner del proyecto.

Cuando digo facilitador lo digo en un sentido muy amplio, ya que mis tareas incluian un poco de gestión, un poco de diseño, capacitación, configuración/troubleshooting de Jenkins y hasta programación en Php. Básicamente ayudaba a que cada involucrado cumpliera con sus tareas, lo cual podía incluso implicar que en ciertas ocasiones me encargara yo mismo de la ejecución de dichas tareas, ya fueran configurar un repositorio GitHub o escribir algo de código.

releases

En estos días estamos cerrando el proyecto y me complace el hecho de que no sólo hemos cumplido con la mayoría de los objetivos inicialmente planteados, sino que aún más importante, hemos agregado valor a la organización permitiendo que el área de tecnología pueda dar respuestas más rápidas a las necesidades del negocio, acortando el ciclo de feedback y potenciando el retorno de la inversión.

En las próximas semanas iré compartiendo algunos datos más de esto, por el momento termino este artículo con un gráfico que muestra la evolución de la cantidad de releases desde que arrancamos el proyecto. En el  mismo se puede apreciar que se pasó de 60 releases mensuales en marzo de 2013 a 180 en enero de 2014.

Sobre la terminologia ágil y sus traducciones

Muchos de los términos del ámbito de la informática tienen su origen en habla inglesa. A lo largo de los años diversos términos han sido traducidos al castellano y en mayor o menor medida las traducciones han sido adoptadas por la comunidad hispano-parlante.

En particular dentro del mundo ágil también nos encontramos con muchos término con origen en lengua inglesa, pero que tal vez por ser de más reciente aparición, aún no tienen traducciones consolidadas en castellano.

La traducción de estos términos fue uno de los desafíos que enfrentamos al escribir el libro sobre desarrollo ágil. Desde un principio decidimos intentar traducir todo lo que fuera posible y razonable. Finalmente la estrategia fue:

  • En el caso de términos con una traducción ampliamente aceptada por la comunidad y a nuestro entender apropiada, hemos utilizado dicha traducción.
  • En el caso de términos con diversas traducciones razonables, optamos por elegir aquellas que a nuestro criterio resultaban más apropiadas.
  • En el caso de términos sin traducciones razonables, optamos por no traducir.

Un caso interesante es el término User Story, muchas veces traducido como Historia de usuario. A nuestro entender dicha traducción no es del todo correcta. El término historia en castellano hace referencia justamente a la historia como sucesión de hechos pasados, lo que en inglés es history. El término inglés story, sería en castellano algo así como cuento. Es por esto que decidimos utilizar directamente el término inglés.

Entre los términos que no tradujimos están: spike, coach, slack y build.

Libro en castellano sobre desarrollo ágil

Hace aproximadamente año y medio me embarqué junto a otros 5 colegas de la UBA en el proyecto de escribir un libro sobre desarrollo ágil.  Si, en total 6 autores lo cual ya de por si sólo significó un gran desafío. La idea no era hacer una compilación de escritos independientes, sino una obra integrada en la que todos los autores fuéramos responsables por la totalidad del libro y no sólo por las partes que escribió cada uno.

La semana pasada finalmente entregamos el manuscrito a la editorial. Aún nos queda un buen camino por recorrer, la parte más trabajosa (al menos para los autores) parece haber quedado atrás.

Entre las cosas que nos quedan por hacer, está la definición del título del libró, una cuestión no menor.

Continuará…