Estou fazendo 4-5x mais pontos de história do que a média, mas produzindo bugs a metade da taxa. Os gráficos dizem que são 2x mais bugs, como lidar com isso?

Eu acho que você está misturando suas preocupações. E não há nada no lado que você precise mudar.

A produtividade é uma indicação de quão rapidamente um projeto será concluído. Os gerentes de projeto e todos os outros gostam de saber quando o projeto será entregue. Produtividade maior ou mais rápida significa que veremos o projeto entregar mais cedo.

A taxa de erros não está vinculada à produtividade, mas ao tamanho do projeto. Por exemplo, você pode ter N bugs por Y linhas de código. Não há nada nessa métrica que diga (ou se preocupe!) A rapidez com que essas linhas de código são escritas.

Para unir isso, se você tiver maior produtividade, sim, "verá" os erros sendo gravados mais rapidamente. Mas você teria esse número de bugs de qualquer maneira, já que está ligado ao tamanho do projeto.

Se houver algo, maior produtividade significa que você terá mais tempo no final do projeto para caçar esses bugs ou o desenvolvedor será mais rápido em encontrar os bugs que eles criaram. ¹

Para abordar os aspectos mais pessoais da sua pergunta.

Se o seu chefe está olhando estritamente para o número de erros que você produz, ao contrário da taxa de erros que você produz, uma sessão educacional está em ordem. Número de bugs criados é sem sentido sem uma taxa de apoio.

Para levar esse exemplo ao extremo, diga ao seu chefe que eu quero dobrar seu salário. Por quê? Eu criei absolutamente nenhum bug em seu projeto e, portanto, sou um programador muito superior ao seu. O que? Ele vai ter um problema que eu não tenha produzido uma única linha de código para beneficiar o seu projeto? Ah Agora temos uma compreensão de por que a taxa é importante.

Parece que sua equipe tem as métricas para avaliar os erros por ponto de história. Se nada mais, é melhor do que ser medido pelo número bruto de bugs criados. Seus melhores desenvolvedores devem estar criando mais bugs porque estão escrevendo mais código. Peça ao seu chefe que jogue fora esse gráfico ou, pelo menos, jogue outra série atrás dele mostrando quantos pontos da história (ou qualquer valor comercial que você meça), juntamente com o número de erros. Esse gráfico contará uma história mais precisa.

¹ _{Este comentário em particular atraiu muito mais atenção do que pretendia. Então, vamos ser um pouco pedantes (surpresa, eu sei) e redefinir nosso foco nessa questão.}

_{A raiz desta questão é sobre um gerente olhando para a (s) coisa (s) errada (s). Eles estão analisando os totais brutos dos erros quando deveriam estar considerando a taxa de geração versus o número de tarefas concluídas. Não vamos ficar obcecados em medir contra "linhas de código" ou pontos de história, complexidade ou qualquer outra coisa. Essa não é a questão em mãos e essas preocupações nos distraem da questão mais importante.}

_{Como estabelecido nos links pelo OP, você pode prever um certo número de bugs em um projeto puramente pelo tamanho do projeto sozinho. Sim, você pode reduzir esse número de bugs por meio de diferentes técnicas de desenvolvimento e teste. Mais uma vez, esse não era o ponto dessa questão. Para entender essa questão, precisamos aceitar que, para um projeto de tamanho e uma metodologia de desenvolvimento, veremos um determinado número de bugs quando o desenvolvimento estiver "completo".}

_{Então, vamos finalmente voltar a este comentário que alguns completamente incompreendidos. Se você atribuir tarefas de tamanho comparável a dois desenvolvedores, o desenvolvedor com uma taxa de produtividade mais alta concluirá a tarefa antes da outra. O desenvolvedor mais produtivo terá, portanto, mais tempo disponível no final da janela de desenvolvimento. Esse "tempo extra" (em comparação com o outro desenvolvedor) pode ser usado para outras tarefas, como trabalhar nos defeitos que percorrerão um processo de desenvolvimento padrão.}

_{Nós temos que considerar o OP como sendo mais produtivo do que outros desenvolvedores. Nada dentro dessas afirmações implica que o OP ou outros desenvolvedores mais produtivos estão sendo negligenciados em seu trabalho. Apontando que haveria menos bugs se eles gastassem mais tempo com o recurso ou sugerindo que a depuração não faz parte desse tempo de desenvolvimento, e que o que foi perguntado é uma falha. Alguns desenvolvedores são mais rápidos do que outros e produzem um trabalho de qualidade comparável ou melhor. Novamente, veja os links que o OP coloca em sua pergunta.}

Gaste um pouco desse tempo extra limpando, polindo e testando seu código. Ainda haverá erros, mas haverá menos. Isso leva tempo. Sua taxa de saída do código diminuirá, mas a saída do código sem erros aumentará, e isso resultará em melhor produtividade. Porque os erros são caros.

Você pode manter seu código em uma ramificação ou em um ambiente de teste até você chutá-lo e pegar mais dos bugs? Bugs em um branch geralmente causam menos waves que bugs no código de produção.

Mas não estou exatamente pesquisando suas afirmações que levam à sua pergunta. E talvez seu chefe também não seja.

Eu não acho que todo codificador produza a mesma taxa de erros. Seu segundo link é, na verdade, totalmente fora do tópico, pois está comparando diferentes idiomas, não diferentes níveis de habilidade do codificador. Código completo menciona algumas medições de amostra grande que estão olhando para o processo, em vez da habilidade dos codificadores. E quando dizem que codificadores de primeira linha produzem mais / melhor código, parte disso significa que ele tem menos bugs. Depende da aplicação. Então, sim, eu acho que é uma questão de perspectiva diferente.

No final, se o chefe quiser um código mais limpo, dê a ele um código mais limpo.

Eu vou sair em um membro e ser o advogado do diabo. Isso não quer dizer que eu não simpatizo com sua situação, mas, bem, minha simpatia não vai ajudá-lo. Então, permita-me adicionar à perspectiva de Philip :

Seu chefe se preocupa com a qualidade do produto, em parte porque seu nome e reputação estarão vinculados a ele. Parte da qualidade é a quantidade percebida de bugs . Se você vende uma furadeira incrível que perfura quatro vezes mais rápido do que qualquer exercício concorrente, mas também quebra duas vezes mais, você terá uma má reputação. Mesmo que seja discutível que a broca tenha um melhor desempenho, as pessoas se acostumaram com a velocidade, mas elas se lembrarão dos problemas.

Em retrospectiva, a maioria dos bugs são obviamente evitáveis. Se você fosse um pouco mais cuidadoso, seu chefe sentiria, você poderia evitar esses problemas e qualquer limpeza necessária. De sua perspectiva, isso é uma coisa sensata e trivial, e qualquer discussão que você fizer sobre isso não vai funcionar e vai fazer você parecer mal.

Ele não pode medir sua produtividade superior. Você reivindica maior produtividade com base em uma métrica verificável, então, como seus colegas se sentem sobre isso? Eles concordam, talvez com má vontade, que você é um programador mais produtivo ou está sozinho na sua opinião? Você fará um ponto mais strong se tiver outras pessoas para respaldar suas afirmações.

Isso é para perspectiva. Agora, como você resolve essa situação frustrante?

Diminua a velocidade um pouco. Mencione explicitamente a quem quer que distribua tarefas para as quais você tentará diminuir a taxa de erros (*), para que elas não fiquem surpresas com o menor consumo. Se alguma coisa, desacelerar irá reduzir o número de bugs atribuídos a você por falta de suprimento.

_{(*) Há uma diferença entre, por um lado, reconhecer que há erros em seu nome e que você tentará diminuir essa quantidade e, por outro lado , admitindo que você tem muitos bugs em seu nome e deve agir.}

Não tente convencer seu chefe, porque não funcionará. Mais uma vez, isso não significa que você tenha que admitir seu ponto; você pode apresentar um contraponto e manter sua opinião sem descartar suas preocupações. Porque se você argumentar e não puder provar satisfatoriamente sua produtividade superior (e mesmo se puder), você se arriscará a insultar seus colegas, ou parecer desconsiderá-los. Você não quer ser esse cara .

Supondo que você produziria a mesma "quantidade" de código como seus colegas em 20% do tempo, você poderia gastar 4 vezes mais em realmente depurar o código e torná-lo perfeito, o que reduziria ainda mais a sua taxa de bugs. Então você poderia se chamar um bom programador.

A maior questão é por que você está codificando 5 vezes mais que os outros em vez de buscar qualidade. Isso é algo que o seu ego dita para você ou o seu chefe o força?

Além disso, você precisa considerar os custos para corrigir um bug. Quando você achar cedo, você ainda pode estar "dentro" do código o suficiente para consertá-lo rapidamente. Se aparecer apenas depois de mais um mês de desenvolvimento, pode ser difícil encontrar ou forçar você a alterar grandes partes do código já programado.

Você parece ter o conjunto de habilidades para produzir código, e você pode torná-lo incrível se você se concentrar na qualidade e não na velocidade. Tente um tempo, meu palpite é que você vai gostar.

O próximo problema, então, é obter o reconhecimento (falar em dinheiro) para o seu melhor desempenho. Converse com seu chefe e pergunte-lhe como proceder, a empresa e o dinheiro dele, afinal, e se ele quiser que você produza menos bugs, ele também deve decidir de que maneira isso acontece.

Os desenvolvedores podem ser brilhantes, até mesmo geniais, com aptidão para entender e codificar sozinho, sem serem bons desenvolvedores. Um bom desenvolvedor cria um trabalho de qualidade e torna todo o projeto melhor.

Eu não estou dizendo que este é você, mas um dos programadores mais frustrantes com quem trabalhei escreveu mais código do que qualquer um na equipe, e nós tínhamos boas pessoas na equipe. Nós rastreamos os commits com um software de classificação, então era quase uma competição para algumas pessoas. Ele produziu faixas de código, deixando para trás sua documentação ZERO, florestas impenetráveis, e na verdade fez alguns dos meus próprios códigos difíceis para eu entender (eu posso fazer isso sozinho, muito obrigado!). Eventualmente ele quase descarrilou o projeto, porque ele se tornou um show de um homem. As pessoas não podiam segui-lo. Nós não estávamos em sincronia como um time. Na verdade, reescrevemos alguns de seus recursos anos depois, apenas para recuperar a manutenção.

A coisa que eu queria dele era desacelerar e passar mais tempo: 1) Melhorar a qualidade da base de código 2) Comunicando com a equipe 3) Trabalhar em coisas que ajudaram os outros, bem como ajudá-lo a terminar características / histórias 4) Corrigindo bugs

Eu não concordo com a medição da produtividade por linhas de código, mas é uma métrica chave. O seu contador de código inclui comentários? Em caso afirmativo, existe uma maneira fácil de manter a saída da sua linha enquanto reduz sua "taxa de erros"; simplesmente aumente a qualidade e a quantidade de comentários que você escreve. Os comentários raramente têm bugs (embora possam) e, em geral, não temos comentários de qualidade suficientes. Eu não aprovo a inflação do código, mas o ato de comentar é como uma mini revisão de código, obriga a pensar, refatorar e melhorar.

Tentar esclarecer o gerenciamento não é uma novidade. Há um velho clichê: "Você vai acreditar em mim ou em seus olhos mentirosos?" O que preocupa seus chefes são as contagens de bugs. Nenhuma quantidade de racionalização dirá que é aceitável. É mais que duas vezes mais arriscado. Além disso, você não é o único afetado pela sua contagem de erros. QA tem o dobro do trabalho tentando identificar seus bugs, então o gerenciamento vai querer que você faça menos deles.

A melhor solução é reduzir o número de erros que você produz , ponto final. Não só a gestão será mais feliz, mas você também será. Você não vai? Porque tenho tanta certeza quanto você se vangloria de ter superado seus colegas de trabalho por um fator de quatro, você ama dizendo que faz isso com o mesmo número de erros, ou até menos, do que eles fazem.

Como você afirmou, "... a taxa de erros cometidos no código ... tende a ser impactada pelos processos usados ao escrever o código e depois que o código é escrito." Se você quiser alterar o código taxa em que você produz erros você vai ter que mudar os processos que você usa para escrever código.

Os programadores usam métodos de produção para produzir código, da mesma forma que uma linha de montagem usa métodos para produzir algum objeto produzido em massa. Ok, as práticas da indústria de software são mais parecidas com as bugigangas dos galhos encontrados na floresta. Mas como estamos produzindo máquinas, devemos empregar o mesmo rigor e disciplina usados nas máquinas de alta velocidade de produção em massa.

Isso inclui as mesmas técnicas usadas na produção em massa para reduzir a taxa de defeitos: a análise da causa-raiz para determinar por que os erros são feitos e alterar o processo para que eles não sejam. Ou pelo menos que você pegue antes do QA.

1. Crie uma lista dos seus bugs. Você provavelmente já conseguiu um graças aos caras do controle de qualidade. Possivelmente categorizado também. Tipo de bug, severidade, o ponto em que o bug foi injetado no código, etc.

2. Escolha a maior categoria de bugs. Como seu volume é muito alto, você deve segmentar essa categoria primeiro. Outras categorias incluem as mais fáceis de encontrar e as mais fáceis de fazer.

3. Sabendo onde esses bugs são introduzidos no código, procure fazer alterações nessa fase (e anteriores) que evitem que esses bugs aconteçam, e maneiras de facilitar sua captura nessa fase.

4. Assista a incidentes relacionados à não programação, assim como eles podem fazer a diferença na qualidade do seu trabalho. Música de fundo, interrupções, refeições, trabalhando por muito tempo sem pausa, fome, etc.

O que você encontra pode levar você a ir mais devagar. Por outro lado, pode ajudá-lo a produzir ainda mais rápido, pois você terá menos necessidade de refazer as coisas que já colocou atrás de você. Como é, quatro vezes mais código não está perto de ser uma ordem de magnitude melhor do que seus colegas de trabalho, então mudar o seu processo é definitivamente o caminho a percorrer.

Mude seu objetivo de produzir o maior código para ajudar a empresa a avançar mais.

Como parece que você tem muitos colegas e mais tempo extra disponível, o maior efeito que você pode ter em uma entrega mais rápida de recursos e correções de erros é ajudar seus colegas.

Ajude seus colegas por

• usando revisões de código para melhorar a qualidade e a educação do código.
• criando automação de processos para tornar o trabalho mais rápido e facilitar a vida deles.
• escrevendo testes melhores com eles
• atacando código técnico para melhorar a base de código
• sendo o cara que sempre está disponível para ajudar os outros.
• escrevendo / aprimorando ferramentas que ajudam na produtividade do desenvolvedor
• fazendo o caso com o gerenciamento de melhores ferramentas / equipamentos / condições de trabalho para seus colegas de trabalho, se você tiver mais influência.
• preparando e liderando sessões educacionais sobre como escrever um código melhor.
• praticando humildade

So, how to deal with the fact that increased productivity will lead to an increased number of bugs?

Seu chefe é a única pessoa que pode responder isso no seu caso. Fale com ele, aponte sua melhor relação e deixe que ele decida. Se a sua decisão não faz sentido, é hora de procurar uma empresa com o seu raciocínio.

Como profissional, você deve ser capaz de trabalhar com qualquer condição de cliente, apenas certifique-se de que eles entendam as conseqüências. Um bom gráfico de bugs / histórias pode ajudar seu chefe a entender o quanto sua produtividade irá diminuir se você dedicar menos tempo a produzir bugs.

Você também precisa considerar estes pontos:

• complexidade de histórias, por exemplo, invólucros simples de getter / setter versus cálculos estatísticos ou programação em tempo real ou mesmo estatística em tempo real ...
• gravidade dos bugs, são pequenos erros de digitação nos campos de texto ou resultados errados de cálculo, falhas no programa
• custo para corrigir os bugs, se você fizer isso agora, mais tarde ou se outra pessoa tiver que entender seu código porque você saiu

A situação é que você trabalha quatro vezes mais rápido que o programador médio, mas você comete o dobro de erros em um determinado período de tempo. Em relação à quantidade de trabalho que você faz, você realmente faz o HALF com tantos erros quanto "média".

Você pode tentar apontar seus erros baixos para a proporção de trabalho, ou até mesmo erros para o produto concluído (que você pode completar em um quarto do tempo normal). A maioria dos chefes aceitará isso.

Existem alguns chefes que não o fazem porque trabalham com uma mentalidade de "permissão" de erros por vez. Então, você pode diminuir o ritmo de trabalho, fazer DUAS vezes mais trabalho do que a média em um determinado momento e cometer os mesmos (ou menos) erros, porque você tem mais tempo para verificar seu trabalho.

Se o seu chefe quiser que você melhore a qualidade do seu trabalho, melhore a qualidade do seu trabalho.

Você deve mirar em zero bugs, não visando produzir apenas o dobro do próximo melhor programador.

Você deve dizer ao seu chefe que as métricas que ele está usando são bastante falhas. Se você der uma olhada nos turnovers dos guardas da NBA, verá que eles tendem a ter números mais altos do que os da frente. Mas isso é porque eles estão lidando com a bola mais. Se um guarda que não inicie joga 1/5 tanto quanto um guarda de partida e vira a bola mais de 3 vezes em média. um guarda de partida que vira a bola mais de 7 vezes por jogo - à primeira vista, pode parecer que a guarda de partida é pior. Mas, se você dividir o número de turnovers pelo número de minutos jogados, então a guarda inicial tem números muito melhores baseados nos minutos jogados.

Da mesma forma, você tem números muito melhores se o número de bugs for dividido pelo número de pontos de história concluídos. Então, é isso que eu proporia ao seu gerente. Altere a métrica para o número de bugs dividido pelos pontos de história concluídos ou, pelo menos, adicione uma nova métrica para isso se o número total de bugs por desenvolvedor for necessário. Mas, uma vez que alguns pontos da história são muito mais difíceis e mais complexos do que outros pontos da história, pode haver e haverá bastante variação e isso também precisa ser levado em consideração pelo gerente.

O que eu não acho que você deva fazer é diminuir a velocidade.

Medir valor adicionado

Argumente que o que realmente conta é o valor que você adiciona. Então, vá e introduza uma medição aproximada (manual) disso:

• Estime o valor da funcionalidade que você produz
• Subtraia seu salário
• Subtraia o custo estimado de seus bugs (pelo menos o custo para corrigi-los)
• Subtrair o custo estimado de todas as outras dívidas técnicas que você produz

O restante é seu valor adicionado. Da mesma forma para todos os outros.

Essas estimativas são difíceis, mas até as mais difíceis podem apontar. E o mero processo de discutir essas estimativas é útil para a equipe e o projeto.

Os principais programadores têm a tendência de escrever um código muito regular que é fácil de depurar e entender, eles utilizam ferramentas disponíveis (análise estática, erros do compilador, código de depuração) no máximo. Além disso, os principais programadores já aprenderam o valor do teste unitário através da própria experiência difícil.

Assim, enquanto a quantidade inicial de problemas por linha é a mesma, os problemas são eliminados mais rapidamente.