ti-enxame.com

Como acompanhar a produtividade da programação diariamente?

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

16
Tamara Wijsman

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.

18
Wizard79

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 você a concluir, considere produtiva. É uma medida bastante subjetiva, mas você provavelmente a achará muito mais gratificante do que objetiva.

7
sp0rus

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 diferentes ferramentas 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

2
Kevin

Ambas as sugestões abaixo podem ser adotadas aproximadamente para sua necessidade, mas nos dois casos você precisa fazer estimativas antecipadamente e depois analisá-las ad hoc (e honestamente, não tenho certeza se existe outra maneira eficaz de medir isso, concordo com o TheLQ, que as 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 velocidade por ciclo de desenvolvimento métrica 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
Embora o objetivo principal seja melhorar as estimativas, você deve poder usá-lo efetivamente para rastrear tendências decrescentes de produtividade.

2
MicE

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. Reveja cada uma das tarefas e verifique se você é produtivo o suficiente ou não.

2
VinkyH

Aqui está uma medida significativa e precisa da produtividade que envolve a captura de vários agendamento com base em evidências instantâneos:

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

enter image description here

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:

enter image description here

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 trabalhos. 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.

2
Rei Miyasaka

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.

1
Minthos

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 tudo o 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 boxe com horário é 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 realizando alguma tarefa. 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 ideia 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 a 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 nada de relevância real. Em alguns dias, você pode escrever um código como se fosse manteiga derretendo diretamente do seu cérebro, e no 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, talvez precise 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 passar nos testes e concluir uma tarefa, estará produtivo. As medições só terão valor se houver uma razão legítima para analisá-las estatisticamente mais tarde.

0
S.Robins