Quem deve participar da estimativa de tempo?

Em um projeto de TI:

1. Quem deve participar da estimativa de tempo? Desenvolvedor, líder de equipe, scrum master e etc?
2. De quem é o voto mais importante?

Não se trata tanto das pessoas envolvidas, mas também das habilidades que precisam estar presentes:

• Uma boa compreensão do domínio do problema - isso é particularmente importante quando os requisitos são ambíguos ou de alto nível. Como programador que nunca trabalhou em viagens para estimar o trabalho referente a classes de bilhetes em um avião, eles assumem que existem 3 ou 4 (economia, negócios, primeiro etc.), mas se você trabalhou em viagens, saberá que existem dezenas. Isso pode significar que um analista de negócios ou usuário especializado esteja envolvido, embora com o tempo os próprios desenvolvedores desenvolvam esse tipo de conhecimento.

• Uma compreensão da tecnologia e do trabalho que estará envolvido - geralmente um desenvolvedor, embora um gerente com experiência recente e que tenha a confiança da equipe possa fazer o trabalho com frequência. O ideal é que você inclua a pessoa que realmente fará o trabalho da maneira como é incluída na estimativa.

• Uma compreensão do processo de estimativa - isso é fundamental. É preciso entender como fazer uma estimativa decente, como garantir que está correto, verificar os níveis adequados de contingência, verificar a contagem dupla ou o preenchimento excessivo. Geralmente, um gerente de desenvolvimento, gerente de desenvolvimento ou desenvolvedor sênior o trará, embora em alguns processos um modelo de estimativa sólido possa fornecer as orientações necessárias.

Essas habilidades podem estar em uma pessoa, embora às vezes elas precisem de três ou mais, mas o principal é garantir que essas habilidades estejam presentes, e não que determinadas pessoas estejam presentes.

Dito isto, geralmente, embora eu procure mais de duas pessoas, como você deseja a garantia adicional que duas ou mais pessoas verificando o trabalho umas das outras traz.

Em termos de cujo voto é mais contado, não funciona assim. É uma discussão e uma negociação. Se um gerente acha que os desenvolvedores estimam que é muito alto, ele precisa explicar por que e desafiar (e não pressionar) o desenvolvedor a justificá-lo e precisa chegar a um consenso. Caso você não consiga chegar a esse acordo, eu diria duas coisas por experiência:

(a) Não vá com o número que você "deseja", está apenas pedindo problemas e o que você deseja não tem impacto material na rapidez com que o trabalho pode ser feito.

(b) Em quase todos os casos que vi onde um desenvolvedor foi governado por uma estimativa, o número final ficou mais próximo do que o desenvolvedor pensava do que quem o dominava - principalmente porque ignorou o ponto (a) acima.

(Dito isso no Agile, acredito que, e certamente no XP, a regra é que os desenvolvedores controlem as estimativas, e isso é final. Se os usuários querem diminuir as estimativas, precisam alterar o requisito para algo mais simples.)

Não sei se há uma resposta única para essa pergunta. Onde trabalho, geralmente existem dois engenheiros da equipe que implementam o recurso / correção que fornece uma estimativa. Portanto, dois engenheiros fornecem uma estimativa "min", "max" e "esperada". Normalmente, esperamos que ambas as estimativas sejam razoavelmente consistentes; portanto, se são muito diferentes, uma discussão adicional pode ser necessária (talvez um engenheiro tenha feito suposições de que o outro não fez, etc.).

Na nossa situação, o "voto" de ninguém é contado como tal. Normalmente, calculamos a média das duas estimativas (lembre-se, se elas ainda não estão no mesmo estádio, rejeitamos as duas e começamos as discussões novamente, portanto, calcular a média não é um grande salto). Afinal, as estimativas são apenas estimativas, portanto, não precisam ser exatas .

Na minha experiência, as estimativas tendem a ser feitas pela pessoa que provavelmente fará a tarefa em si. As equipes do SCRUM devem se esforçar para ser multifuncionais, mas depois de um tempo, certos tipos de tarefas geralmente são executados pelas mesmas pessoas.

De importância vital é aceitar a equipe em todas as estimativas. Se um desenvolvedor achar que possui uma estimativa, trabalhará para atendê-la. Se os desenvolvedores receberem uma estimativa de que eles não fizeram a si mesmos e não tiveram influência ou influência, eles não sentirão o mesmo nível de responsabilidade e os descobertos serão explicados com "Eu disse a você que levaria mais tempo".

Um projeto possui requisitos e prazos de negócios que vêm de cima para baixo. Essas são "estimativas dadas" para a primeira iteração.

Esses requisitos devem ser particionados para as maiores tarefas com custo 100% conhecido (como "ativar o log" = 2 horas = "faça o download do log4j / SLF4J e conecte").

A estimativa deve ser feita no nível mais alto possível, que já tenha experiência técnica suficiente para fazê-lo.

As estimativas corrigidas devem retornar na forma de "recurso visível da empresa" = "esse período de tempo" até atingir o proprietário da empresa em um nível apropriado, capaz de eliminar / alterar requisitos ou relaxar os prazos. Então volte para baixo. Até convergência final. Na prática, as pessoas tendem a ignorar essa fase ou simplificá-la, o que por sua vez pode criar riscos associados a prazos e oportunidades perdidos.

Quem ou quem deve participar da estimativa de tempo? Desenvolvedor, líder de equipe, scrum master e etc?

Eu prefiro que todos estejam lá na estimativa de tempo e fazemos o mesmo aqui

Quem ou quem deve ser o mais votado?

Desenvolvedor, mas ainda assim, tudo sobre o trabalho em equipe novamente

OS DESENVOLVEDORES CARREGADOS COM A IMPLEMENTAÇÃO DO PROJETO! NINGUÉM MAIS!

Os desenvolvedores que estão realizando as mãos no trabalho e os líderes da equipe de desenvolvimento são os únicos capazes de estimar adequadamente quanto tempo realmente levará. Somente programadores familiarizados com a base de código real podem entender as possíveis dificuldades e armadilhas que podem ser encontradas no decorrer do desenvolvimento. Todo mundo é um 'espectador'.

Além disso, a única maneira de confiar nos desenvolvedores para fornecer estimativas precisas é quando os empresários confiam neles e confiam em sua experiência, de modo que os desenvolvedores saibam que não serão penalizados se a estimativa não atender às expectativas da empresa.

Regra geral: levará pelo menos três vezes a estimativa de qualquer gerente de projeto ou pessoa de negócios que não esteja familiarizado com os desafios do desenvolvimento prático e com a base de código em questão.

Como alguém que trabalhou como desenvolvedor no free-lancer e como empregado em grandes empresas por quase 20 anos, digo isso com a maior certeza e com o benefício de uma experiência amarga.