Respectez vos délais : méthodes utilisées par les développeurs pour estimer l'effort

Bonjour à tous! Il existe une quantité colossale de théorie que vous devez connaître pour vous lancer dans le développement de logiciels. Certains spécialistes (par exemple, les développeurs backend qui utilisent Java et d'autres langages) en savent plus, tandis que d'autres (par exemple, les développeurs frontend qui utilisent JavaScript et React Native) peuvent en savoir un peu moins. Cela dit, les deux groupes doivent posséder un large éventail de connaissances non seulement techniques, mais aussi « organisationnelles ». Cette connaissance "organisationnelle" est un domaine de chevauchement pour les développeurs frontend et backend. Aujourd'hui, je veux parler d'un aspect de cette connaissance organisationnelle non technique. Aujourd'hui, nous allons parler de l'estimation de l'effort . Parce que je n'ai d'expérience qu'avec la méthodologie Agile(qui est considéré comme le plus populaire), plus précisément le framework Scrum, je considérerai l'estimation de l'effort dans le contexte de Scrum . D'emblée, je dois dire que l'estimation de l'effort est difficile. Pour moi, c'est l'un des aspects les plus difficiles/désagréables de mon travail de développeur. Il existe de nombreux facteurs différents à prendre en compte qui peuvent affecter votre estimation de l'effort requis pour une tâche. De plus, les futurs plans de développement seront basés sur vos estimations.

Que faire si vous fournissez une mauvaise estimation?

Si un développeur estime beaucoup plus d'heures pour une tâche que ce qui est finalement consacré à la tâche, son expertise peut être mise en doute car l'estimation était si inexacte. En d'autres termes, c'était une supposition folle. Dans le même temps, si un développeur ne fait pas le travail dans les délais prévus, il compromet les projets du client de publier le produit ou la nouvelle fonctionnalité. C'est le business, et le business c'est de l'argent. Peu de clients seront satisfaits d'un tel slip. En fait, c'est pourquoi je n'aime pas les estimations, car il est parfois très difficile de déterminer avec précision le temps nécessaire pour accomplir une tâche.

Comment faire une estimation de temps

En règle générale, les estimations sont faites en heures ou en points d'histoire. Ma préférence personnelle est de faire le processus d'estimation en utilisant des points d'histoire . Il est difficile de se tromper sur les objets physiques concrets, mais les points d'histoire sont un peu plus abstraits. Les équipes de développement de logiciels fournissent généralement des estimations en termes de temps : heures, jours, semaines, mois. Ces estimations de temps sont basées principalement sur l'expérience personnelle, les conjectures et/ou l'intuition. Dans ce cas, les développeurs regardent simplement la tâche et expriment leur hypothèse sur le temps que cela leur prendra. Par conséquent, ces estimations sont très rarement exactes, car trop de facteurs peuvent influer sur la durée des travaux. C'est pourquoi de nombreuses équipes qui utilisent la méthodologie Agile utilisent également des story points. Plongeons-nous !

Que sont les points d'histoire ?

Un story point est une unité de mesure permettant d'exprimer une estimation de l'effort total requis pour implémenter pleinement une certaine fonctionnalité. C'est-à-dire que nous parlons de relatifcomplexité. Les équipes attribuent une estimation en points d'histoire en fonction de la complexité du travail, du volume de travail et du risque ou de l'incertitude. Ces valeurs sont généralement attribuées pour diviser plus efficacement le travail en plus petits morceaux, éliminant ainsi l'ambiguïté. Au fil du temps, cela aide les équipes à comprendre ce qu'elles peuvent accomplir dans un laps de temps donné et les aide à planifier plus précisément les tâches suivantes. Cela peut vous sembler complètement contre-intuitif, mais cette abstraction est en effet pratique : elle pousse l'équipe à prendre des décisions difficiles quant à la complexité du travail. Examinons quelques-unes des raisons d'utiliser des points d'histoire lors de la planification :

• Vous pouvez éviter des estimations de temps inexactes.
• Contrairement aux estimations faites en unités de temps, les story points vous permettent de comptabiliser les frais généraux : communications entre les membres de l'équipe et le client, diverses discussions d'équipe et activités de planification, ainsi que les situations imprévues.
• Chaque équipe évaluera son travail à l'aide d'échelles différentes, ce qui signifie que sa capacité (mesurée en points) sera différente.
• En définissant une échelle pour attribuer chaque point d'histoire, vous pouvez rapidement attribuer des points sans trop de controverse.

Comment NE PAS utiliser les story points

Malheureusement, les points d'histoire sont souvent mal utilisés. Les story points peuvent être trompeurs lorsqu'ils sont utilisés pour évaluer des personnes, définir des délais et des ressources détaillés, et lorsqu'ils sont confondus avec une mesure de performance. Au lieu de cela, les équipes doivent les utiliser pour comprendre la portée/la complexité de chaque tâche et pour établir des priorités. Peut-être que les parties considérées comme plus difficiles devraient être abordées en premier, afin qu'elles puissent être faites avant la fin du sprint , en déplaçant éventuellement les tâches plus faciles vers plus tard. Permettez-moi de vous rappeler ce qu'est un sprint dans le contexte de la méthodologie Scrum : La durée de cette période est déterminée au début du développement et est convenue entre l'équipe et le client. Cela peut être une période de deux semaines ou d'un mois, ou toute autre période. En règle générale, les estimations d'efforts sont faites au début de chaque sprint afin de planifier le travail qui peut être terminé d'ici la fin du sprint, lorsque le travail terminé est livré au client. La démo vous aide à voir vos progrès dans le développement du produit, à recevoir les commentaires du client et à ajuster la trajectoire du projet en fonction de la vision du client. Mais on s'égare un peu. Revenons aux estimations. Il serait trop subjectif qu'un seul développeur fournisse des estimations pour toutes les tâches. Ce processus est donc généralement un travail d'équipe. Il existe plusieurs techniques que les équipes peuvent utiliser pour générer des estimations. Aujourd'hui, nous allons nous intéresser à la technique la plus populaire : le scrum poker . Cette technique nécessite un manager qui jouera le rôle de modérateur pour le scrum poker . Cela peut être quelqu'un qui est un scrum master ou éventuellement un PM .

Qu'est-ce que Scrum Poker ?

Scrum poker , ou planning poker, est une technique d'estimation basée sur la conclusion d'un accord. Il est principalement utilisé pour estimer la complexité du travail à venir ou la taille relative des tâches de développement logiciel. Je dirai tout de suite que scrum pokerest une pratique courante de développement de logiciels, et vous devez savoir de quoi il s'agit. Cela implique généralement une application ou un site Web pour faciliter la création collaborative d'une équipe d'une estimation pour une tâche particulière. Comment cela peut-il arriver? L'équipe prend quelque chose du backlog (une nouvelle tâche, certaines fonctionnalités) et discute brièvement des pièges possibles et des autres nuances qui y sont associées. Ensuite, chaque participant choisit une carte avec un nombre qui reflète son estimation de la complexité. Oh, encore une chose, lors de ces estimations, nous utilisons des nombres dans la suite de Fibonacci plutôt que des nombres ordinaires. Les nombres de Fibonacci sont populaires au scrum poker, car il y a un écart de plus en plus grand entre eux (ressemblant aux niveaux d'une pyramide). Certaines tâches seront très complexes et nous ne pourrons pas nous en sortir avec un petit nombre de points d'histoire. Certaines cartes inhabituelles ont les significations suivantes :

Nombre inconnu de terminaux

Tâche infiniment longue

Besoin d'une pause

Les méthodes d'estimation moins courantes utilisent :

• Tailles de t-shirts — S, M, L, XL
• Races de chiens - chihuahua, carlin, teckel, bouledogue, etc. (personnellement, je pense que c'est l'unité de mesure la plus étrange pour l'estimation de l'effort = D)

L'équipe compare ensuite les estimations données par différents développeurs pour la même tâche. S'ils sont d'accord, tant mieux ! Si ce n'est pas le cas, les raisons (arguments) des différentes estimations doivent être discutées. Après cela, l'équipe travaille ensemble pour former une estimation unique que tout le monde accepte, plus ou moins. Alors pourquoi le poker est-il même utilisé pour planifier des projets logiciels sérieux ? Vous devez admettre que c'est étrange. Le fait est que ce type de gamification encourage les membres de l'équipe à penser de manière indépendante, les invitant à révéler leurs estimations en même temps que leurs coéquipiers. Ceci, à son tour, évite de créer une situation où certains membres de l'équipe dépendent des opinions des autres. Si cela n'était pas fait de cette façon, les développeurs moins expérimentés examineraient et se concentreraient sur les estimations fournies par les membres de l'équipe plus expérimentés, et cela rendrait leurs propres estimations moins utiles. Mais montrer simultanément les estimations rend cela essentiellement impossible. Offres Atlassianune application scrum poker à utiliser dans le processus de planification.

Exemple d'estimation d'effort

Supposons que votre équipe ait établi l'échelle suivante pour attribuer des points d'histoire aux estimations : Scrum poker est joué pour chaque tâche, et vous fournissez une estimation comme suit :

• Vous n'avez jamais implémenté une fonctionnalité similaire auparavant : +3
• La fonctionnalité est de taille moyenne : +2
• La mise en œuvre sera très complexe : +3
• Ecrire des tests pour la fonctionnalité sera très complexe : +3

En additionnant chaque composant, vous obtenez un total de 11 points d'histoire, mais il n'y a pas de carte de ce type, vous en suggérez donc 13. Un collègue propose l'estimation suivante pour la tâche :

• Il a déjà travaillé avec une tâche similaire : +1
• La fonctionnalité est de taille moyenne : +2
• La mise en œuvre sera de complexité moyenne : +2
• L'écriture des tests pour la fonctionnalité sera de complexité moyenne : +2

Son résultat intermédiaire est de 7 points d'histoire, mais ce nombre n'existe pas dans la série de Fibonacci, il soumet donc la carte avec le nombre le plus approximatif - 8. D'autres membres de l'équipe font également leurs estimations en fonction de leurs opinions subjectives. Ensuite, tout le monde montre ses cartes et vous constatez que presque tous vos collègues ont donné une estimation de 13, à l'exception du seul développeur qui a suggéré un 8. Dans ce cas, il est autorisé à parler pour donner les raisons de son estimation inférieure. Supposons qu'il offre cette justification : il a déjà travaillé sur la même tâche, et ce n'est pas aussi difficile que cela puisse paraître. En fin de compte, il convainc le reste de l'équipe de changer d'avis de 13 à 8 points d'histoire, affirmant qu'il aidera celui qui finira par assumer cette tâche. Ou peut-être le fera-t-il lui-même. En tout cas, ça ne Peu importe que les autres acceptent ou non ses arguments, car d'une manière ou d'une autre une estimation sera attribuée à la tâche, et l'équipe passera à la suivante. Au départ, les estimations seront inexactes, tout comme les estimations de la quantité de travail que vous prévoyez d'effectuer au cours de la prochaine période (sprint). Après tout, ces estimations faites à l'aide d'estimations. Après un certain temps, peut-être trois mois plus tard, l'équipe commencera à estimer plus précisément le temps requis pour les tâches, et la quantité moyenne de travail que l'équipe est capable d'effectuer dans un sprint deviendra évidente. Mais il s'agit d'un processus visant à établir un plan général pour l'étendue des travaux. Il se concentre principalement sur le temps, mais dans ce cas, il peut y avoir de nombreux facteurs pertinents différents. Par exemple, supposons qu'un développeur parte en vacances pendant deux semaines. Vous devrez couper une certaine quantité de travail planifié (fonctionnalité planifiée). Ou supposons qu'un nouveau développeur ait rejoint l'équipe, mais qu'il ne soit pas encore tout à fait au courant, vous devez donc lui laisser le temps de se familiariser avec le projet par le biais d'unprocessus d'intégration . Cela pourrait être deux semaines, plus ou moins une semaine, selon la complexité du projet. C'est tout pour aujourd'hui! J'espère avoir légèrement amélioré vos connaissances sur l'estimation de l'effort, un aspect non technique nécessaire du développement logiciel. Si vous voulez approfondir ce sujet, et dans les détails de Scrum, je vous recommande fortement de lire le livre "SCRUM" de Jeff Sutherland. Je ne peux rien promettre sur les conséquences, car après l'avoir lu vous aurez une envie agaçante de devenir scrum master =D