Comment expliquer qu'il est difficile d'estimer le temps requis pour un projet logiciel plus important?

37

Je suis un développeur junior et j'ai du mal à estimer le temps qu'il faut pour terminer un projet logiciel plus volumineux. Je sais comment structurer l'architecture en général, mais il m'est difficile de savoir quels détails je dois faire et quels problèmes je dois résoudre. Il est donc difficile d’estimer combien de temps il faudra pour terminer un projet plus important, car je ne sais pas quels problèmes je dois résoudre et combien de temps cela prend pour les résoudre.

Comment puis-je expliquer cela à une personne qui n'est pas un développeur de logiciels ?

Jonas
la source
5
Curieux: pourquoi votre travail en tant que développeur junior consiste-t-il à expliquer cela à des développeurs autres que des logiciels? Y a-t-il quelqu'un dans votre groupe de travail ou votre chaîne de direction qui peut vous aider dans le processus de convaincre qui que ce soit que vous avez besoin de convaincre?
Alex Feinman
@ Alex: Non, ce n'est pas une personne dans la même entreprise. Juste une personne avec des idées pour faire une startup. Et je suis le seul développeur avec qui il a des contacts.
Jonas

Réponses:

48

Vous pouvez lui demander d'estimer le temps qu'il lui faudrait pour accéder à un endroit éloigné dans un coin inhabité du monde. À titre d’exemple extrême, choisissons un sommet moins connu dans l’Himalaya, où très peu de personnes (voire aucune) ne sont déjà montées. Elle aurait besoin de beaucoup de préparation et de pratique avant même de commencer le voyage, ainsi que de plusieurs permis, chacun pouvant retarder le voyage de plusieurs mois à plusieurs années ... et d'une bonne équipe de soutien ... puis une fois sur la colline. pente, elle devrait attendre et prier pour que le beau temps commence à grimper vers le sommet, etc. etc. La plupart d’entre elles sont difficiles à estimer, même avec une expérience antérieure.

Et le fait est que chaque projet logiciel est un peu comme l’ascension d’une nouvelle montagne, où personne n’a jamais été, donc personne n’a d’expérience directe. Les développeurs chevronnés ont peut-être acquis de l'expérience dans des projets plus ou moins similaires , mais il y aura toujours de nouveaux éléments et de nouvelles surprises - sinon, si un projet logiciel était exactement comme un projet précédent, il serait absolument inutile de le faire .

Péter Török
la source
Plus d'inconnues signifie plus d'incertitude.
surfasb
9
Oublie loin. Leur demander d'estimer - à la minute près - quand ils rentreront chez eux après le travail ce soir. Que se passera-t-il si le trafic est différent, s’il commence à pleuvoir, si vous recevez un appel téléphonique en conduisant, etc. Si quelque chose d'aussi banal, et effectué aussi souvent que votre retour à la maison, ne peut être mesuré avec précision, alors Pouvons-nous espérer faire une meilleure estimation du temps requis pour mettre en œuvre un logiciel complexe, qui contient d'innombrables variables de plus en plus significatives qu'un maigre chemin du retour au travail?
Quentin-Starin
8
@qes, j'utilise les transports en commun, je peux donc dire avec environ 10% de précision que je rentrerai à la maison - je pense que la plupart des gestionnaires de projets SW seraient satisfaits de ce niveau de précision ;-)
Péter Török
1
Les objectifs du projet logiciel changent également. Ainsi, après avoir estimé le temps dont ils auraient besoin, le PO pourrait leur demander s'ils étaient toujours à l'heure après que quelqu'un leur ait dit de changer de pic lorsqu'ils étaient à mi-chemin du premier.
Paul
18

Avez-vous expliqué cela à la personne? Vous êtes un ingénieur en logiciel professionnel. Par conséquent, la personne pour laquelle vous créez un logiciel devrait prendre en compte vos connaissances et vos commentaires en matière de conception et de mise en œuvre de systèmes logiciels.

Le cône d'incertitude est probablement un bon point de départ. Les projets logiciels sont difficiles à estimer tant que les détails ne sont pas connus, ce qui se produit plus tard dans le projet. En outre, l'évolution des besoins modifiera également les estimations. Vos estimations initiales au début d'un projet auront une grande variabilité.

Vous pourriez aussi être intéressé par d'autres techniques d'estimation. Vous avez mentionné que vous n'êtes qu'un développeur junior. En général, les développeurs plus expérimentés ont une meilleure capacité d'estimation car ils ont constaté plus de problèmes, les ont résolus et (espérons-le) gardé trace de l'estimation par rapport au temps réel. Vous pouvez en tirer parti en utilisant des techniques d’estimation telles que le delphi à large bande ou la planification au poker .

En tant que développeur débutant, commencez dès maintenant à suivre les estimations et le temps réel. Vous voudrez peut-être vous renseigner sur le processus logiciel personnel développé par le Software Engineering Institute. Les principaux ouvrages PSP sont une discipline pour le génie logiciel , PSP: un processus d’amélioration personnelle pour les ingénieurs logiciels et une introduction au processus logiciel personnel . Je crois que l’introduction au processus logiciel personnel couvrirait les sujets que vous jugeriez les plus utiles. Je pense que c'est généralement exagéré pour la plupart des développeurs, mais il contient quelques bonnes idées et bonnes pratiques qui peuvent être extraites et utilisées afin d'améliorer la productivité personnelle et de perfectionner diverses compétences (y compris l'estimation) que vous utiliserez continuellement au cours de votre carrière.

Si vous comptez effectuer beaucoup plus de travaux d'estimation, je vous recommande fortement deux livres de Steve McConnell: Estimation du logiciel: Démystifier l'art noir (met l'accent sur l'estimation en tant qu'art et science) et Développement rapide: Taming Wild Software Schedules (logiciel général processus d'ingénierie et de gestion de projet).

Thomas Owens
la source
7

Reportez-vous à la littérature. Il existe une énorme pile de matériaux complexes et souvent contradictoires qui, comme le prouvent la pratique (expériences), ne fonctionnent pas comme prévu. Au moins les universitaires sont influencés par une pile de livres.

À lire absolument : http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Le mois mythique: Essais sur le génie logiciel est un livre de Fred Brooks sur le génie logiciel et la gestion de projet, dont le thème central est que "l'ajout de main-d'œuvre à un projet logiciel en retard le rend plus tardif". Cette idée est connue sous le nom de loi de Brooks et est présentée avec l'effet de second système et le plaidoyer en faveur du prototypage.

Les observations de Brooks sont basées sur ses expériences chez IBM dans la gestion du développement d’OS / 360. Il avait ajouté plus de programmeurs à un projet en retard sur le calendrier, une décision qu'il conclurait contre-intuitivement par la suite, en retardant davantage le projet. Il a également commis l’erreur d’affirmer qu’un projet - écrire un compilateur ALGOL - nécessiterait six mois, quel que soit le nombre de travailleurs impliqués (il faudrait plus de temps). La tendance des responsables à répéter de telles erreurs dans le développement de projets a conduit Brooks à annoncer que son livre s’appelle "La Bible du génie logiciel", car "tout le monde le cite, certains le lisent, et quelques-uns le passent". Le livre est largement considéré comme un classique des éléments humains du génie logiciel ...

Jürgen Strobel
la source
2

Découvrez ce qu’ils envisagent de faire avec cette estimation. Dans leur esprit, ils veulent savoir si cela prendra des mois, voire des années et que vous essayez d'obtenir les heures exactes (ingénieur type).

Voyez si vous pouvez travailler sur une partie du projet et préparez ensuite une meilleure estimation si nécessaire.

S'ils continuent à pousser, vous allez être obligé de détailler autant de tâches que vous pouvez et d'appliquer un laps de temps. Dites-leur que vous leur ferez savoir dès que vous verrez quelque chose qui pourrait affecter l'estimation et faire des ajustements. Les gens essaient généralement d'éviter les surprises.

JeffO
la source
1

J'ai rencontré des personnes qui affirment pouvoir estimer un logiciel, mais je ne sais pas comment elles le font. Aucun d'entre eux n'a été en mesure d'expliquer comment ils le font.

En tant que consultant, mes clients exigent souvent de moi que je travaille sur une base d'offre fixe. J'ai donc besoin d'estimer pour pouvoir préparer une offre réaliste. Je n'ai jamais réussi à cela. On pourrait penser que je surenchérirais aussi souvent que je sous-enchérirais, mais ce n'est jamais le cas. Le résultat est que je perds souvent beaucoup d'argent sur mes contrats et que je gagne beaucoup moins que si je travaillais pour une entreprise en tant qu'employé régulier.

Je recherche depuis plusieurs années un livre qui m’apprenne à estimer les logiciels, mais je n’en ai pas encore trouvé.

Quant à expliquer cela à quelqu'un qui n'est pas un codeur. Vous pouvez souligner que personne dans l'industrie n'est toujours en mesure de respecter ses estimations. Il arrive tout le temps que de nouveaux produits logiciels soient annoncés à l'avance, uniquement pour être expédiés des mois ou des années après la date initialement annoncée.

Si une grande entreprise telle que Microsoft ne sait pas comment estimer le temps qu'il lui faut pour fabriquer ses propres produits, comment puis-je?

Que je suis payé à l'heure ou à l'emploi, mes clients attendent toujours de moi que je vous fournisse ces estimations. Je ne sais pas comment ils s'attendent à ce que je les produise lorsqu'une telle estimation n'est enseignée nulle part, et je n'ai aucune base rationnelle pour mes estimations.

Mike Crawford
la source
1
Le livre de Steve McConnell Estimation du logiciel: Démystifier l'art noir est très utile pour expliquer comment les ingénieurs en logiciel estiment. Vous pouvez apprendre des techniques et des outils, mais la seule façon de devenir bon en estimation consiste à estimer en permanence, à tirer les leçons de vos estimations et à répéter. En ce qui concerne les estimations, personne ne parvient systématiquement à respecter les estimations, mais certaines entreprises n'atteignent généralement que quelques points de pourcentage - l'ouvrage de McConnell parle d'organisations (souvent de niveau CMMI 4 ou 5, avec une amélioration continue et un suivi détaillé) qui y parviennent. régulièrement.
Thomas Owens
En ce qui concerne votre problème avec de mauvaises estimations. Gardez-vous une trace de votre estimation par rapport au temps qu'il vous reste pour terminer? Si tel est le cas, déterminez par quel facteur vous sous-estimez et multipliez toutes vos estimations par ce nombre.
Kubi
0

L'estimation de la durée totale du projet est généralement effectuée par le chef de projet et non par le programmeur.

Vous pouvez construire un argument sur la base du fait que le chef de projet dispose de la liste complète des tâches requises. Sans cette liste, toute estimation serait une "mauvaise" estimation.

En outre, le temps dépend de nombreux facteurs tels que le nombre de personnes disponibles et la portée des exigences, ce que vous n'avez pas dit que vous aviez. L'architecture seule ne suffit pas.

Aucune chance
la source
Selon la méthodologie de gestion de projet, il se peut que le PM ne dispose même pas de la liste complète des tâches. Dans un domaine comme la gestion de projet à vagues successives, il existe souvent un seau nébuleux qui décrit un niveau de tâche très élevé, généralement trop volumineux pour pouvoir être estimé avec un niveau de confiance décent. Lorsque les tâches précédentes sont terminées, les tâches faisant partie de ce compartiment sont mieux définies et peuvent être estimées. Dans les méthodes agiles, des tâches sont fréquemment ajoutées, supprimées ou redéfinies les priorités à différents moments, ce qui rend encore plus difficile l'estimation des jalons à long terme au-delà de quelques itérations.
Thomas Owens
0

Vous pouvez également faire remarquer que le génie logiciel en est encore à ses balbutiements par rapport à d’autres domaines de l’ingénierie et n’a pas suffisamment mûri pour que des techniques de développement estimables soient apparues.

Le génie logiciel est également dans un état de flux continu. Au moment où une technologie est suffisamment développée pour être considérée comme mature, elle est souvent abandonnée au profit de certaines nouvelles technologies. Cela empêche quiconque d'acquérir suffisamment d'expérience avec une technologie pour pouvoir produire des estimations fiables.

Cela contraste avec l'estimation de la construction. C'est un problème très bien compris, non seulement parce que les contrats sont attribués sur la base d'offres, mais parce que l'humanité construit des choses depuis l'aube de la civilisation.

Mike Crawford
la source
1
Le génie logiciel est encore plus jeune (de loin) que la plupart des autres disciplines du génie à l'âge de 42 ans. Cependant, il existe un certain nombre de techniques et d'outils d'estimation matures. Large bande Delphi (développé dans les années 1970, popularisé par Barry Boehm dans Software Engineering Economics en 1981), points de fonction (1979), SEER-SEM (racines dans les années 1960), estimation par procuration (utilisée dans la PSP, développée en 1994 à SEI) et COCOMO (1981) et COCOMO II (1997). Dans un domaine de seulement 42 ans, près de 40 ans de travail ont déjà été réalisés dans l’estimation de projets.
Thomas Owens