Les délais manqués sont-ils courants dans les emplois de programmation? [fermé]

C'était mon travail d'indépendant chez oDesk. J'ai fait plusieurs travaux plus tôt dans le temps imparti, mais c'était la première fois que je manquais la date limite. C'était un travail très long et j'ai fait de mon mieux, mais j'ai quand même manqué la date limite. Maintenant, j'ai très peur. Parce que c'est ma faute si j'ai manqué le délai.

Ma question est la suivante: est-ce une grande préoccupation ou les délais manqués sont-ils courants dans les emplois de programmation, donc je ne devrais pas trop m'inquiéter à ce sujet?

Oui. Les délais manqués sont courants dans le développement de logiciels.

De nombreux pigistes respectent les délais en contractant des dettes techniques ou en cachant la saleté sous le tapis.

Paraphrasant le Mois de l'homme mythique de Frederick Brooks :

• Les délais sont souvent manqués car les chefs de projet continuent d'estimer les tâches logicielles de la même manière que les tâches de génie civil, ce qui est une approche erronée car le logiciel est une nouvelle industrie artisanale sans corps clair de normes. Cela est si vrai que vous ne pouvez pas révoquer le «permis» d' un programmeur pour coder pour faute professionnelle, ni poursuivre quelqu'un pour avoir programmé sans titre.

• Le développement de logiciels présente une complexité inhérente qui fait défaut à d'autres disciplines. Un grand programme peut avoir plus de composants qu'une voiture, et ces composants peuvent interagir de différentes manières.

• Le logiciel est difficile à visualiser, donc différents types de diagrammes sont utilisés pour voir différents aspects d'un projet, et ces aspects peuvent ne pas être orthogonaux. Le génie civil, d'autre part, a des plans vous permettant de voir la plomberie, le câblage, etc. dans le même graphique (ou couches) de manière orthogonale.

• Il n'est pas courant, après la construction d'un pont ou d'un bâtiment, que le client change complètement la portée du projet. C'est souvent le cas dans les projets logiciels.

• L'état de l'art dans le développement de logiciels n'a pas atteint le point où les projets logiciels sont reproductibles et presque sans risque. Même les plus grandes sociétés de logiciels comme Microsoft peuvent manquer des délais de plusieurs mois ou années.

• La plupart des vaporwares ne sont que des projets logiciels qui ont été supprimés à cause de ce genre de problèmes.

En conclusion:

Les mauvaises estimations et la sous-estimation de la complexité, en raison de la nature artisanale du processus de développement logiciel, signifient qu'il reste une discipline immature.

Les délais non respectés ne devraient pas devenir une pratique courante si vous souhaitez continuer à trouver un emploi.

Cela dit, vous voulez généralement vous laisser une marge de manœuvre supplémentaire dans vos estimations au cas où des choses se produiraient (et c'est toujours le cas). Vous n'avez pas besoin de révéler que vous avez ajouté du temps supplémentaire, mais ne le rendez pas déraisonnable. Peut-être entre 5 et 10% du temps total? La seule façon de le savoir est de le faire plusieurs fois.

Pour être vraiment bon dans les estimations, vous devez savoir combien de temps il faut pour coder un certain type de widget ... par exemple, disons que vous devez créer un widget de défilement infini pour le client X. Si cela vous prend une semaine pour le déployer en production sans bogues, vous pouvez l'utiliser comme référence pour vos estimations de défilement infini.

Les délais manquants ne sont pas rares dans le développement de logiciels. Il est presque impossible d'estimer avec précision la durée d'un projet logiciel.

Le professionnalisme se manifeste dans la façon dont vous y faites face. Lorsque vous savez que vous manquerez un délai, informez-en votre client le plus tôt possible afin qu'il puisse planifier en conséquence.

C'est assez courant, mais vous pouvez vous améliorer. Vous voudrez peut-être étudier l'estimation en utilisant quelque chose d'abstrait comme des points d'histoire , et garder une trace de votre vitesse pour calculer vos estimations réelles. Ces concepts sont le plus souvent associés à la mêlée, mais peuvent être utilisés même si vous ne faites pas de mêlée.

La chose étonnante à propos de la vitesse est qu'elle englobe toutes les choses intangibles comme les interruptions et la complexité inattendue que les développeurs ont du mal à prendre en compte dans leurs estimations. Toutes les probabilités s'étalent dans le temps. En moyenne sur 10 semaines, nos estimations de vitesse ont été précises à environ 5%. Pourtant, lorsque nous estimons les mêmes tâches en heures, la même équipe exacte sous-estime constamment de 30 à 50%.

Ma théorie (non prouvée) est que les humains ont évolué pour sous-estimer les emplois compliqués par deux ou trois pour un. Chaque fois que le Congrès demande à la NASA quelque chose comme: combien cela coûtera-t-il pour construire une navette ou se rendre sur la lune, ils reviennent dans la semaine avec un numéro. Après avoir épuisé tous les coûts attendus, ils découvrent que cela coûtera trois fois plus.

Nous avons eu une blague dans les années 1970: prenez n'importe quelle estimation de programmeur, doublez le nombre, puis déplacez-la vers l'unité de temps suivante. Par conséquent, si un programmeur dit que cela peut être fait en deux semaines, il le terminera en quatre mois.

Si quelqu'un a remodelé une cuisine, il pense généralement: «Eh bien, je le ferai dans deux semaines». Ils le terminent environ six semaines plus tard.