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 bzw. der bisherige Entwurf überprüft und angepasst 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.
7 Kommentare:
4h pro woche klingt relativ wenig - 2h am Tag allerdings relativ viel. Sind die 2h am Tag in den 4h pro Woche enthalten?
@Frank: Wenn du Montag 4 Std entwirfst, sind darin die 2 Std für den Tag schon enthalten :-) Aber Di bis Fr sollen es auch wieder je 2 Std sein.
Das hört sich viel an? Ja, zunächst scheint das viel - wenn man sonst eher nicht entwirft, sondern codiert.
Am Ende ist es aber nicht viel, sondern das Nötigste, um den Entwurf konstant Raum zu geben.
Für "Entwurfsanfänger" ist das erstmal meine Regel. Wer denn Erfahrung aufbaut, der kann und soll natürlich die Regel transzendieren.
Ich halte es jedoch für falsch, am Anfang schon verhandeln zu wollen. Wie man auch bei Scrum oder sonstiger Methode dazu tendiert, zu verhandeln. "Müssen wir das genau so machen?" Ja, am Anfang soll man es genau so machen. So wie ein Anfänger beim Autofahren alles erstmal genauso machen soll wie vom Fahrlehrer gesagt. Dennoch ist allen klar, dass das nach 10 Jahren Fahrpraxis anders aussieht.
Mir gehts auch nicht um genau 4 oder 2 Std, sondern um die Richtung. Angemessen und regelmäßig soll der Entwurf sein.
Weil jeder Anfänger einer Disziplin jedoch schlecht in der Beurteilung der Angemessenheit ist, sind Richtwerte wichtig, um mal loszulegen. Die habe ich aus meinem Verständnis eines Vorgehens bei der Softwareentwicklung gegeben.
@Frank,
mal ganz volkstümlich: 2 oder 4 Stunden in welchen Zeitrahmen auch immer sind ok, wenn es sich "richtig" anfühlt. Man kann das ja auch über die Zeit variieren.
Wenn man jetzt schon beim Schätzen der Zeit, die man für den Entwurf braucht, bürokratisch vorgeht ... wollen wir einen gutes Ergebnis , das uns weiterbringt, oder wollen wir nur stupide 2 Stunden pro Woche abrechnen?
Form follows function ...
Wie Kann man sich so eine Entwurfs Session vorstellen?
Auf Papier whiteboard oder im Code?
Wird das Geschriebene festgehalten?
LG
Für mich ich eine Entwurfssession informell.
Sie hat natürlich ein Ziel. Ein Entwurf für eine konkrete Anforderung ist anzufertigen. Wenn sich herausstellt, dass die Anforderung noch unklar ist, dann mit dem Entwurf aufhören.
Wenn aber die Anforderung klar ist, dann möglichst "ungehemmt" kommunizieren im Team. Es gibt keinen Chefentwerfen. Jedenfalls keinen offiziellen. Jeder kann und soll etwas beitragen. Allerdings gibt es immer wieder unterschiedlich interessierte Entwickler. Das ist ok.
Die Diskussion des Teams wird in Bildern festgehalten, gelegentlich in Worten. Jedenfalls muss es "anfassbare" Resultate geben. Nur reden ist zuwenig. Das wird häufig unterschätzt. "Wir haben doch aber 2 Std entworfen." "Und wo ist das Ergebnis, wo sind die Diagramme?" "Wir haben das alle verstanden und im Kopf!" Nein, so geht es nicht.
Aber Achtung: Diagramme sollen nicht ordentlich sein, nicht mit dem Lineal gezogen. Schon gar nicht mit einem Supertool. Vergiss Visio o.ä. In der Entwurfssitzung steht man am Whiteboard oder Smartboard oder Flipchart.
Die Ergebnissicherung kann dann mit einer Digicam erfolgen. Und ab mit den Bildern ins Coderepository.
Diagramme, die man nicht in wenigen Minuten reproduzieren kann, sind übrigens zu kompliziert. Jedes Diagramm muss weggeschmissen und neu gemacht werden können, wenn sich Änderungen ergeben.
Komm gern zum nächsten Seminar "Agile Architektur", da zeigen wir, wie es geht: http://bit.ly/PpvlWY Morgen beginnt auch eines, aber das ist dir sicher zu kurzfristig :-)
Was bedeutet das für den Entwurf in der Softwareentwicklung?
* Entwerfen Sie regelmäßig
* Entwerfen Sie in einer Timebox
Schön gesagt.
Verdammt... Return erwischt... war nicht fertig.
Manchmal hab' ich das Gefühl, dass über das "Müssen wir das genau so machen?" nicht hinauskommt, und bei "Das haben wir schon immer so gemacht!" hängenbleibt (http://www.infoq.com/presentations/2nd-gen-lean).
Das ganze mit einer Zeitschiene zu versehen, mag für manchen beruhigend sein, aber es kommt nicht auf die Zeit an, sondern auf die Tätigkeit.
Nicht blind darauf losrennen... es kann dann sein, dass man eine gute Strecke in die falsche Richtung gelaufen ist. Nicht zu lange stehenbleiben... irgendwann schlägt man Wurzeln.
Wir halten regelmäßg an und schauen, ob wir noch in die "richtige" Richtung gehen (manchmal lohnt sich auch die gute Aussicht :)
Kommentar veröffentlichen