{"id":593,"date":"2022-01-26T01:46:08","date_gmt":"2022-01-26T01:46:08","guid":{"rendered":"https:\/\/www.cybermedian.com\/de\/?p=593"},"modified":"2022-03-22T14:33:13","modified_gmt":"2022-03-22T06:33:13","slug":"cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/de\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"Funktions\u00fcbergreifende vs. selbstorganisierende vs. Funktions- vs. Komponententeams in Agile"},"content":{"rendered":"
\n
\n
\n

Traditionell ist ein Projekt um\u00a0\u00a0<\/span>Komponententeams<\/span><\/strong>\u00a0herum organisiert \u00a0(dh UX, Dev, Business, Tester und \u2026), jede Version, die eine Reihe von Komponentenkenntnissen erfordert, muss mehrere Komponententeams einbeziehen.\u00a0Typischerweise haben verschiedene Teams unterschiedliche Priorit\u00e4ten, was unweigerlich zu Engp\u00e4ssen im Produktver\u00f6ffentlichungszyklus f\u00fchrt.<\/span><\/p>\n

Laut Wikipedia ist ein funktions\u00fcbergreifendes Team eine Gruppe von Personen mit unterschiedlichen funktionalen Fachkenntnissen, die auf ein gemeinsames Ziel hinarbeiten.\u00a0Eine der besten M\u00f6glichkeiten, die Qualit\u00e4t Ihres Teams zu verbessern, besteht darin, es funktions\u00fcbergreifend zu gestalten.\u00a0Ein funktions\u00fcbergreifendes Team verf\u00fcgt \u00fcber alle notwendigen F\u00e4higkeiten, um aus einer Idee ein funktionierendes Produkt zu machen.<\/span><\/p>\n

\u201e\u00a0<\/span>Ein\u00a0\u00a0<\/span><\/em>funktions\u00fcbergreifendes Team<\/span><\/em><\/strong>\u00a0\u00a0verf\u00fcgt \u00fcber alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne von anderen abh\u00e4ngig zu sein, die nicht Teil des Teams sind<\/span><\/em>\u00a0\u201c \u2013 Scrum Guide<\/span><\/p>\n

Im Gegensatz zum Komponententeam-Ansatz sind\u00a0\u00a0<\/span>funktions\u00fcbergreifende Teams<\/span><\/strong>\u00a0\u00a0Gruppen, die aus Personen aus verschiedenen Funktionsbereichen des Unternehmens bestehen.\u00a0\u2014 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.<\/span><\/p>\n

<\/figure>\n

Ein\u00a0\u00a0<\/span>selbstorganisierendes Team<\/span><\/strong>\u00a0\u00a0ist ein Team, das die Autonomie hat, zu entscheiden, wie es seine Arbeit am besten erledigt, anstatt von anderen au\u00dferhalb des Teams geleitet zu werden.\u00a0Im Gegensatz zu traditionellen Managementprinzipien werden die selbstorganisierten, erm\u00e4chtigten Teams nicht von oben geleitet und kontrolliert;\u00a0Vielmehr entwickeln sie sich aus Teammitgliedern, die aktiv und gemeinsam an allen Scrum-Praktiken und -Events teilnehmen.<\/span><\/p>\n

<\/figure>\n

Traditionelles Team vs. agiles Team<\/span><\/p>\n

\u201eEin\u00a0\u00a0<\/span><\/em>Selbstorganisationsteam<\/span><\/em><\/strong>\u00a0\u00a0besteht aus einer Gruppe von Wissensarbeitern, die sich selbst verwalten m\u00fcssen.\u00a0Sie m\u00fcssen Autonomie haben\u201c \u2013\u200a<\/span><\/em>\u00a0Peter Drucker.<\/span><\/p>\n

Der Scrum Guide sagt: \u201eDas Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master.\u00a0Sie sind:<\/span><\/p>\n

\u201e\u00a0<\/span>Scrum-Teams<\/span><\/strong>\u00a0\u00a0sind\u00a0\u00a0<\/span>selbstorganisierend<\/span><\/strong>\u00a0\u00a0und\u00a0\u00a0<\/span>funktions\u00fcbergreifend\u00a0<\/span><\/strong>\u201c \u2013\u200a<\/span><\/em>\u00a0Scrum Guide:<\/span><\/p>\n

Komponententeam vs. Featureteam<\/span><\/span><\/h3>\n

Der traditionelle Ansatz besteht darin, das Produkt mehr oder weniger logisch und sinnvoll in Komponenten zu zerlegen und diesen Komponententeams zuzuweisen.\u00a0Aus Kundensicht sind diese Komponenten jedoch v\u00f6llig irrelevant.<\/span><\/p>\n

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\u00fcllen, was normalerweise beschleunigt werden kann Wertbereitstellung von Funktionen oder funktionierender Software und verk\u00fcrzen die Feedback-Schleife von den echten Benutzern.\u00a0Ein Feature-Team h\u00e4tte alle F\u00e4higkeiten, um die notwendige Arbeit auf Aufgabenebene auszuf\u00fchren, um die Arbeit zu erledigen.\u00a0Unter der Annahme einer dreischichtigen Architektur w\u00fcrden die Teammitglieder insbesondere an Aufgaben im Zusammenhang mit der GUI, der mittleren Schicht und den Datenbankteilen dieser Geschichte arbeiten.<\/span><\/p>\n

<\/figure>\n

Der gro\u00dfe Nachteil der Komponentenorganisation liegt auf der Hand: Sie verlangsamt den Wertefluss.\u00a0Ein Gro\u00dfteil der Systemfunktionen schafft Abh\u00e4ngigkeiten, die eine Zusammenarbeit zwischen Komponententeams erfordern, um sie zu erstellen, bereitzustellen und schlie\u00dflich freizugeben.\u00a0Teams verbringen einen Gro\u00dfteil ihrer Zeit damit, Abh\u00e4ngigkeiten zwischen Teams zu diskutieren und Verhaltensweisen \u00fcber Komponenten hinweg zu testen, anstatt in der Lage zu sein, Endbenutzernutzen zu liefern.<\/span><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n