Endlich die Antwort auf die Frage, wie viel Entwurf einer Implementierung vorausgehen sollte.
Immer wieder wird darüber ja gerätselt. Seit agile Softwareentwicklung aufgekommen ist, herrscht Unsicherheit. Ein “Big Design Up-Front” (BDUF) ist zu vermeiden. Heißt das jedoch, dass gar nicht mehr entworfen werden soll? [1]
Wie ist dieses Dilemma aufzulösen?
Ich versuche es mal mit einer Analogie:
Mit dem Entwurf ist es wie mit der Gesunderhaltung: Wenn man nicht aufpasst, dann gibt es kein Halten.
Wann haben Sie genug für Ihre Gesundheit getan? Schon genug Sport getrieben? Schon genügend Vorsorgeuntersuchungen machen lassen? Schon genügend Blicke in den Körper werfen lassen mit Ultraschall, CT usw.? Schon genügend Blutanalysen machen lassen? Schon ausreichend auf die Ernährung geachtet? Und wie ist’s mit der spirituellen Seite der Gesundheit?
Es ist ein Fass ohne Boden, was man alles für die Gesundheit tun kann. (Nicht umsonst gibt es eine wachsende Gesundheitsindustrie.) Also müssen Sie Ihren Aufwand bewusst begrenzen. Sie können nicht den ganzen Tag darauf verwenden.
Aber es wäre auch falsch zu sagen, dass Sie nichts dafür tun müssten, weil sich alles von allein ergibt. Ich hoffe, da sind wir uns einig.
Das bedeutet, Sie tun am besten täglich ein bisschen. Vielleicht sind das nur 15-30 Minuten “Fitnesstraining” irgendeiner Art. Schon ein regelmäßiger forscher Spaziergang soll ja Wunder wirken. Dazu ein bisschen Obacht bei der Ernährung. Und dann noch alle Jahre wieder ein paar Vorsorgeuntersuchungen. Plus etwas Meditation zwischendurch.
Was bedeutet das für den Entwurf in der Softwareentwicklung?
- Entwerfen Sie regelmäßig
- Entwerfen Sie in einer Timebox
In der Regelmäßigkeit steckt die Wiederholung. Es gibt also keinen einmaligen Entwurf, der alles vorherbestimmt. Entwerfen ist vielmehr eine kontinuierliche Aufgabe wie Codieren. Bei neuen Erkenntnissen, muss auch neu entworfen werden (bzw. der bisherige Entwurf überprüft werden).
Und in der Timebox steckt die Begrenzung, damit Entwurf kein schwarzes Ressourcenloch wird. Es stimmt ja: Bubbles don´t crash. Und mit einem Entwurf ist noch kein Kunde glücklich gemacht worden. Deshalb muss das Entwerfen immer wieder ein Ende haben, um es in auslieferbaren und nützlichen Code zu überführen, zu dem der Kunde Feedback gibt – das wiederum Einfluss auf den Entwurf haben kann.
Ist Ihnen das genug Empfehlung zur Menge des Entwurfs bei der Softwareentwicklung?
Wenn nicht, dann hier konkrete Zahlen. Die werden Sie natürlich provozieren. Die meine ich auch nicht so, dass sie für alle Softwareprojekte heute und in Zukunft gelten. Natürlich nicht. Aber ich meine sie trotzdem ernst, sozusagen als Tendenz und Denkanstoß:
- Entwerfen Sie am Anfang eines Projektes max. 2 Tage.
- Entwerfen Sie anschließend jede Woche max. 4 Stunden.
- Entwerfen Sie außerdem jeden Tag max. 2 Stunden.
Und das jeweils im Team.
Wie klingt das? Konkret, oder? Und nicht gerade BDUF. Sondern agil, weil kontinuierlich. Außerdem steckt da Kommunikation drin, weil das Team zusammen entwirft (Collective Design Ownership). Und es wird Architekturbewusstsein verkörpert.
Sie sehen, die Antwort auf die immer wieder gestellte Frage ist eigentlich ganz einfach. Wieviel Entwurf ist nötig? Im Schnitt sind es ca. 2-3 Stunden pro Tag. That´s it. Nicht die schiere Menge Entwurf ist wichtig, sondern die Regelmäßigkeit.
Fragt sich jetzt nur, was man während dieser Zeit tut? Aber das ist ein Thema für ein anderes Mal.
Fußnoten
[1] Was Entwurf nun genau ist im Vergleich zum Codieren, lasse ich mal dahingestellt. Soviel sollte aber klar sein, dass beim Entwurf eben kein Code geschrieben wird. Das heißt nicht nur, dass die Programmiersprache dabei keine Rolle spielt, sondern auch, dass das Abstraktionsniveau über der Programmiersprache liegt. Flow-Charts und Structogramme sind für mich daher eher keine Entwurfsmittel, sondern nur graphische Programmiersprachen.
