Por que as programações de software são tão difíceis de definir?

Parece que, na minha experiência, levar os engenheiros a estimar e determinar com precisão as tarefas a serem concluídas é como puxar os dentes. Em vez de apenas fornecer uma estimativa de ganhos de 2 a 3 semanas ou 3 a 6 meses ... qual é a maneira mais simples de definir programações de software para que elas não sejam tão difíceis de definir? Por exemplo, o cliente A deseja um recurso até 01/01/2011. Como você programa o tempo para implementar esse recurso, sabendo que outras correções podem ser necessárias ao longo do caminho e ocupam um tempo adicional de engenharia?

Se você está desenvolvendo um projeto quase idêntico a outros projetos que você já fez, usando ferramentas familiares e uma equipe familiar e recebe requisitos firmes e escritos, deve ser possível fazer uma boa estimativa.

Essas são as condições que os pintores, instaladores de carpetes, paisagistas etc. experimentam regularmente. Mas não é uma boa opção para muitos (ou muitos) projetos de software.

Muitas vezes nos pedem para estimar projetos que usam novas ferramentas, tecnologias, onde os requisitos estão mudando, etc. Isso é mais extrapolação para o desconhecido do que interpolação em nossas experiências passadas. Portanto, é natural que a estimativa seja mais difícil.

De acordo com minha experiência pessoal, é exatamente o oposto do que Pemdas disse : com a prática, acabei de entender que é totalmente impossível estimar quanto tempo uma tarefa exigirá. No início de minha carreira em desenvolvimento de software, muitas vezes forneci estimativas como "45 dias", "cinco semanas" etc., e depois tentei com muito esforço terminar com o tempo. Alguns anos depois, comecei a fornecer estimativas menos precisas, como "aproximadamente um mês", "cinco a sete semanas" etc. Na verdade, tento não fornecer nenhuma estimativa ou pedir ao cliente que faça sua própria estimativa. ou prazo ou faço uma estimativa o mais aproximada possível.

Por que é tão difícil ter uma estimativa? Porque é quase impossível saber como todo o código-fonte será escrito antes de realmente escrevê-lo, e porque seu trabalho depende de coisas aleatórias à medida que outras pessoas trabalham, sua motivação etc. Aqui está uma lista mais detalhada dos possíveis motivos:

1. Não é fácil saber exatamente o que é necessário para fazer um produto, e especialmente como fazê-lo . Muitas vezes iniciei algumas partes de um aplicativo que, após dias de trabalho, entendiam que minha primeira abordagem estava errada e que havia uma maneira melhor e mais inteligente de fazer as coisas.

2. Alguns problemas podem surgir . Por exemplo, se, para começar seu trabalho, você deve instalar em sua máquina um servidor SQL sofisticado e a instalação falhar e o suporte não existir, você pode passar semanas resolvendo esse problema.

3. Os requisitos geralmente não são claros o suficiente , mas depois de lê-los no início, você pensa que são. Às vezes, você pode entender que a média 'A' e, depois de começar a implementá-las, você perceberá que elas talvez signifiquem 'B'.

4. Os clientes gostam de alterar seus requisitos exatamente quando você termina a parte em questão , e eles realmente não entendem por que você está solicitando mais duas semanas e US $ 2000 para fazer uma pequena alteração, porque não vêem que essa pequena alteração requer mudar outras coisas, que exigem mudar outras, etc.

5. Você não pode estimar sua motivação . Há dias em que você pode trabalhar por horas e ter sucesso. Há semanas em que, depois de escrever dez linhas de código, você alterna para o Programmers StackExchange e passa horas lendo e respondendo a perguntas.

6. As coisas ficam muito ruins quando sua estimativa depende de outras pessoas . Por exemplo, em um projeto de 2 meses, tive que esperar que um designer fizesse o trabalho dele para terminar o meu. Esse designer levou três meses para entregar um pedaço de lixo inutilizável. Claro que o projeto estava atrasado.

7. Sua estimativa também depende do seu cliente . Eu tive clientes que passam semanas antes de responderem seus e-mails. Isso pode realmente afetar sua agenda quando você deve esperar pela resposta (por exemplo, se você estiver solicitando que eles precisem de um requisito).

O que você pode fazer?

1. Dê uma agenda maior . Se você acha que pode fazer o trabalho em duas semanas, diga que o entregará em um mês.

2. Seja claro . Se você conta com um designer, outro desenvolvedor etc., diga. Em vez de dizer "Entregarei o produto em três meses", diga "Entregarei o produto em dois meses depois que o designer me fornecer arquivos PSD".

3. Explique que se os requisitos mudarem todos os dias, o projeto dificilmente será entregue a tempo.

4. Fatie sua programação . Entregar partes de um grande projeto no prazo é mais fácil.

5. Nunca faça uma estimativa quando você usa um produto que não conhece bem ou, especialmente, quando trabalha com o código-fonte de outra pessoa: nunca é possível prever o quão ruim o código-fonte pode ser e quanto tempo você gastará entender e copiar e colar no The Daily WTF.

Uma pergunta muito semelhante é "Quanto tempo levará para resolver este jogo de palavras cruzadas?"

Você não pode responder até que você tenha visto isso para ver várias coisas como:

• Está em um idioma familiar? (Espanhol versus inglês versus chinês)
• É um de um tipo que já resolvemos antes? (Um de uma série sendo publicada em uma revista, por exemplo)
• Algum dos leads requer conhecimento adicional antes que possamos entendê-lo?
• Existe em algum lugar do quebra-cabeça coisas que, a seu conhecimento, exigirão trabalho adicional?

Como geralmente existem várias coisas novas em um projeto (caso contrário, não seria um projeto), você não pode dizer quanto tempo elas levarão para serem resolvidas até que você as tenha observado com muito cuidado. Talvez até resolva mais ou menos, ou então, e você ainda não tem certeza de que não há uma surpresa ou duas em que não pensou nelas.

Também há uma forte pressão para fazê-lo o mais barato possível, portanto, o mais rápido possível e a culpa por uma estimativa muito baixa não recai sobre o pressurizador do gerente do projeto, mas com o desenvolvedor fazendo a estimativa. Não é preciso muitas iterações para o desenvolvedor entender isso e aprender a ficar MUITO cansado de fornecer números absolutos.

A razão mais óbvia pela qual os engenheiros não podem fornecer estimativas precisas é que isso é impossível .

Claro que você pode estimar quanto tempo + -2 minutos levará de sua casa para o trabalho. Você sabe dirigir, pode avaliar o tráfego e alguns outros fatores externos.

Diga-me quanto tempo levará para você dirigir de Londres a Barcelona. Sem nenhuma ferramenta avançada de planejamento de GPS, é claro. Usando o bom e velho método, como ainda fazemos na estimativa de software. Estimativas empíricas e previsões .

No software, é pior:

1. As estimativas geralmente se tornam um compromisso , portanto nosso julgamento é modificado.
2. Pode haver grandes diferenças entre a estimativa de Bob e Karl para a mesma tarefa.
3. As incertezas são muito comuns: quantos de nós ficamos presos a um bug estúpido ou falha no disco rígido, destruindo qualquer boa estimativa aparente.
4. Geralmente esquecemos todas as outras tarefas além da programação, incluindo reuniões, telefonemas, ajuda ao nosso colega, etc.
5. O cérebro humano é limitado . Não foi projetado para estimar tarefas de execução longa.

É por isso que é impossível dizer ao seu cliente o que você poderá enviar para o 02/01/2011 com boa precisão e esquecer o 01/03/2011.

Para resolver todos esses problemas, recomendo técnicas avançadas de estimativa, como o Planning Poker (aviso: este é um dos meus sites) e o desenvolvimento iterativo com cálculo de velocidade .

• Os dois primeiros problemas são abordados usando o Planning Poker. As estimativas são coletivas e a equipe as possui, e não os indivíduos.
• Os últimos terceiros problemas são abordados usando o Velocity e o Desenvolvimento Iterativo. Ao conhecer sua velocidade (o fator a ser aplicado às suas estimativas com base no histórico), você pode planejar lançamentos com mais confiança. O desenvolvimento iterativo, quando bem feito, traz os recursos mais importantes para o topo e ajuda a agregar valor aos seus usuários desde o início.

O desenvolvimento de software é - por definição - um ato de descoberta e invenção. Sempre deve envolver algo desconhecido.

O único momento em que tudo relacionado ao desenvolvimento de software é conhecido é quando o software está completo.

O único momento em que não há tecnologia ou recurso comercial desconhecido é quando é uma solução completa e empacotada pronta para download.

A razão pela qual escrevemos um novo software é porque temos um novo recurso ou nova tecnologia ou ambos. Novo significa novo - desconhecido - imprevisível.

Como o desenvolvimento de software deve envolver novidade, o esforço de desenvolvimento não pode ser previsto.

Honestamente, acho que é preciso praticar. Se você escrever código suficiente eventualmente, deve ser "razoavelmente" preciso. Meu primeiro chefe acreditou que essa habilidade era importante o suficiente para que ele solicitasse que eu praticasse isso informalmente em todos os recursos / projetos que implementei. Após cada projeto, revisamos as estimativas e tentamos descobrir onde errei. Eventualmente, você pega o jeito.

Isso nunca é fácil. Você apenas tenta melhorar.

Uma vantagem de dividir seu código de entrega em pedaços menores é que os clientes entendam o que esperar e quando esperar. Agora você tem algum tipo de linha de base para usar como referência.

Se eles tiverem uma definição estrita de um recurso que precisam em um horário definido, precisam saber que recursos adicionais devem ser alocados a essa solicitação. Eles estão arriscando a gravidade dos erros que ocorrem e quanto tempo eles podem durar sem que eles sejam corrigidos. Quando algo importante surge, você volta ao cliente e o força a tomar uma decisão. Corrijo o bug ou faço o prazo para o novo recurso? Dê a eles informações suficientes para tomar uma decisão informada.

Espero que você tenha histórico suficiente de trabalho em conjunto e tenha se estabelecido o suficiente para ser confiável. Você não pode esperar que eles entendam completamente o processo de desenvolvimento, mas você pode fazê-los sentir que estão fazendo um esforço honesto e não tirando proveito da falta de conhecimento deles.

Porque fazemos a programação muito cedo. Veja o artigo da Construx sobre como fazer uma preliminar preliminar e depois uma melhor. Além disso, se você não acompanhar como se saiu nas estimativas anteriores, é difícil melhorar. O FogBugz faz isso [um cliente gratuito, nenhum outro conflito de interesses].

Eu aprendi muito com este livro:

Estimativa de software: desmistificando a arte negra

Em suma, para obter melhores resultados de estimativa, fazemos o seguinte:

1. todas as tarefas, exceto as triviais, são estimadas por mais de uma pessoa (duas no nosso caso)
2. dividimos tarefa em tarefa menor. Quanto mais tarefas você tiver, maior será a probabilidade de sua estimativa - lei de grandes números, se bem me lembro do boo
3. estimamos o pior, o melhor e o mais provável cenário. Às vezes, cada um de nós estima esses cenários de árvores de maneira totalmente diferente. Isso significa que precisamos conversar e, geralmente, um de nós não entendeu a tarefa. Se uma pessoa estimasse a tarefa sozinha, seria incorreta.
4. colocamos 3 números do ponto acima na equação e recebemos a estimativa (excell) k

Depois que a tarefa de trabalho é concluída e nossa estimativa está errada, tentamos encontrar os motivos. E incorporamos esse conhecimento no próximo processo de estimativa. Até agora, esse é o melhor processo que usei para estimar tarefas maiores. Quando digo tarefa, quero dizer trabalhos que levam de 50 a 500 horas.

Nota: isso realmente se aplica apenas a projetos nos quais você fatura por hora versus uma taxa fixa / fixa.

Normalmente, tento planejar minha agenda para que ela consista essencialmente em um monte de SCRUM Sprints (usando ou não SCRUM). Na hora de fazer o cronograma, determino qual será o comprimento de cada sprint e quais serão os recursos do projeto. Normalmente, existem alguns recursos que precisam ser executados primeiro, então tento fornecer uma melhor estimativa (não confundir com otimista) para aqueles e quaisquer recursos que estejam no final do projeto terão estimativas generalizadas. Depois de mapear os recursos para os sprints, tento adicionar 1 a 2 sprints no final do projeto para explicar os recursos que deslizam para a direita e os que foram ignorados na reunião de requisitos original.

A chave para isso é que eu faço tudo isso transparente para o cliente antecipadamente, para que eles entendam por que os dois últimos sprints estão vazios ou pouco preenchidos. Pelo menos até este ponto, os clientes com quem trabalhei gostaram disso, pois sabem que há alguma margem na programação / finanças, pois a maioria deles sabe que as estimativas de SW tendem a ser menos concretas. Eles também sabem que, se não precisarmos do último sprint, mais ou menos, essas são horas que não faturamos. Com a transparência na forma como o cronograma é construído e o feedback regular sobre o andamento da execução do projeto, todos os clientes com quem eu fiz isso ficaram extremamente satisfeitos.

Além de todas as coisas mencionadas, vejo essas duas coisas como alguns dos maiores problemas. Primeiro, você estima a data final com base em todos os devloper disponíveis durante as 8 horas diárias 5 dias por semana. Isso está incorreto e praticamente 100% garante que a data de término seja perdida em qualquer projeto que não seja trivial. As pessoas tiram uma folga, participam de reuniões da empresa (ou não baseadas em projetos), brigam com o RH por reivindicações de seguro de saúde, fazem pausas etc. Nunca assuma mais do que uma disponibilidade de 6 horas por desenvolvedor por dia.

Os próximos desenvolvedores esquecem-se notoriamente de estimar todas as tarefas de não desenvolvimento, como reuniões e emails sobre o projeto, implantação, suporte ao controle de qualidade, suporte ao UAT, testes de unidade de escrita, pesquisa, documentação etc. as estimativas ficaram muito melhores.

Quando se trata de estimativa de tempo para tarefas que podem demorar mais do que algumas horas, tento o meu melhor para usar estas regras:

1. Não sempre tentar prever quando outras pessoas vão terminar o seu trabalho, se tiver que dependem dele. Fale apenas por si mesmo.
2. Primeiro analise a tarefa e depois faça uma estimativa. Ao analisar, quero dizer, pelo menos, escrever (e não tentar manter tudo em sua cabeça!) Uma lista de subtarefas com estimativa para cada uma delas.
3. Se uma tarefa for suficientemente complexa, estime o tempo para essa análise. Deixe a estimativa ser um processo separado. Você também pode garantir que seu chefe saiba disso.
4. Não faça estimativas sob pressão. Deixe claro que leva tempo para fazer uma estimativa razoável e diga a eles algo como "Vou nomear uma data amanhã às 11:00 quando terminar de analisar a tarefa". Eu sei que alguns clientes / gerentes podem pressionar com força, mas não devem passar. Coloque seu rosto ocupado e reivindique seu tempo!
5. Peça um pouco mais de tempo do que você imagina, porque provavelmente se esqueceu de adicionar um intervalo para o café (e outras distrações) em sua estimativa.
6. Para grandes tarefas, peça ainda mais - provavelmente haverá mais de uma pausa para o café.
7. Se você realmente não pode estimar (a tarefa é muito difícil / desconhecida) ou realmente não tem certeza - pergunte a alguém capaz de ajudar com sua análise.

Provavelmente há mais regras do que isso, mas na verdade não tenho um pôster com essas regras na minha parede. Acabei de formulá-los agora, mas eles vêm da minha experiência (por isso pode não funcionar para você).

A única maneira confiável de agendar o desenvolvimento de software em que posso pensar (mas ainda não o experimentei) é o Agendamento Baseado em Evidências, que é basicamente o método de Monte Carlo usado para calcular a probabilidade de uma data de envio com base em registros históricos das tarefas que você ' já fizemos antes. É bom porque não tenta usar nenhuma métrica além do tempo estimado e real. No entanto, requer muita experiência para dividir grandes tarefas em tarefas menores de antemão e você precisa ter um grande conjunto de dados históricos para fazê-lo funcionar com precisão suficiente.

Existem "incógnitas conhecidas" e "incógnitas desconhecidas". :-)

1. As estimativas geralmente se tornam prazos.

   • Ninguém quer perder um prazo e se tornar manchete!

2. Os requisitos mudam (geralmente racionalmente) e o programador não pode vetá-lo.

3. O programador / pode não ter controle sobre fatores como

   • Disponibilidade do código em que ela é dependente
   • Qualidade do código em que ela depende
   • Arquitetura geral e design do sistema
   • APIs para acessar outras partes do sistema