Etiqueta: agile

El testing como ciudadano de primera

Sin duda Agile, y más específicamente XP, hicieron esto, pero no fueron los únicos.

En la época «pre-agile«, el testing estaba en manos de un grupo de personas «externas» al equipo de desarrollo. Agile cambio esto en varios sentidos, por un lado puso de relieve el testing como un trabajo de todos y junto con eso puso gran parte del testing en manos de los developers. Al mismo tiempo puso a los testers a trabajar codo a codo con los developers dentro del equipo de desarrollo y a la pasada cambió las tareas cotidiadas de los testers incluyéndolos en otras cuestiones como ser las plannings y los refinamientos, etc. Hasta aquí creo que no hay novedad, cualquier practicante en la actualidad sabe esto (consciente o inconscientemente).

Pero hay otro hecho que me parece ha pasado desapercibido. Resulta que estoy ayudando a un equipo de un cliente a mejorar su proceso de delivery y en ese contexto estamos agregando tests automatizados, cosa que el equipo nunca hizo. Su solución consiste en una aplicación móvil construida con Ionic y un conjunto de servicios construidos con node/loopback. Personalmente había hecho algunas cosillas con Ionic pero nunca había trabajado con Loopback. Para mi sorpresa, ambos framework traen soporte (guias, ejemplos, etc) para hacer pruebas automatizadas de distinto tipo. Más aún, el scaffolding de Ionic ya genera el esqueleto de pruebas cuando uno genera un componente. Esta sorpresa me hizo caer en la cuenta que hoy en día la gran mayoría de los frameworks de desarrollo ya traen soporte, documentación y ejemplos para hacer pruebas automatizadas. Esto que puede parecer «normal» en la actualidad pero creanme que no era así hace ~20 años cuando yo empezaba a dar mis primeros pasos con automatización de pruebas. Recuerdo varios proyectos lidiando para agregar pruebas a aplicaciones AspNet/C#.

Creo que unas de las herramientas pioneras en este sentido fue Smalltalk (¿squeak?) y luego Rails. Me parece que hoy en día todo frameworks/sdk viene con soporte para hacer pruebas automatizadas: Rails, Django, Java/Spring, NetCore, Nest.js, Next.Js, Android Sdk, por nombrar algunos populares. Es cierto que tal vez no todos los developers escriben pruebas, pero el hecho que las herramientas los habiliten representa una posición de la industria: los developers deben escribir pruebas y es de esta forma el testing se ha convertido en un ciudadano de primera categoría.

Libro recomendado: Joy of Agility, how to solve problems and succeed sooner

Compré este libro pura y exclusivamente por el autor: Joshua Kerievsky. Su libro «Refactoring to Patterns» me resultó excelente. Luego tuve la oportunidad de conocerlo personalmente allá por 2009 y desde entonces lo sigo. En general coincido con las ideas que comparte y por eso cuando vi este nuevo libro, «Joy of Agility», no dude en comprarlo.

Lo empecé a leer e inicialmente pensé que no me gustaría. Me parecía que era como muy filosófico, poco práctico, medio humo. Pero a pesar de esa sensación inicial seguí leyendo.

Lo terminé de leer hace unos días y debo decir que me gustó. Algo que me ayudó mucho a la lectura es que los capítulos son cortos, apenas dos páginas en muchos casos.

En cierto modo el libro es como un compendio de «anécdotas con moraleja». Cada capítulo cuenta una de estas anécdotas y termina con una moraleja/consejo que obviamente está relacionada a la agilidad.

Las anécdotas me resultaron muy entretenidas y muchas de ellas también muy útiles y de aplicación directa a mis tareas cotidianas.

Ojo, no es un para todo el mundo, si esperas ver código y demás nerdeadas, no es por acá. Pero si te consideras: agilista, coach, facilitador, agente de cambio o similar, entonces no dejes de leerlo.

Revisión y ajustes de «Construcción de Software: una mirada ágil»

Como mencioné hace unas semanas, estuve releyendo el libro. Bueno, lo terminé y encontré varias cuestiones. Aquí voy.

Contexto

Antes que nada me parece importante mencionar que el objetivo del libro era dar una idea general de agile incluso cuando algunos capítulos ofrecen bastante detalles de técnicas.

Sin duda que en estos últimos 10 años surgieron muchas cuestiones que podrían/deberían mencionarse en un libro de introducción a agile, algunos temas en este sentido podrían ser: escalamiento, #noEstimates y dual-track agile. Pero también es cierto que varias de las cuestiones que aparecieron no están necesariamente relacionadas a agile, por ejemplo «observabilidad» y «testear en producción» son prácticas que uno podría utilizar sin trabajar en un contexto agile del mismo modo que uno podría trabajar en un contexto agile sin usar estas prácticas.

Al margen de las prácticas yo creo que el mayor cambio que hemos presenciado es que hace 10 años agile era mainstream mientras que hoy en día ya ha supero eso y ahora es el enfoque por default (incluso cuando haya personas/organizaciones que no lo dominan).

Generalidades

La primer cuestión que detecté es que tendríamos que haber numerado explícitamente los capítulos, o sea, en la edición actual los capítulos solo tienen un nombre pero no tienen un número lo cual resulta incómodo cuando uno quiere referirse a un capítulo en particular :-(.

Como era de esperar (o no tanto) detecté algunos errores menores de tipeo (typos).

Creo que en ningún lado explicamos como es el flujo completo de un proyecto ágil, tenemos capítulos que tratan sobre cada una de las partes y tenemos también un capítulo que, a modo novela, cuenta un relato de un proyecto pero no tenemos un capítulo que explique la secuencia de eventos, ceremonias, etc. de un proyecto de punta a punta.

Me parece que falta más énfasis en la entrega continua, es una cuestión que está mencionada pero de forma muy tímida, discreta. Tal vez sea que la entrega continua es mi foco de trabajo actual (y desde hace unos años) pero si tuviera la posibilidad de hacer un ajuste en el libro, definitivamente sería poner más énfasis en la práctica de la entrega continua.

Muy relacionado con lo anterior, falta también más énfasis en stories pequeñas, de hecho creo que debería haber una sección (o incluso un capítulo) de slicing.

La práctica de Pair-Programming, que tiene más de 20 años y es core en XP, está apenas mencionada, creo que deberíamos haber escrito un capítulo al respecto (admito que cuando escribimos el libro, yo mismo no le daba la importancia que le doy en la actualidad a esta práctica).

En todo el libro hablamos constantemente de cliente pero en algunos casos creo que hubiera sido más conveniente hablar de usuario y obviamente hacer la diferenciación explícita entre usuario y cliente.

Finalmente, en lo personal, creo que cambiaría el orden de algunos capítulos.

Sobre cada capítulo

Nota previa: creo que la mayoría de los capítulos puede calificarse en uno de dos grupos: de mindset o de práctica. Los capítulos de mindset buscan explicar cuestiones de valores, principios, el espíritu de alguna cuestión casi sin entrar en cuestiones de prácticas o técnicas, aquí claramente están los dos primeros capítulos. Al mismo tiempo hay otros que se meten más concretamente en prácticas y técnicas, en cómo hacer concretamente alguna cuestión como es el caso del los capítulos de estimación (4) y retrospectivas (11). Dicho esto, los capítulos de mindset siguen siendo completamente válidos y casi que no requieren actualización. Por su parte los capítulos de prácticas, en su mayoría, requieren actualización ya sea por variaciones de las prácticas o por cambios en las herramientas.

Capítulo 1, «¿Por qué cambiar?»: es bastante filosófico/conceptual y si bien se podrían agregar algunas párrafos/secciones, creo que todo lo que dice sigue siendo válido.

Capítulo 2, «Iterativo por naturaleza»: también tiene un tinte bastante conceptual y apunta a explicar la necesidad de trabajar en forma iterativa. Me parece que hoy en día esta es una cuestión ampliamente aceptada aunque no en todos los casos correctamente implementada. Al igual que el capítulo 1, creo que se podría ampliar pero me parece que el contenido actual sigue siendo válido.

Capítulo 3, «Delineando el alcance»: explica las generalidades de las User Stories y la técnica de descubrimiento conocida como Visual Story Mapping(VSM). El contenido sigue siendo completamente válido y actual, aunque creo que amerita algunos ajustes relevantes. En primer lugar, cuando escribimos el libro no había una publicación formal de la técnica Visual Story Mapping, las fuentes disponibles eran algunos posts del blog del Jeff Patton (creador de la técnica) y de algunas otras personas que habían participado de alguna capacitación con el propio Patton. Al poco tiempo de la publicación de nuestro libro, finalmente Patton publicó un libro sobre esta técnica: User Story Mapping, Discover the Whole Story, build the right product. A partir de esto, nuestra descripción de la técnica difiere un poco de la descripción que hace Patton en su libro, lo cual no lo veo como un problema, nuestra descripción sigue siendo una herramienta válida y útil de comunicación/relevamiento. En este sentido creo que lo que sí le falta a nuestro libro (y en particular a este capítulo) es mostrar un ejemplo concreto del uso de la técnica. Finalmente algo que me suele ayudar mucho a entender el alcance de una funcionalidad es la técnica Example Mapping y por ello creo que agregaría una sección sobre la misma.

Capítulo 4, «Estimar no es predecir»: el contenido sigue siendo válido aunque mi práctica de estimación ha variado un poco. Creo que también que faltaría agregar algunos ejemplos concretos de las técnicas explicadas. Finalmente, si hubiera una nueva versión, sin duda agregaría alguna mención al movimiento #NoEstimates.

Capítulo 5, «Planificación constante»: aquí me parece que hay espacio para varios ajustes en línea con la idea de trabajar en un esquema de entrega continua. Planificamos el trabajo para toda la iteración pero esperando entregar los ítems apenas los vamos terminando sin esperar necesariamente al final de la iteración. Al mismo tiempo haría más énfasis en iteraciones cortas: una semana o a lo sumo dos. Creo que también es necesario ajustar la definición del slack pues me parece que no es precisa ni clara. Definitivamente agregaría algún apartado sobre técnicas slicing.

Capítulo 6, «Empezando por la aceptación»: este capítulo está muy bien y seguramente sea este el lugar para explicar con cierto detalle la técnica de Example Mapping. Este es uno de los capítulos que cambiaría de orden (lo pondría antes).

Capítulo 7, «Arquitectura y Diseño en emergencia»: gran parte de este capítulo habla de cuestiones que van más allá de agile, pero al margen de eso, su contenido sigue siendo actual.

Capítulo 8, «Probar, Probar, Probar»: trata de testing y dado que hace mención a varias herramientas requiere una actualización de las mismas. Al mismo tiempo creo que un punto para revisar es la taxonomía de pruebas, en lo personal, hoy en día no me convence del todo la taxonomía que escribimos.

Capítulo 9, «Esto está listo»: es más conceptual que práctico y ha envejecido bien. Nada que ajustar.

Capítulo 10, «Integrando el producto al instante»: al igual que el capítulo de arquitectura, tiene algunas cuestiones que van más allá de agile y al igual que el capítulo de pruebas hay cuestiones de herramientas a actualizar. Al mismo tiempo creo que falta mencionar más explícita y enfáticamente que hacer integración continua implica que todo el equipo trabaja simultáneamente sobre el mismo branch (o que si se crean branches, no deben vivir más de 1 día). Finalmente me resulta curioso que hablamos de feature flags sin utilizar el término feature flag.

Capítulo 11, «En retrospectiva»: es el más largo y si bien sigue siendo completamente válido, dista un poco de lo que es mi práctica actual de retrospectivas, principalmente la parte de preparación.

Capítulo 12, «Reuniendo al equipo»: creo que está muy bien, tal vez profundizaría sobre Pair-Programming (si no agregara un capítulo exclusivo para esta técnica).

Capítulo 13, «Irradiando Información»: muy bien, no creo que necesite cambios, tal vez un agregado para escenarios remotos.

Capítulo 14, «¿Quién manda a quién?»: es muy de mindset y sigue aplicando completamente.

Capítulo 15, «No hay como un buen ambiente»: me gusta mucho, sigue aplicando completamente tal como está aunque creo que faltaría agregar algo de operaciones y/o ambiente productivo.

Capítulo 16, «La fantasía de evitar los cambios»: completamente actual, nada que ajustar.

Capítulo 17, «Formalizando compromisos»: completamente actual, nada que ajustar.

Capítulo 18, «Construyendo con calidad día tras día»: completamente actual, nada que ajustar.

Capítulo 19, «Un día de desarrollo ágil»: creo que fue una muy buena idea para ejemplificar como fluye el día de un equipo trabajando con agile, sin embargo hoy en día creo que faltaría agregar alguna mención/situación relacionada a la operación/producción.

Capítulo 20, «Todo muy lindo pero…»: completamente actual, nada que ajustar.

Capítulo 21, «La riqueza de la diversidad»: completamente actual, nada que ajustar.

No sé si algún día escribiremos una segunda edición, pero en lo personal voy a escribir algunas línea relacionadas a los capítulos marcados en rojo y tal vez también para los naranjas.

Sobre la movida de la Agile Alliance y el PMI

El pasado 3 de enero se anunció «la unión» de la Agile Alliance (AA) al Project Management Institute (PMI) y por todos lados saltaron opiniones, muchas de ellas bastante críticas.

En lo personal el hecho en sí mismo no me resulta demasiado relevante. Al mismo tiempo lo que me llama la atención es la reacción «de la comunidad», muchos de los denominados agilistas.

En lo personal, he estudiado el PMBoK pero nunca me certifiqué como PMP ni fui parte del PMI. Por otro lado sí he tenido membresía de la Agile Alliance, ya que al ser speaker de su conferencia anual (Agile XX) solían otorgar una membresía como parte de los beneficios de speaker. Tampoco tengo ninguna certificación del universo Agile. En términos generales no soy partidario de las certificaciones, no les veo gran valor, pero eso es tema de otro post.

Respecto de la noticia en cuestión solo quiero compartir algunas preguntas para que el lector pueda reflexionar y sacar sus propias conclusiones:

¿Hasta qué punto estas organizaciones representan a los practicantes y a la práctica en sí misma? La misma pregunta podríamos hacerla para «la comunidad» ¿hasta qué punto la comunidad (la gente que organiza y participa activamente de eventos y del debate público) representa a los practicantes?

Aquellos que critican a la AA, ¿cuán involucrados están (o han estado) con la AA?

Cuando hacemos proyectos: gestionamos los proyectos o los proyectos nos gestionan a nosotros ¿qué preferimos?. Sin duda hay distintos enfoques para la gestión pero en lo personal me parece que algunos agilistas reniegan exageradamente de la gestión y en este sentido muchos han demonizado al PMI y su enfoque de gestión.

Sin duda que dentro de estos dos movimientos hay posiciones extremas. Podríamos pensar en los tradicionales gerentes de proyectos del mundo PMI y los fundamentalistas abrazadores de árboles dentro del mundo ágil. ¿Cuán representativos son estos estereotipos del grueso de los practicantes?

Una cuestión que sería importante tener presente es que el PMI como organización ha propuesto un enfoque de gestión que en cierto modo muchos ven como lejano, distante o incluso hasta contrario al enfoque de gestión de Agile. Debemos decir también que Agile surgió del mundo IT mientras que el PMI es mucho más amplio y por supuesto que no es lo mismo gestionar proyectos de IT que proyectos de Ingeniería Nuclear, Civil o Naval.

Finalmente, creo si leemos el comunicado dejando de lado cualquier prejuicio, el anuncio resulta interesante e incluso hasta prometedor. Veremos.

Sobre el ascenso y la caída de Agile, una opinión más

Me acerqué a agile allá por 2003. A diferencia de mucha otra gente, no me acerqué via Scrum sino via XP. Comencé a aplicarlo en proyectos hacia 2005. Pero no fue hasta 2008 que empecé a ver crecer el movimiento más allá de mi entorno. Conferencias, Meet-ups, Cursos, Certificaciones y oportunidades laborales.

Eso llamado «Agile» parecía funcionar, generaba interés, gente y empresas con ganas de «comprar». Una demanda creciente, una oportunidad de negocio. Un negocio. Y la demanda de agile no paraba de crecer. Y creció en diversas dimensiones. Por un lado agile traspasó las áreas de IT (donde inicialmente había surgido) y por otro lado gente de otras disciplinas se metió en IT. Agile coaches y Scrum Masters eran demandados por todos lados. Con esa demanda también florecieron aquellos vendiendo formación de Agile coaches y Scrum Masters. Alguno estuvieron mucho más preocupados por la venta que por la formación. Y Agile coaches y Scrum Master comenzaron a aparecer por todos lados. El agile industrial complex (Martin Fowler dixit)en su máxima expresión. Un fenómeno del cual fui (¿soy?) parte.

En un momento la torta comenzó a escasear, la tortilla se dió vuelta. Agile comenzó a perder credibilidad, a ser «mala palabra» para algunos y «puro cuento» para otros. Y los puestos de Agile Coaches y Scrum Master quedaron el ojo de la tormenta. Alguien le llamó «la crisis de la agilidad».

No sé en qué va a terminar esto, solo puedo decir que de los 3 equipos con los que trabajé en lo que va del año, el que mejor desempeño tiene es precisamente el que no tiene una persona exclusiva en el rol de scrum-master/coach 🤷‍♂️

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.