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

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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