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é
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:
L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.
C’est pour les équipes qui utilisent les estimations probablement la dernière étape pour passer le ticket en ready (DoR)
Pourquoi estimons-nous?
Réduire au maximum les risques
La session d’estimation sert à mettre au jour et diminuer les zones d’ombre et risques du projet. Une fois ces dernières connues, on peut choisir comment les traiter:
Un Spike. Il est utilisé quand on ne connait pas encore la solution technique qui peut être apportée à un problème (idéalement, on fera un ou plusieurs POC).
Inclure cette inconnue dans l’estimation.
Servir de support à la prise de décision et à la priorisation
Avant de développer une fonctionnalité, il est intéressant d’avoir une idée de son coût. Une entreprise qui investit doit pouvoir estimer son ROI (retour sur investissement), cette information servira également dans la priorisation du backlog, c’est la raison pour laquelle il est possible qu’une story estimée ne soit jamais développée. Quand une application doit être mise en production, en fonction du nombre de sprint disponible et du « coût » de développement, on priorisera différemment certaines features. Faut-il engager plus de développeurs, testeurs, analystes et techniques pour augmenter la valeur livrée?
Établir la confiance
Pour que la confiance règne entre les parties prenantes d’un projet (clients, décisionnaires, PO), il faut que l’équipe soit fiable sur sa capacité à livrer ce qui est promis. Les estimations nous guident dans ce que nous devrions être capables de livrer dans un futur plus ou moins proche. Grâce à cette donnée objective, nous pourrons plus facilement négocier le périmètre des releases
Aligner lʼéquipe et partager lʼinformation
Les estimations permettent de sʼassurer dʼune compréhension commune du périmètre, de la valeur à produire et de se mettre dʼaccord sur la « taille » dʼune fonctionnalité.
Pour découper les User Stories (US)
Quand nous lisons, comprenons et estimons un ticket, nous pouvons parfois nous apercevoir que cette dernière est trop importante. Dans ce cas, nous le divisons en ticket plus petit. Nous augmentons la granularité du backlog et renforçons la prédictibilité du travail.
Pour organiser le sprint backlog produit du point de vue de la valeur, de l’effort.
Si nous connaissons lʼeffort nécessaire à la réalisation dʼun ticket, nous pouvons déterminer si ce dernier est réalisable dans le sprint.
Planification
Cʼest également un bon moyen pour estimer le nombre de sprint nécessaire à la réalisation des tickets souhaités dans une release via un forecast. On peut également communiquer plus facilement les causes d’un changement de plan, par exemple, si l’on découvre que l’intégration d’un système à notre application est plus complexe que prévu, on peut aisément démontrer l’effet sur ce que nous avions prévu.
/!\ Le forecast n’est absolument pas un outil permettant de prévoir avec certitude quand une application serra développée.
PiPo
Que représente une estimation?
Nous allons ici explorer plusieurs hypothèses sur le que/quoi et le comment estimer, selon quelle métrique.
Des jours hommes / du temps?
L’humain est incapable d’estimer correctement son temps
Une date ne prend pas en compte les facteurs externes tels que les emails, les meeting, les conversations informelles, lʼaide apportée par un développeur à un autre … (Habituellement, nous considérons quʼun développeur développe environ 6h/ jour)
Le temps / les dates ont une valeur émotionnelle qui finira par oppresser les développeurs et le poussera soit à diminuer la qualité de son travail pour gagner du temps, soit à augmenter le temps prévu.
Le temps nécessaire pour un développeur ne sera pas le même que pour un autre.
Pour illustrer mon propos
Prenons le cas d’une course à pied selon le point de vue d’un analyste ayant fait un Iron Man et d’un Scrum Master de 110 kg.
Si on demande une estimation en temps pour les 20km de Bruxelles, le premier répondra 2h30, le second 6h (sans certitude de terminer). Ajoutons à cela que c’est une tierce personne qui va courir le jour J, il est totalement impossible de prédire le temps qui sera nécessaire. (Même un calcul savant donnerait une réponse erronée). En revanche, si on demande d’estimer l’effort, la réponse sera pour les deux 20km. Et si demain on parle d’un marathon, on sait que l’effort est peu ou prou le double.
Pour les tickets, c’est la même chose, si on estime en jours/homme, on doit savoir qui fera la tâche.
De la complexité?
Au plus c’est complexe à réaliser, au plus la valeur de l’estimation serait élevée, et inversement. C’est en effet un point de départ intéressant, mais qui a ses limites.
Pour illustrer mon propos
Considérons une équipe de deux personnes composée d’un enfant et d’un chirurgien du pied. Considérons 2 tickets (Nous supposons que les activités prennent le même temps.), construire 1000 personnages Lego et réaliser une reconstitution du pied (le pauvre a marché sur une brique).
Si nous parlons complexité, l’opération du pied aura une estimation bien plus élevée que le montage des personnages. Si le but était de planifier et de savoir quand l’équipe aurait terminé, puisque le temps de réalisation est plus ou moins identique, l’estimation aurait dû être la même. En fait, on peut dire que si la complexité des tâches varie, l’effort à fournir est comparable.
Un risque
Dans cette hypothèse, nous considérons qu’au plus le travail est risqué, au plus l’estimation devrait être élevée, et inversement. C’est assez risqué de prendre uniquement cette donnée pour une estimation.
Pour illustrer mon propos
Considérons l’estimation de la durée du voyage maison boulot en transport en commun et en trottinette. Le transport en commun est plus rapide, mais « risqué » (Présence de bouchon, des gens dans les voies (oui, la SNCB dit bien dans les voies). La trottinette, même électrique, c’est plus « sûr », mais c’est lent (oui bon, on ne va pas prendre en considération le nombre de personnes aux urgences après une chute). Une estimation en risque serait plus élevée pour le transport en commun, cependant, il est tout à fait possible que vous arriviez plus vite en bus qu’en trottinette au boulot demain. (Si demain est un weekend, ne vient pas au bureau).
Mais alors quoi?
Et bien, nous devrions surtout parler d’une notion d’effort qui reprendrait toutes les hypothèses précitées. La quantité de travail à fournir, sa complexité, ses risques et inconnues, le temps.
Quelle mesure pouvons-nous utiliser pour représenter l’effort?
T-shirt sizing
À mon sens, à utiliser pour du haut niveau, par exemple pour se donner une idée avant analyse
Valeurs disponibles: XS, S, M, L, XL …
Les animaux
De nouveau, nous sommes sur quelque chose destiné à du haut niveau. Avant l’analyse, Épic …
Valeurs possibles: Puce, tigre, éléphant …
Les StoryPoints
À utiliser pour des tickets pour lesquelles nous avons beaucoup d’informations, voir, plus d’inconnue.
Valeurs disponibles: 1, 2, 3, 5, 8, 13 …
D’autres articles suivront sur ces différentes mesures.
Quand on estime un ticket, ce n’est pas je qui estime, mais nous. Toutes les estimations sont le résultat d’un travail d’équipe.
PiPo
Pourquoi parler de relativité (E=mc²)?
Reprenons notre exemple de course, si notre première estimation était faite pour une course de 20 km, nous pouvons aisément estimer que l’effort nécessaire à 10km sera de 1/2 tandis que l’effort pour 40km sera le double. De la même manière, les autres mesures permettent à l’équipe un accord sur la taille relative des tickets. Par exemple, la story 2 représente 1/2 des efforts de la 1. La story 3 représente 2 fois la somme d’effort de la première.
Estimer de manière relative prend en compte l’imprécision de nos estimations. En effet, les humains ne sont absolument pas doués pour ce genre de chose, par contre, ils sont tout à fait capables de comparer 2 choses entre elles.
Revenons à nos Lego, en voyant un tas, vous ne seriez pas en mesure de donner le nombre de briques qui le compose, par contre, vous pouvez comparer 2 tas et dire qu’il y en a plus dans celui-ci. Vous pourriez également dire qu’ils sont à peu près identiques …
On peut faire le même exercice avec des verres d’eau (ou de Vodka).
Le premier verre est la référence
Nous pouvons estimer que le second est plus rempli
Le troisième est aussi rempli que le 1er (à moitié vide, ou moitié plein …)
It’s difficult to make prediction, especially about the future
Variation du résultat par rapport au travail à fournir
Nous devons garder à lʼesprit que même si lʼéquipe est normalement capable de développer entièrement le produit, nous travaillons avec des spécialistes. Donc, si durant une période donnée, il y a moins de travail dans un domaine, la quantité de travail fournie par l’équipe va mécaniquement diminuer.
Précisions
Il est impossible d’obtenir un chiffre précis quoi que nous fassions. Par contre, au fil du temps, pour une équipe stable, la corrélation estimation de l’effort et nombre de tickets done dans un sprint sera de plus en plus exacte, et donc, la prédiction moyen terme également.
Last but not least, les estimations, ce n’est pas SCRUM, c’est XP.
