2009-03-20 6 views
0

Die Firma, in der ich arbeite, hat Scrum bei einem Projekt getestet und will jetzt drei oder vier verschiedene Projektteams ausspeien. Wir gehen davon aus, dass diese Teams in getrennten Feature-Sparten arbeiten werden (wir verwenden SVN).multiple scrums code integration

Wir sind nicht sicher, ob die Sprints der verschiedenen Teams gleichzeitig enden sollten oder ob wir die Sprints staffeln sollten, damit der Sprint endet und die Sprints getrennt sind. Das Produkt ist eine Website, daher ist die Bereitstellung kein Problem.

Wir sind besorgt über Code-Integration, wenn drei Teams ihren Code zur gleichen Zeit integrieren, ist dies wahrscheinlich zu Konflikten führen. Aber wenn die Releases gestaffelt sind, kann diese Last nur zu den Teams bewegt werden, die Midsprint sind.

Hat jemand versucht entweder Ansatz und was haben sie gefunden, um zu arbeiten?

+0

Ich stimme für das Schließen dieser Frage als Off-Topic ab, da [das Projektmanagement jetzt off-topic auf Stack Overflow ist] (// meta.stackoverflow.com/questions/343829/is-stack-overflow-anpassen -Website-zu-Fragen-über-Projekt-Management-Probleme/343841 # 343841). Stellen Sie diese Fragen stattdessen auf [SoftwareEngineering.SE] (// softwareengineering.stackexchange.com/) und [ProjectManagement.SE] (// pm.stackexchange.com/). (Leider ist diese Frage zu alt, um migriert zu werden.) – robinCTS

Antwort

1

Wir haben auch mehrere Teams, unsere Sprints sind ausgerichtet, und wir integrieren kontinuierlich: Wenn eine Geschichte abgeschlossen ist. Das ist manchmal ärgerlich, aber so vermeiden wir lange Integrationsperioden, die schmerzhaft sein können. Jede Geschichte wird in einem eigenen Zweig entwickelt und dann in den Hauptzweig integriert. Wenn zwei Teams etwas teilen müssen, das nicht integriert ist, arbeiten sie in derselben Branche.

Wir bauen ein Paketprodukt auf, daher ist die Bereitstellung für uns kein Problem.

Die beiden Fragen sind miteinander verknüpft: Wenn man nur am Ende der Sprints integriert, was ich nicht empfehlen würde, dann ist es besser, die Sprints zu taumeln.

Henrik Kniberg (Autor von Scrum und XP aus den Schützengräben) schrieb einen Artikel auf Version Control for Multiple Agile Teams.

+0

Ich fand den Infoq-Artikel, nachdem ich die Frage gestellt hatte, aber Ihre Antwort scheint die Dinge gut zusammenzufassen. Ich denke, nach einer Geschichte zu integrieren ist der Weg zu gehen. –

0

Wir haben zwei Teams mit synchronisierten Sprints und es scheint ganz gut zu funktionieren. Unsere Strategie besteht darin, die Geschichten klein zu halten. Erledige die Geschichten und veröffentliche sie während des Sprints oft im Kofferraum. Ja, wir bekommen Merge-Konflikte, aber sie sind überschaubar.

Ach und stellen Sie sicher, dass die Teams gut miteinander kommunizieren.

0

Werfen Sie einen Blick auf diesen Artikel, erklärt diese Probleme prägnant. http://www.infoq.com/news/2008/04/kniberg-agile-version-control

Kontinuierliche Integration. Integrieren Sie die ganze Zeit, bei jedem Check-in, warten Sie nicht bis zum Ende des Tages oder am Ende einer Iteration zu integrieren. Führen Sie Komponententests und automatisierte Abnahmetests durch, die bei jedem Check-in ausgeführt werden, um sicherzustellen, dass niemand den Code bricht.

Plane kleinere Funktionen, arbeite an kleineren Stücken. Kleinere Brocken sind leichter zu reparieren, wenn etwas kaputt geht. Arbeiten alle Teams an demselben Produkt/derselben Codezeile? Sie können versuchen, die Features so zu planen, dass die Features keinen Einfluss auf die Features haben, an denen ein anderes Team arbeitet. Versuchen Sie, an den Stand-ups des anderen Teams teilzunehmen, damit Sie Integrationskonflikte früher lösen können. Teilen Sie die Arbeit, wenn Features Konflikte verursachen.