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

37

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

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

    
por Jonas 22.08.2011 / 17:05
fonte

7 respostas

47

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 .

    
por 22.08.2011 / 17:10
fonte
18

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).

    
por 22.08.2011 / 17:15
fonte
7

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...

    
por 22.08.2011 / 17:31
fonte
2

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.

    
por 22.08.2011 / 18:32
fonte
1

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

Como consultor, meus clientes geralmente exigem que eu trabalhe com base em lances fixos. Assim, preciso estimar para poder preparar uma oferta realista. Eu nunca consegui uma vez nisso. Alguém poderia pensar que eu iria fazer uma overbid tantas vezes quanto eu underbid, mas isso nunca é o caso. O resultado é que muitas vezes perco muito dinheiro com meus contratos e acabo ganhando muito menos do que se estivesse trabalhando para uma empresa como funcionário regular.

Eu tenho procurado por muitos anos por um livro que me ensinaria como estimar software, mas ainda não encontrei um.

Como para explicar isso para alguém que não é um codificador. Você pode apontar que ninguém na indústria é capaz de atender suas estimativas de maneira consistente. Acontece o tempo todo que os novos produtos de software são pré-anunciados, apenas para enviar meses ou anos após a data originalmente anunciada.

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

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

    
por 22.08.2011 / 17:21
fonte
0

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.

    
por 22.08.2011 / 17:17
fonte
0

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.

    
por 22.08.2011 / 18:02
fonte