Ich mach mir die Welt widewide wie sie mir gefällt.
Unsere Entwickler sollen agil arbeiten, Teams sollen sich selber organisieren, das ganze Management soll noch folgen. Produkte werden schneller, fehlerfreier, vernetzter, individueller und mit weniger Kosten auf den Markt gebracht. Um diesen Herausforderungen gewachsen zu bleiben, müssen wir auch unsere Werkzeuge – mit denen wir die tägliche Wertschöpfung erbringen wollen – im Blick behalten. Dabei geht es im ersten Schritt weniger um konkrete Werkzeuge, Suiten oder Toolketten, wie Sie sie bestimmt aus Ihrem Unternehmen kennen. Es geht vielmehr um die Prüfung, in wie weit die jetzige Arbeitsumgebung den aktuellen und künftigen Anforderungen an moderne Produktentwicklung gewachsen ist.
Annahmen und Schlüsse
Wir gehen davon aus, dass es für mittlere und verteilte Teams notwendig ist, eine IT Infrastruktur zur Kommunikation, Planung, Entwicklung, Auslieferung und den Produkt-Service zu haben. Wir unterstellen weiter, dass es keine passende Kombination von COTS-Produkten gibt, die unsere Arbeitsweise optimal unterstützt. Dann gehen wir noch davon aus, dass wir keine Investitionen in umfassende Eigenentwicklungen für unsere Infrastruktur tätigen werden. Diese drei Annahmen führen dann unter anderen zu dem Schluss, dass wir eine Arbeitsumgebung benötige die:
- effizient skalierbar ist,
- eine hohe Integrationsfähigkeit mit anderen Lösungen besitzt und
- die flexibel auf notwendige Bedürfnisse der Entwicklungsorganisation angepasst werden kann.
Zwei mal drei macht vier
Würde man die einschlägigen IT Messen besuchen und unsere drei groben Anforderungen bei den ausstellenden Softwarehäusern abfragen, bekämen wir sicher eine Menge „passender“ Angebote. So ein Vorgehen wäre aber ohnehin nicht angemessen. Denn sich bei der Tauglichkeitsprüfung der eigenen Arbeitsumgebung, nur auf die Aussagen der Werkzeughersteller zu verlassen, würde zu kurz greifen. Die Werkzeughersteller sind Experten für ihre Werkzeuge, aber eben nicht für unsere Bedürfnisse. Wir müssen uns also selber einen Maßstab schaffen, nach dem wir die Tools bewerten können. Das heißt wir brauchen nicht nur eine grobe Vorstellung, sondern messbare Kriterien.
Vielleicht kommt Ihnen das bekannt vor und Sie denken, jetzt kommt gleich das Lied von der mehrjährigen Selbstfindung mit umfangreicher Dokumentation, welche Features denn meine Entwicklungsteams irgendwann brauchen könnten? Dann noch verschiedene Studien, die eine ausgetüftelte Toolevaluierung einläutet. Ja, solche Berater habe ich auch schon getroffen … widewidewitt und drei macht neune.
Konstruktionsfehler und Konstruktionsprinzipien
Machen wir uns nicht vor, was die Zukunft wirklich bringt können wir je weiter sie vor uns liegt nur immer mehr erahnen. Denken sie auch gerne an ein schönes Zitat von Friedrich Dürrenmatt „Je planmäßiger die Menschen vorgehen, desto wirksamer vermag sie der Zufall zu treffen.“ (21 Punkte zu den Physikern, Punkt 8; Werkausgabe Bd.7 (1998, S. 91 – Diogenes Verlag) – Das Stück empfehle ich Ihnen wärmstens)
Wenn wir noch nicht genau wissen, welche Inneneinrichtung wir für unser Haus benötigen werden, sollten wir uns keine Gedanken darüber machen, welche Farbe der Teppich haben soll. Ob wir mit dem Bau beginnen können oder nicht, hängt an ganz anderen Fragestellungen. Welches Fundament brauchen wir für wie viele Etagen, wie viele Zimmer, welche Zimmerhöhen usw. Wenn der Rohbau für unser Haus fertig ist, haben wir nur wenige Einschränkungen für die Inneneinrichtung – Wände könnten noch eingebaut werden und die Zimmeraufteilung kann variieren. Wird uns das Haus bezugsfertig übergeben sind es schon mehr Einschränkungen – Küche und Bäder sind fertig gestaltet. Ziehen wir in ein möbliertes Haus, wäre unser Gestaltungsrahmen für die Inneneinrichtung sehr eingeschränkt – vielleicht lassen sich noch einige Möbel verschieben. So banal dieses Beispiel auch scheint, so zutreffend sind die Wirkprinzipien in der Softwareentwicklung – und damit auch für deren Arbeitsumgebungen.
Konstruktionsfehler sind – kurz gesagt – ein Ausdruck unangemessener Anwendung von wirksamen Konstruktionsprinzipien. Das heißt, wir müssen herausfinden, welche Konstruktionsprinzipien für unsere Arbeitsumgebung wichtig sind. Dann können wir prüfen, wie gut unsere jetzige und wie viel besser neue Bestandteile unserer Arbeitsumgebung diesen Prinzipien entsprechen.
… die macht, was ihr gefällt
Ein solches Prinzip ist die Modellbildung, also die Fähigkeit, die Struktur und das Verhalten der gesamten/oder Teile der Arbeitsumgebung wie folgt zu beschreiben, durch:
- Abgrenzung: Nichtberücksichtigung irrelevanter Objekte
- Reduktion: Weglassen von Objektdetails
- Dekomposition: Zerlegung, Auflösung in einzelne Segmente
- Aggregation: Vereinigung von Segmenten zu einem Ganzen
- Abstraktion: Begriffs- bzw. Klassenbildung
[Quelle: vgl. http://de.wikipedia.org/wiki/Modell]
Ein weiteres Prinzip ist die Objektorientierung, die mit dem Konzept der Klasse unter anderen die Instanziierbarkeit zu realen Objekte ermöglicht, in unserem Kontext also Objekte der Arbeitsumgebung. Klassen besitzen die modellierten Eigenschaften und das modellierte Verhalten der daraus instanziierten Objekte. Weitere Prinzipien der Objektorientierung sind:
- Vererbung: Klassen können von anderen Klassen abgeleitet werden
- Aggregation: die Unterscheidung zwischen dem Ganzen und seinen Teilen
- Kapselung: Verbergen von Daten oder Informationen vor dem Zugriff von außen. Der direkte Zugriff erfolgt über definierte Schnittstellen.
[Quelle: vgl. http://de.wikipedia.org/wiki/Objektorientierung]
Wie geht es nun weiter?
Nach dieser Einführung werde ich an dieser Stelle in den nächsten Beiträgen beschreiben, wie sich diese Architekturprinzipien auf die Arbeitsumgebung in der Softwareentwicklung auswirken. Darüber hinaus möchte ich Ihnen zu diesem Thema passende Vorträge empfehlen, die ich mit Martin Künzle, von der evosoft, im November halten werde:
MID Insight 2013, 12. November, 11:30 Uhr Track Lissabon, „Innovator und TFS-Modellierung im ALM”
Tags
Jens Donig
Kontaktieren Sie Jens DonigJens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.
