Quelle est la meilleure façon de gérer plusieurs projets lorsque vous avez une seule équipe de développement?[fermé]

Question

Fermé. Cette question ne répond pas à Directives de dépassement de pile . Il n'accepte pas actuellement les réponses.

---

Voulez-vous améliorer cette question? Mettez à jour la question de sorte que c'est sur le sujet pour débordement de pile.

FERMÉ Il y a 2 ans .

.

Améliorer cette question

est agile / scrum de la réponse? Comment Scrum gère-t-il cela?

Un propriétaire du produit, un arriéré de produit vs multiples propriétaires de produits et arriérés de produits?

Comment fonctionne-t-il pour vous? Veuillez partager vos histoires de défaillance de succès?

J'essaie de mettre un processus ensemble pour gérer plusieurs files d'attente de travail allant de Projets d'infrastructure, améliorations de fonctionnalités simples, puis grands projets avec un Petite équipe de développement de 6-7 développeurs.

Answer 1

Je suppose que vous pouvez faire deux choses:

1. Faites une publication d'un projet, lorsque vous avez terminé, faites le prochain
2. Séparez votre équipe de développement

ou une combinaison des deux :)

Agile / Scrum sont de bons mots à la mode, mais ne semblent pas très liés à votre question. Depuis qu'ils s'appliquent à la portée d'un projet, pas à un tas de projets.

J'ai de l'expérience avec la deuxième option, jusqu'à un niveau où il y a plus de projets que les développeurs, ce qui n'est pas ce que vous voulez.Mais avec des sessions de revue de code décent, il semble fonctionner.

Answer 2

Un bit manquant est de savoir si c'est techniquement un produit (comme une base de code, même si grande) ou non.

Si ce sont Produits complètement distincts à l'aide de Scrum, j'irais dans des sprints très courts (1-2 semaines) et des travaux de développement de séquences. Donc deux semaines projet A, puis projet B, puis c, puis à nouveau A - peut-être pour deux sprints, puis c etc. Dans une telle situation, un seul arriéré n'a aucun sens, des arriérés séparés doivent être conservés pour A, B et C. I connaître au moins une équipe qui fonctionne comme celle-ci.

Si vous avez besoin de plus de POS, c'est plutôt une fonction de connaissance des produits. Peut-être avez-vous besoin de quelqu'un pour chaque projet, peut-être que vous avez quelqu'un qui sait assez bien A, B et C pour être le PO.

Si différents produits, alors lorsque vous essayez de le faire en prenant différentes histoires de différents arriérés, chaque sprint, ce que vous finirez avec Sclind Team. Naturellement, les gens seront spécialisés dans le projet donné, il sera également très difficile d'avoir une bonne définition de la finalité (sommes-nous faits si nous pouvons expédier de nouveaux incréments pour A et B, mais pas C Ce sprint?). Si vous ne pouvez pas séquencer des projets avec de courtes sprints, je ressemblerais à Kanban pour essayer de mettre une certaine organisation à cela.

Si c'est un produit / une base de code - alors les choses sont beaucoup plus faciles. Même si l'équipe devra toucher différentes zones du codeBase en raison de projets différents, ils travailleront toujours sur les mêmes produits afin que tous les mécanismes de Scrum s'appliquent bien. Un arriéré, une po.

Un inconvénient de ceci à noter est que les personnes de l'équipe se dirigeront et qu'il y a une pénalité de faire cela, quel que soit le processus que vous utilisez. Quel que soit le processus que vous choisissez devrait essayer de minimiser cela aussi longtemps que possible (tant que les affaires seront en mesure de tenir). Bonne chose à propos de Scrum, c'est que cela dispose d'un accord intégré avec le PO que les commutateurs contextuels ne peuvent survenir que chez Sprint Border - autrement dit que l'équipe obtiendra 1 à 2 semaines de se concentrer avant de devoir passer à un autre projet.

En outre, n'oubliez pas toutes les pratiques techniques d'Agile. Tests unitaires. Constructions et tests automatiques. Avis de code. Utilisation intelligente des repos. Normes élevées Re. qualité. Tous ceux qui sont incontournables dans un environnement aussi difficile.

Answer 3

Un peu plus de détails pourrait aider. Est-ce une grande équipe de production, qui partage de nombreux projets entre eux?Est-ce une petite équipe (5 ish) avec beaucoup de projets?

Pourquoi avez-vous beaucoup de projets?Travaillent-ils sur des cadres de temps différents, certains étant le «vrai travail» et d'autres étant le «si vous n'êtes pas occupé, faites-la comme une tâche de fond».

Je suppose que la clé ici pourrait être le projet du ratio de développeur.

Nous avons un seul département d'environ 15 ans, qui gère 3-4 projets à la fois.Les gens appartiennent généralement à un projet à la fois, mais peuvent se déplacer entre eux à mesure que des projets passent à travers des phases différentes et comme des compétences différentes sont nécessaires.Test en particulier semble changer beaucoup de projets.

comme pour un processus strict ... Faites le processus adapté à vos besoins.Si nous avons une meilleure idée de vos besoins, nous pourrions peut-être faire de meilleures suggestions.

Answer 4

Un élément critique est que les multiples propriétaires de produits doivent être conscients de l'autre et être capable de travailler ensemble en dehors de la portée du développement. S'ils sont séparés dans leurs propres fiefs et chacun essayant d'être plus fort que les autres pour attirer l'attention "leur produit" mérite, alors vous allez avoir des problèmes.

Au moment où tout travail de développement est mis avant l'équipe, ces choses devraient déjà être redressées. Les développeurs ne devraient pas se soucier (ou, dans certains cas, même se soucier de savoir) quelles tâches sont pour quels propriétaires ou quels projets, etc. ils peuvent les soins et connaissent ces choses, mais bien, mais cela ne devrait pas 't être critique.

Les propriétaires de produits et divers autres rôles de haut niveau doivent commencer chaque sprint avec un plan dont les histoires doivent être effectuées pendant ce sprint. Peu importe combien d'histoires d'un projet donné sont incluses, triant que l'exercice est une préoccupation de planification pour ces parties prenantes. Travailler avec l'architecte ou le développeur principal ou tel, ils devraient simplement décider quelles histoires sont implémentées dans le sprint actuel / suivant.

(sur une note latérale, j'ai une zone 51 proposition de ce genre de chose: http:// zone51.stackexchange.com/proposals/9543/Development-methodologies )

Answer 5

IMHO, Scrum est plus efficace lorsque vous avez au moins 3 à 4 itérations de deux semaines avec une équipe de 4 à 6 développeurs.Donc, pour des projets de + - 400 homme / jour

Je pense que c'est une mauvaise idée de faire plusieurs projets à la fois.

Veuillez également vérifier cette question précédemment répondue:

Comment fonctionne-t-il lorsque vous avez plusieurs projets?

Answer 6

Il semble que vous mélangez des concepts de produits et de projets.

Je suggère de gérer un développement de produits avec une équipe et un arriéré de produits.Ne créez pas de projets distincts pour les demandes de fonctionnalités d'un projet.Au lieu de cela, une équipe travaillant sur différentes demandes de différents clients en priorisant les histoires d'utilisateurs.

Cependant, si ce sont des produits complètement distincts que vous développez, essayez de diviser l'équipe afin que chaque équipe puisse se concentrer sur un produit à la fois.