Herramientas de gestión de backlog: estas NO

No voy decir qué herramienta no utilizar. En lugar de ello voy a contar cómo me gusta trabajar y cuales son incomodidades/limitaciones que me he encontrado con ciertas herramientas pero sin dar nombres.

Parte de la motivación de escribir este artículo tiene que ver con que en más de una vez veo equipos trabajando de una determinada forma que ni a ellos mismos les convence y ante la pregunta de porqué lo hacen me dicen cosas tales como «Es que la herramienta lo maneja así» o «Nos gustaría hacerlo de otra forma pero nuestra herramienta no lo soporta«. Estas situaciones caen dentro de lo que yo suelo denominar «Poner el caballo delante del carro». En fin, voy con mi lista.

Identificación de ítems: me gusta poder referirme a los ítems del backlog de forma rápida con un número, onda: «el ítem 14», «el ítem 182». Resulta muy práctico y directo sin ambigüedades. Hay herramientas que en lugar identificador los ítems con secuencias numéricas por proyecto, utilizan identificadores largos tipo GUID o tienen una secuencia global para todos los proyectos entonces estos IDs tienden a ser números muy largos como «1234599934» y resulta incómodo utilizarlos para identificar los ítems en una charla.

Ítems linkeables: me gusta poder compartir links directos a cada ítem, es algo que parece trivial pero he visto herramientas que no lo soportan, solo es posible compartir un link al backlog y luego uno manualmente debe posicionarse en el ítem en cuestión.

Libertad en los tipos de items: en general tiendo a no hacer distinción en los tipos de ítems, por eso me resulta indiferente si la herramienta soporta o no distintos tipos de ítems (story, tasks, etc). Pero hay herramientas que fuerzan a que todo ítem sea de algún tipo (hasta ahí, ok) y junto con ello «le imponen ciertas reglas» (por ejemplo: cierto tipo de ítem no se puede estimar) mmm, esto ya es demasiado.

Prioridad y costo: todo ítem de backlog tiene una prioridad para el negocio y un costo (estimado) asociado de construcción, entonces espero que la herramienta provea soporte explícito para estos dos datos. No todas las herramientas lo hacen. El hecho de poder tener estas propiedades individualizadas permite a posteriori hacer ciertas operaciones de reporte 7 análisis.

Iteraciones: generalmente me inclino por un esquema de entrega continua pero igualmente me gusta trabajar en iteraciones para así poder establecer una cadencia de reflexión y planificación. Hay herramientas que no soportan iteraciones.

Reporting: al cabo de un par de iteraciones me gusta poder sacar algunas métricas y proyecciones de la evolución del proyecto. Hay herramientas que vienen con un nutrido set de reportes, otras tienen algún reporte pero permiten exportar la información. Pero hay otras que nada de eso.

Para cerrar, soy consciente que aún cuando la herramienta no soporte cierta funcionalidad, es posible que podamos, como decimos en Argentina, «atarlo con alambre», buscarle la vuelta, onda: si la herramienta no tiene soporte para indicar la estimación entonces la podemos cargar en la descripción. Mmmm, demasiado rudimentario para mi gusto.

En fin, el mercado está plagado de herramientas para gestionar el backlog, cada uno que use lo que guste pero procuren no poner el carro delante del caballo.

Libre recomendado: Wild West to Agile

Hace unos días terminé de leer este libro. Simplemente excelente. Su autor es Jim Highsmith, uno de los autores del Manifiesto Ágil. Jim ha escrito más de un libro y muchos artículos que nunca leí. Esa fue una de mis motivaciones para leer este libro.

El libro es en gran medida un repaso histórico, desde la perspectiva personal del autor, de la evolución de las metodologías y procesos de desarrollo. A lo largo del libro Jim va contando sus experiencias (que comienzan allá por los años 60) y que llegan hasta la actualidad. Creo que para quienes trabajamos en cuestiones de metodología y procesos es una excelente referencia para entender la evolución de la forma de trabajo y como una cosa llevó a la otra. Por otro lado creo que para aquellos «amantes de agile» es un lectura obligada para entender cómo fue gestándose Agile. El libro está plagado de anécdotas que van ejemplificando las distintas corrientes a lo largo del tiempo.

Una cosa que me gustó mucho del libro es la cuidada terminología. Jim dice explícitamente que prefiere hablar de Desarrollo de Software en lugar de Ingeniería de Software, reavivando esa eterna polémica. También habla explícitamente sobre «métodos estructurados», «metodologías monumentales», «métodos ágiles», «agile» y «agility». También hace una clara diferenciación entre método, metodología y mindset, términos que muchas veces se confunden (sobre todos los dos primeros).

Cuando habla de Agile hace explícita mención a prácticas técnicas y también a prácticas de gestión, resaltando las importancia de estas últimas.

En la parte final del libro se mete en temas de transformación digital y escalamiento. Aquí no habla de SAFe ni LeSS sino de EDGE y unFIX.

En fin, el libro me gusto mucho y lo super recomiendo.

La hora del Scrum Master técnico

Una publicación reciente de la Scrum Alliance sobre las habilidades en mayor demanda en la actualidad dice textualmente, entre otras cosas, «Delivery-facing agile roles, such as Scrum Masters, are being expected to be technical experts in addition to their agile responsibilities.» Esto está muy en línea con lo que yo mismo he observado en algunos de mis clientes.

Ocurre que en muchas organizaciones se toma el rol de Scrum Master como «exclusivo», o sea: se contrata una persona con habilidades de Scrum Master (y tal vez algunas otras habilidades «blandas») pero sin habilidades técnicas. Esto no está mal, pero tampoco pidamos peras al olmo: una persona sin habilidades técnicas será poco lo que podrá aportar en cuestiones técnicas de desarrollo/delivery. Creo que justamente en línea con este fenómeno (personas que solo saben de Scrum trabajando como Scrum Master) la última versión de la guía de Scrum no habla del Scrum Master como un rol sino como un conjunto de responsabilidades. Esto, a mi parecer, explicita el hecho de que las responsabilidades de «Scrum Mastering» puede ser tomadas por un Developer o algún otro rol (siempre que no haya conflicto de intereses).

Situación recurrente: una persona en el rol de Scrum Master con formación de Scrum Master pero sin formación en sistemas. La organización que lo contrata quiere «delivery» y en parte por ello espera que la persona en el rol de Scrum Master haga más que Scrum dicta del Scrum Master. Pedir que programe puede sonar mucho, pero pedirle habilidades de gestión suena bastante más razonable y aquí está muchas veces la cuestión. La gente que estudio sistemas estudio algo de gestión de proyectos pues es tema presente en todas las carreras de sistemas y hoy en día es muy posible que también haya estudiado Agile en general y Scrum en particular.

En parte fue esta situación la que me llevó a armar el Taller de Prácticas Técnicas para Scrum Masters que tan buena aceptación viene teniendo. En este taller vemos algunas cuestiones técnicas y también algunas cuestiones básicas de gestión de proyectos.

Siguiendo en esta línea de trabajo, estoy empezando a armar un Taller de Técnicas de Facilitación & Gestión para Tech Leads. el cual estará destinado a gente técnica que quiera tomar responsabilidades de facilitador de equipo, Scrum Master, etc. Obviamente tendrá algunos puntos de contacto con los del otro taller pero será un taller diferente y orientado a una audiencia diferente.

Si alguien está interesado en este taller puede contactarme por este formulario y le compartiré más información.

Podcast: Agilidad Técnica

Hace un par de días salió publicado un episodio del podcast La Revolución Ágil en el que estuve participando. El episodio fue grabado hace un par de meses y es básicamente una charla uno a uno con Camilo Velasquez, host del del podcast.

Previo a esta publicación tuvimos cierto desencuentro respecto del título con el que saldría publicado el episodio. El título original que había puesto Camilo me generaba cierta incomodidad pues a mi parecer transmitia una idea de «rivalidad» entre técnicos y agilistas. El título final, «Agilidad Técnica», me parece mas apropiado pero igualmente a mi parecer tiene cierta redundancia ya la verdadera agilidad implica el uso de ciertas prácticas técnicas (test-automation, CI/CD, etc).

Más allá de la cuestión del título, creo que la charla estuvo muy buena y creo que trae muchas cuestiones interesantes para aquellos agilistas que trabajan con equipos de entrega de software y que no tienen formación técnica.

Varias de las cuestiones que menciono en la charla son parte de mi Taller de Prácticas Técnicas para Scrum Master.

Agradezco a Camilo por invitación y lo felicito por iniciativa ya que al margen de este episodio hay otros episodios super interesantes. En lo personal me gustaron mucho los episodios 7 y 13 con Hiroshi y Alistair respectivamente.

Testing sin Testers, una mirada distinta al control de calidad

Tradicionalmente la actividad de control de calidad, usualmente denominada testing, ha sido llevada a cabo por personal con el rol específico de tester. Asimismo es una actividad que en muchos contextos se realiza de forma manual e incluso en algunas organizaciones de una forma no sistematizada y completamente ad-hoc.

Si bien las iniciativas Agile/DevOps han propuesto algunos cambios significativos en la forma de realizar el testing, muchas organizaciones siguen sufriendo estragos con el control de calidad en parte por seguir estrategias contrarias en esencia a lo propuesto por estas iniciativas.

Es por esto que mañana, jueves 16 a las 11:30 hs., estaré disertando sobre este tema en el contexto de las Jornadas de Calidad de Software y Agilidad organizadas por la Universidad Nacional de Misiones y que se realizarán en formato mixto presencial-online. Los interesados pueden registrarse aquí.

En mi disertación repasaré los puntos centrales del movimiento Agile/DevOps en lo referente al testing, compartiré varias experiencias de implementación que me han resultado efectivas y daré algunos consejos para quienes quieran aventurarse al cambio.

Mis notas de la conferencia Agile2023

Esta fue mi tercera participación en la conferencia Agile y al igual que en mis dos participaciones anteriores, también tuve la posibilidad de presentar una charla (ya hablé de ello en el post anterior).

Como es tendencia en todas las conferencias de Agile, la cantidad de charlas técnicas está en extinción. Mucho contenido de producto, transformaciones, chatgpt (¿¡!?) y curiosamente también muchas charlas de nivel inicial. Digo curiosamente porque a esta altura me resulta curioso que las charlas iniciales (agile essentials, como se las denominaba en la conferencia) hayan sido de las más concurridas.

De las charlas que asistí creo que las dos mejores fueron:

  • la de Jeff Patton, Shift: why it’s so hard to shift to a product mindset
  • la de Chris Edwards, Zero-Downtime Data migrations – Mastering Continuous Deployment

Otras que también me resultaron muy interesantes fueron

  • la de Nayan Hajratwala, Embrace these Three Fearsome Words: Test in Production
  • la Llewellyn Falco y Jay Bazuzi, Provable Refactoring – Safety without Tests
  • la de Jen Krieger, The developer-centric mindset will disrupt how all of us work
  • la de James Grenning y Jeff Langr, Your first test-driven development
  • la de Marisa Smith, Faster, Better, Stronger with Ephemeral Environments

En siguientes posts iré compartiendo detalles de algunas de estas charlas.

La organización como siempre, impecable, aunque me resultó raro y hasta inconveniente la duración de las charlas: en general los slots eran de 75 minutos. A mi me resultó bien (en parte porque tenia contenido para 2 horas más) pero en la mayoría de las charlas que participé sobró bastante tiempo. Una de las sesiones que participé sobraron literalmente ¡20 minutos!.

En lo personal tuve la oportunidad de compartir un par de días con colegas que no suelo ver: Hiro, Andrés y Martin que viven en Lima(Perú), Rosario(Arg) y Orlando(USA) respectivamente. Al margen de nosotros había unos cuantos colegas de Latam (al menos 15). También aproveché el viaje para hacerme de algunos libros: dos nuevos (The Joy of Agility y Wild West to Agile) y dos clásicos (Waltzing with Bears y Extreme Programming Explored).

Luego de haber participado en 3 ediciones creo que es una conferencia interesante, ofrece contenido variado y muchas oportunidades de networking. Al mismo tiempo participar puede resultar «bastante picante»: pasaje a USA, alojamiento y una entrada que ronda los $2.500. El «truco» es participar como speaker, ya que en ese caso la entrada está bonificada y alojamiento cubierto.

Cierro con una noticia: el año próximo la conferencia se realizará el Dallas, Texas.

Sobre la Guia Oficial de eXtreme Programming

En Scrum que existe una guía oficial que los autores mantienen actualizada. También existe una organización (en realidad creo que más de una pero la que conozco yo es la Scrum Alliance) que ofrece certificaciones de Scrum. En este sentido es razonable pensar que quien se acercó a Agile con Scrum, luego quiera acercarse a Extreme Programming (XP) y busque la guia oficial de XP.

Pero en XP no hay guía oficial, perdón si llegaron a este post buscando esa guía oficial. Al menos ahora saben que no existe :-). Tampoco existe una certificación oficial de XP, ni una XP Alliance.

En términos de publicaciones creo que los más cercano a una guía oficial es la serie de libros «XP Series» de la editorial Addison-Wesley publicada entre 1999 y 2005. En dicha serie se incluye el libro fundacional de XP escrito por Beck: «Extreme Programming Explained, Embrace chance» que a mi parece no es el mejor libro de la serie. No leí todos los libros de la serie en parte porque no pude conseguirlos, varios de ellos están discontinuados, de hecho algunos los conseguí usados. Dos libros que me parecieron excelentes fueron «Planning Extreme Programming» de Beck y Fowler y «Extreme Programming Installed» de Jeffries, Anderson y Hendrickson.

Por otro lado, un libro que a simple vista no parece de XP pero que definitivamente lo es, es el libro de James Shore «The Art of Agile Development«. La segunda edición, publicada en 2021, creo que es una descripción muy acertada de lo que podría considerarse un «XP Moderno».

En lo personal, creo que cada vez tiene menos sentido hablar de «métodos/marcos/metodologías» de desarrollo de software. Podemos debatir valores, principios, mindsets y luego bajar a prácticas concretas en las que materialicemos esos valores pero no necesitamos un rótulo para eso. Creo que las combinaciones pre-armadas de «valores + principios + prácticas» empaquetadas bajo un rótulo pueden agregar valor para un equipo/organización que recién empieza, pero a medida que conformamos grupos de trabajo más estables los «combos» agregan cada vez menos valor por el simple hecho de que el grupo de trabajo se convierte en un equipo y empieza a generar sus propias prácticas.

Meetup: Recorrida de Prácticas Técnicas para Gente no Técnica

La semana próxima, miércoles 19 a las 8:15 AM, estaré dando esta charla gratuita orientada a aquellas personas que trabajan con equipos de desarrollo de software pero que no tienen un perfil técnico. En la charla repasaremos la terminología y prácticas técnicas de uso habitual en equipos de desarrollo en la actualidad al mismo tiempo que haré una demostración en vivo del desarrollo y despliegue en la nube de una funcionalidad.

Los interesadxs en participar pueden registrase en el Meetup de Agiles Argentina para recibir el link de acceso.

Esta charla es la versión en castellano de la que estaré dando a fin de mes en la conferencia Agile 2023.

Charla Aceptada: Recorrida de prácticas técnicas para gente no téncnica

Desde el año pasado vengo trabajando en intentar transmitir la importancia de ciertas prácticas técnicas fundamentales para la entrega continua a aquellos que se encuentran trabajando con equipos de desarrollo de software y que no tienen un background técnico. En este sentido el año pasado diseñe un curso que ya he dictado dos veces y del cual ya tengo agendada una tercera edición.

En la misma línea del curso, envié una propuesta de charla a la conferencia internacional de Agile de la Agile Alliance. La propuesta fue aceptada y mi charla «Technical Practices Walkthrough for Non-technical People» está agendada para el jueves 27 de Julio a las 15:45. Para aquellos que asistan al evento nos vemos en Orlando y para los que no, tengo pensado hacer un Meet-up online en castellano para la comunidad hispano-parlante. Aún no tengo definida fecha ni plataforma, pero en cuanto la tenga lo publicaré aquí.

Resultado de la segunda edición del curso de Prácticas Técnicas para Scrum Masters

Hace un par de semanas completé el dictado de la segunda edición de este curso. Quedé muy conforme con los ajustes realizados luego de la primera edición y considero que el formato utilizado será el mismo en la siguiente edición: 5 encuentros de 2 horas cada uno.

En esta segundo edición, además de agregar un quinto encuentro, también agregué varias actividades para sumar así un total de 20 actividades extra clase. Según reportaron los mismos participantes, la dedicación promedio semanal fue de 3 horas lo cual hace que la dedicación total del curso ascienda a 25 horas (10 horas de encuentros online y 15 horas de actividades extra clase).

La evaluación del taller por parte de los participantes fue muy positiva.

Sin duda que hay algunas cuestiones que mejorar pero en términos generales estoy muy conforme y contento con el resultado. Comparto algunas frases que los participantes dejaron en el formulario de feedback:

«Me encantó el curso, me fue de mucha utilidad para comprender conceptos de los cuales no tenía conocimiento y que me permiten comunicarme mejor con los equipos a los que acompaño«

«Me gusto mucho el curso, la parte de devops fue la más esclarecedora junto con el mapa de las formas de quebrar o realizar slicing de una Historia de Usuario, fue excelente.«

Para aquellos interesad@s en participar de la próxima, ya tenemos fecha y está abierta la inscripción, pueden ver más info aquí.