Comment supprimer les barrières entre développement et assurance qualité sur un projet agile? [fermé]

Question

Je postule depuis quelques mois déjà à agile sur mon projet. Cependant, nous constatons un problème constant avec nos burndowns d'itération. Nous n'atteignons pas zéro à chaque itération.

Les tâches restantes sont des tâches QA. Des choses comme écrire des tests, des tests, etc.

Désormais, il existe une certaine résistance organisationnelle à l'égard de "l'équipe interfonctionnelle". idée d'agile. Les développeurs développent pour des projets uniques mais les testeurs sont partagés pour plusieurs projets. Ce qui est tout à fait contraire à l'idée agile selon laquelle Dev et QA travaillent ensemble.

Le ralentissement de notre testeur est partagé entre tant d’autres projets. Les développeurs essaient de trouver le moins de mou possible, mais certaines tâches ne sont toujours pas terminées.

D'après ce que je vois, je peux faire deux choses:

1. Persuader l'organisation de se déplacer vers "chaque projet ayant un Personne QA dédiée "
2. Modifier ma définition de "Terminé" à n'inclut pas les travaux d'assurance qualité / tests. Des choses serait toujours testé par l'unité.

Je préférerais de loin éviter de faire le n ° 2, car j'apprécie la collaboration en matière de tests que nous effectuons.

Quels conseils donnes-tu pour ma situation difficile?

Answer 1

C’est une situation difficile et malheureusement, de nombreuses entreprises qui tentent de suivre Agile ne la reconnaissent pas. Vous n'avez pas besoin d'un responsable QA dédié - même avec des ressources Agiles, il peut être divisé en différentes tâches. Vous devez inclure votre assurance qualité dans le suivi de vos progrès.

Oui, vos progrès seront plus lents. Il y a une bonne raison à cela (vous n'avez pas assez de ressources d'assurance qualité) et vous devriez l'expliquer à la direction de votre organisation avec les chiffres en main. Cela vous aidera à les persuader qu'un changement doit se produire.

Vous pouvez également passer à des tests plus automatisés et utiliser vos développeurs pour aider les testeurs avec l’automatisation des tests. Cela répartira la charge de manière plus uniforme et améliorera la qualité de l'assurance qualité de votre projet

Answer 2

Je ne pense pas que vous puissiez appeler ce que vous faites agile à moins que tout le monde ne le comprenne. Amenez le testeur à s’asseoir physiquement près des développeurs (au moins pendant le temps que le testeur exécute des tâches pour son projet, telles que la création de plans de test), cela peut améliorer la communication et obtenir l’assurance qualité pour y participer.

Answer 3

Pour que cela fonctionne, vous devez faire en sorte que les QA consacrent suffisamment de temps au projet. Vous devrez peut-être travailler avec leur direction afin de leur laisser un peu de temps pour travailler sur votre projet. De cette façon, vous seriez en mesure de planifier leur temps et de savoir exactement combien de travail vos développeurs peuvent effectuer et que l'équipe d'assurance qualité aura le temps de tester. Cela peut nécessiter une réduction du développement afin de compenser la réduction de l'assistance fournie par l'assurance qualité.

Vous ne précisez pas combien de vos tests sont automatisés. Vous pourrez peut-être augmenter l'automatisation des tests afin de réduire le temps nécessaire à l'équipe d'assurance qualité pour certifier le projet. Vous pourriez utiliser une partie de votre temps de développement pour préparer les tests d’assurance-qualité à l’équipe. Pas optimal, mais cela pourrait aider.

Answer 4

Je pense que l’assurance qualité a bien plus à offrir en environnement agile qu’un simple travail de test. Si le contrôle qualité est suffisamment au courant du flux de travail et de ses différentes branches, il peut être utile que le conducteur conduise le reste du processus Scrum. Un contrôle qualité peut être demandé aux développeurs pour concevoir les flux de travail logiques qui vont finalement conduire les cas de test. De cette façon, on peut éliminer beaucoup d'erreurs liées à la conception et au flux de travail au cours du processus de développement avant qu'elles ne pénètrent dans l'environnement d'assurance qualité.

Answer 5

Vous pouvez considérer l’assurance qualité comme le client des développeurs. Ainsi, lorsque les développeurs lancent une itération au contrôle qualité, l'itération est terminée.

Les commentaires du client (bogues à corriger) peuvent être intégrés au travail à effectuer pour la prochaine itération.

Answer 6

À court terme, cessez d'utiliser les ressources d'assurance qualité qui ne peuvent pas s'intégrer à votre processus et prenez en charge ces tâches avec celles pouvant être dédiées à la demande. Je me rends compte que ce n'est pas idéal, mais il existe une situation sous-optimale dans laquelle vous avez une structure organisationnelle qui ne correspond pas à vos processus. Vous constaterez peut-être que cela fonctionnera bien (et vous renseigner sur les tests en cours de processus).

À long terme, vos options sont

• trouver un moyen pour que cela fonctionne avec la structure / processus organisationnel donné
• modifier la structure organisationnelle pour l'adapter au processus
• chagne le processus de développement doit être adapté à l'organisation