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

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 ?

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 .

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

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

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.

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.

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.

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.