Follow my new blog

Freitag, 1. Februar 2013

Softwareentwurf in der hohlen Hand

Gerade komme ich wieder von drei Trainingstagen zum Thema agiler Softwareentwurf. Ein inhouse Training für ehemalige C bzw. C++ Entwickler, die sich noch an .NET gewöhnen müssen. Aber es hat vielleicht gerade deshalb besonders Spaß gemacht, weil sie noch nicht so “objektorientiert verdorben” sind. Ihnen steckt vor allem die C-Praxis in den Knochen, die sie anscheinend offen für den Softwareentwurf mit Softwareuniversum und Flow-Design gemacht hat. Denn wenn die prozedurale Programmierung in einem Recht hatte, dann darin, dass es zuerst und vor allem um Funktionalität und nicht um Daten geht.

Aber von dem positiven Feedback, das Stefan Lieser und ich dort bekommen haben, wollte ich gar nicht sprechen. Die gute Stimmung bei den Trainingsteilnehmern hat vielmehr mich selbst nochmal unseren Ansatz frisch erleben lassen.

Abends saß ich nämlich im Hotel bei einem gemütlichen Kaminfeuerchen und habe an einer Anwendungsidee herumgebastelt. Eine Web-Anwendung, die helfen soll, eine Klippe des Kennenlernens über online Partnerbörsen zu umschiffen. Wie das gehen soll wird die dotnetpro demnächst berichten ;-) Technologisch mit von der Partie werden jedenfalls AppHarbor, Nancy und iron.io sein.

Da saß ich also und habe darüber nachgedacht, wie die Idee in Software funktionieren könnte. Welche Seiten sollte so ein Website haben? Wie sollten die Seitenübergänge sein? Was sollte dabei passieren? Welche Klassen/Komponenten sollte es geben? Wie würden Feature ineinander greifen?

Im Kopf kann ich so etwas bewegen – aber nur bis zu einer gewissen Grenze. Dann muss ich einen Dump machen. Irgendwie muss ich meine Gedanken und Ergebnisse manifestieren. Visual Studio hatte ich vor dem Kamin aber nicht zur Hand. Warum auch? Ich brauche keinen Code, um Software zu entwerfen.

So hat mir denn ein kleiner Notizblock des Hotels geholfen. Der war nur handtellergroß mit schmalen Blättern. Aber er hat mir gereicht wie diese Bilder zeigen:

image

image

Wenn Sie nicht wissen, was die Symbole bedeuten und meine Schrift nicht lesen können, macht das nichts. Ich will Ihnen ja nicht erklären, was die Anwendung tut und wie ich gedenke, das zu realisieren.

An dieser Stelle soll nur rüberkommen, dass ich mit zwei kleinen Zetteln die Software entwerfen konnte. Ich weiß nun, welche Klassen ist brauche. Ich weiß, welche Methoden die haben. Ich weiß, wie alles zusammenhängt und die Funktionalität herstellt. Ich weiß, welche Daten fließen. Ich weiß, wie ich APIs kapseln muss. Ich weiß sogar schon, wie ein guter Teil des Codes aussehen muss.

Den Entwurf der beiden Bilder kann ich “so runtercodieren”. Da ist alles drin, was ich brauche. Nur das Layout der Seiten fehlt. Aber das gehört ja auch nicht zum funktionalen Entwurf. Wichtig ist dafür nur, welche Interaktionen der Benutzer mit Dialogen hat. Und die stecken in dem Modell drin.

Durch das Training geöffnet habe ich frisch erlebt, wie effektiv Softwareentwurf mit Papier und Stift sein kann – wenn man eine geeignete Methode hat ;-) Ich muss nicht darauf warten, dass Softwarestrukturen durch Tests wachsen. Ich brauche keine IDE, um bei einer Anwendung voran zu kommen.

Klar, am Ende muss implementiert werden. Bubbles don´t crash. Ich weiß nicht, ob mein Entwurf 100% korrekt/ausreichend ist. Aber ich bin ein gutes Stück voran gekommen. Ich habe mit “systematischer Kritzelei” das Codieren solide vorbereitet. Wenn ich dann Details mit TDD austreiben will, weiß ich, wo ich ansetzen kann.

Und all das steckt in zwei Blättchen mit Flow-Designs. Das fand selbst ich, der ich täglich mit Flow-Design arbeite, irgendwie bemerkenswert cool.

Kommentare:

Andreas Richter hat gesagt…

Good old paper.
Es sind oftmals die einfachen Dinge, auf die man lange Zeit hinarbeiten muss.

Beim betrachten der Fotos bin ich im übrigen sehr froh, dass Stefan Lieser im letzten Video den Part am SMART-Board übernommen hat :)

Christian Götz hat gesagt…

Eine Web-Anwendung, die helfen soll, eine Klippe des Kennenlernens über online Partnerbörsen zu umschiffen.

Also da bin ich, als Single, ja ganz Ohr!
Ich hoffe, dass du die Idee dahinter auch noch auf deinem Blog besprichst und es nicht nur exklusiv für die DotNet Pro reserviert ist. :-)

Ralf Westphal - One Man Think Tank hat gesagt…

Die Idee ist ja nicht geheim. Und sie ist ganz einfach:

Wenn man sich denn per Dating Platform zu einem Date verabredet hat, sitzt am Ende des Date da und muss sich gegenseitig sagen, wie man es gefunden hat. Das fällt nicht jedem leicht.

Wenn man sagt, "Es war klasse!" und der andere findet das nicht so, dann ärgert man sich womöglich, sich so aus dem Fenster gelehnt zu haben. Also mauert man vielleicht lieber. Das ist aber nicht ganz ehrlich und führt zu Anspannung.

Oder man bekommt zu hören, es war klasse, wollte aber sagen, "Ich möchte dich nicht wiedersehen". Dann kann es sein, dass man auch keine ganz ehrliche Meinung äußert.

Mit einem "Treuhandservice" für die Stimmungsäußerung wird das alles viel einfacher :-) Beide Date Partner geben dann darüber ihre Meinung ab und die wird beiden gegenseitig erst sichtbar gemacht, wenn beide auch "gevotet" haben.

Heute haben ja alle ein Smartphone beim Date dabei. Also sagt man am Ende, "Lass uns jetzt mal voten..." :-) Und dann sagt jeder ehrlich, was er meint. Das nimmt dann auch unangenehme Emotionalität aus der Situation. Naja, so die Theorie zumindest.

War halt ne Idee für ne kleine Web-App, an der ich mal ein paar Cloud-Dienste vorstellen kann.

Andreas Richter hat gesagt…

@Ralf: Klingt nach Planning Poker :)

stmon hat gesagt…

Mal 'ne blöde Frage:

Werden die Zettel weiter archiviert oder irgendwie (digital) aufbereitet?

Ralf Westphal - One Man Think Tank hat gesagt…

@stmon: Die Zettel werden natürlich nicht archiviert, aber Fotos von den Zetteln - wenn es denn die Entwürfe sind, die implementiert werden. Vorstadien sind nicht nötig, es sei denn, dass die Entwicklung der Erkenntnis zu dokumentieren nützlich ist.

Die digitale Aufbereitung besteht in der Codierung :-)

Aber was ich eher nicht rate ist, solche handschriftlichen Entwürfe (auch wenn gemeinsam am Flipchart gemacht), in Visio oder so reinzuzeichnen. Damit werden sie starr und bekommen eine Autorität, die ihnen nicht zusteht.

stmon hat gesagt…

@Ralph: Ok... war auch so meine Einschätzung bzgl. der "Archivierung" :)

Aber was ich eher nicht rate ist, solche handschriftlichen Entwürfe (auch wenn gemeinsam am Flipchart gemacht), in Visio oder so reinzuzeichnen. Damit werden sie starr und bekommen eine Autorität, die ihnen nicht zusteht.

Mhm... hört sich fast an wie ein Anti-Pattern ;)

Diese Erfahrung habe ich schon öfters machen dürfen, dass solche Entwürfe als "einzig wahre Wahrheit" angenommen wurden.

"An Worte läßt sich trefflich glauben..."

Denis hat gesagt…

Bzgl. der "objekt-orientierten Verdorbenheit" habe ich ähnliche Erfanrungen gemacht. Firmware-Entwickler, die vorrangig in C programmieren, ist Flow-Design sehr viel einfacher rüberzubringen, als z.B. Java-Entwicklern. Hier war auch die Metapher des elektronischen Bauteils und des Designs von elektronischen Boards, das Du ganz am Anfang mal verwendet hast, sehr hilfreich. Ich halte das auch immer noch für einen guten Einstieg ins Flow-Design, wenn man die Parallelen zum Design von elektronischen Boards aufzeigt.