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

Você poderia pedir a ele / ela para estimar quanto tempo levaria para ela acessar algum local distante em um canto desabitado do mundo. Como um exemplo extremo, vamos escolher um pico menos conhecido nos Himalaias, onde pouquíssimas (se alguma) pessoas já subiram. Ela precisaria de muita preparação e prática antes mesmo de começar a jornada, além de um monte de permissões, cada uma das quais pode atrasar a viagem por meses ou anos ... e uma boa equipe de apoio ... então uma vez na colina inclinação, ela precisaria esperar e rezar para o bom tempo para começar a subir para o pico ... etc etc A maioria destes é difícil impossível estimar, mesmo com experiência prévia.

E o ponto é: cada projeto de software é um pouco como escalar uma nova montanha, onde ninguém esteve antes, então ninguém tem experiência prévia direta. Desenvolvedores experientes podem ter acumulado 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 alguns anterior, não haveria absolutamente nenhum ponto fazê-lo .

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

O Cone of Uncertainty é provavelmente um bom ponto de partida. Projetos de software são difíceis de estimar até que mais detalhes sejam conhecidos, o que acontece mais tarde no projeto. Além disso, a mudança de requisitos também mudará as estimativas. Suas estimativas iniciais no início de um projeto terão uma grande variabilidade.

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

Como desenvolvedor júnior, comece a rastrear estimativas e o tempo real agora. Você pode estar interessado em ler sobre o Processo de Software Pessoal desenvolvido no Instituto de Engenharia de Software. Os principais livros da PSP são Uma Disciplina para Engenharia de Software , PSP: Um Processo de Auto-Melhoria para Engenheiros de Software , e Introdução ao Processo Pessoal de Software . Acredito que Introdução ao Processo de Software Pessoal abrangeria os tópicos que você consideraria mais úteis. Eu acho que geralmente é um exagero para a maioria dos desenvolvedores, mas tem boas idéias e boas práticas que podem ser retiradas e usadas para melhorar a produtividade pessoal e aprimorar várias habilidades (incluindo estimativa) que você usará continuamente durante sua carreira.

Se você estiver fazendo muito mais trabalho na estimativa, eu recomendo dois dos livros de Steve McConnell: Estimativa de software: Desmistificando a Arte Negra (enfoca a estimativa como arte e ciência) e o Desenvolvimento Rápido: Domar os Programas Selvagens de Software (processo geral de engenharia de software e tópicos de gerenciamento de projetos).

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

Deve ler: link

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping.

Brooks' observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later counter-intuitively conclude to have delayed the project even further. He also made the mistake of asserting that one project — writing an ALGOL compiler — would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it." The book is widely regarded as a classic on the human elements of software engineering...

Descubra o que eles planejam fazer com essa estimativa. Em sua mente, 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 um pedaço do projeto e, em seguida, montar uma estimativa melhor, se necessário.

Se eles continuarem pressionando, você será forçado a listar 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.

A estimativa de todo o tempo do projeto é geralmente realizada pelo gerente de projetos e não pelo programador.

Você pode construir um argumento baseado no fato de que o gerente de projeto tem 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. Arquitetura sozinha não é suficiente.

Outro ponto que você poderia fazer é que a engenharia de software ainda está em sua infância em comparação com outros campos da engenharia, e não amadureceu o suficiente para que surgissem técnicas de desenvolvimento estimáveis.

A engenharia de software também está em um estado contínuo de fluxo. Até o momento uma tecnologia tem sido suficiente para ser considerada madura, é muitas vezes abandonada em favor de alguma nova tecnologia. Isso impede que qualquer pessoa ganhe experiência suficiente com qualquer tecnologia para gerar estimativas confiáveis.

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