Comment SCRUM gère-t-il un environnement où les membres de l'équipe sont partagés?

Eh bien, les questions se sont dites. Dans mon lieu de travail, ces cas se produisent, mais aussi, de nombreux livres Agile encouragent le travail dans le même lieu de travail et la concentration dans le projet actuel pour accélérer le rythme de travail.

Peut-être que je ne suis pas très informé sur le sujet, peut-être que ce n'est pas si strict mais, c'est pourquoi je voulais savoir ce que propose Agile dans des cas comme ceux-là.

N'importe qui?

Dans la méthodologie Scrum, cela affecte simplement l'estimation.

Vous affecteriez un facteur de concentration pour cette personne en fonction de l'allocation de son temps à chaque projet.

Donc, si je travaille également sur le projet A et le projet B , le projet A calculera les ressources comme suit:

Projet A - Facteur de focalisation de l'équipe de 70%
Sam - 10 jours, allocation de 100% (7 après facteur de focalisation)
Joe - 10 jours, allocation de 100% (7 après facteur de focalisation)
Moi - 10 jours, allocation de 50% (3,5 après facteur de focalisation) )
Total: 25 jours * facteur de focalisation de 70% = 17,5 vitesse projetée

Vous pouvez également calculer le facteur de focalisation séparément pour les membres de l'équipe à temps plein et pour les membres de l'équipe à temps partiel plutôt qu'une seule fois pour toute l'équipe, en raison de l'efficacité réduite du fractionnement des projets. Dans ce cas, vous utiliseriez mon facteur de focalisation de projet de 50% et le multiplieriez par une allocation personnelle de 50% pour 25%, ou 2,5 jours de vitesse projetée .

Dans quelle mesure cela fonctionne dans la pratique, cela dépendra de la façon dont vous savez à l'avance combien de temps une ressource partagée va passer sur chaque projet, et dans quelle mesure Scrum travaille pour vous par d'autres moyens.

D'après mon expérience dans Scrum, la vitesse ne peut être prédite que si le projet et l'équipe restent les mêmes et dévoués. Si l'une de ces choses change, vous ne pouvez pas vraiment utiliser les calculs de vitesse des sprints précédents pour faire votre estimation. Vous pouvez essayer, mais vous serez beaucoup plus loin que d'habitude.

En général, vous devriez certainement essayer de garder l'équipe la même et dédiée au MOINS tout au long d'un sprint, plus si vous le pouvez.

À mon avis, cela affectera très gravement tous les projets. Il ne s'agit pas seulement d'estimer ou de planifier. Oui, vous pouvez dire que si les membres de l'équipe sont affectés à trois projets et qu'ils ont une allocation de 33% pour chaque projet, vous savez tout ce dont vous avez besoin et vous avez terminé, mais ce n'est pas vrai.

La commutation de contexte est très coûteuse. Il est également impossible de maintenir un engagement total envers plusieurs projets parallèles, de sorte que ces 33% de temps de développeur sont loin de 33% lorsque le développeur n'est affecté qu'à un seul projet.

Un autre endroit où cela échoue totalement est la communication. Que se passe-t-il si un membre de l'équipe travaillant actuellement sur le projet A doit communiquer quelque chose avec un membre de l'équipe ayant travaillé sur le projet A hier mais travaillant actuellement sur le projet B? C'est un obstacle pour les deux parce que le premier a besoin d'informations mais le second est concentré sur un projet complètement différent et toute question pour le projet A le dérange. Scrum master du projet A veut que son développeur obtienne les informations le plus rapidement possible et Scrum master du projet B ne veut pas que son membre de l'équipe soit dérangé par tout ce qui n'est pas lié au projet B. Si vous voulez éviter cela, vous devez tout planifier les développeurs de l'équipe de travailler sur le même projet dans les mêmes jours - c'est une grosse complication pour l'ensemble du processus de planification et quelque chose qui devrait être complètement évité.

Vous devez également planifier toutes les réunions pour ne pas entrer en collision. Vous devez également comprendre que la réunion est en fait un gaspillage et, à cause de cela, il devrait y avoir un nombre minimum requis de réunions aussi court que possible pour garder le contrôle du processus. Mais si un membre de l'équipe travaille sur trois projets, il doit participer à toutes les réunions pour ces trois projets => trois fois plus de réunions où le développeur ne produit aucune valeur commerciale.

En conclusion, l'agile consiste également à réduire les déchets (oui, c'est de l'approche Lean) et le partage des membres de l'équipe entre les équipes est l'un des pires échecs en termes d'introduction de déchets et de réduction de la productivité. Je suppose que la valeur commerciale livrée pour une allocation de 33% à un seul projet sera égale à la valeur commerciale livrée de 10 à 16% de l'allocation à temps plein. Cela signifie que le développeur participera non seulement 1/3 fois sur le projet, mais pendant ce temps sa productivité sera comprise entre 1/3 et 1/2.

SCRUM est basé sur une équipe engagée sans membres partagés, donc vous pourriez tout aussi bien demander:

Étant donné qu'on nous a dit que nous devons faire vrai == faux, comment faisons-nous x

Si ce n'est pas SCRUM, ne l'appelez pas SCRUM!

La question clé concerne l'engagement du membre de l'équipe dans le projet. Idéalement, un membre de l'équipe devrait être totalement engagé dans la réussite du projet. Cela ne signifie pas que son temps est entièrement consacré au projet, mais qu'il est disponible pour effectuer toutes les tâches requises pour le projet lorsqu'il travaille sur le projet.

Souvent avec du personnel qui ne travaille qu'à temps partiel sur un projet, ils ne sont impliqués que pour une portée d'engagement limitée. Par exemple, vous pouvez avoir une personne qui ne fait que l'optimisation de la base de données.

Dans ce cas, il est souvent préférable de traiter cette personne comme une «ressource» plutôt que comme un membre de l'équipe. L'équipe décide de la quantité de ressources dont elle aura besoin dans un Sprint particulier et leur donne un ensemble de tâches très spécifiques à accomplir pour le Sprint. Parfois, il est préférable que l'équipe ait un membre de l'équipe particulier responsable de cette ressource, et qu'il fasse les mises à jour de statut et les rapports d'obstacles pour cette ressource dans le Scrum quotidien.

Je crois que l'un des aspects fondamentaux de Scrum est de garder l'équipe concentrée sur une seule chose à la fois (un projet, une histoire, une tâche ...)

Vous avez demandé "ce que propose Agile" dans le cas où vous ne pouvez pas allouer les ressources à un projet ... Vous pourriez envisager d'essayer l'un des:

• Gardez un grand tableau Kanban qui couvre les multiples projets. Comme un projet a un besoin, il est ajouté au tableau, car les gens ont la capacité, ils tirent les histoires clés. Le problème est que tous les projets sont gérés ensemble, ce qui diminue la prévisibilité globale pour n'importe quel projet. Cela dit, les éléments histoire / Kanban individuels seront extraits et développés par une personne ou une équipe ciblée. (Vous pouvez essayer de créer de plus petites équipes de 4 à 5 personnes à tirer du tableau Kanban
• Affectez uniquement des ressources engagées. Conservez un pool de ressources dédiées à un projet. Ceux-ci sont protégés en équipe et les interruptions sont maintenues proches de zéro. Gardez également une «équipe d'intervention rapide» qui n'a pas de carnet de commandes et qui ne se concentre pas sur un projet / produit. Au fur et à mesure des interruptions, l'équipe d'intervention rapide s'occupe des interruptions. Quand ils n'ont pas d'interruptions, ils peuvent se concentrer sur l'amélioration du système de construction, l'ajout au cadre de test d'automatisation, etc. Gérez le développement comme si cette équipe n'existait pas. Tout ce qu'ils peuvent faire, c'est retirer la livraison. Faites tourner les gens dans cette équipe pour "garder la fraîcheur" (les gens semblent aimer / détester faire partie de l'équipe d'intervention rapide ...)

J'espère que cela t'aides!