» Les réponses

Comment augmenter la vélocité

Posted on 18 janvier 202324 mars 2023 by pierre

Que répondre à une demande d’augmentation de la vélocité?

Comprendre

S’assurer que le demandeur sait de quoi il parle

Est-ce que le demandeur sait de quoi il parle? Sait-il que la vélocité est une mesure qui est utile uniquement à l’équipe, qu’elle ne peut être comparée entre les équipes …

Il y a sur ce site plusieurs articles qui peuvent t’aider à faire comprendre ce qu’est la vélocité

Qu’est-ce qui motive cette demande

Une personne de l’entreprise a comparé les différentes vélocités?
Il y a une nécessité d’accélération du développement pour réagir et s’adapter au marcher?
…

L’objectif est de trouver une réponse adaptée à la demande, par exemple, s’il faut réagir à un marché changeant, la réponse n’est pas une meilleure vélocité, mais un changement de priorité, un pivot.

Si le client désire une augmentation du résultat, alors, oui, c’est peut être une solution.

Que peux faire l’équipe pour y arriver

Favoriser la communication et la collaboration

Une collaboration et un contact direct entre les gens favorisent généralement la prise de décision et la résolution des problèmes. En effet, quand on se comprend, on passe plus vite à la solution efficace.

Travailler à la réduction des problèmes

Oui, c’est évident, au plus vite les problèmes sont résolus, au moins ils auront d’impact et au plus on a de temps pour autre chose.
Des soucis non résolus qui s’accumulent génèrent généralement du travail supplémentaire.

De plus, un esprit léger nous permet de nous concentrer sur le principal, à savoir, la réalisation du produit.

Augmenter la qualité du code

Même si mettre en place un système de production et de revue de code efficace semblera être une perte de temps, il évitera les aller-retour entre le test, le développement, l’acceptation du métier …

Avec un code qualitatif, nous avons moins de bugs, et donc, moins de rework, moins de régression.
C’est exactement cela qui donnera de la confiance au client et permettra un meilleur focus de l’équipe sur les choses qu’ils doivent résoudre.
Explorer des pratiques comme le pair-review, le Test Driven Développement est donc à envisager.

Tester le code

Comment, ce n’est pas encore fait …

Parmi les raisons pour lesquelles il est important de faire des tests unitaires de son code, on a d’abord;

Les tests unitaires peuvent aider à détecter les bugs dans le code plus rapidement et plus efficacement (d’où une augmentation de la qualité).
En outre, les tests unitaires aident à garantir que le code continue de fonctionner correctement lorsque des modifications sont apportées.
Les TU sont rejoués à chaque itération de code
Enfin, les tests unitaires servent également à documenter le comportement attendu du code, ce qui peut faciliter la maintenance et la compréhension du code à long terme.

L’automatisation

Quoi de plus ennuyeux que de devoir lancer les 10 mêmes commandes de compilations encore et encore pour ensuite passer aux tests puis générer un rapport alors qu’il est possible en appuyant sur un bouton de lancer un script qui va aller chercher la dernière version du code, ou une branche, la compiler, remplacer les différents couples utilisateur mot de pass nécessaire à l’environnement à la volée
Il est beaucoup plus intéressant de libérer du temps pour des tâches plus créatives.

Et bon, soyons claires, si en plus vous pouvez juste pousser un bouton pour passer en production … 🙂

Automatiser les tâches répétitives : en automatisant les tâches répétitives, l’équipe peut se concentrer sur des tâches plus importantes qui nécessitent une attention humaine.

L’apprentissage en continu

En augmentant son niveau de compétence, via de l’apprentissage, l’équipe sera en mesure de réagir plus vite et probablement mieux face aux obstacles qui se dressent. Ils s’adapteront plus aisément.
Ils seront en mesure d’appréhender les nouvelles technologies …

Augmenter le nombre de membres

C’est probablement la chose la plus simple à comprendre et donc, celle à laquelle nous penserons en premier.

Ce n’est pas faux, mais il faut nuancer le propos … Si ajouter un membre qualifié et divise les tickets en plus petits items indépendants pour permettre de répartir les « tâches », alors oui, on devrait augmenter la vélocité à moyen long terme. Il faut également que le nouveau membre soit bien intégré à l’équipe.

Attention, en augmentant la taille d’une équipe, il peut y avoir la naissance de coups supplémentaires suite à des besoins de coordinations. La communication est également plus complexe au fur et à mesure que l’équipe grandit.

La lecture de ces articles te sera certainement utile:

Qu’est-ce que la vélocité

Posted on 18 janvier 202320 janvier 2023 by pierre

La vélocité, c’est « l’effort » moyen qu’est capable de réaliser une équipe sur une période donnée.
(Une quantité de sprint par exemple).
Cet effort peut être exprimé au moyen de story points

Exemple de calcul

Voici quelques données nécessaires à la compréhension d’un calcule de vélocité.
Comme tu le constates, il y a une grande différence entre les sprints 8 & 9 et les autres.
De temps à autre, il arrive que l’équipe ne finisse pas tout ce qu’il y avait dans le sprint, je t’invite à lire l’article Le sprint est fini, et il reste des tickets
Les points brûlés correspondent à l’addition des SP des items réalisés. Répondant à la Definition of Done (DoD)

Sprint	Points brulé dans le sprint
Sprint 7	25
Sprint 8	11
Sprint 9	37
Sprint 10	24
Sprint 11	26

Donnée nécessaire à un calcul de vélocité

Nombre total de points pour les 5 sprints: 123
Nombre moyen par sprint / vélocité: 24,6

Est-ce toujours fiable?

Pas nécessairement, c’est une excellente indication, mais certains facteurs vont influencer les chiffres.

Les jours de maladie / congé

Si un développeur ne travaille pas et donc ne développe pas, il y a moins de choses qui sont réalisées au courant du sprint => moins de SP brûlé.

Si nous fonctionnons en flux tendu (c’est-à-dire que le temps entre la rédaction des tickets et leur apparition dans un sprint est relativement court), on pourrait également se retrouver avec moins de choses à faire, ou des choses non encore bien décrit et répondant à la DoR. Dans ce cas, le travail de développement sera également impacté.

Oui, mais bon, tous les développeurs sont au moins une fois malades sur l’année, donc, on peut lisser cette donnée.
Ce n’est pas faux, mais ce n’est pas tout à fait vrais non plus, on reviendra sur cela plus loin dans l’article.

Au plus l’équipe est petite, au plus ce facteur aura d’influence (100% pour une équipe de 1 dev).

Les changements dans l’équipe

Alors ici, c’est très simple, si l’équipe n’est pas stable depuis un certain temps, cette information n’a absolument aucun sens, aucune fiabilité, aucune valeur.

En cas de nouveau venu, du temps à consacrer à son intégration, à la place du développement des tickets.
En théorie, on reviendra à la situation initiale et à une augmentation après un certain temps. Si ce n’est pas le cas, il y a des questions à se poser.
Un membre de l’équipe part, il y a donc moins de « force de travail » disponible

À tous les coups, un changement dans l’équipe modifie la vélocité.

La spécialisation des membres de l’équipe

Une équipe doit être en mesure de réaliser l’entièreté du produit, cependant, ses membres ont certaines spécialités. Il est tout à fait envisageable dans un projet de développement d’une application ou d’un site qu’un sprint contienne plus de demande front-end que back, dans ce cas, un spécialiste back-end peut se retrouver sans ticket dans sa spécialité. Bien entendu, il ne va pas rester à rien, mais il est certainement moins compétent dans les autres domaines.
PS c’est probablement un bon moment pour régler un peu de dette technique (qui ne devrait pas exister) ou aider à l’analyse, ou optimiser du code …

Que peut-on faire avec cette information?

Prévoir le nombre d’item à mettre dans un sprint

Cette mesure nous permet par addition des SP de savoir quelle quantité de tickets nous pouvons mettre dans le sprint.

Planifier

On peut faire un forcast, c’est-à-dire qu’on peut tenter de prédire, d’estimer et donc de planifier quand une fonctionnalité aura été développée.

Considérons qu’en additionnant les story points des tickets nécessaires à la réalisation d’une fonctionnalité, on arrive à 94. Nous savons que notre moyenne / vélocité est de 24,6

94 / 24,6 = 3,82.

Il nous faut donc 3,82 => 4 sprints pour réaliser la fonctionnalité.

Quelle période de temps devons-nous considérer?

On serait aisément tenté de dire qu’au plus la période de référence est longue, au plus la mesure est fiable. Après tout, on a plus de données …

Et bien non, la vélocité va varier avec le temps. Nous avons déjà soulevé le cas de l’augmentation ou diminution du nombre de membres dans l’équipe, nous allons donc considérer que l’équipe reste stable.

Il y a d’autres phénomènes qui feront varier cette information, par exemple, la montée en compétence technique des membres, la manière d’écrire les tickets va évoluer avec le temps, idéalement devenir meilleure, les membres de l’équipe vont mieux se comprendre et l’estimation deviendra plus précise.

On considère l’information comme correcte après 3 à 5 sprints. Sachant que cette valeur évolue légèrement au fil du temps, utiliser un forcast à long terme n’est pas idéale. Au plus le calcule se fait dans le futur, au moins l’information a de valeur.

Donc, on ne peut pas facilement considérer la possible absence d’un membre durant 4 semaines sur l’année ou même un prorata

Il est tentant de comparer les vélocités propres des équipes, ou de faire un prorata par développeur.
Hé bien, cela ne fonctionne pas, car les estimations pour l’équipe A ne sont pas les estimations l’équipe B.

La lecture de ces articles te sera certainement utile:

On va estimer, à quoi devons-nous faire attention?

Posted on 21 décembre 202227 décembre 2022 by pierre

C’est probablement une excellente démarche que d’entreprendre des estimations, cependant, il y a quelques pièges à éviter.
Voici une courte liste de points d’attention

Savoir ce qu’est une estimation

Je te conseille la lecture de cet excellent article sur ce que sont les estimations .
(Il est excellent car c’est moi qui l’ai rédigé ;))

Avoir un ticket de référence

La dérive des ~~continents~~ estimations.
Sans baseline, ou référence comparative, les estimations vont se décaler, de ce fait, la vélocité, le burndown chart et autres indicateurs ne seront plus fiables.

Ne pas convertir les estimations en jour-homme

Les jour-homme créent une complexité inutile et annulent complètement l’intérêt d’estimations relatives qui permettent à tout le monde travaillant à des vitesses différentes de se comprendre et de se mettre d’accord.

Ne pas estimer uniquement en fonction de la complexité

Si on estime uniquement la complexité, une story « simple » mais demandant beaucoup d’effort. (Par exemple une tâche à répéter un certain nombre de fois, des tests longs …). Cela va créer de fausses prédictions et un manque de visibilité sur la quantité / charge de travail à réaliser dans le backlog.

Voici un tableau comparatif « à la suédoise » de la notion de complexité par rapport à la notion d’effort.

Ticket	Remarque	Comp.	Effort
En tant que constructeur, je souhaite monter un tabouret MARIUS afin de poser mes fesses	3 visses à serrer	1	1
En tant que constructeur, je souhaite monter un tabouret SKOGSTA afin de poser mes fesses	Un rien plus complexe que le MARIUS	2	2
En tant que constructeur, je souhaite monter un lit NORDLI afin de pouvoir dormir	C’est bien plus compliqué qu’un tabouret et les tiroirs sont super dur à mettre en place	5	5
En tant que constructeur, je souhaite monter 10 tabourets SKOGSTA afin de poser mes fesses et celles de mes invités	Aussi complexe simple qu’un SKOGSTA . (Nous aurions également pu considérer l’expérience)	2	20

Exemple de la complexité VS l’effort pour la réalisation d’un ticket

Ne pas considérer une estimation comme quelque chose de précis, gravé dans le marbre

Jamais l’équipe et/ou les parties prenantes ne peuvent considérer une estimation comme un contrat.
L’estimation est surtout valable au moment où elle a été faite, la solution évoluant au jour le jour, il est envisageable qu’un item soit impacté par la réalisation d’un autre qui n’existait pas au moment de l’estimation. (Si il existait déjà, il faut absolument lier les 2 tickets et marquer le dépendance).
Il n’y a pas que l’application qui évolue, les développeurs aussi, dans la plus part des cas, il considérera le ticket comme plus « simple » et tout le monde y gagnera.

Ne pas considérer les estimations comme une mesure de productivité des équipes, ou pire, des développeurs.

Dans ce cas, nous verrons très vite apparaitre des dérives telles que surestimation systématique, sous engagement dans le sprint pour être sûr de le terminer.

Certains développeurs feront des heures supplémentaires et seront donc moins alertes et moins qualitatifs. D’autres simplement bâcleront le travail pour tenir le délai, ce qui générera inévitablement de la dette technique

Les estimations ne sont en aucun cas à utiliser pour contrôler l’équipe et/ou un développeur en particulier
PiPo

Ne pas comparer les estimations de deux équipes

Il est tentant de comparer les performances des équipes en convertissant l’estimation en chiffre et en divisant le total d’un sprint par le nombre de jours de ce dernier (et de faire un prorata par développeur).
Hé bien, ça ne fonctionne pas, car une estimation pour l’équipe A n’est pas une estimation pour l’équipe B.

Faire attention aux changement dans l’équipe

Si une personne sort de lʼéquipe, cette dernière aura moins de force de travail, donc, la vélocité va décroitre.
Si une personne rejoint lʼéquipe, dans un premier temps, la vélocité va également décroitre
(Lʼonboarding va occuper dʼautres membres de lʼéquipe, la nouvelle personne ne sera pas efficiente à 100% au début …)
Sur le long terme, la vélocité devrait croitre et dépasser la vélocité initiale.
Si ce n’est pas le cas, il faut absolument comprendre pourquoi.

Ne pas forcer à estimer

Jamais les développeurs ne doivent se forcer / être forcé à estimer un ticket.
Si un ticket ne peut être compris, il ne doit pas être estimé. Une fois que l’estimation existe, elle est utilisée par les autres membres de l’équipe, or, si elle n’est pas correcte, elle faussera les travaux de ses utilisateurs.

Ne pas estimer avec une seule personne

Durant une session d’estimation, avec plusieurs participants, nous arrivons de temps à autre à des résultats différents, ce qui permet d’ouvrir un débat et amène généralement des questions sur le travail à effectuer. Nous y gagnions en précisions.

En dehors de cela, avoir une équipe avec un seul développeur n’est pas prudent, imagine l’impact si ce dernier quitte le projet …

Le sprint est fini, et il reste des tickets

Posted on 16 décembre 202213 janvier 2023 by pierre

Oups, nous n’avons pas terminé tout ce que nous avons promis …

Pourquoi est-ce qu’il reste un / des tickets dans le sprint

La première étape est de déterminer pourquoi nous n’avons pas terminé le sprint.
Nous devrons également répondre à la question suivante: « Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction ».

Une question de capacité

Dans le cas d’un début de projet, il est probable que nous n’ayons pas encore trouvé notre vitesse de croisière, nous remplissons donc le sprint en tâtonnant jusqu’à savoir ce que nous sommes capables de réaliser au cours de la timebox.

Un changement dans l’équipe entraine une perturbation (dans la force).
Une personne en moins diminue d’office la capacité de réalisation de l’équipe, logique me diras tu, cependant, une nouvelle recrue va également diminuer la vélocité (dans un premier temps)
Quand un nouveau rejoint le projet, il va devoir prendre connaissance du métier, de la problématique que l’équipe résout par son travail, il va également apprendre le fonctionnement de l’équipe, et pour ce faire, les autres membres de l’équipe vont ~~perdre~~ investir du temps pour le former.
Donc, en plus de ne pas bénéficier tout de suite d’une augmentation de vélocité, nous allons également en perdre.

Attention, la perte de vélocité doit être à court voire moyen terme, si cette perte perdure, il faut envisager que la nouvelle recrue a été mal intégrée, qu’elle ne correspond pas au projet ou encore que l’équipe devient trop importante et ne se synchronise plus correctement.
Dans tous les cas, il faut agir.

Une mauvaise estimation

Et oui, une estimation reste une science inexacte, de temps à autre, nous nous trompons. Nous surestimons ou sous-estimons. La plupart du temps, nous arrivons à l’équilibre.

Une erreur de compréhension

Nous sommes humains, nous avons plein de possibilités de ne pas nous comprendre, alors, oui, il arrive que nous comprenions une chose alors que ce n’était pas du tout ça.

À la revue par les pairs, nous nous rendons compte que ce n’est pas du tout ce qui était demandé.

Ah zut, je n’avais pas ben compris, et je n’ai pas anticipé ces changements, c’est plus compliqué, ça prend plus de temps …
Ah, en fait, maintenant que j’ai compris, je vois que nous avons une dépendance vis-à-vis d’une autre équipe, d’un autre fournisseur …
Ah, l’équipe a changé entre le moment ou ce ticket est passé à prêt et le développement (Oui oui, ça arrive)

Que faire avec les tickets que nous n’avons pas terminés durant notre sprint?

Il n’y a pas de réponse simple, c’est au cas par cas.

La logique voudrait que s’il y avait un ticket X dans le sprint venant de se terminer, c’est qu’il faut le réaliser, donc, hop sprint suivant.
Cependant …

La fonctionnalité à développer arrive trop tard, et n’a donc plus de raison d’être.
Le produit a pivoté, la fonctionnalité n’est donc plus aussi prioritaire, voir, plus nécessaire.
D’autres items ayant une priorité plus élevée sont apparus dans le backlog
L’item ne peut pas être réalisé, car il y a des dépendances non résolues

Pour ma part, je considère que si un ticket a été commencé, il est préférable de le terminer.
En effet, si nous laissons les changements tels quels, suite aux autres évolutions, le travail sera probablement entièrement à refaire pour être intégré dans la solution qui aura évolué. (Tout en prenant en compte les points précédemment cités)

Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction

Heu, ben oui, en fait, il sert à quoi le daily, si ce n’est justement faire un topo sur la santé du sprint, inspecter au jour le jour que nous pouvons respecter le sprint goal et réaliser tout le contenu initialement prévu.po
Si nécessaire, nous nous devons de réaménager le contenu du sprint en accord avec les dev et le PO tout en respectant le sprint goal.

Tout ça pour dire que ça ne devrait pas arriver car nous devrions avoir géré le problème en amont.
PiPo