Je suis PM au
service de messagerie
UniSender . Il y a 6 ans je suis venu en tant que programmeur, et maintenant je suis responsable de l'interaction entre les équipes produits. Auparavant, notre développement consistait en une équipe distribuée et nous avions 2 problèmes. Mais pas des imbéciles et des routes, mais des retards dans les sprints et des standups ennuyeux pendant une demi-heure.
Je vais vous dire comment nous les avons résolus.
Comme je l'ai dit, nous avons eu 2 problèmes:
- Sprint pourrait s'attarder en raison de la faute d'une tâche . QA et Dev ont travaillé sur le même sprint, les portées des tâches ont été fixées au début du travail, et toute l'équipe s'est précipitée héroïquement pour la mettre en œuvre. Parfois, des bogues urgents arrivaient et allaient aux correctifs "principaux". Les tâches de sprint pourraient être assez volumineuses. Lorsque certaines tâches étaient prêtes à être publiées, d'autres étaient encore en développement. En conséquence, l'équipe pourrait retarder le sprint en raison d'une tâche.
- Les standups prenaient du temps et étaient d'une utilité douteuse . L'équipe s'est agrandie, des stand-up ont été effectués sur Skype, et au début rien n'était de mauvais augure. Nous avons commencé à soupçonner que quelque chose n'allait pas lorsque les positions debout ont commencé à s'étirer pendant 20 à 30 minutes. Les personnes présentes n'ont pas toujours compris ce que faisaient les autres membres de l'équipe.
Pendant un certain temps, nous avons vécu avec ces problèmes, puis nous avons essayé de nous battre.
- Ils ont réduit les stand-up grâce à l'introduction de réglementations sur les humains.
- Ils ont réduit le nombre de personnes présentes - seul le chef d'équipe s'est rendu debout.
- Essais de sprints hebdomadaires.
- Réduction du nombre de tâches dans le sprint.
Ces tentatives n'ont pas donné le résultat escompté. On a compris que des changements radicaux ne pouvaient être supprimés.
Ici, il faut dire quelques mots sur le produit.
Nous sommes une solution SaaS disponible 24/7. En plus de la partie visible pour les utilisateurs - l'interface graphique - nous avons également une grande couche de logique système qui fonctionne indépendamment de l'heure de la journée ou de la situation politique dans le pays. Autrement dit, le développement et la mise à jour du service sont en cours, sans s'arrêter.
Aller à Kanban
La première révolution à grande échelle s'est produite lorsque nous avons réalisé: "Scrum ne nous convient pas."
Nous avons décidé de passer à Kanban. Bien sûr, nous n'étions pas Toyota et n'avons pas commencé à mettre en œuvre la mise en œuvre complète. Par conséquent, "notre kanban" sera différent de "votre kanban".
Sprints et travail d'équipe
En bref sur notre version:
- Nous avons considéré le sprint (une fonctionnalité terminée) comme l'unité de travail.
- Une équipe pour la tâche a été constituée en fonction de la charge et des compétences nécessaires. Une équipe comptait généralement jusqu'à 3 développeurs et 1 QA. Il n'y avait pas d'équipes permanentes.
- Le nombre de sprints simultanés est devenu plus d'un.
- Il n'y avait pas de tableau physique et d'autres attributs de Kanban, les tâches ont été effectuées grâce à l'ajout à Jira.
Dans ce cas, l'équipe a dû faire un sprint du début à la fin. Cela s'applique également à la phase de test: les mêmes personnes qui ont travaillé sur le sprint ont corrigé les erreurs.
Résultat.- Avec le retard de grandes tâches, les autres n'ont pas souffert, dont le développement a été achevé.
- Le nombre de problèmes lors des déploiements a diminué - dans un sprint, il y a moins de tâches hétéroclites.
Standups
Les stand-ups ont été transformés - ils ont été visités par un représentant de chaque équipe qui a travaillé sur un sprint séparé.
Résultat.- Les standups sont devenus comme des standups et nous avons de nouveau commencé à nous adapter aux 10-15 minutes standard.
Ainsi, nous avons pu résoudre des problèmes critiques.
Mais ... tout l'iceberg a commencé à émerger de derrière l'île!
Après le passage à Kanban, nous avons eu une équipe frontend dédiée et il y avait plus d'employés dans l'équipe backend et produit. L'interaction entre les départements est devenue plus compliquée - plusieurs équipes ont pu travailler sur un même projet.
Nous avons résolu certains problèmes, mais de nouveaux sont apparus:
- Tout le monde n'a pas participé à des stand-up - souvent l'équipe a dû relire des informations.
- Un QA pourrait avoir 2-3 sprints parallèles avec différentes équipes. J'ai dû changer: rappelez-vous les fonctionnalités du sprint et redéployez constamment le code sur les environnements de test.
- L'AQ n'était pas pleinement impliquée dans le processus de travail sur les sprints. Souvent, la tâche leur est parvenue à la fin du sprint et les exigences ont été étudiées une fois le développement terminé.
- Les équipes se sont réunies pour le projet et leur composition a souvent changé. Une équipe de deux développeurs pourrait travailler sur 3 sprints simultanément: 2 sprints sur le test plus 1 sprint en cours.
- Il était difficile d'estimer le temps de développement. On ne sait pas combien de temps le sprint inachevé précédent va manger.
Pendant un certain temps, nous avons vécu les nouvelles règles et avons dû faire face à de nouveaux défis. Nous avons essayé différentes approches et rempli beaucoup de cônes.
En fin de compte, nous avons de nouveau commencé à soupçonner que quelque chose n'allait pas. Une nouvelle révolution en devenir.
Division en équipes, nouveaux stand-ups, introduction de Fireteam
Nous avons analysé les processus depuis le début de l'idée jusqu'au déploiement de l'implémentation terminée en prod. Nous avons examiné le fonctionnement des méthodologies agiles dans d'autres entreprises. Nous avons réalisé que nos approches du processus de développement n'étaient pas si mauvaises.
Pas besoin de casser un système qui fonctionne, vous devez réparer les moments qui causent de la douleur.
C'est ce que nous avons changé au cours du processus de développement.
Sprints
Nous fonctionnions toujours sur le concept de «sprint». Sprint est un travail de «près de deux semaines» pour l'équipe.
Quel est le plus. Le code ne «va pas mal» et arrive à la prod sans retards importants. Si l'équipe va faire un sprint dans 2 semaines - vous devez essayer de le resserrer à un mois.
Ce qui peut être amélioré. Souvent, nous manquons la marque et les sprints sont un peu retardés. Le temps de travail sur certains sprints est initialement difficile à évaluer (par exemple, beaucoup de refactoring). Nous devons résoudre ce problème.
Division en équipes
Nous avons divisé une grande équipe en plusieurs petites équipes. Chacun d'eux comprend 2-3 développeurs et un QA dédié. Maintenant, les équipes sont stables et ne changent pas d'un projet à l'autre. Parfois, les gens changent d'équipe pour optimiser les listes ou ajouter l'expertise requise à une équipe. BA participe à l'équipe, mais peut en même temps diriger 2-3 projets.
Bien que le reste soit toujours une équipe)Dans le même temps, toute l'équipe travaille sur un projet du début à la fin. Un projet peut consister en plusieurs sprints.
Quel est le plus.- Les équipes sont dans la même salle. Avant cela, tout le monde était assis dans les départements.
- L'équipe est incluse dans le travail sur le projet du début à la fin, ce qui réduit le facteur bus.
- Les membres de l'équipe sont présents à tous les événements: rétro, stand-up, plénières. Tous les employés sont à jour des tâches en cours.
- L'équipe ne travaille plus sur les sprints des autres. Maintenant, tout est natif.
Ce qui peut être amélioré. Je voudrais introduire pleinement BA dans l'équipe. Cela est problématique car le VA commence généralement plus tôt que le reste de l'équipe.
Travail d'équipe
Une équipe au travail ne peut pas avoir plus de deux sprints: «celui qui est encore à l'épreuve» et «le nouveau que nous verrons». En règle générale, après la fin du développement, tout le monde, au moment de sa sortie, commence à travailler sur un nouveau sprint.
Quel est le plus. Le travail d'équipe est devenu plus prévisible, tout le monde connaît le code et peut prendre en charge le sprint pendant les tests. Les participants sont moins susceptibles de basculer entre les tâches, et le processus de changement est désormais plus rapide.
Ce qui peut être amélioré. Idéalement, une équipe ne devrait avoir qu'un seul sprint en cours. Mais pour l'instant, un monde idéal n'est pas notre monde.
Fireteam
Chaque équipe est élue pour une semaine. Cette commande répond à tous les irritants externes: appels des autres services, comportement anormal du service, correctifs. Nous appelons cette équipe «Fireteam».
Quel est le plus. La semaine Fireteam ne compte pas pour l'équipe dans le temps de sprint. Entre les incendies, les employés peuvent se concentrer sur leurs tâches:
- Refactor.
- Terminez la tâche de sprint.
- Rédiger de la documentation.
- Effectuer un transfert de connaissances avec d'autres équipes.
Inconvénient. Pendant la semaine des équipes de pompiers, la vie de l'équipe est très mouvementée. Tous les départements aiment et connaissent ces personnes en personne, en particulier le support technique. Vous devez constamment basculer entre les différentes tâches: débit, lire les journaux, scier les tâches urgentes et éteindre tous les incendies. Tout cela doit être fait simultanément.
Standups
Nous avons introduit 2 types de stand-up:
- Équipe Ils ont impliqué une équipe qui travaille sur le projet.
- Général Ils ont lieu une fois par semaine, des leads de chaque équipe y participent.
Quel est le plus.- L'équipe est informée de l'état du sprint.
- Les employés savent ce que font les autres équipes.
- Les stand-ups ne se transforment pas en «activités ennuyeuses pour lire sur une feuille de papier certains ensembles de chiffres». Tous les participants comprennent ce qui est en jeu. Il est devenu plus facile de détecter les zones à problèmes au travail.
- Les standups prennent 5 à 10 minutes.
Inconvénient. L'équipe porte toujours des informations à l'équipe.
Résumé
Ainsi, en modifiant progressivement le processus, nous avons résolu la plupart des problèmes urgents:
- Nous avons réuni des équipes stables de 2-3 développeurs et QA. Chaque équipe n'a plus que 2 sprints, les participants ne travaillent pas sur les projets des autres.
- Il y avait une équipe qui traite les messages des autres départements, répond aux comportements anormaux du service et des correctifs. Les autres équipes ne sont pas distraites par ces tâches.
- Aujourd'hui, l'entreprise dispose de 2 types de stand-up: en équipe et en général. Tous les employés sont informés de l'état des affaires du sprint, et un stand-up dure 5 à 10 minutes.
Eh bien, nous travaillons.
