Entwicklungsteam

Was macht ein Entwicklungsteam und wo liegen die Unterschiede von Entwicklungsteams in V-Modell XT und Scrum?

Die gemeinschaftliche Implementierung von Produkten

Ein Entwicklungsteam ist eine Gruppe von Menschen, die gemeinschaftlich ein Produkt implementiert. Meist bestehen Entwicklungsteams aus Mitarbeiterinnen und Mitarbeitern eines Unternehmens. Handelt es sich um Kooperationen oder Joint Ventures können sie auch aus unterschiedlichen Organisationen stammen. Wie ein Entwicklungsteam strukturiert ist und wie es miteinander arbeitet, hängt stark vom gewählten Vorgehen und dem damit verbundenen Mindset ab.

Das Entwicklungsteam im V-Modell XT

Das V-Modell XT definiert zahlreiche Rollen innerhalb einer Entwicklung wie bspw.

  • Hardware-Architekt, Hardware-Entwickler, Software-Architekt und Software-Entwickler,
  • Konfigurationsmanagement-Administrator und Konfigurationsmanagement-Verantwortlicher,
  • Logistikentwickler, System-Architekt, System-Integrator und Prüfer.

Für jede Rolle gibt es eine formale Rollenbeschreibung, die maximal fünf Punkte umfasst: Aufgaben und Befugnisse, Fähigkeitsprofil, Rollenbesetzung, Verantwortlichkeit und Mitwirkung. Damit auch kleinere Projekte und Entwicklungen mit dem V-Modell XT durchgeführt werden können, dürfen Mitarbeiter auf mehr als eine Rolle übernehmen, sofern es keinen Interessenkonflikt gibt.

Das Entwicklungsteam in Scrum

Scrum hingegen verzichtet gänzlich auf die Unterscheidung von Rollen im Entwicklungsteam. Der Scrum Guide definiert keinerlei Hierarchie, alle Teammitglieder eines Scrum Entwicklungsteams sind somit ausnahmslos Entwickler. Damit werden im Wesentlichen zwei Ziele verfolgt: Entscheidungen sollen auf Basis fachlicher Kriterien getroffen werden. Und die Verantwortung liegt im Team und nicht bei einzelnen Teammitgliedern. Die Aufgaben, die ein Scrum Entwicklungsteam übernimmt, sind klar umrissen:

  • Es beurteilt die Machbarkeit und den Aufwand von Backlog Items beim Sprint Planning, entscheidet über den Umfang des Sprint Backlogs und committed sich auf ein gemeinsames Sprint-Ziel.
  • Es liefert zum Ende eines jeden Sprints – unter Beachtung der Definition of Done – ein potentiell lieferfähiges Inkrement.
  • Über den Fortschritt beim Sprinten tauscht es sich untereinander, mit dem Scrum Master und ggf. dem Product Owner im Daily Scrum aus. Als Orientierung dient das Sprint-Ziel. Hindernisse – die sogenannten Impediments – auf dem Weg zum Sprint-Ziel werden kommuniziert und idealerweise (auch durch die Hilfe des Scrum Masters) beseitigt.
  • Im Sprint Review präsentiert es die realisierten Backlog Items bzw. das Inkrement.
  • In der Retrospektive versucht es sein Vorgehen für den nächsten Sprint zu optimieren.

Auch wenn Scrum für das Entwicklungsteam keine expliziten Rollen definiert, so besitzen die Teammitglieder im Idealfall dennoch unterschiedliche Fähigkeiten und Kenntnisse. Die Leistung des Teams hängt maßgeblich von der Kombination dieser Fähigkeiten ab. Verfügt eine Mitarbeiterin oder ein Mitarbeiter nicht über benötigte Kenntnisse, so ist das Team als Ganzes gefordert, sie oder ihn bei der Tätigkeit zu unterstützen und die Fähigkeiten zu erweitern. Das Sprint-Ziel lässt sich nur gemeinsam erreichen.

Entwicklungsteam - verschiedene Ansätze je nach Vorgehensweise

Hinweise:

Eine Liste der unterschiedlichen Rollen in V-Modell XT finden Sie hier  »

In der Scrum Guide Fassung vom November 2017 wird klargestellt, dass sich Scrum nicht nur für die Softwareentwicklung, sondern generell auch für die Produktentwicklung eignet. Damit adressiert Scrum dieselben Gegenstände – Software, Hardware, Systeme – wie das V-Modell XT. Der wesentliche Unterschied liegt in der Selbstorganisation und der Eigenverantwortung des Scrum Entwicklungsteams und dem damit einhergehenden agilen Mindset.

Was macht t2informatik?

t2informatik - Wir entwickeln Software für großartige Unternehmen

Hier finden Sie ergänzende Informationen aus unserem Blog:

t2informatik Blog: Das SWAT-Team in Scrum

Das SWAT-Team in Scrum

t2informatik Blog: Sinnvolle Grenzen für selbstverantwortliche Teams

Sinnvolle Grenzen für selbstverantwortliche Teams