Bonjour, je m'appelle Maksim Plavchenok, je travaille pour Bercut, je fais des tests d'intégration. En septembre, mon équipe et moi avons franchi une étape importante: nous n'avons reçu aucune erreur à la suite de tests d'intégration pour la sortie d'une nouvelle version de facturation pour un opérateur mobile. Nous y sommes allés pendant deux ans; Je veux vous dire aujourd'hui comment nous avons réussi à atteindre notre objectif.
Zéro erreur sur la base des résultats des tests d'intégration - nous parlons ici de tester de nouvelles fonctionnalités sur une acceptation commerciale du côté de l'opérateur. Quelques mots sur le fonctionnement de ces tests.
Nous publions de nouvelles versions de notre logiciel de facturation dans les délais prévus, 6 fois par an. Les dates d'expédition de sortie sont connues à l'avance. Au moment d'écrire ces lignes, nous avons déjà prévu des dates de sortie pour toute l'année prochaine.
Cette spécificité est liée à la course des opérateurs cellulaires pour le time-to-market. Le principe de base: l'abonné doit bénéficier régulièrement de nouvelles fonctionnalités de facturation. Paiements via un smartphone, enregistrement d'un numéro lors du changement d'opérateur, possibilité de vendre du trafic inutilisé - les mises à jour peuvent être différentes.
"Nous ne savons peut-être pas exactement ce que nous publierons dans un an, mais nous connaissons la date exacte à laquelle la mise à jour sera publiée." De ce fait, il est possible de maintenir le rythme de mise à jour souhaité.
Du côté du développement de la facturation, environ 70 personnes sont impliquées dans la sortie. Ce sont 5 à 6 équipes, chacune avec sa propre spécialisation: analyse, développement (plusieurs équipes), tests fonctionnels, tests d'intégration.
Oui, nous avons une cascade dans les projets de facturation. Mais l'histoire actuelle ne concerne pas la façon dont nous avons radicalement changé le paradigme de développement de Waterfall à Agile ou vice versa. Chaque approche de développement a ses propres avantages et est bonne dans les bonnes conditions; Je voudrais laisser cette discussion en dehors du cadre de cet article. Aujourd'hui, je veux parler du développement évolutif: comment nous sommes passés à zéro erreur lors de l'acceptation de la publication dans le cadre de l'approche de développement existante.
Zone d'inconfort
Au début de l'histoire décrite, il y a deux ans, nous avions l'image suivante:
- les équipes à la fin de la chaîne de développement étaient débordées; «Il est temps de donner à la prochaine équipe, et la précédente vient de commencer sa part de travail»;
- le client a pu trouver environ 70 erreurs après nos cycles de test.
Les erreurs qui pourraient être trouvées selon les résultats des tests d'intégration pourraient être mineures («une partie du message est affichée sous forme de tirets») ou même critiques («il n'y a pas de transition vers un autre tarif»).
Nous avons décidé de changer cet alignement: nous nous sommes fixé un objectif - zéro erreur dans l'acceptation commerciale de la nouvelle fonctionnalité.
Au bout d'un an, nous avons pu réduire le nombre d'erreurs à 10-15, à la mi-2020 - à 2-3. Et en septembre, nous avons réussi à atteindre l'objectif de zéro.
Nous avons réussi grâce à des améliorations dans plusieurs domaines: outils, expertise, documentation, travail avec un client, une équipe. Les améliorations varient en importance: connaître les spécificités et les processus du client est important, passer à une nouvelle échelle pour évaluer la complexité des tâches est facultatif et travailler avec la motivation de l'équipe est d'une importance cruciale. Mais tout d'abord.
Points de croissance
Le principal outil de test d'intégration est le banc de test. Là, l'activité de l'abonné est émulée.
Stands partagés
Les décharges de production sont enroulées sur des bancs de test afin que vous puissiez tester dans des conditions aussi proches que possible du combat.
Le hic, c'est que les décharges sur nos stands et les stands des clients pourraient être différents. L'opérateur fait un dump, nous le transmet, nous testons de nouvelles fonctionnalités, détectons et corrigeons les bogues. Nous donnons la fonctionnalité finie au client, des collègues de l'autre côté commencent les tests. Les nôtres et leurs décharges pourraient différer en pertinence: nous avons testé en juillet, l'opérateur - en août, par exemple.
Les différences ne sont pas critiques, mais elles existaient toujours. Cela a conduit au fait que lors des tests du côté du client, des erreurs pouvaient apparaître que nous n'avions pas.
Ce que nous avons fait: convenu que les schémas de données utilisés pour les tests seront les mêmes, et en général, nous aurons une position commune.
Le décalage de vidage demeure, mais nous avons configuré l'infrastructure sur laquelle ce décalage est minime. Pour cette raison, nous avons pu réduire le nombre d'erreurs causées par les différences entre les environnements de test et de production.
Vérification des paramètres avant le test
Lorsque nous donnons une nouvelle version du logiciel à l'opérateur, pour des tests côté client, nous devons effectuer le paramétrage. Configurer la nouvelle fonctionnalité, éventuellement personnaliser davantage l'ancienne.
Nous avons rédigé la documentation pour vous informer des paramètres requis. Ce n'est qu'ici que les manuels peuvent transmettre des informations avec des distorsions. La documentation a été écrite par des personnes, lue par des personnes, et dans la communication des personnes, il y a un malentendu.
C'est la spécificité de notre logiciel: des exigences élevées sont placées sur les paramètres en termes de flexibilité et de disponibilité. Les réglages sont complexes et sans communication supplémentaire, il n'était pas toujours possible de transmettre toutes les informations nécessaires au moyen de la seule documentation.
En conséquence, les réglages peuvent ne pas toujours être exécutés correctement, ce qui a conduit à la détection d'erreurs lors des tests du côté de l'opérateur. Lors de l'analyse, nous avons découvert qu'il ne s'agissait pas d'erreurs logicielles, mais de paramètres. De telles erreurs font perdre un temps précieux.
Ce que nous avons fait: nous avons mis en place une procédure de vérification des réglages côté client avant de commencer les tests sur les stands de l'opérateur.
La procédure est la suivante: le client choisit les caisses que nous présentons sur le stand configuré. Nous effectuons des tests. S'il y a des erreurs, nous les corrigerons rapidement; sinon, le test est réussi.
Cette approche nous a permis de réduire le nombre d'erreurs associées à des paramètres incorrects lors des tests d'intégration.
Communications supplémentaires autour de la documentation
La vérification des paramètres avant le test en plus de la description de ces paramètres dans les manuels est un exemple de communication supplémentaire autour de la documentation. Il y en avait d'autres.
Par exemple, nous avons fait en sorte qu'à chaque instant, il y ait toujours un spécialiste de notre côté, vers qui le client pouvait se tourner pour poser des questions sur la documentation et le système dans son ensemble. Quelque chose comme une ligne d'assistance technique dédiée avec nos spécialistes hautement qualifiés.
Nos rédacteurs techniques ont organisé des ateliers pour informer les employés des clients sur les nouvelles fonctionnalités.
Le processus de transfert de la documentation est devenu moins discret, plus continu: nouvelles informations, clarifications, recommandations - pourraient désormais être envoyées en plusieurs parties après "l'expédition" des manuels principaux; tel qu'il apparaît ou sur demande.
Tout cela a permis de mieux informer le client sur les nouvelles fonctionnalités et de réduire ainsi le nombre d'erreurs sur les tests d'intégration.
Expertise sur l'utilisation de systèmes tiers
Pour développer la facturation, nous devons être en mesure de suivre le trafic. Il existe des systèmes PCRF séparés pour cela. Les appels sont comptés dans une base de données, les SMS au même endroit et le trafic dans une autre base de données; et il existe un logiciel spécial qui synchronise tout cela.
Dans le même temps, les systèmes PCRF sont des logiciels propriétaires tiers. C'est-à-dire une boîte noire: nous y envoyons des données, nous recevons quelque chose en retour, mais nous ne pouvons pas contrôler ce qui se passe à l'intérieur. De plus, nous ne pouvons rien y changer.
Cet alignement a limité notre capacité à localiser et à corriger les bogues liés au trafic.
Ce que nous avons fait: Nous avons mis en place une base de connaissances PCRF interne distincte. Chaque incident, chaque option de personnalisation, chaque aperçu - tout a été enregistré et partagé par l'équipe.
En conséquence, nous sommes devenus de bons utilisateurs du système PCRF, nous pouvons le personnaliser et comprendre ce qu'il doit faire. Cela permet de gagner du temps sur des incidents simples. Dans les cas complexes, bien sûr, nous nous tournons toujours vers les développeurs du système pour obtenir de l'aide.
Plus de stands
Une autre caractéristique du test de facturation des opérateurs mobiles est que les scripts personnalisés peuvent être étirés au fil du temps. Le script complet que nous voulons tester peut prendre plusieurs jours, voire plusieurs semaines.
Il est difficile d'attendre des jours ou des semaines pendant la phase de test. En réalité, pour vérifier de tels scénarios, le plus souvent, il est simplement temps de se détendre dans la base de données.
Pour revenir en arrière, vous devez fermer toutes les sessions sauf la vôtre. Nous obtenons une situation où, conditionnellement, 20 testeurs peuvent postuler pour deux bancs de test, et tout le monde veut revenir en arrière. Ceci est la file d'attente. Et la file d'attente est la probabilité qu'à la date convenue d'expédition du logiciel, nous n'ayons pas le temps de tout vérifier correctement.
Ce que nous avons fait: installer un stand séparé pour chaque testeur.
Cela nous a permis de supprimer les erreurs survenues en raison du «retard venu mon tour au stand, je n'ai pas eu le temps».
Virtualisation
La préparation du stand n'est pas un processus rapide. Vous devez vous connecter au réseau de l'opérateur, demander l'accès, et ce n'est pas tout. La procédure complète peut prendre plusieurs semaines. La lutte pour réduire le temps de préparation du stand a été une direction importante pour atteindre l'objectif du zéro erreur.
Ce que nous avons fait: la virtualisation activée.
La copie de machines virtuelles avec tous les paramètres nécessaires, les logiciels préinstallés et l'automatisation de ce processus ont permis de réduire le temps de préparation du stand à «en une journée».
Planification
Les erreurs des tests d'intégration sont également le résultat d'erreurs de calcul dans la planification des versions. Nous avons beaucoup balancé, au moment de la date de sortie fixée, tout n'était pas à temps.
Ce que nous avons fait: Introduire des délais intermédiaires pour chaque étape de développement. «Si vous connaissez la date de fin, alors vous connaissez tous les intermédiaires» - ce principe nous a aidés à mieux contrôler la vitesse de déplacement vers l'objectif de sortie.
Support et publication en parallèle
Au début de notre voyage, il y avait une situation où les «dettes» de la dernière version entraient en conflit avec la prochaine version. Après acceptation, les bugs sont arrivés du côté du client et tout le monde est allé les corriger.
Dans le même temps, le calendrier de diffusion n'a pas bougé. En conséquence, au moment où il était temps de s'attaquer à la prochaine version, nous pourrions continuer à travailler sur la précédente.
Il a été possible de changer la situation en raison de la séparation de deux groupes de l'équipe: qui corrigera les erreurs de l'acceptation et qui traitera la nouvelle version dans les délais.
La division était conditionnelle: pas nécessairement la moitié ici, mais la moitié ici. Nous pourrions transférer des personnes entre les groupes au besoin. De l'extérieur, il peut sembler que rien n'avait changé: voici une personne de l'équipe, pendant le sprint, il a travaillé à la fois sur des bugs et de nouvelles fonctionnalités. Mais en fait, la sélection de groupes individuels était une amélioration par rapport à la catégorie «maintenant, nous pouvons expirer». La concentration de chaque groupe et la parallélisation du travail entre les groupes nous ont beaucoup aidés.
Chronologiquement, c'était l'un des premiers points de croissance que nous ayons formulé sur le post-mortem. Et ici mon histoire arrive à la partie sur l'instrument principal.
Outil principal
L'amélioration qui nous a le plus aidés est l'honnêteté des post-mortems.
Quelqu'un appelle cela une rétrospective, quelqu'un - une analyse des résultats; le mot «post-mortem» est resté dans notre équipe. Toutes les améliorations décrites dans cet article ont été inventées sur les post-mortems.
Le principe est simple: il y a eu une sortie, il faut se réunir et discuter honnêtement de la façon dont tout s'est passé. Cela semble simple, mais il y a des pièges dans la mise en œuvre. Après une sortie «infructueuse», les membres de l'équipe ont le sentiment «il n'y a pas le temps de se gratter avec les langues, il faut faire quelque chose». Quelqu'un peut venir aux post-mortems et rester silencieux (et ainsi ne pas fournir certaines des informations potentiellement utiles).
Pendant deux ans passés à atteindre l'objectif de zéro erreur, nous avons développé un certain nombre de principes sur la façon dont nous menons les post-mortems.
- Assemblez l'image complète
Nous invitons une liste élargie de participants. Développeurs, testeurs, analystes, managers, cadres - tous ceux qui ont envie de s'exprimer. Sur le plan organisationnel, il n'est pas toujours possible de rassembler tout le monde, tout le monde. C'est bon, ça marche aussi comme ça. Il ne s’agit pas de nier la participation des collègues avec la formulation «ici dans notre équipe nous résumons les résultats, vous résumez dans la vôtre». Travailler avec des stands, du code, des processus, des interactions - nous nous efforçons de ne perdre de vue aucun aspect.
- Ne saisissez pas tout en même temps
Ok, à la suite du post-mortem, nous sommes arrivés à 30 points de croissance. Combien faut-il prendre pour travailler? Peut-être pourrons-nous y arriver jusqu'à la prochaine fois? Le format «pick 2-3» fonctionnait le mieux pour nous. Dans cette situation, il y a une concentration, et les efforts des personnes de l'équipe ne sont pas diffusés. Il vaut mieux faire moins, mais complètement, que beaucoup, mais ne pas y penser.
- Ne soyez pas intelligent avec le format
Il existe de nombreuses approches pour mener des post-mortems. Pratiques de facilitation, techniques du design thinking et de la pensée latérale, technique de Goldratt et autres experts respectés. D'après notre expérience, le bon sens suffit pour commencer. Nous avons noté les problèmes, les avons regroupés, choisi plusieurs clusters, écarté le reste (voir le point précédent), discuté, fixé le plan. Lorsqu'il y a un objectif commun, trouver une langue commune n'est pas si difficile.
- Prendre au travail
Peut-être le principe principal de cette liste. Aussi prometteuse et convaincante que soit la liste des améliorations basées sur les résultats de l'autopsie, si elle ne fonctionne pas, tout est vain. Nous avons accepté, puis nous le faisons. Oui, il y a d'autres questions urgentes. Mais nous avons aussi un objectif et nous voulons nous en rapprocher.
L'autopsie peut être assez douloureuse. Parler d'échec, même de manière constructive, n'est pas facile. Mais combattre l'inconfort en vaut la peine. Je suis sûr que sans post-mortem, nous n'aurions pas été en mesure de proposer et de mettre en œuvre toutes ces choses qui ont contribué à atteindre l'objectif de zéro erreur dans la version.
L'outil le plus important
Postmortem vous permet de trouver les moyens d'atteindre l'objectif, mais si vous le regardez, cela peut également être appelé une conséquence d'un principe de niveau supérieur.
L'outil le plus important est l'implication de l'équipe.
Il y a un côté instrumental à l'implication. Par exemple:
- si nous faisons des heures supplémentaires, le patron est à côté de l'équipe, aidant de ses mains;
- si vous encouragez l'équipe en suivant les progrès, vous pouvez trouver des mesures visuelles (ce n'est pas difficile pour le nombre d'erreurs).
Et plus loin dans le même esprit.
L'implication a également un côté difficile à formaliser - la capacité de partager avec l'équipe votre croyance en la réussite. Après tout, mon équipe et moi n’avons pas seulement regardé dans la brochure avec les valeurs de l’entreprise, nous y avons vu «plus fort ensemble» et avons décidé que, au bingo, une solution avait été trouvée. Nous avons vu des exemples de la façon dont des objectifs ambitieux peuvent être atteints en unissant leurs forces. Nous avions des gens dans notre équipe qui croyaient au succès et qui ont essayé de transmettre cette conviction à leurs collègues. Le reste est une question de technologie.
Les gens sont la chose la plus importante.
Il y avait beaucoup plus dans la sortie vers l'objectif de zéro bogue. Les travaux d'amélioration de la documentation, d'augmentation de la rapidité et de la qualité de réponse aux questions des clients sont différents. Cette fois, j'ai essayé de ne partager que quelques exemples et de parler des principes de base.
L'équipe et moi avons encore beaucoup à faire dans la lutte pour la qualité des versions et l'optimisation du time-to-market. Rendre le résultat régulièrement reproductible sans aucune erreur sur les tests d'intégration, automatiser la régression.
Il reste à voir comment atteindre ces objectifs. Mais ce que nous savons avec certitude en ce moment: nous allons certainement faire des post-mortems et mettre en œuvre des points de croissance basés sur des motifs. Et nous essaierons d'utiliser les opportunités de l'équipe impliquée.
J'espère que cela vous sera également utile.