Pourquoi les plannings logiciels sont-ils si difficiles à définir?

39

Il me semble que, selon mon expérience, demander à nos ingénieurs d'estimer et de déterminer avec précision les tâches à accomplir revient à tirer les ficelles. Plutôt que de simplement donner une estimation approximative de 2 à 3 semaines ou de 3 à 6 mois ... Quel est le moyen le plus simple de définir des calendriers logiciels afin qu’ils ne soient pas si difficiles à définir? Par exemple, le client A souhaite une fonctionnalité avant le 01/01/2011. Comment prévoyez-vous du temps pour implémenter cette fonctionnalité, sachant que d’autres corrections de bugs pourraient être nécessaires en cours de route et occuper plus de temps d’ingénierie?

Brian
la source
33
J'ai découvert une preuve véritablement merveilleuse qu'il est impossible d'estimer avec précision toutes les tâches de développement complexes, ou de les planifier parfaitement, ou en général de tout programme basé sur des estimations. Cette zone de commentaire est trop petite pour la contenir.
Dan McGrath
2
@Dan McGrath: Pourquoi ne postez-vous pas un lien contenant la preuve? Attendez, essayez-vous d'être comme Fermat et sa dernière preuve de théorème, qui n'a jamais été trouvée: |
Shamim Hafiz le
9
Pour la même raison, il est difficile de planifier un voyage lorsque le navigateur n’est pas sûr de la destination, que le conducteur ne connaît pas les routes et que les passagers veulent tous de la glace.
Steven A. Lowe
1
Quelque chose qui pourrait vous intéresser est la planification basée sur des preuves.
Craige
2
Ils ne sont pas difficiles à définir. Juste impossible à garder.
Tony Hopkinson

Réponses:

57

Si vous démarrez un projet presque identique à d'autres projets que vous avez réalisés, en utilisant des outils familiers et une équipe familière, et si vous avez des exigences écrites fermes, vous devriez pouvoir faire une bonne estimation.

Ce sont les conditions que les peintres, les installateurs de tapis, les paysagistes, etc., connaissent régulièrement. Mais cela ne convient pas à beaucoup (ou à la plupart) des projets logiciels.

On nous demande souvent d’estimer les projets qui utilisent de nouveaux outils, technologies, où les exigences changent, etc. C'est plus une extrapolation à l'inconnu qu'une interpolation sur nos expériences passées. Il est donc naturel que l'estimation soit plus difficile.

Rob Weir
la source
20
Points excellents. C'est comme demander combien de temps cela vous prendra pour conduire quelque part où vous n'êtes jamais allé. Vous pouvez donner une estimation en fonction de la distance, mais vous ne pouvez pas prendre en compte le volume de trafic aux heures de pointe.
JeffO
2
@ Jeff C'est une très bonne comparaison. Je vais devoir me rappeler celui-là
Dave McClelland
1
@ Jeff ... mais vous pouvez savoir qu'il est l'heure de pointe et ajouter ce fait à vos estimations ... vous êtes peut-être toujours en
retard
2
@Pemdas: En fait, vous ne pouvez pas en savoir assez pour ajouter tous les faits à vos estimations. Vous ne pouvez pas savoir si le service d'incendie répond à un appel. Vous ne pouvez pas savoir si un fil électrique est tombé et bloque la route. Il y a un nombre infini de choses que vous ne pouvez pas savoir sur le futur. C'est le futur. C'est difficile à prédire - par définition.
S.Lott
1
@Pemdas - Plus la tâche est complexe, plus les dieux du chaos interviennent. Bien sûr, cela correspond probablement plus à votre propos qu'à certains commentaires - avec des tâches familières, vous savez à quel point ces dieux embêtants ont tendance à s'intéresser.
Steve314
35

D'après mon expérience personnelle, c'est exactement le contraire de ce que Pemdas a dit : avec la pratique, je viens de comprendre qu'il est totalement impossible d'estimer combien de temps une tâche nécessitera. Au début de ma carrière dans le développement de logiciels, je donnais souvent des estimations comme "45 jours", "cinq semaines", etc., puis j'essayais très fort de terminer à temps. Quelques années après, j'ai commencé à donner des estimations moins précises telles que "environ un mois", "cinq à sept semaines", etc. ou date limite ou je donne une estimation aussi approximative que possible.

Pourquoi est-ce si difficile d'avoir une estimation? Parce qu'il est presque impossible de savoir comment tout le code source sera écrit avant de l'écrire, et parce que votre travail dépend d'éléments aléatoires tels que le travail d'autres personnes, de votre motivation, etc. Voici une liste plus détaillée des raisons possibles:

  1. Il n'est pas facile de savoir exactement ce qu'il faut faire pour fabriquer un produit et surtout comment le faire . Très souvent, j'ai commencé certaines parties d'une application qui, après des jours de travail, ont compris que ma première approche était fausse et qu'il existe une manière plus efficace et plus intelligente de faire les choses.

  2. Certains problèmes peuvent survenir . Par exemple, si, pour commencer votre travail, vous devez installer un serveur SQL sophistiqué sur votre ordinateur et que l'installation échoue et que la prise en charge est inexistante, vous pouvez passer des semaines à résoudre ce problème.

  3. Les exigences ne sont souvent pas assez claires , mais après les avoir lues au début, vous pensez qu'elles le sont. Parfois, vous pouvez comprendre que la moyenne "A", et, après avoir commencé à les mettre en œuvre, vous remarquerez qu'ils signifient peut-être "B".

  4. Les clients aiment modifier leurs exigences exactement lorsque vous venez de terminer la partie concernée , et ils ne comprennent vraiment pas pourquoi vous demandez deux semaines supplémentaires et 2000 $ pour effectuer un changement minime , car ils ne voient pas que ce changement minime nécessite changer d'autres choses, ce qui nécessite de changer les autres, etc.

  5. Vous ne pouvez pas estimer votre motivation . Il y a des jours où vous pouvez travailler des heures et réussir. Il y a des semaines où, après avoir écrit dix lignes de code, vous passez à Programmers StackExchange et passez des heures à lire et à répondre aux questions.

  6. Les choses deviennent vraiment mauvaises lorsque votre estimation dépend d'autres personnes . Par exemple, dans un projet de 2 mois, j'ai dû attendre qu'un designer fasse son travail pour finir le mien. Ce concepteur a pris 3 mois avant de livrer un morceau de merde inutilisable. Bien sûr, le projet était en retard.

  7. Votre estimation dépend également de votre client . J'ai des clients qui passent des semaines avant de répondre à leur courrier. Cela peut vraiment affecter votre emploi du temps lorsque vous devez attendre leur réponse (par exemple, si vous leur demandez de préciser une exigence).

Que pouvez-vous faire?

  1. Donnez un horaire plus long . Si vous pensez pouvoir faire le travail en deux semaines, dites que vous le livrerez dans un mois.

  2. Sois clair . Si vous comptez sur un designer, un autre développeur, etc., dites-le. Au lieu de dire "Je livrerai le produit dans trois mois", dites "Je livrerai le produit dans deux mois après que le concepteur m'ait donné des fichiers PSD".

  3. Expliquez que si les exigences changent chaque jour, le projet sera difficilement livré à temps.

  4. Tranchez votre horaire . Il est plus facile de livrer des parties d'un grand projet à temps.

  5. Ne donnez jamais d'estimation lorsque vous utilisez un produit que vous ne connaissez pas bien ou, en particulier, lorsque vous travaillerez sur le code source de quelqu'un d'autre: vous ne pouvez jamais prédire à quel point le code source peut être merdique et combien de temps vous passerez comprendre et copier-coller dans The Daily WTF.

Arseni Mourzenko
la source
1
@ Jeff O: Je ne sais pas. Pour moi, une date de livraison signifie une date limite. Et une date limite signifie que le projet ne peut pas être livré après. En outre, psychologiquement, les clients pourraient être moins fâchés quand vous leur dites que vous livrerez quelque chose dans un mois et que vous le livrerez quatre jours plus tard que si, le 8 janvier 2011, vous disiez que vous le livriez le 8 février 2011 et que livrer le 12 février.
Arseni Mourzenko le
10
@Pemdas: ce n'est pas une question de paresse. Vous pouvez simplement être déprimé ou avoir des difficultés temporaires à vous concentrer, ou avoir des problèmes personnels / familiaux, ou être trop stressé par d'autres clients ou autre.
Arseni Mourzenko le
2
En ajoutant aux points de MainMa, si vous travaillez en équipe, il y a des situations où quelqu'un doit être en congé, de joie ou de maladie.
Shamim Hafiz le
5
@Pemdas Ils se produisent dans une certaine mesure avec chaque programmeur. C'est juste que cela se manifeste d'une manière qui n'est pas toujours évidente. Une semaine de traitement d'un problème donné peut prendre 3 heures, car vous êtes très forte et "dans la zone", tandis que la semaine suivante, cela prend 3 jours.
Matthew Frederick
7
@ 0A0D Si vous décomposez le projet en ses tâches les plus détaillées et déterminez le fonctionnement exact de chacun d'entre eux, vous devez tout analyser pour vous assurer de bien comprendre les implications de la combinaison de ces éléments, et de passer en revue toute nouvelle version, nouvelle ou non. Les technologies qui vous occupent le mieux sont impliquées, et vous obtenez tous les inconnus, alors vous pouvez absolument fournir une estimation précise et sacrée. Bien sûr, vous avez également réalisé presque toute la programmation, ne laissant que la partie codage, et vous ne pouvez pas savoir à l'avance combien de temps toutes ces estimations prendront. ;)
Matthew Frederick
15

Une question très similaire est "Combien de temps cela prendra-t-il pour résoudre ce jeu de mots croisés?"

Vous ne pouvez pas répondre à cette question tant que vous n’y avez pas jeté un œil pour voir de nombreuses choses comme:

  • Est-ce dans une langue familière? (Espagnol contre anglais contre chinois)
  • Est-ce un type de problème que nous avons déjà résolu? (Un dans une série en cours d'exécution dans un magazine, par exemple)
  • Est-ce que l'une des pistes nécessite des connaissances supplémentaires avant même que nous puissions le comprendre?
  • Y a-t-il quelque chose dans le puzzle qui, à votre connaissance, nécessitera un travail supplémentaire?

Puisqu'il y a habituellement plusieurs choses nouvelles dans un projet (sinon ce ne serait pas un projet), vous ne pouvez pas dire combien de temps il faudra pour les résoudre avant de les avoir examinées de très près. Peut-être même en résoudre plus ou moins, et vous n'êtes toujours pas sûr qu'il n'y ait pas une ou deux surprises où vous n'y avez pas pensé.

De plus, il existe une forte pression pour le faire le moins cher possible, donc le plus rapidement possible, et la responsabilité d'une estimation trop basse ne repose pas sur la mise en pression du chef de projet, mais sur le développeur qui donne l'estimation. Il ne faut pas beaucoup d'itérations pour que le développeur comprenne cela et apprenne à être TRÈS fatigué de donner des chiffres absolus.

Jim G.
la source
11

La raison la plus évidente pour laquelle vos ingénieurs ne peuvent vous donner d’estimations précises est que c’est impossible .

Bien sûr, vous pouvez estimer combien de temps + -2 minutes il faudra de votre domicile au travail. Vous savez conduire une voiture, vous pouvez évaluer le trafic et certains autres facteurs externes.

Dites-moi combien de temps il vous faudra pour conduire de Londres à Barcelone. Sans outils de planification GPS avancés, bien sûr. En utilisant la bonne vieille méthode comme nous le faisons encore dans l'estimation logicielle. Estimation empirique et prédictions .

Dans le logiciel, c'est pire:

  1. Les estimations deviennent souvent un engagement , notre jugement est donc modifié.
  2. Il peut y avoir d’ énormes différences entre les estimations de Bob et Karl pour la même tâche.
  3. Les incertitudes sont très courantes, combien d’entre nous sont bloqués par un bogue stupide ou un crash de disque dur, détruisant ainsi toute bonne estimation apparente.
  4. Nous oublions généralement toutes les tâches autres que la programmation, y compris les réunions, les appels téléphoniques, l'aide à notre collègue, etc.
  5. Le cerveau humain est limité . Il n'a pas été conçu pour estimer les tâches de longue durée.

C'est pourquoi il est impossible de dire à votre client ce que vous pourrez expédier pour le 02/01/2011 avec une précision suffisante et oublier le 03/01/2011.

Pour résoudre tous ces problèmes, je vous recommande des techniques d'estimation avancées telles que Planning Poker (disclaimer: ce site est l'un de mes sites Web) et le développement itératif avec calcul de la vélocité .

  • Planning Poker aborde les deux premiers problèmes. Les estimations sont collectives et l'équipe les possède plutôt que des individus.
  • Les trois dernières questions sont traitées à l'aide de Velocity et du développement itératif. En connaissant votre vélocité (le facteur à appliquer à vos estimations en fonction de l'historique), vous pouvez planifier les versions avec plus de confiance. Le développement itératif, lorsqu'il est bien effectué, optimise les fonctionnalités les plus importantes et vous aide à offrir rapidement de la valeur à vos utilisateurs.

la source
Donc, si quelqu'un demande une date de livraison du 02/01/2011 pour une fonctionnalité, le mieux est de dire "dès que je travaillerai dessus, je vous ferai savoir combien de temps cela prendra"? Je suis sûr que ça se passerait bien comme un ballon de tête;)
Brian
0A0D: cela dépend de la situation. Avec une équipe qui ne se connaît pas, je ne parierais sur AUCUNE échéance. Toutefois, si vous connaissez votre vitesse moyenne, utilisez des estimations collectives et pratiquez le développement itératif, vous pouvez définir un délai avec beaucoup plus de confiance.
@ 0A0D, en Europe le 02/01/2011 signifie le 2 janvier. Au moins, la réponse est plus facile lorsqu'on lui a demandé le 8 janvier: D
6

Le développement de logiciels est - par définition - un acte de découverte et d’invention. Cela doit toujours impliquer quelque chose d'inconnu.

Le seul moment où tout ce qui concerne le développement de logiciels est connu est celui où le logiciel est complet.

La seule fois où il n'y a pas de technologie ou de fonctionnalité commerciale inconnue, c'est quand il s'agit d'une solution complète prête à être téléchargée.

Nous écrivons un nouveau logiciel parce que nous avons une nouvelle fonctionnalité ou une nouvelle technologie, ou les deux. Nouveau signifie nouveau - inconnu - imprévisible.

Étant donné que le développement logiciel doit impliquer la nouveauté, l'effort de développement ne peut être prédit.

S.Lott
la source
3

Honnêtement, je pense que cela prend juste de la pratique. Si vous écrivez suffisamment de code, vous devriez être "assez" précis. Mon premier chef a estimé que cette compétence était suffisamment importante pour qu'il me demande de la pratiquer de manière informelle pour chaque fonction / projet mis en œuvre. Après chaque projet, nous avons examiné les estimations et tenté de comprendre où je me suis trompé. Finalement, vous avez le coup de main.

Pemdas
la source
J'approuve l'examen, mais je suis vraiment curieux: @Pemdas, avez-vous tendance à travailler sur le même type de problèmes pour chaque projet, avec seulement des changements mineurs? Faites-vous allusion à des choses relativement simples, peut-être un autre service RESTful qui ne fait que renvoyer des lignes de table de base de données ou quelque chose de ce genre? Ayant travaillé avec plusieurs dizaines de programmeurs et en ayant embauché des dizaines également, je n'ai pas encore trouvé quelqu'un qui puisse donner des estimations précises pour des problèmes remplis d'inconnus.
Matthew Frederick
Je travaille sur le même produit, mais les problèmes rencontrés changent à chaque version. J'admettrai que je n'ai jamais eu à estimer quelque chose qui a pris plus de 6 à 8 mois.
Pemdas
Perndas, rien que pour le plaisir: combien de temps faudra-t-il pour réécrire votre produit en C # ou en Java? Pour exécuter dans le nuage de Google? Pour visualiser des données en direct dans OpenGL? Avoir un client utilisateur final fonctionnant sur une Wii?
Peut-être que notre définition des estimations est fausse. Il faut certainement une période de recherche avant de pouvoir donner une estimation raisonnable, mais je n’inclus généralement pas mon estimation du temps de livraison. Je ne peux pas répondre à aucune de ces questions sans faire d’abord des recherches. Je ne supposerais jamais pouvoir donner une estimation sans comprendre les technologies.
Pemdas
2

Ce n'est jamais facile Vous essayez juste de vous améliorer.

L'un des avantages de la décomposition de votre code livrable en éléments plus petits est que les clients comprennent parfaitement à quoi s'attendre et quand s'y attendre. Vous avez maintenant une sorte de référence à utiliser comme référence.

S'ils ont une définition stricte d'une fonctionnalité dont ils ont besoin à une heure définie, ils doivent savoir que des ressources supplémentaires doivent être allouées à cette demande. Ils prennent un risque quant à la gravité des bugs et à la durée pendant laquelle ils peuvent rester sans qu’ils ne soient corrigés. Lorsque quelque chose d'important se présente, vous retournez chez le client et le force à prendre une décision. Est-ce que je corrige le bogue ou fixe la date limite pour la nouvelle fonctionnalité? Donnez-leur suffisamment d'informations pour prendre une décision éclairée.

J'espère que vous avez suffisamment d'expérience dans le travail ensemble et que vous vous êtes suffisamment établi pour qu'on vous fasse confiance. Vous ne pouvez pas vous attendre à ce qu'ils comprennent parfaitement le processus de développement, mais vous pouvez leur faire sentir que vous déployez des efforts honnêtes et que vous ne tirez pas parti de leur manque de connaissances.

JeffO
la source
Je n'ai même pas pensé aux versions incrémentielles. C'est un excellent outil pour permettre au client de progresser. Bien que je ne travaille pas avec des clients "externes", je le pratique en interne, mais c’est un excellent moyen de tester le pipeline en développement.
Pemdas
2

Parce que nous faisons l’horaire trop tôt. Voir l'article de Construx sur une ébauche préliminaire, puis une meilleure plus tard. De plus, si vous ne suivez pas vos estimations précédentes, il est difficile de vous améliorer. FogBugz fait cela [un client de leur libre, aucun autre conflit d’intérêts].

Brian Carlton
la source
2

J'ai beaucoup appris de ce livre:

Estimation de logiciel: Démystifier l'art noir

En bref, pour obtenir de meilleurs résultats d'estimation, nous procédons comme suit:

  1. toutes les tâches sauf les tâches triviales sont estimées par plus d'une personne (deux dans notre cas)
  2. nous divisons la tâche en tâche plus petite. Plus vous aurez de tâches, plus votre estimation sera probable - loi des grands nombres si je me souviens bien de la
  3. nous estimons le pire, le meilleur et le plus probable des scénarios. Parfois, chacun de nous estime ces arborescences de manière totalement différente. Cela signifie que nous devons parler et il s’avère généralement que l’un d’entre nous n’a pas compris la tâche. Si cette personne avait estimé la tâche seule, elle aurait été mal estimée.
  4. nous mettons 3 nombres du point ci-dessus dans l'équation et recevons une estimation (excell) k

Une fois que la tâche est terminée et que notre estimation était fausse, nous essayons de trouver les raisons. Et nous intégrons ces connaissances au prochain processus d’estimation. Jusqu'à présent, c'est le meilleur processus que j'ai utilisé pour l'estimation de tâches plus importantes. Quand je parle de tâche, je parle d’emplois qui prennent entre 50 et 500 heures.

Piotr Perak
la source
1

Remarque: cela ne s'applique vraiment qu'aux projets pour lesquels vous facturez à l'heure, par opposition à un taux fixe / forfaitaire.

J'essaie habituellement de planifier mon emploi du temps de sorte qu'il se compose essentiellement d'un groupe de sprints SCRUM (qu'ils utilisent ou non SCRUM). Dès le début du calendrier, je détermine la longueur de chaque sprint et les caractéristiques du projet. En règle générale, certaines fonctions doivent être réalisées en premier. J'essaie donc de donner une meilleure estimation (à ne pas confondre avec optimisme) pour celles-ci. Toutes les caractéristiques qui aboutiront à la fin du projet auront des estimations généralisées. Après avoir mappé les fonctionnalités sur les sprints, j'essaie d'ajouter 1 à 2 sprints à la fin du projet pour prendre en compte les fonctionnalités qui glissent vers la droite et celles qui ont été ignorées dans la collecte des exigences d'origine.

La clé de ceci est que je rende tout cela transparent pour le client dès le départ afin qu'il comprenne pourquoi les deux derniers sprints sont vides ou peu peuplés. Au moins à ce stade, les clients avec lesquels j'ai travaillé apprécient ce projet, car ils savent qu'il existe une certaine marge de sécurité dans le calendrier et les états financiers, car la plupart d'entre eux savent que les estimations de SW ont tendance à être moins que concrètes. Ils sont également conscients que si nous n’avons pas besoin du dernier sprint, ce sont des heures que nous ne facturons pas. Grâce à la transparence dans la construction du planning et aux commentaires réguliers sur l'état d'avancement de l'exécution du projet, chaque client avec lequel j'ai effectué ce travail a été extrêmement satisfait.

Ken Henderson
la source
1

En plus de toutes les choses nommées, je considère ces deux choses comme l'un des plus gros problèmes. Premièrement, vous estimez la date finale en fonction de la disponibilité de chaque développeur pour les 8 heures complètes par jour, 5 jours par semaine. Ceci est incorrect et garantira pratiquement à 100% que la date de fin est manquée pour tout projet non négligeable. Les gens prennent des congés, assistent aux réunions de l'entreprise (ou non basées sur un projet), se disputent avec les ressources humaines à propos des réclamations d'assurance maladie, prennent des pauses, etc. N'assumez jamais plus de 6 heures de disponibilité par développeur et par jour.

Les développeurs oublient notoirement d'estimer toutes les tâches non liées au développement, telles que les réunions et les e-mails concernant le projet, le déploiement, l'assistance QA, l'assistance UAT, la rédaction de tests unitaires, la recherche, la documentation, etc. Une fois ces types de tâches ajoutés à notre feuille de calcul les estimations sont bien meilleures.

HLGEM
la source
Je n'appellerais pas l'écriture des tests unitaires comme une tâche non-développement;) et nos chefs nous comptent 6 heures par jour. Si je dis 60 heures, ils disent 10 jours.
Piotr Perak
@ Peri, D'accord, je ne le ferais pas non plus vraiment, mais beaucoup de gens oublient d'ajouter du temps pour la rédaction des tests et ne pensent qu'au problème principal. Bon pour vos patrons, ça me surprend combien ne le font pas.
HLGEM
1

En ce qui concerne l'estimation du temps pour des tâches qui peuvent prendre plus de temps que quelques heures, je fais de mon mieux pour utiliser ces règles:

  1. N'essayez jamais de prédire quand d'autres personnes finiront leur travail si vous en dépendez. Ne parlez que pour vous-même.
  2. Analysez d'abord la tâche, puis estimez. En analysant, j'entends au moins écrire (et ne pas essayer de tout garder en tête!) Une liste de sous-tâches avec une estimation pour chacune d’elles.
  3. Si une tâche est suffisamment complexe, estimez le temps nécessaire à cette analyse. Laissez l'estimation être un processus séparé. Vous pouvez également vous assurer que votre patron le sait.
  4. Ne pas estimer sous pression. Dites clairement qu'il faut du temps pour faire une estimation raisonnable et dites-leur simplement quelque chose comme: «Je nommerai une date demain à 11 heures, lorsque j'aurai fini d'analyser la tâche». Je sais que certains clients / gestionnaires peuvent insister, mais ils ne passeront pas. Mettez votre visage occupé et réclamez votre temps!
  5. Demandez un peu plus de temps que vous ne le pensez, car vous avez probablement oublié d'ajouter une pause-café (et d'autres distractions) à votre estimation.
  6. Pour les grandes tâches, demandez encore plus - il y aura probablement plus d'une pause-café.
  7. Si vous ne pouvez vraiment pas estimer (la tâche est trop difficile / peu familière) ou vraiment incertain, demandez à une personne capable de vous aider avec votre analyse.

Il y a probablement plus de règles que cela, mais je n'ai pas d'affiche avec ces règles sur mon mur. Je viens de les formuler maintenant, mais ils viennent de mon expérience (donc cela peut ne pas fonctionner pour vous).

Le seul moyen fiable de planifier le développement de logiciels auquel je puisse penser (mais je ne l'ai pas encore essayé) est la planification basée sur des preuves, qui est essentiellement la méthode de Monte Carlo utilisée pour compter la probabilité d'une date d'expédition sur la base d'enregistrements historiques de tâches que vous avez effectuées. ai accompli avant. Cela fait du bien parce qu’il n’essaie pas d’utiliser des métriques autres que le temps estimé et réel. Cependant, il faut au préalable beaucoup d’expérience pour scinder au préalable des tâches importantes en tâches plus petites. Vous devez disposer d’un grand ensemble de données historiques pour le rendre suffisamment précis.

scriptin
la source
1

Il existe des "inconnus connus" et des "inconnus inconnus". :-)

  1. Les estimations deviennent souvent des délais.

    • Personne ne veut manquer une date limite et devenir le titre!
  2. Les exigences changent (souvent de manière rationnelle) et le programmeur ne peut pas y opposer son veto.

  3. Le programmeur a / peut ne pas avoir le contrôle sur des facteurs tels que

    • Disponibilité du code sur lequel elle est dépendante
    • Qualité du code dont elle dépend
    • Architecture globale et conception du système
    • API pour accéder à d'autres parties du système
Arun Saha
la source