Den Entwicklungsstapel aufschneiden - diagonal?

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:

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.

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:

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:

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.

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).