Agilität – Die häufigsten Missverständnisse

Falsch: In komplexen Großprojekten lässt sich nicht alle vier Wochen ein Release freigeben

Diese Aussage kann so ohne weiteres nicht nachvollzogen werden. Viele Kollegen haben schon komplexe Software mit agilen Vorgehensweisen entwickelt und konnten noch kürzere Releasezyklen erreichen. Die Vorgehensweise kann also nicht das Problem sein. Eine näher liegende Vermutung ist stattdessen, dass viele Organisationen „noch nicht so weit sind“. Gute Voraussetzungen für kurze Releasezyklen sind:

Funktionierende Continuous-Integration-(CI-)Umgebung

Wenn die Anwendung jeden Tag kompiliert, zusammengesetzt, getestet und qualitätsgesichert wird, dann hat man jederzeit einen schnellen Überblick. Man weiß jeden Tag, ob die Software lauffähig ist. CI ist im Sinne unseres Regelkreises die laufende automatische Überwachung des Outputs der Regelstrecke.

Ausgiebige Testautomatisierung (Unit Tests und GUI Tests)

Oft wird die gesamte Anwendung immer wieder von Hand durchgetestet. Dies erschwert die Durchführung von kurzen Releasezyklen. Stattdessen ist es ratsam, eine ausgewogene Abdeckung an automatisierten Tests zu erstellen, wodurch der Regressionstest automatisch abläuft.

Continuous Feedback in funktionsübergreifenden Teams

Wenn der Kunde im Team ist, dann hat er laufend Rückkopplung über den Stand der aktuellen Entwicklung. Die kontinuierliche Rückmeldung über die Qualität der erledigten Arbeitsergebnisse könnte man analog zu Continuous Integration auch als Continuous Feedback bezeichnen. Der Kunde ist so am Ende eines Entwicklungszyklus nicht plötzlich mit der Anwendung konfrontiert, sondern hat zusammen mit den Entwicklern kontinuierlich an der Erstellung und Bewertung gearbeitet.

Richtig: Die Länge der Releasezyklen hängt maßgeblich von einer zeitnahen und kontinuierlichen Rückmeldung über den Zustand der Regelgröße ,laufende Software‘ ab.

Zusammenfassung

Das waren die ersten vier Missverständnisse. Auf Basis des eingeführten Regelkreises haben wir die oben aufgelisteten Aussagen diskutiert. Der Regelkreis bietet sich als gute Diskussionsgrundlage an, weil das dargestellte Prinzip von Steuerung und Kontrolle besonders im Management gut nachvollziehbar ist. Und dort wird entschieden, ob Agile Verfahren im Unternehmensalltag weiter Einzug halten. Zusammengefasst ist das Ergebnis der ersten Diskussion in diesem Artikel:

  1. In agilen Teams wird dokumentiert, Dokumente sind aber generell weniger wichtig als laufende Software.
  2. Fortschrittskontrolle wird durch Agile Software-Entwicklung verbessert.
  3. Kurze Releasezyklen erfordern bestimmte Voraussetzungen, dazu gehören insbesondere Testautomatisierung sowie Continuous Integration und Feedback.

Soweit, so gut! In den nächsten Beiträgen werden wir weitere Missverständnisse diskutieren. Dabei widmen wir den einzelnen Falschaussagen einen jeweils eigenen Artikel, da die Themen inhaltlich etwas umfangreicher sind. Fortsetzung folgt!

Niklas Schlimm ist seit über 15 Jahren als Software-Entwickler und Architekt in unterschiedlich großen Projekten tätig. Zurzeit arbeitet er als Gruppenleiter eines Architektur-Teams bei der Provinzial Rheinland Versicherung AG. Seine Schwerpunkte dort liegen im Bereich Agile Software-Entwicklung, Java-EE-Architekturen mit Hostanbindung und Application-Lifecycle-Management.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.