Cómo planea Microsoft con DevOps

Microsoft es una de las empresas más grandes del mundo para usar metodologías ágiles. A lo largo de años de experiencia, Microsoft ha desarrollado un proceso de planeación de DevOps que se escala a partir de los proyectos más pequeños a través de esfuerzos masivos como Windows. En este artículo se describen muchas de las lecciones aprendidas y prácticas que Microsoft implementa al planear proyectos de software en toda la empresa.

Cambios instrumentales

Los siguientes cambios clave ayudan a que los ciclos de desarrollo y envío sean más saludables y eficientes:

• Promover la alineación cultural y la autonomía.
• Cambiar el foco de los individuos a los equipos.
• Crear nuevas estrategias de planeamiento y aprendizaje.
• Implemente un modelo de varias tripulaciones.
• Mejorar las prácticas de salud del código.
• Fomentar la transparencia y la rendición de cuentas.

Promover la alineación cultural y la autonomía

Peter Drucker dijo: "La cultura come estrategia para el desayuno". La autonomía, el dominio y el propósito son motivaciones humanas clave. Microsoft intenta proporcionar estos motivadores a PMs, desarrolladores y diseñadores para que se sientan capacitados para crear productos exitosos.

Dos colaboradores importantes para este enfoque son la alineación y la autonomía.

• La alineación procede de la parte superior hacia abajo para asegurarse de que las personas y los equipos comprendan cómo se alinean sus responsabilidades con objetivos empresariales más amplios.
• La autonomía se produce desde abajo hacia arriba, para garantizar que las personas y los equipos tengan un impacto en las actividades y decisiones diarias.

Hay un delicado equilibrio entre alineación y autonomía. Demasiada conformidad puede crear una cultura negativa en la que las personas solo actúan como se les dice. Demasiada autonomía puede provocar una falta de estructura o dirección, una toma de decisiones ineficaz y una planificación deficiente.

Cambio del enfoque de individuos a equipos

Microsoft organiza a personas y equipos en tres grupos: PM, diseño e ingeniería.

• PM define qué desarrolla Microsoft y por qué.
• El diseño es responsable de diseñar lo que Microsoft crea.
• La ingeniería construye los productos y garantiza su calidad.

Los equipos de Microsoft tienen las siguientes características clave:

• Interdisciplinario
• 10-12 personas
• Autoadministración
• Carta clara y metas para 12-18 meses
• Salas físicas para equipos
• Despliegue de funcionalidades propias
• Características propias en producción

Buscar equipos verticales

Los equipos de Microsoft solían ser horizontales, abarcando toda la interfaz de usuario, todos los datos o todas las API. Ahora, Microsoft se esfuerza por los equipos verticales. Los equipos poseen sus áreas del producto de principio a fin. Las directrices estrictas en determinados niveles garantizan la uniformidad entre los equipos del producto.

En el diagrama siguiente se conceptualiza la diferencia entre los equipos horizontales y verticales:

Permitir equipos de autoselección

Aproximadamente cada 18 meses, Microsoft ejecuta un "ejercicio de palo amarillo", donde los desarrolladores pueden elegir en qué áreas del producto quieren trabajar para el siguiente par de períodos de planificación. Este ejercicio proporciona autonomía, ya que los equipos pueden elegir en qué trabajar y la alineación organizativa, ya que promueve el equilibrio entre los equipos. Alrededor del 80% de las personas de este ejercicio permanecen en sus equipos actuales, pero se sienten empoderados porque tenían la opción.

Creación de nuevas estrategias de planeamiento y aprendizaje

Dwight Eisenhower dijo: "Los planes no tienen valor, pero la planificación lo es todo". La planificación de Microsoft se divide en la estructura siguiente:

• Sprints (3 semanas)
• Planes (3 sprints)
• Temporadas (6 meses)
• Estrategias (12 meses)

Los ingenieros y equipos son principalmente responsables de los sprints y los planes. El liderazgo es principalmente responsable de las temporadas y las estrategias.

En el diagrama siguiente se muestra la estrategia de planeamiento de Microsoft:

Esta estructura de planeación también ayuda a maximizar el aprendizaje mientras se realiza la planificación. Los equipos pueden recibir comentarios, averiguar qué quieren los clientes e implementar las solicitudes de los clientes de forma rápida y eficaz.

Implementación de un modelo de varias tripulaciones

Los métodos anteriores fomentaron una "cultura de interrupciones" de errores e incidentes en sitios en producción. Los equipos de Microsoft llegaron con su propia manera de proporcionar foco y evitar distracciones. Los equipos se autoorganizan para cada sprint en dos equipos distintos: Features (F-crew) y Customer (C-crew).

El equipo F trabaja en características comprometidas, y el equipo C se ocupa de problemas e interrupciones en el sitio en producción. El equipo establece una cadencia rotativa que permite a los miembros planear actividades más fácilmente. Para obtener más información sobre el modelo de varias tripulaciones, consulte Creación de equipos productivos y centrados en el cliente.

Mejora de las prácticas de salud del código

Antes de cambiar a metodologías ágiles, los equipos solían permitir que los errores de código se compilaran hasta que el código estuviera completo al final de la fase de desarrollo. A continuación, Teams detectó errores y ha trabajado en corregirlos. Esta práctica creó una montaña rusa de errores, que afectaba a la moral y la productividad del equipo cuando los equipos tenían que trabajar en correcciones de errores en lugar de implementar nuevas características.

Teams ahora implementa un límite de errores, calculado por la fórmula # of engineers x 5 = bug cap. Si el recuento de errores de un equipo supera el límite de errores al final de un sprint, debe dejar de trabajar en nuevas características y corregir errores hasta que estén por debajo de su límite. Los equipos ahora pagan la deuda de errores a medida que van.

Fomentar la transparencia y la rendición de cuentas

Al final de cada sprint, cada equipo envía un correo que informa de lo que ha logrado en el sprint anterior y lo que planea hacer en el siguiente sprint.

Objetivos y resultados clave (OKR)

Los equipos son más eficaces cuando están claros en los objetivos que la organización está intentando lograr. Microsoft proporciona claridad a los equipos a través de objetivos y resultados clave (OKR).

• Los objetivos definen los objetivos que se van a lograr. Los objetivos son declaraciones significativas, concretas, orientadas a la acción e idealmente inspiradoras. Los objetivos representan grandes ideas, no números reales.
• Los resultados clave definen los pasos para lograr los objetivos. Los resultados clave son resultados cuantificables que evalúan el progreso e indican el éxito con respecto a los objetivos en un período de tiempo específico.

Los OKR reflejan los mejores resultados posibles, no solo los resultados más probables. Los líderes intentan ser ambiciosos y no cautelosos. Impulsar a los equipos a perseguir desafiantes resultados clave acelera el avance hacia los objetivos y prioriza el trabajo que avanza hacia metas más grandes.

La adopción de un marco de OKR puede ayudar a los equipos a mejorar por los siguientes motivos:

• Cada equipo está alineado con el plan.
• Los equipos se centran en lograr resultados en lugar de completar actividades.
• Cada equipo es responsable de los esfuerzos de forma periódica.

Los OKR pueden existir en distintos niveles de un producto. Por ejemplo, puede haber OKR de producto de nivel superior, OKR de nivel de componente y OKR de nivel de equipo. Mantener los OKR alineados es relativamente fácil, especialmente si los objetivos se establecen de arriba abajo. Los conflictos que surjan son indicadores tempranos valiosos de la desalineación organizativa.

Ejemplo de OKR

Objetivo: Aumentar una base de clientes fuerte y feliz.

Resultados clave:

• Incrementar la puntuación del índice de promotor neto externo (NPS) de 21 a 35.
• Aumentar la satisfacción relacionada con los documentos del 55 al 65.
• El nuevo flujo de canalización tiene una puntuación de Apdex de 0,9.
• El tiempo de cola de los trabajos es de 5 segundos o menos.

Para obtener más información sobre los OKR, consulte Medición de los resultados empresariales mediante objetivos y resultados clave.

Selección de las métricas correctas

Los resultados clave solo son tan útiles como las métricas en las que se basan. Microsoft usa indicadores iniciales que se centran en el cambio. Con el tiempo, estas métricas crean una imagen funcional de aceleración o desaceleración del producto. Microsoft suele usar las métricas siguientes:

• Cambio en la tasa de crecimiento mensual de la adopción
• Cambio en el rendimiento
• Cambio en el tiempo para aprender
• Cambio en la frecuencia de incidentes

Equipos evitan las métricas que no aportan valor hacia los objetivos. Aunque pueden tener ciertos usos, las métricas siguientes no son útiles para realizar el seguimiento del progreso hacia los objetivos:

• Precisión de las estimaciones originales
• Horas completadas
• Líneas de código
• Capacidad del equipo
• Agotamiento del equipo
• Velocidad del equipo
• Número de errores encontrados
• Cobertura de código

Antes de Agile y después de Agile

En la tabla siguiente se resumen los cambios realizados por los equipos de desarrollo de Microsoft a medida que adoptaron prácticas ágiles.

Conclusiones clave

• Tome la ciencia ágil en serio, pero no sea demasiado prescriptiva. Agile puede ser demasiado estricto. Deje que la mentalidad y la cultura ágil crezcan.
• Celebra los resultados, no la actividad. La implementación de la funcionalidad supera las líneas de código.
• Envía en cada sprint para establecer un ritmo y cadencia y encontrar todo el trabajo que debe realizarse.
• Construya la cultura que desea para lograr el comportamiento que busca.