Faut-il arrêter d'essayer de faire de l'agile si l'AQ prend 12 semaines?

24

Quelqu'un dans mon entreprise a récemment proposé des changements à notre produit de base qui, selon nos gestionnaires, devraient déclencher ce que je suppose que mon entreprise considère comme un cycle complet d'AQ (c'est-à-dire tester la suite complète de produits à partir de zéro). Apparemment, notre AQ prend 12 semaines pour effectuer un cycle complet d'AQ pour notre produit. Mon problème avec cela est que nous essayons de faire du développement Agile (bien que la plupart du temps à moitié à mon avis). Nous ferons toute une série de sprints puis ferons une version, que le contrôle qualité prendra une éternité, je suppose. La question est vraiment, si notre AQ va prendre 12 semaines pour faire leur travail, ne devrions-nous pas simplement abandonner nos efforts pour faire de l'Agile? À quoi bon essayer de faire de l'Agile dans une telle situation?

David Hosier
la source
36
Je me risquerais à dire que si l'AQ prend 12 semaines, alors vous n'êtes pas "agile".
SingleNegationElimination
9
Si l'équipe n'est pas responsable de la qualité du code qu'elle produit, je ne dirais pas qu'elle est agile non plus ..
merryprankster
1
@merryprankster Pourriez-vous développer votre réponse? Voulez-vous dire qu'il est inutile de ne pas faire participer l'AQ à l'équipe et de vérifier la qualité dans le cadre du sprint? Ou voulez-vous dire que l'équipe devrait vérifier la qualité par elle-même à un point où l'AQ devrait être rendue presque inutile? Ou peut-être un autre sens? Je ne connais pas les bonnes réponses ici. Je suis à la recherche de tout conseil que je pourrais obtenir sur un moyen de rectifier une situation qui me semble horriblement brisée. Merci.
David Hosier
2
Je veux dire que l'équipe doit s'approprier le processus qualité. Ils feront ce qu'il faut pour s'assurer que la qualité est assez bonne. Cela maintient la boucle de rétroaction aussi courte que possible et la rend plus personnelle. La qualité n'est pas une propriété externe, elle fait intrinsèquement partie du développement.
merryprankster
2
Cela devient un chat, donc ce sera mon dernier commentaire. Oui, je suis d'accord que dans le monde réel, vous êtes limité par votre environnement. En outre, vous devriez pouvoir choisir vos méthodes de travail. Cependant, je pense que ce n'est pas vrai que l'agilité du chat est flexible dans tous les sens, bien au contraire: l'agilité nécessite de la discipline . Un aspect important du développement agile est de garder les boucles de rétroaction courtes. Si vous avez une phase d'assurance qualité en dehors de l'itération, les commentaires sont en retard. Si l'équipe n'aborde pas l'AQ dans le cadre de l'itération, elle n'est pas agile. L'équipe peut décider comment elle fait l'AQ - c'est flexible - mais l' équipe doit le faire.
merryprankster

Réponses:

21

Eh bien, la réponse directe à votre question serait Mu, je le crains - il n'y a tout simplement pas assez de détails pour faire une supposition éclairée si vous devez ou non arrêter d'essayer.

La seule chose que je suis assez positive, c'est que le niveau d'agilité devrait être déterminé par les besoins des clients / du marché (dont vous n'avez donné aucune information).

  • Par exemple, en tant qu'utilisateur d'IDE, je suis parfaitement heureux de passer à la nouvelle version une ou peut-être deux fois par an et je ne suis jamais pressé de le faire. C'est-à-dire que si leur cycle de sortie est de 3 mois ( 12 semaines ), j'en suis parfaitement satisfait.
     
    D'un autre côté, je peux facilement imaginer, disons, une société de négoce financier faire faillite s'il faut plus d'un mois pour que son logiciel s'adapte aux changements du marché - un cycle de test de 12 semaines dans ce cas serait une route vers l'enfer. Maintenant - quels sont vos besoins en matière de produits à cet égard?

Une autre chose à considérer est le niveau de qualité requis pour répondre aux besoins de votre client / marché.

  • Exemple: dans une entreprise où j'ai travaillé, nous avons constaté que nous avions besoin d'une nouvelle fonctionnalité dans un produit sous licence d'un fournisseur de logiciels. Sans cette fonctionnalité, nous avons souffert assez fortement, alors oui, nous voulions vraiment qu'ils soient agiles et fournissent une mise à jour dans un délai d'un mois.
     
    Et oui, ils semblaient être agiles et oui, ils ont publié cette mise à jour en un mois (si leur cycle d'assurance qualité est de 12 semaines, ils l'ont probablement sauté). Et notre fonctionnalité a parfaitement fonctionné - devinez-vous que nous aurions dû être parfaitement heureux? non! nous avons découvert un bogue de régression showstopper dans certaines fonctionnalités qui fonctionnaient très bien auparavant - nous avons donc dû nous en tenir à l'ancienne version.
     
    Un autre mois s'est écoulé - ils ont sorti une autre nouvelle version: notre fonctionnalitéétait là mais le même bug de régression était là aussi: encore une fois, nous n'avons pas mis à niveau. Et encore un mois et un autre.
     
    En fin de compte, nous n'avons pu mettre à niveau que six mois plus tard, tant pour leur agilité.

Maintenant, regardons de plus près ces 12 semaines que vous mentionnez.

Quelles options avez-vous envisagées pour raccourcir le cycle d'AQ? comme vous pouvez le voir dans l'exemple ci-dessus, le sauter simplement ne vous donnera peut-être pas ce que vous attendez donc vous feriez mieux d'être, eh bien, agile et d'envisager différentes façons de le résoudre.

Par exemple, avez-vous envisagé des moyens d'améliorer la testabilité de votre produit?

Ou, avez-vous envisagé une solution de force brute pour simplement embaucher plus d'AQ? Aussi simple que cela puisse paraître, dans certains cas, c'est effectivement la voie à suivre. J'ai vu la direction inexpérimentée essayer de résoudre les problèmes de qualité des produits en embauchant aveuglément de plus en plus de développeurs seniors, où une paire de testeurs professionnels moyens suffirait. Assez pathétique.

Le dernier mais non le moindre - je pense que l'on devrait être agile quant à l'application même des principes agiles. Je veux dire, si les exigences du projet ne sont pas agiles (stables ou changent lentement), alors pourquoi s'embêter? J'ai vu une fois la direction forcer Scrum dans des projets qui se passaient parfaitement bien sans. Quel gaspillage c'était. Non seulement il n'y a eu aucune amélioration dans leur livraison, mais pire, les développeurs et les testeurs sont tous devenus mécontents.


mise à jour basée sur les clarifications fournies dans les commentaires

Pour moi, l'une des parties les plus importantes d'Agile est d'avoir une version livrable à la fin de chaque sprint. Cela implique plusieurs choses. Tout d'abord, un niveau de test doit être effectué pour garantir l'absence de bogues spectaculaires si vous pensez que vous pourriez publier la version à un client ...

Version livrable je vois. Hm. Hmmm. Pensez à ajouter une dose ou deux de Lean dans votre cocktail Agile. Je veux dire, si ce n'est pas un besoin client / marché, cela signifierait seulement un gaspillage de ressources (de test).

Pour ma part, je ne vois rien de criminel en traitant Sprint-end-release comme un simple point de contrôle qui satisfait l'équipe.

  • dev: oui celui-là a l'air assez bon pour passer aux testeurs; QA: oui, celui-ci semble assez bon pour le cas si d'autres tests d'expédition sont nécessaires - des trucs comme ça. L'équipe (dev + QA) est satisfaite, c'est tout.

... Le point le plus important que vous avez soulevé était à la fin de votre réponse en termes de non-application d'agile si les exigences ne sont pas agiles. Je pense que c'est parfait. Lorsque nous avons commencé à faire de l'agilité, nous l'avons fait composer et les circonstances avaient du sens. Mais depuis lors, les choses ont radicalement changé et nous nous accrochons au processus où cela pourrait ne plus avoir de sens.

Vous avez parfaitement compris. De ce que vous décrivez, il semble également que vous soyez arrivé à l'état (maturité équipe / gestion et relation client) vous permettant d'utiliser le développement de modèles itératifs régulier au lieu de Scrum. Si oui , alors vous pourriez être également intéressé de savoir que par mon expérience dans des cas comme celui itérative régulier ressenti plus productif que Scrum. Beaucoup plus productif - il y avait tout simplement tellement moins de frais généraux, c'était tellement plus facile de se concentrer sur le développement (pour que l'AQ se concentre respectivement sur les tests).

  • Je pense généralement à cela en termes de Ferrari (comme itération régulière) vs Landrover (comme Scrum).
     
    Lorsque vous conduisez sur une autoroute (et votre projet semble avoir atteint cette autoroute ), Ferrari bat l'enfer de Landrover.
     
    C'est le tout-terrain où l'on a besoin d'une jeep et non d'une voiture de sport - je veux dire si vos besoins sont irréguliers et / ou si le travail d'équipe et l'expérience de gestion ne sont pas si bons, vous devrez choisir Scrum - simplement parce qu'essayer régulièrement vous coincé - comme Ferrari restera coincé hors route.

Notre produit complet est vraiment composé de nombreuses petites pièces qui peuvent toutes être mises à niveau indépendamment. Je pense que nos clients sont très disposés à mettre à niveau ces composants plus petits beaucoup plus fréquemment. Il me semble que nous devrions peut-être plutôt nous concentrer sur la libération et l'assurance qualité de ces petits composants à la fin des sprints ...

Ci-dessus sonne comme un bon plan. J'ai travaillé une fois sur un tel projet. Nous avons expédié des versions mensuelles avec des mises à jour localisées dans de petits composants à faible risque et l'approbation de l'assurance qualité pour ces derniers était aussi simple que possible.

  • Une chose à garder à l'esprit pour cette stratégie est d'avoir une vérification testable que le changement est localisé là où on l'attend. Même si cela va jusqu'à la comparaison de fichiers bit par bit pour les composants qui n'ont pas changé, allez-y ou vous ne le recevrez pas. Le fait est que c'est le QA qui est responsable de la qualité des versions, pas nous les développeurs.
     
    C'est le casse-tête du testeur de s'assurer que des changements inattendus ne passent pas - parce que franchement, en tant que développeur, j'ai suffisamment d'autres choses à craindre qui sont plus importantes pour moi. Et à cause de cela, ils (les testeurs) ont vraiment vraiment besoin d' une preuve solide que les choses sont sous contrôle avec la version qu'ils testent pour expédier.
moucheron
la source
1
Je pense que c'est probablement la meilleure réponse à la lumière de notre situation actuelle. Pour moi, l'une des parties les plus importantes d'Agile est d'avoir une version livrable à la fin de chaque sprint. Cela implique plusieurs choses. Tout d'abord, un niveau de test doit être effectué pour garantir l'absence de bogues de démonstration si vous pensez que vous pourriez publier la version à un client. Deuxièmement, en supposant que la première affirmation est vraie, est-il possible que l'AQ répète beaucoup de travail qui aurait déjà dû être fait pendant le développement? Je pense qu'il y a probablement quelque chose à aborder là-bas, à la fois dans notre QA et dans notre équipe de développement (je suis un développeur).
David Hosier
Cependant, je ne me souviens pas que nous ayons jamais publié une version à un client après un sprint. De plus, comme notre base de clients est, ils ne veulent pas souvent une version complète du produit. Nos clients mettent du temps à mettre à niveau. Le point le plus important que vous avez soulevé était à la fin de votre réponse en termes de non-application de l'agilité si les exigences ne sont pas agiles. Je pense que c'est parfait. Lorsque nous avons commencé à faire de l'agilité, nous l'avons fait composer et les circonstances avaient du sens. Mais depuis lors, les choses ont radicalement changé et nous nous accrochons au processus où cela pourrait ne plus avoir de sens.
David Hosier
3
Notre produit complet est vraiment composé de nombreuses petites pièces qui peuvent toutes être mises à niveau indépendamment. Je pense que nos clients sont très disposés à mettre à niveau ces composants plus petits beaucoup plus fréquemment. Il me semble que nous devrions peut-être plutôt nous concentrer sur la libération et l'assurance qualité de ces composants plus petits à la fin des sprints. Nous pourrions raccourcir la boucle de rétroaction en raison d'une approche plus ciblée et fournir de la valeur aux clients plus rapidement. Ensuite, nous pourrions faire une version complète du produit à un moment donné qui termine tous les petits morceaux. Le contrôle qualité a alors moins à faire puisque la plupart ont déjà été validés dans les sprints précédents.
David Hosier
1
+1 J'aime vos exemples des différents besoins du marché. On pourrait fournir des exemples plus extrêmes. Par exemple, un logiciel de contrôle pour gérer les lancements de fusées spatiales. Le client peut être satisfait des mises à niveau tous les cinq ans (les lois de la physique ne changent pas beaucoup), mais un seul bug de régression peut coûter des centaines de millions de dollars .
MarkJ
14

Oh, je ressens ta douleur. Il y a de sérieux changements que vous devez apporter à l'équipe AQ ​​pour que cela fonctionne.

Mon conseil est de diviser l'équipe en trois équipes:

Test des fonctionnalités - Délai d'exécution rapide pour tester les nouveaux développements.

Test de régression - Test complet du produit avant qu'il ne sorte de la porte. Cela ne devrait pas prendre 3 mois, même après avoir réduit la taille de l'équipe car la plupart des bogues seront détectés par la première équipe.

Tests automatisés - Rédaction d'une suite complète de tests de régression pour accélérer le travail de l'équipe de tests de régression.

La troisième équipe est un bonus, mais si vous ne pouvez pas avoir les deux premières équipes, vous pouvez tout aussi bien être une cascade.

pdr
la source
+1 Test automatisé - Les tests de régression sont un candidat de choix.
Joshua Davis
Je pense que c'est une très bonne réponse. Je ne suis pas vraiment au courant de la façon dont l'équipe d'AQ est organisée ou de la façon dont elle procède à ses tests. Notre équipe d'AQ est en Inde, ce qui, je pense, n'est pas une partie insignifiante du problème. D'après ce que je comprends, leurs plans de test ne sont pas publiés de sorte que quiconque puisse les examiner et les valider. En outre, en raison de la différence de temps, le temps de rotation entre les développeurs et le contrôle qualité est atroce. Ce qui devrait prendre une heure de conversation au bureau de quelqu'un se transforme en jours de courriels ou de commentaires JIRA.
David Hosier
13

À titre d'illustration:

entrez la description de l'image ici

Notez que votre équipe d'AQ travaille probablement en dehors du cercle (ATDD) et que vous travaillez à l'intérieur.

Je pense que c'est OK de travailler de cette façon; si vous pouvez prouver dans vos tests automatisés que vous remplissez les exigences du client à chaque sprint, vous pouvez autoriser QA à effectuer ses tests à loisir et vous présenter des défauts, que vous pouvez ensuite travailler dans le sprint suivant.

Robert Harvey
la source
2
Un problème est que vous obtenez des rapports de défauts du travail effectué il y a 4 à 6 sprints (en supposant des sprints de 2 à 3 semaines). Selon les politiques et procédures d'assurance qualité de l'entreprise, il se peut que l'entreprise doive se déconnecter d'un sprint avant de le remettre au client. Donc, oui, vous avez des produits potentiellement livrables après chaque sprint, mais moins de 25% d'entre eux atteindront le contrôle qualité (en supposant que lorsqu'ils ont terminé de tester un candidat, ils commencent à tester le candidat le plus récent) afin que vous puissiez montrer à un client un produit tous les quelques semaines, mais ils ne peuvent en obtenir qu'un toutes les 12 semaines et ce sera plus ancien que ce qu'ils viennent de voir.
Thomas Owens
Droite. J'étais en train d'en discuter avec un collègue. Je dirais que nous n'avons même pas vraiment fait de bonnes versions à la fin de chaque sprint. Nous faisons une construction à la fin de chaque sprint parce que c'est ce que Agile dit que vous devriez faire, mais nous n'avons aucune intention que quiconque voie cette construction. Je ne sais pas si QA obtient ces builds ou non, mais je peux vous assurer qu'aucun client ne verra jamais de build à la fin du sprint. Une seule version est potentiellement officielle, et c'est celle du dernier sprint. Dans mon esprit, ce n'est pas du tout agile. Avec ce flux de travail, Agile n'est qu'un moyen d'organiser le travail.
David Hosier
De plus, je ne me souviens pas avoir reçu de retour de QA avant la construction du dernier sprint comme je l'ai mentionné ci-dessus. Cela valide votre point. Ce que je pense que cela pourrait conduire à des situations où les décisions qui sont prises dans le sprint 1 se révèlent être des décisions erronées, mais cette décision défectueuse n'est pleinement réalisée que lorsque tout le travail ultérieur est effectué en plus de cette décision erronée. Bien sûr, cela pourrait conduire à une énorme quantité de retouches.
David Hosier
8

Il semble que vous ayez un problème de "Définition de Terminé".

Étant donné que votre groupe d'assurance qualité est externe et ne participe qu'aux versions client, vous ne pouvez pas vous fier à eux pour obtenir des commentaires en temps opportun sur les problèmes. Cela signifie que si vous voulez un retour rapide, vous devrez apporter un certain degré de test "en interne" pour l'équipe.

Traitez le groupe AQ ​​comme s'il n'existait pas. Agissez si votre version à la fin du sprint sera déployée dans votre environnement le plus critique le lendemain. Le logiciel n'est pas terminé tant qu'il n'est pas prêt à être envoyé aux clients.

L'AQ ne devrait rien trouver.

Ce sera plus difficile à atteindre. Vous aurez probablement des choses qui se faufilent les premières fois. Les tests d'acceptation automatisés et les tests de "régression" sont vos meilleurs amis ici. TDD vous aidera à construire de grandes parties de ces suites. Vous devriez pouvoir savoir - rapidement - si vous avez cassé quelque chose.

Sean McMillan
la source
3

Avez-vous un représentant du client / propriétaire du produit qui peut voir une version donnée avant que le contrôle qualité ne soit terminé et vous donner un avis fiable à ce sujet? Si tel est le cas, vous pouvez utiliser et tirer le meilleur parti des méthodes agiles tout en traitant l'AQ comme une source secondaire, un peu lente de rétroaction. Une version ne serait "officiellement prête" qu'après que le contrôle qualité aura terminé, mais vous n'auriez pas à les attendre avant de commencer la suivante.

Mais si les règles de l'entreprise stipulent que le client ne doit pas voir une version avant que le contrôle qualité en soit terminé, vous pouvez à peu près oublier d'être agile, jusqu'à ce que vous parveniez à faire modifier ces règles.

Michael Borgwardt
la source
3

Le processus que vous avez décrit n'est pas un processus agile. Les équipes qui ont un haut degré d'agilité sont capables de fournir des builds fiables et potentiellement libérables à chaque sprint. Dans la plupart des implémentations agiles, la fonction QA est construite au sein de l'équipe agile, aidant à atteindre cet objectif.

Si vous, votre chef de projet, votre propriétaire de produit et les développeurs ne travaillez pas ensemble et que vous n'avez pas de plan d'amélioration (rétrospectives), nommez votre processus autrement et passez à autre chose. Il ne semble pas que les problèmes de vos équipes soient la faute des managers ou du QA. Ils semblent réagir à un problème systémique provenant de l'organisation de développement. Tout n'est pas perdu si l'équipe est prête à prendre ses responsabilités et à commencer à travailler avec les parties prenantes.

Vous pouvez essayer trois choses. Premièrement, assurez-vous que chaque partie prenante a des rôles définis de manière concise et que chaque personne comprend sa responsabilité. Deuxièmement, stabilisez la construction, puis obtenez l'approbation du contrôle qualité sans introduire plus de modifications. Troisièmement, instaurer l'automatisation des tests. L'équipe QA vous aimera pour cela.

GuyR
la source
Vous avez 100% raison. Vos trois articles sont de bons conseils. Je ne peux qu'affecter autant de changements en tant que développeur unique, mais je peux essayer de donner l'exemple et voir si certaines personnes de l'AQ veulent se joindre à nous. Ma plus grande frustration est que personne d'autre ne semble vraiment s'en soucier, ce qui est évidemment un énorme obstacle à la réussite du redressement requis. La plupart des membres de l'équipe sont simplement heureux de maintenir le statu quo; c'est du moins mon impression.
David Hosier
2

C'est dommage que le feedback prenne si longtemps, mais je ne pense pas que cela vaille la peine de s'arrêter avec l'agilité. À la fin d'un sprint (ou d'un couple), vous sortez un produit que vous êtes sûr qu'il pourrait être mis sur le marché. Pour votre équipe, l'agilité apporte la possibilité de se concentrer sur le travail à effectuer et de garder le produit libérable. Lorsque le contrôle qualité trouve des problèmes, je suggère de créer des rapports de bogues pour ces problèmes et de les résoudre dans le prochain sprint (s'ils ont une priorité suffisamment élevée).

Nos tests sur le terrain des produits durent 8 semaines et nous dépendons de producteurs extérieurs. En agissant toujours, nous pouvons rester concentrés sur le travail à accomplir et produire une nouvelle version très rapidement en cas de besoin.

Le problème réside (à vos yeux) avec le service AQ, le problème peut-il être résolu là-bas? Vous en avez discuté?

refro
la source
Votre réponse a suscité une bonne conversation entre un collègue et moi-même. Le point principal de votre réponse qui m'a attiré a été: "À la fin d'un sprint (ou d'un couple), vous sortez un produit que vous êtes sûr qu'il pourrait être mis sur le marché." Je ne me souviens pas avoir sorti un produit à la fin d'un sprint avant d'avoir terminé toute une série de sprints, il est passé par le contrôle qualité, et nous avons eu plusieurs séries de corrections de bugs de suivi. À cet égard, je pense que nous utilisons Agile simplement comme un moyen de diviser et d'organiser notre charge de travail et rien d'autre. Nous n'obtenons vraiment aucun avantage d'Agile.
David Hosier
@David: Je suis d'accord avec toi.
Christopher Mahan
1

12 semaines, c'est long, mais j'espère que le contrôle qualité peut vous fournir des commentaires et des rapports de bogues pendant cette période (plutôt qu'après les trois mois).

Ensuite, vous pouvez toujours répondre aux problèmes les plus importants de manière agile et pouvez résoudre beaucoup, sinon tous, avant même la fin!

Hugo
la source
-2

Que font les QA pendant que vous exécutez plusieurs sprints? On dirait qu'ils ressentent le besoin de tout tester après chaque changement (c'est pourquoi ils attendent un tas de changements.).

L'équipe de développement est agile, mais pas le reste de l'entreprise.

Celui qui est en charge de l'AQ ne sait pas ce qu'il fait ou il a effectué un Jedi Mind Trick sur la direction et est autorisé à prendre son temps. Comment l'AQ peut-elle prendre plus de temps que le développement?

JeffO
la source