Incentivar os engenheiros de software a rastrear o tempo

Como posso incentivar meus colegas de trabalho a rastrear o tempo que gastam resolvendo problemas e implementando recursos? Temos software para fazer isso, mas eles simplesmente não inserem os números.

Quero que a equipe melhore no fornecimento de estimativas de projetos comparando nossas estimativas anteriores com o tempo real gasto. Suspeito que meus colegas de trabalho não vejam o benefício pessoal, uma vez que não estão frequentemente envolvidos no cronograma do projeto.

Suspeito que meus colegas de trabalho não vejam o benefício pessoal, uma vez que não estão frequentemente envolvidos no cronograma do projeto.

Isso é corrigível.

Envolva-os no agendamento.

Joel Spolsky escreveu um artigo sobre agendamento baseado em evidências que pode ajudá-lo a encontrar alguns argumentos.

Você precisa convencer seus colegas de trabalho de que melhores habilidades de estimativa podem ajudá-los a produzir um software melhor. Aqui estão alguns pontos a favor do rastreamento do tempo da tarefa:

• Se você tiver um prazo arbitrário definido pelo gerenciamento, boas estimativas indicarão o que você realmente pode realizar nesse período. Como bônus, você tem alguns gráficos interessantes para convencer o gerente de que você sabe do que está falando.
• Você precisa pensar no projeto com mais cuidado. O artigo ao qual vinculei declara: "Você precisa dividir sua agenda em tarefas muito pequenas que podem ser medidas em horas ". Como você pensou em praticamente todas as facetas do projeto (espero escrever uma especificação !), É muito menos provável que você se surpreenda com algo em que não pensou.
• Faz de você um desenvolvedor melhor. Você verá com o tempo quais tipos de tarefas você costuma subestimar, para que possa passar algum tempo melhorando nessas tarefas específicas, em vez de otimizar cegamente.

Você pode fazer isso da maneira padrão - cenouras e palitos.

A cenoura (s) neste caso pode ser "melhor estimativa futura entendendo nossa velocidade atual" - mas você teria que seguir adiante.

Seu comentário de que eles não costumam estar envolvidos no cronograma do projeto pode fazer com que seja uma venda difícil.

O mais alto entre eles, principalmente se você tem seguidores do PSP , é que você está ajudando-os a melhorar.

O bastão mais comum (bater com eles, não segurar a cenoura na frente deles) é "é obrigatório, faça". Embora não seja muito motivador; pelo menos a posição é clara.

Por fim, o software que você está usando contribui para a reticência deles? É desajeitado? Eles precisam procurar códigos de tempo no sistema A antes de dedicar seu tempo ao sistema B? É muito granular, não permite folga e exige uma contabilidade de 8 horas por dia. Torne-o o mais livre de atritos possível para também ajudar na adoção.

Boa sorte

Na minha experiência, a seguir estão os problemas com a maioria dos softwares de rastreamento de tempo:

• O desenvolvedor não tem a capacidade ou autoridade para dividir uma tarefa em subtarefas mais facilmente estimadas em tempo real.
• Não há uma boa maneira de explicar subtarefas que você não conhecia até começar a trabalhar em algo, uma situação que surge o tempo todo no desenvolvimento e na depuração de software.
• O tempo gasto é inserido após o fato, quando é difícil lembrar exatamente quanto esforço concentrado foi feito em uma tarefa e quanto foi para reuniões, perguntas de colegas, revisões por pares e outras despesas gerais.
• Não há uma boa maneira de contabilizar tarefas não rastreadas. No final do dia, você adia 8 horas, apesar de seis delas terem passado em reuniões e coisas assim?
• Não há uma boa maneira de explicar e comunicar incerteza em suas estimativas.

Eu lidei com muitos desses problemas, começando a usar a técnica pomodoro para mim. Se trabalho 25 minutos ininterruptamente em uma tarefa, ela é registrada imediatamente e minhas estimativas são feitas em termos desses intervalos ininterruptos. Ainda estou trabalhando na incorporação de agendamento com base em evidências para comunicar a incerteza e em traduzir meu próprio rastreamento refinado nas estimativas de agendamento grosseiro que as PMs gostam, mas definitivamente tem sido uma melhoria até agora.

Bom caminho

Use um software que torne isso fácil e quase transparente, como por exemplo o Mylyn. Combine-o com ferramentas como, por exemplo, um gráfico de queima de horas.

Maneira ruim

Forçá-los a preencher planilhas de horas tediosas, nas quais é necessário especificar manualmente projeto, tarefa, datas e horários exatos etc.

Se você não é o líder da equipe / PM, então você vai lutar com este. As pessoas não gostam de ouvir seus colegas se isso exigir que eles trabalhem mais do que o absolutamente necessário (na minha experiência, esse é o caso, de qualquer maneira). Tente conversar com o líder da equipe ou com o gerente geral e, se eles concordarem com o seu caso, provavelmente poderão tornar obrigatório o registro de horas (é o que aconteceu onde atualmente trabalho).

Se você é o líder da equipe / PM, precisa ser mais vigoroso em seu papel: essas pessoas estão lá para fazer o que você manda (efetivamente), e se você precisar de mais informações para fazer seu trabalho, peça que elas forneçam isso em formação. Se eles não estão dispostos a ajudá-lo a obter as informações, provavelmente porque eles não entendem por que é útil, tente conversar com eles para explicar como seus projetos geralmente ficam fora do cronograma / superestimados / o que quer que seja e porque está causando isso. você problemas, veja se você pode transformá-los!

Acompanhe seu tempo ou não seja pago. Milhões de pessoas fazem isso (consultores, advogados, etc.), por que não podem?

Alguns podem pensar que isso é bastante draconiano, mas não é. Se você trabalha na Starbucks, precisa limpar o banheiro . Se você trabalha em um banco, usa terno e gravata para trabalhar todos os dias , e se você é um engenheiro de software em uma equipe que precisa que você acompanhe seu tempo, faça isso !

Às vezes, temos que fazer coisas em nossos trabalhos que não gostamos. Somos todos meninos e meninas grandes, acho que deveríamos ser capazes de lidar com isso.

Obviamente, a melhor resposta depende inteiramente da mistura psicológica de sua equipe. Eles são competitivos? Crie um concurso recorrente que premie o vencedor por inserir seu tempo no sistema. Ajuste e afine o concurso para que os jogadores pensem que é justo e divertido. Faça disso um jogo.

Talvez eles estejam preocupados que, se houvesse transparência em quanto tempo eles realmente gastaram na execução de uma tarefa, haveria consequências negativas. Eu sempre me perguntei sobre o design de uma "ferramenta de rastreamento de esforço" que era anônima e onde os buckets eram suficientemente altos o suficiente para haver vários indivíduos despejando quantias gastas em esforço em cada bucket, para que colaboradores individuais não pudessem ser destacados. Mesmo apenas a obtenção de custos de esforço mais precisos para baldes de alto nível do projeto pode ser um dado útil para o planejamento do projeto e a velocidade geral da equipe, mas isso evitaria o "OMG, não acredito que Joe tirou 3x sua estimativa para fazer algo tão simples. . "ou outras coisas que as pessoas têm medo de relatar em um sistema tradicional de controle de tempo.

Eu acho que esses são apenas dois exemplos, mas, na verdade, ter uma boa noção da composição psicológica de sua equipe fornecerá a resposta certa para como incentivar ou encorajá-los a contribuir com suas informações de custo de esforço.

Pense no motivo pelo qual eles não respondem bem a essa solicitação. Não pense apenas que eles são preguiçosos ou evitam esforços.

Os desenvolvedores que evitam produzir evidências geralmente são

• Preocupado com a forma como pode ser usado e / ou
• Preocupado com a validade dos dados

É por isso que a estimativa baseada em pontos e o tamanho da camisa decolaram nos últimos anos. Ele leva em conta a natureza muito incerta do processo de estimativa e permite que a "mágica" (também conhecida como média das incertezas) assuma o controle do agendamento.

E, embora possa não parecer lógico, funciona principalmente - pelo menos tão bem quanto um sistema baseado em horas ou dias. Também é muito difícil agredir uma equipe ou indivíduo de cabeça para baixo com o que eles alcançaram em um mês, se isso for feito de maneira arbitrária.

O Scrum também permite que os desenvolvedores controlem a velocidade, o que significa que eles estão prometendo alcançar o que você escolher entre A, B e C ou A, Y e Z. Quando eles fizeram essa promessa, os desenvolvedores não gostam de falhar; mas se você fizer essa promessa para eles, eles não se importarão. A culpa é sua se estiver errada.

Entendo que você está dizendo que não usaria as reestimações dessa maneira, mas qual a certeza das pessoas de sua equipe sobre isso?

Qualquer ferramenta que exija que os programadores dediquem ainda mais tempo à programação não é necessariamente uma grande coisa. Os programadores já têm muita sobrecarga, não estão tendo reuniões de cinco minutos e então estão programando uma tempestade.

Se você tem o poder, pode forçá-los a fazê-lo. Mas, de longe, a melhor solução é criar uma ferramenta perfeita que a torne indolor. Não sei como fazer isso no design, mas na codificação, você deseja registrar as alterações feitas no ambiente de desenvolvimento. Isso costumava ser uma barra impossivelmente alta, mas se você estiver usando algo como o Eclipse, não é tão ruim assim, talvez já exista. Dessa forma, você pode medir quanto tempo está passando em cada arquivo e, potencialmente, em Java, em cada método. São informações muito mais refinadas do que as solicitadas, e podem ser bastante precisas.

Da mesma forma, se você tiver uma ferramenta para inserir desenhos, poderá interceptar lá.

Depende de como e por que você deseja que eles controlem o tempo, também estamos contando o tempo no escritório ou o tempo gasto no trajeto para trabalhar pensando também no problema?

O agendamento do projeto é difícil e há uma boa chance de as métricas obtidas não serem tão úteis quanto você imagina. Como não há dois problemas iguais, uma tarefa pode levar oito horas, enquanto outra pode levar 32 horas para terminar.

Você pode examinar o agendamento baseado em evidências, pois o desenvolvedor estima quanto tempo levará uma tarefa e, em seguida, ajusta-se ao longo do tempo com base na qualidade das estimativas; no entanto, não é tão bom para projetos grandes, pois talvez você não conheça todas as tarefas antecipadamente. Para projetos grandes, é melhor analisar projetos anteriores de escopo semelhante e usá-los como parâmetro, em vez de tentar agregar estimativas individuais.

Tente apresentá-los a sistemas de organização pessoal, como a técnica Pomodoro, por exemplo (existem muitos outros, mas é o que estou tentando agora)

A técnica usa um temporizador para dividir os períodos de trabalho em intervalos de 25 minutos chamados 'Pomodori' (da palavra italiana para 'tomates') separados por intervalos curtos. Intimamente relacionado a conceitos como timeboxing e desenvolvimento iterativo e incremental usado no design de software, o método foi adotado em contextos de programação em pares. O método baseia-se na ideia de que pausas frequentes podem melhorar a agilidade mental.

Em vez de convencê-los a inserir seus números, use um software que funcione sem esforço. Estou usando o ScreenAware: https://www.screenaware.com/en/ Ele rastreia seu tempo automaticamente e o atribui aos respectivos projetos. Portanto, é sempre preciso e ninguém precisa mais adivinhar

Você já pensou em usar seu sistema de tickets existente? Nosso sistema de tickets monitora o tempo entre a criação de um ticket e quando ele é fechado. Se você criar tickets para tarefas e tornar um número de ticket um requisito para confirmar o código, estará obtendo mais retorno.