Cómo planea Microsoft con DevOps

Microsoft es una de las empresas más grandes del mundo en utilizar metodologías Agile. A lo largo de muchos años de experiencia, Microsoft ha desarrollado un proceso de planeamiento de DevOps que abarca desde los proyectos más pequeños hasta iniciativas masivas como Windows. En este artículo se describen muchas de las lecciones aprendidas y las prácticas que Microsoft aplica a la hora de planear proyectos de software en toda la empresa.

Cambios en los instrumentos

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 enfoque de los individuos a los equipos.
• Crear nuevas estrategias de planeamiento y aprendizaje.
• Implantar un modelo de múltiples grupos.
• Mejorar las prácticas de salud del código.
• Fomentar la transparencia y la responsabilidad.

Promover la alineación cultural y la autonomía

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

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

• La alineación se produce de arriba abajo, para garantizar que las personas y los equipos comprendan cómo se alinean sus responsabilidades con los objetivos empresariales más amplios.
• La autonomía se produce de abajo arriba, para garantizar que las personas y los equipos influyan en las actividades y decisiones cotidianas.

Existe un delicado equilibrio entre alineación y autonomía. Demasiada alineación puede crear una referencia cultural negativa en la que las personas solo funcionan como se les dice. Demasiada autonomía puede provocar una falta de estructura o dirección, una toma de decisiones ineficaz y un planeamiento deficiente.

Cambiar el enfoque de los individuos a los equipos

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

• PM define qué construye Microsoft y por qué.
• Diseño se encarga de diseñar lo que construye Microsoft.
• Ingeniería construye los productos y garantiza la calidad de los mismos.

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

• Interdisciplinarios
• 10-12 personas
• Autogestión
• Carta y objetivos claros para 12-18 meses
• Salas físicas para equipos
• Implementación de características propias
• Características propias en la producción

Esfuerzo por crear equipos verticales

Los equipos de Microsoft solían ser horizontales y abarcaban toda la interfaz de usuario, todos los datos o todas las API. Actualmente, Microsoft se esfuerza por crear equipos verticales. Los equipos son dueños de sus áreas del producto de principio a fin. Las estrictas directrices en determinados niveles garantizan la uniformidad entre los equipos de todo el producto.

El diagrama a continuación conceptualiza la diferencia entre equipos horizontales y verticales:

Permitir la autoselección de equipos

Aproximadamente cada 18 meses, Microsoft lleva a cabo un "ejercicio de pegatina amarilla", en el que los desarrolladores pueden elegir en qué áreas del producto quieren trabajar durante los próximos dos periodos de planeamiento. Este ejercicio proporciona autonomía, ya que los equipos pueden elegir en qué trabajar, y alineación organizativa, ya que fomenta el equilibrio entre los equipos. Aproximadamente el 80 % de las personas que participan en este ejercicio permanecen en sus equipos actuales, pero se sienten empoderadas porque han podido elegir.

Crear nuevas estrategias de planeamiento y aprendizaje

Dwight Eisenhower dijo: "Los planes no valen nada, pero el planeamiento lo es todo". El planeamiento de Microsoft se divide en la siguiente estructura:

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

Los ingenieros y los equipos son los principales responsables de los periodos de trabajo y los planes. El liderazgo es el principal responsable de las temporadas y las estrategias.

El diagrama a continuación ilustra la estrategia de planeamiento de Microsoft:

La estructura de planeamiento también ayuda a maximizar el aprendizaje al mismo tiempo que se planea. Los equipos reciben información, averiguan lo que quieren los clientes y ponen en práctica sus pedidos con rapidez y eficacia.

Implantar un modelo de múltiples grupos

Los métodos anteriores fomentaban una "cultura de la interrupción" de los fallos y las incidencias del sitio web en directo. Los equipos de Microsoft idearon su propia forma de concentrarse y evitar distracciones. Los equipos se autoorganizan para cada etapa de trabajo en dos grupos diferenciados: Características (grupo F) y Cliente (grupo C).

El grupo F trabaja en las características previstas y el grupo C se ocupa de los problemas e interrupciones del sitio web en directo. El equipo establece una periodicidad de rotación que permite a los miembros planear las actividades con mayor facilidad. Para obtener más información sobre el modelo de múltiples grupos, consulte el apartado Creación de equipos productivos y centrados en el cliente.

Mejorar las prácticas de salud del código

Antes de adoptar metodologías Agile, los equipos solían dejar que los errores se acumularan hasta que el código estaba completo al final de la fase de desarrollo. A continuación, los equipos descubrían fallos y trabajaban para solucionarlos. Esta práctica creaba una montaña rusa de fallos que afectaba a la moral y la productividad de los equipos, que tenían que trabajar en la corrección de errores en lugar de implementar nuevas características.

En la actualidad, los equipos aplican un límite de errores que se calcula mediante la fórmula # of engineers x 5 = bug cap. Si el recuento de errores de un equipo supera el límite de al final de un sprint, deben dejar de trabajar en nuevas características y corregir errores hasta que estén por debajo del límite. Los equipos ahora pagan la deuda de errores a medida que avanzan.

Fomentar la transparencia y la responsabilidad

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

Objetivos y resultados clave (OKR)

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

• Objetivos definen los objetivos que se pretende alcanzar. Los objetivos son declaraciones de intenciones significativas, concretas, orientadas a la acción e, idealmente, inspiradoras. Los objetivos representan grandes ideas, no cifras concretas.
• Los Resultados clave definen los pasos para alcanzar los objetivos. Los resultados clave son resultados cuantificables que evalúan el progreso e indican el éxito respecto a los objetivos en un periodo de tiempo específico.

Los OKR reflejan los mejores resultados posibles, no solo los más probables. Los líderes tratan de ser ambiciosos y no precavidos. Impulsar a los equipos a perseguir resultados clave estimulantes fomenta la aceleración con respecto a los objetivos y prioriza el trabajo que avanza hacia metas más amplias.

Adoptar un marco de OKR puede ayudar a los equipos a rendir mejor por los siguientes motivos:

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

Los OKR pueden existir en los distintos niveles de un producto. Por ejemplo, puede haber OKR de producto a nivel superior, OKR a nivel de componentes y OKR a nivel de equipo. Mantener los OKR alineados es relativamente fácil, especialmente si los objetivos se establecen de arriba abajo. Cualquier conflicto que surja es un valioso indicador precoz de desajuste organizativo.

Ejemplo de OKR

Objetivo: conseguir una base de clientes sólida y satisfecha.

Resultados clave:

• Aumentar la puntuación del promotor neto (NPS) externo de 21 a 35.
• Aumentar la satisfacción de los documentos de 55 a 65.
• El nuevo flujo de distribución tiene una puntuación de Apdex de 0,9.
• El tiempo de espera de los trabajos es de 5 segundos o menos.

Para obtener más información acerca de los OKR, consulte el apartado Medir los resultados empresariales mediante objetivos y resultados clave.

Seleccionar las métricas adecuadas

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

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

Los equipos evitan las métricas que no aportan valor a los objetivos. Aunque puedan tener ciertos usos, las siguientes métricas no son útiles para seguir el progreso hacia los objetivos:

• Estimaciones originales precisas
• Horas completadas
• Líneas de código
• Capacidad del equipo
• Evolución del equipo
• Progreso del equipo
• Número de errores detectados
• Cobertura de código

Antes y después de la implantación de la cultura Agile

La tabla a continuación resume los cambios que realizaron los equipos de desarrollo de Microsoft al adoptar las prácticas Agile.

Antes	Después
Hitos de 4 a 6 meses	Sprints de 3 semanas
Equipos horizontales	Equipos verticales
Despachos personales	Salas para equipos y trabajo a distancia
Ciclos de planeamiento largos	Planeamiento y aprendizaje continuos
PM, desarrollo y pruebas	PM, diseño e ingeniería
Compromiso anual con los clientes	Compromiso continuo con los clientes
Ramas de características	Todo el mundo trabaja en la sede central
Equipos de más de 20 personas	Equipos de 8 a 12 personas
Plan de trabajo secreto	Plan de trabajo compartido públicamente
Deuda de errores	Deuda cero
Documentos de 100 páginas	Especificaciones de PowerPoint
Los repositorios privados	Código abierto/código interno
Jerarquía organizativa profunda	Jerarquía organizativa plana
Las cifras de instalación marcan el éxito	La satisfacción de los usuarios marca el éxito
Envío de características una vez al año	Envío de características en cada sprint

Puntos clave

• Tómese en serio la ciencia Agile, pero no sea excesivamente prescriptivo. Agile puede llegar a ser demasiado estricto. Deje que crezcan la mentalidad y la cultura Agile.
• Celebre los resultados, no la actividad. La implantación de la funcionalidad pesa más que las líneas de código.
• Realice envíos en cada sprint para establecer un ritmo y una cadencia y encontrar todo el trabajo que haya que hacer.
• Construya la cultura que desea para obtener el comportamiento que busca.