Kein Verständnis ohne Überprüfung – Warum Wasserfallentwicklung nicht funktionieren kann

Gerade lese ich das Manuskript eines Buches, das demnächst im dpunkt.verlag erscheinen wird. Man hat mich nach meiner Meinung danach gefragt und ich finde es spannend. Die Autoren schauen durch die Brille der Psychologie unter fragen kritisch, inwiefern liebgewonnene oder gehypte Praktiken eigentlich auf einem wissenschaftlichen Fundament ruhen. Das finde ich gleichermaßen wichtig wie erhellend. Schön, dass in der letzten Zeit die softe Seite der Softwareentwicklung zunehmend Beachtung findet. Und der dpunkt.verlag tut sich da in Deutschland besonders hervor.

Aber mir geht es nicht um eine Buchrezension, vielmehr möchte ich Gedanken des Buches zum Anlass nehmen, mich selbst nochmal systematisch mit dem Vorgehen in der Softwareentwicklung zu beschäftigen. Was tun wir denn da eigentlich, wenn wir Anforderungen in Software gießen? Und wenn geklärt ist, was wir da tun, wie wird das am besten getan?

Meine These: Softwareentwicklung ist verlustbehaftete Kommunikation unvollständiger Daten. Deshalb ist Softwareentwicklung so besonders.

Datenübermittlung systematisch

Softwareentwicklung setzt Ideen im Kopf des Kunden um in Software, die der Kunde nutzt. Es geht also um eine Transformation von Ideen in ein Produkt. Naja, das ist noch nichts Besonderes; nichts anderes passiert in einem Restaurant, in dem ein Koch eine Idee für ein neues Gericht hat und am Ende liegt etwas auf dem Teller des Gastes. Auch da wird eine Idee in ein Produkt transformiert. Dennoch glaube ich, dass es nützlich ist, genau hinzuschauen und den Prozess der Softwareentwicklung einmal zu visualisieren.

Anfangen möchte allerdings mit simpler Datenübermittlung. Wenn einer “Daten im Kopf hat” die er einem anderen übermittelt, damit sie “in dessen Kopf sind”, dann sieht das so aus:

Der Sender, der mit den Daten im Kopf, kann seine Gedanken leider nicht per Telepathie dem Empfänger zukommen lassen. Also muss er sie in ein Medium verpacken (enkodieren). Dieses Medium interpretiert (dekodieren) der Empfänger; dadurch entsteht bei ihm eine eigene Vorstellung von dem, was der Sender im Kopf hat.

Wie das Bild zeigt, ist diese Datenübermittlung nicht problemlos. An mindestens zwei Punkten kann es zu Fehlern kommen:

• Es kann dem Sender passieren, dass er seine Daten nicht 100% korrekt auf das Medium überträgt. Oder vielleicht ist der Sender schuldlos und das Medium schlicht nicht reichhaltig genug, um die Daten 1:1 zu repräsentieren. In jedem Fall kann es leicht passieren, dass das Medium am Ende nur eine verarmte/reduzierte Version der ursprünglichen Daten transportiert.
• Und dann kann es natürlich dem Empfänger passieren, dass er die Daten im Medium inkorrekt interpretiert. Dann entsteht bei ihm eine andere Vorstellung als beim Sender. Die Daten im Kopf von Sender und Empfänger stimmen nicht überein. Allemal kann das nicht anders sein, wenn das Medium die ursprünglichen Daten nicht korrekt enthält – aus welchem Grund auch immer.

Übertragungsfehler – allemal bei menschlicher Kommunikation – sind mithin nicht zu vermeiden. Es stellt sich daher die Frage: Wie kann ein Sender eigentlich herausfinden, ob der Empfänger am Ende die beabsichtigten Daten “im Kopf hat”?

Wären Enkodieren und Decodieren ohne Probleme, das Medium reichhaltig genug, die Kommunikation also verlust und fehlerfrei… dann könnte der Sender immer sicher sein, dass beim Empfänger das vollständige Bild entsteht. Dann würde es am Ende genügen zu fragen, “Alles angekommen? Alles verstanden?” Und der Empfänger bräuchte nur mit “Ack” oder “Roger” oder “Verstanden” antworten.

Interessanterweise ist solch naive Nachfrage immer noch recht häufig zu hören. Achten Sie bei der nächsten Schulung einmal darauf oder wo immer ein Wissenstransfer stattfinden soll. Irgendwann wird da einer fragen, “Wie schaut es aus? Bis hierher alles klar?” und die kollektive Antwort der Wissensempfänger wird sein “Jo, alles klar. Es kann weiter gehen.”

Leider hat diese Antwort jedoch keinen Wert. Wissensempfänger können nicht wissen, ob sie das zu vermittelnde Wissen tatsächlich schon haben. Selbst in viel simpleren Situationen kann der Empfänger nicht einfach so wissen, ob er korrekt empfangen hat. Deshalb gibt es Prüfsummen.

Der Sender überträgt nicht nur seine Daten, sondern auch noch eine Prüfsumme, die sich aus den Daten errechnen lässt. Der Empfänger kann dann selbst feststellen, ob er korrekt empfangen hat, indem er mit demselben Algorithmus wie der Sender selbst die Prüfsumme berechnet und mit mitgelieferten vergleicht.

Stimmen die Prüfsummen überein, ist alles ok. Stimmen sie nicht überein, sind entweder die Daten oder die Prüfsumme inkorrekt übertragen worden. Der Empfänger muss den Sender also nur im (unwahrscheinlichen) Übertragungsfehlerfall belästigen. (Das gibt dem Sender zwar keine Sicherheit darüber, ob der Empfänger überhaupt Daten empfangen hat, aber den Fall lasse ich mal außen vor. In den Kommunikationen, um die es mir geht, ist das kein wirkliches Problem.)

Wenn für die zu übertragenden Daten eine Prüfsumme errechenbar ist, d.h. weitere Daten existieren, anhand derer der Empfänger prüfen kann, ob die eigentlichen Daten korrekt angekommen sind, dann ist Datenübertragung ohne weitere Kommunikation möglich. Dann kann der Datenstrom unidirektional vom Sender zum Empfänger fließen. Und nur im (seltenen) Fehlerfall ist ein Empfänger-Sender-Kommunikation nötig.

Solange jedoch keine Prüfsumme existiert, kann der Sender ohne eine “Spiegelung” durch den Empfänger nicht wissen, ob der die Daten korrekt empfangen hat.

Wenn der Empfänger während der “Spiegelung” zum Sender wird, kann es natürlich wieder zu einer verlust- und fehlerbehafteten Kommunikation kommen. Falls das Verständnis beim Empfänger inkorrekt ist, ist seine Darstellung dessen gegenüber dem ursprünglichen Sender ebenfalls notwendig inkorrekt. Darüber hinaus ist es aber wahrscheinlich, dass der Empfänger nicht einmal in der Lage ist, sein eigenes Verständnis präzise zu vermitteln. Zumindest ist das der Normalfall bei nicht trivialen Daten, also in allen menschlichen Lernsituationen.

Die Übertragung von Anforderungen aus dem Kopf eines Kunden in den Kopf eines Entwicklers kann nicht in einer Einbahnstraße geschehen. Anforderungen sind sehr komplizierte Daten, deren Enkodierung sicherlich stark verlust- und fehlerbehaftet ist. Dasselbe gilt für die Dekodierung. Das heißt, es sind viele Spiegelungen und Übermittlungswiederholungen nötig, um Anforderungen verlässlich zu übertragen. Zu glauben, es sei mit einem dicken Anforderungsdokument getan, das der Entwickler liest, versteht und in Software umsetzt, ohne großartig nachzufragen, ist naiv.

Anforderungen in Software transformieren

Am schönsten wäre es natürlich, wenn der Kunde selbst seine Software herstellen könnte. Mag sein – ist aber irreal. Soweit ist die Softwareentwicklung noch lange nicht, auch wenn Excel, Access und DSLs das manchmal suggerieren. Dennoch hier der Idealzustand im Bild:

Der Sender/Kunde enkodiert seine Anforderungen in eine Maschine (Software). Die transformiert dann Eingaben in Ausgaben, so wie der Kunde es sich wünscht.

Da das Encodieren auch hier natürlich fehler- und verlustbehaftet sein kann, stellt sich die Frage, wie der Maschinenbauer feststellt, ob die Maschine das tut, was sie tun soll? Ganz einfach: er muss sie mit Testeingaben füttern und schauen, ob sie daraus die zu erwartenden Ausgaben macht. Zur Definition einer Maschine gehören also nicht nur ihre Transformationsregeln (funktionale Anforderungen), sondern auch Beschreibungen zulässiger Eingaben und der daraus zu erzeugenden Ausgaben.

Wer eine Maschine bauen will, muss also sogar etwas mehr “im Köpfchen haben” als Regeln; er muss sehr konkret wissen, welche Eingaben erlaubt sind und in welche Ausgaben die durch eine korrekte Implementierung der Regeln in der Maschine transformiert werden sollen:

Damit stellt sich der reale Softwareentwicklungsprozess als Kette von Datenübermittlungen dar: der Kunde übermittel Anforderungen an einen Stellvertreter, der die Anforderungen dem Team vermittelt, das daraus eine Maschine baut, die der Kunde bzw. sein Stellvertreter prüfen müssen. Hier eine etwas verkürzte Darstellung der minimalen Entwicklungssequenz:

Eigentlich ganz einfach, oder? Es müssen die Anforderungen nur drei Mal verlust- und fehlerfrei enkodiert werden und zwei Mal verlust- und fehlerfrei dekodiert werden.

Entwicklung vs. Produktion

Selbst diese vereinfachte Darstellung der Softwareentwicklung sollte nun eines klar machen: Softwareentwicklung ist eben Entwicklung und nicht Produktion. Produktion ist nämlich, wenn eine existierende Maschine (oder Maschinerie) wiederholt Eingaben und Ausgaben transformiert. Die Eingaben mögen in einer gewissen, vergleichsweise geringen Bandbreite variieren und damit auch die Ausgaben. Aber letztlich läuft die Maschine(rie) ohne große Änderungen durch.

Das ist ja Sinn und Zweck einer Maschine(rie): Ermüdungsfrei immer wieder dasselbe tun. Ganz unkreativ – dafür verlust- und fehlerfrei.

Wenn eine Software erstmal entwickelt ist, dann ist sie selbstverständlich eine solche Maschine. Dann kann der Kunde mit ihr Ausgaben aus Eingaben produzieren. Immer und immer wieder.

Der Weg zur Software hin ist allerdings, der ist keine Produktion. Weder Kunde, noch Stellvertreter, noch Team sind Maschine(rie)n. Von ihnen kann bei aller möglicherweise vorhandenen Erfahrung nicht erwartet werden, dass sie verlust- und fehlerfrei Eingaben in Ausgaben transformieren. Enkodieren und Decodieren sind essenziell schwierig, sehr schwierig. Aus Anforderungen eine Software zu machen, ist mithin ein aufwändiger Kommunikations und Realisierungsprozess. Ansprüche, wie man sie an die Produktion stellt (z.B. gute Schätzbarkeit in puncto Geld- und Zeitaufwand), sind hier fehl am Platze. Softwareentwicklung ist vielmehr kreative Einzelstückherstellung, beginnt also immer wieder bei quasi Null.

Entwicklung als Lernprozess

Hier ein typischer Vermittlungsprozess ganz allgemeiner Art:

Die zu vermittelnden Daten sind kompliziert; es handelt sich um Wissen, also Fakten und Zusammenhänge. Enkodieren und dekodieren sind deshalb notwendig verlust- und fehlerbehaftet. Also ist eine Spiegelung des Empfangenen durch den Empfänger gegenüber dem Sender nötig. Und wenn der Empfänger “sich dumm anstellt” oder der Sender “sich nicht ausdrücken kann” oder schlicht die Natur der Daten auch bei kommunikationsfähigen und intelligenden Sendern und Empfängern keine Abkürzung erlaubt, dann ist eine “Datenübertragung” nur im Dialog möglich. Sender und Empfänger brauchen mehrere Iterationen, damit beim Empfänger die Daten in ausreichend hoher Korrektheit und Vollständigkeit ankommen.

Das nennt man dann Lernen.

Da es für nicht trivialen Lernstoff keine Prüfsummen gibt, braucht es einen Dialog, um Wissen vom Wissenden zum Unwissenden zu übertragen. Es geht zwar auch im Monolog, indem der Wissende sein Wissen einmalig enkodiert, z.B. in ein Buch oder ein Video, und der Unwissende dieses Medium wiederholt dekodiert und dann versucht, mit seinem Verständigs Eingaben in Ausgaben zu transformieren. Doch solches Autodidaktentum ist mindestens langwierig. Aber vor allem besteht keine Gewähr, dass der Unwissende je das Wissen des Wissenden erlangt. Denn bei aller Mühe, die sich der Wissende beim encodieren gibt, kann es zu Verlusten und Fehlern kommen. Wie aber soll dann der Unwissende aus einem löchrigen und/oder fehlerhaften Medium lückenloses und fehlerfreies Wissen dekodieren?

Wer an effektiver und effizier Wissensweitergabe interessiert ist, der stellt sich besser auf einen Dialog mit dem Wissensempfänger ein.

Jetzt konkreter für die Softwareentwicklung. Wie nun offensichtlich sein sollte, ist Softwareentwicklung Lernen. Der Stellvertreter lernt vom Kunden, der Softwareentwickler lernt vom Stellvertreter des Kunden, die Software “lernt” vom Entwickler. Mindestens drei Dialoge müssen also geführt werden, denn – darin sind sich wohl alle einige – Anforderungen sind keine trivialen Daten.

An den drei Dialogen gehts nichts vorbei. Die Frage ist allerdings, wie sie geführt werden sollten? Sequenziell…

…oder parallel/verschränkt:

Die Antwort sollte auf der Hand liegen: Sequenziell kommuniziert liegt eine erste Version der angeforderten Maschine nach 12 Kommunikationsschritten vor; mit verschränkten Dialogen steht eine erste Version jedoch schon nach 8 Kommunikationsschritten bereit.

Als mehrstufige Wissensvermittlung sollte Softwareentwicklung auf keiner Stufe glauben, bei endgültigem Verständnis angekommen zu sein. Deshalb ist ein Vorgehen, das erst eine Stufe abschließt, um dann die nächste zu beginnen, kontraproduktiv. Missverständnisse kann es in allen Kommunikationsphasen geben. Vielmehr ist ein zügiges Fortschreiten von der Idee zu ihrer Manifestation in einer Maschine anzustreben, um dem Ideal der Selbstentwicklung durch den Kunden (s.o.) möglichst nahe zu kommen.

Der Lernprozess ist nämlich noch unvollständig dargestellt. Die Herstellung der Maschine Software ist nicht schon abgeschlossen, wenn der Entwickler meint, den Dialog mit ihr beenden zu können. Softwareentwicklung ist vielmehr – da geht sie über das übliche Lernen hinaus – ein rekursiv gekoppelter Prozess.

Lernen ist bei allem Dialog nur als Einbahnstraße gedacht: Wissen wird vom Wissenden zum Unwissenden übertragen. Was der dann damit macht, ist dem Wissenden recht egal. Der Lehrer soll nur sicherstellen, dass die Übertragung verlust- und fehlerfrei ist.

Das ist anders bei der Softwareentwicklung. Da will der Wissende/Kunde hinterher mit dem Ergebnis der Übertragung, dem manifestierten Wissen, den Maschine gewordenen Anforderungen etwas anfangen. Deshalb kann der Kunde sich nicht darauf verlassen, dass die oben gezeigte Dialogkaskade – ob sequenziell oder verschränkt – bei genügend Mühe verlust- und fehlerfrei ist. Nein, der Kunde muss das Endergebnis auch noch selbst prüfen. Auch er muss mit der Maschine einen direkten Dialog führen.

Und dieser notwendige Dialog des Kunden mit der Software führt dann zu einer nächsten Lernkaskade. Beim üblichen Lernen steht der Lehrer nur am Anfang, seine Aufgabe ist das Senden (und die Überprüfung, ob der Empfang ausreichend ist). Bei der Softwareentwicklung steht der Lehrer/Kunde jedoch am Anfang und am Ende. Er ist gleichzeitig Sender und ultimativer Empfänger.

Das ist aber nicht insofern etwas Besonderes, als dass die Kommunikation grundsätzlich so schwierig ist vom Sender bis zum Produkt/zur Maschine. Das ist auch in anderen Situationen so. Wahrhaft besonders ist die Situation, weil die zu übermittelnden Daten so kompliziert sind.

Man mag es kaum glauben, aber es ist nicht zu leugnen:

• Kunden kennen nicht einmal die funktionalen Regeln der Maschine vollständig, die sie in Auftrag geben.
• Kunden kennen die Eingabemenge der Maschine nicht vollständig.
• Kunden kennen die Ausgabemenge der Maschine nicht vollständig.

Das bedeutet für die Kette von Lernprozessen, aus denen die Softwareentwicklung besteht: Keine Stufe kann je sicher sein, dass sie das, was “eigentlich” gewollt ist, verstanden hat. Selbst nach einem Dialog mit seinem Sender hat der Empfänger kein wirklich, wirklich verlässliches Wissen. Kein Empfänger kann es haben, weil der ursprüngliche Sender, der Kunde, es nicht einmal hat.

Das liegt nicht an der Dummheit des Kunden, sondern an der Komplexität der Materie. Softwaremaschinen sind zum einen komplizierter als die meisten Hardwaremaschinene, zum anderen ist ihnen aber auch etwas anderes enkodiert. Softwaremaschinen sind geronnene Geschäftsprozesse und keine Materialtransformatoren. Und da Geschäftsprozesse auch ohne Computer viel schwerer greifbar sind als die Produktion von Wurst, Schuhen oder auch Häusern – schon weil Geschäftsprozesse die enthalten, also umfassender sind –, ist das Wissen des Kunden über sich notwendig lückenhaft.

Es geht also nicht ohne dass der Kunde selbst in Dialog tritt mit der Softwaremaschine, um erstens festzustellen, ob die Wissensvermittlung und Manifestation geklappt hat, und zweitens, um seine eigenen Vorstellungen in der Maschine reflektiert zu sehen. Erst durch den Dialog mit der Maschine kann der Kunde sich selbst und seine Wünsche verstehen. Software ist ein Spiegel; in ihm sieht der Kunde ein gnadenloses Abbild seines Selbstverständnisses bzw. seines Domänenverständnisses.

Softwareentwicklung arbeitet an der Grenze des explizit für den Kunden wissbaren. Die Wissensübertragung ist schwierig, weil Enkodieren und Dekodieren über mehrere Studen immer schwierig ist, aber insbesondere das ursprüngliche Wissen unvollständig ist. Deshalb muss die Softwareentwicklung dem Kunden schnell und häufig den Spiegel des aktuellen Softwarestandes vorhalten. Nur so kann der Kunde über sein eigenes vermeintliches Wissen reflektieren.

Prüfsummen für die Softwareentwicklung

Lehrer mögen es, wenn Schüler ihre Lernerfolge selbst kontrollieren können. Dann haben sie weniger Arbeit. Weniger Interaktionen im Dialog sind nötig. Und überhaupt mögen Sender Rückfragen nicht. Deshalb liegen Datenpaketen Prüfsummen bei.

Um in der Softwareentwicklung die notwendigen Dialoge zumindest so kurz wie möglich zu halten, wäre es also nützlich, auch hier Prüfsummen zu haben. Was sind aber Prüfsummen für die funktionalen Regelwerke, die Kunden in Software gegossen haben wollen?

Eingabe-Ausgabe-Paare sind solche Prüfsummen.

Die vornehmste Aufgabe jedes Empfängers von Anforderungen in der Kommunikationskette der Softwareentwicklung ist es daher, beispielhafte Ein- und Ausgaben zu sammeln. Sie sind wichtiger als das Regelwerk der Maschine, da dies ohnehin sehr wahrscheinlich Lückenhaft ist oder im Extremfall gar nicht vorliegt. Die letzte Wahrheit liegt daher immer bei gegebenen Eingaben mit zugehörigen Ausgaben, d.h. Akzeptanztestdaten. Ihnen muss die Aufmerksamkeit bei der Anforderungserhebung zuvörderst gelten.

Liegen Akzeptanztestdaten vor – je mehr desto besser –, kann ein Empfänger selbstständig prüfen, ob sein Verständnis des Maschinenregelwerks korrekt ist. Das senkt die Notwendigkeit für Interaktionen mit dem Sender.

Eine Maschinenbeschreibung sollte daher nicht nur ein Tripel sein – {Funktionale Regeln R, Eingabemengenbeschreibung E, Ausgabemengenbeschreibung A} –, sondern mindestens ein Quadrupel: {R, E, A, ea} – mit ea als Menge von Paaren von Elementen aus E mit zugehörigem Element aus A.

Spätestens der Entwickler sollte keine Anforderung entgegennehmen ohne Akzeptanztestdaten. Das spart Rückfragen bei vorgelagerten Sendern und somit Zeit wie Nerven.

Und auf ein Kunde sollte keine Entwicklung beauftragen, ohne für jede Funktionalität Akzeptanztestdaten zu spezifizieren. Solange die Entwicklung nicht kurz und knapp demonstrieren kann, dass die korrekt transformiert werden, muss dem Kunden die Maschine nicht vorgeführt werden.

Wie die korrekte Transformation demonstriert wird, damit der Kunde frühzeitig in “einen Spiegel blicken kann”, ist eine andere Frage. Jedes Mittel ist dabei recht; auf ein vollständige Software muss nicht gewartet werden. Ein spezieller Prüfstand kann auch ein probates Mittel sein – und sollte vom Kunden nicht abgelehnt werden mit dem Argument, da sei ja noch nicht alles fertig. Bei den Dialogen in der Kommunikationskaskade der Softwareentwicklung geht es um zügige Spiegelung aller möglichen Aspekte der Maschinendefinition im Kopf des Kunden. Komplette Benutzerschnittstellen sind dafür nicht unbedingt nötig.

Zusammenfassung

Softwareentwicklung ist keine Produktion im üblichen Sinn. Sie ist ein Lernprozess, unvollständiges und gar fehlerhaftes Wissen aus dem Kopf des Kunden in eine dennoch korrekte Maschine transferieren soll.

Da der Nürnberger Trichter bisher nicht erfunden wurde, ist Lernen ein mühsames Geschäft. Es bedeutet Dialog um Übertragungsverluste und –fehler bei der Wissensvermittlung zu kompensieren. Das gilt umso mehr, wenn das Lernen über mehrere Stationen erfolgen muss. Zentral für die Softwareentwicklung ist also die Kommunikations-, die Dialogkompetenz.

Eine besondere Herausforderung stellt dabei die mangelnde Qualität des expliziten Wissens im Kundenkopf dar. Spätestens sie zwingt den Prozess in eine ständige Rückkopplungsschleife mit dem Kunden. Je schneller der “anfassen kann”, was aus seinem Wissen gemacht wurde, desto eher kann er beurteilen, ob das, was er meinte zu wissen auch wirklich korrekt war. Unumgänglich ist also eine fortlaufende Prüfung von in Software manifestiertem Verständnis durch den Kunden.

Um sich selbst für die Prüfung zu entlasten, kann und soll der Kunde jedoch möglichst viele Akzeptanztestdaten beibringen. Das Entwicklerteam belästigt ihn mit einer neuen Version der Softwaremaschine nur, wenn es aufgrund dieser Testdaten sicher ist, die Anforderungen korrekt verstanden und umgesetzt zu haben. Daran sollte dem Kunden sehr gelegen sein, so dass er sich auch mit speziellen Prüfständen zufrieden gibt und nicht darauf besteht, Anforderungen nur durch die endgültige Benutzerschnittstelle zu prüfen.

Prüfstände haben den Vorteil, dass sie viel einfacher zu realisieren sind als eine Benutzerschnittstelle und auch für ansonsten “versteckte” Subfunktionalität aufgebaut werden können. Der Kunde kann sich dadurch viel zügiger “einen Spiegel vorhalten”, um sein Verständnis der Domäne zu überprüfen. Dass Kunden solchen “Blick in den Spiegel” scheuen mögen, steht auf einem anderen Blatt und vergrößert die Herausforderung Softwareentwicklung. Softwareentwicklung ist wie ein Therapeut, der mit seinen Fragen nicht an der Oberfläche bleibt, sondern sich auch ins Unterbewusste gräbt. Und wer mag das schon?

Verständnis und Einfühlungsvermögen gehören mithin auch zu den wünschenswerten Kompetenzen eines Softwareentwicklungsteams. Wer therapeutisch arbeitet, sollte sich nicht wie ein Elephant im Porzellanladen benehmen.

Und zuguterletzt: Was für Therapeuten angemessen ist, kann für Softwareteams nicht so falsch sein. Zur Softwareentwicklung gehört also auch die Reflexion, gar Supervision. Sonst ist nicht nur keine Nachhaltigkeit der unvermeidlichen eigenen Veränderung gewährleistet – die ist über Effizienz und Effektivität hinaus aber sehr wichtig für langfristigen Erfolg –, nein, Teams laufen sonst auch Gefahr, sich durch ihre Klienten nachteilig beeinflussen zu lassen. Ohne Reflexion/Supervision können auch “Softwaretherapeutenteams” in die Falle Gegenübertragung oder Neurose tappen. Aber davon ein andermal mehr…

An dieser Stelle sollte nur soviel klar geworden sein: Wasserfall oder nicht ist keine Frage von Weltanschauung, sondern eine Frage der Qualität des expliziten Wissens eines Kunden und der Kommunikationskompetenz aller Beteiligten im Softwareherstellungsprozess.

Da Menschen eine Menge wissen, aber oft sich selbst nicht kennen und dasselbe daher für Unternehmen, die aus Menschen bestehen, anzunehmen ist, sollte die Qualität des expliziten Wissens nicht allzu hoch eingestuft werden. Dasselbe gilt für die Kommunikationsfähigkeit vom Benutzer beim Kunden über einen ProductOwner bis zum Entwickler. Durchschnittlichkeit zu erwarten, scheint das Maximum. Und deshalb sind Wasserfall oder andere Vorgehensmodelle, die eher unidirektional sind und/oder viele Sender-Empfänger-Stufen bis zur Software haben, ungeeignet für die Softwareentwicklung.