Comment Scrum fonctionne-t-il lorsque vous avez plusieurs projets? [fermé]

Je suis assez bien lu dans les avantages et les processus de Scrum. J'obtiens les idées sur le backlog, les graphiques de burndown, les itérations, en utilisant des user stories, et d'autres divers concepts du «framework» Scrum.

Cela dit ... Je travaille pour une firme de développement Web qui gère plusieurs projets à la fois, avec six membres de l'équipe qui composent "l'équipe de production".

Comment Scrum fonctionne-t-il avec plusieurs projets? Planifiez-vous toujours une itération pour un seul projet dans un certain laps de temps et toute l'équipe y travaille, puis vous passez au projet suivant avec une nouvelle itération lorsque cette itération est terminée? Ou y a-t-il une manière «agile» de gérer plusieurs projets avec leurs propres itérations avec une seule équipe à la fois?

Scrum ne vous oblige pas vraiment à travailler sur le seul produit autonome. Il indique simplement qu'il y a un tas de choses à faire (le backlog du produit), il y a un certain temps de développement disponible dans la prochaine itération (calculé à partir de la vitesse du projet) et il y a des éléments sélectionnés par le client / business comme ayant le plus de priorité dans ce pool de problèmes / tâches qui seront effectués lors de la prochaine itération (le backlog de sprint).

Il n'y a aucune raison pour que le backlog de produit et le backlog de sprint proviennent d'un seul projet - même dans un seul projet, il y aura des unités de travail distinctes qui ressemblent à des projets séparés - l'interface utilisateur, la couche métier, le schéma de base de données, etc. Le développement de logiciels d'entreprise en particulier est comme celui-ci, où vous avez un certain nombre de bases de code qui doivent toutes progresser. Le processus Scrum - réunions, questions, graphe déroulant, etc. - fonctionne tous, qu'il s'agisse d'un ou de plusieurs projets.

Cela dit, dans la pratique, il est souvent bon que chaque itération ait un thème majeur - "faire le module de reporting" ou "interface avec l'API du système XYZ" - de sorte que beaucoup de problèmes proviennent d'un projet ou d'un domaine et À la fin de l'itération, vous pouvez pointer vers un gros travail et placer une coche contre celui-ci.

Je pense que la réponse dépend de « qui donnera la priorité aux éléments de l'arriéré » (c.-à-d. Décider de ce qui doit être fait en premier). S'il s'agit d'une seule personne, cette personne est le Product Owner de vos projets, et vous pouvez avoir un seul backlog pour tous les éléments de tous les projets - ou un backlog par projet - et vous sélectionnez les éléments de backlog de tous les projets lorsque vous planifiez un Sprint. Dans ce cas, Scrum "fonctionne" très bien.

Si chaque projet a son responsable, alors vous risquez de rencontrer des problèmes où chaque responsable tentera - plus ou moins consciemment - de favoriser son (ses) projet (s). À mon humble avis, vous ne devrez avoir qu'un seul propriétaire de produit habilité à régler les priorités par arbitrage.

Une règle qui doit être suivie dans un tel contexte est de ne jamais changer le contenu du Sprint pendant le Sprint . Si nécessaire, vous pouvez raccourcir l'itération à deux ou trois semaines pour réduire le risque d'avoir à ajouter un élément urgent dans le Sprint actuel.

Je ne suis pas d’accord. Je pense que c'est la clé du processus d'avoir une équipe concentrée sur un seul projet lors d'un sprint. Si vous avez des spécialistes qui ne peuvent pas contribuer à l'ensemble du processus de développement (auteurs de contenu, graphistes, analystes de processus métier, etc.), je les supprimerais de l'équipe lorsqu'ils ne pourraient plus contribuer. Ou mieux encore, formez-les à différentes tâches afin qu'ils puissent contribuer à des choses comme les tests.

Une autre chose à garder à l'esprit est que l'exécution de projets en parallèle tue votre emploi du temps. Considérez ceci: pour simplifier, disons que nous avons 5 projets utilisant la même équipe et commençant à la même date. Chaque projet nécessite 3 mois d'effort.Dans le meilleur des cas, en parallèle, vous les terminerez tous en même temps et cela prendra 15 mois. Votre vitesse sera crémée car vous ne pouvez faire que 1/5 d'un mois d'effort dans un seul sprint. Vous ferez également 5 réunions de démonstration en même temps. Dans le meilleur des cas, vous livrez vos 5 projets en 15 mois et vos concurrents prétendront faire le même travail en 3. Vos équipes estimant la maturité en souffriront car elles ne pourront considérer que 20% de leur main-d'œuvre disponible. Vous constaterez peut-être que vous ne parvenez pas à effectuer certaines tâches en un seul sprint. Si vous devez changer le nombre de projets en cours de travail de 5, votre équipe devra ajuster ses habitudes d'estimation, ce qui nuira à l'efficacité des équipes. De plus, votre équipe aura du mal à s'auto-organiser lorsqu'une simple réaffectation de tâches peut nécessiter la création d'un nouvel environnement de développement avant que le travail ne puisse commencer.

Si vous deviez exécuter les mêmes 5 projets en série, vous livreriez le 5e projet dans les mêmes 15 mois, mais vous auriez informé votre client que votre équipe est tellement demandée que vous avez un backlog de 12 mois et que vous pouvez utiliser cette fois pour affiner les objectifs de votre projet. Ou si vous avez un arriéré constant, vous savez qu'il est temps de commencer à embaucher une autre équipe. Votre meilleur projet, cependant, est terminé en 3 mois avec un client qui a vu des améliorations rapides pendant la période active. Vous pouvez terminer ce projet un an plus tôt et le mettre sur votre CV. Votre vitesse de sprint se stabilisera au cours de cette période et vous constaterez peut-être que cela atteint son objectif après un projet ou deux et que vous êtes capable d'accomplir plus dans un sprint donné.

Je pense que gérer des projets en série est l'un des plus grands obstacles pour une organisation qui tente d'adopter des visages de mêlée. C'est un changement culturel majeur associé à la déconstruction du rôle de chef de projet, mais les avantages pour le processus Scrum sont énormes.

Gardez à l'esprit que TOUT LE MONDE n'a pas besoin d'être un membre à part entière de l'équipe. Ils peuvent engager votre client dans la salle d'attente, se préparer au processus de développement. Je garde mes analystes commerciaux, architectes réseau et concepteurs graphiques en tant qu'experts du domaine et ne les attache à une équipe que si nécessaire. Laissez-les courir avec le sprint 0. Vous seriez surpris de voir à quel point le travail sur l'apparence et le flux de travail est intéressant. Il est également bon de préparer votre client en sachant que lorsque le développement commence véritablement, son niveau de participation peut en fait augmenter et qu'il est important pour lui d'être disponible. Faites-leur connaître le calendrier afin qu'ils aient suffisamment de temps pour s'occuper de choses comme les vacances et les vacances bien à l'avance.

J'ai été dans cette situation précise.

Si vous avez un propriétaire de produit dans les projets, Phillipe a tout à fait raison; Un sprint avec une équipe devrait bien fonctionner.

Si vous avez plus d'un propriétaire de produit, alors, idéalement, le côté commercial doit choisir un seul «hiérarchiseur» à qui la responsabilité de planifier le travail est confiée. C'est certainement la meilleure solution.

Si (comme c'est probablement le cas) l'entreprise ne veut pas changer la façon dont elle souhaite hiérarchiser les choses (ce serait beaucoup trop pratique), vous pouvez diviser l'équipe et exécuter deux sprints simultanés. Cependant, avec une équipe de six, je ne la diviserais pas en plus de 3 équipes (je ne voudrais pas du tout la diviser, mais je pense que 2-3 équipes seraient réalisables). Se diviser davantage comme le suggère Kenny, et avoir des équipes d'une seule personne me semble quelque peu inutile, car alors vous n'avez plus d'équipe, juste des programmeurs individuels.

Si vous divisez l'équipe, je n'ai pas trouvé beaucoup de valeur à fusionner les stand-ups, à moins que vous n'ayez des sprints séparés travaillant sur une grande partie de la même base de code, mais cela peut être un argument pour fusionner ces équipes dans le but de le sprint.

Il y a une autre opinion que j'ai lu ces derniers temps, à savoir que dans un environnement Agile, le concept de projet pourrait être contre-productif et pourrait être éliminé. Selon cette ligne de pensée, l'organisation devrait plutôt se concentrer sur les versions . En effet, les projets sont des boîtes de travail artificielles qui ne produisent aucune valeur tant qu’elles ne sont pas terminées. Ils sont contraires à l'objectif d'Agile de fournir fréquemment une valeur livrable. Une version est plus conforme à Agile car elle est orientée vers la création de valeur et parce que sa portée peut être réduite ou étendue en fonction de ce que les équipes peuvent livrer avant la prochaine version .

Il existe un terrain d'entente potentiel, dans lequel ce qu'on appelait autrefois un projet dans votre entreprise est maintenant reconditionné en tant que thème ou fonctionnalité Agile commun . L'avantage de cette approche est que le thème ou la fonctionnalité peut désormais être implémenté par éléments de valeur, comme le propriétaire du produit le juge opportun.

Il y a toujours la question d'une équipe travaillant sur plusieurs produits , et c'est une question en raison de préoccupations légitimes concernant la connaissance du domaine et les compétences techniques possibles. Mais les produits construits avec Agile, même plusieurs produits construits par une seule équipe, accumulent constamment de presse valeur able. En revanche, les projets ne valent rien tant qu'ils ne sont pas terminés (et beaucoup ne le sont pas).

Quelque chose à quoi penser...

Je pense qu'anopres avait raison: le meilleur moyen est d'éviter plusieurs projets en même temps avec Scrum. Faites tout pour convaincre que trop courir en parallèle n'est pas efficace.

Supposons 5 projets chacun environ 3 mois pour une équipe de 5 personnes.

Approche 1: chaque personne travaille sur un seul projet en équipe

• 1/5 de la vitesse de livraison par projet donne 15 mois de livraison pour tous les projets
• Chaque personne est experte mais uniquement dans son propre projet
• Pas d'esprit d'équipe

Approche 2: 1 sprint par projet, changement de projet

• Chaque 6ème sprint travaille sur le projet
• Trop de temps entre les travaux du projet - pas de valeur incrémentielle régulière pour le projet (pour le backlog produit oui), facile à oublier, effort nécessaire pour restaurer le contexte,
• Premier projet livré après environ 12-13 mois (en supposant un sprint de 2 semaines)

Approche 3: 5 projets en un seul sprint

• Nécessite une répartition trop détaillée des tâches juste pour s'intégrer dans le sprint
• Très peu de build incrémentiel par projet
• Livraison du premier projet après environ 12-15 mois

Approche 4: recommandée - Travail sérialisé

• L'équipe travaille sur un seul projet après projet
• Premier projet démarré et livré après 3 mois
• Deuxième projet démarré après le 3ème mois, livré après le 6ème mois
• ...
• 5ème projet démarré après 12 mois, livré après 15 mois
• Équipe très concentrée sur le projet, la recherche intensive et la collaboration avec le client
• Toute l'équipe a une bonne connaissance générale de tous les projets
• Pas de perte de temps sur le changement de contexte
• Nécessite une bonne coopération d'équipe (les conflits peuvent ralentir la livraison).

Comme vous le voyez, la solution 4 est généralement meilleure car les projets sont livrés beaucoup plus rapidement, l'équipe travaille ensemble et est efficace. D'autres approches incluent la perte de temps due au changement de contexte, l'absence de collaboration complète en équipe, le très long délai de livraison total de tous les projets, etc.

Et qu'en est-il du toilettage de l'arriéré? Si l'équipe travaille sur un seul projet à la fois, c'est simple - tout le monde se joindra. S'il y a plusieurs projets, nous pouvons avoir besoin de déléguer des personnes seules à des sessions de toilettage distinctes (aucune équipe complète n'est impliquée).

Il est important de convaincre les clients que le démarrage du 2ème projet après 3 mois se traduira toujours par une livraison plus rapide (après le 6ème mois) plutôt que si nous le démarrons immédiatement avec tous les autres. C'est une illusion que voient les managers - nous démarrons 5 projets à la fois, nous travaillons dur et livrons petit à petit. En fin de compte, ce n'est cependant pas efficace.

C'est pourquoi je ne pense pas que Scrum soit efficace pour plusieurs projets en parallèle, il est très difficile de le faire correspondre dans le cadre et de travailler selon les règles de Scrum. Parfois, il peut être bon d'avoir 2 projets pour occuper tout le monde, mais plus nous ajouterons de projets, moins la mêlée sera efficace. Peut-être que kanban est une alternative juste pour voir les progrès et le travail d'équipe (pas si fort que dans l'équipe Scrum)?

Cordialement, Adam

Comme @Chris l'a dit, un projet normal contient des sous-projets. Cependant, vous n'avez qu'un seul arriéré.

Pensez à un backlog avec tous vos projets. Premier problème: attribuez-vous des priorités à des tâches ou à des projets? Je préfère un backlog par projet. Au moins pour avoir clairement les priorités du Product Owner.

Avoir des propriétaires de produits différents, et en raison du fait que ces propriétaires de produits ne s'entendront pas sur le temps qu'ils devraient consacrer à chaque projet. «Quelqu'un» devra absorber la décision sur la façon de gérer les priorités interprojets. Remarque: les développeurs ne devraient pas le faire.

Voici notre chef de projet "S" qui équilibrera les ressources dont les propriétaires de produits ont besoin et le temps que les membres de l'équipe peuvent donner. Le Product Owner A a payé un mois de travail, mais le Product Owner B met toujours à jour son projet (et vous paie bien aussi). Voilà comment vous allez équilibrer votre équipe pour que A ait son mois (temps de développeur) et n'empêchez pas B de remplir vos poches.

Dans le cas des logiciels internes (une entreprise, mille projets). Les différents propriétaires de produits doivent s'entendre sur le temps qui leur est imparti. Ils ne vivent pas isolés, mais dans le même bateau que vous (chef de projet "S"). Ils vous faciliteront la vie en pouvant reporter certaines tâches, mais en même temps, vous ne devez jamais oublier leurs besoins.

Eh bien, j'essaie toujours de trouver la meilleure façon de le faire. Mais c'est ce que nous poussons en ce moment. J'espère que cela aide.

Les membres de l'équipe peuvent partager leur temps entre les projets Scrum, mais il est beaucoup plus productif d'avoir des membres de l'équipe entièrement dévoués. Les membres de l'équipe peuvent également changer d'un sprint à l'autre, mais cela réduit également la productivité de l'équipe. Les projets avec des équipes plus importantes sont organisés en plusieurs mêlées, chacune axée sur un aspect différent du développement du produit, avec une coordination étroite de leurs efforts.

Je suggérerais d'exécuter un Sprint pour chaque projet et d'organiser une réunion quotidienne pour gérer tous les ressorts / projets actifs.

J'aimerais contribuer. Voici comment je le fais:

• Il y a un propriétaire de produit et un backlog de produit par équipe. Le Product Owner n'est pas obligé d'être une seule personne, mais cette «entité» de Product Owner est en charge du backlog produit.
• Le backlog produit contient les user stories de chaque projet (tous les projets ici). Chaque user story a un effort / story points (responsabilité d'équipe) et une valeur commerciale (responsabilité du propriétaire de produit).
• Nous avons un "toilettage du backlog produit" qui se réunit à chaque sprint. Avant cette réunion, le propriétaire du produit a mis à jour les valeurs commerciales des histoires (si elles ont besoin de changement pour une raison commerciale quelconque - que nous ne nous soucions pas et ne devrions pas nous en préoccuper -) et inclure de nouvelles histoires. Lors de cette réunion, les nouvelles histoires sont expliquées et les efforts sont également mis à jour. Cette réunion dure environ une heure (sauf la première fois, environ 4 heures).
• Lorsque nous allons planifier un nouveau sprint, nous ouvrons le backlog du produit, classons les histoires par retour sur investissement (il s'agit de la valeur / effort de l'entreprise) et planifions les histoires jusqu'à ce que le temps soit écoulé.

Et c'est tout. Je peux dire que cela fonctionne assez bien. Nous utilisons quelques feuilles de calcul Google (le backlog du produit et le backlog de sprint, à la fois avec des graphiques et des trucs) pour ce faire, et redmine (avec une sémantique spécifique) pour une organisation en ligne tous les jours: heure, progression des tâches, etc.

Le problème avec cette approche est que j'ai dupliqué les tâches dans la feuille de calcul du backlog de sprint et dans la redmine. Mais je ne trouve aucun outil en ligne pour le faire entièrement en ligne. Il me manque un backlog de produit dans redmine (aucune autre sémantique ne fonctionne pour moi), un seul tableau dans jira, plus d'histoires dans la taïga, etc.