Faire des estimations précises de projets logiciels

estimation de projet logiciel

Pixabay

introduction

L'estimation est simplement difficile. Malheureusement, c'est aussi très nécessaire. Les entreprises utilisent des estimations pour projeter les calendriers de publication, prendre des engagements envers leurs clients, décider si une fonctionnalité proposée vaut la peine d'être mise en œuvre, suivre la vitesse des équipes et hiérarchiser efficacement le travail. Les dirigeants veulent souvent savoir quand une fonctionnalité ou un livrable sera prêt pour la production. Après tout, le développement de logiciels n'est pas un investissement insignifiant. Sans estimations, comment le chef de projet ferait-il une évaluation? Si les humains pouvaient prédire l'avenir avec précision, les gens ne gagneraient pas aux courses de chevaux 2% du temps. L'estimation est la grande énigme. Il est essentiel et nécessaire pour les entreprises de demander à leurs collaborateurs de faire l'impossible: prédire l'avenir.

Tout d'abord, passons en revue quelques méthodes d'estimation populaires (au cas où vous auriez manqué une partie de l'excitation). Ensuite, nous pouvons voir ce que cela signifie pour nous et nos projets.

Le modèle de diseuse de bonne aventure

Ce modèle ne nécessite pratiquement aucun effort pour produire une estimation. Les estimateurs réfléchissent un peu à ce qui doit être fait pour implémenter et tester une fonctionnalité, puis ils jettent un nombre. Cela ressemble beaucoup à "… (longue pause)… Ummmmm… 6 semaines." Puis tout le monde hoche la tête et on passe à autre chose. Ils pourraient passer un certain temps sur le front-end à parler de ce qu'ils savent des exigences (ce qui n'est probablement pas une image complète). Cette analyse minutieuse rend leur estimation plus fiable. À la fin du projet, il y a toujours une justification acceptée pour expliquer pourquoi l'estimation était si éloignée de la réalité. Il y a toujours des circonstances imprévues qui peuvent servir de bouc émissaire. Personne ne vient souvent à l'esprit que le modèle est gravement défectueux.

Alors, comment pouvons-nous améliorer ce processus? Je sais! Nous pouvons utiliser la technique de décomposition (c.-à-d. Diviser pour conquérir). Cette approche suppose que vous connaissez l'étendue complète de la fonctionnalité ou du projet sur le front-end. Chaque fonctionnalité est décomposée en morceaux de la taille d'une bouchée. Chaque morceau est estimé (style diseuse de bonne aventure), puis nous les additionnons pour obtenir une estimation globale des fonctionnalités / projets. C'est certainement une approche plus compliquée, mais elle semble meilleure pour deux raisons:

• Les petits morceaux de travail ont tendance à être plus faciles à estimer de manière fiable.
• Bien qu'il y ait encore une possibilité d'erreur (+/- un certain montant), on suppose que les erreurs s'annuleront lorsque vous additionnerez tout et que vous obtiendrez une estimation globale plus fiable.

Le défaut fondamental de cette approche est que les contributeurs individuels (les personnes qui font réellement le travail) sous-estiment universellement. Ils sont toujours nettement meilleurs que ceux au-dessus et autour d'eux, mais ce n'est pas une barre haute. Cela ne semble pas être le cas, car nous avons tous vu des cas où les développeurs se sont surpris en accomplissant quelque chose en avance sur le calendrier. Mais il s'agit d'un point de données unique, pas d'une tendance. Les gens gagnent en fait occasionnellement au casino; dépensez de l'argent dans un casino tous les jours pendant un an et vous aurez moins d'argent qu'au départ. Si vous suivez les estimations par rapport aux chiffres réels pendant un an ou deux, vous découvrirez que les estimations ne correspondent pas à la réalité. Alors que de nombreux hommes d’affaires sont absolument certains que les développeurs complètent paresseusement leurs estimations et utilisent le temps supplémentaire pour «plaquer l’or» ou vérifier leurs stocks,les données montrent le contraire. La stratégie «d'annulation» ne fonctionne pas.

Et maintenant? Abandonnons le modèle de diseuse de bonne aventure et passons à une approche basée sur la taille. Il s'avère que, alors que les humains sont assez horribles pour estimer le temps d'achèvement, nous sommes en fait assez bons pour dire à quel point quelque chose est gros. Nous sommes particulièrement doués pour le dimensionnement comparatif («c'est plus gros que ça, mais plus petit que ça là-bas»). Si nous pensons en termes de taille ou de complexité plutôt qu'en termes de temps, notre cerveau le traite de manière plus fiable. Ensuite, nous pouvons prendre les valeurs de taille et calculer le nombre réel d'heures pour le projet en fonction d'une formule magique astucieuse! Et c'est à ce moment que le modèle populaire de points de fonction entre en scène (scène à gauche).

Analyse des points de fonction (FPA)

Pour l'analyse des points de fonction, nous devons identifier cinq types de choses dans notre application: les entrées externes, les sorties externes, les requêtes externes, les fichiers d'interface externes et les fichiers logiques internes (ne vous inquiétez pas trop des définitions; vous pourrez les rechercher plus tard). Chaque exemple de ceux-ci (une fonction) est associé à une complexité (faible, moyenne ou élevée). Nous utilisons le tableau ci-dessous pour déterminer le nombre de points attribués à chaque fonction.

Maintenant, si nous additionnons les points pour toutes nos fonctions, nous pourrions obtenir un nombre comme 457 points de fonction pour notre projet. Ensuite, nous avons juste besoin d'une formule pour calculer le nombre d'heures… Sur la base de notre dernier projet, notre «taux de livraison» était de 15 points de fonction par personne et par mois. Cela représente environ 30 mois-personnes de travail, ce qui devrait prendre un peu plus de deux mois et demi pour mon équipe de 12. Ta-da!

C'est certainement plus complexe que notre modèle précédent. En fait, il y a quatre domaines clés de complexité à reconnaître.

1. Les cinq types de composants ne sont pas nécessairement intuitifs et il est facile d'oublier de mettre quelque chose dans la liste ou de l'affecter au mauvais compartiment.
2. La table utilisée pour générer réellement les points de fonction contient des nombres magiques dont la validation nécessiterait beaucoup d'efforts. Ces chiffres sont-ils correctement calibrés pour générer des estimations fiables pour mes équipes?
3. Le taux de livraison (une pièce essentielle du puzzle) est calculé en fonction de la productivité de votre équipe. À quelle fréquence devons-nous calculer un nouveau nombre? Il y a en fait très peu d'indications à ce sujet.
4. Qu'est-ce qui constitue une complexité faible, moyenne ou élevée? Comment définir cela pour que tout le monde le comprenne? Est-ce que cela n'est pas essentiel pour l'exactitude de nos calculs?

Il y a plusieurs pièces mobiles dans cet exemple très simple, et nous n'avons même pas discuté de modèles de complexité plus compliqués et des autres données qui peuvent entrer en jeu (ex. Taux de coût, taux de support, densité de défauts, etc.). Plus de pièces mobiles signifie plus de possibilités d'erreurs. Rendons-nous l'estimation trop compliquée maintenant? Nous ne payons pas les développeurs pour qu'ils consacrent beaucoup de temps à l'estimation. Je ne peux pas vendre un devis à mes clients. J'ai besoin d'un logiciel fonctionnel. Y a-t-il autre chose là-bas?

Devenir agile

Examinons maintenant brièvement Agile Scrum (juste assez pour faire une comparaison). Comme indiqué précédemment, les humains sont terribles pour estimer le temps et sont assez bons pour le dimensionnement comparatif. Voici quelques termes à comprendre:

• Un sprint - une période de temps encadrée (généralement deux semaines).

• User story - un travail discret, de préférence assez petit pour être effectué par une seule personne dans un sprint. C'est ce que nous estimons.

La stratégie la plus populaire consiste à utiliser une séquence de fibonacci (0, 1, 2, 3, 5, 8, 13) pour les estimations. Ce n'est pas linéaire - à mesure que vous montez dans l'échelle, la taille des espaces augmente. La clé est que les écarts devraient être suffisamment larges pour qu'il n'y ait aucune raison de discuter de différences insignifiantes. Une fois que vous avez dépassé 3, la différence entre 4 et 5 ou 7 et 8 est si négligeable qu'il est inutile de passer du temps à déterminer lequel il s'agit. Une séquence de base 2 fonctionnerait également (0, 1, 2, 4, 8, 16, etc.).

«Mais attendez, ce n'est qu'un chiffre. Qu'est-ce que ça veut dire? Combien d'heures est un point? » Les points ne sont pas destinés à être directement corrélés aux heures, car s'ils le faisaient, les équipes seraient tentées de revenir à l'estimation en heures, puis de les convertir en points d'une manière ou d'une autre. Comme indiqué précédemment, l'exactitude de nos estimations provient du dimensionnement comparatif et non de l'estimation du nombre d'heures que quelque chose prendra. Si vous donnez à l'équipe la capacité de penser en termes d'heures, vous compromettez votre capacité à estimer avec précision.

Disons que vous avez commencé par un exercice d'étalonnage. Faites entrer votre équipe dans une pièce et parcourez une liste de 10 à 12 user stories. Choisissez-en un qui est petit mais pas le plus petit et faites-le en premier. Passez en revue et annoncez que cette histoire est un «3». Vous ne demandez pas. Vous dites. Ensuite, passez à l'histoire suivante. "Si c'était un 3, qu'est-ce que celui-ci?" Maintenant, l'équipe évalue les histoires par rapport à d'autres histoires. Finalement, ils auront une assez bonne idée de ce qui constitue un «1», un «2», etc. Ils n'évaluent pas. Le temps n'a pas d'importance. Ils évaluent les histoires par rapport à d'autres histoires qui en ont déjà un certain nombre. Vous pouvez ensuite mettre des exemples d'histoires pour chaque numéro de la séquence dans un document appelé règle. Ils peuvent l'utiliser comme référence s'ils ne sont pas sûrs de ce qu'est un «5».

Voici maintenant la clé. La sauce magique qui fait ce travail est la «vélocité» (le nombre de points qu'une équipe peut compléter dans un sprint en moyenne sur 3-4 sprints). Disons que votre sprint dure deux semaines et que votre équipe de 8 personnes a une vitesse moyenne de 35 points. Vous obtenez 35 points en 640 heures de travail (8 x 80 heures). Si nous comprenons qu'une fonctionnalité va prendre environ 100 points de travail du début à la fin, je sais que cela représente environ 6 semaines de travail et environ 1900 heures. L'équipe est très douée pour dimensionner régulièrement les histoires, et vous en tirez parti pour planifier votre projet. Ce calcul fonctionne car la durée est cohérente d'un sprint à l'autre.

Pour effectuer une planification de haut niveau à long terme, vous pouvez demander à vos prospects de décomposer les fonctionnalités de haut niveau en histoires intermédiaires et de leur attribuer des valeurs ponctuelles. Il y aura une perte de précision, mais vous tirez parti du modèle qu'ils comprennent déjà. Un chemin plus précis serait le dimensionnement relatif au niveau de l'entité. "Cette fonction est plus grande que cette entité à 40 points, plus petite que cette entité à 120 points là-bas, et légèrement plus grande que l'entité à 65 points que nous venons de faire." Les histoires sont regroupées en «épopées». Si chaque fonctionnalité est une épopée, à la fin, vous saurez combien de points il a fallu pour compléter cette fonctionnalité. Gardez un historique de cela et vous pouvez l'utiliser pour la planification de votre version.

Conclusion

De nombreuses méthodologies sont utilisées aujourd'hui. Chacun a des avantages et des inconvénients. D'une manière ou d'une autre, nous devons trouver comment maximiser l'exactitude de nos estimations afin de pouvoir prendre de bonnes décisions. Cela ne veut pas dire que nos estimations doivent être exactes. Ils doivent juste être suffisamment précis pour être utiles. Si vous ne comprenez pas l'estimation, vous pourriez supposer que les estimations n'étaient pas exactes parce que l'équipe n'a pas fait du bon travail. Ils n'ont pas estimé correctement ou n'ont pas exécuté correctement le projet. Les coups continueront jusqu'à ce que les estimations s'améliorent. Mais les estimations ne doivent jamais être utilisées comme un engagement. C'est une meilleure estimation basée sur les informations limitées dont nous disposons aujourd'hui. Lorsque de nouvelles informations apparaissent, nous devons autoriser la révision des estimations. Tout le reste s'attend à l'impossible, ce qui est un problème de leadership (pas avec l'équipe).

L'approche de Scrum est beaucoup plus simple que ce que nous voyons dans l'analyse des points de fonction. Et je dirais que c'est beaucoup plus fiable que les tables magiques avec des nombres magiques. Il en a pour son argent (effort minimal avec un degré de précision raisonnablement élevé). Du point de vue de l'effort, cela ne crée pas un processus lourd à comprendre et à utiliser pour les équipes. L'estimation de l'élément agile peut en fait se produire très rapidement une fois que tout le monde comprend les détails du travail estimé. C'est certainement mieux que d'extraire des nombres de rien. Tirer parti de la vitesse fait quelque chose de très important: il apporte des données historiques dans le calcul. À chaque sprint, vous recalculez votre vitesse. Ceci est essentiel, car le débit change avec le temps. Les équipes qui utilisent FPA peuvent tirer leur taux de livraison de leur projet précédent,ce qui, dans certains cas, remonte à plusieurs mois. Beaucoup de choses ont probablement changé depuis. Ma suggestion est pour vous d'explorer Agile et de vraiment faire des efforts pour comprendre les points de l'histoire et la vitesse. Ne vous rabattez pas sur l'estimation en heures simplement parce que c'est ce que vous comprenez. Je crois que vous vous remercierez plus tard.

Sondage rapide