Construyendo una cultura ágil

La caída de la metodología de gestión de proyectos en cascada

Hace muchos años fui testigo de un proyecto de TI masivo en "cascada" para reemplazar una aplicación comercial completa. El proyecto tenía 3 años de retraso y millones por encima del presupuesto, y cuando finalmente se entregó, tanto los clientes internos como los externos rechazaron la solución. No habían sido parte del esfuerzo de ingeniería, tal vez los requisitos habían cambiado en los 5 años que tomó construirlo y, lo que es más importante, no habían visto el producto en absoluto hasta que estuvo listo.

Numerosas organizaciones compartieron la misma experiencia y, como resultado, comenzaron a adoptar la metodología ágil. El principio es simple, mostrar el progreso de forma incremental a medida que las funciones se codifican y se agregan progresivamente a la solución con el tiempo en las versiones. El diseño es fluido y no tiene que definirse completamente al comienzo del esfuerzo. Y, lo que es más importante, las partes interesadas pueden usar el software desde el principio y pueden proporcionar comentarios e influir en la configuración y la ingeniería de la solución antes de que esté completa. Agile es una metodología de gestión de proyectos, pero es más importante una filosofía y una cultura.

Agile también dio paso a la cultura DevOps, la antigua disputa entre los desarrolladores, que quieren llevar el software a producción antes de que esté completamente horneado, y los equipos de operaciones (Ops) que quieren preservar un entorno de producción estable con la menor cantidad de cambios posible. . Más que un problema de frecuencia de lanzamiento, el objetivo de DevOps también es terminar con el problema persistente de "Yo lo construí, tú lo ejecutas", que estaba causando que los equipos de operaciones fueran responsables de implementar y respaldar soluciones de software de las que tenían poco o ningún conocimiento. . DevOps no solo permite a los equipos de desarrollo crear e implementar soluciones rápidamente, sino que también pone en sus manos el soporte y la responsabilidad de guardia, lo que a su vez tiende a mejorar la calidad y la estabilidad del producto de software. Las canalizaciones de integración continua e implementación continua (CI/CD) han empujado la agilidad al extremo, cada compromiso de código ahora puede, en esencia, construirse, implementarse, probarse y eventualmente promoverse automáticamente a través de los entornos hasta la producción. Muchas grandes empresas de TI ahora están acostumbradas a varios cientos de implementaciones de producción por día, muy lejos de los viejos tiempos.

Mantener una "separación de tareas" también es importante para muchas organizaciones, nunca se debe permitir que un solo empleado descontento (o un desarrollador junior torpe) escriba código incorrecto y lo implemente hasta el entorno de producción. Como resultado, en muchos casos, los equipos de desarrollo no pueden implementar soluciones en la producción, los equipos de ingeniería de confiabilidad del sitio (SRE) actúan como "custodios de la producción" y también ofrecen alivio a los equipos de desarrollo asumiendo tareas de guardia si se proporciona la documentación de solución de problemas adecuada.

Junto con la cultura ágil y DevOps, el concepto de microservicios también ganó más popularidad, como lo describe la metodología de los doce factores . La idea no es nueva, la arquitectura orientada a servicios (SOA) también promovió muchos de los mismos conceptos, pero JSON y los avances de los lenguajes de programación modernos facilitaron mucho su aplicación. En lugar de crear enormes aplicaciones monolíticas, cada función distinta se puede dividir en su propio microservicio, que otras aplicaciones pueden reutilizar. Piense en ello como funciones disponibles a través de una llamada API. Para que este concepto funcione, los microservicios deben estar desacoplados e independientes entre sí. El concepto de microservicios, una función comercial distinta dentro de la solución general, también reforzó la noción de propiedad del producto, en oposición a la gestión del producto. Los equipos de DevOps son responsables de esa función comercial general de principio a fin, son dueños de esa solución y, como tal, se les otorga la libertad y la independencia para tomar decisiones, como las herramientas que se usarán y, a veces, los lenguajes de programación y los marcos que se usarán.

Entrega ágil y continua: la cultura de ingeniería de Spotify

Estos videos están un poco anticuados ahora, pero aún están bellamente ejecutados y siguen siendo muy relevantes para muchas empresas, tanto grandes como pequeñas.

La estructura organizativa de Spotify se hizo popular después de que Henrik Kniberg publicara un video que detalla el funcionamiento de la estructura interna de la empresa, que se divide en escuadrones, tribus y gremios.

Lecciones de Spotify: construir un negocio ágil. Las normas culturales de Spotify, descritas en sus videos de cultura de ingeniería (Parte 1 y Parte 2), mantienen fuerte la alineación del equipo. 

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Propiedad ágil del producto en pocas palabras

Otro gran video también de Henrik Kniberg.