Aidez-moi à comprendre le fonctionnement de l'assurance qualité dans Scrum.

Question

Apparemment, nous utilisons la méthodologie de développement Scrum. Voici comment ça se passe en général :

Les développeurs se démènent pour essayer d'accomplir leurs tâches. En général, les tâches prennent la majeure partie du sprint pour être achevées. L'AQ harcèle les développeurs pour qu'ils publient quelque chose qu'ils puissent tester, les développeurs finissent par envoyer un code bogué à l'AQ un jour ou deux avant la fin du sprint et passent le reste du temps à corriger les bogues que l'AQ trouve. L'AQ ne peut jamais terminer les tâches à temps, les sprints sont rarement publiables à temps, et Dev et l'AQ passent quelques jours misérables à la fin du sprint.

Comment scrum est censé fonctionner lorsque des tâches de développement publiables occupent la majeure partie du sprint ?

Merci à tous pour votre participation à la discussion. Comme il s'agit d'une question assez ouverte, il ne semble pas y avoir de "réponse" unique - il y a beaucoup de bonnes suggestions ci-dessous. Je vais tenter de résumer certains des points que j'ai retenus et d'apporter quelques clarifications.

(BTW - Est-ce le meilleur endroit pour poser cette question ou aurais-je dû la poser dans une "réponse" ?)

Points à méditer/agir :

• Il faut veiller à ce que les tâches des développeurs soient aussi réduites (granulaires) que possible.
• La durée du sprint doit être basée sur la durée moyenne des tâches (par exemple, un sprint avec des tâches d'une semaine doit durer au moins 4 semaines).
• L'équipe (y compris l'AQ) doit s'efforcer de devenir plus précise dans ses estimations.
• Envisagez de réaliser un sprint d'assurance qualité distinct, en parallèle mais décalé, si cela convient le mieux à l'équipe.
• Les tests unitaires !

Answer 1

Divisez les tâches en tâches plus petites.

De même, le service d'assurance qualité peut créer des cas de test pour que le service de développement les teste.

Answer 2

Une idée à envisager est de faire travailler l'assurance qualité une itération après le développement principal. Cela fonctionne bien dans notre environnement.

Answer 3

Je dirais ici que la taille unique ne convient pas à tous. Chaque équipe traite l'AQ différemment. Cela dépend beaucoup du projet sur lequel vous travaillez, qu'il s'agisse d'un petit ou d'un grand projet. A-t-il besoin de tests de régression, d'acceptation par l'utilisateur et de tests exploratoires approfondis ou avez-vous quelques scénarios à tester ? Permettez-moi de répéter qu'en Agile, les généralistes sont préférés aux spécialistes. Pourquoi ? Parce qu'il y a un moment pendant le projet où vous n'avez rien à tester, donc à ce moment-là vous pouvez faire autre chose. Il se peut aussi que vous fassiez des tests même si vous êtes un programmeur pur et dur.

Comment le gérer ? Nous avons un sprint régulier de 2 semaines. Les tests commencent après une semaine sur les tâches effectuées par les développeurs pendant la semaine. Les testeurs continuent à ajouter des problèmes dans notre Issue Tracker et les développeurs qui ont terminé leurs tâches de sprint commencent à corriger ces bogues. A la fin du sprint, nous avons pratiquement terminé notre tâche et tous les bugs critiques et majeurs.

Alors, que fait le testeur deux dans la première semaine du sprint ?

Eh bien, il y a toujours des choses à tester. Nous avons des tâches de test dans le backlog, qui peuvent inclure des tests exploratoires. Beaucoup de gens n'apprécient pas les tests exploratoires, mais ils sont extrêmement importants pour construire des produits de qualité. Les bons testeurs créent des tâches pour eux-mêmes et trouvent les possibilités où les choses vont mal et les testent.

J'espère que cela vous aidera !