Wir verwenden ein beliebtes Projekttool, Pivotal Tracker. Wir haben beschlossen, unser Produktteam in drei separate Teams aufzuteilen, die sich jeweils auf Funktionen mit einem bestimmten Thema konzentrieren. Es gibt einige Diskussionen darüber, ob jedes Team seinen eigenen Tracker haben sollte oder ob wir einen integrierten Tracker verwenden sollten.
Die Teams bleiben mindestens ein Viertel des Jahres zusammen. Es geht alles in eine Codebasis und in ein Quellrepository. Wir teilen auch Demo- und Staging-Umgebungen. Wir sind auch alle im selben Raum.
Irgendwelche Ratschläge in beide Richtungen? Ich neige dazu, alles in einem Tracker zu behalten und Labels zur Unterscheidung zu verwenden, aber ich frage mich, ob es sinnvoll ist, für jede Zeit separate Geschwindigkeitsberechnungen zu haben. Alle Gedanken wären willkommen.
Meine Neigung entspricht deiner; Ich kann mir aus eigener Erfahrung keine Situation vorstellen, in der ich separate Tracker für dasselbe Projekt, aber für verschiedene Teams erstellen würde, außer in einer Situation, in der die Berechnungen oder Berichte, die Sie zu erstellen versuchen, nicht auf Tag- oder Komponentenebene durchgeführt werden können , oder auf eine andere leicht pro Team zu bestimmende Weise. Es scheint mir, dass die Fokussierung Ihrer Tools auf den Aufbau des Teams mehr auf die Verwaltung der verschiedenen Teams als auf die Verwaltung des Projekts selbst hinauslaufen würde.
Wenn die Teams an verschiedenen Teilen des Projekts arbeiten, die als autonome Teilprojekte betrachtet werden können, die zusammen ein größeres Projekt bilden, sollten Sie die Aufteilung in Betracht ziehen.
Aus Ihrer Beschreibung heraus klingt es eher wie ein großes Team, das an demselben Projekt arbeitet, das nach Fachgebieten aufgeteilt ist, um die Übereinstimmung und Austauschbarkeit zwischen den Entwicklern innerhalb jedes Unterteams zu gewährleisten.
Integration braucht Zeit und kostet Geld. Es erfordert Mühe und Geld, jedes Projekt in einem einzigen Tool synchronisiert zu halten. Wenn diese Teams viel Hin und Her, Abhängigkeiten und Koordination haben, wäre das Geld gut angelegt. Wenn das Team einfach auf sich allein gestellt ist und sein Stück vom Kuchen abliefert, wenn es fertig ist, dann würde ich den Integrationsaufwand in Frage stellen. Intuitiv erscheint es mir logischer und einfacher, ein einziges Tracking-Tool zu verwenden. Aber wir verbessern uns nicht, wenn wir den Status quo nicht hinterfragen. Wenn im Team diskutiert wird, dann sehen einige Mitglieder darin einen Nutzen, der geprüft werden sollte.
Also, das erste, was ich mir ansehen würde, sind die Kosten. Zweitens wäre die Integration und wie einfach es für mich wäre, den Status und die Gesundheit der Teams und des Gesamtprojekts wirklich zu kennen. Wäre es besser für mich, einem oder drei Werkzeugen zu misstrauen?
Wenn die 3 Teams alle an völlig separaten Projekten arbeiten würden, wäre ich versucht, sie als 3 separate Einheiten und 3 separate Experimente zu behandeln. Wenn Sie kleinen Teams die Freiheit geben, unabhängig zu arbeiten, können sie experimentieren und Methoden finden, die ihnen helfen, am erfolgreichsten zu sein.
Wenn ein Team eine Entdeckung macht, die ihre Produktivität in die Stratosphäre katapultiert, können sich die anderen Teams entscheiden, sie zu übernehmen und umgekehrt.
In dieser Situation besteht jedoch eine sehr hohe Wahrscheinlichkeit, dass die drei Teams eng zusammenarbeiten müssen. Schließlich bauen sie alle das gleiche Produkt. Wenn Sie den Präzedenzfall schaffen, dass es in Ordnung ist, von der Gruppe abzuweichen und andere Tools zu verwenden, kann es später schwierig sein, die Teams zusammenzuführen, und es kann schwierig sein, während der Integrationsphase funktionsübergreifende Teams zu bilden.
In dieser Situation wäre mein Vorschlag, wenn irgend möglich, ein einzelnes System auszuwählen und dabei zu bleiben.
Darüber hinaus besteht das Risiko, dass Sie den Status und Fortschritt Ihres Produkts verlieren, wenn Sie es in einige wenige Systeme aufteilen.
jmort253