La influencia de Agile en el uso de prácticas de desarrollo

Este el título del artículo de investigación que estaré presentando en Congreso Bianual de IEEE Argentina. Este artículo, cuya autoría comparto con Diego Fontdevila y Alejandro Oliveros, es parte del resultado de nuestra participación en la iniciativa HELENA Survey. La presentación será esta tarde en el bloque de 15 a 17 hs., la participación es gratuita pero requiere registración aquí.

En forma resumida encontramos que entre las prácticas de desarrollo más utilizadas, las prácticas de gestión/organización son prácticas que fueron introducidas por los métodos ágiles. Al mismo tiempo vemos que las prácticas técnicas más utilizadas son principalmente prácticas previas a los métodos ágiles pero que estos últimos han reconocido e incorporado. En cierto modo podríamos leer esto como lo que la industria tomó de Agile es principalmente técnicas de gestión/organización.

La publicación de este trabajo marca el cierre de una etapa en mi trabajo de investigación. Esta etapa que inició allá por 2016 estuvo enfocada en estudios de índole principalmente exploratoria sobre el uso de métodos ágiles de desarrollo de software. El año próximo continuaré trabajando en otra línea de investigación relacionada a la enseñanza de ingeniería de software (tema que ya vengo trabajando desde 2018) y comenzaré a trabajar en el estudio de prácticas de desarrollos de software.

La motivación de estudiar las prácticas concretas de desarrollo surge a partir de ver que muchos equipos no utilizan un método/enfoque/proceso particular sino que más bien utilizan algún tipo de “enfoque híbrido” que combina prácticas de diferentes enfoques/métodos/procesos. En particular me interesa estudiar experimentalmente dos prácticas: Pair-programming y Test-Driven Development.

#HistoriaDeTrinchera: Planning de una User Story

Recurrentemente hablo con gente que me comenta de sus dificultades para completar el trabajo planificado en la iteración. En muchos de esos casos mi sensación es que el equipo incluye funcionalidades en su iteración sin tener suficientemente en claro su implicancia. Creo que muchos se han ido del extremo de especificar cada detalle de la funcionalidad en un documento tipo especificación de casos de uso, a directamente pasar al otro extremo y escribir un título y nada más. Es por esto que quiero compartir en este artículo el ejercicio que intentamos hacer en mi proyecto actual a la hora de armar nuestro backlog de iteración determinando las funcionalidades que trabajaremos.

Una de las particularidades de nuestro proyecto es que como parte del equipo tenemos una especialista en diseño de experiencia usuario (digo particularidad pero me parece que esto es cada vez más común). A su vez esa especialista es en simultáneo parte de otro equipo que trabaja en forma transversal en el diseño de la experiencia de varios productos de la organización. Es así que las funcionalidades (que usualmente llamamos user stories) se piensan desde un momento muy temprano teniendo presente la experiencia que se quiere ofrecer al usuario. De esta forma, cuando hablamos sobre una funcionalidad en una reunión de planificación generalmente ya contamos con un diseño de pantalla (o tal vez varias) que acompañan la conversación.

De la conversación sobre la user story buscamos esclarecer los siguientes puntos para poder agregarla al backlog de la iteración:

  • El escenario principal de uso y alguno de los escenarios alternativos más importantes. De ser posible, y si la complejidad lo amerita, ahi mismo expresamos estos escenarios en sintaxis Gherkin.
  • Las tareas necesarias para completar la story como ser: codear la pantalla, codear un nuevo servicio, codear componente para conectar con otro sistema, generar los datos de prueba, automatizar la prueba end-2-end, etc, etc
  • La dependencias de otras aplicaciones/apis y estados de las mismas (esa API que debemos consumir ¿ya está disponible en producción? ¿la está consumiendo algún otro equipo?)
  • La necesidad (o no) de hacer que la funcionalidad sea “apagable” o “segmentable”. Hay funcionalidades que son simples y de baja criticidad que apenas las terminamos pueden ser liberadas al público en general, pero hay otras que, ya sea por su complejidad o criticidad, se prefiere liberarlas gradualmente a distintos grupos de usuarios. En términos técnicos pretendemos identificar si la funcionalidad debe ser “toogleable”.

A medida que vamos viendo cada una estas cuestiones vamos tomando conciencia del tamaño y la complejidad de la funcionalidad y puede que en base a ello decidamos partir la funcionalidad en varios cortes (lo que comúnmente se conoce como slicing).

En algunos casos parte de estas cuestiones se hablan en una reunión de refinamiento que ocure previamente a la planning. A su vez dicha reunión nos permite identificar potenciales blockers para el desarrollo de alguna funcionalidad pedida. En algunos casos también ocurre que la funcionalidad pedida depende de funcionalidades provistas por alguna API desarrollada por otro equipo y que no se encuentra disponible aún o tal vez no provee todo lo que necesitamos. En estos casos en lugar agregar la funcionalidad en cuestión a nuestra iteración, agregamos una tarea de gestión para darle seguimiento a al desarrollo de esa API e incluso hacer algún prueba de concepto como para ir familiarizándonos.

Dos datos adicionales de contexto:

  • En las reuniones de refinamiento no participa necesariamente todo el equipo. Seguro están los especialistas de negocio, la especialista en UX, el facilitador y algunos devs. En general esta reunión dura 1 hora.
  • Las reuniones de planificación tiene 2 partes: una estratégica donde participa todo el equipo y una táctica donde solo participan los técnicos (devs & testers). Entre ambas se van entre 2 y 3 horas.

A partir de lo anterior resulta que para planificar una iteración de 2 semanas este el equipo requiere en total de unas 4 horas de trabajo conjunto.

Algunas de estas cuestiones puede que no coincidan exactamente con lo que recomiendan algunos libros y posiblemente a algunos lectores puede que le resulten impracticables en su propio contexto y lo entiendo. No es mi intención convencer a nadie de trabajar de esta de esta forma, simplemente pretendo compartir lo que a nosotros nos viene funcionando y nos permite entregar software todas las semanas.

Enseñanza de Métodos Ágiles en Argentina

Corté el título porque quedaba demasiado largo, pero para ser preciso debería haber puesto: Enseñanza de Métodos ágiles de Desarrollo de Software en Argentina. Estado del Arte. Este es el título formal del trabajo con el que completé mi carrera de Especialista en Tecnología Informática Aplicada en Educación (UNLP).

Este trabajo es un estudio formal y sistemático basado en métodos empíricos de investigación. El trabajo completo tuvo 3 fases.

La primera fase, a fines de 2018, fue incluso antes de comenzar formalmente con el trabajo de especialización. Hice una encuesta entre estudiantes en CONAIISI 2018. El resultado de esa encuesta fue un artículo titulado en “Initial Assessment of Agile Development in theUndergraduate Curricula” que fue publicado en el Workshop Brasilero de Métodos Agiles que se llevó a cabo en el contexto de Agile Brazil 2019.

La segunda fase, ya en el contexto de la especialización, consistió en un mapeo sistemático de literatura que fue publicado en el XXV Congreso Argentino de Ciencias de la Computación con el título Introducing Agile Methods in Undergraduate Curricula, a Systematic Mapping Study

Hasta este punto, toda la información recolectada no resultaba suficiente para tener un entendimiento lo suficientemente certero sobre el estado de la enseñanza de métodos ágiles en Argentina. Entonces ya en la fase 3 realicé una encuesta a docentes de Ingeniería de Software, que es el área donde típicamente se estudian métodos ágiles. Para esto contacte en forma personalizada a los docentes de Ingeniería de Software de la universidades pertenecientes a la Red de Universidades Nacionales con Carreras de Informática, un organismo que agrupa tanto a instituciones públicas como privadas.
Logré así recolectar respuestas de 69 cursos pertenecientes a 44 instituciones distintas. Según los datos provistos por de la Secretaría de Políticas Universitarias del Ministerio de Educación de la Nación , las instituciones relevadas en mi estudio “generaron” en ~77 % de los egresados de las carreras universitarias de informática en el país en el 2017. Esto da cuenta de la representatividad de la muestra analizada.

Entre los resultados encontrados, destacan:

  • Los métodos ágiles son enseñados en el 97.7 % de las carreras de grado relevadas. Más aún, en el 54,5 % de los casos, los métodos ágiles se estudian en el contexto de varias materias que también abordan otros temas.
  • La gran mayoría de los encuestados (83.8 %) dicta sus materias de forma completamente presencial. Este hecho puede estar influido por cuestiones de regulaciones ya que muchas instituciones no admiten alternativas de educación no presencial y exigen asistencia física a las clases. Sin embargo, el 70 % de los encuestados utiliza en sus materias un campus virtual, lo cual representa una extensión del aula y por ende cierto grado de hibridación en la modalidad de enseñanza.
  • El 77 % de los encuestados indicó enseñar Scrum, pero tan solo el 53 % indicó enseñar Retrospectivas, que sin duda es una de las prácticas más importantes de Scrum. Iteration Planning, Iteration Review y Daily Standup son todas prácticas centrales de Scrum y su porcentaje de enseñanza es bastante menor al de Scrum
  • Respecto de las prácticas ágiles; User Stories, Iteration Planning, Planning Pocker, Retrospectives e Iteration Review son las cinco prácticas más enseñadas, las cinco por encima del 50 %. Cabe destacar que estas cinco prácticas pertenecen todas a la categoría “Practicas de gestión”.

Los interesados en leer el trabajo completo lo pueden descargar desde este link.

El próximo lunes 17 a las 19.00 hs voy a hacer un sesión online para compartir los resultados de este estudio y debatir al respecto. Si estas interesado en participar, puedes registrarte aquí.

The Pragmatic Programmer

La primera edición de este libro fue publicada en 1999 pero yo no lo conocí hasta ~2005. Y no lo leí hasta 2009 cuando lo encontré la biblioteca de la empresa en la que trabajaba en aquella época. El año pasado se publicó la edición 20 aniversario y no dudé en comprarlo. Ayer terminé de leerlo.

Mas allá de la elegancia de la edición tapa dura, a nivel contenido el libro no tiene desperdicio y creo que es una lectura obligada para todo developer. Cubre temas muy variados que van desde principios de diseño, estimación, hasta ética profesional pasando por programación concurrente, técnicas de testing y recomendaciones de organizacional personal.

Complementariamente a la usual división en capítulos, el libro está organizado en “temas” (topics) que son subdivisiones de los capítulos y la extensión de cada uno es tal que su lectura puede realizarse en 30 minutos (lo cual a mi personalmente me facilita mucho la lectura). Asimismo al final de cada tema se listan los temas relacionados y se ofrece una serie de ejercicios, algunos de reflexión, otros de programación, etc.

Los autores son Dave Thomas y Andrew Hunt, ambos autores del Agile Manifesto. Tal vez por eso muchas de las cuestiones tratadas en el libro están abordadas desde una perspectiva ágil.

Esta edición 20 aniversario es bastante distinta a la edición original de 1999. La esencia de libro es la misma pero el contenido ha sido totalmente actualizado. De hecho los propios autores reconocen que hay partes del libro que fueron completamente reescritas.

#HistoriaDeTrinchera: equipo completo

Al cabo de 6 iteraciones hemos completado el equipo. Resulta que al comenzar la sexta iteración se sumó el miembro faltante. Tenemos ahora cubiertos todos los roles/habilidades que consideramos necesarios para llevar adelante el proyecto y al mismo tiempo hemos alcanzado, a mi criterio (no estoy seguro que mis colegas compartan) el número máximo de personas que el equipo puede tener.

Nuestra expectativa es poder tener dentro del equipo todas las habilidades (y autorizaciones) para operar en un esquema de entrega continua dentro de ciertas restricciones organizacionales que por el momento no parecen estar abiertas a negociación (tema de otro post). En este sentido tenemos los siguientes roles/habilidades:

  • Developer
  • Tester
  • Diseñador de UI/UX
  • Facilitador
  • Product Owner
  • Infraestructura

Estos roles/habilidades son ocupados por personas que están en el día a día del proyecto y que como tal participan diariamente de las reuniones de sincronización (daily standups). Algunas aclaraciones que pueden resultar relevantes para el lector:

  • Developers: apuntamos a que puedan desarrollar una funcionalidad de punta a punta, lo cual implica tanto hacer tanto front (angular) como back (netCore) y tocar algunas cuestiones de infra como pipeline de CI/CD y generación de los correspondientes contenedores.
  • Testers: en el sentido de Agile, trabajan muy de la mano de la gente de negocio y con una visión funcional. Colaboran en la identificación/definición de casos y también en su automatización.
  • Diseñadores de UI/UX: diseñan/validan la experiencia del usuario y definen las pantallas. Trabajan muy de cerca con la gente del negocio y los usuarios. No codean, su trabajo llega hasta el maquetado con alguna herramienta tipo Miro, Marvel y Zeplin.
  • Facilitadores: llamados a veces Scrum Masters o coaches, ayudan a que el equipo mantenga el foco en el proceso y la entrega de valor, destraban impedimentos y mantienen los diálogos abiertos con otros equipos/áreas.
  • Product Owners: es gente con perfil de negocio que define el norte del producto, concentra los pedidos de los usuarios y los prioriza.
  • Infraestructura: más allá del control que tenga el equipo sobre la infraestructura es fundamental que el equipo entienda (y pueda definir y discutir) ciertas cuestiones de infraestructura porque pueden impactar en la implementación de algunas características/funcionalidades de la aplicación. En este caso particular, la organización tiene un área de DevOps con la cual nosotros como equipo de desarrollo trabajamos muy cerca en un ida y vuelta constante. Luego ese equipo de DevOps se encarga de la interacción con el resto de los sectores de infraestructura como seguridad, networking, etc.
    (este es un punto que puede resultar polémico y por ello le dedicaré un post aparte)

Todo este conjunto de roles/habilidades está repartido entre 12 personas, varias de ellas con asignación parcial (yo entre ellas). Para mi gusto ya son demasiadas personas y como algunos colegas coinciden con esto, es muy posible que en el corto/mediano plazo sumemos más gente y partamos el equipo en 2.

Sobre la cadencia de iteración

Sobre la cadencia de iteración

Personalmente me gusta trabajar con iteraciones de 1 semana. Pero en el proyecto que estoy trabajando actualmente acordamos trabajar en iteraciones de 2 semanas pues la mayoría del equipo así lo prefiere y no logré convencerlos. Y cuando digo la mayoría del equipo en este caso es todo el equipo salvo yo. Entre los argumentos de mis compañeros para no hacer iteraciones de 1 semanas se destacó: “si hacemos iteraciones de una semana vamos a invertir demasiado tiempo porcentual en planning, review y retro”. Personalmente no coincido, al ser las iteraciones más cortas, la planning y la review deberían también ser más cortas. Pero es cierto que más allá del tiempo dedicado a planning y review hay un costo de logística/setup de cada reunión.

Mi preferencia por las iteraciones de una semana se remonta a unos 10 años atrás. Desde entonces siempre que puedo intento trabajar de esta forma. Otra de mis preferencias es hacer las iteraciones en continuado agrupado en un mismo día las reuniones de revisión y planificación. Respecto de las retrospectivas no considero mandatorio que tengan la misma cadencia que la planificación. En varios proyectos he trabajado con una cadencia de planning/review semanal y con retrospectivas cada 2 o 3 semanas dependiendo de la consolidación del equipo.

Cuando me toca trabajar en iteraciones de 2 semanas (como en mi proyecto actual) yo igualmente en iteraciones de 1. No es que yo haga planning y review en solitario ni en paralelo, sino que al inicio de la iteración yo mentalmente planifico que voy hacer durante la primera semana. Una vez completa la primera semana, hago un checkpoint de mitad de iteración, leo el burndown chart, analizo cuánto hemos completado y veo como enfocar la semana siguiente de cara a intentar asegurar cumplir con el plan de la iteración o de ajustarlo si es que el contexto así lo requiere.

Agile a izquierda y derecha

Continuando con la inquietud que traje hace un par de días comparto algunas ideas más surgidas de mi intercambio con mi querido colega @Pablitux.

Dada la relevancia del factor humano, la consciencia del otro, el espíritu de co-creación y colaboración, uno podría pensar que Agile tiene cierto aire de “izquierda”.

Del mismo modo si pensamos en el foco en la entrega de valor, la eliminación de desperdicios y la optimización del flujo, uno podría pensar que es un enfoque resultadista, algo que suena más de “derecha”.

Más allá de esto pensamientos algunos hechos que podrían aportar a esta reflexión.

  • Toda la movida de Scrum at Scale tiene una onda muy corporativa
  • El libro de Tobias Mayer & Alan sobre Scrum se llama Por un Scrum Popular
  • En Ágiles 2017 no hubo sponsors, lo que podría interpretarse como una postura “anti mercado”
  • El Ágiles 2014 se hizo en un hotel de categoría, la organización estuvo a cargo de una empresa de eventos, el precio de la entrada fue record y los sponsors estuvieron muy presentes en el evento

Estudio sobre enseñanza de métodos ágiles (pedido de ayuda)

El principal foco de mi trabajo de investigación este año es la enseñanza de métodos ágiles en carreras universitarias de grado en Argentina. En ese sentido llevo publicados dos trabajos:

  • Introducing Agile Methods in Undergraduate Curricula, a Systematic Mapping Study, publicado en CACIC 2019
  • Initial Assessment of Agile Development in the Undergraduate Curricula, publicado en WBMA@AgileBrazil 2019

El primero es una revisión de sistemática de publicaciones. El segundo es un trabajo basado en una encuesta realizada a estudiantes de carreras de informática. El tercer paso de este trabajo de investigación es estudiar el tema desde las perspectiva docente y en ese sentido estoy contactando docentes de ingeniería de software y afines para revelar qué enseñan y cómo lo enseñan.

Hasta el momento he logrado contactar docentes de 22 universidades, no pretendo contactar docentes de todas las universidades de país, pero hay algunas que particularmente me gustaría poder contactar:

  • Universidad de Mendoza
  • Universidad Nacional de Córdoba
  • Universidad Nacional de Rosario
  • Universidad Nacional de Entre Ríos
  • Universidad Nacional de Formosa
  • Universidad Nacional de La Pampa
  • Universidad Nacional de Río Cuarto
  • Universidad Nacional de Santiago del Estero

Si algún lector puede darme una mano para contactar docentes de ingeniería de software de estas instituciones le estaré muy agradecido.

Agile, Economía, Tradicionalistas e Innovadores

El clima político que se ha vivido en Argentina desde el comienzo de las campañas electorales me llevo reflexionar sobre las posibles relaciones entre Agilismo y los tan mencionados modelos económicos que tanto han sido nombrados en estos últimos tiempos. Antes de adentrarme más en el tema quiero aclarar que no soy experto en estos temas, sino un simple ciudadano de a pie, cuyas ideas pueden implicar razonamientos erróneos. Hecha la advertencia, avanzo.

Dentro de lo que ha dado en llamarse “Agile” o “Agilismo” hay a mi entender dos corrientes que yo personalmente denomino “los tradicionalistas” y “los innovadores”.
Los tradicionalistas son lo que ven los métodos ágiles como literalmente los describe el manifiesto: “…formas mejores de desarrollar software…” y por consiguiente lo aplica puntual y concretamente al desarrollo de software.
Los innovadores son los que tienen una conexión más profunda con el Agilismo y lo aplican en diversos contextos de su vida, excediendo por mucho el desarrollo de software e incluso el ámbito laboral. Yo personalmente me considero tradicionalista pero tengo varios amigos y colegas que sin duda se ubicarían en el grupo de los innovadores.

Para los tradicionalista me parece que no hay conexión entre agile y los modelos económicos.

Pero en el caso de los innovadores sospecho que puede llegar a haber cierta conexión. Los innovadores “van con agile a todos lados” y eso hace que agile se filtre indefectiblemente en la discusión de modelos económicos. Y cuando hablo de modelos económicos no me refiero necesariamente a cuestiones de macroeconomía sino también a cuestiones más del día a día como la forma en que nos organizamos dentro de una organización. Un dato en este sentido: en el meetup de Agiles Argentina suele hablarse con bastante frecuencia de organizaciones horizontales. En contraposición a eso, mientras escribo estas líneas me viene a la memoria una conversación con un colega que me cuenta que está trabajando en un corporación internacional y que están implementado SAFe lo cual me hace pensar que estoy escribiendo boludeces (perdón el término, puede que no suene elegante pero es muy gráfico).

En fin, me cuesta articular argumentos, tal vez porque soy un tradicionalista. Voy a cortar aquí y voy a intentar validar algunas ideas con colegas innovadores a ver opinan.

Continuará….

Algunos datos de Agiles 2019

La semana pasada estuve participando de la conferencia Latinoamericana de Agilidad, previamente llamada Conferencia Latinoamericana de Métodos Ágiles. Desconozco cuándo ocurrió el rename, pero ocurrió.

En términos generales debo decir que estuvo muy bien. Superó mis expectativas, aunque sinceramente no esperaba demasiado considerando que a mi parecer en los últimos años la conferencia se viene “alejando” de la construcción de software para enfocarse en cuestiones más genéricas de gestión y colaboración.

Algunos puntos que me parece vale la pena destacar:

  • El lugar de la conferencia me pareció muy apropiado: un espacio enorme con más de 20 salas alrededor
  • Había 2 salas especialmente acondicionadas para sesiones de programación / con computadoras
  • Un bar/restaurant dentro del espacio abierto
  • No hubo un momento predefinido para el almuerzo, había sesiones todo el tiempo y cada uno elegía a qué hora parar para comer o incluso se podía seguir de largo. De esta forma se evitó congestión a la hora de almorzar
  • El lugar de la conferencia estaba ubicado entre un parque y un centro comercial. Se podía cruzar fácilmente al patio de comidas del centro comercial del mismo modo que se podía cruzar al parque para disfrutar el aire libre. Incluso me parece que hubo alguna sesión en el parque
  • El marketplace del open space fluyó bastante bien a pesar de la gran cantidad de participantes (~1000)
  • Respecto del contenido creo que hubo para todos los gustos:
    • sesiones técnicas / específicas de software,
    • sesiones más orientadas a la gestión / colaboración (la mayoría me parece que fueron de este tipo)
    • y sesiones diversas que no entran en ninguno de los otros dos grupos que mencioné

Esta es la tercera edición de la conferencia en formato 100% Open Space y sin keynotes, me parece que es un momento interesante para detenernos a pensar cómo queremos que sea el evento en las siguientes ediciones, pero ese es un tema que trataré en otro post.

Un detalle interesante de las credenciales es que tenían semillas incrustadas con la idea de plantar la credencial una vez finalizada la conferencia
En la apertura del evento hubo un show de tango: músicos en vivo y una pareja de baile