Wir haben eine "Produktsuite", die aus 3 Hauptprodukten mit separaten Codebasen, 2 C-Projekten, 1 Java besteht.
Die Ingenieure wurden im Namen eines funktionsübergreifenden Teams in dasselbe Scrum-Team versetzt, da die drei Produkte einen vollständigen Produktstapel bilden.
Ingenieure können jedoch keine Codebasen überschreiten. Es wäre zu viel, jede Codebasis hat ihre eigene Architektur und ihren eigenen Zweck.
Dies schafft eine Situation, in der Ingenieure nicht schwärmen oder als Team arbeiten können.
Außerdem sind die meisten Geschichten produktspezifisch. Gelegentlich gibt es jedoch Geschichten, die den 3-Produkt-Stack "vereinheitlichen".
Sollte ein Scrum-Team aus Ingenieuren verschiedener Codebasen bestehen? Für und Wider?
Vor allem gesunder Menschenverstand. Ich meine, Sie können C-Entwickler, die Java zum ersten Mal in ihrem Leben sehen, zwingen, Java zu programmieren, genauso wie Sie mich Ihren C-Code schreiben lassen können. Macht das Sinn? Hängt von einem Ziel ab. Wenn das Ziel darin besteht, ihnen neue Technologien beizubringen, könnte dies durchaus der Fall sein. Wenn das Ziel darin besteht, die Arbeit zu erledigen, nicht so sehr.
Darüber hinaus steht hinter dem Cross-Functional Team nicht die Idee, Entwickler unterschiedlicher Rollen untereinander auszutauschen, sondern unterschiedliche Projektrollen, zB Entwickler, Qualitätsingenieure, Produktmanager/Eigentümer, Release Manager etc. in einem Team zu vereinen.
In diesem Fall wäre meine Frage: Was bringt es Ihnen eigentlich langfristig, wenn Entwickler aus unterschiedlichen Welten in einem Team arbeiten? Möchten Sie, dass sie auf nur eine Technologie umsteigen? Oder diskutieren wir vielleicht über ein 3-köpfiges Team, bei dem es schwierig ist, Leute auszutauschen, wenn jemand einen Tag frei nimmt? Oder funktioniert es so wie es ist? Wenn letzteres zutrifft, versuchen Sie nicht, Änderungen zu erzwingen.
Der andere Weg ist, ob es eine gute Idee ist, sie in einem Team zu haben. Eigentlich würde ich sagen, dass es wahrscheinlicher ist als nicht. Es liegt nicht daran, dass Sie möchten, dass sie sich gegenseitig Aufgaben auf zufällige Weise abnehmen. Was Sie erreichen, wenn Sie sie in einem Team zusammenbringen, ist, dass Sie tatsächlich die Kommunikation zwischen ihnen verbessern, was besonders wichtig ist, wenn sie an einem einzigen Softwarestapel arbeiten.
Hinweis: Es muss nicht automatisch bedeuten, dass sie über ihre Aufgaben oder ihr Pair-Programm schwärmen. Sie können immer noch ein Team sein. Eigentlich ist eine Definition eines Teams nicht "sie können schwärmen" oder so. Spezialisierung ist nichts Schlechtes. Wenn es sinnvoll ist, erlauben Sie den Leuten, sich auf Aufgaben zu konzentrieren, die sie beherrschen. Sie können sie weiterhin in einem Team organisieren.
Wir haben eine sehr ähnliche Situation, wo es 4 Projekte gibt, die alle unabhängig sind, sich aber am Ende der Projekte nahtlos integrieren müssen. Und es ist ein bisschen wie ein Alptraum zu verwalten! :-)
Der Schlüssel hier ist, die Projekte/Produkte getrennt zu halten und sich separat um die Integrationsgeschichten zu kümmern. Wenn die meisten Ihrer Geschichten produktspezifisch sind, klingt es so, als würde es wenig Nutzen bringen, die Entwickler zu einem einzigen „Team“ zusammenzufassen. Halten Sie sie getrennt und konzentrieren Sie sich auf ihre Produkte.
Als nächstes geht es darum, wie man mit den produktübergreifenden Abhängigkeitsgeschichten umgeht ... das ist eine größere Herausforderung. Was wir tun, ist für jede produktübergreifende Story die Story zu einem „Eigentümer“-Projekt hinzuzufügen. Für uns ist dies derjenige, der am meisten in das Feature investiert hat oder logischerweise das Feature besitzt, nicht unbedingt derjenige, der die meiste Arbeit zu erledigen hat. Wenn die Story beispielsweise die Funktionalität X von Produkt A in Produkt B integrieren soll, damit der Kunde von Produkt B etwas erreichen kann, dann würde Produkt B die Story besitzen, weil sie diese Funktion in ihrem Produkt demonstrieren müssen, obwohl der größte Teil der Integration könnte mit Produkt A gearbeitet werden. Ist das sinnvoll? Sobald die Geschichte in einem Projekt ist, müssen wir sie in anderen Projekten nachverfolgen, damit sie nicht vergessen wird. Dazu fügen wir technische Geschichten in die anderen Projekte ein, um sicherzustellen, dass sie nicht verloren gehen.
Um dies zu verfolgen, haben wir ein wöchentliches Treffen der Projektleiter (ähnlich einem Scrum of Scrums), um Fortschritte und Hindernisse zu besprechen.
Das scheint ganz gut zu funktionieren.
„Ingenieure können jedoch keine Codebasen kreuzen. Das wäre zu viel, jede Codebasis hat ihre eigene Architektur und ihren eigenen Zweck.“
Ich würde die Vorstellung in Frage stellen, dass dies bedeutet, dass Ingenieure nicht schwärmen oder als Team arbeiten können. Ich habe mit Teams von Entwicklern zusammengearbeitet, die über sehr isolierte Fähigkeiten verfügen – jeder mit Kenntnissen eines bestimmten Systems, das in einer bestimmten Sprache geschrieben ist – und die immer noch sehr effektiv auf einen einzigen Zweck hinarbeiten.
Meist tun sie dies, indem sie herausfinden, was der nachgelagerte Dienst vom vorgelagerten Dienst benötigt; Zusammenarbeit an Schnittstellen (Dienst-, Anwendungs- oder Bibliotheksschnittstelle), Änderung der bereitgestellten oder verarbeiteten Informationen und der Austausch miteinander .
Ich sah, dass das Team zusammengekommen war, als einer den Stakeholdern einige Arbeiten präsentierte und sagte:
"Letzte Woche haben Sie die Arbeit von Y an dieser Anwendung gesehen. Ich habe Ihnen auch gezeigt, wie mein Dienst Ihre Informationen speichert. Diese Woche möchte ich Ihnen zeigen, wie sie zusammenarbeiten."
Es sind nicht die Technologien oder das Verständnis dafür, die ein Team ausmachen. Es ist der Wunsch sicherzustellen, dass die Arbeit jeder Person zur Arbeit anderer beiträgt und zu einem größeren Ganzen beiträgt.
Dies funktionierte jedoch, weil sie ein bestimmtes Problem zu lösen hatten. Man kann kein Team bilden, indem man einfach Menschen mit unterschiedlichen Fähigkeiten und Erfahrungen zusammenbringt; Stellen Sie stattdessen ein Team zusammen, das über geeignete Fähigkeiten für das Problem verfügt, das es zu lösen versucht, und lassen Sie es lernen oder um Hilfe bitten, wenn es diese braucht.
Wenn Sie das gut machen, geht es nicht darum, sie in dasselbe Team zu setzen. Sie sind dasselbe Team, sobald Sie es zulassen.
Es kann erhebliche Vorteile bringen, wenn Mitglieder des gesamten Teams als Team zusammenarbeiten. Wenn Sie sie dazu bringen können, effektiv als Team zu arbeiten, werden die Schnittstellen zwischen den Ebenen des Stacks besser funktionieren.
Einige Projekte haben eine einfache Architektur und ein vollständig funktionsübergreifendes Team zu haben, kann eher der Realität entsprechen. Sie werden und sollten Leute im Team haben, die Ansprechpartner für bestimmte Fragen sind. Ein Backup für sie zu haben ist gut, zwei oder mehr sind der Himmel.
Bei einem Projekt wie Ihrem erhalten Sie nicht so viele funktionsübergreifende Funktionen wie bei anderen. Was Sie anstreben sollten, ist, dass die Teammitglieder auf beiden Seiten der Schnittstellen zwischen den Schichten die Schnittstellen verstehen. Bei den beiden C-Projekten sollten die Mitglieder den Code auf beiden Seiten der Schnittstelle verstehen. Ebenso für die Schnittstelle zwischen den C- und Java-Codebasen. C und Java sind ähnlich genug, dass die Ingenieure auf beiden Seiten in der Lage sein sollten, dem Code zu folgen.
VORTEILE:
NACHTEILE: