Dans Scrum, qui vérifie «Terminé»?

Je suis responsable QA / Test dans mon organisation et jusqu'à aujourd'hui j'ai vérifié la qualité du logiciel (tests écrits et exécutés et bugs corrigés). Qui vérifiera cela dans Scrum? Comment puis-je savoir que l'équipe a écrit et exécuté tous les bons tests? D'un autre côté, je crains que si je continue à faire la vérification, l'équipe ne se sentira pas suffisamment responsabilisée. Mais j'ai besoin d'un processus de vérification que "Terminé" est bien "Terminé". Que suggérez-vous?

Une idée majeure dans Scrum est que l'équipe devrait se mettre d'accord sur une "définition du fait". Idéalement, cela ressemble à un ensemble de critères objectifs que n'importe qui peut vérifier en parcourant une liste de contrôle.

Mais pour réduire le risque que quelque chose se glisse, il est parfaitement logique d'avoir une règle selon laquelle la vérification du «fait» doit être effectuée par une personne autre que la personne qui a implémenté un élément - ou un responsable de l'assurance qualité comme vous (mais cela risque de vous faire un goulot d'étranglement).

En cas de doute, discutez avec l'équipe et le Scrum Master et décidez ensemble.

Je pense qu'il y a une hypothèse implicite dans la question. Il existe une différence entre «accepté», lorsqu'un propriétaire de produit déclare qu'un élément ou une tâche de backlog a satisfait le propriétaire de produit, et «terminé», ce qui signifie que tout le travail associé à l'élément de backlog est terminé.

Cependant, il y a régulièrement plus d'une tâche que celle visible par le propriétaire du produit, généralement quelqu'un de semi-technique au mieux, y compris les tests (automatisés et manuels), la documentation et la révision. Le Product Owner est rarement en mesure de connaître les aspects techniques, et encore moins s'ils sont complétés.

Par conséquent, c'est finalement à l'équipe de déterminer ce que signifie «fait». L'organisation peut avoir des normes et différentes parties prenantes auront leurs propres exigences. Le Scrum Master ou les managers concernés sont généralement responsables de la compilation et de l'application de la liste.

Dans votre exemple, en tant que responsable QA / Test, c'est vous qui dites si les tests sont terminés. Cependant, vous n'êtes peut-être pas la meilleure personne pour dire si le code a été révisé, si les exigences de sécurité sont remplies, si le produit est internationalisé, si la documentation est complète ou quoi que ce soit d'autre "fait".

Le seul concept de «fait» est de savoir si une histoire dans son ensemble est terminée ou non. L'équipe aurait dû créer une définition du fait qui indique quand ils sentent qu'une histoire est terminée ou non. Cela comprend généralement des éléments tels que "le code a été revu", "les tests nocturnes ont été exécutés", "tous les critères d'acceptation ont été remplis", etc. attendu d'eux pour terminer une histoire.

Pendant un sprint, si vous essayez de déterminer si l'un de ces éléments dans la définition de fait a été accompli, demandez simplement. Scrum et agile, c'est une communication ouverte. Si vous faites partie de l'équipe, demandez à vos coéquipiers si quelqu'un a écrit les tests, ou les a exécutés, ou a créé le travail de nuit, etc. Si vous êtes un intervenant, demandez au maître de mêlée.

Si vous vous asseyez en dehors de l'équipe mais que vous devez toujours réviser les tests, demandez à l'équipe d'ajouter "les tests doivent être examinés par l'utilisateur user3251930" dans le cadre de la définition de terminé. Si c'est ce qu'il faut pour qu'une histoire soit faite, soyez honnête à ce sujet et intégrez-la au processus. L'intérêt de la "définition du fait" est que l'équipe puisse savoir avec certitude qu'elle a fait ce qui est nécessaire pour fournir un logiciel de qualité. S'il s'agit en partie d'un examen externe, qu'il en soit ainsi.

En fin de compte, c'est le propriétaire du produit qui signe une histoire particulière, donc à la fin de la journée, il ou elle a la décision finale de savoir si une histoire dans son ensemble est terminée ou non.

Première question que vous devez vous poser

Êtes-vous le Scrum Master ? si oui.

En Scrum, les processus sont contrôlés et gérés par le Scrum Master.

Comment faites-vous:

Dans la phase d'exigence, vous pouvez utiliser les user stories pour chacune d'entre elles, il existe un test qui doit être vérifié.

Dans chaque Sprint Les éléments de travail sont extraits du carnet de produits et dirigés par le propriétaire du produit. Chacun d'eux aura également des critères de vérification.

Maintenant, dans Scrum, les exigences ne changent pas après le démarrage du sprint. À la fin du sprint, vous pouvez analyser la vérification en fonction des critères de chaque élément effectué.

Si son fait ne peut être trouvé que par la réponse du propriétaire du produit.

Rappelez-vous dans Agile que vous "Embrassez le changement" même tard dans la phase de développement

L'équipe décide. J'utilise une liste de contrôle pour ce qui est considéré comme «terminé». Qu'est-ce qui est «fait» par histoire, par sprint, par version.

Comme d'autres l'ont mentionné, la décision revient en définitive au propriétaire du produit.

Convenez que c'est quelque chose que l'équipe de développement / test doit définir, en fonction de vos propres pratiques. Certains projets sont si agiles qu'ils sont prêts à risquer de publier des bogues dans leur flux alpha; certains considèrent tout bogue qui sort du groupe de développement comme un échec du processus.

Le projet sur lequel je travaille nécessite un examen par les pairs des modifications du code et exige que la personne qui a écrit le code fournisse / mette à jour des tests de régression ou explique pourquoi il n'est pas possible de le faire. (Ils et leurs examinateurs doivent également certifier qu'ils ont vérifié les mauvaises pratiques connues. Nous sommes généralement beaucoup plus heureux s'ils peuvent montrer qu'ils ont exécuté la suite de tests complète et ont obtenu un résultat net (ou un module propre connu). problèmes ouverts, au moins) Le code doit alors survivre à des tests unitaires et fonctionnels automatisés intensifs sur plusieurs plates-formes pour démontrer qu'il ne provoque aucune régression contre ceux-ci, et il est en outre vérifié pour les antipatterns communs par un système d'analyse de code automatisé. l'acceptons-nous ensuite dans le flux de développement principal et marquons l'élément de travail comme terminé.

Cela ne garantit évidemment pas que personne ne trouve une nouvelle façon d'échouer, mais cela réduit le risque à un niveau acceptable sans entraver considérablement la vitesse de développement.