Quais são os maiores gargalos no desenvolvimento de grandes projetos? [fechadas]

Digamos que minha empresa desenvolvesse uma réplica do MS Word (apenas como exemplo). Qual seria o gargalo do processo de desenvolvimento, supondo que se tenha dinheiro infinito disponível e uma organização como a Microsoft? Em outras palavras, quais são os obstáculos mais comuns para o desenvolvimento rápido desse software? Vamos supor que todas as especificações estejam em vigor e a organização esteja funcionando perfeitamente, portanto, focamos apenas no desenvolvimento de software até que o produto esteja pronto para ser enviado. Algumas alternativas podem ser: - Escrever o código - Escrever testes - Testar manualmente o produto final - Reescrever o código devido ao mau design em primeiro lugar - Projetar o código - Revisão do código feita por desenvolvedores experientes - Projetar GUI - Redesenhar a GUI com base em alfa / feedback do usuário beta - Processando feedback dos usuários - Aguardando feedback do usuário alfa / beta

Por favor, use referências em sua resposta ou declare sua experiência sobre o assunto.

Na minha experiência, o principal "gargalo" é o processo de aprendizado . Quando sua empresa hipotética se propõe a desenvolver o próximo Microsoft Word, existe uma enorme lacuna entre o que você precisa saber e o que realmente sabe. O tamanho da lacuna depende de muitos fatores, pode estar na tecnologia ou no domínio. Você abordou alguns desses problemas na sua pergunta, por exemplo, design, feedback do usuário etc. O Microsoft Word está em desenvolvimento há mais de 30 anos. Portanto, entre a história, o código, as ferramentas e as pessoas, há muito conhecimento por trás disso.

Portanto, se eu tentasse fazer isso, tentaria contratar as melhores pessoas com experiência no domínio, técnica e de gerenciamento. Experimente e leia toda a literatura disponível no campo. Eu também tentaria obter o feedback do cliente o mais rápido possível. O maior problema são as coisas críticas que você não sabe e pode descobrir muito tarde no seu processo.

A propósito, isso não é exclusivo de projetos de software. É verdade para todos os projetos de grande escala em que você está tentando fazer algo novo. Por exemplo, veja o Boeing Dreamliner. Existem muitos livros escritos sobre isso. O Mês do Homem Mítico é um.

Vamos supor que todas as especificações estejam em vigor e a organização esteja funcionando perfeitamente.

Você presumiu que os dois maiores "gargalos" nos processos de desenvolvimento de software não existem (pelas minhas experiências pessoais).

Mesmo em seu mundo hipotético e perfeito, há alguns problemas que posso ver:

Provavelmente o mais importante, do meu ponto de vista, é lidar com os clientes. Na minha própria experiência, a empresa precisa lidar com clientes que frequentemente tentam alterar o projeto enquanto ele está sendo desenvolvido. Em alguns casos, eles tentaram usar uma solicitação de mudança como uma correção de bug para evitar pagar qualquer dinheiro. Isso pode levar a muita burocracia que pode atrasar um projeto ou levar a hacks rápidos no código, que se transforma em dívida técnica mais adiante. Eu li e ouvi falar de equipes que lidam com esses problemas com a facilidade de respirar, e com certeza gostaria de estar em um deles :)

A segunda questão é a falta de um modelo de domínio adequado. Eric Evans fornece uma boa cobertura sobre isso em seu livro: Domain Driven Design . A falta de um bom modelo de domínio leva a alguns dos problemas destacados na resposta de Glenn, como tentar localizar um bug. Sem um modelo de domínio limpo, pode ser demorado percorrer / depurar o código para isolar e corrigir um problema. Eu argumentaria que um bom modelo de domínio facilita muito a vida e a depuração, ainda mais ao manter e estender o aplicativo mais adiante.

Os problemas que mencionei acima não produzem problemas imediatos, mas se você precisar manter esse produto por um longo período, eles poderão voltar para assombrar você e sua equipe.

Não sei ao certo o que você quer dizer com "a organização está funcionando perfeitamente", mas mesmo em uma organização fantástica, o maior gargalo em qualquer projeto considerável é comunicação. O Mythical Man Month mostra como, à medida que a equipe do projeto cresce, as combinações de comunicação explodem, quase garantindo erros e informações perdidas.

Pelo que vi até agora no trabalho, uma grande fonte de gargalo vem simplesmente dos bugs e do erro humano que os criou. Pense no tempo que leva para depurar o código, encontre uma correção para o problema e teste novamente a nova solução. Agora imagine se essa correção causou outro bug sutil. Pode ser um grande fluxo de dor e, assim, retarda o desenvolvimento geral.

Eu acho que Brandon Moretz tem a melhor resposta. Mas quero acrescentar que não é tão difícil obter a primeira versão de um projeto grande. Eu pessoalmente nunca deixei de fazer isso.

O que não consegui fazer foi criar a primeira versão de forma que a segunda, terceira versão etc e / ou correções de bugs e / ou aprimoramentos menores de recursos também possam ser entregues em tempo hábil.

Sim, eu vou concordar com as coisas acima e deve seguir os modelos de software. Conforme meu conhecimento, as principais coisas são:

1. Gerenciamento de tempo 2. Eficiência da equipe e gerenciamento de equipe 3.Coordenação em equipe e 4. Melhor entendimento com o cliente

Se tivermos os quatro acima, podemos mudar para um novo mundo com sucesso e muita melhoria em termos de personalidade e software. Isso leva a um bom relacionamento com o cliente e o cliente dará os pedidos sem pensar em nós.

Defeitos latentes, em requisitos, design, implementação, implantação .... Como em coisas que estão quebradas, mas você ainda precisa encontrá-las. Imagine o desenvolvimento de software onde cada novo bug foi causado pelas alterações mais recentes.