Mi experiencia en 233 implantando Testing Ágil y DevOps en varias empresas

Estas últimas semanas he estado escribiendo sobre cosas más técnicas, sobre todo enfocado a Testing Ágil y DevOps (más a Testing Ágil, ya sabéis, sobre TDD con NodeJS, sobre Xamarín, etc.), debido a que en los últimos proyectos en los que he estado son términos de los que se ha hablado mucho.
Hoy voy a escribir para contar mi experiencia en 233 Grados de TI en proyectos en los que he participado sobre implantación, no solo de agilidad, sino de Testing Ágil y DevOps (aquí podéis ver con quién hemos trabajado).
Hará ya alrededor de 2 años que colaboro con Javier (@jgarzas) en diferentes proyectos de mentoring y formación, sobre agilidad, equipos, y últimamente mucho Testing Ágil y DevOps.
En algún proyecto en los que me he embarcado, me han dicho y preguntado, -María yo quiero ser DevOps, nosotros (la empresa), queremos ser DevOps, ¿cómo podemos conseguirlo?-.
En el post de hoy quiero compartir mi experiencia, como decía antes, y alguno de los impedimentos más importantes que yo he visto y me he encontrado a la hora de implantar estas prácticas en grandes organizaciones, te los cuento…

Confusión o desconocimiento de los términos

Uno de los principales problemas viene de la terminología, de su significado o el contexto, como decía antes, me comentaban -“yo quiero ser DevOps y rápido”-. Mi respuesta era, no se puede ser DevOps, no hay un rol específico con perfiles específicos de DevOps y tampoco es algo que sea rápido y se consiga de un día para otro.
Por lo que ya sabréis (ya que se ha hablado varias veces en el blog), DevOps es una tendencia en la que desarrollo y operaciones colaboran en un mismo equipo para asegurar que los cambios en el software se ejecutan lo más rápidamente posible y con el mínimo de problemas.
Además no es algo que se consiga con facilidad, hay muchos impedimentos que no dejan trabajar siguiendo la filosofía DevOps, en un mes, ya querían ver resultados, y claro, teniendo en cuenta los impedimentos que nos encontrábamos (los siguientes puntos), un mes no era realista.
Si buscas una persona con perfil DevOps, error, lo que necesitamos es equipos trabajen en conjunto para conseguirlo, no solo una persona.
Organizaciones como Quora trabaja de esta manera y consiguen muchos pasos a producción incluso al día (te dejo aquí un post por si quieres saber más sobre este caso).

Visión de equipos orientada a departamentos

Otro gran impedimento y de lo que hemos hablado mucho, son los equipos, el peopleware (aprovecho para decir que todavía puedes mandar tu ponencia para la #PAM2016).
Como ya adelantaba, la visón de equipo orientada a departamentos, es una visión que me he encontrado siempre, en la que para pasar a producción tenía que haber mucha comunicación entre departamentos (lo que se perdía tiempo para el paso a producción), aceptar la versión a pasar a producción… Un jaleo! Que os voy a contar…
Lo que yo me he encontrado, no solo equipos en departamentos separados, si no equipos de desarrollo en un edificio incluso otra empresa, Testing externalizado, la parte de sistemas en la otra punta… Vamos lo idóneo eh… Creo que esto ya nos lo sabemos todo…
Además, en proyectos ya en desarrollo, implantar el Testing Ágil ni pensarlo, directamente llamar a un tercero y “quitarse ellos el marrón del Testing” hablando rápido, es decir, externalizarlo, llamar a las Testing Factores de turno.
Otros impedimentos que he visto a la hora de implantar el Testing Ágil es por parte de negocio, ¡cómo a aprender un lenguaje en el que hacer las historias de usuario (Gherkin)!, o testers aprender a programar, ya que eran los testers de toda la vida (de la vieja escuela), de darle a la tecla.
Al final implantar todo esto lleva tiempo y sobre todo ganas y motivación por parte de todo el equipo, algo que en alguna ocasión no he visto, sino que todo esto se ha visto como más trabajo además del que ya tenían. Pero he decir que también me he encontrado proyectos en los que la actitud y las ganas de llevar a cabo estas prácticas era muy buenas y a día de hoy están con ello.
Como siempre decimos, tenemos que tener equipos multifuncionales, es decir, en un mismo equipo todas las competencias necesarias para poder sacar el proyecto adelante y poner en producción en un solo commit  (¿qué pasa si pasamos de externalizar el Testing a integrarlo en los equipos?).

Tener equipos multifuncionales conlleva reducir (que en todos los lados que he estado hay) los rambos, o héroes apaga fuegos, aquellas personas que solo ellas saben arreglar una línea de código y pasa algo en producción, por ejemplo.
Antes de pasar al siguiente punto, os dejo aquí un vídeo sobre las 5 características de un equipo de alto rendimiento, muy interesante, os recomiendo verlo.

Burocracia y sobre documentación

El nivel organizativo en las empresas en las que he estado es realmente jerárquico, tal que para poder aceptar una propuesta, tenía que pasar hasta por 5 personas/niveles, una cantidad de papeleo, tramitación increíble.
Esto es realmente restrictivo y conlleva un alto coste para la agilidad, DevOps, etc. Muchas de las propuestas de cambio, debido a esto, son rechazadas, o muchos periodos de tiempo para elección de herramientas entornos, etc.
Otra cosa que siempre me han preguntado mucho es acerca de la documentación. Si hacemos Testing Ágil, las historias de usuario escritas en Gherkin, que contienen los criterios de aceptación, nos vale como documentación, es lo que llamamos documentación viva ya que luego se va a poder ejecutar.
En los proyectos en los que he estado, todos al final me preguntaban o acababan haciendo un documento adicional detallando lo que creían necesario (que en la mayoría de los casos acababan siendo guías). Para que esto no sucediera, yo siempre contaba el método ACC un caso de estudio de James Witaker.
Esto es algo realmente difícil de cambiar en una organización que trabaja en cascada, en la que todo es documentación en casi todas las fases (os dejo aquí un post taller de desintoxicación documental).

Para terminar…

Supongo que al leer este post, os sentiréis, en mayor o menor medida, identificados con muchos de los impedimentos que os he ido contando (ya hablaré de alguno más como las reuniones interminables…).
Si queréis podéis compartirlo conmigo en los comentarios, vuestras experiencias, casos similares, compartir que no estamos solos en el mundo con estos problemas, y aportar a la comunidad un granito de arena para intentar ayudar al mundo del software a cambiar esto.