Les estimations d’ingénierie logicielle sont des ordures
La plupart des estimations de génie logiciel sont des ordures.
Ce n’est pas parce que les entreprises utilisent les mauvaises méthodes ou outils. Structure de répartition du travail ou par analogie ? Combinaison mécanique ou jugement ? Fonction, cas d’utilisation ou story points ? SEER-SEM, WMFP ou Delphi large bande ? Bien.
Les outils ne sont pas le problème. Au contraire, la plupart des estimations sont des ordures parce qu’elles sont basées sur une compréhension fondamentalement erronée de la façon dont un logiciel de qualité est construit.
L’impact va bien au-delà des dépassements de coûts et des délais non respectés. L’approche typique des estimations finit par forcer les mauvais comportements tout en privilégiant les mesures de vanité plutôt que de fournir une valeur commerciale réelle.
Le bruit et le non-déterminisme sont inhérents au génie logiciel
Dans les environnements Agile, les estimations sont souvent basées sur les story points et la vélocité. À quel point sera-t-il complexe de créer un élément discret de la solution ? Et combien de temps nous faut-il généralement pour terminer une histoire de cette complexité ? (J’ai déjà écrit sur la façon dont cette approche Agile corrompt Scrum avec des méthodes de contrôle en cascade.)
Lors de l’estimation de cette façon, nous comprenons que tout ne se déroulera pas comme prévu. Mais sous-jacente à la plupart des estimations se trouve une hypothèse dangereuse selon laquelle même cette incertitude peut être quantifiée et prise en compte dans nos estimations. Si les ingénieurs optimistes ont tendance à sous-estimer de 15 % la durée d’une tâche donnée, nous intégrons simplement cette correction dans la formule pour une meilleure prédiction.
Cette obsession de spécifier et de mesurer à l’avance le processus complet enveloppe un écart positif ou négatif autour d’un système qui considère les ingénieurs comme des machines poussant des produits de travail prévisibles à travers un pipeline à un flux constant. Ensuite, cette métaphore du développement de logiciels est traitée comme réelle et traduite en calculs mathématiques qui recouvrent les fonctions fantaisistes d’un vernis de validité quantitative.
Pourtant, pour dire ce qui devrait être évident, les êtres humains ne sont pas des machines. (Dieu merci pour cela.) Et peut-être moins évidemment, la complexité de toute tâche d’ingénierie logicielle non triviale est presque impossible à estimer avec précision à l’avance.
Notre domaine est si nouveau et évolue rapidement. Cela fait des performances de la semaine dernière un très mauvais prédicteur de la vitesse de la semaine prochaine. Tant de défis intéressants auxquels nous sommes confrontés chaque jour sont nouveaux et inconnus, et même les plus connus ne resteront pas immobiles.
Prenons un exemple trivial : implémenter une page de connexion. Tout ingénieur logiciel expérimenté l’a fait des dizaines ou des centaines de fois. Nous connaissons bien le modèle de la solution et nous pouvons faire des prédictions sur la durée de la prochaine. Mais vient ensuite une nouvelle façon plus sécurisée de gérer l’authentification et l’autorisation, et soudain nous devons repenser et réimplémenter le fonctionnement d’une page de connexion de base.
La plupart des défis de génie logiciel sont bien plus compliqués qu’une page de connexion. C’est comme il se doit quand on s’attaque à de gros problèmes et qu’on crée une valeur substantielle. Faisaient des choses qui n’avaient pas été faites auparavant, ou peut-être n’ont-elles pas été faites aussi bien que nous pensons que c’est maintenant possible. Étaient en territoire inconnu, avec une boussole mais pas de carte.
Cette incertitude, en d’autres termes, est bonne. C’est le signe que notre ambition est suffisamment visionnaire, que nous nous chargeons d’un travail qui a du sens et qui en vaut la peine. La mauvaise prévisibilité n’est pas le problème. Les estimations arbitraires sont.
Comme pourrait le dire un statisticien, il y a trop de bruit dans le système, plus de variance que nous ne pourrions éventuellement corriger dans nos estimations. Et le travail essayait d’estimer, si son travail vaut la peine d’être fait, est fondamentalement non déterministe.
Lorsque les estimations sont basées sur le mythe des machines à coder métronomiques s’attaquant au travail déterministe, elles sont une perte de temps totale.
Mais perdre du temps n’est que le début. C’est le coût le moins grave.
De mauvaises estimations forcent de mauvais comportements qui sont également mauvais pour les affaires
Les estimations des ordures ne tiennent pas compte de l’humanité des personnes qui font le travail. Pire, ils impliquent que seuls le système et ses processus comptent.
Cela finit par forcer les mauvais comportements qui conduisent à une ingénierie inférieure, à la perte de talents et, finalement, à des solutions moins valables. De telles estimations sont le bâton de mesure d’une culture dysfonctionnelle qui suppose que les ingénieurs ne produiront que s’ils sont obligés de le faire de sorte qu’ils ne se soucient pas de leur travail ou des personnes qu’ils servent.
En retard sur les promesses des estimations? Oubliez votre famille, vos amis, votre bonheur ou votre santé. Il est temps de bousculer et de moudre.
Vous ne pouvez pas élaborer une solution de qualité dans le temps qui vous a été imparti ? Piratez une solution rapide pour pouvoir fermer le ticket. Résoudre les problèmes en aval que vous créerez est le problème de quelqu’un d’autre. Qui a besoin de tests automatisés de toute façon ?
Inspiré d’une nouvelle idée de la façon dont ce logiciel pourrait être mieux construit que prévu à l’origine ? Gardez-le pour vous afin de ne pas gâcher la chronologie.
Bludgeez les gens avec une estimation suffisante, et ils apprendront bientôt à déjouer le système. Ils surestimeront la complexité pour gagner du temps. Ils ralentiront lorsqu’ils progresseront trop rapidement afin de ne pas fixer d’attentes futures trop élevées. Les gens intelligents seraient idiots de faire moins.
Les individus et les interactions créent plus de valeur que les processus et les outils
Les individus et les interactions sur les processus et les outils. C’est l’une des valeurs clés du Manifeste Agile. C’est une déclaration de ce que nous devrions valoriser en tant qu’êtres humains compatissants et éthiques. C’est aussi une affirmation selon laquelle se concentrer davantage sur les personnes que sur les processus conduit à des résultats de meilleure qualité.
Une culture d’ingénierie logicielle générative est construite sur une base de confiance et guidée par les relations humaines. C’est un réseau social d’adultes avec un engagement commun à élaborer des solutions de haute qualité et de grande valeur qui résolvent des problèmes importants ou saisissent des opportunités significatives.
Il n’y a pas de jeu avec le système dans une telle culture. Une cause commune inspire les gens à faire de leur mieux.
Les progrès sont mesurés par la valeur créée, et non par les tickets clôturés. Et si (quand) les gens découvrent qu’il existe une meilleure approche que ce qui est spécifié dans l’estimation, ils partagent volontiers ces idées, sachant qu’une solution de qualité, et non une estimation arbitraire, est la mesure ultime du succès.
Lorsque nous nous concentrons sur les individus et les interactions plutôt que sur les processus et les outils, nous donnons toute la valeur à ce que chaque individu a à offrir, et nous multiplions la valeur que les équipes créent en collaboration.
Cela peut être moins prévisible que ce que nous obtenons lorsque nous contrôlons les gens avec une estimation détaillée pour un produit entièrement spécifié, mais abandonner ce contrôle et cette prévisibilité débloque finalement une valeur beaucoup plus grande.
Les feuilles de route, les plages et les relations sont le moyen
Il est tentant de suggérer que nous pourrions supprimer complètement les estimations.
Je pense qu’il existe des scénarios convaincants dans lesquels nous pourrions faire exactement cela : nous mettre d’accord sur notre mission commune, nous approprier notre vision commune, puis travailler ensemble pour créer un logiciel de qualité sans aucune prédiction préalable du temps que cela prendra ou combien il faudra coûtera. Imaginez simplement les gros problèmes significatifs que nous pourrions résoudre, les solutions élégantes que nous pourrions élaborer.
Cependant, une telle approche est rarement pratique dans un environnement commercial, où nous devons généralement faire des compromis pragmatiques avec les budgets et les échéanciers.
La réponse n’est donc pas d’éliminer complètement les estimations, mais plutôt de les aborder comme une conversation dans une culture de confiance mutuelle.
Les équipes de produit et d’ingénierie doivent avoir des conversations ouvertes et honnêtes au début et tout au long du cycle de vie du développement logiciel. Ces conversations partent du principe que tout le monde s’en soucie et fera de son mieux pour résoudre les problèmes importants, dans les délais et dans les limites du budget.
Que pensons-nous pouvoir accomplir avec les ressources disponibles ? Que pouvons-nous livrer et quand ? Quels sont nos plans de sauvegarde si le temps ou les ressources manquent ?
Ces conversations débouchent sur des feuilles de route et des gammes provisoires : Avec humilité, voici comment nous pensons que le projet va se dérouler. Et voici les limites supérieure et inférieure du temps que nous pensons qu’il faudra pour terminer.
Au fur et à mesure que le développement progresse, les conversations se poursuivent. Si certains aspects du projet s’avèrent plus difficiles à résoudre que prévu, retardons-nous une fonctionnalité ? Choisir une solution plus simple ? Accepter de modifier la feuille de route pour tenir compte du temps supplémentaire ?
Si (quand) nous proposons une idée plus valable en cours de développement, modifions-nous la feuille de route ou gardons-nous cette idée pour le prochain cycle ?
Lorsque les relations entre les équipes et au sein des équipes sont saines, ces conversations se produisent tout le temps et mènent à des solutions de plus grande valeur.
Lorsque les estimations des déchets régissent les processus et les outils, tous ces changements en cours de route sont perçus comme un échec à respecter l’estimation. Mais l’échec est en fait dans l’estimation elle-même. C’est un échec à reconnaître la plus grande valeur créée lorsque nous faisons confiance à de bonnes personnes et à de bonnes équipes pour faire de leur mieux.
Au lieu de délais et de tickets, nous pouvons diriger avec mission et vision. Nous pouvons reconnaître et accepter que chaque collaboration est une conversation, et chaque projet est un voyage d’exploration qui ne peut pas, qui ne doit pas, être entièrement planifié à l’avance.
Parce qu’en ingénierie, comme dans la vie, les bonnes choses ne sont souvent pas ce que nous prévoyons avant de commencer. C’est ce que nous trouvons en cours de route.
Copyright © 2022 IDG Communications, Inc.