Agile Softwareentwicklung ist inzwischen in vielen Unternehmen selbstverständlich. Ein Großteil der Anwendungen, die wir täglich nutzen, ob privat oder beruflich, wäre ohne sie nicht so flexibel an Kundenwünsche anpassbar. Für das Vorgehen gilt Scrum schon fast als Synonym. Dieser Artikel ist der erste Teil einer Serie von Beiträgen, die sich damit beschäftigen, welche agilen Pfade es jenseits von Scrum gibt. Und mit welchen Elementen – Agile Patterns – wir positive Erfahrungen bei und mit unterschiedlichen Kunden sammeln konnten.
Scrum ist kein Kochrezept
Das Framework ist rasch erklärt und gibt einen klaren Rahmen für die Umsetzung agiler Prinzipien vor. Trotzdem rumpelt es bei der Anwendung oft in der Praxis, was daran liegt, dass es sich dabei nicht um ein Kochrezept handelt. Es reicht nicht, die formalen Bestandteile miteinander zu vermischen und einmal umzurühren. Die Interaktionen aller Beteiligten, Umfeld, Kultur, Führungsverständnis, haben ebenso einen wesentlichen Einfluss auf das Ergebnis.
Scrum ist nicht der einzige Weg ins unbeschwerte Produktentwicklungsparadies. Konzentrieren wir uns auf die ursprünglichen Ideen, auf erfolgreiche Muster in der Anwendung, so erschließen sich uns eine Reihe von weiteren Möglichkeiten, um agilen Prinzipien zu folgen und sie in Projekte einfließen zu lassen. Nicht in jedem Umfeld ist es möglich oder sinnvoll, von einem Tag auf den anderen alle bisher bestehenden Paradigmen umzustoßen.
Eine evolutionäre Anpassung des Projektvorgehens, ein sanfter Umstieg, kann gerade in größeren Firmen zweckmäßig sein. Mit dem Vorteil, aus überschauberen Umsetzungsschritten zu lernen und ihren eigentlichen Sinn zu verinnerlichen. Und die Organisation parallel zum methodischen Vorgehen weiterzuentwickeln.
Agile Patterns: auf die Ideen konzentrieren
Am Anfang war das Agile Manifest. Der Urknall agiler Bestrebungen. Vier Leitsätze und 12 Prinzipien. Einer der Unterzeichner war Alistair Cockburn, der bereits in den neunziger Jahren eine Reihe von Projekten analysierte, um Ursachen für deren Erfolg oder Misserfolg zu festzustellen. Allerdings führte zu seiner Überraschung nicht das Anwenden einer bestimmten Methode zu ihrem Gelingen. Dafür wiesen sie aber eine wesentliche Gemeinsamkeit auf: regelmäßige und enge Kommunikation.
Rückblickend betrachtet war das Ergebnis nicht so erstaunlich, wenn man bedenkt, dass auch Tom de Marco im gleichen Zeitraum wiederkehrend auf die sozialen Faktoren von Projektteams aufmerksam machte, auf Rahmenbedingungen und Teambuilding. In den Büchern Wien wartet auf dich oder Spielräume hob dieser die Bedeutung von Menschen in der Softwareentwicklung hervor: dass neben Hard- und Software auch die Peopleware zu betrachten sei.
Menschen sind entscheidend, weniger die Methoden
Cockburn kam jedenfalls zu dem Schluss, jedes Projekt, jedes Team sei einzigartig, eine allgemeine Vorgehensweise existiere nicht. Vielmehr sollte die Methodik an das konkrete Projekt und seine Umstände angepasst werden. Er schlug vor, die Vorhaben dabei nach zwei Kriterien zu kategorisieren:
- Anzahl beteiligter Personen
- Kritikalität (Höhe des Risikos)
Wenn jedes Projekt spezifisch zu betrachten ist, so wirkt sich die Anzahl der an einem Vorhaben beteiligten Personen auf die Umstände der Projektarbeit ganz wesentlich aus. Eine Gruppe von 10 Mitarbeitern, die ihre Aufgaben autonom erledigt, braucht andere Regeln für die Kommunikation, als ein aus mehreren Teams zusammengesetztes Projekt mit insgesamt 50 Personen.
Ebenso ist für die Durchführung eines Projekts das damit verbundene Risiko zu berücksichtigen. Die Entwicklung von Softwareanwendungen, welche die Sicherheit von Menschenleben gefährden können, ist anders zu handhaben als die testweise Konfiguration eines internen Tools. Es wünscht sich wohl keiner von uns eine oberflächlich getestete Beta-Release für ein Atomkraftwerk, um rasches Kundenfeedback zu erhalten. Cockburn unterscheidet bei der Einstufung von Kritikalität daher folgende Auswirkungen:
- Gefährdung der Kundenzufriedenheit (Comfort)
- Verlust von Geld (Discretionary Money)
- Imageschaden (Essential Money)
- Verlust von Menschenleben (Loss of Life)
Projekte ähnlicher Größe und Kritikalität entsprechen dabei einer Gruppe von Projekten mit ähnlichen Bedürfnissen. Jedes Projekt definiert sein Vorgehen anhand eines Vorrats von konkreten und praktisch erprobten Methodenelementen. Das Konzept nennt Cockburn Crystal-Family und gehört zu den sogenannten leichtgewichtigen Methoden.
Quelle: https://en.wikiversity.org/wiki/Crystal_Methods
Die Größe von Projekten kennzeichnet er mit einer Farbe, die Kritikalität vergleicht er mit einem Härtegrad. So bedeutet zum Beispiel Crystal Clear, dass es sich um ein Projekt mit bis zu sechs Personen handelt, die Bezeichnung C6 charakterisiert das Risiko (Kundenzufriedenheit = Comfort).
Wer mehr darüber wissen möchte, liest eines der Bücher von Alistair Cockburn oder wartet auf den nächsten Blogartikel aus dieser Reihe!
Literaturtipps:
The post Agile Patterns – Teil 1/4: Überblick Crystal Family appeared first on ANECON Blog.
Jobs of Anecon Software Design und Beratung GmbH
Software Test Berater (m/w)Architekt Testautomatisierung (m/w)
Software Test Manager (m/w)
Entwickler (m/w) für Automatisierungs-Frameworks Java/.NET bzw. SAP/ABAP