Quels sont les plus gros goulots d'étranglement lors du développement de grands projets? [fermé]

Disons que mon entreprise devait développer une réplique de MS Word (à titre d'exemple). Quel serait le goulot d'étranglement du processus de développement, en supposant que l'on dispose d'une trésorerie infinie et d'une organisation comme Microsoft? En d'autres termes, quels sont les obstacles les plus courants au développement rapide de tels logiciels? Supposons que toutes les spécifications soient en place et que l'organisation fonctionne parfaitement, nous nous concentrons donc uniquement sur le développement logiciel jusqu'à ce que le produit soit prêt à être expédié. Certaines alternatives peuvent être: - Écriture du code - Écriture de tests - Test manuel du produit final - Réécriture du code en raison d'une mauvaise conception en premier lieu - Conception du code - Examen du code effectué par des développeurs expérimentés - Conception de l'interface graphique - Nouvelle conception de l'interface graphique basée sur alpha / Commentaires des utilisateurs bêta - Traitement des commentaires des utilisateurs - En attente des commentaires des utilisateurs alpha / bêta

Veuillez utiliser des références dans votre réponse ou indiquer votre expérience sur le sujet.

D'après mon expérience, le principal «goulot d'étranglement» est le processus d'apprentissage . Lorsque votre entreprise hypothétique se propose de développer le prochain Microsoft Word, il y a un énorme fossé entre ce que vous devez savoir et ce que vous savez réellement. La taille de l'écart dépend de nombreux facteurs, qu'il s'agisse de la technologie ou du domaine. Vous avez abordé certains de ces problèmes dans votre question, par exemple la conception, les commentaires des utilisateurs, etc. Microsoft Word est en développement depuis plus de 30 ans maintenant, donc entre l'histoire, le code, les outils et les gens, il y a beaucoup de connaissances derrière.

Donc, si je devais essayer de le faire, j'essaierais d'embaucher les meilleures personnes ayant une expérience dans le domaine, à la fois technique et de gestion. Essayez de lire toute la littérature disponible dans le domaine. J'essaierais également d'obtenir les commentaires des clients dès que possible. Le plus gros problème est les choses critiques que vous ne savez pas et que vous pourriez découvrir très tard dans votre processus.

Soit dit en passant, cela n'est pas propre aux projets logiciels. C'est vrai pour chaque projet à grande échelle où vous essayez de faire quelque chose de nouveau. Par exemple, regardez le Boeing Dreamliner. Il existe de nombreux livres écrits à ce sujet. Le Mois de l'homme mythique en est un.

Supposons que toutes les spécifications soient en place et que l'organisation fonctionne parfaitement.

Vous avez supposé que les deux plus gros "goulots d'étranglement" dans les processus de développement logiciel n'existent pas (d'après mes expériences personnelles).

Même dans votre monde hypothétique et parfait, je peux voir certains problèmes:

Le plus important, selon moi, est probablement le traitement des clients. D'après ma propre expérience, l'entreprise doit traiter avec des clients qui essaient fréquemment de changer le projet pendant son développement. Dans certains cas, ils ont essayé d'envoyer une demande de changement comme correction de bogue pour éviter d'avoir à payer de l'argent. Cela peut conduire à beaucoup de bureaucratie qui peut retarder un projet ou conduire à des hacks rapides dans le code qui se transforment en dette technique plus loin. J'ai lu et entendu parler d'équipes qui s'occupent de ces problèmes aussi facilement que de respirer, et je souhaite vraiment être dans l'un d'entre eux :)

Le deuxième problème est le manque d'un modèle de domaine approprié. Eric Evans fournit une bonne couverture à ce sujet dans son livre: Domain Driven Design . L'absence d'un bon modèle de domaine conduit à certains des problèmes mis en évidence dans la réponse de Glenn, comme essayer de localiser un bogue. Sans modèle de domaine propre, il peut être long de parcourir / déboguer le code pour isoler et résoudre un problème. Je dirais qu'un bon modèle de domaine rend la vie et le débogage beaucoup plus faciles, encore plus lors de la maintenance et de l'extension de l'application plus loin.

Les problèmes que j'ai mentionnés ci-dessus ne génèrent pas de problèmes immédiats, mais si vous devez entretenir ce produit pendant une longue période, ils peuvent revenir vous hanter, vous et votre équipe.

Je ne sais pas ce que vous entendez par "l'organisation fonctionne parfaitement", mais même dans une organisation fantastique, le plus gros goulot d'étranglement dans un projet de taille est la communication. Le Mois de l'homme mythique montre comment, au fur et à mesure qu'une équipe de projet se développe, les combinaisons de communication explosent, garantissant presque des erreurs et des informations manquées.

D'après ce que j'ai vu jusqu'à présent au travail, une grande source de goulot d'étranglement vient simplement des bogues et de l'erreur humaine qui les a créés. Pensez simplement au temps nécessaire pour déboguer le code, trouvez une solution au problème, puis testez à nouveau la nouvelle solution. Imaginez maintenant si ce correctif provoquait un autre bug subtil. Cela peut être un flux de douleur majeur et ralentit ainsi le développement global.

Je pense que Brandon Moretz a la meilleure réponse. Mais je veux ajouter que l'extraction de la première version d'un grand projet n'est pas si difficile. Personnellement, je n'ai jamais manqué de le faire.

Ce que je n'ai pas réussi à faire, c'est de créer la première version de telle sorte que la deuxième, la troisième version, etc.

Oui, je serai d'accord avec les éléments ci-dessus et il doit suivre les modèles de logiciels.À ma connaissance, les principaux éléments sont:

1. Gestion du temps 2. Efficacité de l'équipe et gestion de l'équipe 3. Coordination en équipe et 4. Meilleure compréhension avec le client

Si nous avons les quatre ci-dessus, nous pouvons passer à un nouveau monde avec succès et beaucoup d'amélioration en termes de personnalité et de logiciel, ce qui conduit à de bonnes relations avec le client et le client donnera les commandes sans penser à nous.

Défauts latents, en termes d'exigences, de conception, d'implémentation, de déploiement .... Imaginez le développement de logiciels où chaque nouveau bogue était causé par les changements les plus récents.