Categoría: agile

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á…

Historia de Ágiles Argentina

Si tuviera que definir un hito punto de inicio de la comunidad ágil de Argentina, sin duda diría que ese hito fue la Conferencia Latinoamericana de Métodos Ágiles, Agiles 2008. Luego de ese evento, comenzamos con las reuniones mensuales de la comunidad ágil de Buenos Aires.

Recuerdo que la primer reunión estuvo dedicada a debatir sobre lo discutido en el panel de cierre de Agiles 2008 en el que habían participado los Poppendieck y Tobias Mayer entre otros. También recuerdo que no pude asistí a ese encuentro :-(.

Ya en 2009, empezamos con eventos en formato Open Space. El primero fue el Agile Open Buenos Aires 2009. Para mi el evento fue un éxito total, si les interesa pueden leer algunos posts que escribí en aquel momento. Luego de este evento realizamos lo que denominamos el “Agile Open Tour” que consistió en hacer eventos Agile Open en distintas ciudades del interior del país. Entre las ciudades que visitó el tour en todos estos años se encuentran: Buenos Aires, Córdoba, Tandil, Bahía Blanca, Tucumán, Rosario, Paraná, La Plata y Mar del Plata. En varios casos estos eventos fueron el punto de partida para la conformación de comunidades locales.

Hasta el 2010, la comunidad éramos básicamente un grupo de entusiastas autoorganizados con ganas de compartir inquietudes, experiencias, conocimientos y aprendizajes. Esto estaba muy bien, pero no contábamos con ningún tipo de estructura organizacional lo cual resultaba un inconveniente en ciertas situaciones . Un ejemplo de estas situaciones fue cuando organizamos la conferencia Agiles 2008. Algunos de los sponsors de la conferencia pagaban en especias haciéndose cargo de algún gasto del evento. Pero otros aportaban directamente dinero y esperaban una factura de parte de la organización, ¡oops!.  Este fue el principal motivo que nos llevó a pensar en la necesidad de contar con una estructura organizacional. Básicamente teníamos dos opciones: armar una asociación civil o bien sumarnos a alguna asociación ya existente como ser IEEE o SADIO. Finalmente fue SADIO.

SADIO es la Sociedad Argentina de Informática, una institución que desde 1960 realiza diversas actividades relacionadas a la difusión de la informática. Posiblemente la actividad más importante sean las Jornadas Argentinas de Informática e Investigación Operativa que año a año reunen a investigadores y profesionales de la informática. SADIO prevé en su estatuto la existencia de grupos de interés denominados divisiones. Lo que nosotros hicimos fue crear la División Ágiles Argentina. Para ello, unos 15 participantes de la comunidad ágil nos asociamos a SADIO y completamos las formalidades para dar origen a la división.

Como comunidad, el ser parte de SADIO nos brinda una estructura organizacional que nos facilita la organización de actividades, como fue el caso de Ágiles 2011, Ágiles 2012 y el Scrum Gathering de Buenos Aires en 2012. Como individuos, el estar asociados a SADIO, brinda descuentos para la participación en eventos/cursos/actividades así como también el acceso a una serie de recursos de la institución.

Desde que somos parte de SADIO hemos participado activamente de las Jornadas Argentinas de Informática, dando cursos de agilismo en el contexto del Simposio de Ingeniería de Software (ASSE).  Adicionalmente, en 2013 algunos miembros de ágiles argentina han dictado cursos en SADIO, una actividad que esperamos se repita durante 2014.

La comunidad no tiene un espacio físico, pero si un espacio virtual que está dado por una página y una lista correo, cuya dirección se encuentra en la página.

ao_tandil_2011Agile Open Tandil 2011