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í.
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í.
La semana pasada completé la primera edición de este curso que pensamos junto @martinalaimo. Estoy muy contento con cómo salió considerando que fue la primera edición.
Fueron 4 encuentros online y sincrónicos a todo ritmo con un grupo de 20 participantes muy motivados. Si bien los encuentros tuvieron bastante interacción, me quedó gusto a poco con las interacción offline, me hubiera gustado ver más participación en los foros :-(.
Hablamos de facilitación de estimaciones, modelos de branching, integración continua, test automation y devops.
El feedback de los participantes fue muy positivo y todos coincidieron en que el curso debería haber tenido más encuentros para poder profundizar mas en algunas cuestiones, cosa con la que estoy completamente de acuerdo. Agradezco a todos los participantes por haberse sumado al curso y haber sido en cierto modo «conejillos de india» de este nuevo curso.
Ya tengo en mente varias mejoras para la siguiente edición incluyendo el hecho de extender la duración (posiblemente sean 5 o 6 encuentros) y agregar algunas demostraciones «ejecutables» de pipelines y pruebas automatizadas. Aún no hemos puesto fecha para la siguiente edición pero seguramente tengamos una fecha para el primer trimestre de 2023.
Finalmente quiero agradecer a Martin Alaimo por haberme alentado en esta iniciativa y al equipo de AlaimoLabs por el soporte y la logística del curso.
Desde 2006 vengo trabajando con equipos desarrollo que intentan trabajar en una dinámica «tipo Scrum». Sin embargo son contadas con los dedos de una mano las ocasiones que he trabajado con un Scrum Master que aporte valor al equipo desarrollo más allá de los rituales estrictos de Scrum. Lo que ocurre es que a medida que el equipo va ganando experiencia en Scrum el aporte del Scrum Master se va diluyendo si el Scrum Master se limita a aportar estrictamente desde Scrum.
Sin embargo, los equipos de desarrollo afrontan diversos desafíos que van más allá de las reglas de Scrum y de las cuestiones de programación. Muchos de esos desafíos representan oportunidades para que un Scrum Master agregue valor al equipo. Pero para eso es necesario que el Scrum Master se familiarice con algunas cuestiones de indole técnica que típicamente no forman parte del camino de formación de un Scrum Master. A esto se suma una situación cada vez más habitual: gente desempeñándose en rol de Scrum Master que no viene del mundo IT. No resulta extraño hoy en día encontrarse con equipos de desarrollo cuyo rol de Scrum Master es ocupado por una persona con formación en psicología, arte, marketing o ciencias sociales.
Es por esto que hace un tiempo, junto a Martín Alaimo, comencé a trabajar en el diseño de un entrenamiento para Scrum Masters de cara a ayudarlos adquirir conocimientos y habilidades para poder sumar valor a sus equipos de desarrollo más allá de lo que propone Scrum.
El curso está pensado para personas en el rol de Scrum Master (o facilitador de equipo en términos más generales). No es necesario tener formación el IT/programación pero sí es necesario tener experiencia de campo trabajando con un equipo de desarrollo.
El curso será en modalidad online, con 4 encuentros en vivo (uno por semana) y varias actividades semanales a lo largo de las 4 semanas del curso. Pueden encontrar más información aquí.
Este es el título de la charla que voy a estar dando en el contexto de la conferencia XP 2021 el 17 de Junio a las 14:00 (GMT-3). La charla está basada en un artículo que escribí a modo de reporte de experiencia con la colaboración de Rebecca Wirfs-Brock y que será publicado en el sitio de la Agile Alliance.
El punto central de la experiencia que voy a contar pasa por la estrategia de slicing que utilizamos en un proyecto en el que participé el año pasado. Dicha estrategia fue central para poder entregar incrementos de valor de forma continua. Al mismo tiempo la estrategia de slicing requirió del uso conjunto de otras técnicas como continuous delivery, feature toggles y una arquitectura de «micro-apps».
Esta conferencia es una de las conferencias que más me gusta porque tiene la particularidad de combinar trabajos formales/académicos con experiencias de industria. Los interesados en participar pueden aprovechar la registración temprana que está habilitada hasta el 31 de mayo.
Los métodos ágiles surgieron en los 90′ y su «nacimiento formal» se ubica usualmente en 2001 con la firma del manifiesto.
Hacia 2010 Forrester ya decretaba Agile como mainstream.
Hoy, 2021, creo que «todos son ágiles» o al menos dicen serlo. Claro está que del dicho al hecho hay un gran trecho.
En los años que llevo trabajando como facilitador he visto situaciones de las más variadas respecto de la adopción de Agile a nivel equipos de desarrollo pero que en términos muy simplificados podrían clasificarse en dos grandes grupos: 1) Equipos que llegan a agile desde «el desorden» y 2) Equipos que llegan a agile desde un proceso definido, no-agile, generalmente controlado, secuencial o «iterativo «laxoo»(iteraciones de duración variable, típicamente no time-boxes, etc.)
En el caso de los equipos que provienen del desorden, generalmente optan por agile (y particulamente por Scrum) sin mayor cuestionamiento. Como que simplemente siguen al rebaño. Esto obviamente trae sus riesgos ya que en más de un caso los equipos no cuentan con los requisitos mínimos para aplicar agile de forma eficaz (usuario/PO muy involucrado, developers capaces de auto-organizarse, etc). Según he visto, en muchos casos esto resulta en equipos que dicen practicar agile pero que en la práctica terminando haciendo ScrumBut y/o Flaccid Scrum. Obviamente esto les impide alcanzar todos los beneficios que generalmente se esperan de un equipo usando agile, pero a pesar de eso puede que el equipo termine trabajando de una forma mejor que lo era su situación previa trabajando en el total desorden.
El caso de los equipos que llegan a agile desde un proceso no-agile pero definido, controlado y generalmente secuencial es menos frecuente en mi experiencia. En los casos de este tipo con los que me he cruzado mi sensación es que logran una implementación más sólida de agile, ya que generalmente cuentan con cierto orden y capacidades que les permiten gradualmente incorporar distintas prácticas de agile.
Esta situación de que «todos son ágiles» me ha llevado personalmente a intentar evitar el término agile para definir una forma de trabajo. En general prefiero hablar en términos de prácticas pues me parece que resulta mucho más concretro que hablar de «Agile en abstracto» o «Scrum by the book».
Desde hace ya un par de años me hace más sentido hablar de prácticas y performance de delivery que de Agile o Scrum. En este sentido me resulta mucho más significativo que un equipo me diga que su lead time es de 1 semana a que me diga que hace Scrum.
En fin, resumiendo: hoy en día todos dicen ser Agiles, pero en la práctica no todos lo son en verdad. Muchos practican agile con un grado tal de ineficacia que su «agilidad» bien podría debatirse. Esto me lleva a reforzar el fondo de la cuestión (al menos desde mi perspectiva): la cuestión no es si agile o no, la cuestión es cuan buenos(y felices) somos entregando valor independientemente de la forma en que lo hagamos. Personalmente hoy creo que para muchos contextos tiene más sentido analizar la entrega de valor desde un perspectiva Lean que desde una perspectiva Agile.
Nota: Lean y Agile no son lo mismo, son dos marcos diferentes, con mucha afinidad, pero distintos. Diferencias y similitudes de estos marcos serán tema de otro artículo.
Este es el título de la charla que di la semana pasada en el contexto de un webinar organizado por la Agile Alliance. El webinar estaba titulado «Camino hacia la agilidad: Una mirada integral» y constó de 3 oradores: Israel Alcázar, Ana Carmona y yo.
Israel fue el primero en presentar, su charla se tituló «Un enfoque integral para entender la agilidad». Luego fue mi turno. Finalmente fue el turno de Ana cuya charla se tituló «Cuando un equipo tiene que seguir siendo ágil». Creo que las 3 charlas estuvieron muy alineadas, primero Israel habló sobre cuestiones de transformación nivel organización/empresa. Luego yo hablé desde mi rol de XP coach trabajando con equipos de desarrollo. Finalmente Ana se centró en las situaciones que enfrenta un equipo luego del primer momento de transformación, cuando ya el equipo trabaja de forma autónoma sin la guía de un coach externo.
Luego de las tres charlas hubo un espacio de preguntas y respuestas. Toda la actividad estuvo moderada por Juan Banda.
A pesar de llevar más de un año de eventos online, no termino de acostumbrarme, sigo sintiendo como que estoy hablando al aire.
Continuando el aniversario de los 20 años del manifiesto ágil parece un buen momento para compartir algunas recomendaciones de libros.
El primero es la joya oculta de mi biblioteca: Planning Extreme Programming. Estoy seguro que mucha gente ni lo escuchó nombrar pero definitivamente vale una mirada aunque más no sea por sus autores: Kent Beck y Martin Fowler. A pesar de ser un libro de XP no es un libro de código, como su nombre lo indica es un libro de planificación que cubre también varias cuestiones de generales de gestión obviamente desde una perspectiva de XP. No es un libro reciente, es del año 2000, o sea que es previo a la publicación del manifiesto. Al igual que todos los libros la serie XP, el contenido está organizado en capítulos cortos, lo cual facilita la lectura.
Tengo dudas de incluir en este listado el libro The Art of Agile Development de Shore y Warden porque tengo la sesión que es un bastante conocido. Si bien no lo indica en el título, es un libro de XP. Fue publicado en 2007 y en estos días (marzo 2021) se está escribiendo en forma abierta la segunda edición la cual parece muy prometedora. El libro es excelente y es la referencia central de mi materia de Ingeniería de Software. Cubre muchísimas cuestiones que van desde mindset, pasando por temas de gestión y hasta cuestiones de código. Es en un libro de ingeniería de software al estilo XP.
Agile!: The Good, the Hype and the Ugly es un libro un tanto polémico para «los agilistas». Lo conocí gracias a mi amigo @dfontde. El autor del libro es Bertrand Meyer, un referente en el mundo académico de la ingeniería de software. El libro es tal cual lo que indica su título: lo bueno, lo feo y lo popular de agile. Personalmente no comparto algunas de las apreciaciones del autor y justamente por eso lo recomiendo. Resulta interesante leerlo porque Meyer es un referente que lleva muchos años en esta disciplina y que en cierto modo muchos lo asociamos a métodos más tradicionales/pre-agile. Un aporte interesante del libro es que para parte del análisis que hace de agile toma las 10 prácticas ágiles que considera más relevantes/representativas de agile.
Otro libro de un autor reconocido es More Effective Agile, este libro aún lo estoy leyendo, pero lo que llevo leído me pareció excelente. Es un libro reciente, fue publicado a mediados de 2019. Su autor es Steve McConnell, un reconocido autor de libros de ingeniería de software entre los que se encuentran Code Complete, Rapid Development y Software Estimation: Demystifying the Black Art. Hay dos cuestiones que me llevaron a leer este libro. Por un lado, ya había leído mucho material de McConnell (además de sus libros también tiene publicados muchos artículo interesantes) y quería saber su visión de agile. Por otro lado, al ser un libro reciente, me resultaba interesante averiguar qué hay para decir de agile a casi 20 años del manifiesto cuando ya se han publicado cientos de libros de agile. La visión de agile que ofrece McConnell la sentí muy afín con mis propias ideas. En esa visión McConnell desmistifica y corrige algunas falsas creencias (y argumentos de venta) de Agile.
En estos días se están cumpliendo 20 años de la publicación del manifiesto ágil. Mucha agua ha corrido bajo el puente.
Agile se volvió mainstream (¿hacia ~2010?).
Alguna gente llegó, probó y se fue (¿los menos?).
Otra gente llegó, se enamoró y ahora abraza árboles (¿demasiados?).
Están también los fundamentalistas, que incorporaron Agile a su vida y evangelizan con Agile a todo el que se cruza (¿coaches?).
Están también los pragmáticos no fundamentalista que ven los métodos ágiles como una herramienta útil para ciertos contextos pero que no dudan en dejar Agile de lado si ven un enfoque que calza mejor para el contexto (¿yo?)
Obviamente también hay gente que aún no llegó (¿llegarán algún día?).
Como dirían algunos amigos, también están los «vende humo» (como en todo negocio ¿no?)
Siempre que hay una moda, están los contra, en este caso los «anti-agile» que, en gran medida debido a los abrazadores de árboles y a los vende humo, creen que Agile es puro cuento y militan en su contra.
Sin duda podríamos seguir enumerando posiciones respecto a Agile, pero creo que con esto basta para exponer la situación.
El término «agile» a mi entender ha perdido un poco de significado, ha sido utilizado para referirse a cosas muy distintas, basta ver algunas conversaciones de twitter para confirmarlo.
Uno lee el manifiesto y en los primero años de los 2000, hablar de Agile es prácticamente XP, equipos chicos, autogestionados, que construyen software con excelencia técnica, tal como sugiere el manifiesto. Hacía el 2010 la situación cambia y Scrum toma el lugar de mayor popularidad. Nos inundan los post-its. Empezamos a ver equipos agile que no construyen software con excelencia técnica (Flaccid Scrum). Tiempo después aparecen los enfoques de escalamiento y todo el «Agile Industrial Complex» y los equipos casi que dejan de ser autogestionados y cierta burocracia renace. Esto da origen a un movimiento «revolucionario» de vuelta a las raíces y los enfoques de Modern Agile y Heart of Agile empiezan a cobrar relevancia en contraposición a las propuestas de escalamiento como SAFe.
En fin, realmente hay discusiones y usos de Agile que son de lo más diverso. Pero hay un hecho innegable: agile ha tenido un importante impacto en IT tanto a nivel industrial como académico. Y a mi parece ese impacto ha sido muy positivo.
Justamente con motivo de estos 20 años de Agile, estas semanas se han organizado diversos eventos relacionados a Agile. En mi caso estaré participando este viernes 12 de febrero en un conversatorio con formato fishbowl sobre DevOps. Este evento es organizado por la gente de RunRoom. La participación es gratuita pero requiere registración aquí.
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.
Blog de NicoPaez 