Рет қаралды 1,355
Lego-Experiment zu inkrementellem Design:
Auf der JAX 2009 haben wir um eine Ritterburg gebeten - jeder durfte ganz nach belieben Steine versetzen oder hinzufügen.
Doch wünscht sich der König jeden Tag etwas anderes, und so heißt die Devise: Inspect & Adapt!
Was genau war das Lego-Experiment?
Wir wollten wissen, was dabei herauskommt, wenn man Softwareentwickler und Projektleiter dazu einlädt, gemeinsam inkrementell eine Ritterburg aus Lego zu bauen. Also haben wir allen 1.700 Teilnehmern der JAX 2009 einen Legostein in ihre Konferenztasche gelegt und sie dazu eingeladen, zu uns an den Stand zu kommen.
Die Regeln waren bewusst einfach gehalten: Jeder Teilnehmer hatte genau 30 Sekunden lang Zeit (Timebox) und durfte in dieser Zeit so viele Steine aus unserer Legokiste verbauen, wie er wollte. Er durfte auch bereits gesetzte Steine umsetzen (also kleine Refactorings durchführen). Nach jeder Timebox haben wir ein Foto gemacht, um die Veränderung zu dokumentieren.
Tag 1: Ohne großen Vorlauf soll es losgehen. Deshalb gibt es nur eine einzige, allgemeine Vorgabe: es soll eine Ritterbug entstehen.
Tag 2: Die wichtigste Erkenntnis vom Vortag lautet: Ganz ohne Designvorgaben geht es offensichtlich nicht! Wir bekommen zwar wahnsinnig schnell erste Ergebnisse, aber nichts wird wirklich zu Ende gebaut. Und die Vorstellungen, wie genau eine Ritterburg auszusehen hat, gehen auch recht weit auseinander. Die Burg hat zwar schon erste Zinnen und einen Balkon, aber die Mauern sind noch nicht mal fertig!
Also legen wir (gemeinsam mit dem König) in einer Quick Design Session die wichtigsten Anforderungen an die Burg fest und lassen den König priorisieren. Als erstes müssen die Mauern fertig werden, denn der König will nicht frieren. Danach soll die Burg ein Fenster, ein Tor, einen Turm, einen Balkon und Zinnen bekommen.
Tag 3: Na bitte! Nach dem zweiten Tag sieht unser Bauwerk eindeutig wie eine Ritterburg aus. Nun fehlt nur noch das richtige "Look and Feel". Also wird zum Schluss noch ein kleiner Park mit einer Rasenfläche, Bänken und Tischen sowie einem Springbrunnen gebaut. Und dann kann der König auch schon einziehen.
Nun ist ein Softwareprojekt natürlich etwas anderes als eine Ritterburg aus Lego. Aber einige Ähnlichkeiten ließen sich doch erkennen. Beispielsweise bringt es offensichtlich viel mehr Spaß, neue Steine zu setzen, als bereits vorhandene Steine umzusetzen (also Refactorings durchzuführen). Dass dann die Fehler vom Anfang umso schwerer zu beheben sind, je länger man sich Zeit damit lässt, ist offensichtlich. Und noch ein weiterer wichtiger Punkt ist deutlich geworden, der den Kern agiler Softwareentwicklung ausmacht: Die wichtigsten Features müssen zuerst fertig gestellt werden, unabhängig davon, was später eventuell noch kommen könnte. Und man muss sich so oft wie möglich Feedback darüber verschaffen, ob man nicht an den Anforderungen vorbei entwickelt. Natürlich wäre es schön gewesen, wenn unsere Burg noch einen zweiten Turm gehabt hätte. Aber dazu hatten wir weder genug Zeit noch ausreichend Steine. Hätte man also von Anfang an zwei Türmen gleichzeitig gebaut, wäre letztlich gar nichts wirklich fertig geworden!