El Standish Group es una organización de investigación con sede en Boston, cuyo foco principal es el desempeño del desarrollo de software. Periódicamente publican resultados de investigaciones analizando el desempeño de miles de proyectos de desarrollo de software a nivel mundial. Tomando como referencia algunos de los resultados del estudio publicado en el informe “Decision Latency Theory: It’s all about the Interval”, queremos contrastarlos con nuestra propia experiencia en la implementación de proyectos Devops.
1. La mano ganadora
El concepto de “mano ganadora” o “winning hand” fue introducido por primera vez en el Chaos Report de 2016, e identifica las características más relevantes que están presentes en los proyectos de software que han sido exitosos.
En primer lugar, debemos definir el concepto de “proyecto exitoso”.
Este concepto ha evolucionado continuamente a través de los años, y para el Standish Group, la definición actual de un proyecto exitoso, contempla tres características:
- El proyecto fue terminado dentro de los tiempos estimados.
- El proyecto fue terminado dentro del presupuesto estimado
- Los clientes y usuarios del proyecto quedaron satisfechos con el resultado, independientemente del alcance inicial identificado. Llama la atención este aspecto, que no se alinea con la “triple restricción” que ha sido tradicional como criterio de éxito de los proyectos de software.
Cuando hablamos de proyectos terminados con dificultades, nos referimos a proyectos que han terminado tarde, fuera del presupuesto y/o con baja satisfacción del cliente, mientras que un proyecto fallido es un proyecto que se canceló antes de terminar, o se terminó, pero no se usó.
Volviendo a la mano ganadora, ésta se compone de cinco cartas:
-
El proyecto necesita ser pequeño.
- Para el Standish Group, un proyecto pequeño debería tener un equipo de máximo de 6 miembros, y una duración de seis meses o menos.
De acuerdo a los resultados publicados en el informe, de los proyectos analizados, el 57% de los proyectos pequeños fue exitoso, mientras que sólo el 10% de los proyectos más grandes tuvo éxito.
En nuestro caso, cuando implementamos Devops, generalmente conceptualizamos un proyecto pequeño, tanto en las prácticas involucradas como en el número de aplicaciones incluidas. Posteriormente y cuando se alcance un resultado satisfactorio para el cliente, realizamos un proceso de masificación en las aplicaciones restantes y a la vez vamos ampliando progresivamente el alcance de las prácticas de Devops.
El hecho de implementar progresivamente las prácticas Devops ha sido de vital importancia, dado que generalmente implementamos en aplicaciones o proyectos que están en curso, y no podemos impactar sus compromisos. En caso contrario, es decir, cuando implementamos en aplicaciones que no están en cambio permanente, los resultados no generan el mismo nivel de satisfacción en nuestros clientes, a pesar que se logre el resultado planeado en cuanto a alcance, tiempo y costos.
-
El Product Owner o Sponsor debe estar altamente calificado.
- Para el Standish Group, la calidad del sponsor es un factor crítico en el éxito de un proyecto. Un buen sponsor debe inspirar a su equipo, trabajar duro, ser creativo y tomar decisiones rápidamente. Dentro de la investigación se establece que no es para nada aconsejable que un comité actúe como sponsor, pues esto incrementa el tiempo de toma de decisiones y el riesgo de que algunas decisiones puedan ser reversadas.
Según el estudio, el 48% de los proyectos exitosos contaba con un sponsor calificado, mientras que apenas el 18% de los proyectos exitosos no contaba con buenos sponsors.
Además de las características enunciadas anteriormente, uno de los aspectos bien importantes en cuanto al Sponsor en proyectos Devops es que esté alineado permanentemente con el objetivo por el que se está implementando Devops. Recordemos que Devops nos habilita para entregar software más rápido y con mayor calidad, para entregar valor más rápidamente al negocio.
Entonces, un proyecto Devops debe estar enfocado precisamente en resolver de forma prioritaria aquellos dolores que nos impiden entregar el software más rápido y con mayor calidad a nuestros usuarios finales. Lo demás es accesorio. Por eso es tan importante que el Sponsor esté alineado claramente con este objetivo, pues por el camino pueden surgir los famosos “ya-que” y en proyectos Devops, sí que aparecen (suena familiar?). Todo el equipo debe estar alineado con este objetivo y el Sponsor juega un papel fundamental en este tema.
-
El proyecto debe ser ágil (aplicar una metodología ágil)
- Conocemos todas las bondades de las metodologías ágiles. Sin embargo, el efecto más importante considerado en este caso es la habilidad para tomar decisiones rápidamente. Muchos de los equipos ágiles analizados son autogestionados, lo que permite mantener el proceso de decisión dentro del mismo equipo y los escalamientos no son frecuentes.
El efecto de usar una metodología ágil en los proyectos se ve reflejado en el 48% de proyectos exitosos, mientras que sólo el 26% de proyectos exitosos no seguía un proceso ágil.
En cuanto a los proyectos Devops, es fundamental implementarlos de forma ágil, pues en cada sprint estamos incorporando o mejorando prácticas en el equipo de desarrollo, permitiendo que el equipo a su vez nos pueda retroalimentar lo antes posible sobre si las prácticas implementadas están siendo efectivas o no, a la luz del objetivo de Devops.
Por otro lado, y dada la dinámica de una organización de desarrollo de software, las prioridades cambian todo el tiempo, y es ahí donde una metodología ágil es lo suficientemente flexible para poder hacer cambios en el alcance del proyecto Devops, sin alejarnos del objetivo. En caso contrario, podríamos estar empleando tiempo valioso del proyecto en tramitar cambios de alcance permanentemente.
Hemos encontrado también que los proyectos cuyo objetivo es definir y detallar un modelo de gobierno devops, presentan dificultades a la hora de implementarlos. Esto es explicable en la medida en que no es fácil identificar las necesidades de un equipo de desarrollo y plasmarlas en un documento, sin validarlas en la práctica. Es como querer identificar y detallar todos los requerimientos de un sistema para luego empezar a construirlo, y está demostrado que eso ya no es tan conveniente.
-
Equipos entrenados
- Un factor clave para el éxito del proyecto es contar con los skills que éste demanda. Un equipo sin los skills necesarios batallará todo el tiempo. Más aún, teniendo en cuenta que en los equipos pequeños, que es otro de los componentes de la mano ganadora, cada integrante debe realizar varias tareas, para las que debe estar entrenado, en la idea de ser eficiente.
El estudio muestra que el 33% de los proyectos exitosos contaba con un equipo entrenado, mientras que sólo el 20% de los proyectos exitosos no tenía un equipo entrenado.
Para nuestro caso, podemos analizar varios temas: si en un proyecto de desarrollo se incluye dentro del alcance la implementación de Devops, y el equipo no está suficientemente bien entrenado, lo más probable es que se deje de lado el tema de Devops para cumplir con los objetivos del desarrollo, lo cual es absolutamente comprensible, pues el equipo hará más rápido lo que sabe hacer, es decir, no incorporará nuevas prácticas dentro del proyecto, para poder cumplir con los objetivos de desarrollo.
Por el contrario, cuando el equipo Devops es independiente del proyecto y está suficientemente bien entrenado, no solamente cumplirá con los objetivos de Devops sino que apoyará a los equipos de desarrollo y operaciones incorporando prácticas más eficientes.
Por otra parte, y es uno de los factores que en nuestro caso ha sido muy valorado por nuestros clientes es la experiencia en proyectos similares. Además del entrenamiento, la participación previa de nuestros consultores en proyectos Devops nos ha permitido evitarle a nuestros clientes la experimentación, pues es bien sabido que cada tecnología es diferente y cada aplicación es diferente. Por lo tanto, entre más implementaciones de devops tenga el equipo del proyecto, mejor será el resultado.
-
Madurez Emocional
- Se ha demostrado que un equipo emocionalmente maduro trabaja de forma ordenada y es altamente productivo. Estudios realizados previamente por el mismo Standish Group, concluyen que buena parte de los problemas en los proyectos tienen que ver con el comportamiento humano, o lo que generalmente llamamos “soft skills”. Dentro de estos aspectos se incluye el manejo de expectativas, la habilidad para construir consenso, influenciar positivamente, entre muchos otros.
El 42% de los proyectos exitosos tenía un equipo emocionalmente maduro, mientras que tan sólo 14% de los proyectos exitosos no lo tenía.
En nuestro caso, la madurez emocional está también directamente relacionada con la experiencia del equipo. A mayor experiencia del equipo en proyectos similares, estará más preparado emocionalmente para manejar situaciones no planeadas o imprevistos, que siempre aparecen. En un proyecto de este tipo, se requiere especialmente de estas habilidades para poder apoyar al equipo de desarrollo en el cumplimiento de sus propios objetivos.
Resultados combinando las características de la mano ganadora
Para concluir el tema de la “mano ganadora”, el informe presenta el resultado de los proyectos, combinando el efecto de todas las cartas de la mano ganadora. Presentamos el resultado del estudio, combinando las 5 características descritas anteriormente:
El informe analiza un total de 25.000 proyectos, ejecutados entre 2013 y 2017.
En la segunda parte de este artículo presentaremos los factores de éxito de los proyectos exitosos, que también está incluido en el informe del Standish Group.
Referencias
Decision Latency Theory: It Is All About the Interval
Jim Johnson
CHAOS Report Series – Standish Group – 2018
