Das Glas ist halbvoll!

Im Interview mit heise Developer zeichnet UML-Erfinder Grady Booch ein düsteres Bild der Softwareentwicklung. Dem möchte ich widersprechen.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Bernd Oestereich

Im Interview mit heise Developer ("UML-Erfinder Grady Booch zeichnet düsteres Bild der Softwareentwicklung") rät Grady Booch den Hochschulen: "Softwareentwickler müssen vor allem lernen, im Team zu arbeiten und zu kommunizieren, sie müssen ihre Ergebnisse besser präsentieren können und sie müssen deutlich mehr betriebswirtschaftliches Basiswissen mitbringen". Die Aussage teile ich teilweise, die düstere und pessimistische Stimmung jedoch gar nicht. Ganz im Gegenteil.

Die letzten Jahrzehnte des letzten Jahrhunderts waren geprägt durch ein eher tayloristisches Bild der Softwareentwicklung, das zwischenmenschliche Kommunikation eher formal und technokratisch betrachtete. Metaphern aus dieser Zeit, wie "das Anforderungsdokument über den (Abteilungs-)Zaun werfen", charakterisieren diese Sichtweise treffend.

Schon in den 1990er-Jahren, also zu der Zeit, als Booch die UML erfand, setzte eine Gegenbewegung zu diesem Weltbild ein, und es formierte sich eine eher systemische Sichtweise, die kommunikative Aspekte ins Zentrum rückte. Ich meine die agile Bewegung, die 1999 mit der Buchveröffentlichung von "Extreme Programming" (Kent Beck) und 2001 mit der Veröffentlichung des agilen Manifestes größere Aufmerksamkeit auf sich ziehen konnte.

Natürlich gibt es 10 Jahre später immer noch ein paar Ewiggestrige, aber insgesamt ist die Bewegung längst im Mainstream angekommen. Auch an Hochschulen werden agile Prinzipien immer mehr praktiziert, das heißt gelehrt und vor allem auch geübt. Berufsakademien und Fachhochschulen fallen mir beim Aspekt des praktischen Übens mehr auf, und insgesamt ist die Lehre sicherlich noch zu praxisfern. Das hat meiner Meinung nach vor allem auch mit der Anpassung der Lehre an internationale Standards (Bologna-Prozess), Verkürzung der Studienzeiten und der Eliteförderung (statt Breitenförderung) zu tun.

Auch in der Praxis gab es Anfang der 2000er-Jahre noch Unverständnis gegenüber dem Thema zwischenmenschliche Kommunikation oder sagen wir mal ganz allgemein "Soft Skills". Ich erinnere mich daran, dass entsprechende Vorschläge und Einreichungen von großen kommerziellen Branchentreffs wie der OOP regelmäßig abgelehnt wurden. In den letzten fünf Jahren ist hier aber richtig Fahrt reingekommen. Auch hier in Deutschland.

Uwe Vigenschow und Björn Schneider veröffentlichten den ersten Band „Soft Skills für Softwareentwickler “, später den zweiten für Führungskräfte und am dritten arbeiten sie bereits. Und auf der letzten OOP stellten Michael Schmücker und Markus Wittwer mit „Scaling Agile @ Allianz“ einen Erfahrungsbericht vor, der mit dem Kotter-Modell und Spiral Dynamics als Inhalt von Soft Skills zum Werte- und Kulturwandel in IT-Organisationen und Veränderungsprozessen überleitete.

Scrum als derzeit populärste agile Vorgehensweise stellt Kommunikation gar in den Mittelpunkt. Kommunikation über Anforderungen, Retrospektiven, Inkrementbegutachtungen, tägliche Teamtreffen und osmotische Kommunikation sind hier nur die prägnantesten Stichwörter. Der Scrum Master ist mehr ein systemisch arbeitender Coach, der die Kommunikation der Beteiligten unterstützt, und der Product Owner ist der Kummulationspunkt für die fachlich-inhaltliche Kommunikation schlechthin.

Das ist dabei nicht nur (Scrum-)Theorie, sondern gelebte Praxis. Die vielen Scrum-User-Gruppen und Diskussionsforen offenbaren, dass Fragen der Kommunikation und Zusammenarbeit in den Firmen und Projekten hohe Relevanz haben.

Über die Hälfte der Teilnehmer unserer CSM-Trainings (Certified Scrum Master) buchen die Kombipackung mit Soft-Skills für Scrum-Führungsrollen (Scrum-Master und Product-Owner), was das große Interesse daran ausdrückt.

Wir haben Anfragen von Unternehmen, die gezielt Kommunikations- und Präsentationsfähigkeiten ihrer Softwarearchitekten stärker ausprägen möchten. Weil sie erkannt haben, dass gute Architektur nicht in einem Beschreibungsmodell oder im Kopf eines Architekten entsteht, sondern dadurch, dass Entwickler das Modell mit seinen inhärenten Entscheidungen verstehen. Das gelingt vor allem durch einen kontinuierlichen Kommunikationsprozess zwischen Architekten und Entwicklern, den zu führen Aufgabe des Architekten ist.

Sicherlich stehen wir hier eher am Anfang, und manchmal übersteigt die Absicht, das Thema Soft Skills zu berücksichtigen, die Fähigkeiten der Akteure. Da gab es schon den einen oder anderen Konferenzvortrag zum Thema, den Teilnehmer mit dem Urteil "er hätte bei seinen Java-Themen bleiben sollen, davon versteht er wenigstens etwas" verließen. Und auch der eine oder andere Trainer, Coach oder Scrum-Master mag seine Fähigkeiten überschätzen und besitzt gar keine fundierte Qualifikation für Themen wie Kommunikation, Moderation, Konfliktbehandlung oder Veränderungsprozesse.

Aber so pessimistisch wie Booch sehe ich unsere Branche nicht. Ich freue mich viel mehr über die laufenden Entwicklungen, Fortschritte und Erfolge. ()