Fragen? Antworten! Siehe auch: Alternativlos
Wir brauchen glaube ich mal einen Steelman-Vortrag zum Wasserfall. Ein Vortrag, der dem Publikum ernsthaft zu verkaufen versucht, wieso man das machen sollte.
Ich finde das ja generell sehr abstoßend, wenn Leute alle performativ gegen irgendwas sind, weil alle anderen auch dagegen sind. Am besten etwas, das jahrzehntelang Stand der Technik war, und von den erfolgreichsten Organisationen seiner Zeit verwendet wurde. Eine Methode, ohne die wir keine Mondlandung und keine Computer hätten.
Ich verstehe ja, dass die Entwickler das alle unsexy finden. Das Modell hätte auch versagt, wenn das nicht so wäre. Denn das Wasserfallmodell kommt halt aus dem Management und versucht, Entwickler möglichst austauschbar (und billig!) zu halten. Wasserfall versucht das Fordsche Fließband-Konzept auf Softwareentwicklung anzuwenden.
Die Entwickler sollen möglichst wenig Verantwortung übergeben kriegen, und bitte keine Entscheidungen treffen, die sich später rächen können. KLAR finde ich als Entwickler das scheiße! Ich möchte gerne eine Schneeflocke sein, einzigartig und wertgeschätzt für meine großartigen Fähigkeiten.
Wir sind ja inzwischen sogar noch viel weiter. Softwareentwickler nehmen die Situation regelmäßig so wahr, dass sie nach einem Software-Projekt mehr Domain Knowledge haben als der Kunde, für den sie die Software schreiben!
Softwareentwickler halten sich genau so gerne für Gott wie andere Diziplinen!
Für den Kunden (und für die Firma, die mich angestellt hat!) ist es aber besser, wenn der Entwickler ein Rädchen im Getriebe ist, dessen Fähigkeiten sich darauf beschränken, sich zu drehen. Und zwar so schnell und in die Richtung, die vom Domain Expert vorgegeben wird. Das war damals eine separate Berufsbezeichnung, nannte sich Softwarearchitekt. Heute ist Softwarearchitekt bloß ein Pay Grade in vielen Firmen, wo man halt nach soundsovielen Jahren hinbefördert wird als Entwickler.
Genau wie wir mit Devops die Ops-Leute abgeschafft haben, und mit DevSecOps die Security-Leute, und mit Agile die Tester, genau so gab es bei Wasserfall noch Architekten.
Genau wie es sich bei DevOps herausgestellt hat, dass du nicht einfach die Entwickler nebenher Ops machen lassen kannst, und das dann insgesamt billiger wird, genau wie sich bei DevSecOps herausgestellt hat, dass du nicht einfach Entwickler auch Security machen lassen kannst, und dann wird das billiger oder besser, genauso hat sich nach der Wasserfall-Abschaffung herausgestellt, dass nicht jeder "Entwickler" das Zeug zum Softwarearchitekten hat. Aber die Entwicklergehälter sind halt entsprechend hochgegangen, daher ist das heute normal, dann halt auch Architektur zu erwarten von denen.
Typische Ausreden gegen das Wasserfallmodell sind "Wir haben gar keine Domain Experts". Ich halte das für Bias von Entwicklern, die trotzdem das Projekt machen und Geld verdienen wollen. Klar sagen die dann nicht, was sie sagen sollten, nämlich: Dann können wir diese Software nicht seriös anbieten. Die sagen lieber "pass uff, Atze, wir machen das agile. Die Software ist fertig, wenn ihr kein Geld mehr nachschießen könnt. Wenn ihr immer schön mithelft, wird das vielleicht was. Vielleicht auch nicht."
Das sind Zustände wie beim Berliner Großflughafen! Da schäme ich mich für meine Profession, wenn da solche Marktteilnehmer rumlaufen!
Inzwischen hat sich das aber nicht nur durchgesetzt, sondern es hat die Gesamtsituation, dass Software halt nie fertig ist, immer teurer wird, und das Problem nicht löst, so normalisiert, dass die Leute das für normal halten.
Die Leute haben nicht Wasserfall gemacht, weil sie böse Menschen waren, sondern weil das Modell Dinge versprochen (und zumindest teilweise eingelöst!) hat, die attraktiv waren.
Früher hatte man auch Fachkräftemangel. Die Antwort war: Dann nehmen wir die Leute, die wir kriegen können, für die Architektur und das Pflichtenheft und das Domain Knowledge, und das Eintippen des Codes können halbgeschulte bessere Tippkräfte machen.
Heute haben wir Fachkräftemangel, und die Antwort ist: Wir suchen alle nach "Full Stack Engineers" mit 20 Jahren Kubernetes-Erfahrung, die seit 50 Jahren Java programmieren, aber höchstens 25 Jahre alt sind.
Klar funktioniert das nicht, aber wenigstens machen wir keinen Wasserfall mehr!!1!
Update: Jetzt werde ich gerade unsicher, ob ich Wasserfall vielleicht falsch verstanden habe. Ein Leser meint (mit Verweis auf Wikipedia), dass es da keine Iterationen gibt. Gibt es natürlich trotzdem, auch wenn du die dann "Folgeprojekt" nennst. Den Einwand wische ich also mal eben zur Seite *hust*
Heutzutage geht das schon als Wasserfall durch, wenn du vor dem Loshacken ein Pflichtenheft gemacht hast.
Das Originalpaper von WW Royce aus dem Jahre 1970 ist übrigens ganz witzig. Mit so Krachern wie
Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay for them, and development personnel would rather not implement them. The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.
Wasserfall war also ursprünglich nicht "so müsst ihr das machen" sondern eher "diese Schritte sind auch noch nötig, sonst wird das nichts". Überhaupt kommt viel der Dogmatik in der Computerei aus neuerer Zeit. Früher war man da deutlich experimentierfreudiger. Deshalb haben die Leute damals ja auch Dinge hingekriegt, während wir heute hauptsächlich heiße Luft und kaputte Software produzieren und nach "KI" schreien, um uns zu retten.
Royce nimmt die Kritik sogar teilweise selbst vorweg, indem er schreibt, dass das Testen erst nach der Implementation eigentlich zu spät ist und ein teures Redesign nach sich ziehen kann. Nicht nur das: Royces Modell sah Feedback entgegen der "Flussrichtung" des Wasserfalls vor (Figure 4), sowie Prototyping, im Gegensatz zum Vorgängermodell von Benington, das da starrer war.
Hier ist noch ein wunderbarer Abschnitt:
At this point it is appropriate to raise the issue of - "how much documentation?" My own view is "quite a lot;" certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements.
Das ist kaum der verstaubte Antichrist der Softwareentwicklung, den die Agile-Leute da als Strohmann verbrennen.
After documentation, the second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned
Von wegen keine Iterationen!
For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer i n a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.
Von wegen "der Kunde wird nicht involviert". Wikipedia liegt falsch und die Agile-Leute sind Lügner.