Comment Scrum fonctionne-t-il lorsque vous avez plusieurs projets?
Je connais assez bien les avantages et les processus de Scrum. Je reçois les idées sur le backlog, les graphiques de burndown, les itérations, l'utilisation des user stories et d'autres concepts divers du "framework" Scrum.
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 composent "l'équipe de production".
Comment Scrum fonctionne 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 existe-t-il une manière "agile" de gérer plusieurs projets avec leurs propres itérations avec une seule équipe à la fois?
Scrum ne 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 backlog du produit), qu'il y a un certain temps de développement disponible dans la prochaine itération (calculé à partir de la vitesse du projet) et qu'il y a des éléments sélectionnés par le client/business comme étant la priorité de 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 que le backlog de produit et le backlog de sprint doivent provenir d'un seul projet - même dans un seul projet, il y aura des unités de travail distinctes qui sont comme 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 ça, où vous avez un certain nombre de bases de code qui doivent toutes progresser. Le processus Scrum - réunions, questions, tableau de gravure, etc. - fonctionne tous 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'une zone et À la fin de l'itération, vous pouvez pointer vers un grand volume de travail et placer une coche contre.
Je pense que la réponse dépend de "qui priorisera les éléments du backlog" (c'est-à-dire décider ce qui doit être fait en premier). S'il s'agit d'une seule personne, cette personne est le propriétaire du produit pour 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, vous risquez de rencontrer des problèmes où chaque responsable tentera - plus ou moins consciemment - de favoriser son ou ses projets. À mon humble avis, vous aurez besoin d'avoir un seul propriétaire de produit avec le pouvoir de 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 en cours.
Je dois être en désaccord. Je pense que c'est la clé du processus d'avoir une équipe concentrée sur un seul projet pendant 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 des processus métier, etc.), je les chasserais de l'équipe lorsqu'ils ne peuvent 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 calendrier. 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'efforts. Dans le meilleur des cas, en parallèle, vous les terminerez tous en même temps et cela prendra 15 mois. Votre vitesse deviendra crémeuse car vous ne pouvez faire que 1/5 d'un mois d'effort en un seul sprint. Vous ferez également 5 réunions de démonstration en même temps. Alors dans le meilleur des cas, vous livrez vos 5 projets en 15 mois et vos concurrents vont prétendre qu'ils pourraient 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 pouvez constater que vous n'êtes pas en mesure d'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 mise en place d'un nouvel environnement de développement avant le début du travail.
Si vous deviez exécuter les 5 mêmes projets en série, vous livreriez le 5ème projet dans les 15 mêmes 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 moment pour affiner les objectifs de votre projet. Ou si vous avez un carnet de commandes 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 connu 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 de temps et vous constaterez peut-être qu'elle atteint son rythme après un ou deux projets et que vous pouvez accomplir plus dans un sprint donné.
Je pense que gérer des projets en série est l'un des plus grands obstacles qu'une organisation 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 du 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, préparer le processus de développement. Je garde mes analystes commerciaux, architectes de réseau et graphistes en tant qu'experts du domaine et je les attache à une équipe uniquement si nécessaire. Laissez-les s'exécuter avec le sprint 0. Vous seriez surpris de constater à 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 sérieusement, leur niveau de participation peut en fait augmenter et qu'il est important qu'il soit disponible. Faites-leur connaître l'horaire afin qu'ils aient suffisamment de temps pour s'occuper des choses comme les vacances et les vacances bien à l'avance.
J'ai été dans cette situation précise.
Si vous avez un seul propriétaire de produit dans les projets, Phillipe a tout à fait raison; Un sprint avec une équipe devrait très bien fonctionner.
Si vous avez plus d'un propriétaire de produit, alors idéalement, le côté commercial doit choisir un seul "prioriseur" qui est chargé de planifier le travail. 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 le diviserais pas en plus de 3 équipes (je ne voudrais pas du tout le diviser, mais je pense que 2-3 équipes seraient réalisables). Fractionner 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, sauf si vous avez 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 lue 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 versions. C'est parce que 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 de la 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 élargie en fonction de ce que les équipes peuvent livrer avant le suivant Relâchez .
Il existe un terrain d'entente potentiel, dans lequel ce qui était anciennement appelé un projet dans votre entreprise est maintenant reconditionné sous la forme Agile commune Thème = ou Fonction. L'avantage de cette approche est que le thème ou fonctionnalité peut désormais être mis en œuvre en morceaux 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 Produits construits avec Agile, même plusieurs Produits construits par une seule équipe , s'accumulent constamment Relâchez - valeur. En revanche, Les projets ne valent rien tant qu'ils ne sont pas terminés (et beaucoup ne le font 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 comprendre 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 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 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 répartition trop détaillée des tâches juste pour tenir dans le 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 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 commencé après le 12ème mois, livré après le 15ème 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 le temps perdu à changer de contexte, pas de collaboration complète avec l'équipe, un temps de livraison total très long pour tous les projets, etc.
Et qu'en est-il du nettoyage 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, il se peut que nous devions 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 2e projet après 3 mois se traduira toujours par une livraison plus rapide (après le 6e mois) plutôt que si nous le démarrons immédiatement avec tous les autres. C'est une illusion que les managers voient - 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 crois pas que Scrum soit efficace pour plusieurs projets en parallèle, il est très difficile de le faire correspondre au framework et de travailler selon les règles 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 le 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 l'a dit @Chris, un projet normal contient des sous-projets. Vous n'avez cependant qu'un seul backlog.
Pensez dans un carnet de commandes avec tous vos projets. Premier problème: attribuez-vous des priorités aux tâches ou aux projets? Je préfère un backlog par projet. Au moins pour avoir clairement les priorités du propriétaire du produit.
Avoir des propriétaires de produits différents et du fait que ces propriétaires de produits ne s'entendront pas sur le temps à 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 gestionnaire 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 propriétaire du produit A a payé un mois de travail, mais le propriétaire du produit B met toujours à jour son projet (et vous paie bien aussi). Il y a de quoi équilibrer votre équipe pour que A ait son mois (temps 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 convenir du 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 étant en mesure de 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 ça aide.
Les membres de l'équipe peuvent partager leur temps entre des 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 de plus grandes équipes 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 de standup 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 propriétaire du produit ne doit pas nécessairement être une seule personne, mais cette "entité" de propriétaire du produit est en charge du backlog du produit.
- Le backlog produit contient les user stories de chaque projet (tous les projets ici). Chaque user story a un effort/points d'histoire (responsabilité de l'équipe) et une valeur commerciale (responsabilité du propriétaire du 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 (s'il a besoin de changement pour quelque raison commerciale que ce soit ou non) et inclut 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 de produit, commandons les histoires par ROI (c'est la valeur/l'effort commercial) et planifions les histoires jusqu'à ce que le temps soit écoulé.
Et c'est tout. Je peux dire que cela fonctionne très bien. Nous utilisons quelques feuilles de calcul Google (le backlog de 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 de backlog de sprint et redmine. Mais je ne trouve aucun outil en ligne pour le faire complètement en ligne. Je manque un carnet de commandes de produits dans Redmine (pas d'autres travaux sémantiques pour moi), une seule carte dans Jira, plus d'histoires dans la taïga, etc.