Estimation des coûts des logiciels - Pourquoi pas?

Parfois, je sens que je ne vis pas dans le même monde que tout le monde. j'étais (et suis), impliqué dans l'estimation de logiciels professionnels, analyse comparative, et les processus de passation de marchés pour près de la moitié de ma vie, et encore la plupart des gens avec qui je parle n'ont pas la moindre idée de quoi il s'agit. Surtout le "groovy, cool, Nouveau, Jeune, génération de jeunes super cool', n'a aucune idée de quoi je parle. « L'estimation du logiciel est difficile, et va toujours mal, alors pourquoi même l'essayer?' '#Noestimates', regarde sur twitter, c'est une vraie chose. Et ces gens sont sérieux! Ils croient au pouvoir de l'équipe. C'est plus facile à dire qu'à faire quand vous avez une entreprise à gérer. Comme un ami proche à moi, qui travaille pour un grand intégrateur de système international, me dit toujours: « Aucun client ne nous a jamais donné un million de dollars avec la demande de créer une solution logicielle, tant qu'il apporte une certaine valeur commerciale'. Je suis tellement ennuyé chaque fois que les gens disent que l'estimation logicielle n'est plus nécessaire dans le monde agile de la livraison. Il est, et encore plus qu'avant!

Les équipes agiles utilisent souvent des story points, une unité de mesure d'effort arbitraire qui est relative à une certaine quantité de travail. Les points d'histoire ne sont pas reproductibles, non vérifiable, non objectif et non défendable. Mais la communauté agile semble réussir à convaincre la direction informatique de cette planète que les métriques basées sur des points d'histoire sont utiles pour soutenir les décisions de gestion.

C'est vraiment comme si quelqu'un avait convaincu les peintres du monde d'utiliser des « points muraux » au lieu d'une métrique standardisée comme le mètre carré pour mesurer la taille des murs et estimer leurs travaux de peinture murale.. Je ne pense pas que beaucoup de gens accepteraient une citation comme « Je vais vous facturer $ 100 par point de mur’, à droite? n'a tout simplement pas de sens, car le nombre de points de mur ne peut jamais être mesuré objectivement, car il n'est pas standardisé. Pour donner une citation comme « $ 100 par mètre carré' a beaucoup de sens, car il est standardisé, et donc transparent, prévisible et défendable.

 

Seulement aujourd'hui, j'ai parlé à 2 différentes organisations clientes, tous deux se plaignent que leur fournisseur, travail agile, a complètement sous-estimé l'effort nécessaire pour mettre en œuvre un logiciel « indispensable », entraînant de graves dépassements de coûts et de calendrier. Comment est-ce possible en agile, tu demandes? Très simple! Bien que la portée soit censée être variable, les organisations ont encore besoin d'un certain ensemble minimal de fonctions (et non fonctionnel) les utilisateurs doivent être prêts et mis en œuvre à un moment donné et ils allouent également un certain budget à cela, car ils doivent se conformer aux lois financières et comptables. Si vous sous-estimez l'effort (et vous le ferez si vous n'utilisez que des estimations d'experts!), l'équipe sera trop petite et le logiciel ne sera pas prêt quand il devrait l'être.

L'estimation des coûts des logiciels est toujours très pertinente, aussi en temps agile. Lors de la conférence annuelle de l'International Cost Estimation and Analysis Association (ICEAA), en juin dernier à Phoenix (LA, Etats-Unis), L'ICEAA et Nesma ont présenté le corpus de connaissances sur l'estimation des coûts des logiciels (sCEBoK). Dans cette conférence, sur 450 estimateurs de coûts d'organisations comme Boeing, Nasa, Lockheed Martin, Marine américaine, etc. se sont réunis pour discuter des pratiques professionnelles d'estimation des coûts, également en ce qui concerne les logiciels. Pour eux, ce n'est pas une option de se cacher derrière des points d'histoire arbitraires, ils doivent se conformer aux normes internationales et aux meilleures pratiques pour s'assurer que l'estimation est aussi précise, mais aussi le plus défendable possible.

En tant qu'expérience sociale, J'ai décidé de publier un message pour informer l'industrie de l'initiative Nesma/ICEAA dans plusieurs groupes LinkedIn, et j'étais particulièrement intéressé de voir les réactions du groupe ‘Agile and Lean Software Development’, qui a plus 140.000 membres. Le texte:

« Les processus de maturité des estimations sont en moyenne encore assez faibles. De grosses sommes d'argent continuent d'être gaspillées parce que les projets n'ont pas été estimés professionnellement, entraînant des dépassements de coûts et d'échéanciers. L'un des problèmes dans l'ensemble de l'industrie est le fait que l'estimateur des coûts logiciels n'est souvent pas une profession reconnue. Dans de nombreuses organisations, les estimations sont basées sur l'expérience et les opinions d'experts humains biaisés, au lieu d'être basé sur des données historiques et des modèles paramétriques pertinents. Nesma et ICEAA (Association internationale d'estimation et d'analyse des coûts) travaillent ensemble pour créer un programme de formation et une certification pour "Software Cost Estimator", un rôle professionnel pour estimer les activités et les produits liés aux logiciels.

En coopération avec un certain nombre d'organisations de soutien et de professionnels de l'industrie, Nesma et l'ICEAA ont travaillé ensemble pour développer un corpus de connaissances sur l'estimation des coûts logiciels (sCEBoK). Conformément aux programmes de formation et de certification dont dispose déjà l'ICEAA pour l'estimation des coûts, l'objectif est de développer un programme de formation et de certification spécifiquement pour l'estimateur des coûts logiciels. L'objectif est de faire certifier les premiers estimateurs de coûts logiciels professionnels l'année prochaine lors de la conférence de l'ICEAA en mai. 2019 à Tampa, FL et à l'IWSM en novembre 2019 à Haarlem, les Pays-Bas'

Veuillez vérifier si vous en avez l'occasion: https://www.linkedin.com/groups/37631/37631-6422686037318860800

 

C'est vraiment incroyable ce que cette communauté de praticiens pense de l'estimation des coûts des logiciels. Quelques unes des réactions:

‘Pourquoi devrions-nous vouloir devenir matures en perdant notre temps?»

« Jamais impressionné par les estimations précises des nouveaux développements. »

« Désolé si cela ressemble à du sarcasme, mais vous avez inventé une boule de cristal plus sophistiquée pour produire des nombres aléatoires plus précis.

"Je pense que vous feriez mieux d'apporter cela aux communautés de cascade et de chef de projet, car les communautés agiles vont juste en rire."

' J'ai vu de la merde de cheval fumante publiée dans ce groupe, mais c'est en haut de la pile'

« Budget ce que vous pouvez vous permettre. Demandez aux équipes de livrer en continu afin que vous puissiez voir ce que vous obtenez pour votre argent. Améliorer continuellement. Si vous n'obtenez pas assez de valeur, cause racine pourquoi. '

‘Encore une autre certification pour les candidats à l’achat… Exactement ce dont cette industrie a besoin.

 

Et bien d'autres commentaires durs et injustes, de la communauté qui ne semble pas du tout se soucier des implications financières du développement de logiciels (bien qu'il y ait également eu quelques commentaires de soutien, je dois avouer).

Cadres sur cette planète, veuillez prendre note de ces réactions, car ils incarnent les vrais sentiments et croyances de nombreux praticiens de l'industrie. Ils sentent vraiment qu'ils n'ont pas besoin d'estimation (comme ce n'est pas leur argent de toute façon) et ils ne veulent pas être responsables de quoi que ce soit, exprimant la vitesse en « aléatoire, non reproductible, unités de mesure arbitraires non normalisées (par exemple,, points d'histoire)’ et donc jamais responsable de quoi que ce soit. Jeter de l'argent sur des équipes agiles et espérer le meilleur peut fonctionner dans certains cas, mais vous décevra dans la plupart des cas! « Le logiciel est un R&D processus et résultats imprévisibles!' Ce n'est pas vrai! L'estimation du logiciel n'est pas facile, mais cela peut être fait de manière précise, évitant de nombreux dépassements de calendrier et de budget comme nous en sommes témoins aujourd'hui!

Réellement, c'est le problème fondamental de toute l'industrie du logiciel. En niant qu'il est possible de mesurer avec précision la taille des exigences logicielles avec l'utilisation de normes internationales, la maturité des estimations reste faible. Si vous étudiez les travaux du professeur Abran, par exemple son étude sur le pouvoir de prédiction des points d'histoire par rapport à la mesure de la taille fonctionnelle (https://tinyurl.com/y9jf98tq), vous voyez que même l'unité de mesure d'effort arbitraire inventée pour que les équipes restent incomparables et irresponsables (points d'histoire), n'a pas autant de pouvoir de prédiction en ce qui concerne l'estimation logicielle que la mesure de la taille fonctionnelle.

La question fondamentale demeure… est-ce que les cadres de ce monde qui s'occupent d'équipes agiles continuent vraiment à acheter cela? À un moment donné, on pourrait penser qu'ils comprennent qu'ils se font arnaquer pour jeter plus d'argent aux équipes avec des résultats douteux à suivre: moins de fonctionnalités que prévu/requis, basse qualité, coût plus élevé, surtout en entretien.

L'ICEAA et Nesma sont convaincus que l'estimateur de coût logiciel certifié deviendra une véritable profession dans l'industrie, qui va aider les organisations à améliorer la maturité de leurs processus en matière d'estimation, contrôler, mesure du rendement, benchmark et sourcing. L'estimateur des coûts logiciels aidera les responsables informatiques à garder le contrôle sur leurs équipes de livraison agiles sans déranger les équipes avec des frais généraux et des déchets, tout en apportant suffisamment de transparence pour prendre des décisions éclairées.