Enable javascript in your browser for better experience. Need to know to enable it? Go here.
La información en esta página no se encuentra completamente disponible en tu idioma de preferencia. Muy pronto esperamos tenerla completamente disponible en otros idiomas. Para obtener información en tu idioma de preferencia, por favor descarga el PDF aquí.
Última actualización : Mar 29, 2022
NO EN LA EDICIÓN ACTUAL
Este blip no está en la edición actual del Radar. Si ha aparecido en una de las últimas ediciones, es probable que siga siendo relevante. Si es más antiguo, es posible que ya no sea relevante y que nuestra valoración sea diferente hoy en día. Desgraciadamente, no tenemos el ancho de banda necesario para revisar continuamente los anuncios de ediciones anteriores del Radar. Entender más
Mar 2022
Adopt ? Creemos firmemente que la industria debería adoptar estos elementos. Nosotros los utilizamos cuando es apropiado para nuestros proyectos.

Para medir el rendimiento de la entrega de software, cada vez más organizaciones recurren por defecto a las cuatro métricas clave definidas por el programa DORA research: tiempo de espera de los cambios, frecuencia de despliegue, tiempo medio de restauración (MTTR) y porcentaje de fallos en los cambios. Esta investigación y su análisis estadístico han demostrado una clara relación entre el alto rendimiento de la entrega y estas métricas; proporcionan un gran indicador de cómo lo está haciendo una organización de entrega en su conjunto.

Seguimos siendo grandes defensores de estas métricas, pero también hemos aprendido algunas lecciones. Seguimos observando enfoques erróneos con herramientas que ayudan a los equipos a medir estas métricas basándose únicamente en sus conductos de entrega continua (CD). En particular, cuando se trata de las métricas de estabilidad (MTTR y porcentaje de cambios fallidos), los datos del pipeline de CD por sí solos no proporcionan suficiente información para determinar qué es un fallo de despliegue con impacto real en el usuario. Las métricas de estabilidad sólo tienen sentido si incluyen datos sobre incidentes reales que degraden el servicio para los usuarios.

Recomendamos tener siempre presente la intención última de una medición y utilizarla para reflexionar y aprender. Por ejemplo, antes de dedicar semanas a la creación de sofisticadas herramientas de cuadros de mando, considera la posibilidad de limitarse a realizar regularmente la comprobación rápida del DORA en las retrospectivas del equipo. Esto da al equipo la oportunidad de reflexionar sobre qué capacidades podrían trabajar para mejorar sus métricas, lo que puede ser mucho más eficaz que la creación de herramientas demasiado detalladas. Hay que tener en cuenta que estas cuatro métricas clave se originaron a partir de la investigación a nivel de organización de los equipos de alto rendimiento, y el uso de estas métricas a nivel de equipo debe ser una forma de reflexionar sobre sus propios comportamientos, no sólo otro conjunto de métricas para añadir al cuadro de mando.

Oct 2021
Adopt ? Creemos firmemente que la industria debería adoptar estos elementos. Nosotros los utilizamos cuando es apropiado para nuestros proyectos.

Para medir el rendimiento en la entrega de software, cada vez más organizaciones recurren a las cuatro métricas clave definidas por el programa DORA research : el tiempo de espera de un cambio, la frecuencia de despliegue, el tiempo medio de restauración (MTTR) y tasa de fallo de cambio. Esta investigación y sus análisis estadísticos han demostrado una clara relación entre el alto rendimiento de entrega y estas métricas, lo cual proporciona un magnífico indicador de cómo un equipo, o incluso toda una organización, lo está haciendo.

Aún somos partidarios de estas métricas, sin embargo hemos aprendido algunas lecciones desde la primera vez que empezamos a monitorearlas. Cada vez vemos más enfoques de medición erróneos en herramientas que ayudan a los equipos a medir estas métricas basándose puramente en sus pipelines de entrega continua (CD). En particular, cuando se trata de métricas de estabilidad (MTTR y tasa de fallo de cambio), únicamente los datos recogidos de las pipelines de entrega continua (CD)no proveen suficiente información para determinar qué es un fallo en el despliegue con un impacto real en el usuario. Las métricas de estabilidad sólo tienen sentido si incluyen datos sobre los incidentes reales que degradan el servicio para los usuarios.

Y como todas las métricas, recomendamos tener siempre presente el objetivo principal que está detrás de la medición y usarlas para reflexionar y aprender. Por ejemplo, antes de estar semanas construyendo sofisticadas herramientas con tableros, considere incluir y revisar regularmente el DORA quick check en las retrospectivas del equipo. Esto da al equipo la oportunidad de reflexionar en que capabilities podrían trabajar para mejorar sus métricas, lo que puede ser mucho más eficaz que las herramientas que ya están hechas y sobre-detalladas.

Apr 2019
Adopt ? Creemos firmemente que la industria debería adoptar estos elementos. Nosotros los utilizamos cuando es apropiado para nuestros proyectos.

The thorough State of DevOps reports have focused on data-driven and statistical analysis of high-performing organizations. The result of this multiyear research, published in Accelerate, demonstrates a direct link between organizational performance and software delivery performance. The researchers have determined that only four key metrics differentiate between low, medium and high performers: lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. Indeed, we've found that these four key metrics are a simple and yet powerful tool to help leaders and teams focus on measuring and improving what matters. A good place to start is to instrument the build pipelines so you can capture the four key metrics and make the software delivery value stream visible. GoCD pipelines, for example, provide the ability to measure these four key metrics as a first-class citizen of the GoCD analytics.

Nov 2018
Trial ? Vale la pena intentarlo. Es importante entender cómo construir esta habilidad. Las empresas deberían implementar esta tecnología en un proyecto que pueda manejar el riesgo.

The State of DevOps report, first published in 2014, states that high-performing teams create high-performing organizations. Recently, the team behind the report released Accelerate, which describes the scientific method they've used in the report. A key takeaway of both are the four key metrics to support software delivery performance: lead time, deployment frequency, mean time to restore (MTTR), and change fail percentage. As a consultancy that has helped many organizations transform, these metrics have come up time and time again as a way to help organizations determine whether they're improving the overall performance. Each metric creates a virtuous cycle and focuses the teams on continuous improvement: to reduce lead time, you reduce wasteful activities which, in turn, lets you deploy more frequently; deployment frequency forces your teams to improve their practices and automation; your speed to recover from failure is improved by better practices, automation and monitoring which reduces the frequency of failures.

Publicado : Nov 14, 2018

Descarga el PDF

 

 

 

English | Español | Português | 中文

Suscríbete al boletín informativo de Technology Radar

 

 

 

 

Suscríbete ahora

Visita nuestro archivo para leer los volúmenes anteriores