Livraisons trop fréquentes?

Communauté Scrum Life
1

Bonjour,

TL;DR Nous avons un cycle avec des livraisons chez le client toute les semaines. Néanmoins j’ai l’impression que ce cycle est trop court et ne permet pas l’accomplissement de tâches de « R&D »

Avec un cycle de livraison d’une semaine on se retrouve chaque semaine avec quelque bugs (introduits par des fonctionnalités) livrés qui viennent s’accumuler aux bugs existants. Ainsi on se retrouve à traiter principalement des bugs (qui doivent l’être soyons d’accord). Ainsi la semaine est consacré principalement à corriger des bugs et les améliorations produits et/ou sujet de R&D ne sont/seront jamais traités.
80% sur les bugs, 20% sur ajout de valeurs

Le deuxième problème soulevé est le multi-tâches, au lieu de se concentrer 100% sur le sujet de R&D le développeurs doit jongler entre les bugs (dits urgents) et le sujet R&D => perte de temps et d’énergie

Le troisième problème qui émerge est la sensation de se sentir submergé (overwhelmed). Ceci est la conséquence du problème numéro 2.

Auriez-vous des hypothèse pour arriver à mieux orchestrer la gestion des bugs avec la création de nouvelles valeurs (fonctionnalités + R&D) ?

Hypothèse
Au début j’aurai pensé que diminuer la cadence de livraison pourrait aider. Mais au final si nous livrons toutes les deux semaines nous aurons « deux fois plus de bugs » que sur une semaine. Ceci ne nous aide pas. Un avis ?

2

Bonjour,

Voici que je comprends en lisant votre description du problème de R&D.

  1. Beaucoup de bogues

  2. Délai d’une semaine semble trop court.

  3. Multitâches.

  4. Sensation d’être submergé !

Questionnement et réflexion

Réflexion sur le point 1

  • Avez-vous révisé votre définition de « 'terminé » ?

  • Avez-vous regardé des outils de gestion de qualités?

  • Avez-vous pensé faire un sprint plus concentré sur la qualité, pas juste la résolution de bogue? mais, La Qualité. et oui, en livrant de aussi une des améliorations

  • Avez-vous réfléchi la qualité comme faisant partie l’ensemble du processus de développement, pas juste dans le code ou les tests logiciels ?

Réflexion sur le point 3 et 4

  • Avez-vous pensé à limiter le nombre de taches en parallèle ? Je ne parle pas de passer ou d’ajouter Kanban. Mais, d’utiliser la notion de WIP à différent niveau dans le tableau.

  • La aussi, avez-vous révisé votre notion de terminée dans un aspect multitâche ?

  • Avez-vous regardé le flo de travail ou son organisation ?

  • Pourquoi, vous avez besoin de vous concentrer 100% sur la R&D.

Réflexion sur le point 2

  • Et, maintenant, est-ce que vous pensez que le sprint est problématique ?

J’espère vous avoir emmené vers d’autres pistes de réflexions. Je sais, je ne vous ai pas données de solutions. Mais, je crois que les meilleures solutions doivent d’abord venir de votre équipe Scrum.

Bon courage.

Bruno Larouche

1 « J'aime »
3

La question qui me vient instantanément, c’est : « en quoi avoir un cycle 2 fois plus long de livraison diminuera les bugs que vous avez ? »
Parce que là, en lisant ce post, j’ai surtout l’impression que votre dette technique est ingérable.
Qu’est-ce qui est fait pour traiter la dette ? Avez-vous des moments pour la gérer, plutôt que juste travailler sur les bugs ?

Ca me fait beaucoup penser à ça :

Screenshot 2024-08-07 at 14.08.40
Screenshot 2024-08-07 at 14.08.401532×890 118 KB

2 « J'aime »
4

Une image vos milles mots ! Et la votre en vos biens surement plus !

1 « J'aime »
5

Je rejoins mes coreligionnaires sur le fait que réduire la fréquence de cycle risque de détériorer la situation, en tout cas, ça ne devrait pas résoudre le problème. Des temps de cycles plus long, ce sont des incréments plus complexes, donc plus risqués, donc statistiquement ça devrait amener à plus de bugs en proportion du temps passé à ajouter des fonctionnalités. Le fond du problème ce n’est donc pas le temps de cycle, mais plutôt la quantité de bugs que vous devrez traiter. Si la correction des bugs prend 80% du temps du cycle suivant, c’est que globalement le travail n’a pas été terminé correctement dans la phase précédente. Il y a donc un regard critique à porter, non seulement sur la qualité du code, mais aussi et surtout sur la qualité des test qui sont faits.

Au contraire, certains (dont je pourrais faire partie) vous diraient qu’une semaine c’est beaucoup trop long, que l’idéal c’est la pratique de la livraison continue. Le conseil qu’on pourrait vous donner serait donc - paradoxalement - de réduire le temps de cycle, pour réduire la complexité et investir sur la qualité. Ou sans forcément aller jusque là, une première étape serait de tester le sprint d’un jour.

Scrum Life a fait 2 vidéos sur le sujet :

1 « J'aime »
6

Qualité, le terme a été cité dans les réponses de @Bruno_Larouche et d’ @ArwynFr et c’est la première chose qui m’a sauté aux yeux à la lecture de la description du problème d’Adrien. A aucun moment n’est évoqué la démarche qualité mise en place.
@adrien saurais-tu nous en dire plus sur cette démarche mise en place au sein du projet ?

2 « J'aime »
7

You don’t scale crappy code

Je suis adepte du focus. Focus sur quoi ? Sur la ou les causes racines des bugs.
Un atelier du type diagramme d’Ishikawa peut vous aider à comprendre les raisons de vos problèmes récurrents et échafauder un plan d’action .
La résolution d’une cause racine qui s’apparenterait à un objectif de sprints à résoudre serait probablement un grand pas.

J’opterai donc pour une pause claire et nette en R&D pour traiter ces sujets. Que vous y voyez plus clair et que vous puissiez repartir sereinement sur de l’évolutif.

1 « J'aime »
8

Bonjour,

Merci à tous pour vos réponses, effectivement @Bruno_Larouche a bien identifier les problèmes et voici quelques éléments complémentaires (réponse à @Si_Le)

Une démarque de qualité (QA) est mise en place. Des personnes sont en charges de vérifier si les fonctionnalités développés répondent aux exigence. Mais ceci est fait entièrement manuellement. Il est à ce jour compliqué (pour ne pas dire impossible) de réaliser des suites de tests unitaires (trop forte dépendances et découpage inexistant)
La QA réalise un très bon travail et repère des bugs et souvent des cas dont le développeur n’avait pas pensé (fonctionnel). Mais il reste quelques trous.

Concernant une démarche qualité DEV il n’y a pas de merge request/pull request mis en place. Les développeurs peuvent merge le code en production sans relecture. Malgré que vous comme moi trouvons ça « anormal » il ne sera pas question de mettre en place à ce jour les MR (je ne dirais pas que les développeurs sont réfractaires mais aucune envie d’essayer)

Le WIP pourrait effectivement nous aider. Naturellement les développeurs ne font pas 50 tâches en parallèles (mais 2 ou 3; souvent des bugs). Néanmoins les bugs s’accumulent dans le backlog et sont prioritaires par rapport à la aux développements de nouvelles fonctionnalités ou de R&D. Une solution pourrait d’avoir un WIP par catégorie (BUG, Amélioration, R&D, etc …) mais je ne pense pas que ceci soit concrètement réalisable car la correction de bugs prendra toujours le dessus.

Pour résumer, sur la partie legacy qui est le coeur de métier (ce qui rapporte de l’argent) il n’y a pas grand chose pour assurer la qualité (hormis une équipe QA)
Néanmoins sur les autres projets annexes, un ensemble de « bonnes pratiques » ont été mise en place pour éviter de répéter les mêmes erreurs. Ces projets annexes consiste à prévoir le terrain pour passer d’un legacy monolithe à ± une architecture microservices.
Néanmoins en attendant et pour encore de nombreux mois voir années nous devons continuer à maintenir le monolithe legacy.

@nicobiot vous dites « J’opterai donc pour une pause claire et nette en R&D pour traiter ces sujets. Que vous y voyez plus clair et que vous puissiez repartir sereinement sur de l’évolutif. »
Je n’ai pas très bien compris.

  • vous souhaitez arréter les sujets de R&D
  • vous souhaitez que les sujet de R&D soient orientés pour traiter les problèmes qualité ?
9

Bonjour,

Puis-je pousser ma réflexion avec vous, un peu plus loin.

D’abord bravo pour l’ajout du QA, je ne peux qu’approuver.

Et pour faire avec vous un peu de chemin, sur deux derniers problèmes.

Les différents problèmes qu’ils semblent rester.

  1. « les développeurs sont réfractaires, mais aucune envie d’essayer »
  2. « car la correction de bogues prendra toujours le dessus. »
  3. Les différents problèmes de structures, architectures ou qualités du monolithe legacy

Réponse.

Problème 1 : je vous suggérais la méthode des 5 pourquoi. https://www.youtube.com/watch?v=8JYCOxJXT3E

Au lieu, de leur apporter une solution aux différents problèmes qu’ils vivent. Je pense que les amenés à réfléchir le problème différemment pourrait aider à améliorer la situation. Les développeurs ne sont pas rebelles ou retissant, juste pour le fun. Il y a une raison derrière. Il faut juste la trouver. Peut-être, la méthode des 5 pourquoi vous sera utile dans cette quête.

Problème 2.
Je vais appliquer la méthode des 5 pourquoi avec vous. Ok, je vais poser le premier pourquoi et je vous laisse trouver tant les autres pourquoi que leur réponse.

Pourquoi, la correction de bogue est aussi prioritaire ?

Problème 3, le monocyte.

« Bien sûr, on ne reconstruit pas Rome en une journée ! » :wink:

Si vous permettez, j’aimerais vous rappeler ce que dit le TDD (Test Driven Developpement). La première exécution d’un test devrait retourner « Faut ». Car, le code test, effectue un test sur du code qui n’existe pas.

Donc, si on réfléchissait ensemble à transposition avec Monocyte. Si on concevait un test avant même de produire le correctif qu’on veut appliquer.

Je ne suis pas en train de dire ou, d’utiliser la un framework de Type NUNIT OU JUNIT. Mais, de prendre le temps d’écrire le ou les tests qui seront nécessaires avant même de concevoir.

Et pourquoi, de faire cette écriture (« Documentation ») des cas de tests en « pair programming » avec autres Dev ou même un QA. Normalement, c’est un exercice qui ne devrait pas demander des heures de travail.

Quant à la partie, « d’automatisation » des tests. Je comprends la difficulté pour les unitaires. Mais, tu pourrais créer un ensemble de tests '« fonctionnel » avec des approches de types BDD ou ATDD (A pour acceptance). Elle te pourra t’aider à augmenter la qualité de manière générale !

Pour citer encore Rome, elle ne s’est pas construite en jour. Donc, n’essaie pas de tout changer. Seulement d’apprendre ensemble à bien marcher, pour mieux courir plus tard.

P.S. Faite vous confiance mutuellement, vous y arriverez !

Bruno Larouche

10

Bonjour Bruno,

Bien sûr soyez libre de guider en apportant votre expertise/point de vue !

Concernant le problème 1) :
Mon collègue (plus ancien) avait essayé de mettre en place les MR sur le projet legacy mais ce fût un échec (développeurs réfractaires), néanmoins pourquoi pas essayer la méthode des 5 pourquoi.
La solution apportée par ce même collègue fût d’imposer l’utilisation des MR (et outils annexes) sur les nouveaux projet. Solution à mon goût radicale car il n’a pas questionné l’ensemble des équipes mais je le comprends car ne pas utiliser cet outil c’est ce remettre une balle dans le pied.

Concernant le problème 2) :
A moi de jouer =)

Concernant le problème 3) :
Concernant la mise en place de ATDD je mettais déjà pencher sur le sujet dans mon ancien travail mais n’avait jamais mis en place ceci, je vais donc ré-effectuer des recherches à ce sujet

Néanmoins pour l’écriture de tests avant même de concevoir, je ne peux pas être d’accord avec vous (malgré que l’approche théorique soit bonne et à faire) car lors de correction de bugs ou d’amélioration le nombre de ligne à écrire est souvent ridicules (quelques dizaines).
Mais ces lignes à écrire doivent être écrites dans des fonctions qui font plusieurs centaines de lignes et qui ont bien plus qu’une responsabilité (prends du temps pour bien identifier l’endroit + ne pas créer de régression).
Écrire un test sur une fonction avec une multitude de conditions, dépendances, etc … est une horreur (déjà essayé ce fut un « échec »)

Cependant, je suis pour la modification pour le découpage de ces fonctions, puis des classes etc … La lecture du livre Working Effectively with Legacy Code m’aide à essayer de faire ce travail mais ceci est très très long.

Ainsi, il y a une disparité :

  • la nouvelle base de travail est prévue pour ne pas faire les mêmes erreurs (MR, outils d’analyse de code, tests, etc …).
  • Mais en attendant nous devons faire évoluer l’ancienne et les « Roadmap » ne permette pas de savoir si nous devrions continuer à y travailler quelques mois ou plusieurs année.

Et même si le début de la ré-écriture est prévue pour la fin de l’année, il faudra continuer à faire évoluer l’ancien pendant encore de nombreuses années.
Ainsi côté purement technique j’ai du mal à trouver une ou des solutions. Cependant sur le plan QA je pense qu’on peut s’améliorer pour réduire les bugs.

11

Bonjour,
Avant tous j’adore les messages précédent.
Dans ma lecture des messages, il y a une chose qui ma semblé oublié dans les pistes abordées notamment sur le nombre important de bug.
Je vais essayer de l’expliquer.

J’ai l’impression que l’on donne des choses au dev. Ceux-ci ne se pose pas la question de la complétude du parcours. Une bonne qualité ca commence des l’analyse du parcours utilisateur et sa description.

A quelle moment interviennent les QA ?
Existe-t-il des test d acceptance sont il complet ?
Est-ce que les devs et po discutent des impacts des développements?

2 « J'aime »
12

Ne pensez-vous pas, même si les intentions sont bonnes, que vous aurez les mêmes problèmes à faire modifier les pratiques sur cette nouvelle base ? En attendant le démarrage de cette refonte, ne peut-on pas anticiper sur la mise en place de ces pratiques sur le projet actuel ?

13

Vos développeurs ont bien raison. La mise en place de MR/PR à validation manuelle ne fait que ralentir le temps de cycle. Ce qu’il va se passer en pratique c’est que :

  • Soit le relecteur fait plein de commentaires, et les développeurs vont de plus en plus se reposer sur le relecteur sans vraiment améliorer leurs pratiques ;
  • Soit le relecteur ne fait pas de commentaires (que ça soit par paresse ou par incompétence) et le code ne sera pas de qualité.

Le pair programming est un moyen beaucoup plus efficace de tirer la qualité vers le haut.

La question du TDD ne concerne pas tellement les corrections de bugs mais les ajouts de fonctionnalités.

Quel est votre taux de retour QA (part des développements qui ont besoin d’au moins une correction suite à un défaut identifié en QA) ? Si ce taux est trop élevé, alors effectivement, se poser en amont du développement avec les devs et les QA pour bien réfléchir à tous les cas conforme / non-conforme, devrait permettre aux développeurs de mieux appréhender ce qui est attendu d’eux et donc de réduire les taux de retour. De plus, avec une phase de design renforcée, il y a plus de chance que l’équipe identifie en amont du développement des problèmes de conception, ce qui limite aussi le risque d’avoir des bugs compliqués à résoudre après livraison.

Cette situation est souvent rencontrée quand le problème vient du test lui-même. Enfin plus précisément du mauvais choix de découpage du périmètre système sous test. La plupart des développeurs considèrent qu’un test unitaire est un test de classe, ce qui revient à dire qu’on n’a pas compris ce qu’est une unité de développement. Je crois que je vais finir par écrire un livre là-dessus tellement il y a de choses à dire à ce sujet …

Là encore, je pense qu’on peut distinguer l’ajout de nouvelle fonctionnalités et la correction de bugs. Sur un ajout de fonctionnalité, on peut assez facilement imaginer mettre en place une nouvelle structure plus propre, complète de bout-en-bout, et testable, à côté de l’existant, sans le reprendre. De cette manière, pas de régression sur l’existant, et petit à petit on reprend le contrôle technique de la solution. C’est sûr que c’est plus cher, mais si la qualité a un coût, la non-qualité c’est encore pire …

Après si vous êtes dans un contrat forfaitaire et que le client veut pas payer, bah là c’est son problème …

1 « J'aime »
14

Bonjour,

La vie m’a appris quelque chose, oui parfois de manière sévère…! Si j’aborde un problème en me disant que toute manière, ça ne fonctionnera ou c’est de toute manière ce sera un échec.

Le résultat sera un échec, car, je poserai les actions ou décisions, pour « Faciliter » l’échec. Par contre, si je pars un projet que j’en ferai un succès (et là je ne parle pas d’obtenir une médaille aux Jeux olympiques). Mais, d’avoir juste un petit succès dans la quête que je poursuivais et de me servir de ce petit succès pour en construire d’autres.

L’autre point, il y a deux beaux verbes en langue française amené et emmener (Amener ou Emmener? Ne te trompe plus! | Français avec Pierre).

Il me semble que vous cherchez à amener vos ressources vers un objectif de qualité. Mais, je pense qu’un changement de verbe devrait être utilisé "Emmener ».

Au lieu, d’amener vos ressources vers votre objectif. Il serait plus sage de les emmener vers l’objectif. Un travail collectif plus tôt qu’un travail individuel, voir hiérarchique !

Surtout, n’oubliez pas que vous devez aussi accepter ce changement en premier. Fêter, célébrer chacun des petits succès. Rendez-les fiers de leur avancement collectif vers ce changement. Une seul pas vers l’avant, est toujours mieux que rien du tout.

Prenez leurs chapeaux, et comment vous, sentiriez-vous si on vous imposait sans que vous ne puissiez participer à ce changement. Je me répète: « Emmener » les vers ce changement.

Quand, vous aurez fait ce premier pas. Tous les conseils et commentaires de tout monde ici, vous aiderons allez encore plus loin.

En terminant, un échec qu’on apprend de ce qui s’est passé, ce n’est pas négatif. Ça nous outille pour la prochaine fois.

Bon courage dans votre « Évolution » (plus positif que changement)

Bruno Larouche

15

Bonjour,

La QA intervient uniquement à la fin. Effectivement la faire rentrer en collaboration avec le développeurs pour faire une analyse d’impact est envisageable et surement apportera du positif.

Il n’y a pas de PO à proprement parler, certains développeurs ont de bonnes connaissances fonctionnelles et sont les PO+devs d’une partie du produit (e.g. la gestion du parc automobile)

16

Effectivement je suis conscients de ces problèmes mais comme dit plus haut sans cette relecture il y a eu la création d’une codebase qui est devenue non-évolutive. L’objectif est d’avoir des retours de personnes plus expérimenté côté code pour donner des conseils ET également fonctionnellement en incluant un développeur ayant une bonne connaissance fonctionnelle il peut voir des trucs qui auraient échappés.

Le pair programming est un moyen beaucoup plus efficace de tirer la qualité vers le haut. Totalement d’accord avec vous, et j’ai l’impression que ceci ce fait naturellement dans le sens ou du PP est réalisé au besoin.

Donc oui le temps de cycle est réduit mais le gain suite à la production d’une code « plus juste » permettra une retour sur investissement (espérons …)

Très élevé oui, comme répondu à un autre message envisager un réflexion QA+devs en amont est une bonne idée et sera bénéfique.

Oui si on parle de nouvelles fonctionnalités alors les pratiques TDD ne devraient pas poser problème. Je vais me pencher sur le sujet pour moi même essayer d’implémenter ceci.

Merci

17

Bonjour Bruno,

Merci de le rappeler, quand on est « dans le jus » on oublie parfois cela et ne voir que le côté négatif, je ferai bien attention.

Et oui l’objectif est bien d’emmener.
Ce sujet me fait rebondir sur un autre : Développeur ou CODEUR ? Nos CONSEILS pour Scrum Developers nous (l’équipe) devont également travailler sur ce point

18

Bonjour Adrien,

Au bureau avec mon équipe, je m’amuse souvent à leur dire que je ne suis pas : Scrum Master, Coach Agile ou n’importe quoi du genre. Mais, seulement un empêcheur de tourner en rond !

Ne t’en fait pas, eux aussi me trouve parfois tannant avec mes questions en guise en réponse à leur question.

Bruno Larouche