Sprint running /Traitement de ticket en prod

Bonjour,
Je dispose d’une équipe de 09 devs repartis en 3 sous équipes qui travaillent sur des projets différents.
Le problème auquel je suis confronté, ce sont les mêmes devs qui traitent les tickets des apps déjà en production et cela provoque très souvent des glissements de sprint.

Solution proposée et rejetée par la direction : Mettre en place une équipe pour traiter ces différents tickets et faire la mise à niveau de la version du code, l’architecture, la version des outils utiliser car nous avons constaté en majorité que ces anomalies sont liées à la vétusté des versions de code et de l’environnement.

Besoin de votre retour d’expérience sur la question.

Merci d’avance.

Salut,

Par « tickets des apps déjà en production », tu parles des bugs ?
Pour un produit en prod, en rythme de croisière, tu peux tabler sur 20% d’effort de maintenance (donc 80% de dev pour les nouvelles features).
Cet effort de maintenance va progressivement augmenter au fur et à mesure que le projet vieilli. Pour des vieux dinosaures, il n’est pas rare d’avoir 50%, voir 80% de la workforce dédiée à la maintenance. Dans ce cas, il faut sérieusement se poser la question de la fin de vie du projet…

Mais dans tous les cas, c’est une très mauvaise idée d’avoir une équipe « Dev » et une équipe « Maintenance ». L’équipe de dev doit assurer la maintenance de ce qu’elle produit.

1 « J'aime »

Tu as 3 équipes et 3 projets ? Chaque équipe a son projet ?
Si c’est le cas, comme dit @Tan je pense que chaque équipe doit gérer le Run et le build de son appli.
Si c’est plus complexe que ça il existe d’autres topologies mais il faut avoir plus de détail sur les dépendances techniques entre projets, les rôles autres que les dev (9 devs répartis en 3 équipes ça me parait un ratio très faible), la répartition bugs/new features, etc.

(9 devs répartis en 3 équipes ça me parait un ratio très faible).
Ce qui voudrait dire que le nombre dev doit augmenter par équipe pour avoir un bon ratio.

3 dev pour une équipe est assez faible, mais ça peut marcher. Une équipe de 3 dev qui s’entendent bien marchera mieux et produira plus que 6 dev qui dépilent leur ticket sans communiquer.

S’il y a vraiment 3 projets indépendants, pas la peine de chambouler tout ça. Mais comme l’a dit @nicobiot, s’il y a des dépendances entre les projets, il faudrait peut-être fusionner les équipe. Une équipe de 9 est encore acceptable. On peut faire aussi 2 équipes avec des scopes cohérent, mais pitié, pas une équipe front et une équipe back :stuck_out_tongue:.

Garder à l’esprit que le ratio maintenance/feature n’a rien à voir avec le nombre de dev. Une équipe de 1 développeur peut très bien assurer 20% de maintenance et 80% de développement. C’est aux développeurs d’organiser leurs emplois du temps comme ils veulent.

Bonjour et bienvenue dans la communauté @Tenemaga_Coulibaly

Oula, ce sont de très gros chiffres ça. Et ce n’est pas une fatalité. Les développeurs sont responsables d’inverser ces chiffres. Pour conserver une productivité constante.

L’objectif c’est tendre vers le 0 bug.
Et l’effet de maintenant doit ne faire que diminuer.

Lors de ma dernière expérience j’ai mis le pied à l’étrier et emmené toute l’équipe vers ce résultat :

Nous devons nous attendre à voir le nombre de bugs causé par les changements diminuer. Et les autres être résorber progressivement. Jusqu’à ce qu’il n’y en ai plus qui vaille la peine d’être corrigé.

Pour ce problème précis, je met le doigt sur un manque d’excellence technique. Même pour ce que l’on appelle le « legacy ».

Nous en avons parler récemment dans un autre sujet.

C’est la différence entre la théorie des livres comme « Accelerate » et la réalité du terrain. Sur du soft industriel legacy qui a 10, 20 voir 30 ans, quelques millions de lignes de code et l’équivalent de plusieurs siècles homme de développement, les paradigmes ne sont pas les mêmes. Même en stoppant tous les développements, le flux de bug remonté par les utilisateurs ne s’interrompra pas, il y en a juste trop dans le code existant. Il faut alors gérer la maintenance comme un flux continue avec un trop plein, et assumer le fait qu’on ne fixera pas tous les bugs entrants et encore moins tous les bugs du logiciel.

Souvent ces soft ont eut un age d’or, avec plusieurs dizaines voir centaines de développeurs. Ils ont passé leur pic d’activité et se retrouvent avec une équipe réduite qui n’a tout simplement pas la capacité d’adresser la dette technique. On parle réellement de plusieurs siècles de développement. Il est utopique d’imaginer résorber la dette en seulement quelques années avec quelques développeurs. Il faut savoir être Agile et adapter ses méthodes de travail :wink:

Exactement, en itérant sur le produit :smiley:

1 « J'aime »

Mes propos expriment la réalité du terrain, quand l’excellence technique est présente.

Nos expériences sont différentes dans des contextes différents. La nuance du contexte est importante ici.


Dans ce contexte de code « legacy », les valeurs minimum sont la patience et le courage.

La capacité de gérer un contexte difficile demande un certain niveau de compétence.

Personnellement je ne recommanderais pas d’avoir des équipes composées que de juniors.


@Tenemaga_Coulibaly que peux-tu nous dire sur la composition de tes équipes ? À propos des compétences et du niveau de ces compétences.

Exemple :

Ici la séniorité n’est pas le nombre d’années.

1 senior full stack axé back.
1 junior full stack axé front.
1 senior frontend.

J’ai toujours connu ce combat, et jamais réussi à mettre en place une solution parce que ça demande un équilibre entre des parties qui n’ont pas les mêmes KPI ;(
Je suppose que tu parles d’un contexte où l’équipe de 9 devs assurent directement le support et le développement.

C’est grave le glissement de sprint ? Ça veut dire quoi glissement de sprint ? Y aurait-il eu des promesses ? Du waterfall planqué ?

Un sprint => Objectif et on essaye de réaliser le plus possible pour cet objectif.
Glissement = « on n’a pas su tout faire » … Et alors ???
Si tout faire est obligatoire, c’est qu’on revient à l’ancien triangle

Le Zéro-Bug : tous les tickets des apps en prods, soit c’est de l’incident, soit du problème, soit de la demande d’amélioration

  • Réparer un incident, c’est rétablir le service
  • Régler un problème, éviter qu’un type d’incident ne se (re)produise.
  • Une demande d’amélioration : c’est ajouter de la valeur.

Régler un problème est une forme d’amélioration.

Mon amélioration => PO => est-ce que ca peut attendre d’être cohérent avec l’objectif de sprint ?
OUI => Item du Product Backlog
NON=> opérationnel (comme les incidents)

Zero bug => PO (qui aura sans doute discuté avec l’exploitant du produit) a 2 choix

→ On intervient et tout de suite
→ On n’intervient pas et on assume

(note il y a déjà eu un choix plus haut qui correspond à "on interviendra => product backlog)

Il reste le « on le fait immédiatement »
Pas besoin de le mettre dans le kanban de sprint

Autre version c’est
On l’ajoute au « Kanban du bruit et des imprévus »

==> C’est ce qu’on voit avec les SCRUMBAN

Un choix peut être : "ok on ne stoppe pas l’encours dès qu’un hors « objectif de sprint » survient, mais dès que la personne a fini sa tâche en cours.

QUI doit le faire ?

Le coup de l’équipe dédiée : perso il y a 2 choses qui font que je n’aime pas ça.

=> c’est donc équipe dédiée à un type de tâche et non au produit, c’est une équipe support.

C’est du silo. Si cette équipe touche au code, il va falloir mettre en place des échanges réguliers entre l’équipe support et l’équipe ajout de valeur. ⇒ perte de temps et complexité de communication
Être dans une équipe de support, c’est toujours vu comme « moins » fun, moins valorisant.
Chez les dev ça développe une acceptation de baisser la qualité, de toute façon, il y a le support pour encaisser mon mauvais travail.

Je suis partisan de l’équipe qui développe le futur et assume le présent.

Il y a un cas de figure qui passe parfois.

1 équipe de support N et les autres équipes qui font « futur » + "Support niveau N+1.
Donc le support N protège la N+1 tout en apprenant à devenir de futurs membres de N+1

Dans cette équipe, on trouve des apprentis (nouveau dans la boite, pas forcément junior en compétence) qui évoluent et apprennent à la dure pour monter en compétence et découvrir le produit et/ou des gars qui aiment ça. Le support ça peut être aussi plus de défi, plus de variétés, plus de contacts avec les utilisateurs, plus de « solitude » et « autonomie » …

Donc, on revient à ta situation actuelle. Mais là, il y a encore des adaptations possibles.

Soit ce fameux Zero bug => ca demande l’acceptation de mon préambule « un glissement de sprint, c’est pas grave »

Soit la marge.

Il y a plusieurs possibilités pour ca (à combiner)

  • n% du temps de sprint est consacré à cela.
  • n% de l’équipe se consacre à ça (pour protéger les autres, à la shadock), un rôle tournant

L’important, c’est de comprendre que
1° c’est le PO qui choisi et assume ce qu’il prend par rapport au SLA
2° L’équipe n’a qu’un seul décideur humain. (Le PO)
Perso, je l’observe au quotidien. Les managers qui font de l’ingérence dans le travail des équipes pour protéger leurs KPI persos au détriment du sprint, de Scrum.
3° Le SLA défini le temps de réaction aux incidents et demandes imprévues. Donc ca aide énormément à faire les choix du « maintenant ou pas »

2 « J'aime »

C’est un peu décousu quand même comme réponse :stuck_out_tongue: (même si je suis d’accord sur l’essentiel)

Bah de toute façon ce n’est pas à prendre tel quel, je partage juste mon raisonnement (et il est tordu, fouilli comme mon cerveau) et si ça inspire ou fait réfléchir tant mieux :wink:

2 « J'aime »

Les dev sont tous full stack.
Dans chaque équipe, il y’a au moins un senior.

Tu parles au sens commun ou au sens Scrum ?

Au sens Scrum, les « devs » sont juste tous "membres de l’équipe scrum "
Et quelque soient leurs compétences (fullstack, marketing, expert en boucle while, testing, dessinateurs, légistes, secouristes…,) Ils sont solidaires et responsables du livrable, de l’incrément.

1 « J'aime »

Le message était adressé en réponse à Alexandre à prioi… :stuck_out_tongue: Mais effectivement, ça montre qu’il y a peut être un focus trop « technique » justement.

1 « J'aime »

Elles m’ont l’air relativement bien armées tes 3 sous-équipes de full-stack.

Comme il a au moins un senior, je devine qu’ils connaissent les tests de caractérisation.

Et j’imagine que lorsque chaque membre rentre le soir chez eux. Et qu’ils se regardent dans le miroir, ils sont fiers de ce qu’ils ont réalisés durant la journée.

Via du pair ou mob programming.

  • Les seniors ont appris en expliquant les concepts aux juniors.
  • Les juniors ont appris en comprenant les connaissances que les seniors leur ont transmises.

Ici, un point de vocabulaire à définir.

En quoi ces « projets » sont-ils différents pour les dev ?

Aide pour répondre, à ouvrir en dernier ressort
  • niveau d’autonomie
  • complexité
  • durée
  • base de code ; commune, indépendante, etc
  • des compétences requises
  • dépendances ; entre projets, entre apps, etc
  • les liens avec les apps
  • autres différences, etc