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

Question

Je connais assez bien les avantages et les processus de Scrum. Je reçois les idées sur l'arriéré, les graphiques de burndown, les itérations, l'utilisation d'histoires d'utilisateurs et d'autres concepts divers du Scrum "framework".

Cela dit ... Je travaille pour une société de développement Web qui gère plusieurs projets à la fois, avec six membres de l’équipe qui constituent l’équipe de production.

Comment Scrum fonctionne-t-il avec plusieurs projets? Planifiez-vous toujours une itération pour un seul projet dans un laps de temps donné et toute l’équipe y travaille, puis passez-vous au projet suivant avec une nouvelle itération une fois cette itération terminée? Ou existe-t-il un " agile " façon de gérer plusieurs projets avec leurs propres itérations avec une seule équipe à la fois?

Answer 1

Scrum ne vous dicte vraiment pas que vous devez travailler sur le seul produit autonome. Il indique simplement qu'il y a un tas de choses à faire (le carnet de produit), qu'il y a un certain temps de développement disponible à la prochaine itération (calculé à partir de la vitesse du projet) et que le client sélectionne des articles. / business en tant que priorité de ce groupe de problèmes / tâches qui sera effectué lors de la prochaine itération (le carnet de commandes de sprint).

Il n'y a aucune raison pour que le carnet de produit et le carnet de sprint doivent provenir d'un projet - même dans un projet, il y aura des unités de travail distinctes qui ressemblent à des projets distincts - l'interface utilisateur, la couche de gestion, le schéma de base de données , etc. Le développement de logiciels d'entreprise, en particulier, ressemble à cela, où vous avez un certain nombre de bases de code que toutes doivent évoluer. Le processus Scrum - réunions, questions, graphique en réduction, etc. - fonctionne dans tous les cas, qu'il s'agisse d'un projet ou de plusieurs.

Cela dit, dans la pratique, il est souvent bon que chaque itération ait un thème majeur: "faire le module de rapport" " 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 qu'à la fin de l'itération, vous pouvez pointer vers un grand volume de travail et le placer en opposition.

Answer 2

Je pense que la réponse dépend de " qui donnera la priorité aux éléments de l'arriéré ". (c’est-à-dire décider ce qui doit être fait en premier). S'il s'agit d'une seule personne, cette personne est le responsable du produit pour vos projets. Vous pouvez avoir un seul arriéré pour tous les éléments de tous les projets - ou un arriéré par projet - et vous sélectionnez les éléments de l'arriéré de tous les projets lorsque vous planifiez. un sprint. Dans ce cas, Scrum " works " bien.

Si chaque projet a ses responsables, il est probable que vous rencontriez des difficultés au cours desquelles chaque responsable essaiera, plus ou moins consciemment, de favoriser ses projets. IMHO, vous aurez besoin d'avoir un seul Product Owner avec le pouvoir de régler les priorités par arbitrage.

Une règle à suivre dans un tel contexte consiste à ne jamais modifier le contenu du sprint pendant le sprint . Si nécessaire, vous pouvez réduire l'itération à deux ou trois semaines pour réduire le risque de devoir ajouter un élément urgent dans le Sprint en cours.

Answer 3

Je ne suis pas d'accord. Je pense qu'il est essentiel dans le processus de disposer d'une équipe centré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 du contenu, responsables graphiques, analystes des processus métier, etc.), je les écarterai de l'équipe dès qu'ils ne pourront plus contribuer. Ou mieux encore, formez-les à différentes tâches pour qu'ils puissent contribuer à des tâches telles que les tests.

Une autre chose à garder à l'esprit est que l'exécution de projets en parallèle tue votre planning. Considérez ceci: pour simplifier, supposons que nous ayons 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 vélocité sera crémée parce que vous ne pouvez faire que 1/5 de mois d'effort en un seul sprint. Vous ferez également 5 réunions de démonstration en même temps. Donc, dans le meilleur des cas, vous livrez vos 5 projets en 15 mois et vos concurrents prétendent pouvoir faire le même travail en 3. Vos équipes estimant la maturité en souffriront car elles ne pourront prendre en compte que 20% de leur main-d'œuvre disponible. Vous constaterez peut-être que vous n'êtes pas en mesure d'effectuer certaines tâches dans un seul sprint. Si vous devez modifier le nombre de projets en cours de travail sur 5, votre équipe devra ajuster ses habitudes d'estimation, ce qui nuira à l'efficacité de l'équipe. De plus, votre équipe aura du mal à s'auto-organiser lorsqu'une simple réaffectation de tâches peut nécessiter l'activation d'un nouvel environnement de développement avant le début du travail.

Si vous exécutiez les mêmes 5 projets en série, vous livriez le 5ème projet dans les mêmes 15 mois, mais vous auriez informé votre client que votre équipe est si sollicitée que vous avez un carnet de commandes de 12 mois et que vous pouvez utiliser ce temps pour affiner les objectifs de votre projet. Si vous avez un arriéré constant, vous savez qu'il est temps de recruter une autre équipe. Cependant, votre meilleur projet se termine en 3 mois avec un client qui a vu des améliorations rapides au cours de la période active. Vous pouvez terminer ce projet un an plus tôt et le mettre sur votre CV. Votre vitesse de sprint va se stabiliser au cours de cette période et vous constaterez peut-être que sa vitesse de frappe est élevée après un projet ou deux et que vous pouvez accomplir davantage dans un sprint donné.

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

N'oubliez pas 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 et se préparer au processus de développement. Je garde mes analystes métier, mes architectes de réseau et mes concepteurs graphiques d’experts en domaines et ne les attache à une équipe que de besoin. Laissez-les courir avec le sprint 0. Vous seriez surpris de voir à quel point il est intéressant de travailler sur l'apparence et le flux de travail. Il est également bon de préparer votre client en sachant que lorsque le développement commence sérieusement, son niveau de participation peut en fait augmenter et qu'il est important pour lui d'être disponible. Informez-les de l'horaire afin qu'ils disposent de suffisamment de temps pour s'occuper des vacances et des vacances bien à l'avance.

Answer 4

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

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

Si vous avez plus d'un propriétaire de produit, alors, dans l'idéal, le secteur privé doit choisir un seul "prioriseur", à qui revient la responsabilité de planifier le travail. C’est définitivement la meilleure solution.

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

Si vous divisez l'équipe, je ne trouve pas l'intérêt de fusionner les stand-ups, à moins que vous n'ayez des sprints distincts travaillant à peu près de la même base de code, mais cela pourrait être un argument pour fusionner ces équipes. le but du sprint.

Answer 5

Il y a un autre avis que j'ai lu récemment, à 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 Communiqués . 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 une valeur pouvant être expédiée fréquemment. Une version correspond mieux à Agile car elle est orientée vers la création de valeur et que son étendue peut être réduite ou étendue en fonction de ce que les équipes peuvent fournir avant la prochaine version .

Il existe un terrain d'entente dans lequel ce que vous appeliez auparavant un projet dans votre entreprise est désormais reconditionné en tant que thème ou Feature . L’avantage de cette approche est que le thème ou la fonctionnalité peut désormais être implémenté en plusieurs éléments de valeur, comme le propriétaire du produit le juge utile.

Il reste la question d'une équipe travaillant sur plusieurs produits , en raison d'inquiétudes légitimes concernant la connaissance du domaine et les éventuelles compétences techniques. Mais les Produits construits avec Agile, même plusieurs Produits construits par une seule équipe, accumulent en permanence une valeur Libération . En revanche, les Projets ne valent rien tant qu'ils ne sont pas terminés (et beaucoup non).

Pensez-y ...

Answer 6

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

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

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

• 1/5 de rapidité de livraison par projet donne 15 mois de livraison pour tous les projets
• Chaque personne est experte mais seulement 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 de 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 sprint unique

• Nécessite une division trop détaillée des tâches pour pouvoir s'intégrer au sprint
• Très peu de construction incrémentielle par projet
• Livraison du premier projet après environ 12-15 mois

Approche 4: recommandée - Travail en série

• L'équipe travaille sur un projet après l'autre
• 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
• ...
• Le 5ème projet a démarré après le 12ème mois et a été livré après le 15ème mois
• Une é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 la commutation de contexte
• Exige une bonne coopération des équipes (les conflits peuvent ralentir la livraison).

Comme vous le voyez, la solution 4 est généralement préférable car les projets sont livrés beaucoup plus rapidement, l’équipe travaille en équipe et est efficace. D’autres approches incluent une perte de temps due au changement de contexte, une absence de collaboration totale entre les équipes, un très long délai de livraison de tous les projets, etc.

.

Et qu'en est-il de la gestion de l'arriéré? Si l’équipe travaille sur un projet à la fois, c’est simple, tout le monde se joindra à nous. S'il y a plusieurs projets, il se peut que nous devions déléguer une seule personne pour des sessions de toilettage séparées (aucune équipe complète n'est impliquée).

Il est important de convaincre les clients que le démarrage du deuxième projet après trois mois entraînera toujours une livraison plus rapide (après le sixième mois) plutôt que si nous le démarrons immédiatement avec tous les autres. C'est une illusion que les gestionnaires voient - nous démarrons 5 projets à la fois, nous travaillons fort et livrons petit à petit. Au final, ce n’est pas efficace cependant.

C'est pourquoi je ne crois pas que Scrum soit efficace pour plusieurs projets en parallèle, il est très difficile de le faire correspondre à un 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 nous serons efficaces. Peut-être que le kanban est une alternative juste pour voir les progrès et le travail d’équipe (pas aussi fort que dans l’équipe Scrum)?

Cordialement, Adam

Answer 7

Comme @Chris l’a dit, un projet normal contient des sous-projets. Vous n’avez cependant qu’un seul carnet de commandes.

Pensez dans un carnet de commandes avec tous vos projets. Premier problème: attribuez-vous des priorités à des tâches ou à des projets? Je préfère un arriéré par projet. Au moins pour définir clairement les priorités du responsable du produit.

Avoir des propriétaires de produits différents, et en raison du fait que ces propriétaires de produits ne vont pas se mettre d’accord sur le temps qu’ils devraient consacrer à chaque projet. " Quelqu'un " prendre la décision sur la façon de gérer les priorités entre les projets. Remarque: les développeurs ne devraient pas le faire.

Voici notre projet "S" gestionnaire qui équilibrera les ressources dont les propriétaires de produits ont besoin et le temps que les membres de l’équipe peuvent consacrer. Propriétaire du produit A payé pour un mois de travail, mais le propriétaire du produit B met toujours à jour son projet (et vous paye bien aussi). Voici comment vous allez équilibrer votre équipe pour que A ait son mois (développeur), et n’empêchez pas B de remplir vos poches.

Dans le cas d'un logiciel interne (une entreprise, mille projets). Les différents propriétaires de produits doivent s’accorder sur le temps qui leur est imparti. Ils ne vivent pas isolés, mais dans le même bateau que vous (gestionnaire du projet "S"). Ils vous faciliteront la vie en reportant certaines tâches, mais en même temps, vous ne devez jamais oublier leurs besoins.

Eh bien, j'essaie toujours de trouver le meilleur moyen de le faire. Mais c’est ce que nous préconisons en ce moment. J'espère que ça aide.

Answer 8

Les membres de l’équipe peuvent partager leur temps entre projets Scrum, mais c’est beaucoup plus productif d'avoir des membres de l'équipe entièrement dédiés. Les membres de l'équipe peuvent également changer d'un sprint au suivant, 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 produit. développement, avec une coordination étroite de leurs efforts.

Answer 9

Je suggèrerais de lancer un Sprint pour chaque projet et d’organiser une réunion journalière pour gérer tous les projets / projets actifs.

Answer 10

J'aimerais contribuer. Voici comment je le fais:

• Il existe un propriétaire de produit et un carnet de produit par équipe. Le propriétaire du produit ne doit pas obligatoirement être une seule personne, mais ce propriétaire du produit "entité". est en charge du carnet de produit.
• Le carnet de produit contient les user stories de chaque projet (tous les projets ici). Chaque user story a des points d’effort / story (responsabilité de l’équipe) et une valeur commerciale (responsabilité du propriétaire du produit).
• Nous avons un "traitement du carnet de produit en retard". rencontrer chaque sprint. Avant cette réunion, le propriétaire du produit a mis à jour les valeurs commerciales des récits (s’ils ont besoin de changements, quelle que soit la raison commerciale - nous ne le faisons pas et ne devrions pas nous en soucier-) et incluent de nouveaux récits. Au cours 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 planifions un nouveau sprint, nous ouvrons le carnet de produit, classons les récits par ROI (valeur commerciale / effort) et planifions les récits jusqu'à la fin.

Et c'est tout. Je peux dire que cela fonctionne très bien. Pour ce faire, nous utilisons quelques tableurs Google (le carnet de produit et le carnet de sprint), et redmine (avec une sémantique spécifique) pour une organisation en ligne chaque jour: heure, progression de la tâche, etc.

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