Software entwickeln mit Verstand
Jörg Dirbach verantwortet als Chief Knowledge Officer das Informations- und Wissensmanagement bei Zühlke. Er verfügt über 20 Jahre Erfahrung im Software Engineering als Entwickler, Berater und Manager. Die Frage der Produktivitätssteigerung von Wissensarbeitern beschäftigt ihn seit vielen Jahren und gab Anlass zur Auseinandersetzung mit Themen wie Kognitive Psychologie und Lernpsychologie. Seine Gedanken und Beobachtungen kommentiert Jörg Dirbach regelmäßig in seinem Blog (http://www.wissensarbeiter.org).
Markus Flückiger ist Usability Engineering Berater bei der Zühlke Engineering AG und Lehrbeauftragter der Berner Fachhoschule. Er gestaltet in Projekten das benutzerorientierte Vorgehen und bildet damit die Brücke zwischen Benutzern und Entwicklung, von der ersten Idee bis zum fertigen Produkt. In dieser Position trifft er immer wieder auf die große Herausforderung im unter Zeitdruck stehenden Software-Projektteam: effektiver Wissensfluss und interdisziplinäres Problemlösen.
Steffen Lentz arbeitet als Projektleiter bei der Credit Suisse in Zürich. Zuvor war er über 10 Jahre als Berater in verschiedenen Disziplinen des Software-Engineerings für Projekte großer Unternehmen im Einsatz. Schwerpunkte seiner Erfahrung sind neben Requirements- und Qualitätsmanagement vor allem Entwicklungsprozesse und Projektmanagement. Ihn beschäftigt die Frage, was ein Projekt erfolgreich macht und wie man es produktiv gestaltet.
Was Sie über Wissensarbeit wissen müssen,
um Projekte produktiver zu machen
Jörg Dirbach
jdi@zuehlke.com
Markus Flückiger
mdf@zuehlke.com
Steffen Lentz
Steffen.Lentz@credit-suisse.com
Lektorat: René Schönfeldt
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Nadine Thiele
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: Media-Print Informationstechnologie, Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch 978-3-89864-654-3
PDF 978-3-86491-040-1
ePub 978-3-86491-041-8
1. Auflage 2011
Copyright © 2011 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
1 Einleitung
1.1 Warum wir dieses Buch geschrieben haben
1.2 Für wen dieses Buch ist
1.3 Was erwartet den Leser?
1.4 Dank
2 Wie wir heute Software entwickeln
2.1 Erwartungen an Softwareentwicklung
2.2 Zwei gegensätzliche Ansätze
2.3 Wo stehen wir damit?
2.4 Zusammenfassung
3 Das Wesen von Softwareentwicklung
3.1 Was ist Softwareentwicklung eigentlich?
3.2 Team
3.3 Projektführung
3.4 Wissensarbeit als Herausforderung
3.5 Zusammenfassung
4 Softwareentwicklung aus Sicht des Gehirns
4.1 Routine- und Wissensarbeit
4.2 Das Problem ist die Barriere
4.3 Der Hebel ist die gedankliche Repräsentation
4.4 Problemlösen ist ein Kreisprozess
4.5 Das zweifache Handlungsfeld
4.6 Unser Gehirn unter der Lupe
4.7 Problemlösen in komplexen dynamischen Systemen
4.8 Zusammenfassung
5 Problemlösen im Team – Softwareentwicklung aus Sicht kommunizierender Gehirne
5.1 Teamarbeit: Parallelisierung und Synergie
5.2 Das Umfeld prägt das Team
5.3 Kommunikation ist die Voraussetzung
5.4 Gemeinsam Probleme lösen
5.5 Lernende Teams
5.6 Teams und komplexe Problemlösung
5.7 Zusammenfassung
6 Externe Mittel – Hilfe fürs Gehirn
6.1 Externe Mittel – wozu?
6.2 Der Einsatz von Dokumenten
6.3 Die Wirkung externer Mittel
6.4 Externe Mittel im Kreisprozess der Problemlösung
6.5 Im Team: Synergie und Arbeitsteilung
6.6 Interaktion mit dem Kontext
6.7 Feedbacktiefe
6.8 Zusammenfassung
7 Produktivität in der Wissensarbeit
7.1 Produktivität – was ist das eigentlich?
7.2 Individuelle Produktivität
7.3 Produktivität im Team
7.4 Strategische Produktivität
7.5 Zusammenfassung
8 Management von Wissensarbeit
8.1 Ein kurzer Blick auf Vorgehensmodelle
8.2 Softwareentwicklung gestalten
8.3 Planung zum Ziel
8.4 Iterationen – ein Schwert mit zwei Klingen
8.5 Qualität – was gibt’s denn da zu sichern?
8.6 Teams richtig aufstellen
8.7 Teams führen
8.8 Zusammenfassung
9 Die neue Sicht auf Softwareentwicklung
9.1 Ein neuer Aspekt: die Wissenslücke
9.2 Ein idealer Prozess
9.3 Zusammenfassung
10 Ausblick
Literatur
Index
Die Diskussion um den richtigen Softwareentwicklungsprozess ist fast so alt wie die Softwareentwicklung selbst. Lineare Prozesse nach dem Wasserfallmodell, iterative inkrementelle Prozesse wie RUP und seit einigen Jahren agile Prozesse wie Scrum sind in aller Munde. Auf vielen Konferenzen werden die verschiedenen Prozesse sowie deren Weiterentwicklung und erfolgreiche Anwendung eifrig diskutiert.
Wir selbst haben viele erfolgreiche Projekte in den letzten 10 Jahren mit RUP durchgeführt und setzen seit einigen Jahren auch agile Methoden wie Scrum erfolgreich ein. Zwar weniger aus eigener Erfahrung, aber von unseren Kollegen wissen wir, dass es auch Projekte gab und immer noch gibt, die mit linearen Prozessen erfolgreich verlaufen oder verlaufen sind.
Dennoch konnten wir bisher auch in der Literatur keine vernünftige Erklärung finden, welche Projekte mit welchen Prozessen überhaupt realisierbar sind und wie dabei eine hohe Produktivität erreicht werden kann. Stattdessen sind wir seit vielen Jahren Zeugen von Prozessdiskussionen, die manchmal schon fast religiösen Charakter annehmen. Dieser Streitpunkt und die dahinter liegende Frage, wie Softwareentwicklung abseits von Prozessen und Technologie funktioniert, haben uns motiviert, nach den eigentlichen Grundlagen zu suchen.
Eigene Erfahrung und die Beobachtungen darüber, wie Softwareentwickler bei der Arbeit vorgehen und Projektteams als Ganzes funktionieren, haben uns zur Beschäftigung mit kognitiver Psychologie und dabei speziell mit problemlösendem Denken geführt. Dabei haben wir einen neuen Blick auf Softwareentwicklung gewonnen und unsere unterschiedlichen Ansichten und Erfahrungen ausgetauscht. Das zunächst unscharfe Bild hat sich damit über die Zeit schrittweise weiterentwickelt. Die Autoren Jörg Dirbach als Business Unit Manager und Chief Knowledge Officer, Markus Flückiger als Usability-Experte und Steffen Lentz als Architekt, Requirements Engineer und Projektmanager haben ihre Erfahrungen und Beobachtungen zu einer neuen fundierten Sicht auf Softwareentwicklung kondensiert.
Dieses Buch haben wir für alle Personen geschrieben, die in der Softwareentwicklung tätig sind. Dazu gehören zum Beispiel Softwareentwickler, Requirements Engineers, Softwarearchitekten, Projektmanager, aber auch Leiter von Entwicklungsabteilungen oder Prozess- und Qualitätsverantwortliche.
In diesem Buch lernen Sie, wie Sie gängige Prozessmodelle aus einer neuen Perspektive betrachten und auf die Eignung für Ihr Projekt hin bewerten können. Dabei betrachtet diese neue Perspektive den Menschen in seiner Rolle als Problemlöser als die zentrale Einheit. Individuelle Problemlösung spielt dabei genauso eine Rolle wie die Zusammenarbeit im Team und die Interaktion mit den Benutzern oder Kunden.
Dabei ist es egal, ob Sie zurzeit lineare Prozesse wie den Wasserfallprozess verwenden oder ob agile Prozesse wie Scrum zu Ihrer täglichen Arbeit gehören. Sie lernen durch dieses Buch, warum lineare Prozesse Grenzen haben und wo genau diese liegen. Anhänger der iterativen, inkrementellen und agilen Prozesse lernen zu verstehen, welche der Techniken in welchen Situationen Mehrwert liefern und in welchen nicht. Mit diesem Verständnis als Rüstzeug können Sie zukünftig fundiert beurteilen, für welche Projekte bestimmte Prozesse geeignet sind und wann Sie Elemente anderer Vorgehensweisen einsetzen sollten.
Sie sind dann in der Lage, den für Ihr Projekt und Ihr Team optimalen Prozess selbst zu gestalten – und dogmatische Prozessdiskussionen gehören der Vergangenheit an. Natürlich bedienen Sie sich dabei aus der Vielzahl etablierter und gut beschriebener Vorgehensmodelle – aber jetzt mit einer Souveränität, die auf einem soliden, an den kognitiven Fähigkeiten des Menschen orientierten Fundament basiert.
Nach dieser Einführung gibt Kapitel 2 einen Überblick über die heutigen Ansprüche an Softwareentwicklung sowie die gängigen Herangehensweisen.
Kapitel 3 beschreibt die drei aus unserer Sicht wesentlichen Aspekte der Softwareentwicklung, die häufig zu Missverständnissen und damit zu unproduktiven Projekten beitragen.
Was problemlösendes Denken allgemein und in der Softwareentwicklung wirklich ausmacht und wie es sich von Routinearbeit unterscheidet, beschreiben wir in Kapitel 4.
Wenn Teams gemeinsam Software entwickeln, ist es wichtig, die individuellen Problemlösefähigkeiten derart zu vernetzen, dass Teams in der Lage sind, Software zu entwickeln, die für eine Person alleine zu komplex oder zu umfangreich ist. Wie dies gelingt, beschreiben wir ausführlich in Kapitel 5.
Dokumente, Zeichnungen oder allgemein Modelle sind meist ein wesentlicher Bestandteil jedes Entwicklungsprojekts. Wie Sie all diese externen Arbeitsmittel so einsetzen, dass Teams produktiv Software entwickeln, lesen Sie in Kapitel 6.
Basierend auf all diesen Grundlagen vermitteln wir Ihnen in Kapitel 7 den eigentlichen Kern von Produktivität.
Kapitel 8 beschreibt Bausteine einer erfolgreichen Führung von Softwareentwicklung und vergleicht die etablierten Softwareentwicklungsprozesse.
In Kapitel 9 stellen wir Ihnen, basierend auf den erarbeiteten Grundlagen, unsere neue Sicht auf Softwareentwicklung vor. Mit dieser neuen Perspektive werden Sie zukünftig Softwareentwicklung viel grundlegender verstehen und damit erfolgreich das Vorgehen im Team dynamisch der Projektsituation anpassen können.
Der Ausblick in Kapitel 10 fasst die neu gewonnene Perspektive auf Softwareentwicklung nochmals zusammen und schildert eine Diskussion darüber, wie ein Team diese Erkenntnisse nun in die Tat umsetzen kann.
Durch alle Kapitel begleiten Sie mehrere fiktive Personen, die in Dialogen und Interviews ihre Erfahrungen und Meinungen erzählen. Wir möchten Ihnen damit das Wissen in diesem Buch nicht nur in sachlich formulierten Texten und Grafiken vermitteln, sondern durch die Aussagen und Erzählungen von Personen auch Ihre Erfahrungswelt als Leser ansprechen und herausfordern.
Wir empfehlen Ihnen, das Buch von vorne bis hinten durchzulesen, da die Kapitel aufeinander aufbauen und besonders die Kapitel 4 bis 6 sehr wichtige Grundlagen vermitteln, ohne die die nachfolgenden Kapitel nur schwer zu verstehen sind. Dennoch haben wir auch eine Abkürzung für eilige Leser in das Buch eingebaut, die sich zunächst einen weniger detaillierten Überblick verschaffen wollen und dabei in Kauf nehmen, nicht alles in der Tiefe zu verstehen. Wenn Sie nach dem Lesen des Inhaltsverzeichnisses und dieser Einleitung den Absatz zu Beginn sowie die abschließende Zusammenfassung jedes Kapitels lesen, sollten Sie innerhalb einer Stunde einen guten Überblick über die vorgestellte neue Sicht auf Softwareentwicklung gewinnen. Danach steht es Ihnen frei, in einzelne Kapitel einzutauchen oder nun das Buch in einem Zug durchzulesen.
Wir haben uns entschieden, Zitate aus englischsprachiger Literatur nicht zu übersetzen, sondern im Original zu belassen. Deswegen sind grundlegende englische Sprachkenntnisse zum Lesen dieses Buchs von Vorteil.
Ein solches Buch zu schreiben, ist ein Projekt, das zu Beginn mit vielen Risiken behaftet ist. All diese Risiken entstehen aus Wissenslücken, die im Laufe des Buchschreibens geschlossen werden müssen.
Besonders geholfen hat uns hier René Schönfeldt, Leiter des Lektorats beim dpunkt.verlag, der mit konstruktivem Feedback vom ersten Manuskript bis zum fertigen Buch eine wertvolle Stütze dieses Projekts war. Herzlichen Dank dafür.
Die Firma Zühlke, Arbeitgeber von Jörg und Markus, hat das Projekt mit Arbeits- und Ausbildungszeit großzügig unterstützt, was alles andere als selbstverständlich ist. Da die langfristige Entwicklung der Mitarbeiter einer der Kernwerte von Zühlke ist, war dies möglich. Nutzen konnten wir auch das Wissen aus unserer täglichen Projektarbeit: Der Know-how-Pool, der einfache Zugang zu Informationen, die Zusammenarbeit mit Kunden und der Austausch mit unseren Kolleginnen und Kollegen waren sehr wertvoll. Wir möchten uns hier herzlich für die Unterstützung bedanken, namentlich bei Dr. Walter Hürsch, der die Idee zu diesem Buch von Anfang an gefördert hat, sowie bei Philipp Sutter.
Auch die Credit Suisse in Zürich, Arbeitgeber von Steffen, hat das Projekt mit freier Zeit großzügig unterstützt. Vielen Dank dafür an Isabelle Laurin und Nicolas Stuby.
Einige unserer Kollegen bei Zühlke haben sich schon sehr früh bereit erklärt, mehrere Versionen unseres noch unreifen Manuskripts zu lesen und wertvolles Feedback zu geben. Danke an Gregor, Marco, Roland, Simon, Franziska, Ueli und Frank.
Dass die Grafiken in unserem Buch so schön geworden sind, verdanken wir Jeannine Steinhauer und Michael Feer. Vielen Dank an Euch beide für die engagierte und kreative Arbeit.
Ein Dank geht auch an die Gutachter, die unser Manuskript kritisch durchleuchteten und mit konstruktiven Vorschlägen einen wertvollen Beitrag geleistet haben.
»Zwei Wahrheiten können sich nie widersprechen.«
Galileo Galilei, Physiker und Astronom
Die Ansprüche und Erwartungen an die Softwareentwicklung sind ebenso groß wie die damit verbundenen Herausforderungen. Entwicklungsprozesse und Vorgehensmodelle versprechen Hilfe und erfolgreiche Projekte. Dennoch zeigt die Erfahrung, dass jedes Projekt mit Risiken verbunden und ein Scheitern immer möglich ist. Dieses Kapitel enthält eine Bestandsaufnahme und beantwortet die Frage: Wo stehen wir heute eigentlich?
Software ist heute aus unserem Leben nicht mehr wegzudenken. Der Alltag der Menschen ist von elektronischen Geräten bestimmt, vom PC über den Wäschetrockner bis hin zum Smartphone. Und kaum ein Unternehmen könnte ohne elektronische Unterstützung sein Geschäft auf dem heutigen Stand betreiben – von Fluggesellschaften und Eisenbahnen über Banken bis hin zum produzierenden Gewerbe.
Ansprüche an Software und ihre EntwicklungSoftware ist zum bestimmenden Element geworden – entsprechend hoch und nicht selten widersprüchlich sind die Ansprüche an Software und ihre Entwicklung. Anwender wünschen sich die für sie richtigen Funktionen, verpackt mit einer guten Bedienbarkeit. Für Unternehmen zählt sowohl Innovation als auch die »Time-to-Market«, also die schnelle Fertigstellung einer Software. Gepaart werden soll dies mit hoher Flexibilität für zukünftige Änderungen und Erweiterungen.
Für alle ist Software ein Kostenfaktor, den es gering zu halten gilt. Gleichzeitig sollte die Qualität nicht leiden – schlechte Software hat jeder schon einmal gesehen, und gescheiterte Projekte können gar Millionen kosten.
Ansprüche an das Management von SoftwareprojektenDie Ansprüche an das Management von Projekten zur Software-entwicklung sind nicht geringer. Zum einen soll es selbstverständlich dafür sorgen, dass das Projekt erfolgreich ist und das Resultat alle Wünsche der Interessenvertreter erfüllt. Darüber hinaus möchte das höhere Management Transparenz über das Projekt, den Fortschritt und das investierte Geld. Das Projektmanagement muss daher in der Regel eine Planung liefern, die zeigt, wann was zu welchen Kosten geliefert wird. Anhand dieses Plans wird dann auch der Fortschritt gemessen: Man vergleiche zu einem Zeitpunkt den Istzustand im Projekt mit dem Plansoll. So kann das Projektmanagement eventuelle Abweichungen früh erkennen und gegebenenfalls Maßnahmen ergreifen.
Was meint Toni, Projektleiter, dazu?Toni: »Ich arbeite nun seit bald zwanzig Jahren in der Softwareentwicklung. Angefangen habe ich in einer Firma, die Geräte herstellt, als Ingenieur. Jetzt bin ich in der Entwicklungsabteilung einer großen Firma gelandet und leite Projekte. Ich bin dafür verantwortlich, dass die gewünschte Funktionalität in Zeit und Budget geliefert wird.«
I: »Was gefällt dir an deiner Aufgabe?«
Toni: »Ich finde das Führen eines Teams spannend, und natürlich die ganze Kommunikation nach oben. Wie bekomme ich das Projekt durch und erhalte die nötige Priorität im Management? Wie bekomme ich die Anforderungen richtig und was alles dazu gehört.«
I: »Was gefällt dir weniger gut?«
Toni: »Naja, zwischendurch bin ich mehr Sekretär denn Führungskraft: Irgendwelche Projektpläne der Realität anpassen, den aufgelaufenen Aufwand der Arbeitspakete nachtragen und ähnliche Dinge. Und dann immer wieder die politischen Spielchen in der Firma.«
I: »Warum ist Softwareentwicklung schwierig?«
Toni: »Die Kommunikation ist schwierig. Informationen müssen von den Stakeholdern und Fachexperten über die Business-Analysten, Anforderungsleuten, Entwickler bis ganz zu den Testern gelangen. Das ist fast wie in diesem Spiel, wo man sich der Reihe nach einen Satz ins Ohr flüstert. Was rauskommt, ist immer was ganz anderes, als was reingeht. Unter diesen Umständen so etwas wie Planung und Fortschrittskontrolle zu machen, ist wirklich nicht einfach.«
Die Ansprüche aller Interessenvertreter zu erfüllen, ist für jedes Softwareprojekt eine Herausforderung. Nicht nur, aber auch deswegen hat jedes Projekt ein gewisses Risiko des Scheiterns. Einerseits können konkurrierende Anforderungen der Stakeholder nicht immer schlüssig gelöst werden. Andererseits ist es aber auch möglich, dass die vom Projekt zu liefernde Lösung zu aufwendig oder zu kompliziert ist.
Ein Beispiel für Letzteres ist das Projekt Toll Collect für die LkwMaut auf Deutschlands Autobahnen. Die beabsichtigte Lösung mit GPS-Empfängern, Rückmeldung über Mobilfunkverbindungen und automatischer, streckenabhängiger Abrechnung war so komplex, dass sie sich nicht innerhalb des gesteckten Zeit- und Kostenrahmens von nicht einmal einem Jahr liefern ließ. Erst über ein Jahr später als ursprünglich geplant konnte eine funktionierende Lösung in Betrieb genommen werden, der volle Funktionsumfang war erst fast zweieinhalb Jahre später erreicht. Immerhin gab es hier letztendlich eine funktionierende Lösung – andere Projekte schaffen auch das nicht.
Die Frage, wie sich Erfahrungen wie die mit Toll Collect vermeiden lassen, beschäftigt das Software Engineering seit Jahrzehnten. Zudem schielt das Management von Unternehmen, in denen Software entwickelt wird, geradezu neidisch auf das produzierende Gewerbe. Diesem gelingt es, durch einen vorab definierten Herstellungsprozess, nahezu absolute Sicherheit über die benötigten Ressourcen und die Qualität des späteren Ergebnisses zu erreichen. Ist das nicht auch für die Entwicklung von Software möglich?
Vorgehensmodelle nach dem Vorbild der IndustrialisierungJa, es ist auch für Entwicklungsprojekte möglich – sagen die einen. Vorgehensmodelle, vom V-Modell über den Rational Unified Process (RUP) bis hin zu zahlreichen unternehmensinternen Prozessen (häufig abgeleitet vom V- oder Wasserfallmodell) versuchen genau diese perfekte Planbarkeit und Kontrolle der Softwareentwicklung, wie es uns die Industrialisierung in der Produktion vorgemacht hat. Kennzeichen sind eine hohe Arbeitsteilung mit vielen Rollen, viele Vorgaben in Form von Aktivitäten und zu erstellenden Zwischenergebnissen sowie in der Regel eine hohe Zahl an Dokumenten, die im Projektverlauf zu erstellen sind.
Die Philosophie dahinter ist der Fertigungsindustrie entlehnt, und die wiederum basiert bis heute auf Ideen eines gewissen Frederick Winslow Taylor aus dem frühen 20. Jahrhundert.
Taylor (1856–1915) war ein Ingenieur und Arbeitswissenschaftler, der die Unternehmensführung mit rein wissenschaftlichen Herangehensweisen (Scientific Management) optimieren und damit zugleich auch soziale Herausforderungen lösen wollte. Seine Ideen wurden zuerst von Henry Ford in der Autoproduktion des berühmten »Model T« umgesetzt.
Die von Taylor 1911 in seinem Hauptwerk, The Principles of Scientific Management, [Taylor 1911] verfassten Thesen lassen sich wie folgt zusammenfassen:
Die Prinzipien des Taylorismus sind vor dem Hintergrund der damaligen Zeit zu sehen und stießen später auf Ablehnung – etliche Aspekte wirken dennoch bis heute.
Der bis heute gültige Kern der industriellen Fertigung, die Arbeitsteilung mit ihrer typischen, oft am Fließband durchgeführten Routinearbeit, geht auf diese Prinzipien zurück. Anstatt eine Person ein komplettes Produkt – beispielsweise ein Auto – herstellen zu lassen, gibt es nur noch spezialisierte Arbeitsstationen, an denen einzelne Arbeiter eine ganz spezifische Tätigkeit ausüben – z. B. Karosserie lackieren. Anschließend wird das Produkt mit dem Fließband zum nächsten Arbeiter weitergereicht, der die darauf folgende Tätigkeit ausführt, wie den Motor einbauen.
Traditionelle Vorgehensmodelle für die Softwareentwicklung versuchen, diese in der Industrie nach wie vor erfolgreichen Prinzipien auf die Projektarbeit zu übertragen. Konkret manifestiert sich das so:
Der Prozess der Software-»Herstellung« ist wie in der Fabrik funktional zerlegt, hier in sogenannte Disziplinen. Was der Lackierer und der Monteur in der Fabrikhalle sind, sind die Analysten, Architekten und Entwickler im Softwareprojekt.
Es gibt einen mehr oder weniger sequenziellen Prozess mit aufeinander aufbauenden Arbeitsergebnissen. Was die Karosserie und der Motor in der Autofabrik sind, das sind die Spezifikation und Architekturdefinition im Softwareprojekt.
Die Arbeitsergebnisse der einzelnen Disziplinen werden kontrolliert bzw. qualitätsgesichert. Software wird getestet, im Falle von Dokumenten geschieht dies mittels Reviews.
Die Schritte vom Beginn des Projekts bis zum fertigen Endprodukt werden so exakt wie möglich geplant.
Mit dieser Philosophie und den genannten Maßnahmen streben die Vertreter der Softwareentwicklung nach industriellem Vorbild einen ähnlichen Grad an Vorhersagbarkeit an wie in der Massenfertigung von Produkten.
Roman, Business-Analyst, erzählt:
»Ich arbeite in unseren Projekten auf der Business-Seite. Beispielsweise definieren wir eine Prozessoptimierung, eine neue Dienstleistung oder dergleichen, die dann durch die IT unterstützt umgesetzt werden soll. Aus den gesetzlichen Vorgaben, Prozessen, Geschäftsregeln und dem Domänenmodell stelle ich für die Softwareentwicklung eine Fachspezifikation zusammen.«
I: »Was gefällt dir an deiner Aufgabe?«
Roman: »Die Komplexität und Vielfalt der Aufgabe. Man braucht technisches Verständnis, viel Fachwissen und muss die vielen Abhängigkeiten berücksichtigen. Zudem hat man es mit fast allen Hierarchiestufen zu tun und muss mit allen kommunizieren können.«
I: »Was gefällt dir weniger gut?«
Roman: »Naja, es ist immer eine große Herausforderung, Spezifikationen derart zu schreiben, dass die Entwickler diese auch wirklich verstehen. Ich beschreibe auf vielen Hundert Seiten Dinge, die mir völlig klar sind. Doch die Entwickler haben oft keinerlei Verständnis für die Geschäftsprozesse.«
I: »Warum ist Softwareentwicklung schwierig?«
Roman: »Meine Erfahrung zeigt mir, dass die Arbeit an umfangreichen Dokumenten immer sehr aufwendig und vor allem langwierig ist. Da müssen dann jede Menge Personen Input geben und zustimmen. Oft muss das Ganze dann auch noch einmal formell abgenommen werden. Das ist dann eine zusätzliche Hürde, denn niemand will sich aus dem Fenster lehnen und später die Schuld bekommen, wenn es Missverständnisse gegeben hat. Und ist dann endlich ein Dokument abgenommen, dann weiß man ja trotzdem nicht, was die Entwicklung daraus macht. Irgendwie scheint das alles recht ineffizient und sollte eigentlich besser gehen – aber wie?«
Rolf beschreibt seine Sicht als Entwickler: »Ich habe an einer Fachhochschule Informatik studiert und arbeite nun als GUI-Entwickler, wir machen hier eigentlich alles mit .NET, ich kenne mich aber auch mit Eclipse RCP, Silverlight und Flash aus.«
I: »Was gefällt dir an deiner Aufgabe?«
Rolf: »Naja, ein gutes GUI zu entwerfen und zu entwickeln finde ich eine spannende Aufgabe. Man möchte das gut testbar machen. Außerdem ist mir das gestalterische Element wichtig. Es macht einfach Freude, ein GUI zu haben, das nicht nur einfach zu bedienen ist, sondern auch gut aussieht.«
I: »Was gefällt dir weniger gut?«
Rolf: »Man macht sich das Leben hier unnötig schwer. Einerseits haben unsere Architekten ein Framework erstellt, das wir einsetzen müssen und uns sehr einschränkt. Auf der anderen Seite kommen die Business-Analysten teilweise schon mit fertigen Skizzen der Screens. Die Vorgaben sind aber nicht realisierbar, viel zu kompliziert und haben kein durchgängiges Konzept. Anstatt uns das zu überlassen, beharren sie auf ihren Skizzen. Wir implementieren das halt so gut es geht. Damit ist zwar niemand zufrieden, aber wir können endlich miteinander diskutieren. Letztendlich implementieren wir jedes GUI meist zweimal.«
I: »Warum ist Softwareentwicklung schwierig?«
Rolf: »So schwierig wäre das gar nicht, wenn sich die Leute nicht selbst das Leben schwer machen würden und jeder irgendwas für sich werkeln würde, anstatt sich zusammenzusetzen und gemeinsam eine Lösung zu finden. Vor allem nutzen wir die leichte Änderbarkeit von Software in den frühen Phasen eines Projekts viel zu wenig aus.«
Mittlerweile mehren sich die Stimmen, die sagen, dass die Prinzipien der industriellen Fertigung nicht auf die Softwareentwicklung übertragbar seien. Die Vertreter sogenannter agiler Prozesse wollen einige Dinge grundlegend anders machen als die »Industrialisierer«: wenige Rollen, wenige Vorgaben, direkte Kommunikation im Team und mit dem Kunden, Dokumentation nur in begründeten Fällen und vor allem ein sehr kurzer Planungshorizont von nur wenigen Wochen mit schnellem Feedback. Und auch deren Befürworter haben ein Vorbild in der Fertigungsindustrie. Denn mit dem sogenannten Lean Management existiert auch dort – und zwar seit Mitte des 20. Jahrhunderts – eine Alternative zur tayloristischen Philosophie [Liker 2003]. Der Fokus liegt hier auf einer in allen Bereichen schlanken Organisation, auf strikter Kundenorientierung sowie einem kontinuierlichen Verbesserungsprozess.
Die Methoden stammen unter anderem aus Japan, und da vom Autohersteller Toyota. Auch im Lean Management gibt es verschiedenste Vorgehensmodelle und Ausprägungen – sowohl in der Industrie (z. B. mit dem Kanban-Produktionsprinzip) als auch in der Software-entwicklung (z. B. mit Extreme Programming oder Scrum).
Für das Software Engineering, in dem die Philosophie des Lean Management eben unter dem Begriff agile Entwicklung bekannt ist, ist das agile Manifest maßgebend [Beck et al. 2001]. Es wurde im Jahr 2001 von 14 führenden unabhängigen Software-Ingenieuren während einer Klausur in den Bergen von Utah erdacht und verfasst. Unter den Autoren sind so bekannte Namen wie Kent Beck, Martin Fowler, Alistair Cockburn und Ward Cunningham.
Das agile Manifest bricht bewusst mit etlichen von Taylor übernommenen Prinzipien der traditionellen Softwareentwicklung. Es umfasst folgende vier Prinzipien:
Individuen und Interaktion sind wichtiger als Prozesse und Tools.
Funktionierende Software ist wichtiger als überbordende Dokumentation.
Enge Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
Auf Änderungen reagieren ist wichtiger, als einem Plan zu folgen.
Die Formulierungen sind genau zu nehmen. Die jeweils zuerst genannten Punkte gelten als wichtiger – was jedoch nicht bedeutet, dass die anderen Dinge unwichtig oder gar überflüssig wären.
Die agilen Vorgehensmodelle setzen diese Prinzipien um, was sich folgendermaßen zeigt:
Es gibt keine Arbeitsteilung mittels Disziplinen. Stattdessen steht das gemeinsam arbeitende Team im Vordergrund.
Es gibt keinen sequenziellen Prozess mit definierten Schritten, denen möglichst genau zu folgen wäre.
Dokumente werden nicht als »Bauteil« behandelt, sind also nicht Arbeitsergebnis des einen und Arbeitsauftrag des nächsten.
Der einzige, der die Qualität des Produkts (und damit die Zielerreichung des Projekts) beurteilen kann, ist der Kunde. Entsprechend eng muss er involviert sein.
Aufgrund der Komplexität und üblicherweise vieler Unbekannter in einem Projekt wird der Planungshorizont stark verkürzt. Dadurch erhält man schneller Feedback und die regelmäßige Berücksichtigung von Änderungen wird möglich.
Der Unterschied zur Industrialisierung könnte nicht größer sein – nicht nur in der Arbeitsweise, sondern auch bezüglich Planung und Fortschrittskontrolle. Die agilen Prozesse versuchen gar nicht erst, vorab eine große, allumfassende Lösung für die Aufgabe des Projekts zu entwerfen. Sie gehen bewusst kleine Schritte, getreu dem Motto »Der Weg ist das Ziel.«
Wie sieht Evelyn, Softwarearchitektin, die Welt der Softwareentwicklung?Evelyn: »Ich arbeite nun seit über zehn Jahren in einer Softwarefirma und entwickle Software im Kundenauftrag, typischerweise in Java. Ich bin Softwarearchitektin und habe somit die Verantwortung für die technische Lösung. Ich bin insbesondere dafür verantwortlich, dass die Software die Anforderungen, vor allem die nicht funktionalen, erfüllt.«
I: »Was gefällt dir an deiner Aufgabe?«
Evelyn: »Als Dienstleister sieht man viele Firmen, hat viel Abwechslung und immer ein spannendes Umfeld. Zudem bin ich ein Mensch, der im Team arbeiten will und sich dabei wohlfühlt. Ich glaube, was mich reizt, ist die herausfordernde Denkarbeit zusammen mit anderen Menschen.«
I: »Was gefällt dir weniger gut?«
Evelyn: »Dogmatisch vertretene Ansätze. Architektur hat viel mit Vorausdenken zu tun. Ich muss mir Gedanken darüber machen, was das System in einigen Monaten oder Jahren mal aushalten muss. Beispielsweise wird in agilen Projekten gerne der üblicherweise kurze Planungshorizont als Vorwand genommen, nicht mehr nach so etwas wie stabilen Anforderungen zu suchen. Wir können das ja später einem Refactoring unterziehen, sagen die Entwickler. Schon, nur ist es bei einem großen System doch viel zu aufwendig, nachträglich so etwas wie Performance oder Skalierbarkeit grundlegend zu verbessern. Agilität kann doch nicht bedeuten, dass man sich dümmer stellt, als man ohnehin schon ist.«
I: »Warum ist Softwareentwicklung schwierig?«
Evelyn: »Man hört von Entwicklern häufig den Vorwurf, dass sich die Anwender doch erstmal richtig überlegen sollen, was sie eigentlich haben wollen. Ich denke aber, das greift zu kurz. Ich habe vielmehr den Eindruck, dass vieles den Anwendern erst beim Anblick der Software selbst so richtig klar wird. Aus Sicht der Entwickler mag das natürlich zu spät sein. Aber insofern hat agile Softwareentwicklung schon ein paar interessante Ansätze.«
Für eine Branche, deren Arbeitsergebnisse derart den Alltag der modernen Menschheit bestimmen, ist eine solch fundamentale Uneinigkeit über das richtige Vorgehen mehr als verwunderlich.
Wie kann es sein, dass es mit dem linearen Vorgehen auf der einen und der agilen Entwicklung auf der anderen Seite nicht nur zwei grundverschiedene Strömungen gibt, sondern diese auch mit teilweise fanatischem Eifer von den jeweiligen Vertretern propagiert werden? Das wäre noch halb so schlimm, wenn beide für gewöhnlich auch erfolgreich wären. Aber so wie es zahlreiche Beispiele für vollkommen unproduktive Softwareprojekte nach industriellem Muster gibt, so ist auch der Erfolg dann nicht unbedingt garantiert, wenn man sich agil auf die Fahnen schreibt.
Offensichtlich ist keine der beiden Welten perfekt, sonst gäbe es sicher nur noch eine. Auf das eine Kochrezept, dem man auf dem Weg zum Projekterfolg nur folgen muss, wartet die Softwarewelt bis heute – und womöglich für immer – vergeblich.
Für jede Methodik, gleich welcher Couleur, gibt es viel Know-how, wie man sie bestmöglich anwenden soll. Was tut man nun, wenn all das Know-how noch immer keinen Erfolg garantiert?
Wir sind der Meinung, dass Know-how alleine nicht reicht – was fehlt, ist Know-why: Welche Herausforderungen liegen eigentlich genau in einem Softwareprojekt? Wie können diese durch eine Methodik gemeistert werden? Welche Rolle spielen kognitive Denkprozesse und wie arbeiten Teams am besten zusammen? Welche Arbeitsmittel unterstützen die Softwareentwicklung optimal? Welche Kriterien gibt es, um eine Methodik auszuwählen oder zu beurteilen? Wo liegen die Stärken und Schwächen der vielen Methodiken? Ein grundlegendes Modell für Softwareentwicklung kann hier viele Fragen beantworten.
Bei all den Diskussionen um Prozesse und Vorgehensweisen scheinen uns die wichtigsten Akteure zu wenig beachtet zu werden – nämlich die am Projekt beteiligten Menschen. Ein Softwareprojekt ist von Anfang bis Ende ausschließlich menschliche Kopfarbeit: Menschen beschreiben das zu lösende Problem, Menschen denken sich mögliche Lösungen aus, Menschen untersuchen technische Möglichkeiten, Menschen schreiben und benutzen letztendlich die Software.
Vor diesem Hintergrund erwecken etliche der heute bekannten Vorgehensmodelle bei näherer Betrachtung den Eindruck, das Pferd von hinten aufzuzäumen. Anstatt zu berücksichtigen, wie Menschen gemeinsam ein Problem wie Softwareentwicklung lösen, zwängen sie den Menschen in einen idealisierten Fabrikationsprozess. Es wird vorgegeben, welche Vorlagen auszufüllen sind und wer wann mit wem zu kommunizieren hat. Der Inhalt des Projekts tritt in den Hintergrund, individuelle Stärken werden zweitrangig. Es sind lediglich Funktionen zu erfüllen, womit letztlich auch die Ressourcen austauschbar werden. Im Zweifelsfall gilt: Der Prozess hat immer Recht, der Mensch ist das Sorgenkind und muss sich anpassen. Lässt sich so wirklich Produktivität erzielen? Wir meinen nein.
Gemeinsam Neues entwickelnEs ist an der Zeit, dass wir verstehen, wie Menschen Neues entwickeln und wie sie miteinander Probleme lösen. Wie Sie bald sehen werden, funktioniert dies grundlegend anders als alles, was sich von der industriellen Produktion abschauen lässt.
Jeder Einzelne von uns hat Stärken und Schwächen, individuelle Erfahrungen und Vorlieben – Eigenschaften also, die eine Person ebenso einzigartig machen wie ihren Anteil am Projekt. Wollen wir Produktivität erreichen, dann müssen wir jedes Individuum in die Lage versetzen, seinen bestmöglichen Beitrag einzubringen – nicht nur alleine, sondern gerade im Team.
Mit einer Kombination aus Theorie, Praxisbeispielen und Gesprächen mit den fiktiven Personen liefert dieses Buch im Folgenden eine Antwort auf die wichtigste aller Fragen: Wie erreichen wir Produktivität in der Softwareentwicklung?
Trotz vieler verschiedener Softwareentwicklungsprozesse lässt sich feststellen, dass die Ansprüche und Erwartungen an den Erfolg von Softwareprojekten nicht erfüllt werden. Die Prozesslandschaft reicht dabei von einer nach industriellem Vorbild eher tayloristisch ausgerichteten Vorgehensweise bis hin zu agilen Prozessen, die Ideen des Lean Managements in der Softwareentwicklung verwirklichen. Obwohl viele dieser Prozesse sehr gut dokumentiert sind und auch meist schon sehr viel Erfahrung existiert, gibt es Projekte, die scheitern oder in große Schwierigkeiten geraten. Warum es mit dem industriellen und dem agilen Ansatz überhaupt zwei so grundverschiedene Philosophien zur Entwicklung von Software gibt, bleibt unklar.
Wir möchten nicht mehr den Prozess ins Zentrum stellen, sondern die Menschen im Projekt. Wir sind der Meinung, dass der Prozess die menschlichen Fähigkeiten zur Problemlösung sinnvoll unterstützen muss und nicht umgekehrt. So kommen wir einer produktiven Softwareentwicklung näher.
Softwareentwicklung hat wenig bis nichts mit der Herstellung von Massengütern gemein. Vielmehr befasst sich Softwareentwicklung mit der Lösung von Problemen. Welche Konsequenzen sich daraus ergeben, ist Thema des nun folgenden Kapitels. Wir stellen Ihnen drei Thesen vor, die aufgrund unserer Erfahrung den Kern der Softwareentwicklung ausmachen. Im weiteren Verlaufe des Buchs werden wir diese detaillieren und auf die Konsequenzen eingehen.
Softwareprozesse, die auf tayloristischen Prinzipien basieren, nehmen sich Fertigungsprozesse aus der Industrie zum Vorbild. Kennzeichnend für diese Prozesse ist, dass das jeweilige Endprodukt exakt bekannt und definiert ist. Im Rahmen einer Massenfertigung soll dieses tausend- oder gar millionenfach identisch und mit konstanten qualitativen Eigenschaften hergestellt werden.
Ausgehend von einem fertigen Prototyp leiten die Ingenieure der Forschungs- und Entwicklungsabteilung die dafür benötigten Fertigungsschritte ab und optimieren diese. Sie erstellen so zu einem standardisierten Produkt ein ebenso standardisiertes Rezept zu dessen Bau. Die Produktionsabteilung arbeitet anschließend das Rezept in der gewünschten Menge ab. Dank der definierten und kontrollierten Herstellungsweise erzeugt eine Firma so Produkte mit denkbar geringen Qualitätsschwankungen. Der Erfolg dieses Prinzips in Bezug auf Kosten und Qualität in der Industrie ist unbestritten.
Softwareentwicklung ist keine industrielle FertigungWie verhält sich das nun in der Softwareentwicklung? Rolf, GUI-Entwickler, schildert eine typische Ausgangslage eines Softwareprojekts:
»Die Ziele waren gegeben, der Kunde hatte eine recht genaue Vorstellung, was er erreichen wollte, und nannte ebenfalls einige konkrete Features. Doch gab es auch Benutzer an einem anderen Standort, und deren Bedürfnisse kannte niemand so genau. Selbstverständlich gab es unterschiedliche Lösungsalternativen mit Vor- und Nachteilen, doch so etwas wie ein Lösungskonzept war noch nicht da. Dies mussten wir zuerst entwickeln und die Alternativen entsprechend abwägen. Das ist uns – glaube ich – ganz gut gelungen. Leider änderten sich auch die Vorstellungen der Anwendervertreter im Projekt, gerade nach einer Demonstration des aktuellen Zwischenstands und insbesondere als zum ersten Mal Vertreter des anderen Standorts die Software begutachteten.«
Rolfs Schilderung ist exemplarisch für viele Projekte und deutet auf die wesentlichen Merkmale von Softwareentwicklung hin.
Das Ziel eines Softwareprojekts ist eine für die Benutzer zufriedenstellende Lösung, soviel ist klar. Allerdings gibt es verschiedene Lösungsalternativen – gute und weniger gute, effiziente und weniger effiziente. Welche es gibt, und welche unter Abwägung aller Umstände tatsächlich die beste ist, ist zu Beginn des Projekts unbekannt. Ein Projektteam tastet sich im Verlauf des Projekts an eine Lösung heran. Da es für gewöhnlich keine perfekte Lösung gibt, sondern Lösungen mit unterschiedlichen Stärken und Schwächen, wägt ein Projektteam also immer wieder Vor- und Nachteile einzelner Lösungen und Teillösungen ab.
Zudem ist zu Beginn für gewöhnlich auch die Ausgangssituation nur ungenügend bekannt. In Rolfs Beispiel ist es die Arbeitsweise am entfernten Standort, in anderen Situationen sind es unzureichende Kenntnisse der Fachdomäne, neue Geschäftsprozesse, Ergebnisse paralleler Entwicklungen und vieles mehr. Ein Projekt ist somit immer auch ein Lernprozess für die Beteiligten. Diese verstehen mit der Zeit die Bedürfnisse der Anspruchsgruppen besser und können so besser abschätzen, welche Lösungen eher gut und welche eher schlecht funktionieren könnten.
Nun steht eine Software nicht alleine da, sondern in einer engen Wechselwirkung zum Kontext. Wozu und wie werden Benutzer die Software verwenden? Wie sieht es mit konkurrierenden Lösungen und Bestrebungen aus? Wie ist die Wertschöpfungskette? Wie arbeitet das Unternehmen heute, wie vielleicht in zwei Jahren? Eine Software soll für einen bestimmten Kontext funktionieren und dieser ist dynamisch. Die Dynamik kann dafür sorgen, dass selbst an den Grundfesten einer Softwareentwicklung gerüttelt wird, wie folgender Bericht von Evelyn, Softwarearchitektin, unterstreicht:
»Wir steckten mitten in der Programmierung, als der Konzern entschied, eine größere Restrukturierung vorzunehmen. Da unser System die Kommunikation zwischen den Fachleuten elektronisch unterstützte, die Reorganisation diese Kommunikation aber völlig auf den Kopf stellte, war die Software quasi obsolet. Wir mussten konzeptionell wieder an den Anfang zurück und überlegen, was unter den gegebenen Umständen noch Sinn macht und was nicht.«
Evelyns Beispiel ist ein Extrem: Die Änderung im Kontext stellt das ganze Projekt infrage. Weit häufiger sind in der Praxis graduelle Änderungen. Das Projektteam, das eine Lösung liefern soll, wird aufgefordert, die Lösung entgegen ursprünglichen Plänen auf die eine oder andere Art zu modifizieren, die Prioritäten zu ändern oder etwas zusätzlich zu bauen. Kommt Ihnen das bekannt vor?
Eigenschaften der Softwareentwicklung Softwareentwicklung Softwareentwicklung lässt sich demzufolge mit folgenden Punkten charakterisieren:
Unwissen über Ausgangszustand
Unscharfes Ziel
Verschiedene, gegeneinander abzuwägende Lösungsalternativen
Kompromissbildung
Dynamik im Kontext
Damit besteht in der Softwareentwicklung eine komplett andere Situation als in der industriellen Fertigung. Sämtliche von dort übernommenen Ideen basieren darauf, dass das Endprodukt sowie der Prozess zum fertigen Produkt zweifelsfrei vorab bekannt sind. Beides ist in der Softwareentwicklung nicht gegeben.
Softwareentwicklung ist ProblemlösenSoftwareentwicklung funktioniert grundlegend anders als die Fertigung eines Produkts. Denken Sie an ein Schachspiel: Es gibt eine Unmenge an Varianten, wie am Ende die Figuren stehen können und auch wie die Spieler diesen Stand erreichen. Ein Spieler weiß zudem nicht, wie der Gegenspieler auf die eigenen Züge reagieren wird. So lässt sich eine Partie nicht im Voraus im Detail planen. Ein Spieler muss im Kopf Stellungen bewerten, Zugfolgen durchspielen, Gelegenheiten packen, also den Plan kontinuierlich anpassen. Softwareentwicklung hat viel mehr mit Schachspielen gemeinsam als mit der Produktion eines Autos.
Die allgemeine Frage nach Produktivität in der Softwareentwicklung lässt sich nun konkretisieren: Wie lösen Menschen produktiv Probleme? Dies ist Gegenstand von Untersuchungen von Kognitionspsychologen. Was die Forschung herausgefunden hat und was das für eine neue Sicht auf die Softwareentwicklung bedeutet, lesen Sie in Kapitel 4.
Die von der Industrie übernommenen Prinzipien beeinflussen nicht nur unsere Vorgehensweisen im Projekt, sondern auch das Denken in der Zusammenstellung und der Funktionsweise von Teams. Tayloristisch geprägte Softwareteams bestehen aus Spezialisten, die im Rahmen der Arbeitsteilung eine jeweils eng umfasste Aufgabe erfüllen, beispielsweise Anforderungen erheben. Das Arbeitsergebnis einer Person wird dann zum nächsten Spezialisten weitergereicht, also zum Beispiel dem Softwarearchitekten, der es weiterverarbeitet, bevor auch dieser sein Ergebnis jemandem übergibt.
Damit wird, analog zur industriellen Massenfertigung, aus den Menschen ein letztendlich austauschbarer Produktionsfaktor. Sie erfüllen eine eng definierte Rolle mit klarem Input und Output, im Grunde ähnlich wie eine Maschine.
Der nächste Schritt für Unternehmen ist dann nur logisch. Zuerst standardisiert ein Unternehmen die Prozesse organisationsweit mit dem Ziel, diese quantitativ zu optimieren. Ist dies erreicht, können anschließend ganze Teile des Prozesses, beispielsweise die Entwicklung oder das Testing, einfach in ein Billiglohnland ausgelagert werden. So versucht die Firma, dieselbe Leistung für weniger Geld zu erhalten – in dem Gedankenmodell ist es ja nur eine Funktion, die irgendwie irgendwo erfüllt werden muss.
Nun, funktioniert das in der Softwareentwicklung wirklich genauso wie in der Industrie? Sind die Menschen in einem Softwareteam austauschbare Produktionsfaktoren in einem standardisierbaren Prozess? Was sind die Konsequenzen dieser Haltung?
Andere Menschen, andere ProblemlösungEvelyn, Softwarearchitektin, erzählt:
»Wir wählten hier nicht eine Standardarchitektur, sondern bauten uns eine eigene Lösung zusammen, die insbesondere Multicasts auf dem Netzwerk zuließ. Einer unserer Entwickler hatte den Vorschlag gemacht, da er in einem früheren Projekt die Vorteile dieses Ansatzes schätzen gelernt hat. Das erwies sich im Nachhinein als Glücksfall. Wir stellten im Betrieb nämlich fest, dass deutlich mehr Anfragen auf unser System einprasselten als erwartet. Die Standardarchitektur hätte dies nicht geschafft. Ein anderes Team hätte vielleicht anders entschieden und sich dann an der schlechten Reaktionszeit die Zähne ausgebissen.«
Ob die getroffene Entscheidung nun richtig oder falsch war, sei dahingestellt, Evelyns Beispiel deutet auf etwas ganz anderes hin: Die an der Problemlösung mitarbeitenden Menschen sind ein höchst individueller Teil der Problemlösung. Mit dem Ersetzen durch andere Menschen würde nicht nur die Problemlösung in der Vorgehensweise, sondern sogar die spätere Lösung selbst ganz anders aussehen.
Wie ungewöhnlich dies auf den ersten Blick auch klingen mag, bei genauer Betrachtung macht dies Sinn. Jede Person bringt ein eigenes technisches und methodisches Erfahrungsspektrum, unterschiedliche Problemlösefähigkeiten und vieles mehr mit. Genau solche Faktoren entscheiden über das Ergebnis und den Weg einer Problemlösung. In Kapitel 4 werden wir noch näher darauf eingehen.
Ökosystem TeamSeit der Aufklärung prägt die Menschen der westlichen Welt ein sehr deterministisches Weltbild. Alles basiert auf dem Prinzip von Ursache und Wirkung. Die Physik der Welt um uns herum – so die Denkweise – muss nur verstanden werden, dann können wir sie uns untertan machen.
Genau so deterministisch soll auch die Softwareentwicklung sein. Die Autoren der diversen Vorgehensmodelle haben die Physik der Softwareentwicklung bereits für uns erforscht und eine Wegbeschreibung angefertigt. Die Projektteams können es sich daher einfach machen und nur noch mechanisch die Anweisungen dieses Rezepts befolgen. Voilà, die fertige Software steht glänzend und zitronenfrisch duftend im Regal. Alles ist vorher bestimmbar, die Arbeit ist simpel, überprüfbar, Ressourcen sind austauschbar und der Erfolg reproduzierbar.