Funktionsübergreifende vs. selbstorganisierende vs. Funktions- vs. Komponententeams in Agile

Traditionell ist ein Projekt um  Komponententeams herum organisiert  (dh UX, Dev, Business, Tester und …), jede Version, die eine Reihe von Komponentenkenntnissen erfordert, muss mehrere Komponententeams einbeziehen. Typischerweise haben verschiedene Teams unterschiedliche Prioritäten, was unweigerlich zu Engpässen im Produktveröffentlichungszyklus führt.

Laut Wikipedia ist ein funktionsübergreifendes Team eine Gruppe von Personen mit unterschiedlichen funktionalen Fachkenntnissen, die auf ein gemeinsames Ziel hinarbeiten. Eine der besten Möglichkeiten, die Qualität Ihres Teams zu verbessern, besteht darin, es funktionsübergreifend zu gestalten. Ein funktionsübergreifendes Team verfügt über alle notwendigen Fähigkeiten, um aus einer Idee ein funktionierendes Produkt zu machen.

„ Ein  funktionsübergreifendes Team  verfügt über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne von anderen abhängig zu sein, die nicht Teil des Teams sind “ – Scrum Guide

Im Gegensatz zum Komponententeam-Ansatz sind  funktionsübergreifende Teams  Gruppen, die aus Personen aus verschiedenen Funktionsbereichen des Unternehmens bestehen. — Es sollte nicht nur aus technischen Spezialisten (Back-End-, Front-End-Entwickler, QA-Ingenieure usw.) bestehen, sondern auch aus Mitgliedern wie Business-Analysten, Marketing- und UX-Spezialisten oder anderen Personen bestehen, die aktiv am Projekt beteiligt sind.

Ein  selbstorganisierendes Team  ist ein Team, das die Autonomie hat, zu entscheiden, wie es seine Arbeit am besten erledigt, anstatt von anderen außerhalb des Teams geleitet zu werden. Im Gegensatz zu traditionellen Managementprinzipien werden die selbstorganisierten, ermächtigten Teams nicht von oben geleitet und kontrolliert; Vielmehr entwickeln sie sich aus Teammitgliedern, die aktiv und gemeinsam an allen Scrum-Praktiken und -Events teilnehmen.

Traditionelles Team vs. agiles Team

„Ein  Selbstorganisationsteam  besteht aus einer Gruppe von Wissensarbeitern, die sich selbst verwalten müssen. Sie müssen Autonomie haben“ –  Peter Drucker.

Der Scrum Guide sagt: „Das Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master. Sie sind:

„ Scrum-Teams  sind  selbstorganisierend  und  funktionsübergreifend “ –  Scrum Guide:

Komponententeam vs. Featureteam

Der traditionelle Ansatz besteht darin, das Produkt mehr oder weniger logisch und sinnvoll in Komponenten zu zerlegen und diesen Komponententeams zuzuweisen. Aus Kundensicht sind diese Komponenten jedoch völlig irrelevant.

Ein Feature-Team-Ansatz ist jetzt eine fast allgemein akzeptierte Methode zur Organisation ihrer Teams, im Gegensatz zum Technologie-Stack-Team, insbesondere im Continuous-Delivery-Ansatz, betont er Funktionen (dh einen vertikalen Teil des Systems), die die Benutzeranforderungen erfüllen, was normalerweise beschleunigt werden kann Wertbereitstellung von Funktionen oder funktionierender Software und verkürzen die Feedback-Schleife von den echten Benutzern. Ein Feature-Team hätte alle Fähigkeiten, um die notwendige Arbeit auf Aufgabenebene auszuführen, um die Arbeit zu erledigen. Unter der Annahme einer dreischichtigen Architektur würden die Teammitglieder insbesondere an Aufgaben im Zusammenhang mit der GUI, der mittleren Schicht und den Datenbankteilen dieser Geschichte arbeiten.

Der große Nachteil der Komponentenorganisation liegt auf der Hand: Sie verlangsamt den Wertefluss. Ein Großteil der Systemfunktionen schafft Abhängigkeiten, die eine Zusammenarbeit zwischen Komponententeams erfordern, um sie zu erstellen, bereitzustellen und schließlich freizugeben. Teams verbringen einen Großteil ihrer Zeit damit, Abhängigkeiten zwischen Teams zu diskutieren und Verhaltensweisen über Komponenten hinweg zu testen, anstatt in der Lage zu sein, Endbenutzernutzen zu liefern.