El análisis de datos es la base para una mejor planificación ágil.

Planificación ágilPor su naturaleza, es rápido y adaptable, con margen para realizar cambios según sea necesario. Sin embargo, un proceso diseñado para ser flexible también puede verse influenciado por factores subjetivos, como la percepción del propio equipo ágil sobre qué historias de usuario deben tener prioridad.

La verdadera objetividad en la planificación ágil solo se consigue mediante el uso de datos y análisis. Los datos revelan la realidad de lo que ocurre en los procesos y cuál es el resultado real de los mismos. DevOps El trabajo lo es. Los datos nos indican qué características e historias tienen valor y lo aportan, por ejemplo, mejorando la usabilidad o aumentando los ingresos. Los datos son la herramienta que se utiliza para distinguir los resultados cuantificables de las suposiciones.

Sin datos, puede existir una desconexión entre el trabajo realizado y si genera un impacto positivo en los usuarios y contribuye al logro de los objetivos comerciales prioritarios. La falta de datos incluso puede llevar a que las prioridades se establezcan de forma arbitraria. Sin embargo, una vez que se dispone de datos, las partes interesadas de toda la organización —no solo de los equipos de desarrollo— pueden determinar científicamente las respuestas a estas importantes preguntas:

1. ¿Qué características son las más importantes para nuestros usuarios?
2. ¿Cómo podemos mejorar nuestros procesos?
3. ¿Estamos ofreciendo el máximo valor de la manera más eficiente?

La retroalimentación de datos guía la visión y elimina la naturaleza a veces arbitraria del proceso de toma de decisiones.

Aquí hay varios ejemplos de cómo se puede utilizar el análisis de datos para mejorar la planificación ágil y orientarla hacia mejores resultados que produzcan valor concreto:

• Priorizar historias de usuario
• Utilizar la retroalimentación de datos para fundamentar la planificación de lanzamientos
• Evaluación del rendimiento en sprints
• Identificar oportunidades para optimizar los procesos
• Adaptarse rápidamente para responder a las necesidades cambiantes del mercado
• Determinar las nuevas características que necesitan los clientes

Priorizar las historias de usuario en función de los resultados comerciales previstos

Es importante evaluar todas las opiniones. El valor que las oportunidades de cocreación pueden derivar de objetivos comerciales, como los ingresos o los lanzamientos de productos, también puede provenir de las opiniones pasivas y activas de los usuarios o clientes.

• retroalimentación pasiva Incluye métricas como el uso activo diario de ciertas funciones y los informes de errores de usuario.
• Comentarios activos Incluye encuestas, quejas de usuarios y solicitudes.

Aprovechar los datos de esta retroalimentación permite obtener una medida objetiva de qué historias de usuario tienen el potencial de generar el mayor impacto. Por ejemplo, una combinación de métricas de usuario y comentarios de los clientes puede identificar ciertas tareas de la plataforma que experimentan una alta latencia y que se correlacionan con el abandono del sitio. Esto representa una oportunidad para abordar la latencia, reducir el abandono y mejorar la experiencia del cliente.

Tenga en cuenta que muchos métodos comunes de priorización de historias de usuario son subjetivos, como por ejemplo: Moscú y póker prioritarioAdemás, muchas decisiones importantes quedan a discreción del propietario del producto o de los equipos ágiles. Si bien pueden tener buenas intenciones, si toman decisiones sin datos, siguen siendo meras suposiciones. La intuición no puede ser la única guía para los líderes de Scrum, quienes buscan priorizar las historias que aporten mayor beneficio. Consideraciones internas, como el tiempo de implementación, también pueden desviar a los equipos de Scrum de priorizar las historias que ofrecen mayor valor.

Utilizar los datos de retroalimentación del servicio, las pruebas, la seguridad y las operaciones para fundamentar la planificación de lanzamientos.

Aplicar analíticas de otros dominios es similar al caso de uso anterior de priorizar historias de usuario, pero a mayor escala en la planificación de lanzamientos. Agile y DevOps Los equipos necesitan retroalimentación de datos de servicio, pruebas, seguridad y operaciones. Recabar esta retroalimentación puede ayudar a establecer prioridades importantes en su planificación de lanzamientos. No basta con perseguir las funcionalidades más atractivas; es necesario contar con datos que respalden las decisiones.

La retroalimentación de datos es un paso crítico de DevOps. Es parte de la diagrama de figura ochoSin embargo, puede pasar desapercibido. Rara vez se le indica al equipo de desarrollo que ajuste sus prácticas o prioridades basándose únicamente en la retroalimentación de operaciones. No obstante, esta retroalimentación puede ser vital para generar mayor valor en todas las etapas del trabajo. Los datos pueden revelar cambios críticos en los productos y adelantar elementos importantes en el calendario de lanzamientos.

Por ejemplo, los informes sobre vulnerabilidades en las pruebas de seguridad significan que se deben realizar esfuerzos para subsanar las deficiencias en la protección.

De manera similar, los informes de operaciones generados a partir de análisis que miden el riesgo del cambio Puede informar a los equipos de desarrollo sobre prácticas que generan defectos o incluso incidentes. Los líderes de desarrollo pueden aprovechar los datos de todos los sistemas clave de registro para identificar y abordar prácticas, equipos, individuos o correlaciones de mejora continua que se convierten en fuentes de riesgo en los cambios.

Evaluación del rendimiento del sprint y los resultados del negocio

Muchos equipos ágiles se orientan hacia los resultados previstos, pero no siempre se mide el resultado real. La evaluación del desempeño debería ser introspectiva, en lugar de considerarse una forma de castigar el mal desempeño. Los equipos pueden preguntarse: "¿Qué salió bien?" y "¿Qué se puede mejorar?", en lugar de simplemente: "¿Qué salió mal?".

Un buen ejemplo de herramienta de evaluación es un gráfico de burndownEste gráfico muestra el progreso del trabajo dentro del sprint, basado en hitos. Estos breves bloques de trabajo incluyen objetivos específicos que deben completarse durante el sprint, y el tiempo necesario para lograr cada hito se registra visualmente, donde los tiempos más cortos se representan como "pasos" más cortos en el gráfico.

En general, al analizar los resultados del sprint finalizado, se puede determinar si el rendimiento es bueno o malo según si se alcanzaron o no los objetivos. Sin embargo, un análisis más detallado del gráfico de trabajo pendiente (burndown chart) revela una perspectiva más compleja. Finalizar un sprint antes de tiempo permite ampliar el trabajo entre los hitos, mientras que incumplir los plazos puede indicar que se asumió demasiado trabajo. Los gráficos de trabajo pendiente con incrementos pronunciados pueden indicar que el trabajo no se dividió en suficientes partes. Estos datos son útiles y pueden ayudar a planificar un sprint más eficaz.

Los objetivos de equipo también son clave para el éxito. Los equipos autónomos no solo mejoran la productividad, sino que también fomentan un mayor compromiso de los empleados.

Como titular de McKinsey & Company El artículo señala: “Las organizaciones ágiles exitosas se centran en el rendimiento del equipo al establecer objetivos y evaluar el desempeño, permitiendo a menudo que los equipos definan sus propios objetivos para fomentar la responsabilidad”.

Analizar los procesos en busca de oportunidades para optimizar

Las organizaciones necesitan comprender el flujo de trabajo, así como el flujo de valor a través de las distintas etapas. El análisis de esta visualización del flujo de valor revelará oportunidades para mejorar los procesos.

Un ejemplo de capacidad se logra comparando el tiempo total de entrega/ciclo con el tiempo dedicado a etapas específicas de DevOpsDeterminar el tiempo de flujo permite identificar las etapas intermedias del trabajo en las que una versión permanece incompleta, a la espera de aprobación o en un estado de espera durante las transferencias entre equipos. Algunas preguntas que se pueden formular son:

• ¿Cómo podemos eliminar estos “puntos muertos”?
• ¿Se puede otorgar una aprobación previa a los equipos?
• ¿Podemos modelar los cambios para que sean más estandarizados?
• ¿Podemos reestructurar los equipos, por ejemplo, incorporando un consultor de seguridad al equipo Scrum para evitar la necesidad de un consultor independiente?

Las organizaciones no solo mejorarán sus productos, sino que también podrían descubrir que los procesos que dan por sentados pueden optimizarse de forma iterativa. Los datos pueden revelar cuellos de botella en otras áreas, ya sean herramientas, procesos o personal. Identificar estos cuellos de botella también representa una oportunidad para detectar pasos y procesos manuales engorrosos y automatizarlos para lograr mayor agilidad y eficiencia.

La transición de la planificación ágil a la era de los datos

La metodología ágil es una mentalidad productiva, pero a menudo puede estar sujeta a factores arbitrarios o subjetivos. El desarrollo de software debe basarse en datos en lugar de en la intuición o el juicio.

Un ejemplo es el uso de métodos no basados ​​en datos para priorizar las historias de usuario. Estos métodos suelen basarse en el criterio del gerente o propietario del producto, fundamentado en su conocimiento del mercado y los clientes, y pueden ser claramente subjetivos.

Integrar los datos en el proceso no solo implica desarrollar mejores productos, sino que también puede reducir el trabajo innecesario de los equipos. Los datos fomentan la responsabilidad y la autonomía. Los equipos con acceso de autoservicio a las analíticas pueden operar de forma autónoma para establecer objetivos, mejorar procesos y alcanzar un mejor rendimiento.

La metodología ágil necesita agilidad. Solo los datos pueden proporcionarla. De lo contrario, es como lanzar dardos a ciegas con la esperanza de dar en el blanco.

Descubre por qué usar metodologías ágiles solo a nivel de equipo podría estar frenando a tu organización y qué puedes hacer para aumentar la eficacia y la escalabilidad en nuestro eBook: “8 razones por las que la metodología ágil a nivel de equipo no es suficiente.