Arguments pour/contre FUSIONNER la TESTEUSE dans les DEV?

Communauté Scrum Life
,
1

Bonjour chère communauté !
(Que deviendrais-je, si vous n’étiez pas là?! :blush:)

En Scrum, théoriquement, il n’y a pas de rôles mais une équipe DEV incluant toutes les personnes impliquées dans la création du produit. OK.

Chez nous, il y a 2 dév spécialisés dans la partie appli mobile, 3 dév spécialisés dans la partie web, une testeuse, une P.O. qui fait les tests finaux, et une SM (moi).

La testeuse a une fonction transverse, donc, puisqu’elle teste tous les types de tickets.

Actuellement, (j’ai hérité de cette situation), la vélocité de l’équipe est calculée sur la base des heures prévues de présence des 5 dév. pendant le Sprint concerné. Les heures de présence de la testeuse ne sont pas prises en compte.

Je trouve que c’est gênant, pour diverses raisons :

  • par principe, car en Scrum, comme déjà dit, tous les participants à la production sont DEV. Tous à égalité d’accountability et de « statut » = il n’y a pas de raison pour qu’elle soit exclue.

  • parce que quand elle est absente, la vélocité calculée n’est pas impactée, alors que la vélocité réelle le sera forcément (puisqu’il n’y a personne pour tester les tickets)

  • parce qu’il arrive que lui soit confiés des tickets spécifiques consistant en des tests un peu plus poussés sur tel ou tel sujet, et que ces tickets restent sans points… (ils ne sont pas comptés dans le travail de l’équipe, ce qui est injuste en soi + ça impacte les reportings que le client demande, sur les réalisations de l’équipe)

Le seul inconvénient que je voie à la rendre DEV au même titre que les autres, c’est que pendant quelques temps, la vélocité calculée va être surestimée : on va ajouter des points de capacité de l’équipe, alors qu’en réalité, rien n’a changé concrètement. (Et d’ailleurs, je ne sais pas encore comment je vais arranger ça…).

L’équipe semble majoritairement résistante à cette idée, a priori. Et peut-être qu’elle a raison?
(On n’en a pas encore discuté : ça doit venir la semaine prochaine, mais j’aimerais leur donner mes arguments un peu en avance pour que tout le monde puisse y réfléchir un peu, en amont).
Il semblerait que ce soit la transversalité du rôle de la testeuse qui soit le principal argument contre, je crois…

Et vous, auriez-vous des arguments PROS et CONS à partager avec moi sur cette question de savoir s’il serait bénéfique ou non que la testeuse soit considérée comme une DEV à part entière dans notre équipe, et qu’en conséquence, ses heures de présence prévues soient incluses dans le calcul de la vélocité de l’équipe ? (à part l’argument de principe Scrum, bien sûr :wink:)

Merci d’avance !

2

Salut,

Argument qui m’apparait immédiat: truck factor.

Si elle part en vacances, comment se déroulent les tests ?

Si elle change de boite, combien de temps avant de pouvoir reprendre sereinement un process de tests et de qualité ?

1 « J'aime »
3

Bonjour Charlotte.

Je comprends tout à fait ta question et honore le fait d’en tenir compte vis à vis de la testeuse pour l’avoir vécu en tant que testeur ancien développeur.

En Agilité by Scrum et non Agile j’ai été confronté au sujet « et le test dans tout ça ?! » C’est là, que m’est né le souhait de devenir testeur mais également celui suivre la pratique Scrum et pourquoi pas un jour contribuer à l’approche d’utilisation du framework dans les équipes projet.

Je suppose que ton équipe donc dev est en maintenance et non forfait ou comme dit parfois réponse à la demande ?

Pour ma part j’ai connu les deux pour découvrir Scrum dans le second cadre, au forfait.

Dans le premier cas le test était toujours pris hors tests comme si celà ne faisait pas partie de la qualité et du DoD. Et surtout comme si la complexité du développement n’était pas à prendre en compte également pour la réalisation des tests.

Celà dit c’est en forfait que j’ai découvert un fonctionnement différents en Agilité et qui prenait en compte la symbiose DEV et que les testeurs faisaient partie des développeurs dev purs partageant ensemble les diverses tâches et problématiques rencontrées.

Pour espérer répondre à ta question et voir un jour ce type de conseil apporté donné à de futures équipes DEV j’ai envie d’apporter le conseil, que la testeuse se fasse entendre comme équipière DEV en tant que développeuse opératrice du produit fini.

Alors que je travaillais le dev en Scrum, j’ai le métier testeur en mode équipe séparée aet bien le temps perdu aller retour voire sans retour. Car je testais en tant qu’ancien dev et trouvait des anomalies non ciblées en mode exploratoire, et les tickets créés, feedback n’avaient aucun retour, aucun échange comme si le travail ne servait à rien.

Où est le produit fini dans tout ça? Et surtout comment le testeur est il pris en compte dans tout ça?

Comme au début me diriez vous, hors charge. Et ça c’est dommageable car un salaire hors charge mais surtout un produit qui risque de ne pas voir le jour sans tests, faut l’expliquer…

1 « J'aime »
4

@Johann_HARGUINDEGUY Qu’entends-tu par maintenance et forfait ?

5

Comment mesures-tu la valeur produite sur ton projet ?

Pour calculer une vélocité qui ait du sens, il faut mettre en relation des mesures qui portent sur la même chose. Il faut donc inclure les mêmes activités en terme de calcul de temps passé qu’en terme de valeur produite.

En excluant l’activité de la testeuse de la mesure de vélocité, c’est une manière de dire que son activité ne produit pas de valeur. En cohérence, on considère que les programmeurs écrivent du code, et que cela suffit à fournir un incrément utilisable et capable de générer de la valeur. L’activité de la testeuse est donc inutile, on devrait donc retirer les tests qu’elle exécute de la DOD et supprimer son poste. Cette réflexion te semble absurde ? Ca ne l’est pas complètement si on se place dans un contexte de software à la demande où le client paye à la livraison du code source et que la recette est réalisée par un tiers. Car pour cette entreprise, le fait d’avoir livré un code, même non testé, permet de facturer et donc de gagner de l’argent (si c’est comme ça que cette entreprise mesure la valeur produite).

Si tu es dans un contexte où ces tests sont importants et nécessaires avant un déploiement, alors cette activité conditionne la mise à disposition du produit aux des utilisateurs, et donc sa capacité à générer de la valeur. Si tu mesure la valeur du produit de cette manière, alors l’activité de test devrait être incluse dans le calcul de vélocité. Il faut aussi voir ça comme une opportunité, car si l’activité de test n’est pas incluse dans le calcul de la vélocité, alors celui-ci ne peut pas être optimisé et donc on ne peut pas se poser des questions comme « cet objectif de sprint mérite-t-il d’y passer x k€ de test manuel ? », « Peut-on rendre les activités de test plus efficace ? » ou encore « quel serait le ROI d’un investissement dans l’automatisation des tests ? ».

Est-ce que ce n’est pas plutôt les calcul de vélocité actuels qui sont faussés car ne tenant pas compte d’une activité essentielle à la production d’un incrément utilisable et capable de produire de la valeur ?

Car corriger cela nécessite le courage d’admettre qu’on s’est trompés, et ça c’est parfois difficile.

3 « J'aime »
6

Je ne sais pas si ta question est vraiment de savoir si un QA est à considérer comme développeur scrum ou plutôt si le travail nécessaire pour la QA est à prendre en compte dans l’estimation globale de la charge de travail ?

Oui la QA est un développeur. Si on doit siloter les équipes on a pas fini :slight_smile:
Pour les équipes qui estiment, la logique est de parcourir la definition of done et d’estimer en prenant en compte tous les points qui y sont prévus. Je peux comprendre que si demain vous devez prendre en compte la charge de tests dans les estimations, le réflexe soit de passer le 5 à 8, le 8 à 13, le 3 à 5 etc. Mais à quoi ça sert ? A se gloser d’avoir 20% de vélocité en plus.

Moi je conseillerai de ne rien changer sur vos estimations mais qu’à chaque fois la question des tests (très souvent oubliés) soit posée clairement : qui fait les tests ? comment ? quel moment idéal (pour prioriser les tickets), si la personne habituelle est absente qui fait les tests ?
En répondant à ces questions vous adapterez votre capacité totale dans le but d’obtenir les meilleurs résultats et pas respecter une valeur de capacité idéale basée sur des jours . homme.

Il faut donc sûrement plus communiquer, collaborer, que vouloir modifier les processus = principe 1 du manifeste agile

Les individus et leurs interactions plus que les processus et les outils

2 « J'aime »
7

En ne mesurant que la complexité de la programmation on force implicitement les efforts de tests à être proportionnels à cette activité. Or parfois certains développements sont facile à programmer mais complexes à tester ou inversement. Dans ces cas là, ça devrait se refléter dans les estimations. La technique des ratios est uniquement bonne dans les chiffrages traditionnels pour mentir plus vite ! :wink:

Je pense qu’une confusions autour des silos vient du fait que le guide scrum parle d’équipe de développement dans un sens large (toute activité technique permettant de fabriquer un incrément) alors que le terme « développeur » est souvent limité au silo « programmation » dans l’imaginaire des gens, en particulier en ESN pour les gens qui ont l’expérience de gros projets avec une équipe QA séparée. Un peu comme le terme devops qui est souvent juste devenu le nouveau nom des équipes d’exploitation. On veut bien adopter l’agilité mais réorganiser les équipes y’a plus d’inertie …

De plus en plus j’essaye de parler de codage ou de programmation pour désigner l’activité consistant à écrire du code, car parler de développement est devenu ambigüe. Peut-être qu’on devrait parler d’équipe technique plutôt que d’équipe de développement d’ailleurs ?

1 « J'aime »
8

https://ss2ideal.fr/regie-forfait-tous-les-details/

Je me permets de citer le lien ci-dessus non pour fuir mais pour être plus explicite.

En tout cas assistance technique correspond à mon activité connue en régie en tant que consultant En en régie chez client.

Le forfait, je l’ai connu également et je confirme là on parlait bien de jouer homme et par conséquent, regard plus intrusif sur le travail opérationnel apporté par la personne, plus que le service rendu ou finalité apportée au produit.

Là, Scrum a eu toute son importance dans le projet réalisé car étude pour proposition au et ressentir quoi proposer en livrable futur.

9

Je confirme ts vision Adrien tenir compte la réalisation des tests (conception, optimisation et réalisation) dans la réalisation du produit et par définition DoD est un fait à prendre en compte pour valorisation du produit pour prendre en compte la charge.

Celà dit il arrive que recette faite par société externe et c’est là que je pense qu’elle rendre dans le contexte parties prenantes et donc sort De la DEV Team. Je suis curieux de suivre le débat en me sortant de l’histoire :slightly_smiling_face:

Bonne enquête.
Et encore bonne année

10

Un autre aspect qui me saute aux yeux c’est la structure de l’équipe. Ca donne l’impression qu’il y a une équipe mobile et une équipe web. Dans ce contexte, « l’ajout » de la testeuse vient effectivement bouleverser l’organisation à cause de la loi de Conway. Dans le fond, est-ce que vous faite un produit ou deux ?

1 « J'aime »
11

Pourrais-tu expliciter en quoi cette approche aiderait ?

12

Je me permets de répondre an partie à cette question sur le terme « developer » que je mets volontairement en anglais pour supprimer toute ambiguïté …
En effet, comme le mentionne scrum.org on parle ici plus d’apport de valeur.
Malheureusement, il n’est pas rare de distinguer dans une équipe scrum les UX, les UI, les codeurs, les QA, les BU, … ; cela est très apprécié des managers comptables car ils en tirent des indicateurs faux dès la première minute de leur vie.
Personnellement je ne parle jamais d’équipe de développeurs (mal traduit) mais je parle toujours et exclusivement d’équipe de réalisation qui est multi-compétente et pluridisciplinaire.
L’approche de Adrien est de dire que la question ne se pose pas … les tests inhérents aux récits sont dans l’équipe de réalisation. Je recommande de regarder la vidéo de ScrumLife sur la DoD.
Mais cela dépend de la DoD bien entendu.

  • Si la DoD se limite à la production du code de programmation (hé oui, j’ai vu des équipes par spécialité)
  • Si la DoD se termine par un récit qui fonctionne dans un environnement accessible par l’utilisateur (le but du sprint normalement) alors le récit est testé à fond avant de sortir du sprint.
    Depuis le début de l’industrie japonaise il est précisé qu’un test fait au plus tôt coûte moins cher que si c’est l’utilisateur (usager) qui le découvre …
1 « J'aime »
13

C’est gentil mais la question était seulement pour la personne à qui elle était adressée :sweat_smile:

14

Oups, désolé je ne suis pas encore très habitué aux fonctionnement du forum…

15

Un membre de l’équipe de développement Scrum n’est pas Un développeur au sens codeur/programmeur.

Un membre et l’équipe de développement est avec les autres membres, RESPONSABLE de l’increment.

Si c’est le cas de la testeuse , c’est une membre de l’équipe de développement.
Sinon elle est une source de feedback.

16

Pax hominibus bonae voluntatis :sweat_smile:

En anglais le guide parle de « development team », mais dans un contexte anglo-saxon le terme « development » fait plus facilement référence, dans l’imaginaire collectif, au « product management » qu’au développement logiciel. On a plutôt tendance à trouver même aujourd’hui des offres d’emploi pour des « programmers ».

En France, les ESN ont historiquement segmenté les profils des employés par fonction. C’était aussi lié avec une certain vision de la profession, où on a commencé à parler de « code factory » et où l’intégration continue s’appelait encore « industrialisation ». Dans ce contexte, le terme de « développeur » a généralement été simplement le nouveau terme à la mode pour désigner des programmeurs.

Même si c’est parfois de la mauvaise foi, on peut comprendre que, dans ce contexte, certains se soient mépris en lisant le guide scrum, dont la traduction parle « d’équipe de développement » en la comprenant comme l’équipe qui contient les « développeurs », les personnes qui codent. D’où le nombre d’équipes scrum qui vivent encore en silos:

  • un chef de projet scrum master pour piloter le projet
  • des analystes product owners pour dire aux devs quoi coder
  • des programmeurs développeurs pour coder
  • des graphistes UX designers pour que ça soit joli
  • des testeurs parce que les devs codent comme des cochons
  • des admins experts devops pour se démerder à faire fonctionner le truc

Avec du recul, et dans la lignée de DDD et de l’ubiquitous language, je me dis que peut-être on a un coup à jouer sur la sémantique. Peut-être qu’en appelant ça l’équipe technique, il serait plus naturel de faire comprendre qu’elle ne doit pas se résumer à ceux qui codent. Et a contrario, tant qu’on utilise le terme « équipe de développement » dans une acception large (incluant test, admin, design, …), on ne devrait pas parler de développement comme un synonyme de programmation mais de bien parler de chaque activité avec son nom.

Autre exemple de traduction foireuse à mon avis: le product owner. Fondamentalement un product owner c’est assez proche d’un chef de produit. Si on prend cette offre d’emploi pour un chef de produit par exemple, on voit qu’on a assez peu de modifications à faire.

1 « J'aime »
17

Merci beaucoup à tous·tes pour votre participation ! :pray:t5:

@Johann_HARGUINDEGUY : la testeuse ne veut pas se faire entendre. Elle, ainsi qu’une bonne partie de l’équipe, est très conservatrice, et a pris l’habitude de dire “non” à tout ce que je propose :wink:

C’est moi qui doit convaincre l’équipe, incluant la testeuse elle-même, que c’est plus logique de l’intégrer dans le calcul de la vélocité (qui a des impacts non seulement sur ce qu’on peut prévoir de réaliser en un Sprint, mais aussi sur les inévitables reportings que je suis censée faire pour le client -c’est pas Scrum, je sais, je sais! :smirk: -)

Pour répondre à ta supposition : nous faisons des développements à la demande, et de la maintenance, mais tu as raison, on est surtout dans de la maintenance : le produit est déjà largement développé.

@ArwynFr : je suis tout à fait d’accord avec toi. Hélas, je crains que les arguments financiers (ROI, etc.) n’atteignent pas du tout l’équipe, qui est complètement exclue de ces considérations.
C’est la P.O. qui pose ce regard là sur les activités de l’équipe. Même moi, S.M., je n’y suis pas mêlée, et je n’ai pas du tout la main sur l’estimation de la valeur de ce qu’on produit. (Pour l’anecdote, quand j’ai évoqué la question, et demandé quels étaient les KPI que le client regardait pour considérer la valeur délivrée, j’ai eu droit à des balbutiements parmi lesquels j’ai cru entendre « satisfaction client ». C’était malaisant, j’ai pas insisté! :smile:)

Et oui, bien d’accord, le calcul actuel de la vélocité est faussé, selon moi. C’est pour cela que j’aimerais le mettre à jour. Comme dit plus haut à Johann : je suis en présence d’une équipe très conservatrice qui dit “non” avant de réfléchir, et, dont certains membres, après avoir dit “non”, réfléchissent surtout à comment justifier leur “non”! :sweat_smile:
C’est pour ça que j’essaie de blinder mon argumentaire.

Et je devrais peut-être essayer d’adopter ta suggestion de remplacer le terme de DEV (que j’entends comme “totalité des personnes intervenant dans la fabrication du produit jusqu’à sa livraison”) par quelque chose de moins ambigü = “Technical team” ? (c’est une équipe internationale).
D’un autre côté, j’ai déjà bien ramé à faire de la pédago pour qu’iels veuillent bien entendre que « The DEVs », c’est elles/eux tous·tes ! Je crois que je vais encore continuer un peu sur ma lancée. Et si je vois que ça ne rentre pas, je changerai mon fusil d’épaule.

Concernant ta deuxième remarque sur la double équipe. Oui, c’est particulier, mais on développe/maintient une appli hybride web/mobile. C’est donc un produit décliné en deux app (une web, une mobile).
Je ne comprends pas ce qu’est la Loi de Conway dans ce contexte. Si tu as le courage de vulgariser?

J’irai aussi regarder la vidéo que @jplambert et @const ont faite sur le sujet : " Loi de Conway & management des organisations "

@nicobiot : :smile: ma question n’est pas du tout de savoir si la testeuse est une DEV. En Scrum, elle l’est. Et c’est ce que j’ai posé dès le début de mon post. (Mais j’imagine qu’il est trop long ou pas clair, parce que plusieurs interventions me font penser que j’ai laissé planer un doute là-dessus :yum:)

Merci d’avoir levé cette notion des estimations et de la DOD ! :pray:t5: :grinning:
Effectivement, actuellement les dév-codeurs (appelons-les) tiennent compte de tout le processus de production de la fonctionnalité dans leurs estimations. Y compris le temps de tests. CQFD ! Puisque l’estimation se fait en tenant compte du temps de tests, la capacité de production de l’équipe devrait être calculée avec le temps de travail de la testeuse.

Et je trouve ton conseil très intéressant et de bon sens, concernant l’accent à mettre sur une estimation fine du temps réel à passer en tests pour chaque ticket estimé. J’aimerais bien le mettre en pratique, mais ça induirait d’impliquer davantage la testeuse dans les sessions d’estimations. Or, je suis (quasi) certaine que la testeuse n’a aucunement envie d’être davantage impliquée (d’une manière générale, l’équipe ne souhaite pas changer ses habitudes).
Comme ça avait été judicieusement et autrement dit dans un autre fil : si l’équipe se sent bien comme ça, que le client est satisfait de ce qu’on lui délivre, la S.M. devrait songer à s’économiser ! :stuck_out_tongue_closed_eyes:
Je vais essayer d’aborder discrètement la question quand même, à l’occasion, en Sprint planning, oui.

T’façon, ça sent la fin de projet, là :wink:

Bonne journée à tous·tes, et encore merci pour votre aide ! :pray:t5: :wave:t5:

18

Alors par contre je viens de tiquer.

Déjà, ça vaut le coût, je pense, de rappeler que Scrum ne prévoit pas d’estimation ni de calcul de vélocité : ces termes n’apparaissent pas dans le guide.

La vélocité ce n’est pas la quantité de travail effectué (= consommé) mais la valeur ajoutée (= produit) par le sprint divisé par le temps pour comparer des sprints de durée différente. Elle se mesure par la somme de points de valeur associé aux US terminées pendant le sprint. Comparer la vélocité d’un sprint à l’autre permet d’identifier certains problèmes comme la désorganisation de l’équipe, le choix de story à faible valeur ajoutée, ou le fait d’avoir attaqué un développement plus complexe que ce qu’on avait prévu au départ. Ce n’est pas un indicateur de performance car des explications autres peuvent expliquer les fluctuations.

La consommation, elle, se mesure au niveau du sprint sans descendre au niveau des US. On peut le faire sans fliquer l’équipe par un simple calcul: Nb ETP x CJM x durée du sprint. Et là, il faut bien tenir compte du temps passé par la testeuse, car j’imagine qu’elle doit bien imputer sur le projet. Sinon elle ne serait pas payée. Comparer la valeur produite et le consommé du sprint permet de mesurer un ROI pour démontrer la rentabilité de l’équipe. On a claqué 30k€ dans un sprint, si ça rapport 8k€/semaine c’est vite rentabilisé. Si on a passé 90 k€ dans un sprint pour rapporter 1k€/an, vous allez vite vous ruiner.

Le loi de Conway c’est l’idée que si l’organisation de l’équipe n’est pas alignée sur l’architecture technique, alors tu vas galérer jusqu’à adopter une architecture technique alignée sur la structure organisationnelle (et c’est toujours la structure organisationnelle qui gagne).

J’en parle un peu plus dans ce sujet de discussion :

19

Bonjour @Charlotte,

Scrum indique « Les Scrum Teams sont pluridisciplinaires, leurs membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Elles sont également autogérées, elles décident en interne qui fait quoi, quand et comment. »

Votre équipe se focalise trop sur la vélocité. Elle ne prend pas en compte votre capacité à fournir un incrément de valeurs.

Tu peux poser comme question :

  • Que se passerait-il si la testeuse était assignée à une autre équipe ?
  • En tant qu’équipe auto-gérée, sommes-nous en capacité de réduire nos dépendances avec des ressources hors de l’équipe ?
    …

En tant que SM, tu devrais peut-être approfondir le modèle souhaité par ton organisation et en parler à un coach Agile.

20

En apparte ne tenant peut être pas compte du sujet initial mais merci @Adrien d’avoir fait renaître cette vision devenue ambition : la valeur produit apportée dans le sprint. permettant de calculer par comparaison l’évolution globale apportée au produit.

Ce cadre de travail m’a donné une envie d’accompagner dans ce sens lors de ma première mission réalisée en Scrum.

1 « J'aime »