Points d'histoire agiles vs heures : comment mieux estimer le développement de logiciels

Il peut être difficile de se concentrer sur les processus de développement de logiciels. Lorsque vous proposez une idée et que vous l'approchez des développeurs, les deux premières choses que vous demandez sont le coût de sa mise en œuvre et le temps qu'il faudra pour la construire . L'estimation est l'une des premières étapes du développement d'applications.

Dans cet article, nous comparons les deux modèles d'estimation les plus populaires dans le développement de logiciels modernes : les points d'histoire agiles par rapport aux heures .

Lisez la suite pour apprendre à estimer le temps en Agile, obtenir l'essentiel des deux modèles d'estimation, comprendre leurs différences et voir pourquoi les développeurs peuvent choisir l'un plutôt que l'autre.

Les heures sont assez faciles à comprendre et constituent depuis longtemps le principal modèle d'estimation dans le développement de logiciels. Les heures, également appelées heures-homme ou heures-travailleur, sont le nombre d'heures qu'un développeur passe sur le projet.

Alors, que sont les story points et pourquoi ont-ils émergé si nous avons déjà un modèle d'estimation simple et direct ?

Contenu:

1. Que sont exactement les points d'histoire?
2. Voici comment les story points sont calculés en Agile
3. Avantages de l'estimation en points d'histoire
4. Inconvénients de l'estimation en story points
5. Avantages de l'estimation en heures
6. Inconvénients de l'estimation en heures
7. Pouvez-vous convertir des points d'histoire en heures ?
8. Points d'histoire vs heures : que choisir pour le développement de logiciels ?

Que sont exactement les points d'histoire?

Les story points sont un modèle d'estimation relative natif d'Agile et de Scrum. Ils évaluent l' effort pour créer un produit en abordant trois aspects du développement :

• la quantité de travail que le produit nécessite

• la complexité des fonctionnalités du produit

• risques et incertitudes pouvant affecter le développement

Au tout début de l'évaluation du projet, les développeurs choisissent la user story la plus petite et la plus simple d' un produit (par exemple, une user story d'inscription) et la définissent comme une user story en 1 point. C'est la story de base : une user story qui sera utilisée pour les comparaisons de complexité. Toutes les autres user stories se verront attribuer un certain nombre de story points en fonction de leur complexité à développer par rapport à la story de base.

Cela semble assez simple à première vue, mais qui décide du nombre de points d'histoire dans chaque histoire ?

Voici comment les story points sont calculés en Agile

Comme pour les heures, les personnes qui travailleront sur le produit estiment généralement les points d'histoire pour le développement. Cependant, le processus d'estimation est légèrement différent avec les points d'histoire.

Pour attribuer des story points à une user story, plusieurs développeurs sont impliqués. Il devrait y en avoir au moins deux, mais la société peut demander à tous ses développeurs de contribuer en jouant à ce que l'industrie appelle le Planning Poker . Voici les règles du jeu :

1. Chaque développeur reçoit un jeu de cartes Planning Poker.

2. Les développeurs choisissent une user story et discutent de sa complexité et de l'effort de développement nécessaire.

3. Chaque développeur propose une carte correspondant au nombre de points qu'il attribuerait à l'histoire.

4. Si les estimations des points de reportage sont les mêmes, le nombre estimé de points est attribué au reportage.

5. Si les points de story suggérés diffèrent, les développeurs discutent de la user story jusqu'à ce qu'ils trouvent un certain nombre de points approuvés par la majorité.

6. Les développeurs choisissent la prochaine user story.

7. Répétez les étapes 3 à 5.

Lorsque nos activités se sont toutes éloignées, ce processus a été modifié. Au lieu de cartes et de réunions, les points de l'histoire sont décidés lors de discussions en ligne, lors de réunions Zoom ou dans des messageries.

Ça ressemble un peu à ça :

Cela ne signifie pas que tous les développeurs impliqués dans l'estimation des points d'histoire travailleront sur le projet, bien sûr. Mais un avantage clé du système de points d'histoire est qu'il crée un cadre plus ou moins universel qui peut être utilisé non seulement sur le projet en question mais aussi sur de futurs projets avec des caractéristiques similaires.

Il existe deux options fréquemment utilisées pour estimer les points d'histoire. Vous pouvez attribuer des points :

• en utilisant des nombres entiers (1, 2, 3… 13,14,15, etc.)

• en utilisant des nombres dans la séquence de Fibonacci (1, 2, 3, 5, 8, 13… 55, 89, 144, etc.)

La séquence de Fibonacci est une option plus pratique pour estimer le développement car elle laisse une certaine marge d'approximation. Le modèle d'ordre numérique est un peu trop précis pour des comparaisons pratiques.

Au cours du développement et entre les projets, si la user story finit par être plus ou moins complexe que prévu, les points de story attribués peuvent être modifiés.

Avantages de l'estimation en points d'histoire

Si le processus d'attribution des points d'histoire semble un peu complexe, ne vous laissez pas décourager. La planification des capacités avec des story points présente des avantages.

1. Les points d'histoire sont indépendants du développeur

Les points d'histoire pour chaque histoire sont attribués par plusieurs développeurs en cours de négociation , et la raison en est que le numéro est attribué non seulement pour un produit particulier et un développeur particulier, mais "en moyenne". Pourquoi est-ce une bonne chose ?

Des choses arrivent. Parfois, le développeur de votre projet peut quitter votre projet et être remplacé. Peut-être qu'ils tomberont malades, décideront de prendre un congé parental ou un congé sabbatique, ou tout simplement quitteront l'entreprise. Peut-être qu'ils seront sous-qualifiés ou surqualifiés pour le projet.

Lorsqu'ils sont remplacés, un nouveau développeur peut avoir une vitesse de travail différente , ce qui conduira à ré-estimer le nombre d'heures de travail nécessaires pour créer le produit.

Les points d'histoire minimisent ce problème . Attribuées par plusieurs développeurs différents, elles donnent un aperçu général de la complexité d'une user story particulière. Les points d'histoire fonctionnent pour tous les développeurs d'une entreprise particulière. (Cependant, gardez à l'esprit que les estimations des points d'histoire ne seront pas correctes pour différentes entreprises.)

2. Les story points facilitent le recalcul du temps de développement

Dans l'estimation du temps Agile avec des points d'histoire, les équipes utilisent le terme vélocité pour désigner le nombre de points d'histoire libérés en un seul sprint.

Les équipes surveillent en permanence leur vélocité, et elle est assez variable au départ. Une équipe peut publier des fonctionnalités valant cinq points d'histoire une semaine et vingt points d'histoire la suivante. Mais ce n'est qu'au début. Au fur et à mesure que le projet progresse, le graphique de vitesse s'égalisera .

Avec les heures, si un membre de l'équipe change, chaque tâche dans laquelle il est impliqué devra être réestimée pour ajuster les délais. Avec les story points, cela n'est pas nécessaire - l'équipe peut ajuster la date limite du projet après le prochain sprint en connaissant le changement de vélocité globale.

Les points d'histoire évaluent la performance de l'équipe dans son ensemble , éliminant ainsi le besoin de ré-estimation par tâche.

3. Les story points sont bons pour surveiller les performances de l'équipe

Lorsque des équipes travaillent sur des projets et/ou des tâches similaires à des moments différents, la vélocité peut facilement vous montrer les progrès réalisés par chaque équipe. Se sont-ils améliorés et de combien ? Quelle équipe ou quel développeur a des difficultés et pourrait avoir besoin d'une formation supplémentaire ? Quelle est la courbe d'apprentissage? Peut-être qu'une autre équipe est plus performante ?

Velocity est un excellent outil pour évaluer les performances de vos équipes non seulement sur place mais en continu.

4. L'estimation du temps de lancement avec des points d'histoire est plus précise

En suivant la vitesse, l'équipe sait avec une grande précision combien de points d'histoire elle peut libérer en un sprint. Bien qu'il faille un certain temps à l'équipe de développement de l'application pour calculer sa vélocité, une fois qu'elle a été calculée, la date de lancement estimée est facile à prévoir .

De plus, les changements dans les membres de l'équipe, les exigences ou le nombre/la complexité des fonctionnalités ne causent pas beaucoup de difficultés avec la réestimation.

5. Vous pouvez réutiliser les points d'histoire pour de futurs projets afin d'accélérer l'estimation

Il n'est pas rare qu'une entreprise connaisse bien un créneau spécifique (ou plusieurs) et crée plus d'un produit avec un ensemble de fonctionnalités similaire. Après avoir terminé ne serait-ce qu'un projet estimé en points d'histoire, les développeurs peuvent se référer à cette estimation pour de nouveaux projets . Cela raccourcira le temps d'estimation.

Cependant, il est important de continuer à suivre la vélocité de chaque projet, car les circonstances peuvent changer.

6. Les points d'histoire améliorent le travail d'équipe

Traditionnellement, les sociétés de développement ont plusieurs équipes de développeurs, chacune travaillant sur des projets distincts. Lors de l'estimation en heures, c'est le développeur travaillant sur le projet qui fait une estimation. C'est une bonne chose, en général, car qui sait mieux combien de temps prendra quelque chose que la personne qui le fait ?

Cependant, l'estimation de la complexité des points d'histoire offre une opportunité aux développeurs du même domaine de coopérer , ce qui se produit rarement autrement. Ce genre de travail d'équipe est une excellente occasion de partager des expériences et de se motiver les uns les autres.

Inconvénients de l'estimation en story points

Il y a toujours l'autre côté de l'argument, c'est-à-dire comment de grands systèmes sont nés. L'estimation basée sur la complexité a aussi ses inconvénients , et chaque équipe doit décider elle-même si elle dépasse les avantages.

1. Les points d'histoire doivent être attribués par plus d'un développeur

L'argument de vente du modèle de points d'histoire est son objectivité et sa valeur pour les estimations futures. Mais pour que cela soit vrai, l' estimation doit être faite par plus d'un développeur . Pour les petites entreprises avec une seule équipe ou les entreprises où il n'y a qu'un seul spécialiste dans un domaine (c'est-à-dire un seul concepteur ou développeur iOS), les story points n'apportent pas autant d'avantages. Ces petites entreprises choisissent traditionnellement les heures-travailleur comme modèle d'estimation.

2. L'estimation des points d'histoire nécessite un arriéré considérable

Pour exploiter tout le potentiel des story points, votre équipe devra y consacrer un temps considérable . Si vous travaillez sur un projet avec des fonctionnalités sur lesquelles l'équipe n'a jamais travaillé auparavant (ou n'a pas travaillé à temps plein), les deux ou trois premiers sprints seront difficiles à prévoir en termes de performances. Certes, plus vos équipes ont d'éléments de backlog, plus leurs estimations peuvent être précises en raison de l'abondance de données statistiques. Mais les points d'histoire n'est pas un système prêt à fonctionner tout de suite.

3. Les story points sont plus complexes pour la budgétisation

Les story points sont parfaits pour fixer des délais et des dates de lancement précis, ce qui peut être important pour les développeurs et pour le marketing du client. Cependant, lorsqu'il s'agit d'estimer les coûts de développement d'applications, ils sont moins pratiques .

Le fait est que les développeurs passent du temps sur un projet non seulement à écrire du code (ou à faire des conceptions, ou à tester). Un certain temps est consacré à la recherche, à la discussion - au sein de l'équipe et avec le client - à apporter des modifications, etc. Le temps passé à estimer les points de l'histoire est également du temps consacré au projet, mais il n'est pas inclus dans les points par histoire.

La budgétisation lors de l'estimation des points d'histoire est possible, mais il est généralement plus rapide et plus facile d'assimiler l'argent au temps passé sur le projet.

4. La vélocité est calculée par équipe

Cela signifie que si les équipes se mélangent entre les projets, vous devrez calculer la vélocité pour chaque combinaison de développeurs séparément. Par conséquent, l'estimation pour une équipe ne sera pas nécessairement vraie pour une autre équipe, et même changer un seul membre de l'équipe peut potentiellement invalider les estimations précédentes.

D'autre part, vous pouvez utiliser l'estimation de la complexité pour trouver les combinaisons les plus performantes. Cela prendra du temps, cependant.

Avantages de l'estimation en heures

Alors que certaines équipes Agile utilisent des points d'histoire, beaucoup doivent encore passer des heures de travail. Il y a des raisons importantes à cela. Couvre-les aussi.

1. Les heures sont un modèle familier

L'innovation, c'est bien, mais ça prend du temps. Les développeurs et leurs clients connaissent bien l'estimation des heures de travail. Pour beaucoup, l'idée est "si ce n'est pas cassé, ne le répare pas". Tant que le système propose des estimations réalisables, pourquoi passer à autre chose ?

La différence de précision des estimations peut ne pas être suffisamment importante pour que certains développeurs modifient leur façon de faire les choses.

2. Les clients paient généralement des heures

Cela nécessite peu d'élaboration. Pour les clients, l' estimation basée sur la complexité peut être source de confusion . De plus, si pour le client le budget est plus important que la date de lancement (ce qui est souvent le cas), les story points ne seront pas pertinents pour lui.

3. L'estimation basée sur les heures peut être effectuée par un développeur

Pour les petites équipes ou les indépendants, les story points sont largement inutiles, car ils nécessitent plusieurs points de vue. Sans aucune référence, l'estimation des points d'histoire est une corvée inutile.

Les heures, quant à elles, offrent au développeur travaillant sur le projet un moyen de faire lui-même des estimations assez précises .

Il en va de même pour la vélocité de l'équipe. Lorsque les équipes changent à chaque fois, comme c'est le cas avec les pigistes ou l'externalisation partielle, le suivi de la vitesse n'a que très peu de sens. L'estimation basée sur les heures est le meilleur choix ici.

Inconvénients de l'estimation en heures

Voici les raisons pour lesquelles les équipes pourraient décider d'arrêter d'utiliser les heures comme modèle d'estimation.

1. Être seul responsable de l'estimation, c'est beaucoup de pression

D'une part, estimer vos propres besoins en temps peut être plus facile, car vous ne comptez que sur vous-même.

D'un autre côté, si vous ne respectez pas vos estimations, c'est un coup dur. D'autant plus si l'équipe qui attend de commencer ses tâches dépend de vous pour terminer les vôtres.

De plus, le stress causé par la pression de livrer ce que vous avez vous-même promis peut perturber une tâche qui se déroulerait normalement.

2. L'estimation d'un développeur est toujours moins précise que celle d'une équipe

Les estimations individuelles sont subjectives et liées aux circonstances émotionnelles et psychologiques de l'estimateur.

Certains développeurs ont tendance à se surestimer et à fixer des délais qu'ils ont du mal à respecter par la suite. Cela perturbe non seulement le développement (et impose des coûts supplémentaires à l'équipe s'il y a des amendes) mais provoque également du stress et de l'épuisement chez les développeurs .

D'autres sous-estiment leurs propres compétences , prolongeant le développement plus qu'il n'est objectivement nécessaire. L'insécurité et l'habitude de trop réfléchir, de vérifier et de revérifier le travail conduisent souvent à des dates limites de développement fixées à des dates ultérieures - et les tâches sont rarement terminées avant les dates limites . La contribution de l'équipe permet une estimation plus objective.

3. Plus la tâche est grande, plus elle est difficile à estimer en heures

Cela est également en corrélation avec les situations de non-développement. Il est facile de dire combien de temps il faudra pour lire un livret universitaire de trois pages mais plus difficile d'estimer combien de temps il faudra pour terminer Guerre et Paix .

Il en va de même pour le développement. Les petites tâches sont faciles à estimer pour les développeurs ayant une certaine expérience. Plus la tâche est grande, cependant, plus les choses - se produisant à la fois à l'intérieur et à l'extérieur du projet - peuvent affecter le développement. Les estimations basées sur les heures n'offrent pas les marges des points d'histoire, ce qui rend les estimations plus approximatives.

4. Peu de flexibilité

L'estimation basée sur les heures est basée sur le développeur. Si un membre de l'équipe travaillant sur le produit change en cours de projet, l'équipe devra recalculer chaque user story affectée encore en développement ou prévue pour de futurs sprints. Cela peut représenter beaucoup de travail, selon l'état d'avancement du projet et la différence de compétences entre le développeur d'origine et le nouveau développeur. L'estimation du temps basée sur les heures est assez rigide.

Pouvez-vous convertir des points d'histoire en heures ?

Les clients peuvent demander à une équipe qui fait des estimations en points d'histoire de convertir la cartographie des points d'histoire Agile en heures . La plupart des gens qui ne sont pas familiers avec les dernières tendances en matière de développement de logiciels ne sauront pas quoi penser des points d'histoire.

Cependant, lorsqu'un client demande à combien d'heures correspond un story point, il est impossible de répondre de manière définitive. L'un des éléments clés de l'estimation basée sur la complexité est l'effort déployé pour terminer l'histoire. Mais l'effort ne se traduit pas directement en temps passé . Les heures abordent l'incertitude d'une manière plus vague que les points d'histoire.

Plus la tâche est complexe, plus il y a d'incertitude et de risques. Convertir les points d'histoire en heures de manière simple et ne compter que sur la vitesse ne prend pas en compte beaucoup de ces risques, car l' estimation basée sur les heures est plus approximative que les points d'histoire en ce qui concerne les risques et les incertitudes.

Dans une certaine mesure, l'utilisation de la séquence de Fibonacci pour attribuer des points d'histoire tiendra compte de l'incertitude dans les temps de développement, mais cela ne permet pas exactement une conversion directe.

Voici un exemple.

Une histoire de point de 1 histoire (histoire de base) prend, disons, deux heures pour terminer.

Une histoire de 13 étages peut prendre 26 heures dans le meilleur des cas – si rien ne tourne mal ou ne gêne. Par exemple, si l'API utilisée s'intègre parfaitement, point de terminaison à point de terminaison. Mais si ce n'est pas le cas, l'histoire peut prendre entre, disons, 30 et 50 heures, selon le nombre de discordances. Personne ne peut dire à l'avance comment cela se passera si le développeur n'a pas encore travaillé avec l'API en question.

Ainsi, en traduisant les points de l'histoire en heures, il doit y avoir un multiplicateur de croissance exponentielle pour faire face à l'incertitude. Et ce multiplicateur sera différent d'une équipe à l'autre.

Points d'histoire vs heures : que choisir pour le développement de logiciels ?

Comme vous pouvez le voir, les points d'histoire et les heures sont des choix valables pour un développeur pour estimer des projets.

Dans l'ensemble, nous dirions que davantage d'entreprises de produits choisissent des points d'histoire tandis que les sous-traitants ont tendance à privilégier les heures.

Les entreprises travaillant avec un modèle de prix fixe optent généralement pour une estimation basée sur les heures. Les équipes qui préfèrent Scrum choisissent souvent des story points, car elles sont littéralement nées de Scrum et sont natives de cette méthodologie.
Au cours de nos années d'expérience, nous en sommes venus à voir les choses de cette façon :

• S'il est plus important d'estimer avec précision la date de lancement que d'adapter le budget, optez pour des story points.

• Si le budget est plus important qu'une date de lancement précise, pensez aux heures.

Ou, mieux encore, combinez les deux.

Les story points sont très pratiques pour les équipes de développement travaillant sur de longs projets où le suivi de la vitesse fera la différence.

Les heures sont importantes pour les clients qui craignent de réduire leur budget. De plus, les heures ont plus de sens pour les projets à court terme.

Le système basé sur la complexité est encore assez jeune, tout comme Scrum lui-même, et il continue de se développer. La combinaison des deux modèles d'estimation et l'élaboration d'un système pour changer rapidement chaque point d'histoire en heures offre les avantages des deux modèles tout en minimisant les inconvénients.