Como explicar que é difícil estimar o tempo necessário para um projeto de software maior?

Sou desenvolvedor júnior e acho difícil estimar quanto tempo leva para concluir um projeto de software maior. Sei como estruturar a arquitetura em geral, mas é difícil saber quais detalhes tenho que fazer e quais problemas tenho que resolver. Portanto, é difícil estimar quanto tempo levará para concluir um projeto maior, porque não sei quais problemas eu preciso resolver e quanto tempo leva para resolvê-los.

Como explico isso para uma pessoa que não é desenvolvedor de software ?

Você pode pedir que ele calcule quanto tempo levará para acessar um local distante em um canto desabitado do mundo. Como exemplo extremo, vamos escolher um pico menos conhecido no Himalaia, onde pouquíssimas pessoas (se houver) já escalaram. Ela precisaria de muita preparação e prática antes mesmo de começar a jornada, além de várias permissões, cada uma das quais pode atrasar a viagem por meses a anos ... e uma boa equipe de apoio ... e depois subir a colina em uma encosta, ela precisaria esperar e orar por um bom tempo para começar a subir em direção ao pico ... etc. etc. Muitos deles são difíceis de estimar, mesmo com experiências anteriores.

E o ponto é: cada projeto de software é um pouco como escalar uma nova montanha, onde ninguém havia estado antes; portanto, ninguém tem experiência anterior direta. Desenvolvedores experientes podem ter adquirido experiência em projetos mais ou menos semelhantes , mas sempre haverá novos elementos e surpresas - caso contrário, se um projeto de software fosse exatamente como o anterior, não haveria sentido em fazê-lo .

Você já explicou isso para a pessoa? Você é o engenheiro de software profissional; portanto, a pessoa para quem você está desenvolvendo o software deve considerar o seu conhecimento e feedback quando se trata de design e implementação de sistemas de software.

O Cone da Incerteza é provavelmente um bom ponto de partida. É difícil estimar os projetos de software até que mais detalhes sejam conhecidos, o que acontece mais tarde no projeto. Além disso, a alteração dos requisitos também alterará as estimativas. Suas estimativas iniciais no início de um projeto terão uma grande quantidade de variabilidade.

Você também pode estar interessado em outras técnicas de estimativa. Você mencionou que é apenas um desenvolvedor júnior. Geralmente, desenvolvedores mais experientes têm uma melhor capacidade de estimar, pois viram mais problemas, os resolveram e (esperançosamente) acompanharam a estimativa versus o tempo real. Você pode tirar proveito disso usando técnicas de estimativa como delphi de banda larga ou planejando pôquer .

Como desenvolvedor júnior, comece a acompanhar as estimativas e o tempo real agora. Você pode estar interessado em ler sobre o Processo de Software Pessoal desenvolvido no Software Engineering Institute. Os principais livros do PSP são Uma disciplina para engenharia de software , PSP: Um processo de auto-aperfeiçoamento para engenheiros de software e Introdução ao processo de software pessoal . Acredito que a Introdução ao processo de software pessoal cobriria os tópicos que você consideraria mais úteis. Eu acho que geralmente é um exagero para a maioria dos desenvolvedores, mas ele tem algumas boas idéias e boas práticas que podem ser extraídas e usadas para melhorar a produtividade pessoal e aprimorar várias habilidades (incluindo estimativas) que você usará continuamente ao longo de sua carreira.

Se você estiver fazendo muito mais trabalho de estimativa, eu recomendo dois livros de Steve McConnell: Estimativa de Software: Desmistificando a Arte Negra (concentra-se na estimativa como arte e ciência) e Desenvolvimento Rápido: Domando Wild Software Schedules (software geral tópicos de processo de engenharia e gerenciamento de projetos).

Consulte a literatura. Há uma pilha enorme de material complexo e muitas vezes contraditório, que, conforme comprovado pela prática (experimentos), não funciona como esperado. Pelo menos os acadêmicos são influenciados por uma pilha de livros.

Leitura obrigatória: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

O Mês do Homem - Mês: Ensaios sobre Engenharia de Software é um livro sobre engenharia de software e gerenciamento de projetos de Fred Brooks, cujo tema central é que "adicionar mão de obra a um projeto de software atrasado o torna mais tarde". Essa idéia é conhecida como lei de Brooks e é apresentada juntamente com o efeito do segundo sistema e a defesa da prototipagem.

As observações de Brooks são baseadas em suas experiências na IBM enquanto gerenciam o desenvolvimento do OS / 360. Ele havia adicionado mais programadores a um projeto que estava atrasado, uma decisão que ele mais tarde concluiria contra-intuitivamente por atrasar ainda mais o projeto. Ele também cometeu o erro de afirmar que um projeto - escrever um compilador ALGOL - exigiria seis meses, independentemente do número de trabalhadores envolvidos (era necessário mais tempo). A tendência dos gerentes de repetir esses erros no desenvolvimento do projeto levou Brooks a zombar de que seu livro se chame "A Bíblia da Engenharia de Software", porque "todo mundo cita, algumas pessoas lêem e outras seguem". O livro é amplamente considerado um clássico sobre os elementos humanos da engenharia de software ...

Descubra o que eles planejam fazer com essa estimativa. Eles querem saber se levará meses ou anos e você está tentando obter as horas exatas (engenheiro típico).

Veja se você pode trabalhar em uma parte do projeto e, em seguida, faça uma estimativa melhor, se necessário.

Se eles continuarem pressionando, você será forçado a especificar o máximo de tarefas possível e aplicar um período de tempo. Diga a eles que você os informará assim que vir algo que possa afetar a estimativa e fazer ajustes. As pessoas geralmente tentam evitar surpresas.

Eu conheci pessoas que afirmam que podem estimar software, mas não sei como o fazem. Nenhum deles foi capaz de explicar como o fazem.

Como consultor, meus clientes geralmente exigem que eu trabalhe com base em lances fixos. Portanto, preciso fazer uma estimativa para preparar um lance realista. Eu nunca tive sucesso nisso. Alguém poderia pensar que eu superaria tantas vezes quanto subestimei, mas esse nunca é o caso. O resultado é que muitas vezes perco muito dinheiro em meus contratos e acabo ganhando muito menos do que ganharia se estivesse trabalhando para uma empresa como funcionário regular.

Há muitos anos, procuro um livro que me ensine a estimar software, mas ainda não o encontrei.

Quanto a explicar isso para alguém que não é um codificador. Você pode salientar que ninguém no setor é capaz de atender consistentemente às suas estimativas. Acontece o tempo todo que novos produtos de software são anunciados, apenas para serem enviados meses ou anos após a data que foi originalmente anunciada.

Se uma grande empresa como a Microsoft não consegue descobrir como estimar o tempo gasto na produção de seus próprios produtos, como posso?

Quer eu esteja sendo pago por hora ou pelo trabalho, meus clientes sempre esperam que eu forneça essas estimativas. Não sei como eles esperam que eu os produza quando essa estimativa não é ensinada em lugar algum, e não tenho base racional para minhas estimativas.

A estimativa do tempo inteiro do projeto geralmente é executada pelo gerente do projeto e não pelo programador.

Você pode criar um argumento com base no fato de que o gerente de projeto possui a lista completa de tarefas necessárias. Sem essa lista, qualquer estimativa será um palpite 'ruim'.

Além disso, o tempo depende de muitos fatores, como quantas pessoas estão disponíveis e o escopo dos requisitos, que você não disse ter. Somente a arquitetura não é suficiente.

Outro ponto que você poderia destacar é que a engenharia de software ainda está engatinhando em comparação com outros campos da engenharia e não amadureceu o suficiente para que as técnicas de desenvolvimento estimadas aparecessem.

A engenharia de software também está em um estado contínuo de fluxo. Quando uma tecnologia existe o suficiente para ser considerada madura, ela é frequentemente abandonada em favor de alguma nova tecnologia. Isso impede que alguém obtenha experiência suficiente com qualquer tecnologia para produzir estimativas confiáveis.

Compare isso com a estimativa de construção. Esse é um problema muito bem compreendido, não apenas porque os contratos são concedidos com base em licitações, mas porque a humanidade vem construindo coisas desde o início da civilização.