Rester agile avec une politique zéro bug / défaut

Dans notre projet, nous travaillons selon une méthodologie zéro bug (ou zéro défaut). L'idée de base est que les bogues sont toujours plus prioritaires que les fonctionnalités. Si vous travaillez sur une histoire et qu'elle contient un bug, elle doit être résolue pour que l'histoire soit acceptée. Si un bug est trouvé pendant le sprint pour une histoire plus ancienne, nous devons le mettre ensuite sur notre backlog et le résoudre - priorité absolue.

La raison pour laquelle je dis résolution est que nous ne corrigeons pas toujours le bogue. Parfois, nous le déclarons simplement "ne résoudra pas" car ce n'est pas si important. Dans l'ensemble, cela sonne bien. Nous expédions des produits de haute qualité et ne transportons pas "une bosse" sous la forme d'un énorme arriéré de bogues.

Mais je ne suis pas sûr que cette approche soit correcte. J'ai tendance à convenir que nous devons toujours corriger les bogues graves dès que possible et que nous devons éliminer les bogues non intéressants. Mais qu'en est-il des bogues qui sont importants mais pas aussi importants que les nouvelles fonctionnalités? J'ai tendance à penser qu'ils devraient être classés dans l'arriéré avec une priorité appropriée.

Je vais donner un exemple pour que ce soit plus clair - dans mon projet, nous travaillons avec une interface utilisateur écrite en flex. Nous avons un écran assistant qui s'ouvre à la même taille pour chaque résolution d'écran. Il s'avère que lorsque nous étendons la fenêtre de l'assistant, l'une des pages ne semble pas bonne (il y a une barre de défilement verticale qui ne disparaît pas bien que l'assistant puisse maintenant tout présenter et ne nécessite pas la barre de défilement). Je pense que ce bug est moche. Je suis sûr que cela DOIT être réparé. Mais nous sommes sur un calendrier serré et nous avons beaucoup de fonctionnalités qui, nous le craignons, ne feront pas la coupe et n'entreront pas dans la version. Je pense que nous pouvons vivre avec un tel bug. Il doit être corrigé mais avec une priorité plus faible que les autres fonctionnalités (donc, au cas où nous ne serions pas en mesure de le terminer, au moins nous n'avons pas omis des fonctionnalités plus importantes). Mais,

Je serais ravi d'entendre des opinions sur la façon de gérer les bugs que je ne veux pas marquer comme "ne sera pas corrigé" mais qui ne sont pas non plus de la plus haute importance.

Corriger des bugs avant d'écrire du nouveau code est en fait l'un des douze points du test de Joel . Joel explique également pourquoi c'est un incontournable:

En général, plus vous attendez avant de corriger un bug, plus il est coûteux (en temps et en argent) de le corriger.

Tu as le choix:

• Soit vous implémentez une fonctionnalité très demandée et retardez la correction d'un bogue, ce qui augmentera inévitablement le coût de sa correction,

• Ou vous corrigez le bogue dès maintenant, étant donné que les clients seront déçus que vous soyez si lent à fournir la fonctionnalité dont ils ont tant besoin.

Si le bogue n'est pas très important, alors que la fonctionnalité l'est, la direction sera encline à demander de l'implémenter en premier, puis à corriger le bogue. Sur le plan commercial, c'est un choix parfaitement valable, dans la mesure où la direction en comprend clairement les conséquences, c'est-à-dire qu'il serait plus difficile de corriger le bogue plus tard que maintenant.

S'en tenir à «pas de nouvelles fonctionnalités jusqu'à ce que tous les bugs soient corrigés» peut ne pas être le meilleur choix commercial. Vous avez déjà mentionné ses limites, il n'est donc pas nécessaire de l'expliquer.

Cela dit, le risque de laisser des fonctionnalités très importantes être implémentées avant de corriger des bugs mineurs comporte un risque: où mettre les limites? Une fonctionnalité demandée par 1 000 clients est-elle plus importante qu'un bug rencontré par 100 clients? Comment évaluer si une fonctionnalité donnée doit être effectuée avant de corriger un bogue donné?

Sans règles strictes et si la direction ne comprend pas très bien le processus de développement, vous vous verrez peut-être dans quelques années avec un carnet de commandes rempli de bogues qui n'étaient pas considérés comme suffisamment importants pour être corrigés avant juste une autre fonctionnalité sophistiquée.

En plus de plonger dans des détails particuliers de votre situation, vous feriez mieux de vous assurer que vous avez bien compris les choses de base.

À cet égard, je pense qu'il est très important de souligner que la politique que vous mentionnez, "les bogues sont toujours plus prioritaires que les fonctionnalités", en particulier le mot s'écarte toujours d'au moins deux des quatre principes énoncés dans le Manifeste Agile :

Individus et interactions sur les processus et les outils

Répondre au changement suite à un plan

Je n'insiste pas pour que vous changiez de politique, car je crois fermement qu'il faut être agile quant à l'application même des principes agiles.

Mais vous devez au moins savoir quand vous vous écartez et comprendre si et comment la déviation est justifiée . Autrement dit, vous feriez mieux de vous assurer que ce que vous appelez «agile» ne glisse pas réellement dans un faux insensé, si éloquemment couvert dans le Manifeste Agile Semi-Arsed :

Les individus et les interactions sur les processus et les outils
et 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

Logiciel de travail sur une documentation complète
tant que ce logiciel est documenté de manière exhaustive

La collaboration du client sur la négociation des contrats
dans les limites de contrats stricts, bien sûr, et sous réserve d'un contrôle rigoureux des modifications

Répondre au changement plutôt que de suivre un plan à
condition qu'un plan détaillé soit en place pour répondre au changement et qu'il soit suivi avec précision

Par souci d'exhaustivité, ce n'est pas seulement les principes agiles dont la politique zéro bug semble s'écarter.

Dans les projets non agiles auxquels j'ai participé, il a été généralement considéré comme imprudent de consacrer du temps aux programmeurs à corriger des bogues qui ne sont pas suffisamment importants pour justifier le retard de la publication de fonctionnalités hautement prioritaires.

Pour cette raison, la direction a généralement dépensé (peut-être serait-il plus exact de dire investi ) quelques efforts pour décider quels bogues pourraient attendre la prochaine version.

• ^{Travaillez-vous par hasard sur des logiciels critiques? Je demande parce que dans ce cas, la politique zéro bogue est assez logique et vaut la peine de compromettre les principes agiles / non agiles / peu importe. Bien que j'aie du mal à imaginer un processus agile dans ce cas.}

Vous savez, à moins que vous ne travailliez sur un logiciel essentiel à la mission, je recommanderais d'évaluer de plus près les compétences et les capacités de réflexion de votre gestion.

Je veux dire, d'après ce que vous décrivez, il semble plutôt qu'ils ne sont tout simplement pas capables de hiérarchiser correctement les bogues et les fonctionnalités. Si tel est le cas, s'ils ne peuvent pas gérer une tâche aussi routinière, de quoi d'autre ne sont-ils pas capables? Offrir un salaire compétitif? opportunités de croissance de carrière? les conditions de travail?

Comme vous l'indiquez à juste titre, une politique zéro bug a le risque que les problèmes non critiques soient ignorés ou bousculés sous le tapis, car ce n'est pas le meilleur moment pour les résoudre.

Ce que vous pourriez faire, c'est quand un nouveau problème est signalé, prendre une décision à trois:

1. C'est un véritable bug et devrait être corrigé dès que possible: mettre en haut du backlog
2. C'est un véritable bug, mais n'est pas critique pour le fonctionnement de l'application: transformez-le en une histoire régulière et laissez le propriétaire du produit le prioriser.
3. Ce n'est pas un bug, ou c'est un doublon ou ça ne vaut pas la peine d'être résolu: rejetez avec une raison appropriée.

De cette façon, les problèmes moins importants ne seront pas entièrement oubliés, mais ils ne forceront pas non plus toutes les nouvelles fonctionnalités brillantes du prochain sprint. Le `` transformer en histoire '' est juste pour que la direction puisse continuer à affirmer que vous suivez une politique zéro bug et que le propriétaire du produit devrait être en mesure d'équilibrer l'importance du problème par rapport à l'importance des fonctionnalités du backlog.

Notez que, avec cette procédure, des problèmes comme la barre de défilement que vous avez mentionnée peuvent toujours ne pas être résolus à la fin du projet, mais c'est parce que personne ne pensait que c'était suffisamment important (y compris les clients), pas parce qu'il n'y en avait pas moment où le problème a été détecté.

J'aime votre schéma, cependant, comme vous l'avez identifié, il suffit d'un petit ajustement pour le faire fonctionner - Comme vous l'avez observé, la réalité est souvent qu'une nouvelle fonctionnalité l'emporte sur une correction de bogue .....

Ma suggestion est de forcer l'augmentation de la priorité des bugs à chaque sprint. Disons que vous avez un bug au niveau 5 (échelle 1-haut, 5 = bas). Cela commence comme 5, 4 sprints plus tard, c'est un bug de niveau 1. Cependant, l'état d'esprit nécessaire pour le calcul de la priorité est "Priorité actuelle - Nombre de sprints", plutôt que "Augmenter la priorité des bogues en suspens à la fin de chaque sprint" - cela empêche que la priorité soit "réinitialisée" à faible pour la reporter davantage.

Les bugs de niveau 1 doivent être corrigés dans le prochain sprint ......

Est simple à expliquer, facile à mettre en œuvre ....

Maintenant, mesurez que pour présenter les demandes, peut-être un taux différent. Après un certain temps, la demande doit être traitée - qu'elle soit effectuée ou rejetée, ce qui empêche un arriéré de fonctionnalités qui n'ont aucune valeur ......

Vous rencontrez des problèmes lorsque vous essayez d'être trop littéral ou catégorique sur quoi que ce soit dans le développement de logiciels autant que nous voulons tous vraiment que les choses soient coupées et sèches. Les bogues devraient être corrigés avant l'ajout de nouvelles fonctionnalités, mais je considérerais toujours l'importance de chacun lors de la prise de cette décision ainsi que l'ampleur du problème. Il y a des exceptions à tout.

Certaines applications sont si grandes qu'elles ont des sections qui ne sont pas liées du tout. Je ne vois pas pourquoi chaque nouvelle fonctionnalité du module des comptes fournisseurs doit être suspendue, car il y a quelques bugs ennuyeux dans l'interface graphique des avantages sociaux. Si une certaine gêne de l'interface utilisateur de l'étape de l'assistant se trouvait dans la section achats du site Web de la société, corrigez-le, mais de nombreux bogues peuvent ne pas être résolus si la fonctionnalité ajoutée est le résultat d'une sécurité supplémentaire, d'un besoin commercial et, en particulier, de modifications des réglementations.

Mis à part une grande différence dans le temps et les ressources pour terminer l'un ou l'autre, il est préférable d'obtenir une entrée utilisateur / client. S'ils peuvent vivre avec le bogue si cela signifie obtenir la nouvelle fonctionnalité, ajoutez la fonctionnalité. Le but devrait être d'éviter de laisser les bugs s'accumuler, donc ayez un espace d'arrêt. À un moment donné, de nombreux petits problèmes deviennent majeurs.

Écrire des tests pour montrer le bogue lors de l'exécution du test est un bon début pour corriger les bogues. Mais lorsque vous essayez de corriger les bogues qui ont la priorité la moins importante, nous devrions réfléchir à deux fois avant de procéder. Je ne voulais pas sauter de le réparer. Mais nous pouvons utiliser des ressources non critiques pour corriger ces bogues. Disons, dans mon équipe, que nous formons les nouvelles ressources avec les bogues les moins prioritaires dans la liste des bogues. De cette façon, nous avons la chance de former la nouvelle ressource et de leur donner une teinte de confiance quant au fait qu'ils ont corrigé leur entrée dans l'application. Cela les rendra certainement volontaires pour la prochaine tâche prioritaire.

J'espère que cela t'aides :)