Comment coordonner le temps de développement entre deux projets différents dans Scrum?


40

Je suis devenu le scrum master d'une équipe nouvellement créée, chargée de créer un logiciel ET de gérer d'autres applications déployées. Donc, fondamentalement, chaque membre de l'équipe a des tâches de développement et d'opérations.

J'ai observé leur fonctionnement ces 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 une tâche précédente.

J'ai essayé d'allouer% de temps de développement aux opérations, mais apparemment cela ne résout pas le problème. Ce qui m'intéresse, c’est d’entendre les commentateurs qui ont déjà vécu cette situation, comment vous y êtes pris et quelles sont vos recommandations?


1
Priorisez et résolvez d'abord le bogue de production critique, puis reprenez un développement normal. Les deux en même temps demandent qu'une erreur soit commise.
Mark Rogers

Réponses:


60

Ce problème est aussi vieux que Scrum. Il existe une solution, mais vous ne l'aimerez pas.

  • Mettez de nouvelles tâches sur l'arriéré.
  • N'interrompez pas les développeurs.
  • Attendez le prochain sprint.

Le fait de placer vos développeurs dans plus d'une mêlée, d'avoir deux arriérés distincts ou d'attribuer seulement un pourcentage de leur temps au sprint va à l'encontre de ce que Scrum tente de réaliser, à savoir un flux cohérent de tâches terminées.

Si vous essayez ce genre de choses, vous retournez aux méthodes de développement du «chaos» ou du «JFDI» avec tous leurs problèmes, par exemple:

  • Le développeur a dix tâches à la fois. Personne ne sait sur quoi ils travaillent ou quand ce sera fini.
  • Temps inconnu pour terminer le projet, car cela dépend de ce que d'autres projets se déroulent en même temps.
  • Pas de vision cohérente de la priorité du projet. D'autres gestionnaires orientent les développeurs vers leurs projets favoris.

Bien sûr, la réponse habituelle à cet avis est "Mais je ne peux pas faire ça! L'entreprise a besoin que ces bogues de production soient corrigés dès que possible!"

Mais ce n'est pas vraiment vrai.

Si vous avez vraiment autant de bugs qui affectent votre entreprise dans cette mesure, vous devez devenir professionnel et améliorer vos tests. Travaillez simplement sur les bogues et les tests automatisés jusqu'à ce que vous les ayez tous corrigés. Embauchez une équipe d'assurance qualité 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: manque d’espace disque, pas de reprise après sinistre, pas de sauvegarde, pas de basculement, etc. Faites appel à une équipe OPS.

  • Les bogues sont des utilisateurs qui ne comprennent pas comment le système devrait fonctionner "C'est arrivé! Est-ce un bogue?". Obtenez un service d'assistance et formez vos utilisateurs, écrivez de la documentation.

  • Peur de revenir en arrière. Vous avez lancé une nouvelle fonctionnalité qui a cassé quelque chose. N'essayez pas de trouver une solution. Revenez à la version précédente et mettez les bogues dans l'arriéré.


5
combien de temps dure ton sprint? Je voudrais descendre à une seule semaine
Ewan

3
Vous pouvez vous en tirer en ne faisant pas l'examen et le rétro, peut-être les faire une fois par mois. La conception (conception d'interface utilisateur?) En tant qu'équipe / sprint séparée est une bonne idée, je pense. J'espère que la plupart du temps, la conception est faite avant le début du développeur et ne change pas trop
Ewan

3
Le propriétaire du produit souhaite que les développeurs abandonnent tout et travaillent sur les bogues de production, arrêtent le sprint actuel, corrigent le bogue et lancent un autre sprint à la fin. Ces décisions ont des conséquences et feront en sorte que le responsable du produit réalise l’impact sur les correctifs de bogues immédiats. Ils devront faire preuve de plus de discrétion lorsque les choses sont considérées comme une urgence. Ou vous pouvez attendre et vous adresser à eux lors du prochain lever. De cette façon, vous pouvez voir qui a de la bande passante supplémentaire et vous n'interrompez pas le flux du développeur.
JeffO

5
Si vous ignorez la critique et le rétro et créez le design dans un sprint séparé, il ne reste plus vraiment de Scrum ...
Erik

6
Votre solution consiste à "acquérir l'autorité suprême dans l'entreprise, puis dépenser beaucoup d'argent en créant trois nouvelles équipes"?
Courses de légèreté avec Monica Le

25

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 encore y avoir des erreurs critiques qui ne peuvent tout simplement pas attendre, telles que rencontrer des clients pour lesquels une assistance aux développeurs est nécessaire, etc.

Pourquoi ne pas essayer d’anticiper cela et de l’utiliser à votre avantage?

Vous aurez besoin d’une équipe de 5+ pour que cela soit réaliste peut-être.

Mais pourquoi ne pas supprimer un développeur à chaque sprint (en alternance, 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
  • Exploration des fonctionnalités linguistiques que vous souhaitez utiliser
  • Lecture sur les questions de sécurité
  • Maintenance de la base de données
  • Maintenance du serveur

La vélocité de l'équipe peut augmenter, le stress peut diminuer, les conflits avec la direction peuvent diminuer, vous avez le temps d'améliorer vos connaissances.


3
Je pensais la même chose - permettez à un développeur de faire les "tâches" (problèmes de production) et comme il ne va pas faire beaucoup de travail, laissez-le faire la recherche / exploration / autre chose irrégulière. Et faites une bonne analyse des causes profondes de chaque problème de production afin d’en réduire le nombre.
RemcoGerlich

1
C'est en fait une très bonne idée! Je vais avoir besoin d'embaucher un ou deux autres développeurs, mais je pense que cela en vaut la peine. Merci beaucoup!
Shadin

1
Sur notre projet, nous avons formalisé cette position dans une certaine mesure. Nous avons un développeur senior dans chaque équipe qui est désigné comme responsable technique pour l'équipe Scrum. TL fait un certain nombre de choses (mentor des développeurs juniors, "4 + 1 plans" avant la production, résoudre les problèmes d'autres développeurs à mesure qu'ils se présentent, etc.) défauts de haute priorité. Évidemment, BEAUCOUP dépend de votre système de production / de votre philosophie, mais le TL peut intervenir pour "protéger" le reste de l'équipe et lui permettre de se concentrer sur les histoires d'utilisateurs.
JBiggs

14

L '"approche Batman" est une solution efficace pour gérer les efforts des développeurs concernant des problèmes de production vraiment essentiels.

L’aspect coûteux de la responsabilité de l’assistance à la production lors du développement de nouvelles fonctionnalités est le changement de contexte, vous devriez donc vous limiter.

Avec l’association de l’équipe, créez une liste des membres de l’équipe et parcourez-la de manière à ce que chaque jour une nouvelle personne soit déclarée «Batman» lors de la réunion informelle et réponde 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 liée au soutien. Avec une équipe de 5 personnes, le développeur peut être interrompu un jour par semaine et dispose de 4 jours de temps de développement prévisible et ininterrompu.

Cela présente l'avantage de partager les connaissances et l'expérience au sein de l'équipe. Vous n'avez donc aucune personne chargée de résoudre des problèmes particuliers et de devenir un point de défaillance unique et une répartition équitable des problèmes de support.


Une approche très intéressante et je crois que cela est applicable dans notre situation maintenant! Merci beaucoup!
Shadin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.