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

Mon avis est que vous avez un problème d'estimation. Il semble que le temps nécessaire pour tester chaque fonctionnalité soit absent, et que seule la partie construction soit prise en compte lors de la planification du sprint.

Je ne dis pas que c'est un problème facile à résoudre, car il est plus courant qu'autre chose. Mais les choses qui pourraient aider sont :

• Considérez l'AQ comme un membre de l'équipe de développement et intégrez-le plus étroitement dans la planification et l'estimation des sprint.

• Les "tâches de développement libérables" ne doivent pas occuper la majeure partie du sprint. Ce sont les fonctionnalités complètes qui doivent l'être. Essayez de recueillir des données sur le temps de développement par rapport au temps d'assurance qualité pour chaque type de tâche et utilisez ces données pour estimer les sprints futurs.

• Vous devrez peut-être revoir votre backlog pour voir si vous avez des fonctionnalités à très gros grain. Essayez de les diviser en tâches plus petites qui peuvent être facilement estimées et testées.

En résumé, il semble que votre équipe n'ait pas trouvé sa vélocité réelle car certaines tâches ne sont pas prises en compte lors de l'estimation et de la planification du sprint.

Mais en fin de compte, l'imprécision des estimations est un problème difficile de gestion de projet que l'on retrouve dans les projets basés sur la méthode agile ou sur la méthode de la cascade. Bonne chance.

Answer 2

J'interviens un peu tard dans la soirée, mais voici mon point de vue sur ce que vous avez écrit.

Or, Scrum est une méthodologie de gestion de projet, et non de développement. Mais il est essentiel, à mon avis, de mettre en place un processus de développement. Sans cela, vous passez la majorité de votre temps à Réagissant plutôt que de construire.

Je suis un gars qui teste d'abord. Dans mon processus de développement, je construis d'abord des tests pour faire respecter les exigences et les décisions de conception. Comment votre l'équipe qui les applique ? Le point que j'essaie de faire ici est que vous ne pouvez tout simplement pas "jeter des trucs par-dessus la clôture" et s'attendre à tout sauf à l'échec. Cet échec sera le fait de l'équipe de test (qui ne testera pas très bien et laissera donc passer les problèmes) ou des développeurs (qui ne construiront pas le produit qui résout le problème). Je ne dis pas que vous doit écrivez d'abord des tests - je ne suis pas un militant ou un évangéliste des tests d'abord - mais je dis qu'il faut doit disposer d'un processus permettant de produire un code de qualité, testé et prêt à être mis en production lorsque vous arrivez à la fin d'une itération.

J'ai été là où vous êtes dans cette méthodologie de développement que j'appelle le Méthode de la spirale de la mort . J'ai construit des logiciels pour le gouvernement (américain) pendant des années selon un tel modèle. Cela ne fonctionne pas bien, cela coûte BEAUCOUP d'argent, cela produit du code en retard, du code de mauvaise qualité, et cela ne fait rien pour le moral. Vous ne pouvez pas avancer quand vous passez tout votre temps à corriger des bogues que vous auriez pu éviter de créer en premier lieu. J'étais absolument abattu par cette affaire.

Vous ne voulez pas que l'AQ trouve vos problèmes. Vous voulez les mettre au chômage, vraiment. Mon but est de rendre le service d'assurance qualité stupéfait parce que tout fonctionne. D'accord, c'est un objectif. En pratique, ils trouveront des trucs. Je ne suis pas surhumain. Je fais des erreurs.

Retour à la programmation...

Dans mon travail actuel, nous faisons du Scrum, mais nous ne l'appelons pas ainsi. Nous n'aimons pas les étiquettes, mais nous voulons produire un code de qualité dans les délais. Tout le monde est à bord. Nous disons à l'AQ ce que nous allons avoir de prêt à tester et quand. S'ils viennent frapper à la porte deux semaines plus tôt, ils peuvent parler à la main. Tout le monde connaît le calendrier, tout le monde sait ce que contiendra la version et tout le monde sait que le produit doit fonctionner comme prévu avant d'être envoyé au service d'assurance qualité. Alors qu'est-ce que cela signifie ? Vous dites au service d'assurance qualité "ne vous embêtez pas à tester XYZ - il est cassé et ne sera pas corrigé avant la version C" et s'ils vont le tester, vous leur renvoyez à cette déclaration et leur dites de ne pas perdre leur temps. C'est peut-être dur, mais c'est parfois nécessaire. Il ne s'agit pas d'être impoli, mais chacun doit connaître "les règles" et savoir ce qui doit être testé et ce qui est un "problème connu".

Votre direction doit être d'accord. S'ils ne le sont pas, vous aurez des problèmes. L'AQ ne peut pas diriger le spectacle et le groupe de développement ne peut pas le diriger complètement non plus. Tous les groupes (même s'il ne s'agit que d'une personne par groupe ou d'une personne qui porte plusieurs casquettes) doivent être sur la même longueur d'onde : le client, l'équipe de test, les développeurs, la direction et tous les autres. Plus de la moitié de la bataille est la communication, typiquement.

Peut-être que vous en faites plus que ce que vous pouvez accomplir pendant un sprint. C'est peut-être le cas. Mais pourquoi faites-vous cela ? Pour respecter un calendrier ? Si c'est le cas, c'est là que la direction doit intervenir et résoudre le problème. Si vous donnez à l'AQ un code bogué, attendez-vous à ce qu'il le rejette. Il vaut mieux leur donner 3 choses qui fonctionnent que 8 choses qui ne sont pas terminées. L'objectif est de produire un ensemble de fonctionnalités qui sont complètement mises en œuvre à chaque itération, et non pas d'assembler un tas de choses à moitié faites.

J'espère que ce message est reçu comme il doit l'être - comme un encouragement et non comme une diatribe. Comme je l'ai mentionné, j'ai été là où vous êtes et ce n'est pas drôle. Mais il y a de l'espoir. Vous pouvez renverser la situation en un sprint, voire deux. Peut-être n'ajoutez-vous aucune nouvelle fonctionnalité lors du prochain sprint et réparez-vous simplement ce qui est cassé. C'est à vous d'en décider en équipe.

Encore une petite astuce pour écrire du code de test : Je me suis trouvé beaucoup plus détendu et beaucoup plus confiant dans mon produit depuis que j'ai adopté l'approche "écrire les tests d'abord". Lorsque tous mes tests réussissent, j'ai un niveau de confiance que je ne pouvais tout simplement pas avoir sans eux.

Bonne chance !

Answer 3

Il me semble qu'il y a un problème d'allocation des ressources dans les scénarios exigeant des tests fonctionnels d'AQ pour qu'une fonctionnalité donnée soit "faite" dans un sprint. Personne ne semble aborder ce sujet dans les discussions sur l'assurance qualité que j'ai trouvées jusqu'à présent, et la question originale est presque la même (du moins, elle est liée), donc je voulais offrir une réponse partielle et étendre un peu la question.

Pour ce qui est de la question initiale spécifique sur les tâches de développement qui prennent tout le sprint, il semble que le conseil général d'alléger ces tâches ait du sens si les tests fonctionnels par l'AQ font partie de votre définition de " fait ". Dans le cas d'un sprint de 4 semaines, s'il faut environ une semaine pour tester plusieurs fonctionnalités de plusieurs développeurs, il semble que les tâches de développement prennent environ 3 semaines, suivies d'une semaine de retard pour les tâches de test qui prennent environ 1 semaine. L'AQ commencerait bien sûr dès que possible, mais nous reconnaissons qu'il y aura un décalage d'environ une semaine par rapport à la dernière série de fonctionnalités livrées. Je réalise que nous voulons que les fonctionnalités soient transmises à l'AQ le plus rapidement possible afin d'éviter ce scénario de chute d'eau au cours d'un sprint, mais la réalité est que le développement ne peut généralement pas transmettre à l'AQ des fonctionnalités réelles et valables avant 1 à 3 semaines de sprint. Bien sûr, il y a des morceaux ici et là, mais le gros du travail consiste en 2 à 3 semaines de développement, puis environ une semaine de tests.

Voici donc le problème de l'allocation des ressources, et mon extension à la question - dans le scénario ci-dessus, l'AQ a le temps de tester les fonctionnalités prévues d'un sprint (3 semaines de tâches de développement, laissant la dernière semaine pour tester les fonctionnalités livrées en dernier). Supposons également que l'AQ commence à obtenir des fonctionnalités testables après une semaine de développement - mais qu'en est-il de la semaine 1 pour l'AQ, et de la semaine 4 pour le développement ?

Si les tests fonctionnels de l'AQ font partie de la définition de ce qui est "fait" pour une fonctionnalité dans un sprint, alors il semble que cette inefficacité soit inévitable. L'AQ sera largement inactive pendant la semaine 1 et le développement sera largement inactif pendant la semaine 4. Bien sûr, il y a des choses qui remplissent naturellement ce temps, comme la correction et la vérification des bogues, la conception/planification, etc., mais nous schématisons essentiellement nos ressources à 75% de leur capacité.

La réponse évidente semble être le chevauchement des sprints pour le développement et l'AQ, car la réalité est que l'AQ a toujours un certain retard sur le développement. Les démonstrations aux propriétaires de produits et autres suivraient le sprint d'assurance qualité puisque nous voulons que les fonctionnalités soient testées avant d'être montrées. Cela semble permettre une utilisation plus efficace du développement et de l'AQ puisque nous n'avons pas autant de temps perdu. En supposant que nous voulons que les développeurs continuent à développer et les testeurs à tester, je ne vois pas de meilleure solution pratique. Peut-être ai-je raté quelque chose et j'espère que quelqu'un pourra m'éclairer à ce sujet - sinon, il semble que cette approche rigide de la méthode Scrum soit défectueuse. Merci.

Answer 4

Avec un peu de chance, vous y remédiez en vous attaquant à moins de tâches de développement dans chaque sprint. Ce qui nous amène à la question suivante : Qui fixe les objectifs de Dev ? Pourquoi Dev n'atteint-il pas ces objectifs de manière constante ?

Si dev ne se fixe pas ses propres objectifs, c'est pourquoi il est toujours en retard. Et ce n'est pas la façon idéale de pratiquer Scrum. Il s'agit simplement d'un développement incrémentiel avec des livrables importants axés sur les délais et aucune responsabilité réelle de la part des développeurs.

Si le dév ne peut pas fixer ses propres objectifs parce qu'il n'en sait pas assez, il doit s'impliquer davantage dès le départ.

Scrum repose sur quatre principes de base, décrits dans les Manifeste Agile .

1. Les interactions sont importantes - ce qui signifie que le développement, l'assurance qualité, la gestion de projet et les utilisateurs finaux doivent parler davantage et se parler entre eux. Le logiciel est un processus d'encodage des connaissances dans le langage obscur des ordinateurs. Pour coder les connaissances, les développeurs doivent avoir les connaissances. [Scrum n'est pas une méthodologie de type "écrire les spécifications - jeter par-dessus le tableau". C'est l'ANTI-"write spec - throw over transom".

2. Le logiciel de travail est important, ce qui signifie que chaque morceau que Dev mord doit mener à un travail libération. Pas un ensemble de corrections de bogues pour que le service d'assurance qualité puisse s'y attaquer, mais un logiciel qui fonctionne.

3. Collaboration avec les clients - cela signifie que Dev doit travailler avec des analystes commerciaux, des utilisateurs finaux, des propriétaires d'entreprise, tous ceux qui peuvent les aider à comprendre ce qu'ils construisent. Les délais n'ont pas autant d'importance que la prochaine chose remise au client. Si le client a besoin de X, c'est la chose la plus prioritaire à faire pour tout le monde. Si le plan de projet prévoit la construction de Y, c'est de la foutaise.

4. Réagir au changement - cela signifie que les clients peuvent réorganiser les priorités des sprints suivants. Ils ne peuvent pas réorganiser le sprint en cours (c'est fou), mais tous les sprints suivants sont susceptibles de changer de priorités.

Si c'est le client qui dirige, alors les délais deviennent moins des "jalons de projet" artificiels et plus "nous avons besoin de X d'abord, puis de Y, et cette chose dans la section Z, nous n'en avons plus besoin. Maintenant que nous avons W, Z est redondant".

Answer 5

Les règles de Scrum stipulent que tous les éléments du Sprint doivent être "entièrement testés, des fonctionnalités potentiellement implémentables" à la fin du Sprint pour être considérés comme complets. Les sprints se terminent TOUJOURS à l'heure, et l'équipe ne reçoit aucun crédit et n'est pas autorisée à présenter quoi que ce soit à la revue du sprint qui n'est pas complet - et cela inclut l'AQ.

Techniquement, c'est tout ce dont vous devriez avoir besoin. Une équipe s'engage sur une certaine quantité de travail, l'envoie finalement à l'AQ deux jours avant la fin du Sprint et l'AQ n'est pas faite à temps. Le résultat du sprint est donc nul, l'équipe doit se présenter devant le client et admettre qu'elle n'a rien à montrer pour un mois de travail.

La prochaine fois, vous pouvez parier qu'ils choisiront moins de travail et qu'ils trouveront le moyen de le transmettre au service d'assurance qualité afin qu'il puisse être terminé à temps.