Faire cohabiter des estimations QA et DEV

Communauté Scrum Life
1

Bonjour,

Je suis SM partagé pour 3 équipes travaillant sur le même produit.
Chaque équipe est constitués 5 à 7 Développeurs, et 2 QA + PO et fonctionne en SCRUM.
Nous utilisons JIRA, un seul sprint pour les 3 équipe, avec un Backlog partagé, mais avec des vues différentes selon les équipe pour qu’elles visualisent facilement leur périmètre de sprint.
Historiquement, le service QA était complètement en dehors de notre service : en sortie de sprint, nous avions donc des US développées mais non certifiées.

Nous avons déjà fait un grand pas en intégrant les QA au sein de l’équipe et en tentant de réaliser développement et certification des US au sein du même sprint. Ce n’est pas encore évident car plusieurs contraintes se posent (délai de mise à dispo des US après développement et revue de code, disponibilité des environnements de test…etc…), mais ce n’est pas le sujet qui m’importe ici.

Notre DOD, depuis peu, intègre la certif. Vous le voyez venir… on va avoir une quantité importante d’US qui vont glisser sur le sprint suivant, à cause de la partie certification.
=> là aussi, ce n’est pas mon soucis du moment, car il l’objectif est que progressivement on augmente la proportion de ticket testé au cours du même sprint… ça va se faire avec le temps.

Maintenant que j’ai posé le contexte, j’en viens au sujet qui m’importe aujourd’hui !
De l’époque où les QA était déportés, nous héritons d’un mode d’affinage et d’estimation qui porte sur 2 estimations en PE (Points d’effort) : les PE Dev et les PE certif.

Avez vous déjà rencontré ce mode de fonctionnement ?

En Sprint Planning, nous devons à la fois prendre en compte la vélocité en terme de DEV et en terme de QA.
En effet, si on veut espérer raccrocher les wagons et traiter dev+certif au cours du même sprint, il ne faut pas qu’on tienne compte des 2 critères.

Et en complément, nous utilisons JIRA, qui ne met en évidence qu’une seule valeur de PE et ne sais pas gérer une double notation. (pour ce point, j’arrive quand même à créer des indicateurs sur PE dev et sur PE certif, mais ce n’est pas optimal)

J’attend avec impatience vos retours d’expérience !

2

Hello,

Oui jai deja rencontré cette situation.
La question que je me pose c’est pour quoi faire ces estimations ?

3

Bienvenue sur le forum !

Simple remarque : d’après le scrum guide, chaque équipe devrait avoir son propre sprint, avec son objectif et son SPRINT backlog séparés. Et potentiellement des dates de sprint différentes. Mais le même PO et le même PRODUCT backlog.

Oui, c’est un grand, très grand classique. C’est comme ça qu’on développait des applications dans les années 60~70. Scrum vous fait mettre le doigt sur un sujet de fond autour de la question « qu’est-ce qu’un développeur ». Pour beaucoup d’organisations à l’ancienne, un développeur c’est celui qui code. Il y a un analyste qui fait la conception (sous forme de spécification) et un testeur qui vérifie la conformité.

L’agilité est une généralisation du passage aux analystes programmeurs qui s’est opérée dans de nombreuses organisations dans les années 80~90. Cette transformation avait pour but d’éviter le problème classique de cette séparation entre analystes, programmeurs, et testeurs. Au sens de Scrum, on n’est pas vraiment développeur si on n’est pas capable de prendre ces trois casquettes (c’est une autre formalisation de ce qu’on appelle les 3 amigos). L’optimisation de la valeur passe par le raccourcissement des boucles de feedback, car finalement le principal défaut des logiciels des années passées est beaucoup moins un problème de conformité, ni même de conception, qu’un problème marketing (le service fourni n’est pas le bon). Au final on se rend compte qu’on est plus productif en faisant travailler ces 3 populations ensemble, ce qui ouvre la possibilité de répartir les compétences autrement que par une approche taylorienne.

Dans ce contexte, il faut également faire évoluer la culture du test. Si on n’y prend pas garde, on peut garder la culture historique du test comme moyen de conformité à la spécification, ce qui implique de pousser les développeurs à écrire de la spec « pour pouvoir écrire du test ». Dans ce contexte, on n’a finalement rien changé à l’ancienne culture.

Si je prends une analogie avec le développement d’une chaise, où la taille des pieds est critique pour éviter les chutes : dans une vision à deux niveau conception-implementation, on imagine bien que si l’implémenteur met un pied plus petit que celui recommandé par l’analyste, l’utilisateur risque l’accident. Mais on peut aussi avoir le problème d’un pied conforme à la spec mais cette fois c’est l’analyste qui s’est trompé en concevant une chaise avec un pied trop petit pour le poids de l’utilisateur. Pour l’utilisateur, savoir que le pied installé par l’implémenteur est « conforme à la spec », ou que la chaise a été « conçue pour résister à une charge de N kg » ça lui fait une belle jambe (littéralement) ! Ce qui l’intéresse c’est de savoir que la chaise a été testée à l’utilisation avec un poids de N kg. Le test doit ne doit donc plus être écrit pour garantir la conformité du produit à sa conception, mais pour garantir à l’utilisateur que le service promis lui est rendu. L’étape ultime c’est d’intégrer le marketing au test, car finalement, comme dit plus haut, est-ce que c’est vraiment d’une chaise dont l’utlisateur a besoin ?

1 « J'aime »
4

Sur la tenue du backlog, on est plutôt bien. Chaque équipe dispose de son sprint backlog et des objectifs propre, et partage un product backlog. C’est simplement le sprint au sens JIRA qui est commun, tous les rituels sont séparés.
=> Je n’ai pas de problématique sur cette organisation, elle marche bien chez nous.

Pour le reste, oui, je suis d’accord avec toi.

5

D’une part, on hérite de ce fonctionnement de par le découpage entre un service Dev et un service QA => ce n’est pas une raison suffisante, on est d’accord.

D’autre part, notre environnement technique n’est pas encore optimal pour intégrer l’activité de test dans le sprint, on a souvent des tickets développés/non testés en fin de sprint.
Avoir un estimation des PE certif permet de garder une visibilité sur la charge de travail restante pour terminer ces US.

Chez nous, les rôles et compétences sont bien dissociés : 2 QA et 6 développeurs (codeurs). Il n’est pas envisagé que les compétences soient transverses, on va rester dans ce schéma de fonctionnement.

Donc en Sprint planing, se pose souvent la question de savoir ce que les développeurs vont pouvoir prendre en charge dans le sprint, et de ce que les QA seront en mesure de certifier.
Pour aider à celà, on se base sur une vélocité moyenne des X sprint précédents pour estimer la capacité de l’équipe en terme de PE.

à savoir qu’on est sur du SCRUM, mais par définition, ça ne répond pas à tout puisqu’on est multi-team et que je suis seul SM pour les 3 équipes (et même 4…) donc on est sur de la conduite au changement, je ne peux pas tout révolutionner d’un coup, au risque de perdre du monde sur le chemin.

6

Hello ! Tu peux éventuellement utiliser 2 tableaux différents pour suivre l’avancement côté DEV d’une part et l’avancement côté TEST d’autre part… si tu te rends compte que tu as besoin d’avoir des tickets dans un tableau qui concerne les 2, il vaut mieux identifier les tickets qui ne seront pas testés et validés avant la fin du sprint et ne pas s’engager dessus, mais rien n’empêche de les avoir quand même dans ton sprint et d’avancer dessus. Oui les testeurs et les dévs travaillent de manière décalée, mais ce n’est pas plus mal, pendant que les devs avancent au début du sprint, les testeurs ont déjà des tâches à faire qui proviennent du sprint précédent. Tu as une équipe, la vélocité qui en découlera fera apparaître ça et je ne vois pas pourquoi cela serait un problème. Tu peux aussi juste faire une addition simple des estimations de ton équipe pour avoir une note globale sur tes tickets plutôt que de vouloir les séparer et distinguer la partie dev de la partie QA… quel est l’intérêt de les séparer ? Le but étant de ne pas surcharger l’équipe et qu’elle produise le maximum de valeur le plus rapidement possible, les indicateurs sont là pour faire des choix, et les tickets développés mais non testés en fin de sprint sont simplement des tickets non done, cela n’est pas gênant à partir du moment que c’est clair pour l’équipe. :slight_smile:

7

Merci pour ton partage Franck

Dans une équipe j’ai 2 QA et 6 Dev. Si le Sprint est programmé 10 stories correspondant à 30 PE de DEV et 10 de QA, ce n’est pas du tout la même qu’un sprint de 10 stories correspondant à 20 PE de DEV et 20 de QA.
Dans le premier cas, on aura un indice de confiance élevé, dans le second, on sait que ça ne passera pas.

Je ne sais pas encore si on arrivera à fusionner les 2 valeurs, mais aujourd’hui, force est de constater que ça nous apporte un niveau d’information que l’on perdra si je fusionne les 2

8

Okay ce que j’avais fait dans une équipe ou le management voyant les choses a l’ancienne, et ou justement la QA avait un autre manager mais était dédie à notre équipe.
Et notre manager sen « fichait de la prevision test » parce que globalement la qualité était au rendez-vous.
J’avais configuré dans jira un tableau comprenant la vélocité de l’équipe de « devellopers » donc terminé quand testé.
Pour le besoin de notre manager il avait besoin d’être rassuré sur ses dépenses vis a vis de son équipe et être sur qu’il ne se tourne pas les pouces.
Apres avoir essaye de lui faire comprendre que sa manière de voir n’était pas l’esprit et qu’elle peu justement faire baisser la qualité du code produit (ce qui fut équivalent a pedaler dans la semoule), je faisait des exports jira pour avoir le burndown chart de son équipe de pisseur de code (ironie).

A posteriori j’aurais fait une complexité commune mais des tableaux différents. Pour que dans jira ca corresponde a rapport différent de sprint avec un écart de sprint mais bon c’est du cycle en V déguisé qu’on fait la.

Un peu de théorie sur les estimations que jai pu lire ,cela sert à catégoriser/ranger par taille de tes items de manière relative. Et de mesurer le temps que tu prends à terminer les items.

9

Bonjour,

Ce que je ne comprends pas dans le message initial, c’est que les causes racines semblent identifiées (disponibilité des environnements de test, délais de livraison des Us pour test, temps long de validation) mais que tu veux te focaliser sur comment bien répartir les charges en se basant sur des estimations (plus ou moins fausses par définition)

Es tu sûr que ton action viendra à corriger les problèmes que tu rencontres ?

PS: évidemment ma question est orientée je n’ai jamais eu à travailler de cette façon, pour finaliser les Us du sprint backlog l’estimation relative prenait en compte les temps de tests et retours de la QA et la QA était en totale « fusion » avec les DEv

10

Ce que tu décris n’est culturellement pas du Scrum. Vous en avez adopté la structure (les programmeurs et les testeurs sont dans la même équipe), mais pas l’organisation (les programmeurs et les testeurs ne travaillent pas ensemble, en mêlée, à l’atteinte d’un objectif commun).

Quelle est l’utilité de ranger les items par taille de complexité estimée ? L’objectif de Scrum c’est de maximiser la valeur en évitant de travailler sur les fonctionnalités les moins utiles. Ne faudrait-il pas plutôt trier les items par valeur estimée ?

Ce n’est pas parce qu’une fonctionnalité est complexe qu’elle est utile et réciproquement …

11

Sur cette partie la je n’ai pas parler de scrum.
Nous sommes en accord sur la valeur scrum.

Néanmoins je n’ai jamais rencontrer d’entreprise qui ne se pose la question du temps prit pour livrer la valeur et qui n’essaye pas de le prédire

12

L’action que je veux porter (et que l’équipe veut porter) c’est de re-synchroniser Test et Développement dans le même sprint.

Les freins à cela son travaillés en parallèle (intégration continue en premier lieu, et travail sur la complétude des environnements de branche pour pouvoir certifier plus rapidement les US).

La question que je me pose c’est : si je raisonne purement Scrum, alors on ne devrait réaliser qu’une seule estimation commune. Mais si j’applique ceci dans notre contexte, on perd un niveau de finesse qui est de savoir la charge QA et DEV. Cette information permet d’améliorer notre prédictibilité sur la complétude des items du backlog, d’adapter éventuellement la stratégie de sprint, d’anticiper une surcharge de QA à venir (voir de planifier un renfort temporaire)…

Petit détail : je suis arrivé il y a 2 mois dans ce contexte. Je ne vise pas de coller parfaitement à un framework ni de révolutionner les choses du jour au lendemain, mais dans ce contexte particulier, je suis preneur de retour d’expérience sur ce type de contrainte.

13

Tu mets là le doigt sur un aspect ressources dans l’équipe qui devrait peut être être revu… à quoi bon développer 50 fonctionnalités si derrières tu n’as pas la QA pour valider tout ça.
Tu verras que tu sauras identifier avec l’expérience très rapidement les tickets qui sont coûteux en complexité côté QA même si une seule estimation est rattachée à ton ticket.

14

Si on raisonne purement Scrum (tel que décrit dans le Scrum Guide), alors vous ne devriez pas réaliser d’estimation, ou du moins pas comme ça.

Avec Scrum, l’objectif est de résoudre un problème donné, et non pas d’implémenter une solution donnée, dont un tiers (*) pense qu’elle est censé résoudre ledit problème. Le postulat de départ c’est que l’environnement est chaotique : on nous impose des contraintes / changements d’opnions au fur et à mesure, certains détails contraignants ne sont identifiables qu’au dernier moment, le sujet est par nature plutôt expérimental, … Donc la solution qu’on va effectivement retenir à l’issue du sprint a de fortes chances d’être sensiblement différente de celle qu’on a imaginé au départ.

N’ayant pas de solution définie à implémenter, on ne peut donc pas faire d’estimation initiale des coûts de réalisation. On part donc plutôt sur l’établissement d’un budget initial, qui devrait permettre à l’équipe d’explorer le champs des possibles et d’aboutir à une solution utilisable. Ce budget, c’est la durée du sprint. Si on termine un incrément avant la fin du sprint, et bien tant mieux. C’est tout bénef et on peut démarrer un autre sujet. Sinon, on regarde ce qu’on a réussi à faire et on décide si on continue d’investir dans le sujet ou si on s’arrête là.

Ce qu’on estime, dans ce contexte, c’est la faisabilité d’avoir un incrément d’ici la fin de sprint. On n’a pas besoin de savoir si l’implémentation initiale fait plutôt 237 ou 243 jours. De toutes façons on va faire un sprint de 60 jours, et à la fin on aura probablement complétement changé la conception par rapport à l’estimation initiale. En revanche, les 60 jours sont fixes, et on sait dire ce qu’ils représentent par rapport au bénéfice attendu de la résolution du problème de base. Et à l’issue, si vraiment on n’est pas content et qu’on jette toute la solution à la poubelle, on aura perdu 4 fois moins de budget que dans une approche traditionnelle.

Cette estimation-là, (60 jours versus le bénéfice attendu de la résolution de mon problème) est nettement plus facile et plus fiable qu’une estimation traditionnelle.

(*) Ce phénomène est d’autant plus problématique qu’en général, dans les organisations traditionnelles, cette conception de solution est faite par la personne la plus techniquement inapte de toute l’organisation, et les développeurs sont rarement sollicités. Ces derniers, qui sont les experts techniques de l’entreprise, voient donc débarquer des « trucs » qui ne sont ni de bonnes expression de besoin, ni de bons cahier des charges, et doivent ensuite se débrouiller pour pondre une estimation détaillées des charges …

2 « J'aime »
15

Je connais bien Scrum et sa finalité. Il n’est pas question d’estimer en jours, on applique une estimation largement répandu dans le monde agile (et Scrum)

Dans l’absolu, je suis d’accord… et en même temps pas vraiment :sweat_smile:

Scrum est un cadre, il n’impose pas d’estimer, mais il ne l’interdit pas. Il n’interdit pas d’intégrer des pratiques, tant que le cadre Scrum est respecté.

Celà dit, je ne vise pas un respect complet du cadre Scrum, car l’organisation dans laquelle je me trouve n’en est pas capable. Mais ce n’est pas une raison pour que je ne maximise pas notre méthode de travail en m’appuyant sur des principes agiles.

16

Mon humble opinion est que tu pourrais en faire un sujet de rétro pour que la décision de « comment on estime mieux le travail à venir des développeurs et des testeurs » soit issue d’une réflexion collective

Ton travail d’analyse avec les attentes, les contraintes, les enjeux seront pertinents pour faire que ce travail de réflexion aboutisse à la meilleure solution pour tout le monde mais au final, la décision finale aura plus de poids (d’impact) si tout le monde s’est accordée sur celle-ci

Qu’en penses-tu ? Est-ce possible dans ton contexte ?

17

J’arrive après pas mal d’échanges que je n’ai pu lire qu’en diagonale. Désolé si je fais ou provoque de la redite.

@AntoineL, si j’ai bien compris, l’objectif principal est d’améliorer le flow de l’équipe. Une manière de faire ça est de créer petit à petit une équipe pluridisciplinaire là où avant il y avait des équipes séparées par compétences (devs d’un côté, QA de l’autre). Cette transition suscite différentes problématiques, certaines bien connues, d’autres moins. Une de celles-ci est comment jauger la charge de travail de l’équipe sachant qu’actuellement il existe deux estimations pour chaque sujet, une pour le dev, l’autre pour la certif.

J’ai l’impression que ce sujet est intriqué avec d’autres et qu’il faut le traiter comme tel. De plus, quels sont les critères (potentiels) de succès et d’échec de cette modification du fonctionnement de l’équipe ? Comment faire retour arrière ? Il y a quelque chose qui ne me semble pas cohérent dans la démarche : j’ai l’impression qu’il est supposé que l’objectif est clair et bon alors qu’il y a trop d’incertitudes (cf. Cynefin).

Est-ce que je détecte une présomption que tout le monde doit être occupé à 100% lors d’un sprint ? Si oui, vous allez être victime du piège de l’occupation (https://youtu.be/CostXs2p6r0).

Est-il prévu que les devs mettent la main à la patte dans la phase de certification, et les QA dans le développement ? C’est une des pratiques assez répandues en Kanban et lorsqu’on a des équipes pluridisciplinaires.

Est-il prévu/envisageable de faire du travail en binôme ? Dev + QA ensemble sur un sujet.

Concernant les possibilités de faire cohabiter plusieurs estimations dans JIRA, j’avais déjà fait ça par le passé de deux manières :

  • En utilisant JIRA Advanced Roadmaps (anciennement Portfolio) où j’avais pu décrire les rôles des gens et la proportion que chaque rôle passe sur un ticket.
  • En utilisant des sous-tâches.
1 « J'aime »
18

Bonjour Antoine,

Tu fais face à une problématique que j’ai déjà rencontré, et qu’on rencontre surement sur pas mal de projets.

Cette étape de certification par les QA, fait-elle partie de la DOD ?
Si c’est le cas, alors les estimations en PE devraient en tenir compte de telle sorte qu’on puisse dire « L’item ABC a été estimé à x PE pour qu’il soit DONE et intègre l’incrément à l’issue du sprint ».
Si actuellement votre vélocité ne tenait compte que de la phase de développement, elle se réduira, mais c’est ok. L’idée est de savoir ce que vous pouvez raisonnablement embarquer ET terminer (DOD) dans un sprint par rapport au sprint goal et par rapport à votre vélocité.
On doit obtenir un un incrément utilisable et potentiellement « livrable » à chaque sprint.

Après avoir fait ça, il y aura des sprints avec peut-être plus de temps de test que de temps de développement. Souvent, les développeurs/PO/Managers etc… vont vouloir remonter de nouveaux tickets dans le sprint pour optimiser l’activité, ce qui peut s’avérer être un piège (comme dit plus haut). L’idée serait peut-être de faire réfléchir la scrum team sur son organisation dans pareil cas ?
Ce qui doit nous animer, c’est de terminer les items, pas d’en commencer un max : « Commençons par terminer et arrêtons de commencer ».
Peut-être que ce temps peut être alloué à d’autres activités, plutôt qu’entamer des sujets potentiels du sprint suivant comme :

  • Corriger les anomalies ?
  • Aider les QA dans les tests ?
  • Continuer l’affinement du PB avec le PO ?
  • Partager la connaissance technique sur certains sujets entre devs ?
  • Pair-programming ?
  • Traiter un peu de dette tech ?
  • Se focaliser sur une action d’amélioration continue qui n’aurait pas été encore traitée (l’idée c’est de le faire au plus tôt) ?
  • …

Autre remarque, il ne faut pas chercher à faire rentrer au chausse-pieds des items dans l’incrément de sprint, pour les beaux yeux du client ou de la hiérarchie.
D’une part, ça crée un sentiment d’oppression en fin de sprint, et d’autre part, on peut commettre des erreurs et introduire de nouveaux bugs plus ou moins impactant.
Si on n’arrive pas à terminer un item correctement, s’il manque quelques tests à effectuer, et bien tant pis, on terminera en début de sprint suivant (bien que tout sujet non terminé à l’issue du sprint doive réintégrer le PB, avant de l’ajouter dans le sprint backlog suivant)

J’espère que j’aurais pu t’aider un peu :slight_smile:

Bonne journée

2 « J'aime »
19

Hello, bravo pour ton premier message, cest un super sujet :blush:

Si je comprends bien, le besoin c’est de synchroniser dev et test, enfin j’imagine que le besoin c’est d’avoir du fini (du sprint en cours) en fin de sprint.

Il y a des engagements contractuels sur cette charge ? Sur des dates de livraison ? Un management avec des intérêts à avoir ces informations ? Des pénalités ? C’est quoi comme type d’activité, quels sont les flux de valeur ? D’ailleurs, on est sur du développement logiciel ? Du paramétrage ? De la mise en œuvre de spécifications ? Quel domaine : clair, compliqué, complexe ? C’est quoi l’impact d’un gap entre estimation et réalisation, pour l’equipe, pour toi, pour le management, pour les parties prenantes ?

Pourquoi choisir Scrum alors que - au moins - un des éléments primordiaux ne pourra pas être présent (la pluridisciplinarité) ? Vous avez la latitude de faire évoluer ce cadre ? Parce que au moindre petit gravillon dans les rouages, sans ,
-notamment- la pluridisciplinarité et la bonne philosophie, c’est un patatra assuré et aïe.

Qu’est ce qui empêche la QA d’estimer aujourd’hui ? Dev et test d’être synchro ?

Là comme ça je pense échanges, j’encouragerai les DEV et la QA à se causer un max, à etre cul et chemise sur les refinement et daily et à se poser des questions du genre « de quoi on a besoin pour être confiant de finir ce besoin ou une partie de ce besoin ? » « Sur quoi on est confiant ? > découpage », à construire un plan, sans y passer trop de temps et à l’adapter au plus près jour après jour. Il faut apprzndre à travailler ensemble, trouver un rythme. Je ferai attention à ce que l’équipe soit engagée sur du très confiant au début, pas trop challengeant, quitte à être un peu sous engagé en tout cas, clairement pas sur engagée pour assurer des réussites et prendre le temps de tester et ameliorer pendant le sprint (attention à ne pas toucher à la dod pendant le sprint par contre et il faut que l’équipesache qu’elle a la latitude pour s’organiser, c’est un bel objectif d’équipe), l’idée étant de construire rapidement une confiance avec les parties prenantes et entre les DEV et la QA (maintenant c’est le même bateau qu’il faut faire avancer) et de livrer même plus petit que les attentes si elles sont fortes mais surtout, de livrer ! (Il faut communiquer auprès de sparties prenantes, être transparents sur les difficultés, les réussites, un peu de la vie de l’équipe, c’est elle qui delivre de la valeur). Si vous livrer petit et souvent, il y a des chances pour qu’on vous demande moins de visibilité, ca rassure. Reduisez la durée de votre sprint si nécessaire et identifiez vos flux de valeurs, il y a peut être (probablement) des voies plus rapides (boucle de feedback) pour certains types d’éléments du backlog

Pour le chiffre à y mettre dans ce champ Jira… passer du temps là dessus je trouve que c’est du gaspillage, si vous le faites faites le vite, definissez une timebox courte (Dé 12 faces - Lanceur de dé douze faces - D12 :grin:), c’est pas là qu’est la valeur, tu sais ce genre échanges qui ne provoque pas de questionnement sur le besoin…

Un indice de confiance ne serait il pas suffisant ? La vélocité peut aider l’équipe à savoir si elle est confiante ou non, mais si c’est casse tête de trouver un chiffre, ou meme de savoir s’ul en faut un deux ou un par exécutant (:stuck_out_tongue_winking_eye:) n’en mettez pas, qu’est-ce qui vous y oblige ? Utiliser le temps dégagé à ne pas faire ces estimations, à reflechir à comment tester dev et qa ensemble, ca aidera le bateau à avancer.

Ils s’entendent comment Dev et Qa ? Y a t’il des difficultés, les responsabilités ? La hierarchie ? Les objectifs ? Et le PO dans tout ça ? Et est ce qu’il force la main pour faire entrer des éléments dans le sprint ?

1 « J'aime »
21

Réponse troll

Pourquoi que qa et dev ?

Il y a bien d’autres activités en jeu pour délivrer

1000030474
10000304741080×1075 126 KB

2 « J'aime »