KPI para equipos de desenvolvemento de software – Arragonán – Dani Latorre

Como parte do meu traballo no último ano, intentei empurrar a cultura da mellora continua nos diferentes equipos cos que estiven a traballar .. Tanto sobre cuestións de ferramentas e habilidades técnicas, como nas de comunicación e coordinación, con certas restricións e dependencias que caen da nosa marxe de influencia.

Comezamos a partir da suposición de que o mellor equipo practica Son, a mellor capacidade de entrega terá. Que se traduce nunha maior adaptabilidade aos cambios, un mellor mantemento do software co paso do tempo e posiblemente unha maior motivación do equipo co seu traballo.

Ademais das típicas sensacións subjetivas de efecto de mellora, Tivemos que pensar sobre os indicadores que nos permiten realmente obtelo. Nalgún momento, tamén comezaría a querer ter visibilidade fóra dos equipos, polo que tiven que dar a volta e pedir ideas.

Estaba preparando unha presentación para explicar internamente como estabamos traballando, onde eu Pensamos que debemos pasar por unha mellora continua, os diferentes KPIs que poderiamos observar e as necesidades que estarían cubertas cunha boa capacidade de entrega.

Deslice dunha presentación co a visión do que, como un equipo debe ser cuberto: a adaptabilidade sobre o negocio, entregando pronto, evitando a reposición, unha boa UX e evitando erros tanto como sexa posible

“Dime como me entendo e Direille como me comporto “

Non sei a orixe, pero con estas cousas sempre recordo diso. Ten que andar cun ollo con que indicadores (non obxectivos) mediremos . Ademais, teremos que usar varios para compensar a promoción de comportamentos estraños que falsas esas métricas.

con uso Normal das ferramentas, só acordo con algunhas convencións, a posterior explotación de datos pódese facilitar a extraer métricas. As fontes de datos para os indicadores son:

  • o código
  • O repositorio de automatización e servidor
  • as ferramentas de xestión
  • o Produto en si mesmo

Indicadores de código

As ferramentas de análise de código estático dannos números sobre a débeda técnica que existe. Non debemos perder de vista a estes indicadores e dedicar tempo a analizar e facer unha limpeza específica de cando en vez. Ás veces, resólvense con solucións simples e outros ocultan problemas de deseño que non son tan obvios.

A cobertura de proba é un dos indicadores máis comúns, o máis interesante neste caso é ver o que non está cuberto. E como adoita ser discutido, temos que camiñar coidadosamente porque é un indicador fácil de falsificar se se busca como obxectivo.

Nun momento determinado, ademais, podería usarse probas de mutación (verificación que unha proba está rota ao modificar o código de produción) para ter un indicador da calidade das probas da unidade.

Indicadores de repositorio e servidor de automatización

Hai indicadores bastante interesantes que poden ser eliminados dos repositorios e servidores de automatización, aínda que a maioría dependen das convencións de uso.

Con todo, un indicador sempre é válido e que creo que debería ser observado é a frecuencia de integración.

A integración continua é unha práctica (que ningunha ferramenta) é tan popular como mal interpretada, xa que ata o traballo que fixeches ou está a facer unha persoa coa rama de desenvolvemento principal e completáronse unha compilación, non o estamos facendo.

Ata que termine correctamente A construción dun artefacto de software, non sabemos se todo é correcto. Máis frecuencia, feedback anteriormente e menos incerteza.

En caso de usar ramas, tamén é interesante ver a duración da vida das ramas. Máis tempo, o aumento do risco de conflitos ou outros problemas ao integrar.

e se se utilizan as solicitudes de tirar / fusionar, hai tamén un puñado de indicadores que en calquera momento pode sacar olores relacionados coa capacidade de entrega : Número de comentarios, tempo restante, número de rexeitamentos …

Indicadores de ferramentas de xestión

ferramentas de xestión, ademais de servir como un radiador de información para coñecer a situación actual construción DO PRODUTO E AXUDA DE TRABALLO DE EXTERIOR, son unha boa fonte de información sobre os indicadores do proceso de traballo.

Para observar a capacidade de todo o equipo nun conxunto de cortes verticais é moi útil coñecer o tempo de ciclo .. A un tempo de ciclo máis curto, maior será a nosa capacidade de entrega. É o tempo que leva desde que comeza a traballar en algo que aporta valor (por exemplo, unha historia de usuario) ata que isto ocorre.

É habitual que nalgún momento das ferramentas de xestión pode observar as diferentes implementacións que se fixeron, onde podemos obter a frecuencia de implantación. Obviamente, con máis frecuencia, mellor.

Aínda que o noso tempo de ciclo foi curto e a frecuencia de alta implementación, sería posible que o noso produto sexa fráxil debido a erros. É por iso que o indicador de erros detectados e resoltos por versión / implantación é outra métrica para sempre ter en conta.

Dependendo do momento e escenario no que se atopa un produto, tamén creo que o indicador de O tempo de espera, pasou o tempo desde que se lle pregunte algo novo ata que se desplegue na produción. Iso sería unha consecuencia dos 3 indicadores anteriores eo tamaño da pila do produto.

Como supoño que hai alguén que poida perder os indicadores sobre as estimacións, a iteración de puntos da historia. Na miña opinión, teñen un compoñente moi subjetivo e variable que se pode usar como indicador de cambio na capacidade de entrega dunha computadora.

Indicadores do produto en si mesmos

ademais de Outro tipo de instrumentación máis meticulosa que os membros do equipo ou o equipo de xestión de deseño precisan, o equipo de desenvolvemento debe ser capaz de observar o número e porcentaxe de uso de funcionalidade, que ao final define o éxito ou non do traballo de todos.

O máis interesante sobre este indicador é que combinado con outras métricas pode axudar a tomar decisións sobre a evolución do produto. Como por exemplo, este escenario:

  1. detectou problemas de rendemento moi grave nunha parte do produto.
  2. Observamos que a porcentaxe de uso da funcionalidade afectada por eses problemas é Residual.
  3. Decidimos non solucionalo neste momento, pero o reflictamos na pila do produto como unha pequena prioridade.
  4. Configurar unha alerta para detectar algún aumento na porcentaxe de uso desa funcionalidade.

Outro indicador importante é a taxa de choque do produto, cantas veces se detecta un fallo ou erro por cantidade de uso, que nos permite saber o que é estable a O produto é. E mesturado co indicador de números de uso de funcionalidades, permítenos detectar os puntos problemáticos.

Dependendo do contexto do produto e do negocio, posiblemente podemos sacar outros indicadores relevantes de operacións e apoio que son unha consecuencia do uso do produto.

Mida sen perder o foco

Estes son moitos KPIs diferentes. É interesante observalos porque poden ser utilizados para detectar cheiros sobre problemas e oportunidades de mellora, pero son demasiados para intentar mellorar todo ao mesmo tempo.

para evitar diluír e non acabar en absoluto , debemos escoller e concentrarse nun par de eses indicadores cada vez, dependendo da situación de cada equipo.

E aínda que sexa tentador facelo, evitaría un uso feliz de usar estes indicadores para marcar obxectivos , así como para avaliar equipos diferentes.

Non esquezamos que o propósito de medir estes indicadores é observar a evolución no momento dun equipo que traballa nun determinado produto e contexto.

Leave a Comment

O teu enderezo electrónico non se publicará Os campos obrigatorios están marcados con *