Quantité de travail de routine dans le développement de logiciels et son effet sur l'estimation

Je suis convaincu que la quantité de travail de routine dans le développement de logiciels est - et devrait être - relativement faible, sinon négligeable, et que c'est le problème fondamental de l'estimation des logiciels.

Permettez-moi de décrire comment j'arrive à cette conclusion et de me dire si l'argumentation présente de sérieux défauts:

1. Tout ce qui peut être estimé avec une grande précision est un travail de routine, c'est-à-dire des choses qui ont été faites auparavant. Tous les autres types de travaux impliquant la recherche et la créativité ne peuvent pas vraiment être estimés, du moins pas avec une précision de, disons, +/- 20%.

2. Le développement logiciel consiste à éviter les tâches répétitives. L'un de ses principes de base est SEC (ne vous répétez pas). Chaque fois qu'un programmeur se retrouve à faire des choses répétitives, il est temps de trouver une abstraction qui évite cette répétition. Ces abstractions peuvent être des choses simples comme extraire le code répété dans une fonction ou le mettre en boucle. Ils peuvent également être plus complexes, comme la création d'un langage spécifique à un domaine. Dans tous les cas, leur mise en œuvre impliquera de la recherche (quelqu'un l'a-t-il déjà fait?) Ou de la créativité.

De ces deux points, je tire la conclusion ci-dessus.

En fait, je me demande depuis longtemps pourquoi cette relation n'est pas mentionnée dans toutes les autres discussions, articles de blog ou articles sur l'estimation de logiciels. Est-ce trop théorique? Mes hypothèses sont-elles fausses? Ou est-ce trop trivial - mais alors, pourquoi la plupart des développeurs que je connais croient-ils pouvoir faire des estimations avec une précision de +/- 20% ou mieux?

Pour tout projet donné, cela peut être vrai. Cependant, si vous travaillez sur plusieurs projets similaires pour différentes entreprises au fil des ans, vous pouvez vous retrouver à résoudre plusieurs fois le même problème avec de légères variations.

Par exemple, j'ai écrit des couches d'accès aux données tant de fois que je préfère maintenant le faire à la main plutôt que d'utiliser l'ORM populaire du mois. Il est plus rapide et plus facile pour moi de traiter les «problèmes de routine» avec des solutions connues que de trouver et de résoudre de nouvelles bizarreries dans les composants tiers.

Évidemment, je pouvais écrire mon propre ORM pour simplifier le code répétitif sans ajouter les bizarreries inconnues dans le système de quelqu'un d'autre, mais ce code appartiendrait à la société pour laquelle je travaillais à l'époque, et d'autres développeurs le trouveraient aussi bizarre que tout autre ORM tiers.

De même, d'après mon expérience, la plupart des programmes sont l'automatisation des processus métier et bien que chaque entreprise aime à penser que ses processus lui sont uniques; En réalité, ils ne le sont pas.

Pour ne pas dire que l'estimation est facile! C'est plus facile, mais je trouve que de nos jours le problème d'estimation est dû à l'insuffisance des exigences plutôt qu'au temps passé à coder.

Les exigences se répartissent généralement en trois catégories:

1. Vague, détails laissés au développeur.

"Faites-moi un site web, ça doit être cool et vendre mes widgets"

Celles-ci ont tendance à être les plus faciles à estimer, car lorsqu'un problème grave et inattendu se produit, vous pouvez simplement changer les exigences en quelque chose d'équivalent fonctionnel et éviter le problème.

2. Très spécifique

"Rendre la couleur d'arrière-plan de l'en-tête # ff1100"

Super rapide à faire et, encore une fois, facile à estimer. Mais! l'exigence est appelée à changer. "Hmm non à y réfléchir, essayez cet autre rouge" ou "Attendez! Je voulais dire seulement sur cette seule page!" donc la durée réelle de "combien de temps jusqu'à ce que je sois satisfait de la couleur de l'en-tête" n'a rien à voir avec les estimations de codage

3. Vague, détails supposés

"Faites-moi un site Web, (tout comme Facebook)"

Ici, la multitude d'hypothèses non énoncées, "bien sûr, vous voudrez un logo différent", "il devrait avoir un défilement infini", "doit être évolutif pour 1 milliard d'utilisateurs!" contrôler efficacement l'estimation. Soit le développeur pense à tout et pousse l'estimation au-delà des attentes "1 meeelion d'heures de travail", soit il pense / suppose que seules les fonctionnalités de base sont nécessaires et donnent une estimation trop basse. "oh une semaine ou deux, je suppose que tu veux juste mettre facebook dans un iframe non?"

Avec l'expérience, le codage est très rapide, mais la conception des exigences est (généralement) difficile, et cela est de plus en plus repoussé aux non-codeurs. Les méthodologies agiles augmentent la vitesse de codage en déplaçant cette responsabilité vers «l'entreprise» plutôt que vers les développeurs.

Pourquoi la plupart des développeurs que je connais croient-ils pouvoir faire des estimations avec une précision de +/- 20% ou mieux?

Parce que nous estimons notre patience avec le problème beaucoup plus que le problème réel.

Si je vais animer une balle qui rebondit, je pourrais y passer une journée, une semaine, un mois ou un an et avoir toujours une animation d'une balle qui rebondit. J'espère que ça ira mieux avec le temps que j'y consacre, mais à un certain point, je suis ridicule.

L'effort que je déploie pour faire rebondir la balle est fonction du temps qu'il est raisonnable d'y consacrer. Si mon niveau de compétence ne le coupe pas, je peux me retrouver avec une balle qui reste là. Mais lorsque la date limite arrive, dois-je la laisser glisser ou au moins avoir une balle sur l'écran? Waterfall a insisté pour que le ballon rebondisse et le calendrier a donc glissé. Agile dit qu'il suffit de sortir le ballon. Au moins, nous découvrirons à quel point les gens se soucient du rebond. La qualité a donc chuté.

J'essaie d'être sûr que mes balles rebondissent mais quand la date limite arrive, il vaut mieux produire une balle statique que rien du tout. J'évalue donc le temps en fonction de ce qui semble être un temps raisonnable à consacrer à un problème avant de parler d'alternatives. Parfois, la balle ne va tout simplement pas rebondir. Parfois, ça va. Disparaître pendant un mois n'est pas OK.