{"id":1959,"date":"2021-04-28T08:13:06","date_gmt":"2021-04-28T08:13:06","guid":{"rendered":"https:\/\/keepler.io\/2021\/04\/28\/las-metricas-en-agile\/"},"modified":"2024-01-15T13:30:23","modified_gmt":"2024-01-15T12:30:23","slug":"las-metricas-en-agile","status":"publish","type":"post","link":"https:\/\/keepler.io\/es\/2021\/04\/28\/las-metricas-en-agile\/","title":{"rendered":"Las m\u00e9tricas en agile"},"content":{"rendered":"

A menudo, los \u00e1rboles no permiten ver el bosque. El d\u00eda a d\u00eda, con su realidad tozuda de reuniones y entregas, pueden cegar el desarrollo de software<\/em>. Las m\u00e9tricas suelen centrarse en aspectos relacionados con la mec\u00e1nica de los equipos y de los ciclos de entrega: WIP, WIA, velocidad, <\/span>cycle time<\/span><\/i> o <\/span>delivery rate<\/span><\/i>,\u00a0 pero lo verdaderamente importante no es lo que ocurre dentro de los equipos sino lo que ocurre con los equipos, y entre ellos y sus usuarios finales. La mejora continua siempre debe orientarse a la entrega real de valor no al valor supuesto o estimado.<\/strong><\/span><\/p>\n

La mejora continua de cada equipo particular de forma sostenida no es f\u00e1cil, es necesario la confianza a largo plazo en el marco de trabajo para reconocer la validez y aprovechar las oportunidades. El Agile Manifesto, nos dice: <\/strong><\/span>A intervalos regulares el equipo reflexiona sobre c\u00f3mo ser m\u00e1s efectivo para a continuaci\u00f3n ajustar y perfeccionar su comportamiento en consecuencia.<\/i><\/strong><\/p>\n

La eficacia hace referencia al efecto perseguido mientras que la eficiencia guarda relaci\u00f3n con el uso que se haga de los medios. Por lo tanto, las m\u00e9tricas deben centrarse en lograr de forma efectiva los fines, dado que la eficiencia o funcionamiento internos de los equipos son medios para la consecuci\u00f3n del fin primero.<\/span><\/p>\n

Un conjunto de m\u00e9tricas de equipo que validen las sensaciones con datos y pueda tratar cada iteraci\u00f3n como una mejora a lo largo del tiempo en los valores orientados a la relaci\u00f3n entre el producto y los usuarios que se midan, sirve de respaldo y de evidencia para la toma de decisiones.\u00a0<\/span><\/p>\n

Dado que una transformaci\u00f3n agile parte del compromiso en la autogesti\u00f3n de los equipos, un marco de liderazgo o de toma de decisiones basado en ellas nace de abajo a arriba, con datos agregados que son aprovechados en los distintos \u00e1mbitos de decisi\u00f3n. Siendo los equipos autoorganizados, las m\u00e9tricas deben nacer y ser gestionadas desde ellos.<\/span><\/p>\n

La mejora continua es un proceso mensurable que requiere de m\u00e9tricas para poder valorar el avance<\/strong>. Las m\u00e9tricas y las mediciones son pol\u00e9micas porque existe el temor de que se mida para fomentar una competici\u00f3n m\u00e1s que una mejora de la entrega de valor sustancial.\u00a0<\/span><\/p>\n

Centr\u00e1ndose en lo urgente en vez de en lo importante, los equipos pierden oportunidades de mejorar y progresar como unidad individual o integrados dentro de un esquema corporativo. Debe garantizarse que exista un ecosistema que sea proclive al desarrollo de este esquema de desarrollo. El liderazgo se debe ejercer de forma estructurada y a largo plazo, con objetivos y, c\u00f3mo no, tambi\u00e9n con m\u00e9tricas que permitan tomar conciencia de los avances u obst\u00e1culos.<\/span><\/p>\n

Los equipos deben centrarse en la esencia de agile, que no es otra cosa que el proceso continuo de inspecci\u00f3n y adaptaci\u00f3n en pos de la entrega de valor mediante un flujo iterativo de mejora de la eficacia.\u00a0<\/span><\/p>\n

Medir la velocidad de los equipos y contar el volumen de tickets total que pasan por el flujo de trabajo es lo peor que le ha pasado al desarrollo de software<\/em> desde que waterfall demostr\u00f3 su incapacidad para adaptarse a la incertidumbre, dado que perpet\u00faa su esencia y lo esconde tras el humo y espejos de algo que solo es agile formalmente.<\/span><\/p>\n

Lo \u00fanico que se debe medir es\u00a0 c\u00f3mo y cu\u00e1nto\u00a0 los usuarios desean utilizar y utilizan el software<\/em> entregado y qu\u00e9 impedimentos se interponen. El resto de m\u00e9tricas se supedita a las anteriores, cada KPI debe favorecerlas.<\/span><\/p>\n

Evidence-based management<\/strong> (EBM) procura establecer decisiones bas\u00e1ndose en las mejores evidencias disponibles. Se establecen \u00e1reas de medici\u00f3n y m\u00e9tricas apropiadas<\/strong> en cada una de ellas: <\/span>Unrealized Value, Current Value<\/i>, Ability to Innovate<\/i> y Time to Market.<\/span><\/i><\/p>\n

Simplificando, las m\u00e1s relevantes para un caso general y que cubren esencialmente el espectro de medici\u00f3n, ser\u00edan:<\/span><\/p>\n

Ingresos<\/b><\/p>\n

Es lo que permite que la rueda siga girando. Estos ingresos pueden ser directos a trav\u00e9s de usuarios finales o puede suponer un ahorro\u00a0 y, por lo tanto,\u00a0 un flujo constante de financiaci\u00f3n atendiendo a su pertinencia.<\/span><\/p>\n

Usuarios activos<\/b><\/p>\n

Es lo que permite determinar si el software<\/em> se est\u00e1 utilizando y, por lo tanto, determinar si el incremento de valor que entrega cada equipo representa un beneficio real para los usuarios o si debemos revisar el flujo de inspecci\u00f3n y adaptaci\u00f3n.\u00a0<\/span><\/p>\n

Net Promoter Score<\/em> (NPS)<\/b><\/p>\n

Esta m\u00e9trica representa la valoraci\u00f3n de los usuarios respecto al software<\/em> entregado.\u00a0 Mide la experiencia de los clientes y preside el crecimiento de negocio. Se divide en promotores, pasivos y detractores. Restando el porcentaje de detractores del porcentaje de promotores da como resultado el NPS.<\/span><\/p>\n

Market Share<\/b><\/em><\/p>\n

Representa el porcentaje de mercado controlado por el producto y, por lo tanto, la cuota potencial que podr\u00eda alcanzarse de enfocarse en las necesidades del usuario.<\/span><\/p>\n

Tickets de soporte abiertos<\/b><\/p>\n

Representan el n\u00famero de incidencia o solicitudes de soporte abiertos por los usuarios por unidad de tiempo. Los tickets de soporte pueden representar un bug, un procedimiento mal explicado en la documentaci\u00f3n o un mal uso del software<\/em>, por lo tanto, el objetivo no es eliminarnos sino mantenerlos lo m\u00e1s bajo posible.<\/span><\/p>\n

On-Product Index<\/b><\/em><\/p>\n

Fundamentalmente, es el tiempo que un equipo dedica a trabajar en valor para el producto.<\/span><\/p>\n

Deuda t\u00e9cnica<\/b><\/p>\n

Representa el esfuerzo adicional en los equipos producto de haber tomado atajos en el desarrollo del producto que resulta en la necesidad de dedicar esfuerzo posterior para subsanarlo, restando capacidad de trabajo al equipo.<\/span><\/p>\n

Rendimiento<\/b><\/p>\n

Representa el comportamiento del software<\/em> respecto al tiempo o capacidad como tiempos de respuesta o proceso y volumen.<\/span><\/p>\n

Existe una tendencia a obsesionarse por m\u00e9tricas de optimizaci\u00f3n de proceso que satisfagan la ley de Little o un flujo con una cadencia consistente con un <\/span>Lead Time<\/span><\/i> reducido, y tendemos a olvidar que las m\u00e9tricas relevantes son aquellas relacionadas con el negocio y con los usuarios.<\/span><\/p>\n

Los esfuerzos de los equipos deben orientarse siempre en dos aspectos, a dar valor real a los usuarios y en eliminar o mitigar todo aquello que entorpece su entregar<\/strong>. Para lograrlo, los equipos deben enfocarse en buenas pr\u00e1cticas, eliminaci\u00f3n de deuda t\u00e9cnica y enfocarse en valor real, eliminado esfuerzos de valor percibido pero no no efectivo en el desarrollo del producto. Esto se logra mediante un flujo de experimentaci\u00f3n y validaci\u00f3n de hip\u00f3tesis dentro de los sprints que permite recibir informaci\u00f3n contra la propuesta inicial, inspeccionarla, adaptarla y utilizar el resultado como nuevo punto de partida sobre el que establecer la siguiente propuesta en base a las hip\u00f3tesis planteadas.<\/span><\/p>\n

Unos equipos concienciados de la necesidad de centrarse en estos aspectos, mejorar\u00e1n la entrega de valor y comprender\u00e1n que el resto de acciones son medios orientados a la satisfacci\u00f3n del fin que no es otro que la verdadera entrega de valor siempre con el esfuerzo puesto en los usuarios finales del software<\/em>.<\/span><\/p>\n

Imagen: Unplash | @austindistel<\/p>\n","protected":false},"excerpt":{"rendered":"

A menudo, los \u00e1rboles no permiten ver el bosque. El d\u00eda a d\u00eda, con su realidad tozuda de reuniones y entregas, pueden cegar el desarrollo de software. Las m\u00e9tricas suelen centrarse en aspectos relacionados con la mec\u00e1nica de los equipos y de los ciclos de entrega: WIP, WIA, velocidad, cycle time o delivery rate,\u00a0 pero […]<\/p>\n","protected":false},"author":134360207,"featured_media":1675,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","_crdt_document":"","content-type":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"_wpas_customize_per_network":false},"categories":[303],"tags":[240,297,270],"class_list":["post-1959","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-es","tag-agile","tag-desarrollo-de-software","tag-metodologias"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/keepler.io\/wp-content\/uploads\/2021\/04\/metricas-en-agile.jpg?fit=1280%2C452&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p9CeZw-vB","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/1959","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/users\/134360207"}],"replies":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/comments?post=1959"}],"version-history":[{"count":1,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/1959\/revisions"}],"predecessor-version":[{"id":2396,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/1959\/revisions\/2396"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/media\/1675"}],"wp:attachment":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/media?parent=1959"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/categories?post=1959"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/tags?post=1959"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}