Lidar com estimativas como programador júnior

Estou trabalhando há alguns meses em uma empresa que estima (para a população em geral, não para os juniores) tarefas e, em seguida, recebemos a tarefa, resolvemos, passa por dois testes e, no final, a estimativa deve ser um pouco conhecido.

Estou estressado, porque algumas das estimativas são simplesmente impossíveis de serem atendidas. Ainda não conheço o sistema inteiro (porque é bastante substancial), e às vezes metade do tempo é gasto para descobrir o que preciso fazer e onde e quando termino, às vezes a estimativa termina e ainda há testes a serem realizados. feito (e corrigindo erros, se houver).

Na segunda vez que tenho que lidar com uma funcionalidade semelhante, tudo funciona muito mais rápido, mas até agora sinto que sou apenas ruim em programação.

Existe alguma coisa que você fez quando estava começando que o ajudou a superar esse estágio? Fico tão estressado quando vejo quão pouco tempo há para codificar que às vezes nem consigo me concentrar adequadamente no que estou fazendo, o que torna ainda pior.

• Muitos desenvolvedores com pouca experiência em gerenciamento estimam tarefas usando sua própria velocidade ou a velocidade de um "melhor" desenvolvedor em uma equipe.

• A velocidade varia com a experiência. O desenvolvedor sênior pode levar 3 horas para resolver algo, quando você leva 2 dias úteis para resolver o mesmo problema.

• O estresse raramente pode ser evitado quando você assume um novo emprego. Depois de alguns meses, normalmente fica melhor, supondo que você trabalhe o suficiente e faça muitas perguntas relevantes.

• Seus idosos podem não estar cientes de como você se sente em relação às estimativas; portanto, é importante que você pergunte a eles o que eles esperam de você.

Da minha experiência:

• Penso que um desenvolvedor sênior ou um gerente deve ser capaz de estimar uma história de usuário (requisito comercial) em termos de tamanhos de camiseta (XL, L, M, S, XS).

• É tarefa dos desenvolvedores dividir a história do usuário em tarefas menores e calculá-las. Tarefas grandes podem levar um desenvolvedor sênior por dia para serem resolvidas, quando pode levar uma semana inteira.

• É muito importante registrar quanto tempo você realmente levou para concluir a tarefa.

• Um bom gerente de projetos ou desenvolvedor sênior constantemente reunia essas estatísticas. Quando sua produtividade melhorar, eles ficarão cientes disso e enviarão mais trabalho do seu jeito.

Isso não apenas tornará sua vida menos estressante, mas também permitirá que o departamento gerencie seus recursos de maneira eficaz.

Traga isso à tona com o líder da equipe, gerente de projeto e / ou quem faz sua estimativa; não nós. As pessoas entendem que as coisas não exigem o mesmo esforço de todos e podem trabalhar para ajustar as estimativas quando a tarefa é atribuída ou, pelo menos, aliviar qualquer medo que você tenha sobre o período da revisão.

Esta é, na minha opinião, a razão pela qual as estimativas devem ser feitas pelas pessoas designadas para a tarefa (com contribuição / colaboração dos líderes / pares). Você obtém estimativas mais precisas de quanto tempo o trabalho realmente levará as pessoas a realizar.

Não consigo imaginar uma posição pior para colocar um desenvolvedor júnior do que definir uma expectativa que ele não pode manter, a menos que esteja fazendo isso para desafiá-lo. Você teve alguma repercussão real em não atender às estimativas?

Eu diria que primeiro, é importante que você aprendeu a estimar por conta própria. Quando você receber uma tarefa, faça uma estimativa imediata do que você acha que seria necessário e comece a encontrar o delta entre os dois. Quase posso apostar que a qualidade está sendo sacrificada na estimativa inicial curta. Se simplesmente eles esperam que você projete e desenvolva itens mais rapidamente do que você pode, talvez seja necessário conversar com alguém para resolver o problema.

Segundo, entenda que a qualidade é um recurso pelo qual os interessados, seu chefe, decidem pagar. Pode ser algo que você precisará sacrificar um pouco para satisfazer os requisitos no tempo que tiver.

De qualquer forma, elimine o estresse, não é divertido continuar sentindo que você está sempre por trás de escrever códigos ruins. Espero que isto ajude.

Isso é comum.

Em geral, é melhor fornecer estimativas maiores do que menores (na maioria das vezes, você revisará a estimativa). Aconselho você a reduzir a tarefa nas menores subtarefas possíveis e estimar essas tarefas em cada tarefa por mais de 4 horas.

Se uma tarefa demorar mais de 4 horas, divida-a em outro conjunto de subtarefas. Adicione também um buffer percentual para tarefas que você não pode prever agora (minha preferência pessoal é 1 tarefa inesperada para cada 2 tarefas estimadas, cada tarefa inesperada leva de 2 a 4 horas, dependendo do sistema com o qual você está trabalhando).

Depois disso, adicione o tempo que você acha que levaria para testes, comunicação, análise etc.

Primeiro: se você ficar mais rápido com cada tentativa de um problema, provavelmente não é um programador ruim. Então, vamos tirar esse pensamento do caminho.

Eu sugeriria que esta é uma falha dos seus gerentes, mas é e sempre será seu trabalho gerenciar as expectativas.

Em vez de se esforçar por não conseguir cumprir prazos irrealistas, meça quantos dias de trabalho você pode fazer em uma semana. Em seguida, explique ao líder da sua equipe que você é novo no desenvolvimento de negócios e software e que você só pode esperar n dias de trabalho do desenvolvedor sênior em uma semana padrão. Eles deveriam pelo menos entender isso, mesmo que não gostem.

Diga a eles que você espera continuar melhorando e mostre a eles como você pode medir essa melhoria. E concorde com eles que você não espera o salário de um sênior até que você possa fazer cinco dias de trabalho de desenvolvedor sênior em uma semana. Mas, da mesma forma, você não espera as mesmas responsabilidades que um idoso quando não recebe tanto dinheiro.

Para levar isso adiante, é por isso que sou um forte defensor do uso de pontos da história em vez de horas para estimativa. ie Cada trabalho recebe vários pontos, e a equipe estima quantos pontos eles podem alcançar em um determinado período de tempo. No período seguinte, a estimativa é igual à real do período anterior, ajustada por fatores conhecidos, como um mês de férias intensos ou um desenvolvedor saindo.

Como gerente, quando um novo desenvolvedor chega (júnior ou sênior), deixo claro para os negócios que não aumentaremos a estimativa em primeira instância. Espera-se que esse desenvolvedor gaste tanto tempo com outros desenvolvedores quanto economizar. O novo desenvolvedor provavelmente se sairá melhor do que isso, mas a promessa insuficiente e a entrega excessiva é o mantra.

O desenvolvedor melhorará com o tempo, um mais rápido do que um júnior, e a "velocidade" da equipe - a estimativa mês a mês - irá melhorar junto com ele.

Mantenha a calma e continue. Se alguma vez surgir a questão de não atender às estimativas, diga-lhes as mesmas coisas que você escreveu em sua postagem ou, se estiver inseguro, converse sobre isso com seu mentor / líder de equipe.

Estimativas são apenas isso, estimativas. Eles podem e serão desligados, mais ainda quando você estiver aprendendo as cordas. E como júnior, é provável que você esteja aprendendo as cordas como membro da equipe nesse projeto em particular, como programador usando qualquer tecnologia que esteja usando e como funcionário de sua empresa. E se você estiver trabalhando com pessoas sensatas, elas esperam que você esteja de acordo com as estimativas.

Você provavelmente está olhando para as tarefas que está recebendo "de baixo para cima". Suas tarefas são mais importantes para você do que a visão geral do projeto em que você está trabalhando - isso é compreensível. Você vê as estimativas como restrições impostas a você e obviamente está ficando ansioso quando não as encontra.

Mas quando você olha para o cenário geral, verá que as estimativas, ainda mais que as 'metas' para os desenvolvedores, são 'sinais' para os líderes / gerentes de projeto. Dividir o trabalho em tarefas e calculá-las é uma maneira de diminuir a complexidade de gerenciar e estimar todo o projeto. Acompanhar o trabalho real realizado versus as estimativas é um meio de acompanhar o desempenho do projeto, mas é apenas uma das métricas que podem ser aplicadas. Quando as estimativas não são atendidas regularmente, é um sinal para o gerente que há algo errado com o projeto. Mas em qualquer projeto razoável, não haverá um desenvolvedor júnior na equipe que não atenda às estimativas.

Deixe-me apresentar-lhe meus dois amigos, WAG e SWAG

Ou seja, o 'palpite selvagem' e o 'palpite científico'

Acredite ou não, eu não inventei isso. Eles são realmente muito comuns nos negócios. Dê uma olhada neste artigo para ver o que quero dizer.

Idealmente, é melhor apresentar uma estimativa firme, mas se você não puder, é melhor afirmar que a estimativa é aproximada devido a dados incompletos do que mentir.

A chave é que os negócios não são programação de computadores. Gerenciar expectativas é mais importante que precisão. É importante avaliar o tempo que você acha que levaria mais 10% como contingência para compensar problemas imprevisíveis.

Se você superestimar, eles ficarão felizes quando você terminar com tempo de sobra. Se você subestimar, eles não ficarão desapontados se você cumprir o prazo ou extremamente desapontados se algo der errado.

Os negócios são uma área cinzenta que algumas pessoas adquirem uma sensação intuitiva ao longo do tempo. O fato de estarem pedindo a um desenvolvedor júnior que tome esse tipo de decisão independentemente diz uma coisa. Ou eles não têm ninguém disponível que seja mais capaz de tomar esse tipo de decisão ou os gerentes não querem assumir a responsabilidade por falhas.

Eu apostaria meu dinheiro se você estiver trabalhando para uma grande organização. Quando um modelo de negócios hierárquico cresce o suficiente, a parte superior fica tão longe da base que os superiores só podem medir o progresso pelo que recebem no papel. É um ambiente terrível, porque geralmente são feitas promoções para não cometer erros. Mas as pessoas que recebem as promoções evitam o fracasso, pressionando suas responsabilidades sobre os outros (ou seja, incompetência cega) e assumindo o crédito pelo sucesso das pessoas mais baixas da cadeia.

Infelizmente, programadores são alvos fáceis de jogar 'debaixo do barramento', porque não importa o tamanho do problema, tentaremos encontrar uma solução. A chave é que não gaste mais tempo determinando como estimar o problema do que implementando a solução.

Esse é um lugar difícil. Parece que você está preso no estágio "apenas tenho que entregar" desse pipeline.

Ao longo dos anos, observei o seguinte sobre estimativa: A qualidade de uma estimativa pode ser determinada respondendo (com um nome próprio) às três perguntas a seguir.

• Quem fez o design?
• Quem fez a estimativa?
• Quem está fazendo a implementação?

A qualidade da estimativa é inversamente proporcional ao número de indivíduos distintos nomeados. Por exemplo: a melhor estimativa é quando a mesma pessoa executou as três tarefas acima, uma estimativa fraca é quando uma pessoa projetou / estimou e outra fará a implementação, e a pior estimativa é aquela em que todas as três perguntas são respondidas com um nome único.