Pourquoi les testeurs sont externes à l’équipe ? Comment c’est organisé ? @Hanh_NGUYEN
On a un testeur chez nous qui est vraiment intégré à l’équipe (travaille sur les critères d’acceptation, check en intégration avec les développeurs qu’il n’y a pas d’oubli, modification des critères éventuellement en collaboration avec Po et dev)
Bonjour,
J’ai l’impression que la question au départ c’est pas forcement de savoir si on a tout terminé ou pas mais plutôt à quel moment je place mon DONE dans mon sprint.
Si je ne peux pas tester mes tâches (us ou autres) pendant mon sprint de manière efficace comment faire pour m’assurer qu’elles sont vraiment terminées ?
Est ce que justement, mon état DONE ne vient pas quand on a fait les tests nécessaires ? Dans ce cas quels tests implémenter dans la phase de réalisation de l’incrément pour s’assurer que nos US ou autre tâches sont bien terminées, qu’elles peuvent être livrées ?
Peut-être prévoir de déplacer le DONE après les tests de l’équipe en charge des tests ? (si j’ai bien compris une équipe externe, ou les faire intervenir plus tôt dans le déroulé du sprint ?) ou encore comprendre quels genre de retours sont adressés pour mettre le curseur d’amélioration sur des tests plus pertinents pendant le sprint ?
C’est principalement géré par la rigueur des experts.
Ressources
Les retours de bugs sont dus au syndrome de l’estimation précise. Et la volonté de respecter cette estimation.
En pratique, il est impossible de tout prévoir. Par conséquent, quand un imprévu survient. Il ajoute une pression au développeur. Soit, il est transparent et il en parle tout de suite. Soit cet imprévu est ignoré, car il va empêcher le respect de l’estimation.
Les développeurs doivent se comporter en tant que professionnels, voici quelques points à respecter :
Ressources
Responsabiliser les développeurs, c’est déjà commencé par les traiter comme des experts, des professionnels.
Leur donner l’intention au lieu de pré-mâché le travail à réaliser ; la spec.
Dans cet exemple, tu ne donnes pas l’intention. Qui est par exemple de :
Ressources
Que d"échanges !!!
En tous cas, voici notre vidéo sur le sujet : User Story non terminé : on fait quoi de son estimation en Story Points ? Scrum Life répond ! - YouTube
Hum… ça veux dire quoi se comporter en tant que professionnels exactement ?
Selon quels critères ? Peut-être que la DOR de l’équipe demande ce niveau de précision ?
Personnellement, je ne le sais pas. Si ça ne convient plus à l’équipe, c’est à l’équipe de changer son fusil d’épaule.
Le premier n’est pas une intention, c’est un critère d’acceptation.
Pour tous ces points, un use-case fait amplement le job. On arrive rarement à ce degré de granularité avec des « intentions », quoi que cela puisse vouloir dire.
J’ai l’impression qu’en partant du sujet de cette discussion qui était Gestion des reports d’US non terminées d’un sprint à l’autre, on finit par parler de bugs qui surgissent en prod après avoir livré une fonctionnalité (et qu’on considère donc que l’US n’est pas terminée pour cela).
Il est impossible de toute manière d’éviter les bugs et que s’il y a un cas qui n’était pas prévu, la réaction la plus souvent rencontrée est qu’il y a un bug et qu’on recherche le fautif.
L’essentiel est d’identifier le cas qui ne fonctionne pas et créer un ticket pour gérer ce cas non prévu la première fois afin d’améliorer le système.
Qui est responsable du bug n’est pas important… le PO car il n’a pas prévu ce cas, pas bien décrit l’US, la QA car les tests d’acceptations n’ont pas pensé à ce cas-là, le dev car il aurait dû mieux contrôler son champ de saisie… ?
Et pour en revenir à l’US de base, elle est clôturée et on crée un nouveau ticket, qu’on priorise selon la gravité du problème, qui ira dans le prochain sprint ou fera la queue dans le backlog derrière des tickets plus prioritaires.
L’équipe gagnera en expérience et s’améliorera d’elle-même au fil de sprints et saura détecter plus tôt ce genre de risques, que ce soit le PO, le dev, la QA, …
Pour en revenir au sujet de la discussion, je vois souvent que systématiquement à la fin du sprint tous les tickets commencés ainsi que ceux mis dans le sprint non abordés sont reportés au sprint suivant sans se soucier de leur pertinence et des autres tickets qui attendaient leur tour.
Il faut vraiment partir d’une liste vide et se poser les bonnes questions pour le but à atteindre à chaque nouveau sprint et envisager tous les tickets comme nouveaux candidats au prochain sprint à planifier.
C’est d’abord être responsable.
Le résultat ne doit pas nuire à autrui. Il serait prétentieux de faire référence au serment d’Hippocrate prêté par les médecins.
Ensuite, c’est l’honnêteté, c’est la partie la plus difficile. En commençant par l’honnêteté envers soi-même. À la fin d’une journée de travail on doit pouvoir se regarder dans le miroir et se dire : « J’ai fait du bon travail, aujourd’hui. »
Ressources
En plus de celles précédemment partagées.
Le partage de l’intention est seulement une manière parmi d’autres de responsabiliser les développeurs.
Je suis d’accord que la manière choisi doit dépendre du contexte ; du niveau d’expertise du développeur.
Comment les erreurs sont accueillies ?
Dans tous les cas, on ne pointe jamais du doigt un seul développeur. C’est l’équipe toute entière qui est responsable.
Alors, oui, être responsable, c’est bien ce dont tu parles effectivement. Par contre, être professionnel, ça s’arrête pour moi à être payé pour rendre un service. La responsabilité à que très peu à voir avec ça, à moins d’avoir une vision très romantique de la chose.
Oui, mais le service doit être rendu.
Un Dev doit avoir la présence d’esprit de mettre en place des contrôles de forme basiques sur des zones de formulaire, email ou numéro de tel en cas d’absence de consignes particulières et pas seulement se réfugier « ah mais c’est pas mentionné dans les conditions d’acceptations »
Oui, mais ça c’est que dû à une obligation de résultat. Rien à voir avec des impératifs moraux.
Jusqu’à maintenant, nous récupérons les tickets « done » et les remettre dans le circuit pour corriger les bugs, mais le fait de créer un nouveau ticket est une super idée. Merci pour ta remarque.
Nous y sommes.
Est-ce qu’un chirurgien ayant une obligation de résultat ne va pas se laver les mains avant d’entrer dans la salle d’opération ? Ou bien, laisser une éponge dans le corps de son patient ?
C’est toi qui est sur la table d’opération.
Qu’en penses-tu ? Aurais-tu confiance en ce chirurgien ?
En parlant de responsabilité, c’est aussi celle morale.
Si le code n’est pas prêt, un professionnel a la responsabilité de dire « non ». De ne pas livrer juste pour respecter une deadlines.
Ton entreprise vient de perdre 1M€ à cause d’une négligence d’un développeur pour respecter la deadline il n’a pas testé.
Peut-on avoir confiance en lui en tant que professionnel ?
La médecine est tenu a des obligations de moyens ^^’
Le risque avec les tickets qui ont été acceptés (différent de done) est que tu risques de reboucler longtemps sur des tickets. L’idée étant ici de réagir par rapport à un problème qui arrive en prod, et donc par rapport à une livraison qui a eu lieu, ton sprint est terminé, les tickets, normalement, on ne les rouvre pas…
Le statut done correspond plutôt à un statut (dépend de ta définition du DOD) qui peut être encore en cours de sprint, donc dans ce cas, effectivement, tu peux repasser ton ticket à un état précédent…
Après, c’est une façon de fonctionner, tant que l’équipe est alignée, ça peut fonctionner.
La difficulté lorsque tu réouvres un ticket est plus l’impact sur la vélocité car l’estimation du ticket initial par rapport à ce que tu vas faire pour le corriger n’a plus trop de rapport…
Ou mieux: un bug, ça se corrige immédiatement. De faire de l’inventaire en rajoutant un ticket pour gérer le schmilblik, c’est pas ce qu’on a connu de plus efficace.
Après, si le problème est beaucoup trop gros, oui, un ticket pourquoi pas, mais c’est sûrement parce que le problème est plus structurel qu’il en a l’air à priori.
l’idée du ticket est surtout d’avoir de la traçabilité par rapport à une livraison et une version… la taille du bug importe peu par rapport à cela.
C’est plut pour la partie BL que c’est utile en fait et pouvoir communiquer en toute transparence.
Est-ce qu’il y a besoin de tracer quelque chose qui n’est pas censé être là à la base ? Qu’est ce que ça donne comme information en plus ?
Qu’est ce que foutais le reste de l’équipe à ce moment là ? A moins que la personne est tout fait d’une traite et soit arrivé en prod sans review, sans pipeline, et ait bypass tout le process, je vois pas comment tu peux tenir rigueur à une seule personne sur le sujet.
En ce qui nous concerne, 90% du temps nous avons que des petits oublis (genre un commentaire ne peut pas avoir que des espaces, il faut avoir au moins deux caractères après le. Dans une adresse email etc). C’est vraiment très instructif pour moi de voir plusieurs façons de traiter et les avantages inconvénients de chacune
Je suis d’accord avec ce point de vue.
Mais lorsqu’un ticket arrive du support car il y a un problème en prod, ça permet de faire le lien afin de clôturer le ticket du support lorsque l’équipe l’a traité.
Mais on est sur un autre suivi qui est plus sur la maintenance du produit… l’équipe gère les deux, les évolutions et les bugs donc les tickets n’arrivent pas que du côté PO… et le suivi doit pouvoir être fait sur les deux.
Mais à plus long terme, aucun intérêt effectivement à part justifier que l’équipe a besoin de bande passante pour traiter les bugs en plus des évols.