Les estimations d’ingénierie logicielle sont des ordures

Beaucoup de devis d’ingénierie d’applications logicielles sont nuls.

Ce n’est pas parce que les entreprises utilisent des approches ou des outils incorrects. 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 ? Très bien.

Les outils ne sont pas le problème. Au contraire, la plupart des devis sont des ordures car ils sont basés 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 dépenses et des délais manqués. L’approche typique des devis finit par exiger un mauvais comportement tout en privilégiant les mesures de vanité plutôt que de fournir une valeur réelle à l’entreprise.

Le bruit et le non-déterminisme sont fondamentaux pour l’ingénierie des applications logicielles

Dans les environnements Agile, les devis sont généralement basés sur les points d’histoire et la vélocité. À quel point sera-t-il « complexe » de développer une partie discrète de l’option ? Et combien de temps nous faut-il normalement pour terminer une histoire d’une telle complexité ? J’ai déjà écrit sur la façon dont cette technique Agile corrompt Scrum avec des approches de contrôle en cascade.

En se rapprochant de cette manière, nous comprenons que tout ne se passera pas comme prévu. La plupart des cotations de prix reposent sur une hypothèse néfaste selon laquelle même cette imprévisibilité peut être mesurée et prise en compte dans nos cotations. Si les ingénieurs optimistes ont tendance à sous-évaluer de 15 % la durée d’une tâche fournie, nous intégrons simplement cette correction dans la formule pour une meilleure prédiction.

Cette fixation avec la définition et la mesure de la procédure complète à l’avance s’achève une différence positive ou négative autour d’un système qui considère les ingénieurs comme des machines pressant des éléments de travail prévisibles à travers un pipeline à un flux stable. Ensuite, cette métaphore du développement d’applications logicielles est traitée comme réelle et assimilée à des calculs mathématiques qui ont doté des fonctions fantaisistes d’un placage de validité quantitative.

Pourtant, pour énoncer ce qui devrait être apparent, les êtres humains ne sont pas des créateurs. (Dieu merci pour cela.) Et peut-être moins certainement, la complexité de tout travail d’ingénierie d’application logicielle non trivial est presque impossible à évaluer avec précision au préalable.

Notre domaine est si nouveau et évolue rapidement. Cela fait des performances de ces derniers temps un très mauvais prédicteur de la vélocité de la semaine prochaine. De nombreux défis intéressants auxquels nous sommes confrontés chaque jour sont nouveaux et non identifiés, et même les plus connus ne resteront pas immobiles.

Prenons un exemple insignifiant : la réalisation d’une page de connexion. Tout ingénieur d’application logiciel expérimenté l’a fait de nombreuses fois ou de nombreuses fois. Nous comprenons bien le modèle de l’option et nous pouvons faire des prévisions sur la durée de la prochaine. Vient ensuite une nouvelle méthode plus sûre de gestion de l’authentification et de l’autorisation, et de manière inattendue, nous devons reconsidérer et réimplémenter le fonctionnement d’une page de connexion standard.

La plupart des obstacles d’ingénierie logicielle sont encore plus complexes qu’une page de connexion . C’est comme cela doit être lorsque nous traitons d’énormes problèmes et que nous créons une valeur substantielle. Nous faisons des choses qui n’ont pas été faites auparavant, ou qui n’ont peut-être pas été faites en plus de ce que nous pensons être maintenant possible. Nous restons dans une zone inexplorée, avec une boussole mais pas de carte.

Cette imprévisibilité, tout simplement, est formidable. C’est un signe que notre aspiration est suffisamment visionnaire, que nous entreprenons un travail significatif et gratifiant. La mauvaise prévisibilité n’est pas le problème. Les estimations approximatives le sont.

Comme un statisticien pourrait le dire, il y a trop de bruit dans le système, plus de différence que nous ne pourrions éventuellement corriger dans nos citations. Et le travail que nous essayons d’estimer, s’il vaut la peine d’être fait, est fondamentalement non déterministe.

Lorsque les estimations sont basées sur l’idée fausse des fabricants de codage métronomique traitant du travail déterministe, elles constituent un ensemble complet perte de temps.

La perte de temps n’est que le début. C’est la dépense la moins importante.

De mauvaises estimations forcent de mauvais comportements qui sont également mauvais pour l’organisation

Les estimations de déchets ne tiennent pas compte de l’humanité des individus qui font l’oeuvre. Pire, ils impliquent que seuls le système et ses procédures comptent.

Cela finit par nécessiter de mauvais comportements qui se traduisent par une ingénierie inférieure, une perte de compétences et finalement des services moins importants. De telles estimations sont le bâton déterminant d’une culture dysfonctionnelle qui suppose que les ingénieurs ne produiront que s’ils y sont forcés – qu’ils ne se soucient pas de leur travail ou des personnes qu’ils servent.

les promesses du devis ? Oubliez votre foyer, vos amis, votre joie ou votre santé. Il est temps de se dépêcher.

Vous ne pouvez pas créer un service de qualité dans le temps qui vous est 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é par une originalité de la façon dont ce logiciel pourrait être développé bien mieux que prévu initialement ? Gardez-le pour vous afin de ne pas gâcher la chronologie.

Matraquez suffisamment les gens avec l’estimation, et ils découvriront bientôt le système. Ils exagèrent la complexité pour gagner du temps. Ils diminueront lorsqu’ils progresseront trop rapidement afin de ne pas fixer d’attentes futures trop élevées. Des individus intelligents seraient absurdes d’en faire moins.

Les individus et les interactions produisent plus de valeur que les processus et les outils

« Les individus et les interactions sur les procédures et les outils.  » C’est l’une des valeurs essentielles du Manifeste Agile. C’est une déclaration de ce que nous devons valoriser en tant que personnes compatissantes et éthiques. C’est également une affirmation selon laquelle se concentrer davantage sur les personnes que sur les processus entraîne de meilleurs résultats de qualité.

Une culture d’ingénierie logicielle générative repose sur la confiance et est guidée par les relations humaines. Il s’agit d’un réseau de médias sociaux d’adultes partageant le même dévouement à l’élaboration de solutions de haute qualité et de grande valeur qui résolvent des problèmes considérables ou prennent des risques significatifs.

Il n’y a pas de jeu sur le système dans une telle culture. La cause typique motive les individus à faire leur meilleur travail.

Le développement est mesuré par la valeur produite, et non par les tickets fermés. Et si (quand) les individus trouvent qu’il existe une méthode bien meilleure que celle définie dans le devis, ils partagent facilement ces idées, sachant qu’un service de qualité, et non un devis arbitraire, est l’étape suprême du succès.

Lorsque nous nous concentrons sur les personnes et les interactions plutôt que sur les procédures et les outils, nous responsabilisons la quantité de ce que chaque personne doit fournir et nous multiplions la valeur que les équipes produisent en partenariat.

Cela peut être moins prévisible que ce que nous obtenons lorsque nous contrôlons les individus avec un devis détaillé pour un article totalement défini, mais abandonner ce contrôle et cette prévisibilité débloque finalement une valeur beaucoup plus grande.

Les feuilles de route, les variétés et les relations sont la voie

Il est tentant de recommander que nous supprimions complètement les estimations.

Je pense qu’il y a des circonstances convaincantes dans lesquelles nous pourrions faire exactement cela : nous installer sur notre mission commune , s’approprier notre vision commune, puis collaborer pour créer une application logicielle de qualité ion sans aucune prévision préalable de combien de temps cela prendra ou combien cela coûtera. Imaginez simplement les gros problèmes importants que nous pourrions résoudre, les solutions sophistiquées que nous pourrions élaborer.

Une telle méthode est rarement utile dans un environnement d’entreprise, où nous devons généralement faire des compromis pratiques avec les plans budgétaires et les calendriers.

La réponse n’est donc pas d’éliminer complètement les offres de prix, mais plutôt de les aborder comme une discussion dans une culture de confiance mutuelle.

Les équipes d’articles et d’ingénierie doivent avoir une attitude ouverte et sincère discussions au début et tout au long du cycle de vie de l’évolution du logiciel. Ces discussions partent du principe que tout le monde s’en soucie et fera de son mieux pour résoudre les problèmes cruciaux, dans les délais et selon le plan de dépenses.

Que pensons-nous pouvoir réaliser avec les ressources proposées ? Que pouvons-nous fournir et quand ? Quels sont nos plans de secours si le temps ou les ressources manquent ?

Ces conversations aboutissent à des feuilles de route provisoires et à des variétés : avec humilité, voici comment nous pensons que le projet se déroulera. Et voici les limites supérieures et inférieures du temps dont nous pensons qu’il faudra pour terminer.

Au fur et à mesure que l’avancement progresse, les conversations se poursuivent. Si certains aspects du travail s’avèrent plus difficiles à corriger que prévu, devons-nous reporter une fonctionnalité ? Sélectionnez une option plus facile ? Acceptez-vous de modifier la feuille de route pour tenir compte du temps supplémentaire ?

Si (quand) nous proposons un meilleur concept en cours de développement, modifions-nous la feuille de route ou conservons-nous cette idée pour le prochain tour ?

Lorsque les relations entre et au sein des groupes sont saines, ces conversations se produisent tout le temps, et elles se traduisent par des options de plus grande valeur.

Lorsque les estimations des déchets guident les processus et les outils, tous ces changements en cours de route sont considérés comme un échec à respecter l’estimation. Cependant, l’échec est en fait dans la citation elle-même. C’est un échec à identifier la plus grande valeur créée lorsque nous comptons sur des individus et des équipes formidables pour faire de leur mieux.

Au lieu de délais et de tickets, nous pouvons diriger avec objectif et vision. Nous pouvons reconnaître et accepter que chaque partenariat est une conversation, et chaque travail est un voyage d’expédition qui ne peut pas, qui ne devrait pas, être totalement planifié à l’avance.

Parce qu’en ingénierie, comme dans la vie , les bonnes choses ne sont généralement pas ce que nous préparons avant de commencer. C’est ce que nous trouvons le long de la méthode.