Como acompanhar a produtividade da programação diariamente? [fechadas]

Como posso saber se estou desenvolvendo software mais ou menos produtivo do que nos dias anteriores?

Há uma resposta simples: você não pode. E além disso, você não deveria.

Você quer medir sua própria produtividade, mas pode generalizar: como você pode medir a produtividade dos programadores? Antes de tudo, você precisa definir o que você quer dizer com "produtividade": quantidade de código produzido? Quantidade de projeto (ou especificação) implementada? Número de problemas corrigidos? Qualidade do código produzido? (Sim, a qualidade é um contador de produtividade, você pode produzir muitos códigos ruins ou poucos códigos bons, o que foi mais produtivo?). Todos esses valores dificilmente podem ser mapeados para uma base diária, e qualquer tentativa de rastrear a produtividade diária é perigosa para o projeto, para a empresa e para o programador.

Meu conselho é definir claramente o que você quer dizer com "produtividade", definir uma unidade de medida e aplicá-la semanalmente e mensalmente.

Eu diria que a melhor maneira de medir sua produtividade é definir uma meta a cada dia para o que você deseja fazer naquele dia e, se a concluir, considere produtiva. É uma medida bastante subjetiva, mas você provavelmente a achará muito mais gratificante do que objetiva.

Ambas as sugestões abaixo podem ser adotadas aproximadamente para sua necessidade, mas em ambos os casos você precisa fazer estimativas antecipadamente e depois analisá-las ad hoc (e sinceramente, não tenho certeza se existe outra maneira eficaz de medir isso, concordo com o TheLQ, que linhas de código por período não são utilizáveis).

Metodologias de desenvolvimento ágil
Embora não tenha certeza da eficácia com que ele pode ser aplicado a um único cenário de desenvolvedor, alguns dos princípios usados ​​no Agile podem ser úteis no que você pretende alcançar. O Agile trabalha em ciclos nos quais os desenvolvedores pretendem implementar histórias (tarefas) que são pontuadas (em pontos) com base na complexidade da implementação no início de um ciclo de desenvolvimento e depois analisadas no final de cada ciclo. Isso permite determinar a velocidade, ou seja, o número de pontos que um desenvolvedor ou uma equipe pode concluir dentro de um único ciclo de desenvolvimento.

Se a maneira como você trabalha permite adotar alguns dos princípios e organizar seu trabalho em ciclos, você pode usar a métrica de velocidade por ciclo de desenvolvimento para rastrear sua eficiência. Observe que os ciclos geralmente duram de 2 a 3 semanas; no entanto, você poderá reduzi-los ao usá-lo apenas para si. Tudo se resume a se você pode adotar essa metodologia em seu ambiente.

Programação baseada em evidências
Mesmo que o objetivo principal seja melhorar as estimativas, você poderá usá-lo de forma eficaz para rastrear tendências decrescentes de produtividade.

Concorde com Lorenzo, defina a produtividade.

Também fiz o seguinte: 1. Divida todas as tarefas (quebra de nível alto ou baixo). 2. Estime o horário de trabalho de cada tarefa (não esqueça de definir o buffer de atraso para cada tarefa). 3. Finalize a tarefa. 4. Revise cada uma das tarefas e verifique se você é produtivo o suficiente ou não.

Aqui está uma medida significativa e precisa da produtividade que envolve a tomada de várias instantâneos de agendamento baseados em evidências :

Depois de reunir alguns dias de estatísticas, execute sua simulação de Monte Carlo e observe o gráfico, que deve ser assim:

Em seguida, faça mais um dia de trabalho e execute a simulação novamente. Se você foi produtivo naquele dia, o gráfico deve mudar algo como isto:

Mais importante, se você fosse um produto nesse dia, a probabilidade da data de envio em qualquer data deve aumentar desde a última vez que você executou a simulação antes desse dia de trabalho. Se diminuir, você foi menos produtivo naquele dia.

Obviamente, a precisão do EBS aumenta com o tempo e a experiência, de modo que pode ser outro motivo para a alteração no valor da probabilidade da data de envio. É por isso que você deseja começar a fazer isso pelo menos depois de alguns dias de trabalho amostrado. Mesmo sem isso, porém, se você fosse significativamente mais produtivo em um dia ou outro, a probabilidade aumentaria consideravelmente.

A contagem de linhas de código é uma medida imperfeita, pois não oferece insights sobre a qualidade do código, mas pode ser usada para determinar a produtividade geral. Dependendo do idioma que você usa, existem ferramentas diferentes que contarão linhas de código para você, mas solicitei que o BitBucket, um Repositório Git, adicione estatísticas relacionadas à produtividade.

https://bitbucket.org/site/master/issue/4307/feature-request-contributor-statistics

Meça o tempo que você leva para se sentar no computador pela manhã até realizar qualquer atividade não relacionada ao trabalho, como 9gag, facebook, reddit etc. Sua produtividade naquele dia é proporcional a esse número.

Suponha por um momento que ser produtivo esteja gerenciando seu tempo, de modo que você esteja utilizando todo o seu tempo de trabalho para concluir suas tarefas e que qualquer coisa que contribua para o desperdício de tempo - ou seja: tempo gasto na conclusão de suas tarefas - não é produtivo.

A única coisa que você realmente pode fazer é registrar seu tempo quando envolvido em várias atividades ao longo do dia. O time boxing é uma técnica usada para vários propósitos, mas seria adequado a esse esforço para registrar sua atividade durante um dia. Passe 15 minutos em um cronômetro simplesmente executando algumas tarefas. Se a tarefa é algo em que você deveria estar trabalhando, seu tempo foi produtivo. Se você estava editando seu blog, lendo um jornal ou sonhando acordado com aquela garota legal em contabilidade, provavelmente seu tempo era improdutivo. Aumente seus minutos no final do dia e você terá uma idéia de quão produtivo é ...

Mas há um problema! O que você faz nesses outros minutos ... você sabe, fazendo uma pausa de 5 minutos, indo almoçar, tendo seu chefe interrompendo você para falar sobre o peixe grande que ele não pescou em sua última viagem de pesca? Registre tudo isso também. O tempo gasto em uma pausa não é desperdiçado se contribuir para a sua saúde mental e bem-estar ... desde que você não faça uma pausa de 5 minutos a cada 10-15 minutos! Quanto ao resto, interrupções, lidando com outras questões relacionadas ao trabalho ... tudo isso pode ser rastreado.

É claro que você pode ficar obcecado com esse tipo de coisa, e que Deus o ajude se o chefe for uma daquelas pessoas que vê você no time-boxe e usa isso para justificar razões para acumular mais trabalho ou criticar seus esforços. Veja bem, o problema com a obsessão durante as horas produtivas é que você pode trabalhar durante um dia inteiro e ainda assim não conseguir fazer nada relevante. Em alguns dias, você pode escrever um código como se fosse manteiga derretendo diretamente do seu cérebro, e naquele sanduíche que você chama de tela ... enquanto outros dias você pode ter um sério bloqueio mental ao tentar 357 maneiras diferentes de fazer o mesmo coisa, apenas para vê-lo falhar. Muitos diriam que "falhas" contínuas podem ser improdutivas, e isso por si só não será ajudado, não importa quanto tempo você calcule e registre suas horas durante o dia.

A outra maneira de ver isso é simplesmente definir uma série de objetivos, concluir durante um dia e uma semana e depois trabalhar para cumpri-los. Se você realmente atingir seus objetivos, poderá argumentar que foi produtivo e, se não atingir seus objetivos, poderá entender por que não os alcançou e decidir se foi ou não produtivo. com base nos motivos reais para perder seus objetivos. Por fim, se você entregar o código de trabalho quando necessário, e se conseguir que seus testes passem e uma tarefa seja concluída, estará produtivo. As medições só terão valor se houver uma razão legítima para analisá-las estatisticamente mais tarde.