Ich arbeite als Scrum Master an einem Ort, an dem wir zwei unterschiedliche Produkte haben. Und diese Produkte haben Untermodule:
Product A: (The bigger product)
Submodule A.1
Submodule A.2
Submodule A.3
etc.
Product B: (The smaller product)
Submodule B.1
Submodule B.2
Submodule B.3
etc.
Aktuell haben wir zwei Mannschaften. Produkt-A-Team (bestehend aus 12 Entwicklern) und Produkt-B-Team (bestehend aus 3 Entwicklern)
Außerdem haben wir zwei Tester, die eigentlich nicht Teil dieser Teams sind und einen anderen Rückstand haben.
In unseren Teams haben wir einen Codeüberprüfungsprozess, der durchgeführt wird, bevor ein Problem gelöst wird. Ein Code, der von einem Peer nicht überprüft wurde, kann also nicht als erledigt markiert werden.
Ich weiß, 12 Entwickler sind viel für ein Scrum-Team und 3 Entwickler sind eine kleine Zahl für ein Scrum-Team. Aus diesem Grund und aus einigen anderen Gründen stehen wir vor einigen Problemen.
1) Das Team von Produkt B bewegt sich nur langsam und verliert zu viel Zeit mit Problemen. Die Codeüberprüfungen werden nicht vollständig durchgeführt und fehlerhafte Codes werden als erledigt markiert. Das B-Team ist eigentlich kein Team, jeder hat seine eigenen Ziele. Das liegt daran, dass immer ein Entwickler an den Kernfunktionen und auf Betriebssystemebene arbeitet. Der andere Entwickler arbeitet immer auf der Seite der Benutzeroberfläche (eigentlich ist er kein UI-Designer, sondern ein Backend-Entwickler) und der andere Entwickler ist kürzlich dem Team beigetreten und arbeitet an Möglichkeiten und recherchiert, wie das Produkt mit mehr ausgeführt werden kann Leistung.
Der Entwickler, der auf Betriebssystemebene arbeitet, überprüft also die UI-Codes. Der UI-Entwickler überprüft die OS-Level-Codes. Sie haben tatsächlich nicht das Fachwissen, um den Code des anderen zu überprüfen, und wissen nicht wirklich oder sind nicht wirklich daran interessiert, was der andere tut.
2) Produkt Ein Team ist ein großes Team und das Produkt ist ein riesiges Produkt. Es besteht aus mehreren (etwa 10) Untermodulen. Alle Submodule sind unterschiedliche Module auf der Serverseite (manchmal verwenden sie gemeinsame Bibliotheken und gemeinsame conf-Dateien, Module usw., aber im Allgemeinen unterschiedliche), aber sie teilen sich alle die gleiche GUI (Eine Java-Swing-Anwendung wird verwendet, um alle diese Module zu verwalten). Also 2 Entwickler arbeiten immer an der GUI, einige Entwickler arbeiten an den meisten Modulen auf der Backend-Seite. Und einige Entwickler arbeiten immer an demselben Submodul (z. B.: Submodul A.1 und Submodul A.2). Diese Leute haben also viel Erfahrung mit diesem Modul, wissen aber nicht viel über den Rest des Produkts. Während die anderen Entwickler viel über das Produkt wissen, außer von diesen Submodulen (Submodul A.1 und Submodul A.2)
Eigentlich sind alle unsere Entwickler gute Entwickler, die mit allem umgehen können, was man ihnen entgegenwirft. Aber natürlich sind einige von ihnen auf der UI-Seite besser, während einige von ihnen auf der Backend-Seite besser sind. Einige haben viel Erfahrung in einem bestimmten Modul gesammelt, sodass eine Aufgabe in diesem bestimmten Modul immer von dieser bestimmten Person erledigt wird. Dies führt zu Ein-Mann-Shows, das Scheitern und der Erfolg liegen nicht bei den Teams.
Meine Hauptfrage ist also, wie sollten wir Teams und Backlogs bilden? Im Moment haben wir zwei Teams (Team für Produkt A und Produkt B) und zwei Backlogs (Backlog für Produkt A und Produkt B). Sollen wir das behalten?
Wir planen, Teams wie das Betriebssystemteam, das Plattformteam, das Frontend-Team, das Architekturteam, das Implementierungsteam, das Testteam, das Sicherheitsteam und das Dokumentationsteam zu bilden. Eigentlich weiß ich nicht einmal, wie das passieren wird, wir haben nicht einmal so viele Entwickler. Vielleicht wird eine Person in mehreren Teams sein, ich weiß es nicht. Und wenn wir solche Teams bilden, wie sollen wir die Backlogs bilden?
Aber ich denke, diese Art von Teamstruktur ist gegen Scrum, weil Scrum-Teams funktionsübergreifend sein sollten. Alle Arten von Expertise sollten in Teams sein.
Oder sollten wir zu Beginn jedes Sprints entsprechend den Anforderungen des Sprints neue Teams bilden. Aber wie wird das sein (Wer nimmt an welchem Sprint-Planungsmeeting teil?)
PS: Die Entwickler von Produkt A und Produkt B sind qualifiziert genug, um an dem jeweils anderen Produkt zu arbeiten.
Und entsprechend der Teamstruktur empfehlen Sie, wie viele Scrum Master wir haben sollten. Reicht ein Scrum Master oder sollte jedes Team einen eigenen Scrum Master haben?
Du stellst hier viele Fragen:
Komponententeams (Plattform, Frontend ...): Sie haben Recht, das geht gegen Scrum. Wenn Sie mit der Übergabe Zeit verlieren wollen, dann tun Sie dies :-)
gemeinsam genutzte Teammitglieder geht auch gegen Scrum. Multitasking verlangsamt Menschen, lässt sie den Fokus verlieren. Gut für schlechte Qualität :-)
Wie geht man mit einem richtig großen und ganz kleinen Team um? Die offensichtliche Lösung besteht darin, die Teammitglieder zu verschieben. Bestellen Sie es einfach nicht. Sprechen Sie das Problem mit den Teams an. Vielleicht möchte jemand aus dem großen Team im kleinen Team aushelfen. Dies kann für eine begrenzte Anzahl von Sprints oder dauerhaft sein. Es könnte eine Art Sabbatical sein.
Manche Leute arbeiten die ganze Zeit am selben: Erinnerst du dich an T-förmige Arbeiter? Es ist in Ordnung, wenn einige Teammitglieder eine Sache wirklich gut können und dies oft tun. Aber wenn Sie es ausschließlich tun, stoßen Sie auf Engpässe. Inspirieren Sie den Spezialisten, zu unterrichten und sein Know-how zu teilen. Sie bleiben die Spezialisten, aber andere können und sollten aushelfen.
Wie viele Rückstände? Maximal eine pro Produkt, unabhängig von der Anzahl der Teams.
Jeden Sprint neue Teamstruktur: Das schon mal gemacht, funktioniert nicht. Ein Team braucht Zeit, um sich zu formen. In jedem Sprint neue Teams aufzubauen, macht wirklich schlechte Teams. Ein zusätzlicher Effekt ist, dass jeder nach einer Weile von allem nur ein bisschen gesehen hat, aber nichts tiefer versteht.
Wie viele Scrum Master: Bei vielen Themen ist ein Scrum Master pro Team notwendig.
Sehr späte Antwort. Dir wird es nicht helfen, aber vielleicht jemand anderem.
Produkt-A-Team (bestehend aus 12 Entwicklern) und Produkt-B-Team (bestehend aus 3 Entwicklern)
Team A ist zu groß für eine effektive Kommunikation. Team B könnte theoretisch funktionieren, aber es ist sehr klein.
weil immer ein Entwickler an den Kernfeatures und auf Betriebssystemebene arbeitet
Sie sollten keine "Kernfunktion" haben. Ihre Funktionen sollten dem Endbenutzer einen Mehrwert bieten. Jede „Kernfunktion“, die „UI-Funktionen“ benötigt, um tatsächlich verwendet zu werden, liefert keinen Wert. Es ist eine technische Aufgabe, kein Feature.
Im Idealfall würden Ihre Entwickler an derselben Funktion zusammenarbeiten, und normalerweise aus ihrer eigenen Perspektive (Kern. UI.), Aber mit dem gleichen Benutzerwert im Auge.
In deinem Fall würde ich die Teams mischen. Erstens muss das Backlog Benutzergeschichten enthalten (Wert für den Benutzer liefern); nicht 'dieses UI-Feature erstellen, das immer noch erfordert, dass XYZ erstellt wird, bevor es funktioniert'.
Ich würde sie zusammenrufen (alle 15); sagen Sie ihnen den Rückstand; und bitten Sie sie, sich rund um die Arbeit zu organisieren. * Bilden Sie selbst Teams * Niemand wird zurückgelassen * Kein Team kleiner als 4 oder größer als 7 * Jedes Team muss die Fähigkeiten haben, die Arbeit zu erledigen.
Am Ende haben Sie 3 Teams und jedes kann einen anderen Schwerpunkt haben. Team 1 kann sich auf Produkt A konzentrieren, und die Teams 2 und 3 können beide an Produkt A + B arbeiten.