Por que os programas de software são tão difíceis de definir?

39

Parece que, na minha experiência, conseguir que os engenheiros calculem e determinem com precisão as tarefas a serem concluídas é como puxar os dentes. Em vez de apenas dar uma estimativa de ganho de 2-3 semanas ou 3-6 meses ... qual é a maneira mais simples de definir cronogramas de software para que eles não sejam tão difíceis de definir? Por exemplo, o cliente A quer um recurso até 02/01/2011. Como você agendar o tempo para implementar esse recurso, sabendo que outras correções de bugs podem ser necessárias ao longo do caminho e ocupar tempo adicional de engenharia?

    
por Brian 08.01.2011 / 04:00
fonte

13 respostas

57

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

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

Frequentemente pedimos 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 sobre nossas experiências passadas. Por isso, é natural que a estimativa seja mais difícil.

    
por 08.01.2011 / 04:26
fonte
35

De acordo com minha experiência pessoal, é exatamente o oposto de o que o Pemdas disse : com a prática, acabei de entender que é totalmente impossível estimar quanto tempo uma tarefa exigirá. No início da minha carreira no desenvolvimento de software, muitas vezes eu dei estimativas como "45 dias", "cinco semanas", etc., então tentei muito para terminar a tempo. Alguns anos depois, comecei a dar estimativas menos precisas como "aproximadamente um mês", "cinco a sete semanas", etc. Na verdade, tento não dar nenhuma estimativa, ou peço ao cliente que forneça sua própria estimativa. ou prazo ou eu dou uma estimativa tão áspera quanto 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 o seu trabalho depende de coisas aleatórias, como outros povos trabalham, sua motivação, etc. Aqui está uma lista mais detalhada das possíveis razões:

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

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

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

  4. Os clientes gostam de alterar seus requisitos exatamente quando você acabou de finalizar a parte em questão , e eles realmente não entendem por que você está solicitando mais duas semanas e $ 2000 para fazer um tiny mudar, porque eles não veem que esta pequena alteração requer para mudar outras coisas, o que exige mudar os outros, 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 programador StackExchange e passa horas lendo e respondendo 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 seu trabalho para terminar o meu. Este designer levou 3 meses antes de entregar um pedaço de porcaria inutilizável. Claro que o projeto atrasou.

  7. Sua estimativa também depende do seu cliente . Eu tinha clientes que passavam semanas antes de responder às correspondências. Isso pode realmente afetar o seu cronograma quando você deve esperar pela resposta (por exemplo, se você está pedindo a eles que precisem um requisito).

O que você pode fazer?

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

  2. Seja claro . Se você confiar em um designer, outro desenvolvedor, etc., diga. Em vez de dizer "Eu entregarei o produto em três meses", diga "Eu entregarei o produto em dois meses depois que o designer me der 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 dê uma estimativa quando você usa um produto que você não conhece bem ou, especialmente, quando você trabalha com um código-fonte de outra pessoa: você nunca pode prever quão ruim o código-fonte pode ser e como muito tempo você passará a compreensão e copiando e colando-o no The Daily WTF.

por 08.01.2011 / 04:30
fonte
15

Uma pergunta muito parecida é "Quanto tempo levará para resolver esse enigma de palavras cruzadas?"

Você não pode responder até que tenha visto algumas coisas como:

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

Como geralmente há várias coisas novas em um projeto (caso contrário, não seria um projeto), não é possível saber quanto tempo levarão para resolver até que você tenha uma visão cuidadosa delas. Talvez até resolva mais ou menos ou eles, e então você ainda não está certo de que não há uma surpresa ou duas em que você não tenha pensado neles.

Também há uma strong 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 vai para a pressurização do gerente de projeto, mas sim para o desenvolvedor que forneceu a estimativa. Não são necessárias muitas iterações para o desenvolvedor detectar isso e aprender a estar MUITO cansado de dar números absolutos.

    
por 08.01.2011 / 16:44
fonte
11

The most obvious reason why you engineers can't give you accurate estimates is that it's impossible.

É claro que você pode estimar quanto tempo + -2 minutos ele levará da sua casa para o trabalho. Você sabe dirigir um carro, avaliar o tráfego e alguns outros fatores externos.

Diga-me quanto tempo você levará para ir de Londres a Barcelona. Sem quaisquer ferramentas avançadas de planejamento GPS, é claro. Usando o bom e velho método como ainda fazemos na estimativa de software. Estimativa empírica e previsões .

No software, é pior:

  1. As estimativas costumam se tornar um compromisso , por isso nosso julgamento é modificado.
  2. Pode haver grandes diferenças entre a estimativa de Bob e Karl para a mesma tarefa.
  3. Incertezas são muito comuns, como muitos de nós ficam presos em um bug estúpido ou em uma falha no disco rígido que destrói qualquer boa estimativa aparente.
  4. Geralmente esquecemos de todas as outras tarefas do que a programação incluindo reuniões, telefonemas, ajuda ao colega, etc.
  5. O cérebro humano é limitado . Não foi concebido para estimar tarefas de longa duração.

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

Para resolver todos esses problemas, recomendo técnicas avançadas de estimativa, como Planning Poker (aviso legal: este é um dos meus sites) e Desenvolvimento Iterativo com Velocity .

  • Os dois primeiros problemas são abordados usando o Planning Poker. As estimativas são coletivas e a equipe é proprietária delas, e não de 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 você a agregar valor aos seus usuários desde o início.
por 08.01.2011 / 12:35
fonte
6

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

A única vez que tudo relacionado ao desenvolvimento de software é conhecido é quando o software está completo.

A única vez em que não há nenhuma tecnologia ou recurso empresarial desconhecido é uma solução completa e pronta para download.

A razão pela qual escrevemos um novo software é porque temos um novo recurso, uma 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.

    
por 08.01.2011 / 04:49
fonte
3

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

    
por 08.01.2011 / 04:13
fonte
2

Nunca é fácil. Você apenas tenta melhorar.

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

Se eles tiverem uma definição estrita de um recurso que precisam em um tempo definido, precisarão saber que recursos adicionais precisam ser alocados a essa solicitação. Eles estão assumindo um risco na gravidade dos erros que ocorrem e por quanto tempo podem passar sem que sejam corrigidos. Quando algo importante surge, você volta para o cliente e os força a tomar uma decisão. Eu corrijo o bug ou faço o prazo final no novo recurso? Dê-lhes informações suficientes para tomar uma decisão informada.

Espero que você tenha histórico suficiente de trabalho 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 fazer com que eles sintam que você está fazendo um esforço honesto e não aproveitando a falta de conhecimento deles.

    
por 08.01.2011 / 04:25
fonte
2

Porque nós fazemos o cronograma cedo demais. Veja o artigo do Construx fazendo um preliminar áspero, então melhor um depois. Além disso, se você não acompanhar como fez em estimativas anteriores, será difícil melhorar. O FogBugz faz isso [um cliente do seu livre, nenhum outro conflito de interesses].

    
por 08.01.2011 / 05:01
fonte
2

Aprendi muito com este livro:

Estimativa de software: desmistificando a arte negra

Em suma, para obter melhores resultados de estimativa, fazemos isso:

  1. todas as tarefas triviais são estimadas por mais de uma pessoa (duas no nosso caso)
  2. dividimos a tarefa em tarefas menores. Quanto mais tarefas você tiver, maior será a probabilidade de sua estimativa ser boa - lei de números grandes, se eu me lembrar corretamente do boo
  3. estimamos o cenário pior, melhor e mais provável. Às vezes, cada um de nós estima esses cenários de árvore de forma totalmente diferente. Isso significa que temos que conversar e geralmente acontece que um de nós não entendeu a tarefa. Se essa pessoa tivesse estimado a tarefa sozinha, seria estimado errado.
  4. colocamos 3 números do ponto acima na equação e recebemos a estimativa (excell) k

Após o término da tarefa de trabalho e nossa estimativa estar errada, tentamos descobrir os motivos. E incorporamos esse conhecimento no próximo processo de estimativa. Até agora, este é o melhor processo que usei para estimar tarefas maiores. Quando digo tarefa, quero dizer trabalhos que demoram entre 50 e 500 horas.

    
por 07.03.2013 / 23:38
fonte
1

Observação: isso realmente se aplica apenas a projetos em que você fatura por hora em comparação a uma taxa fixa / fixa.

Eu costumo tentar planejar minha programação para que ela consista essencialmente em um SCRUM Sprints (usando SCRUM ou não). Na frente, ao fazer a programação, determino qual será o comprimento de cada sprint e quais serão os recursos para o projeto. Tipicamente, há algumas características que precisam ser feitas primeiro, então tento dar uma estimativa melhor (não confundir com otimista) para essas e quaisquer características que estarão no final do projeto terão estimativas generalizadas. Depois de mapear os recursos para sprints, tento adicionar de 1 a 2 sprints no final do projeto para considerar os recursos que deslizam para a direita e para os recursos que foram negligenciados na coleta de requisitos original.

A chave para isso é que eu faço tudo isso transparente para o cliente com antecedência, para que eles entendam por que os últimos dois sprints estão vazios ou escassamente povoados. Pelo menos até este ponto, os clientes com quem trabalhei gostaram disso, pois sabem que há alguma reserva no cronograma / finanças, já que a maioria deles sabe que as estimativas de SW tendem a ser menos concretas. Eles também estão cientes de que, se não precisarmos do último sprint, então são horas que não cobramos. Com a transparência de como o cronograma é construído e o feedback regular sobre como o progresso está indo durante a execução do projeto, cada cliente com o qual fiz isso ficou extremamente satisfeito.

    
por 08.01.2011 / 19:03
fonte
1

Além de todas as coisas nomeadas, vejo essas duas coisas como alguns dos maiores problemas. Primeiro você estima a data final com base em cada devloper estar disponível para o total de 8 horas por dia, 5 dias por semana. Isso é incorreto e praticamente garantirá que a data de término seja perdida em qualquer projeto que não seja trivial. As pessoas tiram folga, participam de reuniões da empresa (ou não), brigam com o RH por causa de sinistros de seguro de saúde, fazem pausas, etc. Nunca assumam mais de 6 horas de disponibilidade por desenvolvedor por dia.

Os próximos desenvolvedores notoriamente esquecem de estimar todas as tarefas que não são de desenvolvimento, como reuniões e e-mails sobre o projeto, implantação, suporte ao controle de qualidade, suporte à UAT, testes de unidade de escrita, pesquisa, documentação, etc. Uma vez que adicionamos esses tipos de tarefa à nossa estimativa planilha, nossas estimativas ficaram muito melhores.

    
por 07.03.2013 / 21:17
fonte
1

Quando se trata de estimativa de tempo para tarefas que podem levar mais tempo do que algumas horas, faço o meu melhor para usar essas regras:

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

Provavelmente há mais regras do que isso, mas na verdade não tenho um cartaz com essas regras na minha parede. Eu acabei de formulá-las agora, mas elas vêm da minha experiência (então pode não funcionar para você).

A única maneira confiável de programar o desenvolvimento de software que eu posso imaginar (mas eu realmente não tentei) é Programação Baseada em Evidência que é basicamente o método Monte Carlo usado para contar a probabilidade de uma data de envio com base em registros históricos sobre tarefas que você realizou antes. É legal porque não tenta usar outras métricas além do tempo estimado e real. No entanto, é preciso muita experiência para dividir tarefas grandes em tarefas menores e você precisa ter um grande conjunto de dados históricos para que funcione com precisão suficiente.

    
por 07.03.2013 / 22:25
fonte
1

Existem "desconhecidos conhecidos" e "desconhecidos desconhecidos". : -)

  1. As estimativas costumam se tornar prazos.

    • Ninguém quer perder um prazo e virar manchete!
  2. Os requisitos mudam (geralmente de forma racional) 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 é afetada
    • Qualidade do código do qual ela depende
    • Arquitetura geral e design do sistema
    • APIs para acessar outras partes do sistema
por 07.03.2013 / 20:05
fonte