Quelles méthodes les développeurs utilisent-ils pour évaluer les tâches ?

Salut tout le monde! La théorie requise pour démarrer le développement est très vaste. Certains spécialistes (les développeurs backend en Java et autres langages) en ont plus, tandis que d'autres (par exemple les développeurs frontend en JavaScript - React Native) en ont un peu moins. Cependant, tous deux doivent disposer d’un stock important de connaissances non seulement techniques, mais aussi « organisationnelles ». Ces connaissances « organisationnelles » sont l’un des points d’intersection pour les développeurs frontend et backend. Aujourd'hui, je souhaite parler d'un aspect de ces connaissances organisationnelles non techniques : l'évaluation (estimation) des tâches . Et comme j'ai travaillé uniquement dans la méthodologie Agile (qui est en fait considérée comme la plus populaire), dans sa sous-partie Scrum , j'envisagerai l'évaluation des tâches dans le contexte de Scrum . Je dirai tout de suite que l’évaluation, aussi appelée estimation, est difficile. Pour moi personnellement, en tant que développeur, c'est l'un des aspects les plus difficiles/indésirables du travail. De nombreux facteurs différents doivent être pris en compte et peuvent influencer l’évaluation d’une tâche. Dans le même temps, les plans de développement ultérieur seront basés sur vos prévisions.

Et si vous n'obtenez pas la bonne note ?

Si un développeur consacre beaucoup plus d'heures à une tâche qu'il n'en consacrera au final, il peut sembler qu'il n'est pas le meilleur spécialiste, car l'estimation était très inexacte. Pour ainsi dire, un doigt vers le ciel. Dans le même temps, si le développeur n’investit pas dans le temps prévu, il met en péril les projets du client de lancer le produit/la nouvelle fonctionnalité. C'est une entreprise, et les affaires signifient de l'argent, et peu de clients apprécieront une telle crevaison. C’est en fait pour cela que je n’aime pas les estimations, car il est parfois très difficile de déterminer l’heure exacte pour accomplir une tâche.

Comment le temps est-il évalué ?

En règle générale, l'estimation est effectuée en heures ou en story points. Personnellement, je suis beaucoup plus proche du processus d'évaluation en story points . Si une montre est quelque chose de physique, alors quelque chose qui peut prêter à confusion, les story points concernent un peu autre chose, plus abstrait. En règle générale, les équipes de développement de logiciels donnent des estimations au format temporel : heures, jours, semaines, mois. Ces estimations de temps sont basées principalement sur l'expérience personnelle, les conjectures ou l'intuition. Dans ce cas, les développeurs examinent simplement la tâche et expriment une estimation du temps que cela leur prendrait. En conséquence, ils sont très rarement précis, car trop de facteurs peuvent affecter le délai de réalisation des travaux. Par conséquent, de nombreuses équipes travaillant selon la méthodologie Agile utilisent des story points. Voyons cela.

Que sont les Story Points

Un story point est une unité de mesure qui exprime une évaluation de l'effort total nécessaire pour mettre pleinement en œuvre un certain domaine de travail (fonctionnalité). Autrement dit, c'est une complexité tellement relative . Les équipes attribuent des points d'histoire en fonction de la complexité du travail, de l'étendue du travail et du risque ou de l'incertitude. En règle générale, ces valeurs sont attribuées pour diviser plus efficacement le travail en parties plus petites, éliminant ainsi l'incertitude. Au fil du temps, cela aide les équipes à comprendre ce qu’elles peuvent réaliser dans un laps de temps donné et à planifier plus précisément les prochains domaines de travail. Cela peut vous paraître complètement contre-intuitif, mais cette abstraction est en réalité très utile : elle pousse l’équipe à prendre des décisions plus difficiles quant à la complexité du travail. Examinons quelques raisons d'utiliser des story points dans la planification :

• l'inexactitude des estimations dans les intervalles de temps peut être évitée ;
• Contrairement à l'estimation dans le temps, les frais généraux peuvent être mieux pris en compte : communications entre les membres de l'équipe et le client, diverses discussions et planifications de l'équipe, ainsi que situations imprévues ;
• Chaque équipe notera le travail sur une échelle différente, ce qui signifie que leur vitesse (mesurée en points) sera différente ;
• En définissant une échelle d'attribution de chaque point d'histoire, vous pouvez rapidement répartir les points sans trop de controverse.

Comment NE PAS utiliser les story points

Malheureusement, les story points sont souvent utilisés à d’autres fins. Les story points peuvent être erronés lorsqu’ils sont utilisés pour évaluer des personnes, définir des délais et des ressources détaillés, et lorsqu’ils sont considérés à tort comme une mesure de performance. Au lieu de cela, les équipes doivent les utiliser pour comprendre le volume/la complexité du travail dans chaque tâche et établir des priorités. Il est possible que les parties jugées les plus difficiles soient réalisées en premier afin de pouvoir être complétées avant la fin du sprint , mais les plus faciles peuvent être repoussées à plus tard. Je vous rappelle ce qu'est un sprint dans le cadre de la méthodologie Scrum : La durée de ce délai est déterminée au début du développement par accord 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, l'estimation des tâches est effectuée au début du sprint afin de planifier la quantité possible de travail réalisé d'ici la fin du sprint, lorsque le travail terminé est livré au client. Il vous aide à voir vos progrès dans le développement de produits, à recevoir les commentaires du client et à ajuster le développement du projet en fonction de la vision du client. Mais on s’éloigne quand même un peu : revenons à l’estimation. Évaluer les tâches par un seul développeur serait trop subjectif. Il s’agit donc généralement d’un travail d’équipe. Il existe de nombreuses techniques d’évaluation d’équipe. Aujourd'hui, nous examinerons le plus utilisé d'entre eux - Scrum poker . Cette technique nécessite un manager qui sera quelqu'un comme le leader de ce Scrum poker . Il peut s'agir d'une personne spécialisée dans Scrum Master , ou PM .

Qu'est-ce que Scrum Poker

Le Scrum Poker - ou Planning Poker - est une technique d'évaluation basée sur la conclusion d'un accord. Principalement utilisé pour évaluer la complexité du travail à venir ou le volume relatif de tâches à résoudre lors du développement de logiciels. Je note tout de suite que le Scrum poker est une pratique courante dans le développement, et il faut absolument savoir de quel genre de bête il s'agit. Pour ce processus, nous utilisons généralement une sorte d'application ou de site Web qui nous permet d'organiser une évaluation en équipe d'une tâche particulière. Comment cela peut-il arriver? L'équipe prend un élément du backlog (nouvelle tâche, fonctionnalité), discute brièvement des pièges possibles et des autres nuances qui y sont associées. Chaque participant choisit ensuite une carte avec un numéro qui représente son niveau de difficulté. Oh, et lors de l'estimation, ce ne sont pas les séries habituelles qui sont utilisées, mais les nombres de Fibonacci . Les nombres de Fibonacci sont si populaires au Scrum Poker car l'écart entre eux augmente avec le temps (qui rappelle les niveaux de la pyramide). Certaines tâches seront d’une énorme complexité et un petit nombre de points d’histoire ne pourront pas être réalisés. Explication des cartes inhabituelles :

nombre inconnu de points de terminaison

une tâche infiniment longue

besoin d'une pause

Méthodes d'estimation plus rares :

• dans les tailles de T-shirt - S, M, L, XL
• ou chez les chiens - chihuahua, carlin, teckel, bouledogue, etc. (à mon avis, c'est l'unité la plus étrange pour évaluer les tâches =D)

L’équipe compare ensuite les estimations données au même problème par différents développeurs, et s’ils sont d’accord, tant mieux ! Dans le cas contraire, il est nécessaire de discuter des raisons des différences d’appréciation (arguments). Après cela, nous pouvons parvenir ensemble à une estimation unique, avec laquelle tout le monde, plus ou moins, sera d'accord. Eh bien, pourquoi le poker est-il même utilisé pour planifier un projet logiciel sérieux ? Après tout, c'est en quelque sorte étrange. En fait, une telle gamification encourage les membres de l’équipe à penser de manière indépendante, en leur demandant de montrer leurs résultats en même temps que leurs coéquipiers. Cela permet d’éviter de dépendre des opinions des autres membres de l’équipe. Autrement, les développeurs moins expérimentés examineront et s’appuieront sur les évaluations des membres de l’équipe plus expérimentés, ce qui annulera l’utilité de leur propre évaluation. Mais avec l’ouverture simultanée des résultats, cela est pratiquement impossible. Un exemple d'application de planification Scrum Poker vient d'Atlassian .

Exemple d'évaluation de tâches

Imaginons que votre équipe ait identifié une certaine échelle d'évaluation en story points : Scrum Poker commence une tâche et vous l'évaluez comme ceci :

• vous n'avez jamais travaillé avec la mise en œuvre de fonctionnalités similaires auparavant - +3
• fonctionnalité d'une tâche de taille moyenne - +2
• la mise en œuvre de la tâche a une grande complexité - +3
• grande complexité d'écriture de tests pour cette fonctionnalité - +3

En conséquence, vous obtenez 11 points d'histoire, mais comme une telle carte n'existe pas, vous en proposez 13. Un autre de vos collègues évalue la tâche :

• j'ai déjà travaillé avec un problème similaire - +1
• fonctionnalité d'une tâche de taille moyenne - +2
• la mise en œuvre de la tâche a une complexité moyenne - +2
• complexité moyenne d'écriture des tests pour cette fonctionnalité - +2

En conséquence, il obtient 7 points d'histoire, mais cela n'existe pas dans les nombres de Fibonacci, et il place une carte avec le nombre le plus proche possible - 8. En conséquence, les autres membres de l'équipe donnent des estimations basées sur leurs opinions subjectives. Ensuite, vous montrez vos résultats et découvrez que presque tous vos collègues ont donné l'estimation 13, à l'exception d'un développeur qui lui a donné 8. Dans ce cas, on lui donne la parole et il donne ses raisons. Et eux, par exemple, sont comme ceci : il a déjà travaillé avec le même problème, et ce n'est pas aussi difficile que cela puisse paraître, et à la fin il convainc le reste des membres de l'équipe de changer leur solution de 13 à 8 histoires. points, disant qu'il aidera celui qui assumera cette tâche à le comprendre. Ou alors, il le fera lui-même. Et en général, peu importe que les autres écoutent ou non ses arguments, car d'une manière ou d'une autre, une note sera attribuée à cette tâche, et l'équipe passera à la familiarisation avec la suivante. Les premières fois, 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 sont faites précisément sur la base d'estimations. Après un certain temps, environ trois mois, l'équipe commencera à estimer plus précisément les tâches et la quantité moyenne de travail que l'équipe peut effectuer par sprint deviendra visible. Mais il s’agit ici d’une planification générale de l’étendue des travaux, c’est plutôt une question de temps, et dans ce cas, de nombreux facteurs différents peuvent avoir un impact. Par exemple, l'un des développeurs est parti en vacances pendant deux semaines. Autrement dit, vous devez rayer une certaine quantité de travail planifié (fonctionnalité planifiée). Ou un nouveau développeur est arrivé dans l'équipe, mais vous n'avez pas besoin de compter entièrement sur lui, car... il faut prendre en compte le temps nécessaire pour s'adapter au projet, appelé onboarding . Cela peut prendre 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 dans une partie aussi non technique des connaissances que l'estimation des problèmes. Si vous souhaitez approfondir ce sujet, ainsi que les détails de Scrum, je vous conseille fortement de lire le livre « SCRUM » de Jeff Sutherland. Je ne peux pas garantir les conséquences, car peut-être qu'après cela vous aurez une fâcheuse envie de devenir Scrum Master =D