Salut Je m'appelle Dasha, je teste une application mobile 2GIS sur iOS. Je veux partager notre processus de réalisation de fonctionnalités, ce qui permet non seulement de gagner du temps, mais aussi d'améliorer mes compétences personnelles. Lisez l'article pour découvrir comment nous réussissons à maintenir les produits, les concepteurs et le développement dans le même contexte. Nous pensons que l'examen du premier ensemble de tests par toutes les personnes intéressées nous facilite vraiment la vie. Et la communication est la clé de la gestion d'une fonctionnalité.
Notre douleur
Lorsque je communique avec des testeurs d'autres sociétés, je remarque souvent que tester leurs fonctionnalités est en quelque sorte désordonné, non structuré. Pour cette raison, le temps est perdu, la force des personnes impliquées dans le développement. Les gens se mettent en colère, commencent à haïr leurs collègues, les attendent aux porches.
Auparavant, nous avions également quelque chose de similaire: lors de la planification d'un sprint, une tâche a volé, au début du sprint, elle a été prise en compte dans le développement, nous avons élaboré la tâche dans le processus. S'il y avait des questions sur l'interaction avec d'autres équipes, nous sommes allés au produit. Il arrivait souvent que dans certaines équipes, le travail battait déjà son plein: tout le monde attendait avec impatience la sortie, quelqu'un avait déjà rêvé du long métrage au combat; et dans l'autre équipe, ils ne connaissaient même pas son existence. Un tel processus était inefficace, a dépensé beaucoup de temps / d'efforts, a semé le chaos.
En conséquence, ils ont réalisé qu'il était impossible de vivre comme ça et ont commencé à construire un nouveau processus. Il a déjà aidé à sauver les nerfs de quelqu'un et peut-être la vie.
À propos de l'équipe
Notre équipe est composée de: 9 développeurs, 6 testeurs, un produit et un designer. Lors de la planification d'une itération (ce que nous ferons au cours des 4 prochains mois), des fonctionnalités sont compilées que vous souhaitez publier dans la période actuelle. Lorsque la liste est compilée, une fonctionnalité est allouée pour chaque fonctionnalité de l'équipe de développement et de test, qui sera avec les fonctionnalités du début à la fin.
Pour nous, en vedette est une personne qui vit avec des fonctionnalités de TK à libérer. Il dispose d'informations à jour sur ce qui arrive à la fonctionnalité dans son ensemble et sert de point d'entrée pour les questions sur le travail sur les fonctionnalités pour les personnes d'autres équipes. Vous pouvez en savoir plus sur les fonctionnalités à la fin du
rapport de Sasha Kartavtsev . Rappelez-vous ce terme, alors il sera trouvé plus d'une fois.
Sortie en 9 étapes
L'ensemble du processus de mise à disposition des fonctionnalités peut être divisé en 9 étapes principales. Pour plus de clarté, nous prenons la fonctionnalité récemment publiée des «Récompenses» et expliquons comment nous l'avons menée dans les neuf étapes.
Les récompenses récompensent les utilisateurs pour leur contribution au produit. Les utilisateurs les obtiennent pour rédiger des critiques, télécharger des photos, ajouter de nouvelles entreprises au répertoire. Ils sont visibles sur l'onglet «Mon 2GIS».
Étape 1 - Processus de développement des savoirs traditionnels
Avant de commencer à travailler sur les fonctionnalités, nous avons créé un salon de discussion en mou et appelé toutes les personnes impliquées. Nous avons convenu que nous y discuterons de tous les problèmes concernant les fonctionnalités et les événements de la vie des participants au chat qui peuvent affecter le cours de la version. Il n'est pas nécessaire de dire que vous êtes allé chercher du lait, mais vous devez parler de vacances / congés de maladie, sinon vous courez le risque de tomber dans la haine pour ne pas répondre.
Tout d'abord, les fonctionnalités du développement et des tests ont examiné les savoirs traditionnels / conceptions, posé des questions, proposé des améliorations, basées sur l'expérience d'autres fonctionnalités. La fonctionnalité a été surveillée de manière à répondre aux questions dans la journée. Si les délais étaient retardés, alors ces mêmes gars ont laissé entendre au produit / aux personnes responsables que le chronomètre tournait et il serait bien de répondre déjà.
Le processus de développement des savoirs traditionnels est considéré comme terminé lorsque tous les principaux problèmes sont clos, il existe des conceptions finales, le développement n'a pas de questions sur la mise en œuvre des fonctionnalités.
Au premier stade, c'est très cool de faire un prototype d'une fonctionnalité et de l'utiliser dans le développement des savoirs traditionnels: cela aidera à sentir la fonctionnalité sur l'appareil et à identifier les imperfections à un stade précoce, à trouver des cas pour les tests. Les produits pourront apporter des modifications à la logique avant même le début du développement sur la plateforme.
Étape 2 - Élaboration de la liste de contrôle
Dans le processus d'élaboration des TdR, en tant que fonctionnalité de test, j'ai créé des cas de test pour la fonctionnalité dans TestRail, selon lesquels la fonctionnalité a ensuite été vérifiée. Cas prioritaires pour leur automatisation supplémentaire. Puisqu'il y a un backend dans la fonctionnalité, j'ai ajouté une vérification pour cela au plan de test: quels champs nous envoyons, que nous recevons, et que se passera-t-il s'il y a un non-sens incompréhensible ici. Donnons la liste de contrôle terminée au développement et aux produits pour synchroniser les attentes de la fonctionnalité, afin qu'il ne se produise pas que les tests aient pensé à une chose, que le produit en attende une autre et que le développeur ait fait autre chose.
Étape 3 - Développement
Après le développement des TdR, le développement de la fonctionnalité a commencé. Les tests à ce moment-là fermaient / débattaient des problèmes ouverts dans les TdR et la salle de chat, informaient le développement de tous les changements, le cas échéant: nouvelles exigences, nouveaux designs, nouveaux textes, toute autre chose - le développement devrait être au courant de tout, sinon il n'y a aucun moyen d'éviter un combat.
Étape 4 - Examen du premier ensemble de fonctions
Après avoir reçu le premier assemblage, nous l'avons jeté dans un chat de fonctionnalités, où nous avons appelé les produits et les concepteurs pour un examen. Les tests ont permis de vérifier que l'assemblage était visualisé et recevait des commentaires - le plus vite était le mieux. Cela se fait dans les premiers stades, de sorte que les situations désagréables ultérieures ne se produisent pas.
Un exemple de situation désagréableVous vous asseyez tranquillement le soir à la maison, ne touchez personne. Vous pensez que tout est derrière, demain le long métrage ira au combat. Mais à une heure du matin, un produit diabolique fait irruption dans votre maison (c'est réel, car elle vit à trois étages au-dessus de moi) ou le designer (c'est déjà moins réel, il vit loin de moi, mais il a une voiture) avec les exigences pour réparer d'urgence la police / couleur / rembourrage, sinon «ne soyez pas libéré! vous ne pouvez pas sortir comme ça ". Et le matin, la société de relations publiques était déjà décrite, et c'est tout, tout est perdu. Et maintenant, vous êtes assis à deux heures du matin, appelez le développeur, commencez les tickets. En général, les commentaires reçus en temps opportun des bonnes personnes sont précieux. L'obtenir au tout début ne vous permettra pas de resserrer la libération de ce flanc.
Étape 5 - Test de la plateforme
Parallèlement à l'examen du premier assemblage, les tests ont commencé sur la plate-forme à l'aide de cas de test compilés plus tôt. Au cours du processus de test, si vous rencontriez des problèmes qui menaçaient de perturber la publication, ou réalisiez que quelque chose pourrait être mieux fait, ils ajouteraient des fonctionnalités au chat ou laisseraient un commentaire dans l'énoncé des travaux. Nous nous sommes assurés que la question ne restait pas ouverte.
À la même étape, il y a eu des changements dans la logique des fonctionnalités (interface utilisateur, par exemple) - ils ont également donné l'assemblage au produit et au concepteur pour un examen afin de s'assurer que les attentes coïncidaient avec la réalité.
Étape 6 - Test d'intégration
Cet élément est nécessaire si des équipes autres que les téléphones mobiles participent au développement de la fonctionnalité. Par exemple, téléphones mobiles + backend. Si nous remplaçons la police ou la couleur de l'icône, alors, bien sûr, aucune intégration n'a lieu. Cependant, dans notre exemple avec Rewards, un backend est impliqué - l'intégration était indispensable.
La première chose à faire a été de faire un quai à Confluence. En règle générale, au début, une personne le fait.
Le document prescrit:
- dates d'exécution;
- les participants - pour que l'équipe connaisse les héros à vue et que les héros ne puissent pas réfuter ce fait;
- liste des chèques;
- liste des cas - vérification des scénarios avec des conditions spécifiques.
Après avoir compilé un dock, je l'ai jeté dans le chat des fonctionnalités et j'ai appelé tous les participants à l'intégration à revoir / compléter les cas.
Le jour X, les participants à l'intégration se sont réunis dans un bureau et ont vérifié tous les scénarios à partir des quais d'intégration. C'est formidable de réaliser des intégrations conjointes avec l'équipe backend - vous résolvez immédiatement tous les problèmes sur place et clarifiez toutes les bizarreries.
Étape 7 - Briefing de support
Avant la sortie, ils ont informé le support qu'une fonctionnalité sera bientôt disponible, il est temps de se préparer. Dali a lu TK, poke assembly. Ils ont indiqué les chats à écrire et les personnes à contacter s'ils reçoivent des commentaires des utilisateurs.
Étape 8 - Sortie
Nous avons commencé à rouler la fonctionnalité, notifié le chat à ce sujet et en parallèle regardé Crashlytics, les commentaires dans le magasin et le support. Nous espérions le meilleur, buvait de la valériane. Tout s'est bien passé avec les récompenses, mais nous étions prêts à créer immédiatement un correctif et à informer tout le monde dans le chat des fonctionnalités si, lors du déploiement, un bug critique avait été détecté du côté de la plate-forme.
Étape 9 - Prise en charge des fonctionnalités après la sortie
Après que la fonctionnalité soit entrée dans la bataille, notre rôle est devenu informatif: ils ont répondu aux questions entrantes, invité, trié certains problèmes de plate-forme ou, s'ils comprenaient que le problème était sur le serveur, les ont transmis. Après la sortie, j'ai également versé les étuis sur le chèque Récompenses dans le stockage principal des étuis dans la piste de test afin qu'ils puissent être réutilisés à l'avenir.
Et si brièvement
- Gardez toujours tout le monde dans le même contexte. Signalez les changements importants.
- Dès qu'un assemblage avec fonctionnalités apparaît, organisez une revue du premier assemblage par toutes les parties intéressées.
- Si des changements surviennent dans la logique d'une fonction à un stade quelconque, organisez également une révision.
- Obtenez la réponse: écrivez, appelez, donnez un coup de pied jusqu'à ce que vous répondiez.
- Préparez la prise en charge d'une nouvelle fonctionnalité et aidez-la après le lancement.
Les connaissances et l'expérience que j'ai acquises dans le processus m'aident à la fois au travail et dans la vie. J'ai pompé la communication, l'indépendance, la responsabilité, je me suis plongé dans le produit au-delà du travail de notre équipe. Soit dit en passant, l'équipe est également heureuse - dans le cas d'un fakap, il boit maintenant du vin, pas de la valériane.