Métrica pela qual os desenvolvedores devem ser responsabilizados [duplicados]

Em 16 anos, nunca encontrei uma métrica viável do tipo que você está procurando.

Essencialmente, para ser útil, qualquer coisa precisa ser mensurável, representativa e indecifrável (ou seja, o sistema não pode ser reproduzido por desenvolvedores inteligentes). Há simplesmente muitas variáveis no desenvolvimento de software para torná-lo mensurável como peça de trabalho dessa maneira.

O mais próximo que você chega é o progresso em relação às estimativas - quantas tarefas estão sendo concluídas dentro das estimativas acordadas. O truque aqui é (a) obter boas e justas estimativas e (b) entender onde as estimativas foram excedidas por boas razões pelas quais o desenvolvedor não pode / não deve ser culpado (isso é algo realmente mais complexo do que o previsto). Em última análise, se você forçar demais os desenvolvedores, é provável que você encontre estimativas que gradualmente se elevam a um nível em que elas sempre são atendidas, não por causa do aumento de produtividade, mas por causa de escalas de tempo acolchoadas.

Indo para o outro lado em termos de estimativas (reduzindo-as para criar pressão para entregar) e criando prazos que os estudos mostraram que não aumentam a produtividade e provavelmente causam impacto no moral da equipe (veja Peopleware para mais informações).

Mas, essencialmente, eu me pergunto se você está olhando para um problema ligeiramente falso. Por que os programadores remotos são diferentes de outros programadores quando se trata de medir a produtividade? Como você mede a produtividade de programadores não remotos?

Se é para não confiar que eles funcionem remotamente, isso é basicamente um problema de confiança mais amplo. Se você não confia neles para trabalhar em casa, então você precisa estabelecer essa confiança, não deixá-los trabalhar em casa, ou encontrar alguma maneira de se satisfazer de que eles estão de fato trabalhando quando deveriam estar.

As métricas funcionam melhor em fábricas e os programadores não trabalham em uma linha de montagem.

Compreendo perfeitamente o desejo de medir a produtividade.

Mas você usaria a mesma métrica para um médico de família e um cirurgião cardíaco? Que tal Michelangelo pintar a Capela Sistina e um cara no México fazendo pinturas de Elvis de veludo preto?

As medidas numéricas funcionam melhor em trabalhos que são repetitivos, como fundição de ferro ou parafusos nas portas dos carros. Mas se você está repetindo o código que foi feito antes, você não precisa de um programador, você só precisa copiar e colar. A programação é fundamentalmente uma disciplina criativa, e a produtividade depende inteiramente do que você está fazendo.

Alguns dias, eu faço mil linhas de código. Hoje, vou corrigir erros de geometria de coordenadas e o código pode diminuir. Se eu tivesse que consertar um bug em um driver de kernel do Linux, eu poderia passar o dia todo depurando e não escrever uma nova linha de código.

A medição da produtividade do programador é muito, muito, muito subjetiva .

Se você quer saber se Joe é produtivo, encontre Sally e Ralph, que sabem o que Joe está fazendo e são proficientes nas mesmas áreas, e pergunte a eles.

O melhor sistema numérico que eu já vi foi o planejamento de pontos de pôquer da Agile. Essa é apenas uma maneira chique de perguntar a Joe, Sally e Ralph o quão difícil eles acham que o próximo trabalho de Joe provavelmente será. Então você pode medir a produtividade de pontos por semana para cada membro da equipe. Mas, mesmo assim, leva um tempo para calibrar as estimativas de uma equipe, e os números são confusos e facilmente descartados.

Muitas pessoas querem estimativas de produtividade para que possam planejar o cronograma. É uma espécie de "conecte-se ao MS Project, olhe para o caminho crítico e a teoria da data de envio". Eu nunca, nunca vi esse trabalho - há muitas incógnitas demais. Se você quiser, use o Waterfall, projete tudo na frente, não permita pedidos de alteração e esteja preparado para ficar desapontado de qualquer maneira.

A única métrica que eu uso é a quantidade de software de trabalho que ele produz para uma dada quantidade de dinheiro que investi.

Independentemente do seu horário, se ele / ela trabalha remotamente ou não, o número de pausas que ele / ela faz, as metodologias que ele / ela utiliza ou o número de horas de trabalho.

Por software de trabalho , quero dizer:

List of features defined by user/customer that meets the required quality level

Por quantidade de dinheiro :

How much the user/customer paid for the defined features + maintenance costs

Por isso, ele tem um direto sobre como ele é construído e a qualidade do trabalho produzido, mas não vinculado a qualquer métrica de linha de código-fonte.

Você precisa de um desenvolvedor experiente ou líder de equipe (que não esteja associado a esses programadores remotos) para estimar o tempo que uma tarefa pode levar, e a eficácia é medida comparando o tempo necessário com as estimativas. Para ter certeza de que as estimativas são boas, você pode escolher aleatoriamente algumas tarefas e executá-las por uma equipe interna sob controle.

Outra maneira interessante de medir a produtividade seria contar testes automatizados revisados por um gerente por dia. O desenvolvedor recebe:

• um ponto para escrever um teste automatizável (e passar na revisão) e adicioná-lo ao conjunto de testes de regressão,
• um ponto para fazê-los passar, sem causar nenhuma outra falha no teste de regressão.

O desenvolvedor e o gerente podem melhorar o sistema em conjunto:

• concordando em conjunto sobre as áreas importantes de desenvolvimento e teste
• analisando e executando o conjunto de testes de forma independente.
• decidir não criar um recurso que tenha benefício comercial limitado, mas que exija muito desenvolvimento e teste necessários para fornecer esse recurso. (A linha de código mais produtiva é aquela que você decidiu não escrever porque não oferece nenhum benefício comercial).
• particionando o sistema em uma arquitetura (como model-view-controller) que facilita o desenvolvimento de recursos incrementais sem quebrar todo o sistema.

O desenvolvedor não pode jogar a métrica porque:

• testes redundantes serão bloqueados pela revisão do gerente.
• testes refinados podem ser bloqueados pela análise do gerente.
• testes refinados melhorarão a qualidade do sistema.

O gerente não pode jogar a métrica porque:

• rejeitar muitos testes levará ao atrito do desenvolvedor.
• solicitar muitos testes dificultará a recusa de um prazo posterior.

O desenvolvedor não pode estragar o gerente porque

• Cada unidade entregue de funcionalidade com testes também deve passar pelo conjunto de regressão. Isto força o desenvolvedor a desenvolver cuidadosamente sem quebrar outro código.
• Qualquer reivindicação de trabalho deve ser comprovada pela aprovação de novos testes e testes de regressão.

O gerente não pode estragar o desenvolvedor porque.

• Cada unidade de funcionalidade solicitada deve incluir os principais casos de teste e uma estimativa do número de casos de teste necessários para concluir o trabalho.
• É difícil pedir um cronograma agressivo e / ou horas extras grátis quando você obviamente está pedindo muito trabalho.

Outro grande benefício para o gerente é que ele pode trazer novos desenvolvedores e saber que eles não serão capazes de entregar o código que quebra silenciosamente o sistema (porque o conjunto de testes de regressão captura isso).

Certamente é possível inventar todos os tipos de métricas complexas para avaliar o desempenho, mas no final do dia uma parte significativa do seu julgamento tem que se basear na subjetividade e na contribuição de pessoas próximas à base de código.

Por exemplo, é bem possível que uma equipe produza slop intocável e inamovível internamente a uma taxa muito rápida, e isso pode até mesmo cumprir o prazo e a especificação exigidos. Mas a dívida técnica acumulada com esse tipo de estilo de trabalho é pior do que se a equipe produzisse algo robusto e sustentável, mas perdesse o prazo de algumas semanas? Depende.

Se o propósito da questão é resolver algum tipo de problema de produtividade, eu diria que o que o gerente realmente faz para facilitar o trabalho da equipe é tão ou mais importante do que qualquer técnica de medição usada para avaliar o problema. equipe . Esta é uma via de mão dupla. Em outras palavras, estou dizendo que as métricas são boas, mas se você quer mais de qualquer equipe, a última pergunta é se o gerente está fazendo todo o possível para garantir que a equipe seja produtiva.

Isso vai muito além de escrever uma especificação, encontrar uma equipe, jogar a especificação "por cima do muro" e clicar em um cronômetro.

Algumas ideias:

1. recursos implementados
2. bugs corrigidos (também conta com bugs reabertos posteriormente pelo controle de qualidade)
3. reclamações de usuários resolvidas (note que não é o mesmo que 2 - um erro sério pode ser dor no pescoço enquanto 100 erros de digitação podem não ser tão importantes)

Também pode querer acompanhar:

1. Cobertura de código por testes
2. Cobertura de código por documentação interna
3. Cobertura de recursos por documentação externa (usuário)

Meça da mesma forma que você é medido pelo cliente. Em termos de código funcional, mas em menor escala.

Faça metas curtas - uma semana ou duas - e veja se os programadores cumprem as metas e o façam de maneira satisfatória.

Eu sugiro strongmente uma revisão por pares do código, pois isso permite que você detecte um código incorreto antecipadamente.

Como sobre a taxa de vendas do produto / serviço.

Às vezes eu ouvi que é chamado de comissão / porcentagem do faturamento bruto

As pessoas compram bons produtos, não são?

A empresa quer vender o produto (ou talvez o serviço, a mesma diferença para isso)

Então, se é isso que você quer, meça.

Um pouco como dizer pessoas que projetam um carro que recebe boas críticas & vende bem ter feito um bom trabalho realmente.

Agora adote essa métrica e a equipe de programação desejará interagir com o vendedor por dois motivos.

• Prometendo subalterno

• Não vender produtos aos clientes de forma eficaz

Escrever código / programação não é como colocar um martelo num prego. Muito parecido com "escrever" em geral, não é algo que você pode aplicar normalmente a métricas também - na minha opinião.

Você não poderia simplesmente ver os check-ins deles ou o que eles fizeram por meio de revisão por pares, revisão de código?

Ou você sabe, se eles realmente produzem código de trabalho e soluções que solucionam problemas?

Use uma metodologia, em que a documentação escrita se case com o código escrito. Comece a semana decidindo sobre o que precisa ser feito, consiga um acordo, depois espere até o final da semana para ver se foi feito ou não. Mantenha as tarefas pequenas e mensuráveis como em quantos dias. Eu não acho que você precisa medir o trabalho dos programadores por dizer, mas o acordo sobre o que deve ser entregue e quando é uma obrigação para o controle.

A segunda parte desta solução seria uma revisão de código peer-to-peer que é apoiada por algum tipo de sistema de controle de versão que faz quem fez o quê e quando rastreável. Se o consenso é de que o código é bom, então o seu para um vencedor, se for ruim, então descubra por que e como ele poderia ser melhorado.

Estudos de tempo e movimento são um não não, no que me diz respeito, alguns códigos como Regexes ou alguma lógica realmente difícil podem levar dias para se desenvolver, mas podem formar apenas algumas linhas de código. A única medida verdadeira é entregas a tempo, em um tempo acordado.