Eine Werkzeugkiste für den Umgang mit Änderungen
Die Beschleunigung in der Produktentwicklung ist eine echte Herausforderung für das Systems Engineering. Denn traditionell wird dort auf Stabilität wert gelegt, nicht auf Agilität. Doch steigende Komplexität und ein härterer Wettbewerb machen es überlebensnotwendig, gut mit Änderungen umgehen zu können. Dies wurde schon 2001 erkannt, als das agile Manifest für die Softwareentwicklung aufgestellt wurde, und die zugrundeliegenden Prinzipien breiten sich zur Zeit über alle Aspekte von Organisationen aus, einschließlich Systems Engineering und Produktentwicklung.
Dabei ist der souveräne Umgang mit Änderungen eine Grundvoraussetzung. Das ist ein Thema, mit dem ich mich schon seit einiger Zeit auseinandersetze. Aktuell bereite ich einen vierstündigen Workshop für die ReConf 2019 vor: Änderungen beherrschbar machen. Da es keine Universallösung für alle Situationen gibt, ist hier der Ansatz, verschiedene Taktiken systematisch aufzubereiten, um diese dann in die Entwicklungsprozesse einfließen zu lassen. Für diese Taktiken, oder Best Practices habe ich mich von Design Patterns inspirieren lassn, und stelle das Konzept in Kurzform in einem Vortrag auf der ReConf 2019 vor: Entwicklungsmuster für den Umgang mit Änderungen.
Im Folgenden meine ersten, Gedanken zu diesem Thema.
Werkzeugkästen haben sich bewährt
Die Idee von Mustern ist alt. Geprägt wurden Design Pattern vom Architekt Christopher Alexander. Das Konzept wurde von der Softwaregemeinschaft begeistert aufgenommen, und das Buch der „Gang of Four“ ist heute Pflichtlektüre für alle Softwareentwickler.
Den Werkzeugkasten-Ansatz verfolgt auch Tim Weilkiens mit SYSMOD, ein Werkzeugkasten für die Systemmodellierung.
Eine Schablone für die Muster
Muster werden typischerweise in natürlicher Sprache in einer Schablone festgehalten. Der Einsatz einer Schablone hilft, schnell die richtigen Informationen zu finden. Querverweise stellen die Muster in Beziehung zueinander.
Auch wenn ein einheitliches Muster verwendet wird, so können sich die Muster inhaltlich drastisch voneinander unterscheiden. Die Muster von Christopher Alexander (Architektur) reichen von der Ebene einer ganzen Stadt bis zum einzelnen Fenster.
Diese Flexibilität ist wichtig für den Umgang mit Änderungen, denn auch hier müssen viele unterschiedliche Elemente zusammenspielen: Prozesse, Methoden, Werkzeuge, Verhalten von Menschen, und vieles mehr. Weiter unten ein Beispiel dazu. Hier ist mein aktueller Entwurf für die Schablone:
Intent
A short statement that answers: What does the pattern do? What is the rationale and intend? What particular issue or problem does it address?
Also Known as
Delete if not applicable
Motivation
A scenario that illustrates a problem that is solved by this pattern, include examples
Applicability
What are the situations in which the pattern can be applied? What are examples of poor product development that the pattern can address?
Structure
For structural patterns, a description or visual representation of the data structures (e.g. relationship diagram). For behavior patterns, a description of the processes or activities.
Consequences
Benefits and liabilities
Implementation
What pitfalls, hints or techniques should you be aware of when rolling out this pattern? These can be technical, organizational, cultural or human issues.
Related Standards
Indicate if the pattern supports requirements from standards like ISO/IEC/IEEE 29148 and the like.
Related Patterns
Hyperlinks to other patterns.
Ein Beispiel
Wenn wir auf der „grünen Wiese“ anfangen wollten, würden wir zunächst das→Change Management Process-Muster studieren. Dort wird dann auf verschiedene Strategien eingegangen, die primär aus Referenzen zu Standards bestehen. Dort finden wir auch einen Fragenkatalog der uns hilft, weiterführende Muster zu finden. Soll zum Beispiel →Dokumenten-basiert, → Datenmodell-basiert oder →Systemmodell-basiert gearbeitet werden?
Damit Änderungen in geordneten Bahnen laufen, muss es ein praxisbewährtes →Rollen-Rechte-Konzept. In der Praxis muss spätestens jetzt entschieden werden, mit welchem Werkzeug gearbeitet werden soll (→Werkzeugwahl), und wie dieses entsprechend konfiguriert wird. Bei der Umsetzung gibt es verschiedene Konzepte, die auf unterschiedlichen Ebenen greifen, wie →Quality Gates, die eine große Anzahl von Elementen betreffen, bis hin zu einzelnen Elementen, wo →Suspect Traces richtig eingesetzt werden müssen. Damit das ganze funktioniert, müssen die Nutzer richtig eingebunden werden. Das beginnt mit dem Schreiben von →Good Requirements und beinhaltet aber auch das Vermitteln der →Core Principles für diese Organisation, sowie →Effective Training und →Effective Collaboration.
Scope
Es ist offensichtlich, dass mit dem Erfassen von diesen Mustern ein erheblicher Aufwand verbunden ist. Weiterhin haben im Systems Engineering viele Aktivitäten mit Änderungen zu tun: Wo hören wir auf? Zuletzt stellt sich die Frage nach der Vollständigkeit.
Um beim letzten Punkt anzufangen: Wir können hier keine Vollständigkeit erwarten, genauso wie die Mustersammlung von Christopher Alexander nicht vollständig ist. Ziel ist es hier, nach dem Paretoprinzip die wichtigsten Muster abzudecken. Ebenso werden Aspekte, die nicht mit Änderungsmanagement zu tun haben lediglich erwähnt, aber nicht vertieft.
Und zuletzt: Muster kann man nicht erfinden, nur entdecken. Die Inhalte stammen daher natürlich aus der Praxis.
Feedback?
Was halten Sie von diesem Ansatz? Gibt es bereits Arbeiten dieser Art, die ich übersehen habe? Über eine Rückmeldung in den Kommentaren unten freue ich mich.
