Comment coordonner le temps des développeurs entre deux projets différents dans Scrum?
Je suis devenu le scrum master d'une équipe nouvellement créée, chargée de créer un logiciel ET de maintenir d'autres applications déployées. Donc, fondamentalement, chaque membre de l'équipe a des tâches de développement et d'exploitation.
J'ai observé leur fonctionnement au cours des deux dernières semaines et j'ai remarqué que l'équipe avait du mal à coordonner ces tâches. lorsqu'un développeur se concentre sur le codage, il est interrompu pour résoudre un problème soulevé en production, et il lui est difficile de se concentrer à nouveau sur la tâche précédente.
J'ai essayé d'allouer% du temps du développeur pour les opérations, mais apparemment, cela ne résout pas le problème. Je suis intéressé à entendre les scrum masters qui ont rencontré cette situation auparavant, comment l'avez-vous gérée et quelles sont vos recommandations?
Ce problème est aussi ancien que la mêlée. Il existe une solution, mais vous ne l'aimerez pas.
- Mettez de nouvelles tâches dans l'arriéré.
- N'interrompez pas les développeurs.
- Attendez le prochain sprint.
Mettre vos développeurs dans plus d'une mêlée, avoir deux backlogs distincts ou affecter seulement un pourcentage de leur temps au sprint, tout cela va à l'encontre de ce que la mêlée essaie d'atteindre, c'est-à-dire un flux cohérent de tâches terminées.
Si vous essayez ce genre de choses, vous revenez essentiellement aux méthodologies de développement `` chaos '' ou `` JFDI '' avec tous ses problèmes, par exemple.
- Le développeur a dix tâches en cours à tout moment. Personne ne sait sur quoi ils travaillent ou quand ce sera fini.
- Temps inconnu pour terminer le projet, car cela dépend des autres projets qui se déroulent en même temps.
- Pas de vision cohérente de la priorité du projet. D'autres gestionnaires détournent les développeurs vers leurs projets favoris.
Bien sûr, la réponse habituelle à ce conseil est "Mais je ne peux pas faire ça! L'entreprise a besoin que ces bugs de production soient corrigés dès que possible!"
Mais ce n'est pas vraiment vrai.
Si vous avez vraiment autant de bogues réels qui affectent l'entreprise à ce point, vous devez devenir professionnel et améliorer vos tests. Il suffit de travailler sur les bogues et les tests automatisés jusqu'à ce que vous les ayez tous corrigés. Embauchez une équipe QA et testez l'enfer de toutes les nouvelles versions.
Ce qui est plus probable cependant est l'un des suivants:
Les bogues sont des problèmes opérationnels, manquant d'espace disque, pas de DR, pas de sauvegardes, pas de basculement, etc. Obtenez une équipe OPS.
Les bogues sont des utilisateurs ne comprenant pas comment le système devrait fonctionner "C'est arrivé! Est-ce un bogue?". Obtenez un service d'assistance et formez vos utilisateurs, rédigez de la documentation.
Peur du recul. Vous avez lancé une nouvelle fonctionnalité et elle a cassé quelque chose, n'essayez pas de précipiter un correctif. Revenez à la version précédente et mettez les bogues dans le backlog.
J'essaie juste de sortir des sentiers battus ici.
Comme il pourrait ne pas être possible de faire en sorte que le propriétaire du produit voie les choses à votre façon. Il peut toujours y avoir des erreurs critiques qui ne peuvent tout simplement pas attendre, rencontrer des clients où l'aide des développeurs est nécessaire, etc. où vous devez retirer un développeur du sprint pendant un certain temps.
Pourquoi ne pas essayer d'anticiper cela et de l'utiliser à votre avantage?
Vous aurez besoin d'une équipe de 5+ pour que ce soit réaliste peut-être.
Mais pourquoi ne pas retirer un développeur à chaque sprint (en tournant entre les développeurs, chacun a son tour).
Comme il n'y a probablement pas assez d'erreurs pour utiliser un développeur complet pour les corrections, d'autres problèmes ou tâches peuvent être effectués.
- Exécution de tests pour identifier les goulots d'étranglement des performances ou les problèmes d'évolutivité
- Maintenir le système de construction
- Rencontres avec les clients
- Recherche de nouveaux cadres/bibliothèques
- Explorer les fonctionnalités linguistiques que vous souhaitez utiliser
- Lire sur les problèmes de sécurité
- Maintenance de la base de données
- Maintenance du serveur
La vitesse de l'équipe peut augmenter, le stress peut diminuer, les conflits avec la direction peuvent diminuer, vous avez en fait le temps d'améliorer vos connaissances.
Une solution efficace pour gérer les efforts des développeurs pour les problèmes de production vraiment essentiels que j'ai utilisés est "l'approche Batman".
L'aspect coûteux de la responsabilité du support de production lors du développement de nouvelles fonctionnalités est le changement de contexte, vous devez donc viser à limiter cela.
Avec l'adhésion de l'équipe, créez une liste des membres de l'équipe et parcourez-la, de sorte que chaque jour, une nouvelle personne soit déclarée "Batman" lors de la réunion debout et répondra aux problèmes de production essentiels ce jour-là. Le reste de l'équipe peut rester concentré sur le développement sans avoir à changer de contexte et tout le monde a une part équitable de la douleur du soutien. Avec une équipe de 5 personnes, c'est un jour par semaine où un développeur peut être interrompu et 4 jours de temps de développement prévisible et ininterrompu.
Cela a l'avantage de partager les connaissances/l'expérience au sein de l'équipe, de sorte que vous n'avez pas une seule personne responsable de résoudre des problèmes particuliers et de devenir un seul point d'échec et une répartition équitable des problèmes de support.