2009-03-20 12 views
0

La société dans laquelle je travaille a été en train de tester un projet et cherche maintenant à mettre de l'ordre dans trois ou quatre équipes de projet différentes. Nous prévoyons que ces équipes travailleront dans des branches distinctes (nous utilisons SVN).Intégration de code avec plusieurs points de vente

Nous ne sommes pas sûrs si les sprints des différentes équipes doivent se terminer simultanément ou si nous devons décaler les sprints de manière à ce que les sprints se terminent et que les sprints soient séparés. Le produit est un site Web, le déploiement n'est donc pas un problème.

Nous sommes préoccupés par l'intégration de code, si trois équipes intègrent leur code en même temps, cela risque de conduire à des conflits. Mais si les versions sont décalées, cette charge peut être déplacée vers les équipes qui sont au milieu du sprint.

Est-ce que quelqu'un a essayé l'une ou l'autre approche et qu'a-t-elle trouvé?

+0

Je vote pour clore cette question hors-sujet parce que [la gestion de projet est maintenant hors-sujet sur Stack Overflow] (// meta.stackoverflow.com/questions/343829/is-stack-overflow--appropriate -website-to-ask-about-projet-gestion-questions/343841 # 343841). Posez ces questions sur [SoftwareEngineering.SE] (// softwareengineering.stackexchange.com/) et [ProjectManagement.SE] (// pm.stackexchange.com/) à la place. (Malheureusement, cette question est trop ancienne pour être migrée.) – robinCTS

Répondre

1

Nous avons aussi plusieurs équipes, nos sprints sont alignés, et nous nous intégrons en continu: quand une histoire est complète. C'est parfois agaçant, mais nous évitons ainsi de longues périodes d'intégration qui pourraient être douloureuses. Chaque histoire est développée dans une branche distincte, puis intégrée dans la branche principale. Lorsque deux équipes doivent partager quelque chose qui n'est pas intégré, elles travaillent dans la même branche.

Nous construisons un produit sous emballage, le déploiement n'est donc pas un problème pour nous.

Les deux questions sont liées: si vous intégrez seulement à la fin des sprints, ce que je ne recommanderais pas, alors vous feriez mieux d'échelonner les sprints.

Henrik Kniberg (auteur de Scrum et XP des tranchées) a écrit un article sur Version Control for Multiple Agile Teams.

+0

J'ai trouvé l'article infoq après avoir posé la question, mais votre réponse semble résumer bien les choses. Je pense qu'intégrer après qu'une histoire soit faite est la voie à suivre. –

0

Nous avons deux équipes avec des sprints synchronisés et cela semble fonctionner plutôt bien. Notre stratégie consiste à garder les histoires petites. Faites les histoires et publiez-les souvent sur le tronc pendant le sprint. Oui, nous obtenons des conflits de fusion mais ils sont gérables.

Oh et assurez-vous que les équipes communiquent bien entre elles.

0

jeter un oeil à cet article, explique ces questions succinctement. http://www.infoq.com/news/2008/04/kniberg-agile-version-control

Intégration continue. Intégrez tout le temps, à chaque check-in, n'attendez pas la fin de la journée ou la fin d'une itération pour l'intégrer. Avoir des tests unitaires et des tests d'acceptation automatisés qui s'exécutent à chaque enregistrement pour s'assurer que personne ne casse le code.

Planifiez des fonctions plus petites et travaillez sur de petits travaux. Les petits morceaux sont plus faciles à réparer quand les choses se cassent. Toutes les équipes travaillent-elles sur la même ligne de produits/codes? Vous pouvez essayer de planifier les fonctionnalités afin que les fonctionnalités n'affectent pas les fonctionnalités d'une autre équipe. Essayez d'assister aux stand-ups de l'autre équipe afin de pouvoir résoudre les conflits d'intégration plus tôt. Partagez le travail si les fonctionnalités sont en conflit.