Agile Prozesse – Agile Teams

Ein Software-Prozessmodell ist ein Modell für den Ablauf der Entwicklung eines Software-Systems. Dabei geht es nicht um die Darstellung des Ablaufs eines bestimmten Software-Entwicklungsprojekts, sondern einer ganzen Klasse von Projekten. Man unterscheidet typischerweise zwischen schwergewichtigen und leichtgewichtigen Prozessmodellen, wobei die leichtgewichtigen agilen Modelle mittlerweile dominieren.

Das Agile Manifest ist eine Reaktion der Entwickler auf die sog. „schwergewichtigen“ Prozess- bzw. Vorgehensmodelle, wie den Unified Process oder das V-Modell. Seine vier Leitsätze bilden die Grundlage für das agile Vorgehen in Projekten und damit eine Art Randbedingung der leichtgewichtigen Software-Entwicklung. Alle agilen Prozessmodelle befolgen das Agile Mainfest.

Kent Beck entwickelte sein Prozessmodell Extreme Programming (XP) (Beck 2000) im Rahmen des Chrysler-Projekts Chrysler Comprehensive Compensation (C3), das die Entwicklung einer Lohn- und Gehaltslisten-Software zum Ziel hatte (Beck und Andres 2004). Das Projekt war zum Zeitpunkt des Eintretens von Beck bereits so gut wie gescheitert. Man gab also Beck die Möglichkeit, seine zuerst informellen agilen Projektpraktiken als neues Prozessmodell zu formulieren. Beck entwickelte dazu Werte, Prinzipien und XP-Praktiken, die hier detailliert vorgestellt und bewertet werden.

Die Crystal-Familie agiler Prozessmodelle wurde in den 1990er-Jahren von Alistair Cockburn entwickelt. Cockburn unterteilt die Prozessmodelle der Crystal-Familie nach Farbe und Härtegrad. Die Farbe entspricht der Teamgröße, je dunkler desto größer das Team. Der Härtegrad entspricht der Kritikalität, also der Schwere des Schadens, den eine fehlerhafte Software anrichten kann. Diese Einteilung ist sinnvoll, da einerseits mit größeren Projekten ein erhöhter Kommunikationsaufwand entsteht, andererseits erhöhte Kritikalität mehr Aufwand in der Qualitätssicherung bedeutet. Trotzdem steht im Mittelpunkt des Ansatzes nicht eine spezifische, definierte Vorgehensweise im Projekt. Stattdessen werden generelle Prinzipien postuliert und zu erreichende Projekteigenschaften festgelegt.

Scrum unterscheidet sich von den bisher diskutierten agilen Prozessmodellen, denn es ist eine agile Projektmanagementmethode, die im Scrum Guide zusammengefasst ist (Schwaber und Sutherland 2020). Fragen der Zusammenarbeit und der Teamstruktur stehen nicht im Vordergrund, sondern der Ablauf des Projekts. Die Projektrollen, der Sprint-basierte Prozess und die Scrum-Artefakte werden detailliert diskutiert.

Das japanische Wort „Kanban“ lässt sich mit „Karte“ oder „Signalkarte“ übersetzen. Im deutschen Sprachgebrauch hat sich auch der Begriff „Ticket“ eingebürgert. Über die Darstellung aller Tickets auf einem Kanban-Board und der Bestimmung der „Work in Progress“ kann ein Kanban-Projekt gesteuert werden. Die Kunst ist die Bestimmung der „Work in Progress“.

DevOps ist ein Kunstwort aus Development (Software-Entwicklung) und Operations (Software-Bereitstellung im Produktivsystem). Das erste Auftreten von DevOps in der IT-Branche ist 2009 dokumentiert. Bei DevOps arbeiten Spezialisten aus verschiedenen Disziplinen, wie Entwicklung und Operations zusammen, damit mögliche Probleme zwischen Spezifikation und Inbetriebnahme früh identifiziert und vermieden werden können. Insbesondere das „Silo-Denken“ der unterschiedlichen Disziplinen soll so aufgebrochen werden. Die CALMS-Grundprinzipien und der DevOps Life Cycle werden detailliert beschrieben.

Im studentischen Software-Engineering-Labor des Kompetenzzentrums für agile IT-Prozesse (KAP) der Dualen Hochschule Baden-Württemberg Lörrach führt der jeweilige studentische Jahrgang (Kurs genannt) gemeinsam als Team ein Software-Projekt durch. Dabei werden insbesondere Fragen zu agilen Projektpraktiken und deren Erfolg in der Praxis beantwortet. Somit können aus der Literatur bekannte agile Prozessmodelle und ihre Praktiken auf den Prüfstand gestellt werden.

Ist der Ansatz, immer wieder neue Prozessmodelle zu entwickeln, der richtige? Diese zentrale Frage resultiert aus den geschilderten Erfahrungen im studentischen Labor des Kompetenzzentrums für agile IT-Prozesse (KAP). Wird das Team durch das strikte Befolgen eines vorgegebenen Prozessmodells nicht zu sehr eingeschränkt? Ist es nicht generell besser, lediglich die Rahmenbedingungen für den Prozess zu definieren und das Team den geeigneten agilen Teamprozess selbst finden zu lassen? Die Antwort darauf gibt das vom Autor entwickelte und 2009 erstmals veröffentlichte Meta Agile Process Model (MAP): MAP ist ein systemisches Modell, das die Rahmenbedingungen für den Prozess festgelegt, aber dem Team genügend Raum gibt, den geeigneten agilen Teamprozess selbst zu finden. Dabei findet insbesondere eine organisationspsychologische Betrachtung des Teams statt. Aus der "Landkarte der Verhaltensweisen im Team" (den "MAP-Typen") werden die Voraussetzungen für Team-Erfolg hergeleitet und ihre Relevanz bewiesen. Das Kapitel wird abgerundet durch die Bedingungen für die Koexistenz von MAP mit Scrum und die Beschreibung erfolgreicher MAP-Projekte in der Praxis, insbesondere im regulierten Umfeld.