Parfois, les jeunes équipes de développement se retrouvent dans un pétrin.
Cela se produit à un moment où ils n'ont pas encore pleinement compris ce qu'est un avantage; Le projet et le produit se disputent lequel d'entre eux est qui, et chacun effectue des tâches de manière autonome. Ou tout le monde sait déjà tout, mais les sprints ne peuvent pas être planifiés - les tâches ne sont pas élaborées, les démos et les rétro ne sont pas réguliers.
Nous avions aussi une histoire similaire, mais nous avons trouvé notre chemin.
Ceci est une histoire de l'équipe du compte personnel Yandex.Cash, et les instructions les plus détaillées pour ceux qui veulent améliorer leur planification.
Comment c'était
L'équipe de compte personnel Yandex.Kassa est responsable de la commodité de connecter de nouveaux commerçants à la caisse et effectue un service de facturation. Selon les normes Yandex, l'équipe est jeune - 4 développeurs sur 6 travaillent six mois ou moins, et moi, le chef de projet, avons rejoint l'équipe il y a 3 mois.
Le premier jour du nouveau sprint, l'équipe s'est réunie avec le propriétaire du produit (ci-après - PO) et a planifié le sprint pendant environ deux heures. Cette approche présente des inconvénients évidents:
- Faible élaboration des exigences. PO n'a pas eu suffisamment de temps pour répondre à toutes les questions. Nous avons soit pris ces tâches dans le sprint, soit demandé aux analystes d'évaluer la tâche et reporté sa mise en œuvre jusqu'au début du prochain sprint.
- Il y avait des situations dans lesquelles les parties prenantes se souvenaient lorsque le sprint battait son plein et nous avions besoin d'urgence de certaines améliorations ou solutions de la part d'équipes connexes.
- Manque de gestion des risques.
Avec leur considération, les exigences d'un nouveau processus sont apparues:
- Les exigences relatives aux tâches doivent être définies par le propriétaire du produit et toutes les parties intéressées.
- Dod implémenté (la définition de done est un ensemble de critères qui vous permettent de comprendre si quel était le but du développement) pour chaque activité. Ils ont commencé à identifier les parties prenantes afin qu'une semaine avant le début d'un nouveau sprint, ils soient informés de l'avancement des travaux et recueillent des retours d'expérience.
- Réunions minimales pour se concentrer sur le sprint actuel. Limité à deux réunions en deux semaines d'une heure chacune.
- Ils ont commencé à organiser régulièrement une formation interne sur les produits en équipe, car aujourd'hui l'un des principaux risques est le manque de connaissances sur le produit.
De nouveaux concepts
Nous avons introduit de nouveaux conteneurs (listes) de commandes:
La priorité des tâches dans toutes les listes sauf la première est déterminée par PO.
Si les tâches sont terminées dans le sprint, un membre de l'équipe peut prendre les tâches d'Estimated dans le travail et comprendra qu'il est complètement prêt pour le travail - prenez-le et faites-le.
Première semaine
Par clic - version complète.
Lundi
Le responsable du produit déplace les activités du conteneur Liste des tâches vers le nettoyage, hiérarchise et décrit la définition de Terminé aussi clairement que possible.
Le PM vérifie l'activité dans le conteneur de toilettage par rapport à la liste de contrôle:
- Des dispositions sont-elles nécessaires pour de nouvelles activités et, si oui, le sont-elles?
- Toutes les activités du projet le plus important ont-elles été incluses?
- Les liens entre les tâches sont-ils indiqués?
Si quelque chose ne va pas, le PM communique avec le PO pour clarifier les détails et informe l'équipe que la liste de toilettage est à jour.
Un exemple:
- Prenez la tâche "Les lettres sur les factures émises la nuit sont envoyées avec retard." Il a été ajouté par le testeur à la fin de la liste de toilettage.
- PO a soulevé cette tâche sur la liste.
- Le PM a vérifié que l'activité de travail avec le conteneur de la part de PO avait été effectuée et en a informé l'équipe.
Mardi
L'équipe se familiarise avec les nouvelles activités et écrit des commentaires, des questions et fait des suggestions. PO reçoit automatiquement tous les nouveaux commentaires (nous utilisons Jira, donc c'est facile à faire), et il a le temps de préparer les réponses d'ici demain.
Un membre de l'équipe a précisé si la tâche était pertinente. Il s'est avéré que la tâche était pertinente, le testeur a trouvé la cause du problème et l'a signalé. Cependant, du point de vue de la logique métier, la question est restée ouverte.
Mercredi
Nous avons une rencontre avec le PO qui répond aux questions de l'équipe. Le but de la réunion: fixer le DoD. Après la réunion, une partie des activités ira dans le conteneur «Défini» et une partie - immédiatement dans «Estimé», s'il est immédiatement évident combien de temps cette activité prendra. Définissez les dépendances et les parties prenantes.
Un dialogue entre le PM et l'OP, après quoi il est devenu clair ce qui doit être fait. Habituellement, ce dialogue n'est pas fixe, mais c'est à cause de cette activité que l'OP n'était pas disponible pendant la réunion, donc la communication a été enregistrée par écrit.
Jeudi
Le PM envoie une liste des activités à proximité de la liste estimée et définie aux parties intéressées avec une demande de consultation et de commentaires.
Vendredi
Le PM répond aux questions des parties prenantes, impliquant une équipe ou un PO si nécessaire.
Aucun commentaire n'a été reçu sur la tâche, que nous montrons à titre d'exemple, mais en général, elle ressemble à ceci:
Les commentaires peuvent provenir du messager.
Le résultat de la première semaine est une activité, selon laquelle il est clair ce qui doit être fait (dod est déterminé), en tenant compte des souhaits des parties intéressées.
Deuxième semaine
Lundi
L'équipe évalue de manière indépendante les activités de la liste "Défini" et la décomposition des activités de la liste "Estimé". PO n'est pas impliqué ici, car il est responsable de fixer des objectifs de la part de l'entreprise et il n'est pas de sa responsabilité d'évaluer la façon dont tout ce qui est prévu est fait.
Mardi
Il y a une deuxième réunion avec PO, au cours de laquelle l'équipe peut clarifier les détails et communiquer leurs notes. PO peut vous informer de nouveaux événements d'introduction qui peuvent s'être produits au cours de la semaine écoulée, ainsi que clarifier pourquoi l'activité est précisément de telles estimations, et pas moins.
Mercredi
Il y a une démo sur le sprint actuel. À la suite de la démo, de nouvelles activités sont généralement formées, dont certaines doivent être terminées avant la fin de la semaine, et le reste au prochain sprint. Le but de la démo est de recueillir des commentaires. L'équipe présente le résultat de leur travail et reçoit un retour rapide sur le travail de la nouvelle fonctionnalité.
La démo est interne et externe .
La démo interne concerne PO, où il évalue si l'équipe a atteint le résultat escompté ou si des améliorations sont nécessaires. Elle est réalisée par un testeur sur un environnement de test.
La démo externe est destinée aux parties intéressées. Se produit après le calcul de nouvelles fonctionnalités «à la bataille», le conduit PO.
Après la démo, de nouvelles activités sont ajoutées au backlog et, selon leur priorité et leur note, peuvent être ajoutées au sprint en cours. Nous effectuons spécifiquement une démo au milieu de la deuxième semaine afin d'avoir du temps pour les améliorations jusqu'à la fin du sprint.
Jeudi
PO donne la priorité aux listes définies (si pendant le sprint les activités sont terminées avant la date prévue, alors de nouvelles activités peuvent être prises à partir de cette liste) et estimées (les activités de cette liste sont transférées au nouveau sprint).
Vendredi
La planification du sprint a lieu, à laquelle l'équipe de développement PM et PO participe.
Il y a un rétro où nous discutons de la façon dont nous avons travaillé dans le sprint actuel et si nous étions bien préparés pour le prochain: échange d'opinions, si tout est clair sur le sprint à venir, si nous avons encore suffisamment de ressources dans la ressource pour corriger les bugs inattendus.
Une réunion de gestion des risques est en cours. En ce moment, nous consacrons ce temps à l'étude du produit, car son excellente compréhension réduit considérablement les risques. Le PM et les testeurs pendant la semaine allouent du temps pour étudier le produit et partagent le résultat avec l'équipe. Des représentants des unités sont invités à la réunion pour compléter la photo.
Un vendredi sur deux marque la fin non seulement de la semaine de travail, mais aussi du sprint. C'est une journée de communication et de feedback. Ainsi, le lundi de la nouvelle semaine de travail commence par des tâches claires et appréciées, ce qui est également logique et confortable pour l'équipe.
Conclusions et prochaines étapes
Grâce à ce processus, il a été possible d'établir une interaction de haute qualité entre l'OP et l'équipe, les conflits et les malentendus sont du passé. Le climat dans l'équipe s'est amélioré et un sens du travail rythmique harmonieux est apparu. Bien sûr, il y a encore beaucoup de problèmes, mais il y a beaucoup moins de situations d'urgence et imprévues dans lesquelles l'équipe ou le PM a dû sauver le projet.
Comme tous les êtres vivants, notre processus nécessite de temps en temps une mise à jour. Nous voyons maintenant qu'il vaut la peine de finaliser dans les domaines suivants:
- Bugs. Le travail avec les bogues doit également être planifié. Nous ne pouvons pas effectuer les bogues émergents dans le processus de planification de sprint, plus de travail opérationnel est nécessaire ici. Nous réfléchissons à la façon de procéder.
- Nous voulons faire un tableau des risques typiques afin de les prendre en compte et réduire la probabilité d'erreurs dans la mise en œuvre du sprint.
- Lors de la planification d'un sprint, nous souhaitons nous appuyer sur l'objectif du sprint pour rester concentré sur le travail. L'équipe est jeune, il y a donc des difficultés avec cela.
Nous espérons que notre expérience aidera votre équipe. Nous sommes prêts à discuter de notre approche dans les commentaires, répondre aux questions ou donner des conseils.