Den Entwicklungsstapel aufschneiden - diagonal?

11

Wir haben ein neues Projekt im Gange, und im Moment wurden die Entwickler in zwei Teams aufgeteilt, Team A und Team B. Dieses Projekt besteht aus zwei Teilen, die im gesamten Entwicklungsstapel entwickelt werden müssen. Sehr vereinfachtes Beispiel unseres unten gezeigten Stapels:

Geben Sie hier die Bildbeschreibung ein

Jeder Teil des Projekts erfordert eine Entwicklung über den gesamten Stack. Daher würde ich normalerweise einen Full-Stack-Entwickleransatz erwarten, mit dem wir unsere Arbeit in Team B aufgeschlüsselt und die Interaktionen zwischen verschiedenen Teilen entworfen und ausgearbeitet haben.

Geben Sie hier die Bildbeschreibung ein

Ich habe jedoch kürzlich erfahren, dass Team A für bestimmte Teile des Stapels verantwortlich sein möchte, und sie schlagen eine Aufteilung zwischen den beiden Teams vor, in denen die Datenabstraktionsschicht (und das Einfügen von Inhalten in die Datenschicht) von verwaltet wird selbst ohne Entwicklung von Team B. Die Kluft würde ungefähr so ​​aussehen:

Geben Sie hier die Bildbeschreibung ein

Für mich fühlt sich das sehr unnatürlich an. Jedes Team hat unterschiedliche Ziele und Zeitpläne, um diese zu erreichen. Team B ist jedoch von Team A abhängig, um Funktionen zu implementieren. Die vorgeschlagene Lösung besteht darin, dass gemeinsame Schnittstellen im Voraus definiert werden (es gibt wahrscheinlich einen Zeitrahmen von 2 Jahren für das Projekt, sodass sie zahlreich sein können). Team A wird dann frühzeitig die erforderlichen Komponenten für diese Schnittstellen entwickeln, obwohl es eigene Ziele hat, während Team B alle Anrufe kurzfristig stummschaltet, damit sie Fortschritte erzielen können.

Ich habe Bedenken hinsichtlich dieses Ansatzes in Bezug auf:

  • Die Schnittstellen können sich ändern, und Team A verfügt möglicherweise nicht über die Bandbreite oder Zeit, um sich ändernden Anforderungen gerecht zu werden.
  • Fehler im Code von Team A können das Fortschreiten von Team B verhindern. Auch hier sind sie möglicherweise nicht die Priorität, um diese zu beheben, da Team A eine andere Priorisierungswarteschlange hat.
  • Mangelndes Wissen über die Teams verteilt - Team B versteht möglicherweise nicht vollständig, was unter der Haube vor sich geht, und trifft aus diesem Grund möglicherweise schlechte Designentscheidungen.

Es wurde vorgeschlagen, dass viele Unternehmen in der Branche Subteams haben und in der Lage sein müssen, damit umzugehen. Nach meinem Verständnis werden die Teams im Allgemeinen entweder so aufgeteilt, wie ich es ursprünglich erwartet hatte (Full Stack), oder indem der Technologie-Stack wie folgt aufgeteilt wird:

Geben Sie hier die Bildbeschreibung ein

Ich bin also daran interessiert zu wissen, was der Rest der Industrie tut. Sind die meisten Teilungen vertikal / horizontal? Ist eine diagonale Aufteilung sinnvoll? Wenn eine diagonale Aufteilung eintreten sollte, scheinen meine Bedenken berechtigt zu sein, und gibt es noch etwas, worüber sich Team B Sorgen machen sollte? Zu beachten ist, dass ich wahrscheinlich für den Erfolg oder Misserfolg von Team B verantwortlich gemacht werde.

Ian
quelle
10
Der "Rest der Branche" macht wahrscheinlich jede erdenkliche Kombination von Spaltungen. Aber ehrlich gesagt haben Sie uns nicht gesagt, warum Team A die Verantwortung übernehmen möchte. Und es macht einen Unterschied, wie groß Ihre Teams sind und ob sie gleich qualifiziert sind.
Doc Brown
Ist in Ihrer dritten Abbildung die Arbeit von Team A und Team B durch eine unterschiedliche API getrennt? Gibt es eine klare, logische Grenze durch diese Trennlinie? Arbeitsteilung ist nicht gerade neu; Stack Exchange hat beispielsweise einen eigenen Designer.
Robert Harvey
@DocBrown Ich glaube, Team A möchte die Verantwortung übernehmen, weil sie das Gefühl haben, dass zu viele Köche nach einem früheren Projektversagen mit einem größeren Team die Brühe verderben - aber ich weiß es nicht genau. Die Teams bestehen jeweils aus 5 Entwicklern und sind einigermaßen gleich gut ausgebildet.
Ian
1
Wenn es Ihnen nicht gelingt, sie von einer vertikalen Aufteilung zu überzeugen, möchten Sie möglicherweise Team A verpflichten, die Anforderungen von Team B mit höherer Priorität als ihre eigenen Anforderungen zu bearbeiten. Dies könnte Blockaden und schlechtes Blut verhindern und scheint ein fairer Preis zu sein.
Hans-Peter Störr
1
@hstoerr: Interessanterweise schlägt die Scrum-Allianz genau dies vor. Ein konsumierendes Komponententeam (das Komponententeam, das die Ergebnisse der anderen Komponententeams verwendet oder "konsumiert") fungiert als Produktbesitzer des Produzententeams. entnommen aus scrumalliance.org/community/articles/2012/september/…
Ian

Antworten:

12

Ihre Bedenken sind äußerst berechtigt. Insbesondere die ersten beiden Punkte, in denen Team A nicht die Zeit hat, Funktionen hinzuzufügen oder Fehler zu beheben, die sich auf Team B auswirken. Ich habe dies einige Male bei meiner eigenen Arbeit gesehen.

Dies könnte eine gute Idee sein, wenn:

  • Es ist bekannt, dass Team A an Projekten arbeitet, für die neue Funktionen in der Datenbank erforderlich sind, während Team B im Wesentlichen "nur Frontend" -Funktionen ausführen möchte. Wenn Team B beispielsweise die neue iPhone-App Ihres Unternehmens schreibt, werden wahrscheinlich für eine Weile keine neuen Datenbankfelder hinzugefügt, da alle Funktionen der Desktop-Version portiert / neu implementiert werden müssen.

  • Der "Full Stack" ist so komplex geworden, dass kein einzelner Entwickler (oder Entwicklerteam) das Ganze effektiv "besitzen" kann. Mit "eigenen" meine ich nicht nur das Hinzufügen von Funktionen und das Beheben von Fehlern, sondern das Verstehen und Verwalten des gesamten Systems bis zu dem Punkt, an dem vermieden werden kann, dass im Laufe der Zeit mehr technische Schulden entstehen. In diesem Fall ist die "diagonale" Aufteilung der sinnvolle Schritt, wenn Team A eine UI / Web-API besitzt, die entweder extrem einfach oder unvermeidlich eng mit der DAL / Datenbank-Implementierung verbunden ist (möglicherweise einige interne Diagnosetools?), Während Team B dies tut all die komplizierten benutzerbezogenen Frontend-Sachen.

  • Das Management ist sich des Risikos bewusst, dass Team A zu einem Engpass wird, und wäre bereit, die Dinge zu de-diagonalisieren, wenn oder wenn dieses Risiko zu einem echten Problem wird.

Ich kann nicht mit dem sprechen, was in der Branche mehr oder weniger üblich ist, aber zumindest dort, wo ich arbeite, müssen alle Anwendungsentwickler eindeutig "Full Stack" sein. Was wir haben, sind "Infrastruktur" -Teams, die unsere interne Datenbank, unser Web-Service-Framework und unser UI-Framework entwickeln / warten (habe ich schon erwähnt, dass mein Unternehmen riesig ist?), Damit alle unsere Hunderte von Anwendungen über einen vollständigen Stack verfügen können Entwickler, während das gesamte Unternehmen allen unseren Diensten eine konsistente Leistung und Benutzeroberfläche bieten kann.

Vor kurzem hat unser Unternehmen ein brandneues UI-Framework entwickelt. Es gab also eine Zeit, in der einige unserer neuen Apps aufgrund von Fehlern und fehlenden Funktionen im neuen Framework ziemlich stark blockiert waren. Dies ist nicht mehr der Fall, hauptsächlich weil einige von uns die Erlaubnis erhalten haben, Pull-Anfragen an das Team zu senden, dem das Framework gehört (nicht ganz "De-Diagonalisierung", aber Sie haben die Idee).

Ixrec
quelle
2
In Ihrem zweiten Punkt scheint dies für jede Geschäftsanwendung von angemessener Größe zu gelten. Bibliotheken mit genau definierten APIs scheinen die logischen Grenzen zu sein, vorausgesetzt, sie sind nicht zu groß.
Robert Harvey