Dilemme de l'AQ contre les itérations

Dans mon entreprise, nous travaillons avec succès avec des pratiques agiles - mais sans utiliser d'itérations. La raison principale est que nous ne pouvons pas trouver un moyen propre d'intégrer l'AQ dans un cycle d'itération.

Nous considérons l'AQ comme un élément de vérification supplémentaire pour une certaine version (version candidate) avant que cette version ne soit déployée chez le client. Le but est d'éviter qu'un seul commit malveillant endommage la version entière. Puisque vous ne savez jamais de laquelle il s'agit, QA doit attendre que toutes les fonctionnalités / validations de la version soient dans la version. (Aucun dernier mot célèbre "Ce n'était qu'un petit changement" autorisé.)

Si QA trouve des bogues dans une version candidate, les développeurs corrigent ces bogues dans la branche de publication respective (et la fusionnent dans le tronc). Lorsque tous les bogues sont corrigés, une nouvelle version est déployée pour que QA puisse tester à nouveau. Ce n'est que lorsqu'aucun bogue n'est trouvé dans une certaine version candidate, qu'il est proposé au client pour vérification.

Cela prend généralement environ deux à trois candidats, environ une semaine, par version. Le temps pour écrire les correctifs est généralement beaucoup plus court que les efforts de test. Donc, afin de garder les développeurs occupés, ils travaillent sur la version N + 1 tandis que QA travaille sur N.

Sans utiliser d'itérations, ce n'est pas un problème car nous pouvons chevaucher le travail pour les versions N et N + 1. Cependant, d'après ce que je comprends, ce n'est pas compatible avec les approches basées sur des itérations comme Scrum ou XP. Ils exigent qu'une itération soit libérable à sa fin, tous les efforts de test devant être incorporés dans l'itération.

Je trouve que cela conduit nécessairement à l'un des résultats indésirables suivants:

(A) Les développeurs sont inactifs à la fin d'une itération car le contrôle qualité a besoin de temps pour vérifier une version candidate et le travail de correction de bogues n'occupe pas complètement les développeurs.

(B) Le contrôle qualité commence déjà à fonctionner avant que la première version candidate ne soit prête. C'est ce qui est principalement recommandé sur Stack Exchange. Mais ce n'est pas ce que mon entreprise comprend comme QA car il n'y a pas de version spécifique testée. Et le "petit changement" qui rompt tout peut encore passer inaperçu.

(C) Les bogues sont reportés à la prochaine itération. Ceci est également recommandé sur Stack Exchange. Je ne pense pas que ce soit une solution du tout. Cela signifie essentiellement que nous n'obtenons jamais de version vérifiée car chaque fois que des corrections de bogues sont apportées, de nouvelles validations non vérifiées sont également ajoutées à la même branche.

Y a-t-il un moyen de sortir de ce dilemme?

Nous considérons l'AQ comme un élément de vérification supplémentaire pour une certaine version (version candidate) avant que cette version ne soit déployée chez le client.

Il n'y a rien intrinsèquement incompatible entre cette forme d'AQ et les méthodologies basées sur l'itération comme Scrum.
Au sein de Scrum, l'équipe délivre un livrable sur un cycle X-hebdomadaire à son client. La partie importante ici est que, si l'équipe de développement fait Scrum, alors son client est l'équipe QA, pas l'utilisateur final de votre produit.

En tant que développeur, je considérerais un produit livrable à QA s'il a une chance de se battre de passer tous ses tests. Cela signifie probablement que certains des tests QA ont déjà été exécutés sur les versions quotidiennes, mais la façon dont cela affecte les tests de version officielle par l'équipe QA dépend de votre organisation.

Pour la plupart des situations réelles, l'agilité s'arrête à la livraison à QA / UAT ou quel que soit son nom.

L'effort pour passer de l'assurance qualité à la production dans un environnement réel est souvent sous-estimé. Dans de nombreux cas, cela implique de véritables utilisateurs professionnels dans les tests, la signature de la direction de la ligne réelle des chefs d'entreprise, la planification de la sortie avec les opérations, etc., etc. Ce n'est pas anodin!

Dans les cas extrêmes, le logiciel peut nécessiter une certification par des agences externes ou être soumis à des tests de sécurité rigoureux.

Dans ces circonstances, il est tout simplement impossible d'envisager plus d'une version par trimestre, à l'exception des corrections de bogues.

Cela empire pour un produit logiciel sérieux. La documentation doit être vérifiée et publiée. Les brochures marketing doivent être modifiées. Les vendeurs doivent être informés de ce qu'ils vendent (pas une tâche facile!), Etc. etc. Vous ne voulez vraiment pas faire passer l'entreprise plus d'une fois par an.

La solution à très court terme consiste à accorder à l'AQ une période de temps supplémentaire après votre itération pour finaliser les tests. c'est à dire. Si vous avez une itération de deux semaines, ne relâchez pas avant la semaine 3. Les AQ n'auront rien à tester vers la prochaine itération, pendant la première semaine de toute façon.

Mais je vais vous avertir à l'avance de ce qui se passera (après avoir vu cela dans plusieurs équipes): vous vous retrouverez dans une situation où une itération vous fera deux semaines de travail, les AQ sont surchargés, ils viennent à vous pour ça toute la semaine d'assurance qualité et, l'itération suivante, vous n'aurez qu'une seule semaine de travail. Cette itération, l'AQ n'aura rien à faire et vous penserez avoir résolu le problème. Mais à la prochaine itération, vous recommencerez le cycle.

Donc, dès que vous avez ajouté cette semaine, juste pour vous assurer que votre version est stable (car une chose que j'ai apprise est que si vous perdez la foi de l'entreprise, Agile devient exponentiellement plus difficile à mettre en œuvre), allez-y sur le plan à long terme.

Achetez une copie de la livraison continue de Jez Humble , lisez-la, de couverture en couverture, passez-la autour de l'équipe. Inspirez tout le monde. Mettez ensuite en œuvre tout ce que vous pouvez en tirer.

Faites en sorte que le processus de construction soit fluide. Mettez en œuvre une stratégie de test unitaire et exécutez-les sur chaque build. Faites du processus de déploiement la chose la plus simple que vous ayez jamais vue. Trois clics? Pas assez lisse.

Une fois que vous avez fait tout cela, cela n'aura plus autant d'importance si le bug de régression occasionnel passe. Tu sais pourquoi? Parce que vous pourrez (facultativement) revenir en arrière, le réparer, le déployer à nouveau, avant que l'entreprise ne s'effondre. En fait, le concierge de nuit pourra revenir en arrière pour vous, le processus sera si simple.

Je sais ce que vous pensez: nous n'avons pas le temps de faire tout cela. Laissez-moi vous dire que vous le faites. Si vous surchargez QA, vous déployez trop par itération. Alors ne le fais pas. Si vous ne les surchargez pas déjà, demandez-leur pourquoi ils ne disposent pas encore de suites de tests automatisées. Vous le serez bientôt.

Faites tout cela avec une visibilité totale sur l'entreprise. Estimer plus bas et injecter une partie de ce travail dans l'itération. Ou, mieux encore, divisez-le en histoires et demandez-leur de le prioriser, à côté de tout le reste.

Expliquez-leur que a) cela améliorera la stabilité de la version et b) cela améliorera votre capacité à répondre aux problèmes pour eux et c) cela leur procurera plus de vitesse plus tard. C'est une entreprise rare qui ne veut pas ces choses. Ce n'est certainement pas une entreprise Agile qui n'en veut pas, donc si vous obtenez de la résistance, vous saurez que vous avez un problème différent.

Une fois que vous avez obtenu la livraison continue, vous pouvez commencer à raccourcir le temps accordé au contrôle qualité à la fin de l'itération. Il est dans l'intérêt de tous de ramener les itérations en parallèle, dès que possible. Vous aurez peut-être un jour à la fin de l'itération, où vous devrez remplir le temps. J'ai déjà répondu quoi faire à ce sujet ailleurs .

Sans utiliser d'itérations, ce n'est pas un problème car nous pouvons chevaucher le travail pour les versions N et N + 1.

Il semble y avoir un problème avec la façon dont vous avez décidé ce qui constitue exactement work for release N.

Pour une raison étrange (je peux seulement deviner qu'il y a un malentendu sur des recettes Agile particulières), vous avez en quelque sorte décidé que l'approche agile oblige tous les efforts de l'équipe d'AQ à être incorporés dans l'itération.

• ^{Si tel était vraiment le cas, je suppose que la popularité Agile ne serait même pas proche de ce que nous voyons maintenant. Je ne peux pas imaginer de nombreux projets qui pourraient "survivre" à la synchronisation obligatoire des itérations de l'équipe de développement avec les cycles de test QA.}

Il y a un peu plus sur l' agilité ci-dessous mais d'abord, disons work for release N...

Regardez, il n'y a tout simplement pas de raison impérieuse pour l'équipe de développement de définir le travail de cette façon. Bien au contraire, d'après votre description, il est clair qu'au lieu d'une "unité de travail" monolithique, il y en a plusieurs, avec des jalons faciles à ressentir ...

• ^{Par exemple, la première "unité" est indiquée par un jalon distinct lorsque la version candidate est transmise aux testeurs, et les autres jalons correspondent aux changements impliqués dans les cycles de test effectués par l'AQ, etc.}

Notez également que la façon dont vous définissez work for release Nn'est pas forcée non plus par le flux de travail QA. D'après ce que vous décrivez, les choses semblent avoir leur propre horaire (et assez raisonnable).

Étant donné ci-dessus, une manière plus réaliste de définir les unités de travail dans votre cas pourrait être la suivante:

1. Activités de développement jusqu'au moment où le build est passé à QA
   Release Candidate N
2. Activités de développement liées au premier cycle de test d'AQ
   Release Candidate N patch 1
3. Activités de développement liées au deuxième cycle de test d'AQ
   Release Candidate N patch 2
4. etc, jusqu'à la version finale

Ci-dessus se trouvent vos unités de travail, que vous fassiez de l'Agile ou autre.

Celles-ci sont naturelles et pratiques à définir, suivre et suivre. Cela se marie également bien avec le calendrier d'AQ, permettant une coordination pratique des efforts de développement et d'AQ.

Cependant, d'après ce que je comprends, ce n'est pas compatible avec les approches basées sur des itérations comme Scrum ou XP. Ils exigent qu'une itération soit libérable à sa fin, tous les efforts de test devant être incorporés dans l'itération.

La compréhension ci-dessus de la compatibilité avec Agile semble fondamentalement fausse et voici pourquoi ...

L'hypothèse que vous avez faite n'a rien à voir avec Agile, si nous prenons sa philosophie à sa valeur nominale comme l'indique son nom même, c'est une approche qui favorise et pratique l' agilité .

De ce point de vue, s'en tenir à un flux de travail «fixe» particulier et ignorer s'il est pratique ou non contredit simplement l'esprit d'Agile. Suivre servilement la "procédure" conduit à des pratiques dénigrées avec tant d'éloquence dans le Manifeste Agile Semi-Arsé "... nous avons des processus et des outils obligatoires pour contrôler la façon dont ces individus (nous préférons le terme" ressources ") interagissent" .

Vous pouvez trouver plus d'informations à ce sujet dans une réponse à une autre question , citée ci-dessous. Jetez un oeil à la note sur la "version livrable", il semble qu'à l'époque OP a été confondu de la même manière:

il faut ê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.

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 ...

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.}