Ce matériel a été préparé par notre partenaire Equio .
Lors de l'achat d'un produit informatique pour résoudre certains problèmes d'entreprise, les clients commerciaux pensent souvent à son coût, à sa fonctionnalité, à sa commodité, à ses capacités d'intégration, etc. Ce ne sont pas des problèmes aussi évidents, tels que la qualité et le niveau du support technique, qu'ils pensent déjà en second lieu.
Mais la qualité du produit final dépend dans une large mesure de la façon dont le développeur a organisé le processus de test, d'identification et de correction des bogues, parmi les développeurs appelés «bogues» (du bogue anglais - un bogue, tout insecte, virus, mot d'argot qui signifie généralement une erreur dans le programme). Cette question est posée par très peu de clients commerciaux individuels.
Nous voulons vous expliquer comment les développeurs identifient et corrigent les bogues, sont adaptés aux tests. Une approche est basée sur la politique Zero Bug.
Spoiler! Nous vous dirons sur quoi les développeurs passent réellement du temps et pourquoi ils ne corrigent pas tous les bugs. 
Sept nounous
Il y a une blague bien connue dédiée à l'annonce de la nouvelle version "Performances optimisées des applications, corrections de bugs, ajout de nouvelles". En fait, corriger des bogues et en ajouter de nouveaux est un processus éternel, les anciens bogues sont corrigés, mais pas moins de nouveaux ne surviennent.
Cela est particulièrement visible lorsqu'un grand nombre de développeurs ou même plusieurs équipes de projet travaillent sur un produit logiciel, sur une base de code unique. Il est très difficile de synchroniser leurs efforts et d'obtenir le code de sortie sans erreur. Par exemple, une équipe a enregistré les modifications dans la branche principale, c'est-à-dire dans la version principale du code dans le référentiel (référentiel). À son tour, l'autre équipe est confrontée à un grand nombre de conflits et essaie de les résoudre. En conséquence, tout cela va sortir, c'est-à-dire à la version finale du produit, adaptée aux utilisateurs ordinaires, et ici une quantité incroyable de bugs apparaît. Et cela est lourd de perte d'argent, de clients et, surtout, d'une menace pour la réputation du développeur.
Alors, que faire dans cette situation? Vous pouvez mettre toute votre force et vos ressources à corriger les erreurs, mais comment pouvez-vous alors vous engager dans le développement de produits, améliorer ceux existants et ajouter de nouvelles fonctions?
Hors de vue, arriéré
Une grande entreprise informatique vient d'avoir un problème similaire. Grâce à la recommandation d'un des spécialistes qui travaillaient dans l'entreprise, il a été décidé d'appliquer l'approche
Zero Bug Policy . Malheureusement, peu de choses ont été écrites à son sujet en russe.
Son essence est la suivante. Lorsque les testeurs ou les utilisateurs trouvent un bogue dans le produit et en informent les développeurs, ces derniers décident si ce bogue sera corrigé ou s'il n'affecte pas les performances du produit, et donc sa correction peut être retardée ou complètement exclue. du backlog (liste des tâches). Ce bug se voit attribuer le statut Won't Fix, après quoi il disparaît à jamais du champ de vision des développeurs. Dans certains cas, des bogues avec ce statut sont placés à la toute fin du backlog. Cela signifie que les développeurs «mettront la main sur» pour les corriger uniquement lorsque toutes les autres tâches seront résolues.
Mais revenons à la société informatique déjà mentionnée. Ses employés ont analysé la liste complète des bogues détectés et trié les problèmes détectés. Près de la moitié des erreurs ont été décidées pour être corrigées dans un avenir proche, et plus de la moitié ont reçu le statut Won't Fix. Tout ce travail a duré environ deux mois, après quoi l'entreprise a décidé d'adopter la
politique Zero Bug de manière continue. À ce jour, cette entreprise n'a pas plus de 10 tâches ouvertes dans le backlog. Cela vous permet de vous concentrer sur la mise en œuvre de nouvelles fonctionnalités.
Experts en bogues
Comment les bogues sont-ils triés? Qui décide qu'une erreur est critique et doit être corrigée, et de l'autre, vous pouvez continuer à vivre en paix ou reporter sa correction à plus tard?
Nous vous expliquerons comment ce processus est organisé en utilisant le concept de gestion de projet flexible (Agile). Tout le monde sait qu'Agile comprend plusieurs techniques. Nous prendrons l'un d'eux comme exemple, SCRUM, car il est le plus souvent utilisé dans le monde du développement logiciel.
Le propriétaire du produit ou Scrum Product Owner est l'un des membres clés de l'équipe de projet. C'est lui qui représente les intérêts des utilisateurs finaux et met tout en œuvre pour maximiser la valeur du produit. Il est également responsable du début à la fin du backlog produit. Toute l'équipe de développement participe au tri des bogues, mais le dernier mot revient toujours au Product Owner. Il détermine quelle erreur sera corrigée et laquelle sera marquée comme ne sera pas corrigée.
En fait, tout est argent. Par exemple, si la correction d'un bogue n'apportait aucun rendement financier à l'entreprise, mais prenait en même temps beaucoup de temps et de ressources, il serait préférable qu'un tel bogue reçoive le statut Won't Fix et retarde sa correction jusqu'à des temps meilleurs. En fait, le "propriétaire du produit" est responsable de la priorisation et de l'état des erreurs détectées.
En d'autres termes, tout le monde a «des squelettes dans le placard». Mais s'ils n'ont aucun effet sur les performances du produit, n'entravent pas les actions de l'utilisateur ou n'entravent pas les processus d'intégration, ils peuvent être complètement ignorés.
Critères de sélection
Ces bogues "mineurs" sont dans les produits de tout développeur.
Par exemple, dans l'interface d'administration du système de gestion de contenu, il est impossible de saisir un titre trop long pour une section, un article, etc. Les développeurs décident de ne pas corriger ce bogue. Après tout, la correction prend du temps, des ressources et vous pouvez simplement prendre et réduire le nom à un certain nombre de caractères. Il suffit d'avertir simplement l'utilisateur que les noms de plus de 30 caractères ne sont pas pris en charge.
Le bouton est un peu dans la mauvaise couleur, les éléments d'interface situés à deux pixels à gauche de ce qui est requis - toutes ces erreurs n'affectent pas la convivialité ou les performances de l'application. Par conséquent, ils peuvent potentiellement être attribués à Won't Fix.
Les bogues critiques sont principalement ceux qui sont gérés par de nombreux clients qui dirigent ou peuvent conduire au fait que les clients perdent de l'argent en raison de défauts dans les programmeurs. Tout cela définit le Product Owner, qui est obligé de connaître le produit comme le fond de sa main, et non seulement de comprendre sa fonctionnalité, mais aussi de comprendre comment les clients commerciaux l'utilisent, quels scénarios d'application existent dans une entreprise particulière.
Esprit collectif
La politique zéro bogue est souvent associée à un contrat de niveau de service (SLA). En règle générale, les développeurs disposent de plusieurs lignes de support technique.
Le premier reçoit un message d'erreur de l'utilisateur et recueille toutes les données nécessaires à sa reproduction et à son analyse, puis transfère toutes ces informations à la deuxième ligne. Les spécialistes de la deuxième ligne reproduisent cette erreur sur les postes de travail ou serveurs sur lesquels la même version du produit est installée que l'utilisateur. Si l'erreur se reproduit, comme le prétend l'utilisateur, les informations à son sujet tombent dans le sprint actif, c'est-à-dire une liste de tâches pour les développeurs.
Les première et deuxième lignes de support technique, ainsi que les développeurs, ont des SLA. Plus le bogue est critique, plus les normes SLA sont strictes pour le corriger. Il existe également un SLA général pour le dépannage: du contact client à l'obtention du code corrigé en production. La décision d'affecter ou non un statut de bogue à Won't Fix est prise par la deuxième ligne du support technique. Cependant, son verdict n'est pas définitif. Tout d'abord, ses employés sont guidés par les principes et les règles du sprint actuel. En outre, il existe une collection d'attentes de la part des développeurs, des clients, du département de développement commercial.
Si une situation controversée survient lorsque tous ces facteurs sont pris en compte, le dernier mot sera précisément derrière la deuxième ligne de support et, bien sûr, Product Owner.
Satisfait signifie productif
Pourquoi tout cela a-t-il besoin d'une société de développement? L'une des raisons est la motivation accrue des développeurs. La correction des bugs est un travail routinier et désagréable, ce que tout le monde n'aime pas faire. La mise en œuvre de nouvelles fonctionnalités est beaucoup plus intéressante que la correction des erreurs de vos collègues. Cela augmente la productivité et la productivité. Enfin, de cette façon, sans sacrifier la qualité, on peut sérieusement économiser sur la maintenance des testeurs, laissant un ou deux spécialistes dans l'entreprise au lieu d'un département entier.
Pourquoi les utilisateurs et les clients commerciaux en ont-ils besoin? L'entreprise se développe, elle est constamment confrontée à de nouveaux défis qui doivent être relevés à l'aide de produits informatiques. Et si les développeurs passent la plupart du temps à éliminer les erreurs insignifiantes, plutôt que d'améliorer la fonctionnalité de leurs créations, ils risquent d'être laissés loin derrière leurs concurrents. Les entreprises choisiront celles qui vont de l'avant, tout en maintenant la barre de qualité à un niveau élevé.
C’est tout. Plus d'informations sur la
société "Equio" peuvent être trouvées sur leur site officiel.
Et sur
le site Web d'Otus, vous pouvez vous familiariser avec nos cours et assister aux
webinaires gratuits qui vous intéressent.