♦️ 🦎 🤽🏼 Évaluation des tâches aux points d'histoire 👶 👨‍👨‍👧‍👧 👩‍👧‍👦

Presque tous ceux qui ont découvert le développement de logiciels savent ce qu'est l'évaluation des tâches Story Points (SP), cependant, je dis parfois à des collègues d'autres départements ou à de nouveaux venus dans l'équipe qui n'ont jamais rencontré une telle approche, pourquoi utilisons-nous SP et pourquoi il est pratique pour l'équipe et efficace pour l'entreprise.

Le but de ce texte est de décrire ce qu'est SP, comment les utiliser pour évaluer les problèmes et pourquoi cette technique est devenue si répandue.

Problème

Le calcul du temps requis pour terminer une tâche est à la fois une tâche très simple et très risquée pour les équipes de développement.

Une évaluation incorrecte devient l'une des premières raisons de l'échec des plannings voire de l'échec du projet.
Le problème est que l'entreprise considère les évaluations comme des passifs. Les développeurs considèrent les notations comme des hypothèses.

Pour illustrer, je citerai un exemple de dialogue fictif tiré du livre de Robert Martin, The Ideal Programmer.

Mike (Manager): Quelle est la probabilité que vous puissiez gérer en trois jours?

Peter (développeur): Je peux le gérer.

Mike: Pouvez-vous nommer un numéro?

Peter: Cinquante ou soixante pour cent.

Mike: Il y a donc une forte probabilité que vous ayez besoin de quatre jours?

Peter: Oui. même cinq ou six peuvent être nécessaires, bien que j'en doute.

Mike: Dans quelle mesure en doutez-vous?

Peter: Oh, je ne sais pas ... Je suis sûr à 95% que le travail se fera en moins de six jours.

Mike: Alors peut-être sept?

Peter:Eh bien, si tout va mal ... Merde, si TOUT va mal, peut-être dix ou même onze jours. Mais la probabilité d'une telle coïncidence est très faible, non?

Je pense que le dialogue ci-dessus semble assez familier à tout développeur ou chef de projet.

Malheureusement, les problèmes de notes ne s'arrêtent pas là. D'autres écueils devraient également être envisagés:

Corrélation du grade et du grade

La note donnée n'est valable que si l'auteur de la note mettra en œuvre la tâche. Après tout, il est évident que le temps consacré à la tâche par le développeur senior et le stagiaire sera différent.

Une évaluation idéale dans un monde imparfait

Des réunions urgentes, des lettres de travail, des messageries instantanées et un gestionnaire de tâches déchu compliquent encore le processus de développement déjà complexe, ce qui rend les heures idéales que nous imaginons tout en évaluant mal utiles pour un chef de projet essayant d'assembler un diagramme de Gantt vieillissant rapidement.

Ensuite, nous examinerons l'approche de l'évaluation des tâches dans SP et comment elle répond à toutes les difficultés décrites ci-dessus.

Solutions alternatives

Naturellement, l'approche utilisant SP n'est pas la première tentative pour résoudre les problèmes exprimés, bien qu'elle soit probablement la plus populaire.

Dans ce bloc, je vais parler d'un autre programme qui comprend un schéma d'évaluation des tâches. Le programme s'appelle PERT et sa familiarité n'est pas nécessaire pour atteindre l'objectif des textes, vous pouvez donc passer en toute sécurité au bloc suivant.

Technique d'évaluation et d'examen des programmes

PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ = \frac{O + 4 N + P}{6}

$\mu= \cfrac {O+4N+P} {6}$

, :

σ = \frac{P - O}{6}

$\sigma=\cfrac{P−O}{6}$

, :

\frac{1 + 12 + 12}{6} \pm \frac{12 - 1}{6}

$\cfrac{1+12+12}{6} ± \cfrac{12-1}{6}$

, . , , .

Points d'histoire

Que sont les Story Points et comment aident-ils à évaluer les tâches? Mike Cohn, évangéliste agile et PDG de Mountain Goat Software, parle de cette technique très brièvement et clairement.

Et si, au lieu d'évaluer le temps nécessaire pour terminer une tâche, nous évaluerions l'effort requis pour résoudre ce problème? Pour ce faire, nous prendrons l'échelle de notation et y mettrons des tâches qui nécessitent une évaluation.

En même temps, tous les facteurs qui peuvent l'affecter devraient être inclus dans l'évaluation des efforts:

La quantité de travail requise;
La complexité technique de la tâche;
Risques possibles et incertitude dans les exigences;

Cela ne semble pas facile, mais rappelons-nous que nous n'avons pas besoin de donner une note claire à chaque tâche, il nous suffit de trouver sa place sur l'échelle de notation entre les autres tâches à évaluer.

Je veux souligner deux aspects importants de la méthode Story Points qui lui permettent de résoudre les problèmes dont nous avons discuté à la page précédente:

Évaluation relative

Les tâches sont évaluées les unes par rapport aux autres, d'où une échelle de notation universelle qui ne dépend pas de l'expérience de l'évaluateur. Même si la tâche est remplacée par la tâche responsable - son évaluation restera inchangée, évaluez des tâches relativement nouvelles par rapport à cette échelle.

Remplacement des montres par des points abstraits

Nous supprimons donc de l'évaluateur la nécessité d'évaluer la tâche en heures. Au lieu de cela, il l'évalue en points, nous supprimons donc les contradictions dans la perception de l'évaluation par le développeur et le gestionnaire. De plus, les distractions et les circonstances de force majeure n'affecteront en aucun cas l'évaluation, car elles ne modifient pas les efforts requis pour résoudre le problème!

Numéros de Fibonacci, T-shirts et chiens

Oui, oui T-shirts et chiens. Vous pouvez utiliser n'importe quelle échelle pour évaluer les tâches. Les plus courants sont les nombres de Fibonacci, ce sont des valeurs numériques claires et aussi avec un joli bonus: les éléments de cette séquence reflètent bien la croissance de l'incertitude qui survient avec la complexité du problème estimé.

Cependant, certaines équipes utilisent une autre échelle de notation. La plus courante est une évaluation chez les T-shirts et les chiens, lorsque la complexité de la tâche est indiquée dans la taille du T-shirt (S, M, L, XL) ou dans la race du chien (Chihuahua, Pug, Dog). Ainsi, les équipes sont encore plus abstraites de la représentation numérique de l'évaluation, ce qui sape même dans certains cas le passage à une évaluation temporaire.

Score d'équipe

Quelle est la différence entre l'évaluation en équipe et l'évaluation individuelle?
Pourquoi est-il important d'impliquer toute l'équipe dans le classement?

L'une des plus grandes erreurs qui peuvent être commises lors de l'évaluation des tâches est de le faire vous-même et de ne pas demander l'avis des membres de l'équipe. Peut-être qu'ils ont une opinion là-dessus? Vous souhaitez ajouter une nouvelle prise en charge du navigateur? Qu'en pense QA?

Les gens sont la ressource d'évaluation la plus importante. Ils peuvent voir ce que vous ne voyez pas.

Mais comment conduire une évaluation d'équipe? Crier des notes n'est pas très efficace, d'ailleurs, après avoir entendu votre note, un autre membre de l'équipe peut changer d'avis et ne pas exprimer la sienne.

Planification du poker

En 2002, James Granning a décrit une méthode qui est devenue plus tard si populaire que maintenant vous pouvez même acheter de vrais jeux de cartes pour la planification du poker. Ou utilisez l'un des services en ligne pour la session;

L'essence de la méthode est la suivante: tous les participants de l'équipe reçoivent des cartes avec des numéros de l'échelle de notation. Ensuite, une tâche est sélectionnée et ses exigences sont discutées. Après discussion, le modérateur demande à tous les membres de l'équipe de choisir une carte et de la mettre à l'envers. Ensuite, le modérateur donne un signal pour montrer les cartes.

Si les notes des participants sont cohérentes, la note est fixe, sinon les cartes sont retournées à la main et les membres de l'équipe continuent de discuter du problème. C’est une bonne idée de demander à ceux qui ont des notes différentes: "Quelles difficultés voyez-vous dans cette tâche?" ou "Pourquoi pensez-vous que lors de la mise en œuvre, il n'y aura pas de problèmes?".

Il convient de noter que le consentement ne doit pas être absolu. Vous pouvez accepter qu'un ensemble de notes voisines soit également considéré comme un consentement.

Alternatives

Comme la méthode d'évaluation elle-même, la planification du poker a des alternatives. Je vais parler brièvement de l'un d'eux.

Vous pouvez ignorer ce bloc et passer directement à la page suivante.

Évaluation affine

« . , . , . — . , , , .

, . , . .

, , .

, „“ .

Planification du projet

Combien d'heures y a-t-il à Story Point'e et comment puis-je créer un diagramme de Gantt?

Nous avons donc apprécié notre arriéré de tâches, mais vous ne pouvez pas construire un plan de projet sur Story Point'ah. Souvent, le chef de projet a une question: «Comment traduire SP en heures?».

La réponse courte à cette question est: "Pas question."

Bien sûr, vous pouvez suivre les développeurs avec un chronomètre et enregistrer le temps qu'il leur a fallu pour résoudre le problème, puis afficher ces informations dans un graphique. Ensuite, vous obtenez la «cloche» classique, comme dans l'exemple dans le bloc ci-dessous. Comme nous le voyons dans la première figure, certaines tâches prennent un peu plus de temps, d'autres un peu moins, mais en général, la valeur entière correspondra à une distribution normale.

Il en va de même pour les tâches dans 2 SP et cela est illustré dans la deuxième figure. Avez-vous remarqué que les «queues» des graphiques se croisent? Oui, certaines tâches évaluées à 1 SP peuvent nécessiter plus d'efforts que les tâches les plus simples évaluées à 2 SP. Au final, aucune équipe n'a encore appris à évaluer parfaitement. De plus, en traduisant le SP en heures, nous revenons à l'ancien râteau, le temps dont le développeur aura besoin pour résoudre un problème spécifique dépend fortement du développeur.

Mais que faire, nous ne pouvons pas abandonner complètement la planification. Heureusement, pour cela, nous n'avons pas besoin de traduire chaque point d'histoire en heures. Ce qui compte vraiment, c'est la quantité de SP que l'équipe de développement peut «fermer» pour le sprint (itération, version).

En collectant des données sur la vitesse de l'équipe, vous pouvez obtenir des données suffisamment précises pour une planification de projet à long terme. De plus, n'oubliez pas la loi des grands nombres, les erreurs d'estimation se compensent mutuellement, ceci s'applique aussi bien aux tâches qu'aux itérations. Il convient de noter que cela est un peu optimiste, car les inexactitudes sont généralement associées à une sous-estimation plutôt qu'à une réévaluation. Mais rien n'est parfait.

La vitesse (ou la vitesse) est un puissant outil de planification et la principale mesure de l'équipe de développement. L'équipe doit travailler sur l'amélioration continue afin d'augmenter sa vitesse. N'oubliez pas que la vitesse est un dérivé de SP et donc également relative. Vous ne pouvez pas comparer deux équipes entre elles, l'équipe est en concurrence avec elle-même.

Entraine toi

Quelles nuances devez-vous connaître?
Quelles erreurs peuvent être évitées?

En conclusion, je veux rassembler quelques conseils pour ceux qui ont décidé pour la première fois d'essayer les techniques décrites dans leur travail.

Par où commencer

C'est votre première planification de poker et l'équipe ne comprend pas quoi évaluer de nouvelles tâches. Recueillez quelques tâches déjà terminées, idéalement bien connues ou typiques, et évaluez leur complexité les unes par rapport aux autres. Utilisez ces tâches pour en évaluer de nouvelles.

Vous avez un nouveau projet et aucune tâche terminée? Essayez d'utiliser la note affine décrite ci-dessus et attribuez des tâches à l'échelle de notation.

Ne pas évaluer les notes

Parfois, lorsque deux membres de l'équipe ont évalué la tâche différemment, il est tentant d'attribuer le score moyen à la tâche et de passer à autre chose. Ne cédez pas à cette tentation, la discussion est un élément d'évaluation important, au cours duquel l'équipe peut révéler des caractéristiques jusque-là inconnues dans la mise en œuvre de la tâche.

Mais, comme mentionné ci-dessus, vous pouvez toujours convenir que des estimations proches les unes des autres ne seront pas un motif de discussion supplémentaire.

Ne modifiez pas les notes.

Même si au cours de la mise en œuvre, vous avez réalisé que vous aviez fait une erreur lors de la planification, laissez la note inchangée. Vous vous tromperez à l'avenir, et dans les deux sens. Laissez ces erreurs se compenser, n'interférez pas avec le processus.

Note de bug

J'ai rencontré différentes approches pour évaluer les bogues. Certaines équipes évaluent tous les bogues, à l'exception de ceux qui sont survenus lors de la mise en œuvre de nouvelles tâches dans l'itération. Certains n'évaluent pas les bogues, ce qui se justifie par le fait que la vitesse de l'équipe devrait montrer une nouvelle valeur ajoutée au produit, et la correction des bogues ne devrait pas affecter la croissance de cet indicateur.

Quelle que soit l'approche que vous choisissez, restez cohérent. Les informations sur la vitesse historique de l'équipe ne devraient pas être affectées par l'utilisation de différentes approches de l'évaluation.

Notes nulles

Une autre question qui n'a pas de réponse claire. Quelqu'un pense qu'il n'y a pas de tâches qui ne nécessitent pas d'effort. D'autres leur répondent que l'attribution de points à des tâches simples entraîne une augmentation déraisonnable du graphique de vitesse de l'équipe.

Vous pouvez saisir un score de 1/2 point pour ces tâches et contrôler rétrospectivement si la proportion de ces tâches dépasse les limites raisonnables. Mais le principal conseil est le même, restez cohérent dans vos décisions.

Réévaluation des tâches inachevées entre les itérations

Il n'est pas toujours possible de terminer une tâche en une seule itération, même si elle était initialement planifiée. Néanmoins, vous ne devez pas modifier son évaluation lors de la planification de la prochaine itération en fonction de la quantité de travail restante. Gardez cela à l'esprit lors de la planification, mais laissez l'estimation inchangée pour l'histoire.

Notes rétrospectives

Si vous ne menez pas encore de rétrospectives - il est temps de commencer! Il s'agit d'un excellent outil d'équipe pour augmenter la vitesse et la cohérence de l'équipe. Cependant, c'est une question distincte.

Au cours de vos rétrospectives, passez en revue les estimations faites lors de la planification des itérations et discutez s'il y a eu des écarts importants entre les attentes et la réalité.

Vous pouvez également obtenir plusieurs problèmes de l'historique avec les mêmes notes et déterminer si toutes ces histoires ont vraiment nécessité le même effort.

Tout dossier.

Si votre système de gestion des tâches ne supporte pas les notes et ne pas automatiquement calculer la vitesse de l' équipe, alors vous devrez le faire manuellement. Comme vous l'avez probablement déjà deviné, les données historiques sont un outil important pour améliorer vos notes.

Évaluation des tâches aux points d'histoire