Comment augmenter la vélocité

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:

Le sprint est fini, et il reste des tickets

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