Nachteile vertikaler User Stories

Der agile Ansatz besteht darin, die Arbeit in vertikale User Stories zu strukturieren und einen fokussierten, aber voll funktionsfähigen Teil der Anwendung von Ende zu Ende bereitzustellen . Da dies der neue Ansatz zum Erstellen von Software ist, habe ich viel Literatur darüber gelesen, warum dies besser ist als horizontale Geschichten, aber ich finde nicht viel über die Nachteile dieses Ansatzes.

Ich habe bereits die agile Kühlhilfe getrunken und bin mir auch einig, dass das vertikale Schneiden des Kuchens viele Vorteile gegenüber dem horizontalen Schneiden hat. Hier ist eine kurze Liste von Nachteilen, die ich mir einfallen lassen könnte:

• Ein Entwickler kann eine Funktion anfangs möglicherweise langsamer implementieren, da er alle für die Entwicklung der Story erforderlichen Technologien verstehen muss (Benutzeroberfläche + Serviceschicht + Datenzugriff + Netzwerk usw.).
• Das gesamte Architekturdesign (das Rückgrat der Anwendung) passt nicht wirklich zu diesem Mantra (einige könnten jedoch argumentieren, dass es Teil einer User Story ist, die gesamte Architektur zu entwickeln / zu ändern).

Was sind weitere Nachteile beim vertikalen Schneiden von User Stories?

Hinweis: Der Grund, warum ich diese Frage jetzt stelle, ist, dass ich versuchen werde, ein Team davon zu überzeugen, Geschichten auf "vertikale Weise" zu schreiben, und ich möchte in der Lage sein, die möglichen Kompromisse im Voraus zu erörtern, damit sie gewinnen Betrachten Sie den Ansatz nicht als Fehlschlag, wenn sie mit den Nachteilen konfrontiert sind.

Ich kenne keine langfristigen Nachteile. Kurzfristig und für ein Team, das neu in dieser Art von Entwicklung ist, besteht der Hauptnachteil darin, dass es etwas gewöhnungsbedürftig und etwas lernfähig ist.

Die effizienteste Art, vertikal zu arbeiten, besteht darin, Full-Stack-Entwickler zu haben: Auf diese Weise kann eine Story normalerweise von einer Person ausgeführt werden (oder von mehreren Personen, jedoch ohne Pipelining-Aufgaben ). Dies erfordert natürlich, dass die Entwickler vertikal über den Stapel arbeiten (von HTML bis zur Datenbank im Fall einer Webanwendung).

Wenn Ihr Team nicht daran gewöhnt ist, an vertikalen Storys zu arbeiten, ist es sehr wahrscheinlich, dass es das Gegenteil tut: Jede Person kennt nur eine Ebene / Ebene der Anwendung. Wenn Sie vertikale Storys einführen, können Sie erwarten, dass das Team sie in Aufgaben aufteilt, die Ebenen entsprechen, und die Aufgaben dann an verschiedene Personen verteilt. Dies wird sehr ineffizient sein.

Der beste Ansatz, den ich in dieser Hinsicht geben kann, besteht darin, dieses Pipelining zunächst zu tolerieren und gleichzeitig klar zu machen, dass das langfristige Ziel völlig anders ist. Lassen Sie Teammitglieder über mehrere Ebenen hinweg Programme programmieren, um Vertrauen aufzubauen und schließlich zu ermöglichen, dass die Mitarbeiter völlig unabhängig sind.

Ich stimme der anderen Antwort nicht zu, dass dieser Ansatz technische Schulden mit sich bringt. Es kann, aber auch jeder andere Ansatz.

Ich habe viel über genau diese Frage nachgedacht.

Ich denke, es ist wichtig, zwischen dem Schneiden nach individuellen Verantwortlichkeiten und dem Schneiden nach Teamverantwortlichkeiten zu unterscheiden. Ich werde diese Antwort hauptsächlich auf das Schneiden von Teams konzentrieren.

Einige Hintergrundinformationen: Ich habe in Projekten mit Full-Stack-Entwicklern, Single-Tier-Entwicklern, vertikalen (Full-Stack) Teams, horizontalen (Single-Tier) Teams und diagonalen Teams gearbeitet. Mit diagonalem Team meine ich, alle Ebenen zu enthalten, die für eine Story benötigt werden, aber nicht unbedingt alle Ebenen im System, und möglicherweise auch mehrere Entwickler, die sich auf dieselbe Ebene konzentrieren. Mit anderen Worten: vertikal im Geist, aber möglicherweise etwas horizontal im Erscheinungsbild oder im Implementierungsdetail.

Kürzlich habe ich in einer Gruppe gearbeitet, die von horizontalen Teams zu diagonalen (fast vertikalen) Teams gewechselt ist. Es war besonders lehrreich zu sehen, wie dieselbe Gruppe von Menschen auf zwei verschiedene Arten ausgerichtet wurde. Es macht einige Vor- und Nachteile deutlich.

Ich werde meine bisherige Meinung mit dem folgenden zusammenfassenden Vergleich abrunden:

Horizontale Teams

Vorteile:

• Fördert eine gute Trennung von Bedenken und lose gekoppelten Ebenen
• Viel einfacheres Workload-Verteilungsmanagement
• Einfach für spezialisierte technische Leiter zu verwalten
• Fördert die Zusammenarbeit innerhalb der Ebene, Best Practices, Stolz und eine Kultur der Exzellenz
• Passt sich den natürlichen / entstehenden Kommunikationsmustern an

Nachteile:

• Kann zur Isolation von Ebenen führen und somit die Kommunikation zwischen Ebenen behindern
• Aktiviert die Tier "Bubble" -Kultur, wenn sie nicht aktiviert ist
• Es ist schwierig, die Führung der Generalisten auszunutzen
• Verhindert Generalisten

Vertikale / Diagonale Teams

Vorteile:

• Alle Teile einer User Story in einem Team ("One-Stop-Shop")
• Unterstützt speziell die Bereitstellung von n-Tier-Storys in einem einzigen Sprint (obwohl Sie das wirklich brauchen?)
• Fördert die Zusammenarbeit zwischen den Ebenen und das Wachstum allgemeiner Fähigkeiten
• Unterstützt Generalisten

Nachteile:

• Viel schwierigeres Workload-Verteilungsmanagement
• Ermöglicht eine schlechte Trennung von Bedenken und eng gekoppelten Ebenen
• Verhindert die Spezialisierung durch Einschränkung der Kommunikation innerhalb der Ebene; Es ist schwer zu erkennen, wie aus dieser Struktur eine Kultur der Exzellenz entstehen kann, ohne das horizontale / fachliche Verhalten zu mildern

Ich glaube nicht, dass die Teammitgliedschaft eine einheitliche Lösung bietet. Es scheint jedoch ziemlich einfach zu sein, dass das vertikale Team besser für Organisationen aufgestellt ist, die eine Verallgemeinerung benötigen. Wenn Ihre Ingenieure Generalisten sind und gerne Full Stack arbeiten, ist dies ein guter Grund, vertikale Teams in Betracht zu ziehen. Das horizontale Team ist besser für Organisationen geeignet, die Spezialisten benötigen. Wenn Ihre Ingenieure Spezialisten sind, ist dies ein guter Grund, horizontale Teams in Betracht zu ziehen.

Wie andere bereits erwähnt haben, können sekundäre Strukturen / Verhaltensweisen, die in die andere Richtung schneiden, dazu beitragen, die Nachteile beider Systeme zu mindern. Ein interessanter mildernder Faktor ist die Sprintdauer. Kurze Sprints machen einige der Nachteile horizontaler Teams erträglicher. Wenn Sie das Backend diese Woche und das Frontend nächste Woche erstellen können, ist das möglicherweise schnell genug?

Um einige dieser vorgeschlagenen Prinzipien auf ein reales Problem anzuwenden ... Ich werde sagen, dass die horizontalen Schichten für ein sehr reales SaaS-Entwicklungsteam, an dem ich gearbeitet habe und das sehr herausfordernde technische Probleme in jeder Ebene gelöst hat, recht gut funktioniert haben ( wo Spezialisierung meiner Meinung nach unglaublich wichtig war), wo die Häufigkeit der Lieferung (und die Zuverlässigkeit bei hoher Granularität / Häufigkeit) entscheidend für den Geschäftserfolg war. Bitte beachten Sie, dass diese Schlussfolgerung für ein ganz bestimmtes reales Team gilt und keine allgemeine Aussage über die Überlegenheit des horizontalen Schneidens.

Eine Einschränkung: Ich bin wahrscheinlich voreingenommen gegen die Annahme von Behauptungen allgemeiner Fähigkeiten durch eine Person in der modernen Softwareentwicklungswelt ohne signifikante Beweise, obwohl ich einige seltene außergewöhnliche Generalisten gekannt habe. Ich bin der Meinung, dass Allgemeinheit in der Tat eine große (vertikale?) Ordnung ist, insbesondere da jede Ebene an Komplexität zunimmt und mit der Verbreitung alternativer Sprachen / Plattformen / Frameworks / Bereitstellungen unterschiedliche Anforderungen erfüllt werden. Gerade in diesen Tagen kann ein Alleskönner ganz leicht ein Meister sein. Anekdotisch finde ich auch, dass die meisten Menschen sich mit einigen Ausnahmen ziemlich stark spezialisieren wollen.

Der große Nachteil, den ich festgestellt habe, ist, dass es für ein Team schwierig ist, die Anwendung nach einem einheitlichen Architekturansatz zu erstellen.

In der Anfangsphase des Projekts werden alle ihre Ebenen isoliert schreiben. Die Geschichten (und Ebenen) werden funktionieren, aber wenn Sie auf das gelieferte Produkt am Ende des Sprints zurückblicken, werden Sie leicht die geringfügigen Unterschiede zwischen den Architekturideen der einzelnen Entwickler erkennen.

So etwas ist unvermeidlich, aber kein Blocker. Ich habe versucht, dies auf zwei Arten zu bekämpfen:

1. Führen Sie lange Designdiskussionen mit dem Team, bevor Sie jede Story implementieren
   • Das wird schnell anstrengend. Es ist oft zu früh, um eine fundierte Entscheidung zu treffen, und dann streiten Sie sich einfach über Dinge, die sich definitiv ändern müssen.
2. Gehen Sie voran und entwickeln Sie sich relativ isoliert, wobei Sie bedenken, dass Sie technische Schulden aufbauen .
   • Der Schlüssel hier ist, die technischen (architektonischen) Schulden als Problem zu protokollieren. Dies ist etwas, das zurückgezahlt werden muss.
   • Nach einigen Sprints fällt es Ihnen leichter, sich für eine kohärente und einheitliche Architektur zu entscheiden. In diesem Fall sollten Sie einen Härtungssprint anfordern, um einen Teil Ihrer technischen Schulden zurückzuzahlen (überarbeiten Sie den vorhandenen Code). Alternativ können Sie es in den nächsten Iterationen des Projekts stückweise zurückzahlen.

Das einzige andere Problem, an das ich denken kann, ist, dass zu Beginn eines Projekts normalerweise viel Code für das Boilerplate hinzugefügt werden muss. Das Schreiben vertikaler Slice-Storys bedeutet, dass die Geschwindigkeit des Teams in den ersten Storys aufgrund dieser vorausgesetzten Boilerplate künstlich niedrig sein wird. Solange jedoch jeder weiß, dass dies nur die ersten Sprints betreffen sollte, ist alles in Ordnung.

Ich kenne auch keine Nachteile, aber vertikale Geschichten können schlecht umgesetzt werden.

Als ich meine Karriere begann, trat ich einem Team bei, das XP machen wollte, aber keine Erfahrung damit hatte. Bei der Verwendung vertikaler User Stories haben wir eine Reihe von Fehlern gemacht.

Eines der Probleme, auf die wir bei horizontaler Arbeit gestoßen sind, war, dass Features nicht gut über die Ebenen hinweg integriert wurden. APIs stimmten häufig nicht mit der Spezifikation, fehlenden Funktionen und zahlreichen anderen Problemen überein. Oft, weil der Entwickler von zu etwas anderem übergegangen war, musste man entweder auf sie warten oder es selbst tun.

Der Wechsel zu Vertical Stories löste diese Probleme und reduzierte / beseitigte die Verschwendung von Nacharbeiten zur Integration.

Es gibt eine Reihe von XP-Methoden, die diese Arbeitsweise unterstützen. Jeder muss in der Lage sein, an jedem Bereich zu arbeiten, und von jedem wird erwartet, dass er die gefundenen Fehler behebt ( Besitz des kollektiven Codes ).

Wenn Sie vertikale Storys ändern, kann es schwierig sein, in Bereichen zu arbeiten, mit denen Sie nicht vertraut sind. Paarprogrammierung kann helfen, wenn Sie nicht sicher sind, jemanden im Team zu finden, der mit ihm gepaart ist. Ich habe festgestellt, dass die Paarprogrammierung der schnellste Weg ist, um mit einer neuen Codebasis auf dem neuesten Stand zu sein.

Ohne starke Eigentümer über Schichten stellten wir fest, dass es einige Überschneidungen gab. Obwohl dies kein großes Problem war, mussten wir sicherstellen, dass wir Refactor Mercilessly praktizierten (mit geeigneten Tests zur Unterstützung).

Obwohl ich eine Reihe von Problemen erwähne, glaube ich nicht, dass vertikale Benutzergeschichten die Ursache waren. In der Tat machte es die Probleme offensichtlicher. Nach dem Wechsel wurden die Probleme nicht mehr über Teams oder Anwendungsebenen hinweg verschleiert.