Stefan Roock

Neue Blog-Adressen

2009-02-17T20:01:00.002+01:00

Ich bin mit meinem Blog nach Wordpress umgezogen. Die Site-Adresse bleibt bei http://www.stefanroock.de

RSS-Feed findet sich unter: http://stefanroock.wordpress.com/feed/

RSS-Feed für die Kommentare findet sich unter: http://stefanroock.wordpress.com/comments/feed/

Das Commitment des Product Owners

2009-02-16T21:40:00.002+01:00

In Scrum committet sich das Entwicklungsteam auf das Sprintziel. Und der Product Owner? Der committet sich auch auf die Sprint-Planung! Genauso wie das Entwicklungsteam darf er das Ergebnis der Sprint-Planung nur dann akzeptieren, wenn er es für sinnvoll hält. Das bedeutet insbesondere auch: Der Product Onwer committet sich nur dann auf das Ergebnis der Sprint-Planung, wenn aus seiner Sicht die Entwicklungsgeschwindigkeit des Teams zufriedenstellend ist. Wenn der Product Owner meint, die Geschwindigkeit sei zu niedrig und das Projekt nicht ökonomisch sinnvoll durchführbar, muss er sein Commitment verweigern. Das Ergebnis: es gibt kein Commitment und damit keinen nächsten Sprint.
Und dann? Dann spricht man über die Situation: Ist das Team unpassend zusammengesetzt? Fehlt es an Aus-/Weiterbildung? Gibt es ein anderes Team, dass den Anforderungen des Product Owner besser genügen kann? Etc. Und wenn die Antwort immer "Nein" lautet, dann muss sich der Product Owner die Frage stellen, ob sein Projekt überhaupt ökonomisch sinnvoll ist.
Und bei allem sollten wir ganz gelassen bleiben. Wenn der Product Owner sein Commitment nicht geben kann, ist das keine Krise. Es ist das Ende einer Illusion.

Pair-Programming-BOT für TDD

2009-02-05T11:28:00.001+01:00

Sebastian hat dieses Kleinod gefunden: Den virtuellen Pair-Partner. Das ist lustig.

Aber es ist nicht nur lustig. Ich glaube, das Ding kann in der Tat ganz gute Dienste leisten, wenn man TDD erlernen möchte. Dann ist es nämlich tatsächlich sehr nützlich, genauso dogmatisch vorzugehen, wie der BOT das tut.

Ubuntu für No-Details-Charaktere: Schritt 12 (externe Displays)

2009-02-05T09:00:00.004+01:00

Es ist unter Linux bekanntlich ein Horrorthema einen Beamer anzusteuern. Also hatte ich auf der OOP Power-Point unter Windows verwendet. Jetzt sitze ich hier gerade neben einem externen Monitor. Den kann ich doch mal anschließen. Dann drücke ich auf Fn+F7 um die Bildschirmausgabe auf das externe Gerät umzuschalten und siehe da, es klappt. OK, ich muss ein paar mal Fn+F7 drücken, bis das gewünschte Ergebnis da ist, aber sowas passiert mir unter Windows auch gerne mal.
Ubuntu passt die Bildschirmauflösung auf meinem Notebook an das externe Gerät an. So sieht es bei mir auf dem Notebook etwas eigenartig aus, aber auf dem Monitor mit geringerer Maximalauflösung ist alles prächtig. Cool.
Als ich den Monitor wieder abziehe, merkt Ubuntu das aber anscheinend nicht richtig. Auch mehrfaches Fn+F7 bringt mir nicht meine Original-Auflösung zurück. Ich muss als über System->Einstellungen->Bildschirmauflösung die Auflösung wieder hochstellen, aber das ist kein großer Akt.
Jetzt müsste es eigentlich auch auf dem Beamer funktionieren, oder? Das werde ich bei der nächsten Konferenz mal ausprobieren.

Ubuntu für No-Details-Charaktere: Schritt 11 (UMTS-Karte)

2009-02-03T22:15:00.002+01:00

Ich habe für mein Notebook eine UMTS-Karte von Vodafone. Die Installation der zugehörigen Software gestaltete sich unter Windows als ziemlich umständlich. Also hatte ich auch für die Installation unter Ubuntu mit Problemen gerechnet. Und tatsächlich finde ich erst nach einigem Suchen eine Seite, wo man Treiber herunterladen kann. Dort gibt es zwei Versionen, bei denen mir schon nicht klar ist, welche ich nehmen soll. Also lade ich mal beide herunter. Nützen tut das aber wenig. Keine der beiden Versionen lässt sich installieren. Mist.

Also stecke ich die UMTS-Karte rein und starte Windows. Halt, stop. Was ist das? Ubuntu erkennt die Karte von selbst. Ich muss nur den Provider auswählen und ich bin Online. Und dafür mich ich nicht mal die aufdringliche Vodafone-Software ertragen. Wow!

Also immer bedenken: Wenn man irgendein Gerät unter Ubuntu nutzen will, erstmal anschließen und gucken, was passiert.

Pecha Kucha auf der JAX 2009

2009-02-02T10:10:00.001+01:00

Auf der diesjährigen JAX wird es auf dem Agile Day eine Pecha Kucha
Session geben. Pecha Kucha ist eine spezielle Form der Präsentation.
Es werden mehrere Präsentationen verschiedener Autoren zu agilen
Vorgehensweisen in Folge gezeigt. Jede Präsentation besteht aus genau
20 Folien, die jeweils genau 20 Sekunden angezeigt werden.

Dafür suche ich Referenten. Wer Interesse hat (und möglichst sowieso
auf der JAX oder mind. der Gegend ist), möge sich bei mir melden.

Mehr Infos zu Pecha Kucha:

Noch mehr Spaß mit Internationalisierung

2009-02-01T19:58:00.002+01:00

Gerade habe ich versucht, die Webseite der Hertz-Autovermietung zu öffnen. Die war nicht erreichbar - das kann ja mal passieren. Als Meldung habe ich bekommen:


We're sorry bur we are unable to process your request at this time
 A general application failure has been detected.

Bis auf den peinlichen Tippfehler bei "bur/but" scheint mir das OK zu sein. Und freundlicherweise findet sich darunter gleich die deutsche Übersetzung:


   wir sind, die aber traurig sind, wir sind nicht imstande, Ihren Antrag diesmal zu verarbeiten.
 Ein allgemeiner Anwendung Ausfall ist ermittelt worden.

Na, da sind wir aber traurig...

Ich kann nur hoffen, dass diese Übersetzung von einer Maschine stammt...

Wenn einer eine Reise tut...

2009-01-19T20:10:00.001+01:00

Donnerstag musste ich morgens von Berlin nach Mannheim. Ich hatte meinen Flug im Internet mit der Lufthansa gebucht und elektronisches Ticket über Kreditkarte geordert.

Also stecke ich meine Kreditkarte in den Quick-Checkin-Automaten. Dieser begrüßt mich freundlich mit meinem Namen. Ich muss auswählen, ob ich alleine oder in der Gruppe reise. Alleine. Dann muss ich angeben, ob ich nur Handgepäck habe oder Gepäck aufgeben möchte. Nur Handgepäck. Und dann sagt der Automat mir, dass kein Ticket für mich gebucht ist. Sch... Habe ich den Flug für den falschen Tag gebucht? (Und selbst wenn, was ist das für Usability, dass Fragen beantworten muss, die sich am Ende als Unsinnig herausstellen?)

Ich gucke auf die Übersichtsanzeige der Abflüge. Es geht ein Flug nach Mannheim zu der angegebenen Zeit. Aber die Flugnummer ist anders. Oh, oh. Also schnell zum Checkin-Schalten, um das zu klären.

Mit schnell ist aber nichts, weil ich mich erstmal im Flughafen Berlin Tegel verlaufe. Das ist bei so einem kleinen Flughafen schon eine gewisse Kunst. Einige Hinweisschilder sind aber auch echt eigenartig platziert.

Schließĺich finde ich den Checkin-Schalter. Da ist aber niemand. Nanu? Es sind nicht mal mehr 60 Minuten bis zum Abflug. Jetzt gesellen sich andere verwirrte Passagiere dazu. So falsch kann ich also nicht sein. Tatsächlich öffnet der Schalter nach wenigen Minuten, ca. 45 Minuten vor Abflug. Jetzt sehe ich auch, warum ich kein elektronisches Ticket bekommen konnte und warum die Flugnummer abweicht. Der Flug wird nicht von Lufthanse durchgeführt, sondern von Cirrus Airlines. Also liegt das Ticket wohl im System von Cirrus und der Lufthansa-Automat kommt da nicht dran. Da wäre ein Hinweis bei der Buchung und auch am Quick-Checkin-Automaten hilfreich gewesen - soviel Adrenalin am frühen Morgen muss nun wirklich nicht sein.

Tatsächlich bekomme ich am Cirrus-Schalter mein Ticket. Bei der Sicherheitskontrolle falle ich unangenehm auf. In meinem Notebook-Rucksack haben sich soviele Kabel angesammelt, dass er nicht mehr richtig durchleuchtet werden kann. Letztes Mal musste ich daher alle Kabel rausnehmen und den Rucksack nochmal durchleuchten lassen. So leicht komme ich diesmal nicht davon. Ich werde in einen separaten Raum gebeten. Dort wird eine Art Staubsauger mit Filter in alle Rucksack-Fächer gehalten und der Filter anschließend in eine wirklich große Maschine gesteckt. Die sagt erwartungsgemäß, dass ich keine Bomben dabei habe. Hätte sie das auch gesagt, wenn ich Sylvester Böller in dem Rucksack transportiert hätte? Wenn ich mal zuviel Zeit habe, reibe ich mal eine Tasche mit übriggebliebenen Böllern ein und gehe extra früh zur Sicherheitskontrolle...

Danach warte ich noch kurz am Gate und rein geht's in Flugzeug. Naja, erstmal in den Flughafenbus - zusammen mit einem dutzend anderer Leute. Zwei davon stehen im Bus und machen die Business-Kasper - die waren wirklich sehr nah dran am Sketch!

Nach 5 Minuten steigen wir wieder aus- Der Bus hat sich keinen Zentimeter bewegt. Wir werden wieder zurück in die Wartehalle geholt. In Mannheim kann wg. schlechtem Wetter (Nebel und Eisregen) nicht gelandet werden. 45 Minuten nach geplantem Abflug beschließt man: Wir fliegen nach Saarbrücken und fahren dann 90 Minuten mit dem Bus nach Mannheim. Es gäbe auch noch eine geringe Chance, dass wir in Mannheim landen könnten. Aber das würde sich erst kurz vor Mannheim entscheiden.

Einige Passagiere weisen darauf hin, dass bereits Flüge nach Saarbrücken umgeleitet wurden nach Stuttgart, weil der Flughafen auch schlechtes Wetter hätte. Die Cirrus-Frau fragt nochmal nach bei ihren Leuten. Aber es bleibt dabei: Wenn Mannheim nicht geht, nehmen wir Saarbrücken. Also alle wieder rein in den Bus und los geht's.

Das Flugzeug hat gut 30 Sitze, so dass die meisten Sitze frei bleiben. Wir dürfen uns aber nicht in die ersten 5 Reihen setzen, weil dann die Gewichtsverteilung nicht mehr stimmt. Wer hätte gedacht, dass Flugzeuge so anfällig sind.

Während wir auf die Startbahn rollen, hält die Flugbegleiterin ihre obligatorische Rede: "Im Namen des Piloten, des Copiloten und der restlichen Crew - das bin ich - heiße ich Sie herzlich willkommen beim Cirrus-Flug nach Mannheim ... oder Saarbrücken."

Nach dem Start meldet sich der Pilot: "Auch ich möchte Sie herzlich willkommen heißen auf unserem Flug nach Westen. Auf mehr möchte ich mich erstmal nicht festlegen." Um uns etwas Unterhaltung zukommen zu lassen, erzählt er lange Geschichten über die Orte, an denen wir vorbeifliegen. Seine Ausführungen beschließt er mit den Worten: "Und wenn Ihnen jetzt der Sinn nach etwas seichterer Unterhaltung ist, fragen Sie die Stewardess. Die kann klassischen Ausdruckstanz. Die kann sogar ihren Namen tanzen."

Kurz vor Mannheim meldet sich der Pilot: "In Mannheim ist immer noch schlechtes Wetter und wir können dort nicht landen. In Saarbrücken sieht es genauso aus. Und da es egal ist, wo wir nicht landen, fliege ich jetzt einfach mal Schleifen über Mannheim. Vielleicht tut sich ja noch was."

Nach 30 Minuten kommt die Durchsage: "Es wird sich nichts mehr tun. Wir fliegen zurück nach Frankfurt." Das dauert immerhin nur 12 Minuten, aber als wir da sind: "Dass der Himmel heute nicht voller Geigen hängt, haben Sie ja bereits bemerkt. Hier hängt er voller Flugzeuge, so dass wir auch hier ein paar Warterunden drehen werden."

Ich frage mich langsam, wieviel Sprit in so einer Maschine eigentlich drin ist.

Aber letztlich landen wir dann doch. Lufthansa hat einen Bus organisiert, der uns an Ausgang B6 erwartet. Also wir da ankommen, finden wir da zwei Dinge nicht vor: einen Bus und jemand von Lufthansa, der uns Infos gibt. Gut organisiert ist das nicht.
Stehen wir vielleicht am falschen Ausgang? Nach ca. 30 Minuten taucht jemand auf und nimmt uns zum Bus mit. Dort warten wir noch ziemlich lange, weil die Anzahl der Leute im Bus unter der Anzahl der Passagiere im Flugzeug liegt. Vielleicht haben die ein anderes Transportmittel genommen? Irgendwann fährt der Bus aber doch los und es dauert noch eine Stunde, bis wir in Mannheim ankommen sind.

Summa Summarum: Statt einer Stunde dauerte die Reise Berlin->Mannheim 5,5 Stunden (dass der Pilot einen gewissen Unterhaltungswert hatte, entschädigt da wenig). Und da ich meinem Kunden nicht zumuten kann, um 15 Uhr zu kommen und um 17 Uhr wieder zu gehen, harre ich dort bis 18:15 Uhr aus und komme daher erst gegen 1:00 Uhr morgends wieder zu Hause an - für den Rückweg nehme ich die Bahn. Die ist in Relation zum Flugverkehr dann doch verlässlich und auch bequemer.

Perlen der Internationalisierung

2009-01-12T20:24:00.002+01:00

Eine große Internetanwendung hat rechts oben zwei Links stehen: "Einloggen" und "Anmelden". Da kann man schon mal eine Weile drüber nachdenken.

Und ein bekanntes Internetsystem, mit dem man VOIP machen kann, sagt ständig "XYZ kam online". So begeistert sind also die Benutzer dieses Systems...

Ubuntu für No-Details-Charaktere: Schritt 10 (Wine statt Windows)

2009-01-12T16:50:00.001+01:00

Freitag hatte ich jetzt tatsächlich mal eine Situation, in der ich ein Programm benutzen musste, dass es nur unter Windows gibt. Man muss dazu aber Windows gar nicht starten. Man kann viele Windows-Programme mit Hilfe von Wine direkt unter Ubuntu laufen lassen.

Cool!

Ubuntu für No-Details-Charaktere: Schritt 9 (Skype)

2009-01-06T19:44:00.003+01:00

Jetzt kommt Skype dran. Es gibt eine Ubuntu-Version als Debian-Package. Leider steht Skype nur als 32-Bit-Version zur Verfügung und mein 64-Bit-Ubuntu will das nicht installieren.
Es gibt aber eine gute Doku, wie man es trotzdem hinkriegt im deutschsprachigen Ubuntu-Wiki. Soweit läuft auch alles. Aber beim Audio-Testpassiert nichts. Mal in die Skype-Optionen gucken. Und tatsächlich kann man dort zwischen verschiedenen Audio-Treibern wählen, die mir alle nichts sagen. Zum Glück sind es nur drei. Ich probiere einfach alle aus und der letzte (das war ja klar) funktioniert auch.
Jetzt habe ich nur noch das Problem, dass mein Mikro nicht funktioniert. Nach etwas Suchen stelle ich fest, dass in Ubuntu das Mikro ausgeschaltet ist. Das kann man einfach beheben im Ubuntu-Desktop. Hey, was ist das denn? Man kann dort einen Mikro-Boost einstellen. Was der wohl macht? Wenn man ihn zu hoch aufdreht, auf jeden Fall Rückkopplungen :-) Aber wenn man es nur etwas aufdreht, wird die Mikro-Aufnahme lauter. Das ist cool. Wenn ich das Mikro des Notebooks benutzt habe, war das unter Windows eigentlich immer zu leise. Jetzt hört es sich schon viel besser an.

Ubuntu für No-Details-Charaktere: Schritt 8 (DVDs)

2009-01-06T19:27:00.000+01:00

Nachdem ich bereits flackernde Videos beseitigt habe, sollte ich auch kommerzielle DVDs gucken können. Stimmt aber leider nicht. VLC beendet sich beim Versuch, eine DVD abzuspielen, kommentarlos selbst.
Durch Recherchen im Internet finde ich heraus, dass man anscheinend etwas namens libdvdcss2 braucht. Zum Gück ist gut beschrieben, woher man das Ding bekommt und wie man es installiert. Nicht beschrieben ist, dass man VLC danach neu installieren und dann den Rechner neu booten muss. Aber danach funktionieren auch DVDs.

Ubuntu für No-Details-Charaktere: Schritt 7 (Applets)

2009-01-05T13:25:00.002+01:00

Heute wollte ich dann mal gucken, ob Clipboard2Web nach meinem Redeployment auch noch korrekt funktioniert. Dabei habe ich festgestellt, dass im Firefox das Applet nicht funktioniert. Immerhin weiß ich jetzt, dass die Fehlermeldung in Clipboard2Web korrekt angezeigt wird, wenn der Browser keine Applets kann :-)

Aber warum will Firefox nicht? In den Optionen sind Applets aktiviert und eine aktuelle VM habe ich inzwischen ja auch installiert. Recherche im Internet führt mich auf Seiten, die mir Tipps geben, die ich viel zu technisch finde; so nach dem Motto: "Besorge Dir das JDK von SUN und mache ein Debian-Package daraus und benutze dazu Unmengen Kommandozeilentools, die Du noch nie gesehen hast und die teilweise noch gar nicht auf Deinem System installiert sind."

Gibt es das Problem vielleicht nur mit meinem Applet? Ich suche nach anderen Applets im Internet und probiere mal das von Self-Html aus. Das funktioniert auch nicht. Aber jetzt weist Firefox mich darauf hin, dass ihm ein Plugin fehlt und ich das jetzt installieren könnte. Also installiere ich das Plugin (IcedTea) und schon funktionieren auch die Applets.

Ich muss mir mal angucken, wie Self-Html das Applet eingebunden hat. Da muss ja etwas anders sein als bei Clipboard2Web. Schließlich hat mir Firefox bei meinem Applet keinen hilfreichen Hinweis gegeben.

Ubuntu für No-Details-Charaktere: Schritt 6 (Zwischenstand)

2009-01-03T23:02:00.002+01:00

Heute habe ich mal wieder Windows gestartet und dabei auf die Uhr geguckt.

Aktueller Zustand meines Notebooks: Bis zum Login-Screen benötigt Ubuntu 1 Minute und Windows Vista 1 Minute und 30 Sekunden. Da sieht Windows gar nicht so schlecht aus. Aber nach dem Login passiert ja noch etwas, bevor man arbeitsfähig wird. Und da heißt es Hasta la Vista, Windows. Ubuntu braucht nach dem Login noch 30 Sekunden, bis ich arbeitsfähig bin. Windows Vista braucht 8 Minuten und danach rattert immer noch die Festplatte im Hintergrund.

In Summe dauert das Booten mit Ubuntu also 1:30 Minuten und Windows Vista 9:30 Minuten, also über das 6-fache.

Ubuntu für No-Details-Charaktere: Schritt 5 (Entwicklung)

2008-12-30T13:36:00.008+01:00

mor.ph ruft. Dort habe ich Clipboard2Web in einem kostenlosen Paket gehostet. Als Gegenleistung verlangt der Hoster, dass ich meine Anwendung mind. monatlich aktualisiere. Ansonsten wird die Anwendung stillgelegt.
Wenn noch 14 Tage übrig sind, bekommt man eine E-Mail, dass man seine Anwendung mal wieder neu deployen sollte. Jetzt ist es soweit.

Downloads
Dazu muss ich Java und Grails unter Ubuntu installieren. Java lässt sich über die in Ubuntu eingebauten Nachlade-Mechanismen elegant und einfach installieren. Ich muss mir nicht mal Gedanken darüber machen, wohin das Zeug installiert werden soll. Ubuntu kennt den jeweils passenden Ort.

Grails muss ich manuell herunterladen. Glückerlicherweise kann ich das direkt als Debian-Package tun und mit dem Package-Installer auch auf Knopfdruck installieren.

JAVA_HOME
Java ist danach auch sofort einsatzfähig, bei Grails muss ich noch selbst Hand anlegen. Grails beschwert sich nämlich darüber, dass JAVA_HOME nicht gesetzt ist. Das macht der Java-Installer offensichtlich nicht selbst. Ist auch klar, weil es sehr viele Möglichkeiten gibt, wo man JAVA_HOME definieren kann. Ich bin da auch kein Experte und definiere es erstmal in /etc/environment. Das scheint das passende Ort für globales Zeug zu sein.

Grails
Danach lässt sich Grails aus der Kommandozeuge starten. Wenn ich allerdings etwas Produktives mit Grails machen will, funktioniert es nicht. Genaueres Hinsehen verrät, dass Grails als Versionsnummer null angibt. Das ist natürlich nicht OK. Kurze Recherche im Internet ergibt, dass das von mir verwendete Debian-Package korrupt ist. Es ist eine korrigierte Version hier, die aus mir unerfindlichen Gründen nicht über die Grails-Download-Page erreichbar ist.

grails upgrade
Allerdinge habe ich die Version 1.0.4 installiert und meine Anwendung habe ich mit Versionb 1.0.3, gebaut. Also beschwert Grails sich, dass die Versionen nicht zusammenpassen. Aber mit grails upgrade ist das Problem schnell behoben. Schnell noch bestätigen, dass Grails einige Dateien ersetzen darf - business as usual. Denkste! Grails hat mein build.xml überschrieben mit der völlig sinnfreien Vorlage. Argh! Naja, nicht so wild. Mein Original-Build-File habe ich ja in meinem Subversion-Repository. Also muss ich noch schnell meinen Lieblings-Subversion-Client installieren: Eclipse.

Eclipse und dann nochmal
Ecllipse kann ich über die Download-Features von Ubuntu elegant installieren. Als ich auf mein SVN-Repository zugreifen möchte, stelle ich fest, dass von Eclipse leider nicht die aktuellste Version installiert wurde. Also lade ich die manuell von eclipse.org herunter. Durch die vorherige automatischen Installation weiß ich jetzt immerhin, wohin ich Eclipse installieren sollte. Also lösche ich die alte Installation von Hand (rm -r), wechsle ins neue Eclipse-Verzeichnis und starte eclipse. Und belohnt werde ich mit einer Fehlermeldung, dass die Installation nicht korrekt ist. Die jetzt folgende Odysee durch das Internet erspare ich dem Leser lieber. Das Ergebnis wird dadurch nicht weniger peinlich für mich. Die Original-Eclipse-Installation hat in einem bin-Verzeichnis ein Shell-Script namens eclipse angelegt und das aktuelle Verzeichnis befindet sich unter Linux per Default nicht im Path. Also habe ich weiterhin das alte Shell-Skript aufgerufen. Nach Löschen des Shell-Skripts und Aufruf durch ./eclipse startet Eclipse schließlich.

Java-VM
Beim Start-Bildschirm warnt Eclipse mich, dass GCJ als Java-VM konfiguriert ist und Eclipse auf dieser VM nicht getestet wurde. Keine Ahnung, was GCJ ist, aber es wird schon klappen. Leider nicht sehr weit. Sobald ich versuche, das Update-Center in Eclipse zu öffnen, schmiert Eclipse ohne weiteres Feedback ab. java in der Shell zeigt, dass GCJ ein bei Ubuntu mitgeliefertes GNU-Java ist. Ich hatte Java 6 von SUN ja bereits installiert. Also schnell noch das passende bin-Verzeichnis in etc/environment zum PATH hinzugefügt und schon läuft auch das Update-Center wieder.

Subversive
Beim Versuch, Subversive als Subversion-Client in Eclipse zu installieren, fällt mir wieder ein, dass Eclipse mein Lieblings-CVS-Client ist. Daraus gleich zu folgern, dass es auch mein Lieblings-SVN-Client ist, war vielleicht etwas voreilig. Jetzt fällt mir wieder ein, wie grauenvoll die Installation von Subversive ist. Ich gehe auf die Installation-Webseite zu dem Subversive-Plugin. Dort steht Schritt für Schritt, was man tun muss. Leider sehr umständlich. So steht dort z.B. nicht, wie due URL für die Update-Site steht. Stattdessen steht dort die URL eine Webseite, auf der die URL für die Update-Site steht. Also muss man erst auf diese Seite und die URL dort suchen. Umständlich. Und wenn man dann das Plugin installiert hat, läuft es nicht, weil andere Plugins fehlen (Connectors, Integrators, ???). Und die finden sich nochmal auf einer anderen Seite. Viel komplizierter geht es wohl nicht. Am Ende bekomme ich das Zeug doch noch zum Laufen - ich habe einfach pauschal alles installiert, was Subversion im Namen hatte (außer das, was explizit Windows im Namen hat). Endlich kann ich mein altes Build-File aus dem Subversion-Repository restaurieren.

Grails in Eclipse
Jetzt öffne ich ein Grails-Projekt, das ich unter Windows erstellt habe. GRAILS_HOME zeigt auf einen Ort auf der Windows-Partition. Das muss ich in Eclipse umbiegen. Kein Problem, vor allem weil Grails so nett ist, mir beim Starten zu sagen, wo es installiert ist - das hat Java nicht von sich aus getan. Das musste ich erst auf der Platte suchen.

Deploy
Und jetzt kann ich aus Eclipse über das Build-File meine Anwendung neu deployen. Hurra, geschafft.

Fazit
Ich war davon ausgegangen, dass ich mit Ubuntu eher im Bereich Multimedia/Office Probleme bekomme als im Bereich Entwicklung. Aber das war weit gefehlt. Die meisten und schwierigsten Probleme hatte ich im Bereich Entwicklung. Aber sie waren auch noch zu meistern.
Ich werde mir aber mal ernsthaft überlegen, ob ich wirklich Subversion verwenden möchte. Gefühlt hatte ich mit CVS weniger Probleme (nicht nur, was den Client angeht). Oder ich gucke mir gleich mal was Innovativeres an, wie z.B. Bazaar.

Ubuntu für No-Details-Charaktere: Schritt 4 (multimedial)

2008-12-28T21:16:00.002+01:00

Heute wird es multimedial.

Fotos
Zuerst möchte ich meine Fotos auch unter Ubuntu sehen und bearbeiten. Unter Windows habe ich Picasa2 benutzt. Das ist gut und das gibt es auch für Linux. Allerdings bringt Ubuntu bereits F-Spot Fotoverwaltung mit. Das sieht auf den ersten Blick gut genug aus für mich. Ich kann einfach die bisherigen Foto-Ordner importieren. Einfache Bildbearbeitungsfunktionen sind in F-Spot integriert, für alles kompliziertere wird Gimp gestartet. Ich versuche mal mit F-Spot mein Glück. Mal sehen, wie es sich in der Zukunft bewährt,

Importieren der Fotos von der Kamera ist auf jeden Fall genauso einfach wie unter Windows. Kamera mit dem USB-Kabel mit dem Rechner verbinden und schon kann ich die Bilder auf Tastendruck importieren.

Musik
Bei Musik ist es das gleiche Spiel. iTunes gibt es auch für Linux. Bei Ubuntu ist Rythmbox dabei. Auch hier kann ich einfach die existierenden Ordner mit Musik importieren. Das Programm sieht iTunes sehr ähnlich. Ich gebe auch Rythmbox eine Chance. Außer Musik abspielen mache ich fast nix. Also sollte es ausreichen.

Flackernde Videos
Videos sind etwas komplizierter. Der Ubuntu-Player Totem flackert bei der Videowiedergabe unerträglich. Kurze Suche im Internet ergibt: Die Kombination aus ATI-Grafikchip, Totem-Videoplayer und den coolen Grafikeffekten von compiz führt zu dem beschriebenen Flackern. Ich könnte die Grafikeffekte von compiz ausschalten. Wie ich bereits beschrieben habe, kommt das aber auf keinen Fall in Frage. Also ein neuer Videoplayer. mPlayer hat das Problem nicht, wenn man X11 als Ausgabegerät auswählt. Leider wird das Video dann immer in Originalgröße gezeigt und das ist i.d.R. zu klein. Skalieren lässt sich das Bild nicht. Gerüchteweise soll eine gepatchte Version des mPlayers das Problem lösen. Ich und gepatcht? Lieber nicht. Aber der VLC-Player soll es richten. Tut er auch, wenn man als Ausgabegerät X11 anwählt. Sieht soweit auch OK aus.

Fazit für heute
Bis auf den Stolperstein mit dem Video-Flackern also alles ganz easy im Bereich Multimedia.

Ubuntu für No-Details-Charaktere: Schritt 3 (notwendiger Unsinn :-)

2008-12-27T22:27:00.002+01:00

Nachdem Ubuntu in Schritt 2 meines Selbstversuchs seinen Job als Bürocomputer sehr gut gemeistert hat, lasse ich jetzt mal den Nerd in mir raus. Andreas hat mir auf seinem Notebook coole Gimmicks gezeigt. Die will ich auch.
Die Komponenten dazu (compiz) sind bereits auf Ubuntu mit installiert. Anscheinend fehlt aber das grafische Konfigurationsprogramm. Das hat man mit dem Paketmanager schnell nachgeladen und installiert. Danach kann man unzählige Effekte konfigurieren.
Ich entscheide mich dafür, dass neue Fenster hineingebeamt werden. Schließe ich ein Fenster, wird das verbrannt und die Fenster schwingen beim Verschieben hin und her. Außerdem kleben sie am Bildschirmrand, wenn man sie dort ablegt. Nicht zuletzt kann ich jetzt die virtuellen Desktops / Workspaces auf einen Zylinder legen und dreidimensional zwischen ihnen umschalten.
Das hat mind. Mac-Niveau, vielleicht sogar noch besser.

Ubuntu für No-Details-Charaktere: Schritt 2

2008-12-22T10:56:00.015+01:00

Heute habe ich meinen ersten echten Arbeitstag unter Ubuntu verbracht. Ich habe erstmal mit dem nackt installierten System begonnen und will die benötigten Programme immer erst installieren, wenn ich sie benötige.

E-Mails
Zuerst beginne ich mit der Bearbeitung meiner E-Mails. Das läuft wie zu erwarten ohne Probleme. Google-Mail für Privatkram und der Webmail-Client unter Firefox funktioniert natürlich auch unter Linux - meiner Einbildung nach etwas schneller als unter Windows.

Spesenabrechnung: Excel und Drucken
Dann kommt die Spesenabrechnung. Spesenabrechnung läuft bei uns über Excel. Ich kann von Ubuntu aus einfach auf alle Dokumente zugreifen, die ich auf der Windows-NTFS-Partition liegen habe. Beim Finden des Ordners mit den bereits existierenden Spesen-Excel-Dateien hilft mir der "File Browser". Die dort eingebaute Suchfunktion kommt mir schneller und einfacher vor als das, was Vista so zu bieten hat. Die entsprechenden Excel-Sheets lassen sich inkl. Macros problemlos mit Open-Office öffnen und bearbeiten.
Aber jetzt muss ich die Spesenabrechnung ausdrucken. Wie installiert man unter Linux Druckertreiber und woher bekommt man die? Also beginne ich mit der Suche im Internet. Nebenbei stecke ich schon mal das USB-Druckerkabel ins Notebook. Und noch bevor ich mir ersthaft die Ergebnisse meiner Google-Suche ansehen kann, meldet das System, dass der Treiber für meinen Canon IP4300 installiert wurde und ich jetzt drucken kann. Und das kann ich tatsächlich. Respekt. Unter Windows musste ich die Treiber immer manuell installieren.
Äh, allerdings fehlt unten und oben etwas auf dem Ausdruck. Anscheinend wird beim Drucken nicht berücksichtigt, dass der Drucker nicht das ganze Blatt vollständig bedrucken kann. Aber auch das ist schnell beseitigt. In Open-Office entsprechende Ränder definiert und gut. Zwischendurch ist das Papier im Drucker leer und ich bekomme auf dem Rechner keinen Hinweis, wie ich es unter Windows gewohnt war. Ist das jetzt besser oder schlechter? Keine Ahnung. Der Drucker steht direkt neben meinem Rechner. Ich sehe auch so, dass kein Papier mehr drin ist.

Schulungsorganisation: PDF-Viewer
Jetzt muss ich eine Schulung organisieren. Der Trainer hat die Agenda per PDF geschickt. Muss ich jetzt einen Acrobat Reader installieren? Nö! Es gibt einen "Dokumentenbetrachter". Der zeigt das Dokument einwandfrei an. Nur startet das Ding sehr schnell und braucht nicht die Startzeiten eines halben Betriebssystems wie der Acrobat Reader. Der Rest an dieser Aufgabe ist E-Mail und Wiki - also wieder Firefox als Betriebssystem im Betriebssystem im Einsatz.

Angebot: FTP und Word
Jetzt muss ich ein Angebot erstellen. Dazu hole ich mir ein ähnliches Angebot von unserem Fileserver. Dazu brauche ich Secure-FTP. Hm, im Ubuntu-Menü kann ich nichts finden. Muss ich jetzt was im Internet suchen? Ich tippe einfach mal in den "File Browser" in die Adresszeile die URL mit sftp voran. Und schon bin ich drin. Alles ist nahtlos in den "File Browser" integriert. Ich kann die Dokumente sogar direkt mit Doppelclick vom Server aus öffnen und bearbeiten, ohne dass ich die Dateien nach dem Bearbeiten wieder manuell auf den Server schieben muss. Fast schon ein wenig unheimlich...
Das Angebot ist in Word geschrieben. Wieder erledigt Open-Office den Job einwandfrei. Natürlich schicke ich dem Kunden das Angebot nicht als Word-Dokument. Er bekommt ein PDF. Dazu muss ich nicht den Umweg über Free-PDF gehen, dass sich unter Windows als Drucker tarnt. Ich kann direkt aus Open-Office das PDF-Dokument erstellen. Das geht schneller und einfacher als mit FreePDF unter Windows.

Konferenz-Präsentation: Power-Point
Jetzt muss ich noch meinen Folien für die OOP 2009 den letzten Schliff geben und die Notizen ausdrucken. Doppelclick auf die Power-Point-Präsentation öffnet mal wieder Open-Office. Auf einigen Folien scheint mir der eine oder andere Text um ein paar Pixel verschoben zu sein. Das schadet aber nicht weiter. Ansonsten werden alle Folien korrekt angezeigt und auch die Hyperlinks zwischen einzelnen Folien sind noch intakt. Also drucke ich schnell die Notizen und beende auch diesen Arbeitsschritt ohne große Zwischenfälle.

Inzwischen habe ich ziemlich viele Fenster geöffnet. Die virtuellen Desktops schaffen aber schnell wieder Übersicht.

Aufwandsschätzung: Word und diesmal FTP mit Umlauten
Als nächstes soll ich mir ein Fachkonzept ansehen und eine Hausnummer für den Realisierungsaufwand nennen. Die Dokumente hat ein Kollege auf unseren Fileserver geladen. Mit dem "File Browser" komme ich da ja ohne Probleme dran. Naja fast. Einige Dateinamen enthalten Umlaute. Die werden bei mir nicht korrekt dargestellt und die Dateien lassen sich mit diesem Namen auch nicht vom Server auf meinen Rechner kopieren. Ich kann mir für den Moment damit behelfen, dass ich die Dateien zuerst mit dem "File Browser" auf dem Server umbenenne und dann kopiere. Das Problem mit den Umlauten hatte ich schon mal bei einem Kollegen gesehen, der einen Mac verwendet. Das legt den Verdacht nahe, dass nicht Ubuntu das Problem ist, sondern die Windows-Rechner die Dateien eigenartig anlegen. Diese These wird auch dadurch gestützt, dass der Server ebenfalls ein Linux-Rechner ist. Und Linux-Rechner untereinander sollten sich ja verstehen. Ich frage mal bei den Admins nach.

Abschluss für heute
Und zu guter letzt habe ich dann diesen Blogeintrag geschrieben - mit Firefox unter Ubuntu. Natürlich auch kein Problem.

Fazit: Mein erster kompletter Arbeitstag unter Ubuntu war erfolgreich. Natürlich kann man das alles (virtuelle Desktiops, in den Explorer integriertes FTP, schnellen PDF-Viewer etc.) auch unter Windows haben, aber man muss Unmengen Zeug installieren und konfigurieren. Und persönlich habe ich das Gefühl, dass dieses ganze Installieren von Hilfstools mitverantwortlich dafür ist, dass bei mir jede Windows-Installation nach 1,5 bis 2 Jahren lähmend langsam wird. Aber natürlich kann ich jetzt noch nicht behaupten, dass sowas unter Ubuntu nicht passiert - nach nur einem Tag.

Ubuntu für No-Details-Charaktere: Schritt 1

2008-12-21T22:11:00.003+01:00

Ich liebäugele schon lange mit Linux, habe mich da aber noch nicht so richtig rangetraut. Ich bin eher das Typ für das große Ganze und scheue mich vor den Details - keine 10 Pferde würden mich dazu kriegen, einen Kernel zu compilieren.

Vor ca. einem Jahr hatte ich einen erfolglosen Versuch auf einem etwas älteren Notebook - ich konnte keine WLAN-Verbindung herstellen.

Jetzt hat mich ein Kollege erneut angefixt. Und ein anderer Kollege hat mich herausgefordert, weil er meinte, meine Detailignoranz wäre mit Linux inkomaptibel.
Also starte ich einen zweiten Versuch. Installiert habe ich Ubuntu von Windows aus mit Wubi. Super einfach. Da muss man eigentlich nur Username und Passwort für den ersten Ubuntu-Account wählen und nach der automatischen Installation ist man direkt arbeitsfähig: Partition wird automatisch eingerichtet, man kann von Ubuntu auf sein Windows-Laufwerk zugreifen, Firefox, Open-Office etc. sind gleich installiert und das WLAN wird automatisch erkannt und man muss nur noch den Key für die Verschlüsselung eingeben - einfacher als unter Windows Vista. Und Ubuntu startet schneller als Vista. Bisher bin ich ganz angetan.

Jetzt werde ich versuchen, schrittweise immer mehr Anteile meiner Arbeit am Rechner unter Ubuntu zu erledigen. Mal sehen, wie weit ich komme. Ich werde weiter berichten.

Mein Rechner ist übrigens ein Lenovo Thinkpad T60.

Rezension zu: Refactorings in großen Softwareprojekten

2008-12-07T21:19:00.002+01:00

Ralph Johnson hat die englische Übersetzung des Refactoring-Buches von Martin und mir gelesen und findet es gut. Da fühle ich mich jetzt ja schon ein wenig geadelt...

Ab in den Hyperraum

2008-12-04T14:14:00.000+01:00

IBM hat in mein Notebook anscheinend viel fortschrittlichere Technologie eingebaut, als ich bisher dachte. Vor ein paar Tagen veränderte sich der Bildschirminhalt wie oben dargestellt. In der Mitte ist das Bild noch scharf an den Rändern wird es zunehmend unschärfer. Und wer sich mit Star*-Filmen (Star-Wars, Star-Treck, Star-Gate etc.) auskennt, weiß: So sieht die Welt aus, wenn man in den Hyperraum eintritt bzw. auf Warp-Geschwindigkeit geht.
Ich hoffe, mein Rechner hatte dort keinen Kontakt mit den Bösen (Sith, Borg, Replikanten) und hat sich am Ende noch einen Alien-Virus eingefangen.

Stories schneiden

2008-12-02T13:52:00.002+01:00

Bernd Schiffer hat in seinem Blog ausführlich und gut beschrieben, warum und wie man Stories zerschneiden sollte, um sie klein zu kriegen.
Dazu habe ich noch eine Ergänzung, die Straßenmetapher beim Dimensional Planning. Bei diesem Ansatz unterscheidet man die "Schönheit von Stories" und verwendet eine Straßenmetapher (Diese Art des Kleinschneidens ist in Bernds Ausführungen bereits implizit enthalten.) Stories können in vier Ausführungen realisiert werden:

Feldweg: minimal billige Lösung, die irgendwie funktioniert. Beispiel: Ich will eine Rechnung drucken. Dazu setze ich SQL direkt in der mySQL-Konsole ab. Die ermittelten Daten übertrage ich von Hand in MS-Word und drucke die Rechnung von dort aus.
Kopfsteinpflaster-Straße: sehr einfache Lösung, die schon Vereinfachung/Mehrnutzen bringt. Beispiel: Die Rechnung wird automatisch gedruckt, enthält aber nur die gesetzlich vorgeschriebenen Daten wie Kunde, Gesamtbetrag und MWSt.
Alphaltierte Straße: gute Standardlösung. Beispiel: Die Rechnung bekommt noch die Positionen dazu.
Autobahn: Top-Lösung. Beispiel: Der Kunde kann seine Rechnung personalisieren.

Diese Metapher kann man zum einen gut dazu verwenden, um mit dem Product Owner auszuhandeln, wieviel überhaupt notwendig ist. Das kann die Abschätzung des Product Backlogs vereinfachen.
Und dann kann man diese Ausbaustufen auch zeitlich betrachten (auch innerhalb eines Sprints). Zuerst baut man den Feldweg und erweitert ihn dann in Richtung Kopfsteinpflaster-Straße etc.

Studie zu Projektmanagement

2008-12-01T22:57:00.001+01:00

Wissenschaftliche Untersuchungen sollte man unterstützen. Es nützt uns allen, wenn wir besser verstehen, warum welche Dinge (nicht) funktionieren.
Also bitte mitmachen.

Blog-Einträge jetzt bewertbar

2008-11-25T22:08:00.001+01:00

Die Einträge in diesem Blog kann man jetzt bewerten - jeweils unten im Blog-Eintrag. Das ganze ist experimentell. Mal sehen, was passiert...

Pull und Kanban - über die Entwicklung hinaus

2008-11-25T15:39:00.003+01:00

Das Pull-Prinzip stammt aus dem Lean-Production und ist ein (mehr oder weniger expliziter Aspekt) agiler Softwareentwicklung. Die Idee ist, dass man nicht Arbeit in eine Ressource (z.B. Team) hineindrückt (push), sondern die Ressource sich selbst neue Arbeit holt (pull), wenn sie keine mehr hat. So wird Überlastung der Ressource vermieden.

In Scrum holt sich das Team im Sprint-Planning soviel Arbeit ab, wie es meint, im Sprint realisieren zu können - auch wenn der Product-Owner gerne mehr realisiert haben möchte. Er darf nicht mehr Arbeit in die Sprint drücken. Das Team wendet also Pull an.

Wenn man das Pull-Prinzip weiterdenkt, muss man mind. die Prozesse nach der Entwicklung mit einbeziehen (upstream processes). Faktisch findet in vielen Organisationen nach dem Sprint noch abschließende Qualitätssicherung und Überführung in den Betrieb statt. Dort sollte man natürlich auch nach dem Pull-Prinzip verfahren. Das Team drückt also nicht mit einer festen Live-Deadline die Ergebnisse des Sprints in die Qualitätssicherung und den Betrieb. Stattdessen holen sich Qualitätssicherung und Betrieb ihre Arbeiten, wenn ihre Auslastung es zulässt.

Wie setzt man das konkret um? Ganz Basic-Lean gedacht würde sich der Product Owner an das letzte Element der Wertschöpfungskette wenden und seinen Feature-Wunsch äußern, z.B. "Ich möchte, dass ich die Kontakthistorie von Kunden einsehen kann." Diesen Auftrag würde er auf einen Zettel schreiben und an den Betrieb geben.

Der Betrieb würde daraus einen (Sub-)Auftragszettel an die Qualitätssicherung formulieren: "Ich möchte eine qualitätsgesicherte Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können."

Die Qualitätssicherung macht daraus einen Auftragszettel an das Entwicklungsteam: "Ich möchte eine Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können. Die ganze Funktionalität muss soweit möglich mit FIT akzeptanzgetestet sein und es muss Beschreibungen geben, was noch manuell zu testen ist."

Dann beginnt das Entwicklungsteam, diesen Arbeitsauftrag abzuarbeiten. Wenn es fertig ist, liefert es die Systemfunktion an die Qualitätssicherung zusammen mit dem zugehörigen Auftragszettel. Die Qualitätssicherung verfährt entsprechend an den Betrieb und dieser an den Kunden.

Der ganze Arbeitsfluss wird also über Auftragszettel gesteuert. Diese Auftragszettel heißen im Lean-Production Kanban.

Mit den Auftragszetteln wie beschrieben in der Softwareentwicklung vorzugehen, ist i.d.R. unnötig teuer. Es wird zu viele Missverständnisse geben. Viel besser ist das persönliche Gespräch. Also wendet sich der Product Owner direkt an das Team und erläuert, was er benötigt. Was uns dann der ganze Kanban-Ausflug bringt? Bei diesem Gespräch (Sprint Planning) müssen Qualitätssicherung und Betrieb einbezogen werden. Man faltet den Prozess mit den Auftragszetteln zusammen, um schneller zu sein. Die Beteiligten bleiben aber dieselben!

Direkte Kommunikation in Konfliktsituationen

2008-11-24T11:20:00.003+01:00

Es ist eigentlich ein alter Hut: Wenn ich ein Problem/Konflikt mit jemandem habe, versuche ich das direkt mit dem betroffenen zu klären und belästige damit nicht meinen oder seinen Vorgesetzten. Das stieht dem Vorgesetzten die Zeit und führt häufig zu noch größeren Problemen.
Quint Studer hat es in einem Blogeintrag sehr schön auf den Punkt gebracht: "If an employee at my organization is upset with another employee, who do they tell? If the answer is HR, or their boss, or that person’s boss – actually, if it’s anything other than the employee they’re upset with – then your culture is at risk of being derailed."
Wenn man dann im direkten Gespräch keine Lösung finden kann, holt man sich natürlich Hilfe - und da können Vorgesetzte dann wieder hilfreich sein.

Pecha Kucha

2008-11-24T10:36:00.004+01:00

Das Buch "ZEN oder die Kunst der Präsentation", das ich bereits in einem eigenen Blog-Eintrag beworben habe, hat mich auf eine interessante Präsentationsform aufmerksam gemacht: Pecha Kucha.
Bei Pecha Kucha besteht jede Präsentation aus genau 20 Folien und jede Folie wird genau 20 Sekunden lang angezeigt. Eine Präsentation dauert also genau 6 Minuten und 40 Sekunden.
Mehr Informationen zu Pecha Kucha gibt es auf der zugehörigen Web-Site (oder für Deutschland).
Wie so eine Präsentation dann konkret aussieht, kann man sich in diesem oder diesem You-Tube-Video ansehen.

Präsentieren mit ZEN

2008-11-24T10:15:00.003+01:00

Ich bin vor einigen Wochen durch Zufall auf das Buch "ZEN oder die Kunst der Präsentation" von Garr Reynolds gestoßen. Bevor ich es bestellen konnte, bekam ich es auch schon geschenkt, und zwar von einem Konferenzveranstalter. Nach dem Motto: "Guck' mal, vielleicht kannst Du damit die Präsentation bei uns noch besser machen." Nette Idee. Dummerweise kam das Buch erst nach der Abgabefrist für die Folien bei mir an.
Natürlich habe ich das Buch trotzdem gelesen - mit wachsender Begeisterung. Mir war schon länger bewusst, dass die klassische Form der Power-Point-Präsentation häufig suboptimal ist. Daher hatte ich selbst verschiedene Dinge versucht - weniger Text auf den Folien, keine Folien etc. Das schienen mir auch Schritte in die richtige Richtung zu sein. Und in genau diese Richtung geht auch das Buch: weniger Text, keine Bullet-Point-Listen, Vortragender im Vordergrund etc. Aber es deutlich über das hinaus, was ich mir da zusammenexperimentiert habe.

In diesem Sinne ist es ein sehr gelungenes Buch für multimedial-unterstützet Präsentation (also i.d.R. mit Power-Point oder Keynote). Ich habe in zwei Vorträgen die beschriebenen Ansätze ausprobiert und damit sehr gute Erfahrungen gemacht.

Gibt es auch einen Haken an der Sache? Klar, gleich mehrere.

Da man viel weniger Text auf den Folien hat, muss man entweder seinen Vortrag sehr gut kennen oder mit Karteikarten arbeiten. Die Folien helfen einem nicht mehr so sehr dabei, sich zu erinnern, was man sagen wollte. Aber eigentlich sollte man seinen Vortrag ja doch schon gut können, oder?
Man muss mehr Zeit in die Vorbereitung stecken. Ich kann einen Vortrag voll mit Bullet-Point-Listen in wenigen Minuten zusammenbasteln. Für Präsentieren mit ZEN brauche ich Stunden. Allerdings: Wenn ich die ganzen Mühen auf mich nehme, um z.B. auf einer Konferenz zu sprechen (Vortrag einreichen, An- und Abreise etc.), sollte ich dann nicht das Maximum aus der Zeit herausholen, die ich habe? Wenn das, was ich zu sagen habe, mitunter 100 Leute oder mehr interessieren soll, sollte ich das Publikum dann mit schlechten Folien quälen, um ein paar Stunden Zeit zu sparen?
Die Folien müssen optisch attraktiv gestaltet werden und das bedeutet für die meisten von uns, dass wir Bilder kaufen müssen. Gemessen an der Zeit für Vorbereitung, Overhead und Vortrag sind die Kosten dafür aber nicht so hoch. Im Buch gibt es Hinweise auf verschiedene Dienste, die Bilder verkaufen.

Auf dem Buch-Cover steht ein Zitat von Seth Godin: "Dieses Buch dürfen Sie keinesfalls kaufen! Denn sobald alle Menschen bessere Präsentationen gestalten, gehen meine in der Masse unter..." Ich glaube, da muss Seth Godin keine zu große Angst haben. Die meisten Leute werden wahrscheinlich durch die o.g. drei Punkte abgeschreckt. Unberechtigt, aber irgendwie auch gut für diejenigen, die sich nicht abschrecken lassen.

Meine Empfehlung: Wer mit Power-Point/Keynote präsentieren will oder muss, sollte dieses Buch lesen.

Wann auf TDD verzichten?

2008-11-20T12:40:00.003+01:00

Gibt es eigentlich Situationen, in denen man nicht testgetrieben arbeiten sollte? Mir fallen drei Stück ein.

Ich exploriere, ob und wie etwas funktioniert (z.B. eine neue Technologie).
Es gibt ein definitives Datum in der nahen Zukunft, ab dem das System nicht mehr weiterentwickelt und irgendwann stillgelegt wird.
Wir haben eine Startup-Situation, in der wir eine Idee sehr schnell am Markt testen wollen.

Zu Punkt 1: Exploration
Charakteristisch ist, dass der Code ständig massiv umgebaut wird. Jedesmal Tests anpassen zu müssen, kann sehr aufwändig sein. Mitunter ist man schneller, wenn man dann ganz auf das Testen verzichtet. Man muss dann eben auch nur den Mumm haben, nach der Exploration den ganzen ungetesteten Code wegzuwerfen und vernünftig neu zu schreiben.
Natürlich gibt es bei der Exploration auch Situationen, in denen Tests helfen. Das ist vor allem dann der Fall, wenn man ein neues API ausprobiert. Dann ist der Unit- oder FIT-Test häufig ein angenehm leichtgewichtiger Client für den Test.

Zu Punkt 2: Stilllegung
Wenn das System nicht mehr weiterentwickelt wird, gibt es auch keinen Grund, Aufwand in die Renovierung des Legacy-Codes zu stecken. Allerdings muss man sich auch sicher sein, dass die Stilllegung auch kommt. Viel zu häufig wird es nicht präziser als "das System läuft bestimmt nicht mehr so lange". Was von solchen Prognosen zu halten ist, wissen wir spätestens nach dem Jahr-2000-Problem: Die ursprünglichen Entwickler der Systeme haben auch gedacht, dass ihre Systeme bestimmt nicht so lange laufen. Man muss sich also wirklich, wirklich sicher sein!

Zu Punkt 3: Startup
Bei Startups ist charakteristisch, dass ein schneller Markteintritt essenziell ist. Wenn es gut läuft, verdient man nach dem Markteintritt soviel Geld, dass man davon das System neu und vernünftig getestet nochmal schreiben kann. Wenn man also schneller an dem Markt kommt, wenn man die Tests weglässt, ist das ein valides Argument, auf TDD zu verzichten.
Natürlich gibt es irgendwann eine kritische Masse, ab der man bei der Entwicklung mit Tests schneller ist als ohne. Aber wo liegt diese Grenze? Ich hätte sie aus dem Bauch heraus bei 20-50 Personentagen Programmieraufwand verortet.
Also prüfen wir mal diese Hypothese. Ich habe Clipboard2Web vor diesem Hintergrund ohne Tests programmiert. Und bis zum ersten Release hat sich das nach meiner Einschätzung auch gelohnt. Jetzt ist aber der Zeitpunkt gekommen, ab dem ich mit TDD schneller vorankomme. Wieviel Aufwand habe ich bis zu diesem Punkt investiert? 12 Personenstunden! Ergo: Vergesst das mit dem Weglassen der Tests in Startup-Situationen. Es lohnt sich nicht.

stilversprechend.de

2008-11-13T16:36:00.003+01:00

Was kommt eigentlich dabei heraus, wenn der eigene Bruder erst Gemanistik studiert und dann in selben IT-Unternehmen arbeitet, wie man selbst? stilversprechend.de
stilversprechend.de ist ein Internetservice, der die Lesbarkeit von Texten nach verschiedenen Kriterien bewertet. Am Besten mal reingucken und verschiedene Texte ausprobieren. Vielleicht erscheinen die Bewertungskriterien zunächst etwas "platt". Wenn man aber mal ein paar Texte prüfen lässt, stellt man schnell fest: Texte, die man schwierig, langweilig oder sinnlos findet, bekommen tatsächlich schlechte Werte und Texte, die man gut verstehen kann, bekommen meist gute Werte.

Stehen, stehen, immer nur stehen?

2008-11-11T16:29:00.002+01:00

Hier ist ein interessanter Blog-Eintrag, in dem beschrieben wird, dass die japanischen Lean-Unternehmen auf das Stehen stehen (was für eine formvollendete Formulierung :-)
Die dort genannten Gründe für das Stehen (bessere Ergonomie, herumlaufen ist wichtig etc.) gelten alle auch für die Softwareentwicklung. Unsinn? Nein! Mein Kumpel Henning hat seit seinem Bandscheibenvorfall einen Tisch, der sich auf Stehhöhe hochfahren lässt. Und daran haben wir auch schon Pair-Programming gemacht und es war auf keinen Fall unangenehmer als dies sitzend zu tun.
Irgendwie haben wir die Idee aber nicht weitergetrieben. Ich habe aber mehr und mehr das Gefühl, dass wir das nochmal tun sollten.

Artikelserie Perspektivenwechsel in Java-Magazin und auf JAXenter

2008-11-11T13:12:00.002+01:00

Es gibt eine Artikelserie namens "Perspektivenwechsel" im Java-Magazin, in der ich hin und wieder auch mitschreibe. In der Artikelserie werden unterschiedlichste Themen aufgegriffen, manchmal vielleicht auch etwas provokativ. Mit etwas Verzögerung erscheinen die Artikel auch online auf JAXenter.

Toyoto Product System Details

2008-11-10T23:23:00.002+01:00

Viele kennen die Prinzipien des TPS (Toyota Production System): Hier gibt es noch weitere sehr interessante Details dazu.

One Piece Flow

2008-11-10T15:45:00.002+01:00

Wir wünschen für die agile Softwareentwicklung One-Piece-Flow. Idealerweise soll immer nur eine Story oder ein MMF in Arbeit sein. Dass One-Piece-Flow dem klassischen Modell (Batchen von Aktivitäten) überlegen ist, zeigt dieses Video sehr schön.

Kundenorientierung und Kommunikation extrem

2008-11-10T15:26:00.003+01:00

absolut lesenswerter Artikel

Und jeder der denkt "bei uns geht sowas nicht", könnte mal dazu denken: "Was muss ich tun, damit sowas bei uns geht?".

XP and Frameworks

2008-11-08T13:15:00.003+01:00

At the XP2000 conference I had a talk about eXtreme Programming and frameworks. Some people archive things for a really long time. One of them reread my article and asked me a few days ago if I did further research on it. I didn't really do research but I collected some experiences which lead me to some simple conclusions (which didn't changed too between 2000 and now):

Use before reuse. First you have to use some code successfully and than you can think about generalizing it for reuse. That means that you have to invest effort to refactor application code to framework code. A lot of teams try to avoid this "rework" but in most cases the effect is that the framework becomes bloated and hard to use.
Running application: You always have to have a running application on top of your framework that proves that the framework is useful. This application may be a demo application but that would restrict the "prove". A real application is much better.
Supporting framework team: This is the really hard one. When your framework grows larger and supports more than one application team you normally need an own framework team. That is easy part, here is the hard part: The framework team has to have a perspective that the application teams are their customers and that they have to listen to the application teams and support them. Most frameworks teams I met had another attitude. They thought that they understand much better how to implement applications than the application developers know and that the application developers are dumb and foolish to a certain degree. That results in the attempt to prescribe how to develop with the framework. And that doesn't work, especially not if you try to support agile teams that should be self organized and empowered.

Technical Debt

2008-11-07T15:10:00.001+01:00

Martin Fowler hat einen Vorschlag gemacht, wie man Technical Debt "messen" kann. Das ist sicher ein guter Anfang.

Color Modeling

2008-11-07T15:07:00.003+01:00

Color Modeling ist die Modellierungstechnik, die Feature-Driven-Development (FDD) vorschlägt - aber nicht verpflichtend macht. Aber auch außerhalb von FDD kann Color Modeling sehr nützlich sein. Ich habe es (in adaptierter Form) in Scrum/XP-Projekten eingesetzt.
Insgesamt finde ich, dass die Technik zu wenig bekannt ist und unterschätzt wird. Daher freut es mich, dass jetzt eine gute Erläuterung zu Color Modeling mit ein paar Erfahrungswerten aufgetaucht ist.

TDD-Einsichten

2008-11-07T13:42:00.001+01:00

Wer kann glaubwürdiger den Nutzen von TDD vertreten als jemand, der TDD ursprünglich für Unsinn hielt?

Siehe hier: http://blog.ontheheap.com/2008/10/30/wrong-about-tdd/

W-JAX: Hochperformante Webanwendungen

2008-11-05T18:02:00.002+01:00

Heute habe ich auf der W-JAX einen interessanten Vortrag von Peter Roßbach gehört. Es ging um Tipps und Tricks, wie man Webanwendungen schneller machen kann. Besondere interessant fand ich, dass man sehr viele Dinge ohne Programmierung, einfach durch Konfiguration (z.B. in Apache) regeln kann - Caching, Zippen etc.
Die meisten Dinge kann man sofort umsetzen und sie versuchen keinen oder nur wenig Zusatzaufwand. Ein paar Beispiele sind:

Bilder sollten nicht im Browser skaliert werden, sondern in der benötigten Größe vom Server geliefert werden.
GET-Requests (ohne Parameter) können häufig gecacht werden und damit kann man leicht mal 50% Bandbreite sparen.
Man sollte immer erst die CSS-Dateien in seine HTML-Seiten einbinden und dann die Java-Script-Dateien. Sonst wird mitunter doppelt gerendert.
Man sollte Links ohne Ziel vermeiden (z.B. Favicons, die es nicht gibt). Diese führen intern zu 404 und 404 kann nicht gecacht werden.
etc.

CookieSwap

2008-10-29T11:19:00.002+01:00

Heute hat man ja schnell mehrere Accounts für Web-Sites wie GMail am Hals (z.B. einen für private E-Mail und einen für einen Firmen-Account von Picasa-Web). Da die Login-Infos in Cookies gespeichert werden, bedeutet einloggen in Firmen-Picasa-Web leider automatisches ausloggen aus privatem GMail.

CookieSwap ist ein Firefox-Addon, mit dem man mehrere Cookie-Profile verwalten und schnell zwischen diesen umschalten kann. Das ist noch nicht perfekt, weil man immer noch nicht mehrere Accounts gleichzeitig aufhaben kann, aber es ist eine Verbesserung.

Und wenn man selbstgeschriebene Web-Anwendungen mit mehreren Accounts testen will, ist es sowieso nützlich.

Clipboard2Web mit Zuschneiden

2008-10-17T23:39:00.002+02:00

Ich habe eine neue Version von Clipboard2Web live gestellt. Die größte Änderung ist die Zuschneiden-Funktion, mit der man das Bild auf den gewünschten Inhalt zuschneiden kann.
Darüber hinaus hat Bernd mich darauf aufmerksam gemacht, dass JPG meist nicht das beste Format ist und PNG meist besser ist. Hier gibt es auch noch einen passenden Webcomic zum Thema.
Und nicht zuletzt löscht Clipboard2Web jetzt bei jedem Start die zuletzt gespeicherten Bildern. So läuft die Platte nicht so schnell voll.

Clipboard2Web-Service ist online

2008-10-13T14:24:00.003+02:00

Ich muss relativ häufig Abbildungen oder Bilder in die eine oder andere Web-Anwendung bringen - z.B. in Blogger oder Google-Docs. Das Verfahren dazu ist sehr umständlich. Häufig kopiere ich das Bild ins Clipboard, öffne dann Paint, paste das Bil in Paint, speichere das Bild auf der Festplatte, wechsele in die Webanwendung, öffne den Upload-Dialog, suche die Bilddatei auf der Platte und starte dann den Upload.

Clipboard2Web ist eine Internet-Anwendung, die das vereinfacht. Einfach Bild aus dem Clipboard nach Clipboard2Web pasten und schon steht im Gegenzug der Pfad zum Bild im Clipboard. Das muss man jetzt nur noch in den Upload-Dialog der gewünschten Webanwendung pasten und fertig.

Clipboard2Web enthält ein signiertes Applet, so dass man beim ersten Start der Anwendung das Zertifikat akzeptieren muss.

Technologisch ist Clipboard2Web in erster Linie ein signiertes Applet, eingebunden in eine sehr kleine Grails-Anwendung.

Ich freue mich jederzeit über Feedback zu Clipboard2Web.

Scrum und XP

2008-10-05T20:44:00.002+02:00

Es ist schon etwas her, dass Jens Coldewey und Bernd Schiffer von ihren Eindrücken des dritten deutschsprachigen Scrum-Meetings berichtet haben. Beide hatten das Gefühl, dass es zwischen Scrummern und XPlern nicht immer nur harmonisch zugeht.

Grund genug, einmal in mich zu gehen und zu gucken, wie ich zu der Frage "Scrum oder XP" stehe. Zunächst ist klar, dass ich mit XP "groß" geworden bin. Lange Zeit habe ich Scrum nur am Rande wahrgenommen - "ist in XP sowieso alles mit drin". Im Rahmen meiner beruflichen Tätigkeiten hat Scrum dann aber einen immer größeren Anteil eingenommen. Und das liegt nicht nur daran, dass Scrum heute deutlich weiter verbreitet ist als XP und daher stärker nachgefragt wird.

Ich schätze an Scrum:

die Einfachheit und Stringenz: Scrum kann man leichter lehren und einführen als XP

den expliziten Fokus auf Eigenverantwortlichkeit des Teams (klar, das ist in XP auch so gemeint, aber nicht so explizit herausgearbeitet)

die Scrum-Master-Rolle, um die Selbstorganisation des Teams zu unterstützen

Trotzdem nutze ich persönlich sehr gerne XP. Schließlich kümmert sich Scrum "nur" um das Management der Entwicklung und nicht um die Entwicklung selbst. Um dauerhaft mit agiler Vorgehensweise erfolgreich zu sein, brauche ich passende Entwicklungstechniken. XP bietet passende Techniken wie TDD, Refactoring und Pair-Programming - auch wenn das nicht die einzigen Möglichkeiten sind, agil erfolgreich zu sein. Viele Scrum-Coaches setzen auch genau die XP-Techniken ein, wenn der Scrum-Managementrahmen erstmal erfolgreich eingeführt ist.

Also kann man doch gleich nur XP verwenden und Scrum ignorieren? Nein! XP ist verhältnismäßig umfangreich. Kein Team kann XP vollständig von heute auf morgen einführen. Also muss man die XP-Techniken schrittweise einführen. Und da neigen viele Teams dazu, die leicht einzuführenden Techniken vorzuziehen und das sind häufig die Programmiertechniken. Aber was nützt mir TDD und Refactoring, wenn das Projekt weiterhin nach Wasserfall abgewickelt wird? Vielleicht einiges, aber das Projekt ist nicht agil und schon gar nicht XP. Viele Teams haben aber diesen Eindruck. Sie machen ein bisschen TDD, Refactoring und Pair-Programming und halten das für agiles Vorgehen. Hier findet sich ein entsprechender Projektbericht.

Ivar Jacobson über die Zukunft der Softwareentwicklung

2008-09-23T21:05:00.001+02:00

The future of software development practices.

Hossa: Acrobat Reader

2008-09-09T14:31:00.001+02:00

Ich komme gerade an meinen Rechner zurück und unten rechts blinkt ein kleines Popup, in dem steht: "Acrobat Reader wurde durch den Datenausführungsverhinderer geschlossen. [..]"

Da musste ich eine Weile drüber nachdenken, was das bedeuten soll. Und ganz sicher bin ich mir immer noch nicht.

WerKannWann mit Uhrzeiten

2008-09-08T10:12:00.002+02:00

it-agile hat ein neues Release von WerKannWann veröffentlicht. Mit WerKannWann kann man Terminumfragen über das Internet durchführen und Termine auch dann abstimmen, wenn nicht alle Beteiligten an eine gemeinsame Infrastruktur wie MS-Outlook angeschlossen sind.
WerKannWann ist nicht die erste Anwendung dieser Art. Von der Konkurrenz unterscheidet sich WerKannWann aus meiner Sicht durch:

Uhrzeiten werden direkt zu jedem Termin hinterlegt und nicht im Block, wenn man alle möglichen Termine beisammen hat. Das macht die Arbeit flüssiger. Schließlich beginne ich das Eintragen der Termine normalerweise während ich in meinen Kalender gucke. Wenn ich erst alle Termine auswähle und dann die Uhrzeiten, muss ich für die Uhrzeiten wieder im Kalender zurück und dort die Tage suchen, die ich eingegeben habe.
Man muss die Uhrzeiten nicht umständlich eintippen, sondern kann sie mit coolen Slidern definieren.
Der Service ist nicht werbefinanziert und sendet daher möglicherweise intime Infos aus der Terminumfrage nicht an Google und blendet auch keine Werbung ein. Bei einem der Konkurrenten kann es schon mal passieren, dass man mit einem Kunden einen Termin für eine Scrum-Schulung aushandeln will und die Teilnehmer an der Terminabstimmung die Scrum-Schulungen der Konkurrenz angezeigt bekommen.
Die Teilnehmer an der Terminumfrage können nicht nur "ja" oder "nein" anwählen, sondern auch "wenn es sein muss". Das ist nützlicher als es erscheint, weil viele Teilnehmer "nein" anwählen, wenn der Termin nicht so gut passt. Möglich wäre er aber trotzdem gewesen.
Nach meinem subjektiven Empfinden liegt WerKannWann besser in der Hand als die konkurrierenden Services, die ich so kenne.

Also: Einfach mal ausprobieren. Wir freuen uns über Nutzer und über Feedback.

Software-Putzer?

2008-09-05T16:52:00.004+02:00

Nico Josuttis schreibt in seinem Blog über Software-Putzmänner und die nächste IT-Revolution. Er schlägt darin vor, schlechte Softwarequalität einfach als Fakt hinzunehmen und nicht immer zu versuchen, die Qualität zu verbessern. Vielmehr ginge es darum, mit dieser schlechten Qualität umzugehen. Als eine mögliche Alternative schlägt er Software-Putzkolonnen vor, die hin und wieder kommen und dann im Code aufräumen.

Dazu fallen mir gleich ein paar Sachen ein.

Zuerst zum Akzeptieren schlechter Qualität: Wenn die Qualität wirklich schlecht ist, wirkt sich das mannigfaltig unangenehm aus. Selbst der Product Owner bemerkt es. Nicht nur durch die langsame Entwicklungsgeschwindigkeit sondern auch dadurch, dass er aus technischen Gründen seine Priorisierungen ändern und seine Stories anders aufschreiben muss.

Und ich habe auch gerade ein aktuelles Projektbeispiel zur Hand, dass sich das Aufräumen lohnt. Beim Kunden dümpelte ein Team bei 30 Story Points je Sprint rum. Irgendwann hat das Team festgestellt, dass umfangreichere Refactorings im Bereich CSS notwendig sind, um schneller zu werden. Sie haben die Refactorings in Angriff genommen und die haben viel länger gedauert als zunächst gedacht - das ist nach meiner Erfahrung fast immer so bei größeren Refactorings. Aber sie haben es durchgestanden, obwohl es sogar soweit ging, dass nicht mehr alle Entwickler während des Sprints beschäftigt werden konnten. Nach dem Refactoring hat die Geschwindigkeit des Teams deutlich zugelegt. Heute liegt die Geschwindigkeit bei 80 Story Points je Sprint.
Mindestens in diesem Fall hat sich das Aufräumen schnell gelohnt und es wäre finanzieller Irrsinn gewesen, das Refactoring nicht durchzuführen.

Und zu den Putz-Kolonnen kann ich gleich zwei Erfahrungen beisteuern.
Erstens: Wir hatten bei it-agile mal so ein Dienstleistungsprodukt im Angebot. Das war ein Ladenhüter. Daher gibt es das jetzt nicht mehr als explizites Produkt bei uns. Wenn jemand sich dafür interessiert, beleben wir es aber jederzeit gerne wieder :-)
Zweitens: Wir hatten in einem Projekt mal sowas wie eine Putz-Kolonne in ganz zarten Ansätzen. Das hat in meinen Augen nicht funktioniert. Zum einen liefern die Projekte dann noch schlechtere Qualität - die Putz-Kolonne wird es schon richten. Zum anderen musste die Putz-Kolonne ständig bei den Entwicklern nachfragen, was bestimmter Code bedeutet. Und damit wurde das Team dann doch wieder mit Putzarbeiten belastet.

Langer Rede kurzer Sinn: Ich vertrete genau den konträren Ansatz. Wir als Entwickler sind für die technische Qualität des Systems verantwortlich. Wer schlechte technische Qualität abliefert, verstößt aus meiner Sicht gegen den Code of Ethics unserer Zunft und sollte sich was schämen. Niemand wird uns die Zeit und das Geld zum Aufräumen geben und die Putz-Kolonne wird auch nicht kommen. Wir als Entwickler müssen die Sache selbst in die Hand nehmen und zu unserer Verantwortung stehen!

P.S.: Zum Code of Ethics: Punkt 3 lautet: "PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible." Das bedeutet meiner Meinung nach auch, hohe Qualität abzuliefern.

P.P.S.: Wer mehr darüber erfahren möchte, wie guter Code für agile Entwicklung aussieht und wie man den schreibt: ich werde auf der OOP darüber einen Vortrag halten.

Priorisierung von Features

2008-09-03T22:24:00.001+02:00

mal eine neue nette Idee zum Thema von David Anderson

Aufgaben schätzen oder Aufgaben schneiden?

2008-08-31T14:30:00.004+02:00

Viele agile Projekte arbeiten mit Stories, um die Anforderungen zu definieren. Die Komplexität von Stories wird mit abstrakten Story Points geschätzt. Bei der Sprint-/Iterationsplanung findet der sogenannte Task Breakdown statt: Die Stories werden in Aufgaben (Tasks) für die Entwickler zerlegt und diese Tasks werden dann in Personenstunden oder -tagen geschätzt (Commitment Driven Planning). Die Tasks sollten dabei möglichst klein sein. Häufig wird ein Tag als Obergrenze genannt. Dann hat man beim Daily Standup im Durchschnitt jedes mal mind. einen Tasks als erledigt zu vermelden.

Wir haben gute Erfahrungen damit gemacht, die Tasks nicht nur möglichst klein sondern auch möglichst gleich groß zu halten. Wenn alle Tasks gleich groß sind, muss man Aufwände nicht mehr zusammenrechnen, sondern muss nur noch Tasks zählen. Und wenn man irgendwo mal umplanen muss, ist das auch ganz einfach: Einen Task weghängen und einen neuen dafür dazu hängen. Die Vorteile sind in der Praxis deutlich spürbar.

Allerdings kommt man jetzt in eine Zwickmühle. Tatsächlich sind die Tasks konkret nicht alle gleich groß, sondern nur im Durchschnitt. Das kann dazu führen, dass das Team in einem Sprint/Iteration 20 Tasks schafft und in einem anderen 22 Tasks. Für Commitment Driven Planning reicht das Durchzählen der Tasks also nicht aus. Wenn man beim Sprint-/Iterationsreview feststellt, dass man ein paar Tasks mehr oder weniger geschafft hat als geplant, sagt das erstmal wenig aus. Die Abweichung könnte durch die natürlichen Schwankungen bedingt sein.
Das Problem ließe sich durch das Schätzen von Tasks in Stunden beheben, dann ist aber der Vorteil der gleichen Größe wieder futsch.

Daher hat eins meiner Teams mit "halben" Tasks experimentiert. Die meisten Tasks hatte die Normgröße. Einige wenige Tasks waren kleiner und wurden daher mit 1/2 annotiert. Das hat aber nicht so richtig gut funktioniert. Die bereits vorher sehr guten Commitments wurden dadurch nicht besser. Dafür wurde Sprint-/Iterationsplanung umständlicher und beim Review gab es immer wieder Verwirrung um das Tracking ("Zählen wir die halben Tasks für das Tracking jetzt voll oder nur halb?"). Folgerichtig hat das Team die halben Tasks wieder abgeschafft und arbeitet jetzt wieder unter der Annahme, dass alle Tasks gleich groß sind.

Interessant sind noch zwei Diskussionen, die wir geführt haben:
1) Boris Gloger hat vorgeschlagen, bei Sprint-/Iterationsplanung gar nicht mehr zu schätzen. Stattdessen fragt man das Team nach dem Task Breakdown einfach Story für Story "Würdet Ihr Euch darauf committen?" Tatsächlich reicht das vollkommen aus. Es geht darum, ein Commitment auf die Planung zu bekommen. Wie man das erreicht ist sekundär. Allerdings mochte das Team Boris' Ansatz nicht folgen. Sie meinten, sie könnten auf dieser groben Ebene nicht einschätzen, ob die Planung funktioniert.
2) Man könnte die Tasks auf eine einheitliche Größe zwingen. Dann würde man nicht Tasks auf ToDo-Zettel schreiben, sondern auf Slot-Zettel. Ein Slot hätte eine feste Größe (z.B. 1/2 Personentag) und man müsste die Tasks so formulieren, dass sie auf diese Größe passen. Bei sehr kleinen Aufgaben müsste man mehrere Tasks auf einen Slot-Zettel schreiben. Diese Herangehensweise hat das Team kontrovers diskutiert, letztlich aber abgelehnt. Es schien den Entwicklern zu unnatürlichen Tasks zu führen.

Im Ergebnis ist das Team als bei einer Sprint-/Iterationsplanung verblieben, die mit etwas unscharfen Werten hantiert - alle Tasks werden als gleich groß angesehen, obwohl sie das nicht sind. Das ist solange unproblematisch, wie das Team trotzdem ein Commitment auf die Planung abgibt und das tut es. Jetzt muss man mal beobachten, wie es sich mit der tatsächlichen Qualität der Planungen verhält.

BTW: Ich persönlich mag den Ansatz von Boris und ich tendiere zu dem Slot-Zettel-Ansatz, um alle Tasks gleich groß zu bekommen. Dass ggf. mehrere Tasks auf einem Slot-Zettel stehen, halte ich für unproblematisch, weil sie so klein sind. Man wird die Aufgaben eines Slot-Zettels ohnehin nicht aufspalten und parallel abarbeiten lassen wollen.

P.S.: Tasks gleicher Größe zu haben, reduziert Variabilität und reduzierte Variabilität führt laut Lean Development/Production zu einer höheren Produktivität. Siehe auch bei David Anderson.

Wie misst man technical debt?

2008-08-30T14:25:00.002+02:00

Das Konzept des Technical Debt (technische Schuld) ist schon alt: Wenn man Qualität opfert, um einen bestimmten Termin zu halten, geht man eine technische Schuld ein. Diese technische Schuld bezahlt man zunächst mit einer reduzierten Entwicklungsgeschwindigkeit. Wenn man die technische Schuld dann irgendwann zurückzahlen will, kostet es i.d.R. ein Vielfaches von dem, was man ursprünglich "eingespart" hat.

Soweit so gut. Leider hilft das Konzept in der Projektpraxis nicht so fürchterlich gut. Es gibt kein vernünftiges Verfahren, um Höhe und "Zinssatz" der technischen Schuld zu messen.

Hier gibt es jetzt mal einen Vorschlag, technische Schuld zu messen und zwar in WTFs pro Minute.

Lustig? Klar!
Ernsthaft verwendbar in der Projektpraxis: Da sollte man vielleicht mal drüber nachdenken...

Einladung zu den XP-Days Germany 2008 in Hamburg

2008-08-25T13:13:00.001+02:00

Das Programm für die XP-Days Germany 2008 in Hamburg steht jetzt fest (siehe Programm). Vorträge gibt es am 27.11.08 (Donnerstag) nachmittags und am 28.11.08 (Freitag) den ganzen Tag. Wir haben ein vielfältiges Programm, dass sowohl den Interessen von Neueinsteigern wie auch alter Hasen im Bereich der agilen Methoden gerecht wird.

Wie der Untertitel der Konferenz bereits deutlich macht: Die XP-Days bieten allen agilen Methoden ein Forum, nicht zur eXtreme Programming. Das zeigt sich auch dieses Jahr wieder am Programm. Die meisten Vorträge bieten Wissenswertes, dass sich mit jeder agilen Methode kombinieren lässt.

Der Samstag richtet sich an all diejenigen, die aktiv mitdiskutieren wollen. Dazu muss man kein Experte mit jahrelanger Erfahrung sein. "Nur" das Engagement ist wichtig. Folgerichtig gibt es für den Samstag kein vorab festgelegtes Programm. Stattdessen wird eine "Unconference" im Open-Space-Stil stattfinden.

Jetzt bleibt eigentlich nur noch eines zu tun: Anmelden und den Frühbucherrabatt sichern!

Scrum auf der ADC

2008-08-19T18:43:00.002+02:00

Am 15.10.2008 werde ich im Rahmen der ADC-Konferenz einen eintägigen Scrum-Workshop halten. Der Workshop gibt einen Überblick über Scrum mit seinem Vorgehensmodell, den Management-Techniken sowie den Rollen. Es werden besonders die Aspekte adressiert, die beim Start in die Scrum-Welt von Bedeutung sind.

Der Workshop eignet sich als Grundlagenkurs für weiterführende Scrum-Schulungen, z.B. zum CSM.

Das ganze findet in Frankenthal (bei Mannheim) statt. Wer bis zum 15.09.2008 bucht, spart durch den Frühbucherpreis.

Scrum-ban

2008-08-18T19:22:00.001+02:00

Corey Ladas hat einen interessanten und provakanten Artikel über Scrum und Lean/Kanban geschrieben. Auch wenn man nicht jedem Argument folgen mag, finde ich den Artikel denkanstößig.

Sind Aufwandsschätzungen Verschwendung?

2008-08-13T19:34:00.003+02:00

Bei InfoQ findet sich ein interessanter Artikel, in dem die Frage diskutiert wird, ob Aufwandsschätzungen Verschwendung sind. Im Sinne des Lean Thinking sind Aufwandsschätzungen auf jeden Fall Verschwendung. Sie gehen schließlich nicht in die entwickelte Software ein.
Allerdings: Leider kann man nicht jede Verschwendung sofort beseitigen. Mitunter benötigt man die Verschwendung als Zwischenergebnis oder zur Kontrolle seines Projektes. Viele agile Projekte können daher bisher nicht auf die Verwendung "Aufwandsschätzung" verzichten. Das Unternehmen allokiert beispielsweise auf klassische Weise Budgets und muss daher Projektkosten prognostizieren. Oder man hat mit unsäglichen Festpreisverträgen zu tun. Oder man weiß nicht, wie man sonst vernünftig Projektfortschritt messen - also Release Burndown Charts zeichnen - kann. In diesem Sinne wäre es gefährlich, jetzt einfach auf Aufwandsschätzungen zu verzichten.
Allerdings zum Allerdings: Das Ziel bleibt trotzdem bestehen. Nur, weil wir im Moment nicht wissen, wie wir Verschwendung loswerden können, bedeutet es nicht, dass wir die Verschwendung für alle Zeit akzeptieren müssen. Wir müssen stattdessen kontinuierlich an dem Problem arbeiten und uns (häufig schrittweise) einer Lösung nähern.
Ein erster Schritt könnte darin liegen, alle Stories auf dieselbe Größe zu normieren. Das wird im InfoQ-Artikel auch vorgeschlagen, ist bei FDD schon länger gängige Praxis und hat sich auch in unseren Projekten bereits bewährt. Dann muss man nicht mehr schätzen und zusammenrechnen, sondern nur noch zählen.
Und dann kann man sich überlegen, wie man auch noch das Zählen einspart. Diese Einsparung liegt zunächst wahrscheinlich im Bereich von max. 1 Stunde / Woche je Team. Das ist nicht wirklich berauschend. Aber die Einsparung hätte erhebliche - postitive - Seiteneffekte, bzw. Voraussetzungen. Damit man nicht mehr schätzen und zählen muss, muss sich das Unternehmen wandeln weg von Kostenorientierung hin zur Nutzenorientierung. Bei nutzenorientierter Perspektive interessieren mich erstmal die Kosten nicht. Ich priorisiere - möglichst gleich große - Stories nach ihrem Geschäftswert. Wenn mein Bauchgefühl mir sagt, dass die noch übrig gebliebenen Stories weniger Geschäftswert schaffen als mein Team kontinuierlich kostet, ist das Projekt eben zuende. Fertig. So einfach könnte Softwareentwicklung sein und wenn man dem InfoQ-Artikel glauben schenken darf, ist sie das bei einigen Unternehmen auch.

Technical Debt und das geistige Taskboard

2008-08-12T22:37:00.002+02:00

Entwickler wollen ihren eigenen Ansprüchen genauso gerecht werden wie den Ansprüchen anderer. Daher tun sich viele Scrum-Teams am Anfang schwer, sich einzugestehen, dass sie sich für den Sprint zuviel vorgenommen haben (Over Commitment). Für Product Owner ist es anfänglich ebenso schwer. Schließlich hat man auch als Product Owner seine Ziele und möglicherweise sogar bestimmte Features zu einem festen Zeitpunkt versprochen.
Beides zusammen kann ausreichend Druck erzeugen, dass die Entwickler in den Zug einsteigen, der direkt in die Hölle fährt: Sie opfern Qualität, um den geplanten Sprintinhalt zum Sprintende zu schaffen. Sie gehen eine technische Schuld ein (Technical Debt), die ihnen später sehr schmerzhaft auf die eigenen Füße fällt - in Form einer steilen Aufwandskurve.
Dabei ist das erste Problem aus meiner Sicht gar nicht, dass man die technische Schuld eingegangen ist. Das erste Problem ist, dass das implizit passiert. Die Entwickler machen sich beim Programmieren geistige Tasks in der Art "Hier müsste man noch mal das Refactoring XYZ durchführen.", "Hier müssten noch die Tests nachgeschrieben werden." etc.
Diese Tasks gehören nicht in den "Hinterkopf". Diese Aufräum-Tasks gehören explizit und für alle sichtbar ins Sprint-Backlog (und damit auf das Taskboard). Damit hat man nicht nur die Merker, was man noch erledigen muss. Es wird auch sofort klar, dass man das Sprint-Commitment trotzdem NICHT erreicht hat. Man hat nur die übrig gebliebenen Tasks getauscht. Es sind keine fachlichen Features mehr offen, sondern technische Aufräumarbeiten.
Dieser Fakt ist erstmal zu akzeptieren und in der Sprint-Retrospektive zu beleuchten. Warum konnten wir unser Commitment nicht halten und wie machen wir es nächstes Mal besser? Und dann sollte man sich auch gleich noch die Frage stellen: Warum haben wir Qualität geopfert anstatt Funktionalität zu reduzieren und ist das Opfern der Qualität wirklich der bessere Weg?

Können Anwender/Fachexperten modellieren?

2008-08-01T18:15:00.004+02:00

Auf diese Frage hätte ich früher mit einem klaren "Nein" geantwortet. Inzwischen mehren sich aber deutlich die Anzeichen, dass sie mit entsprechender Unterstützung vielleicht doch viel mehr können, als zumindest ich früher dachte.

In Feature-Driven-Development sind die Fachexperten beim Color Modeling mind. sehr stark in die Erstellung fachlicher Klassenmodelle involviert.
Bei InfoQ ist ein Artikel erschienen, der beschreibt, wie die Fachexperten selbst mit Domain Driven Design fachliche Klassenmodelle erstellt haben, die die Entwickler dann auch genau so umgesetzt haben.

Der InfoQ-Artikel hat mir auch nochmal eine Situation in Erinnerung gerufen, die wir vor 2 oder 3 Jahren in einem Projekt hatten. Wir hatten zeitliche Ereignisse an Wasserzählern modelliert (Einbau, Wechselung, Eichung etc.). Es wurde irgendwann im Projekt klar, dass wir das Modell ändern müssen. Der Code war schwer verständlich und sträubte sich gegen Änderungen.

In der Diskussion über das Zielmodell haben sich zwei Fronten im Team gebildet, die sich auch nicht von selbst auflösten. (Dass die Fronten entstanden sind, halte ich heute für ein Sympton eines tieferliegenden gruppendynamischen Problems, aber das ist hier nicht das Thema.)
Wir haben ziemlich viel Zeit in die Diskussion gesteckt, ohne zu einem Ergebnis zu kommen. Irgendwann habe ich einen Fachexperten einfach mal die beiden Modelle skizziert und gefragt, ob er etwas beitragen kann. Konnte er. Er hat gesagt, dass beide Modelle nicht so gut passen und ein drittes skizziert. Dieses Modell leuchtete dem ganzen Team schnell ein und wir haben die Änderungen durchgeführt. Tatsächlich beseitigte das Modell des Fachexperten unsere Probleme im System.

TeamSpider

2008-08-01T18:13:00.003+02:00

Wir haben unsere kleine Webanwendung zur Selbstbewertung agiler Teams umbenannt. Sie heißt jetzt TeamSpider und ist unter http://teamspider.it-agile.de erreichbar. Sonst ändert sich nichts.

Taskboard: Gute geklaut...

2008-07-30T15:05:00.003+02:00

...ist besser als schlecht selbst gemacht :-)
Ich finde die Kanban-Ansätze von David J. Anderson interessant, beschrieben z.B. in seinem Blog-Eintrag Kanban in Action. Ich bin nicht in allen Punkten einer Meinung mit ihm. Er stellt es z.B. als Vorteil dar, dass er keine Iterationsplanung braucht. Ich bin mir aber nicht so sicher, ob es sich nicht vielleicht doch um einen Bug handelt, weil er keine Iterationsplanung machen kann. Aber das ist letztlich Spekulation. Ich keine sein Setting nicht im Detail.

Zwei Dinge habe ich aber bei ihm geklaut und in verschiedene Taskboards übernommen:

Blockaden/Hindernisse
Kapazitätsbeschränkungen

Blockaden/Hindernisse
Dass man Hindernisse bei den täglichen Standup-Meetings benennt und festhält, hat sich inzwischen allgemein durchgesetzt. Häufig werden diese einfach als Liste festgehalten. Man kann jedoch zwei Typen von Hindernissen unterscheiden: Hindernisse, die mich bei der Arbeit behindern und Blockaden, die die Weiterarbeit an einer Aufgabe blockieren (z.B. fehlende Zulieferungen von Dritten). Aufgabenbezogene Blockaden schreiben wir daher nicht mehr in die Hindernisliste, sondern kleben eine rote Haftnotiz auf die blockierte Aufgabe. Das gibt eine schöne Visualisierung einer häufig gruseligen Situation: Das Team arbeitet gar nicht an den Aufgaben mit der höchsten Priorität, sondern an den wenigen Aufgaben, die gerade nicht blockiert sind.

Kapazitätsbeschränkungen
In einem unserer Festpreisprojekte arbeitet das Team an einem großen Auftrag. Der Kunde ist sehr zufrieden mit unserer Arbeit und versorgt uns daher immer fleißig mit weiteren kleinen Aufträgen. Diese müssen wir schätzen - wir sind immer noch in der Festpreiskonstellation. Die Aufwandsschätzung liefert natürlich das Team selbst. Die Schätzungen durchzuführen, sind Aufgaben, die bei der Iterationsplanung eingeplant werden. Mitunter hat der Kunde aber soviele tolle neue Ideen, dass wir vor lauter Schätzarbeit (Vorleistung) gar nicht mehr zum Hauptauftrag kommen. Da hat es sehr geholfen, dass wir eine neue Kartenfarbe (blau) spendiert haben für solche Aufgaben ohne bezahlten Auftrag und das Taskboard in der Kapazität für blaue Karten auf "2 pro Iteration" beschränkt haben. Das sorgt dafür, dass wir unsere Zeit im Wesentlichen auf den Hauptauftrag konzentrieren können. Und bisher ist dem Kunden dadurch auch kein Nachteil entstanden.

Google-Testing-Blog: Testing Against Interfaces

2008-07-27T10:14:00.003+02:00

Auf dem Google-Testing-Blog ist gerade ein Artikel "Testing Against Interfaces" erschienen. Es geht darum, wie man verschiedene Implementation desselben Interfaces testet. Der Artikel schlägt vor, eine abstrakte Testklasse zu dem Interface zu bauen. Im setUp dieser abstrakten Testklasse wird eine abstrakte Methode createXYZ aufgerufen, die das zu testende Objekt liefert. Jetzt leitet man von der abstrakten Testklasse konkrete Testklasse je getesteter Klasse ab. In diesem konkreten Testklassen überschreibt man die createXYZ-Methode und kann dann verkünden: "ich habe fertig" :-)

Das klingt plausibel, ist nach meiner Erfahrung in vielen Fällen aber nicht praktikabel. Dafür sind zwei Gründe verantwortlich:

Man benötigt in Tests das getestete Objekt mitunter in unterschiedlichen Ausprägungen, und muss mitunter unterschiedliche Konstruktoren aufrufen. Dann muss man die createXYZ-Methode parametrisieren. Das funktioniert aber nur solange gut, wie alle Implementationen des getesteten Interfaces dieselben Parameter bekommen. Ist das nicht der Fall, muss man die Signatur der createXYZ-Methode aufblähen mit Parametern, die nur für einzelne Implementationen einen Sinn ergeben. Hinweis: Das Kochbuch zu JUnit benutzt z.B. unterschiedlich erzeugte Objekte im selben Test (natürlich ohne die Interface-Problematik).
Häufig reicht ein einzelnes Objekt als Fixture nicht aus. Es werden mehrere Objekte benötigt. Jetzt müsste die createXYZ-Methode mehrere Objekte zurück liefern (als Liste?) oder man ruft mehrere createXYZ-Methoden auf, oder... Alles nicht besonders elegant.

Diese Probleme waren bei uns in früheren Jahren in der Praxis so massiv, dass wir diese Konstruktion fallen gelassen haben. Stattdessen haben wir eine andere Lösung konzipiert: Wir bauen ein Test-Center auf. Das ist eine konkrete Klasse, die mir einzelne parametrisierte Testmethoden anbietet. Diese ruft man aus den konkreten Testklassen auf. Damit eliminiert man die Redundanzen in den Tests. Natürlich sind meine Tests etwas länger, weil man die Testmethoden zur Delegation trotzdem alle hinschreiben muss, a la


public void testXYZ() { meinTestCenter.testXYZ(meinObjekt); }

Als weiteren Vorteil bringt die Test-Center-Lösung die Abwesenheit von Vererbung. Die Kopplung zwischen den Testklassen wird also reduziert.

Interessanterweise hatten wir für solche Konstruktionen umso weniger Anwendungsfälle, desto mehr wir uns von technischen Frameworks hin zu konkreten Anwendungssystemen orientiert haben.

Anmerkung: Das Fixtures aus mehreren Objekten bestehen, bedeutet noch nicht automatisch, dass es sich um Integrationstests handelt. Es ist meiner Meinung nach erlaubt und auch notwendig, in Unit-Tests wenige eng zusammenarbeitende Objekte als eine Fixture zu begreifen. Ansonsten neigen die Tests zur Trivialität und in statisch getypten Sprachen wie Java müsste ich überall Interfaces einziehen und in jedem Test Mocks benutzen.

Bug oder Featurewunsch?

2008-07-16T20:53:00.003+02:00

Eine der häufigsten Konfliktlinien in der Softwareentwicklung ist die immer wiederkehrende Frage: "Ist das ein Bug oder ist das ein neuer Featurewunsch?"

Diese Frage tritt regelmäßig auf, wenn der Kunde neue Systemfunktionen präsentiert bekommt und feststellt, dass er es eigentlich anders bräuchte. Im Zweifel steht der Kunde auf der Position, dass es sich um einen Bug handelt während die Entwickler im Zweifel die Auffassung vertreten, es handele sich um einen neuen Featurewunsch.

Bug oder Featurewunsch? "Da regt mich ja die Frage schon auf!" (Loriot) Schließlich will diese Frage zu allererst den Schuldigen finden. Ist es ein Bug, haben die Entwickler Schuld - sie haben falsch programmiert. Ist es ein Featurewunsch, hat der Kunde Schuld - er hat falsch spezifiziert. Wir haben also ein Gegeneinander von Entwicklern und Kunde.

Dass mit dieser Einstellung nur schwer gute Projekte durchgeführt werden können, dürfte einleuchten. Statt an einer gemeinsamen Lösung zu arbeiten, wird über die Schuldfrage gestritten. Also sollten wir uns nicht die Frage stellen, ob etwas ein Bug oder ein Featurewunsch ist. Stattdessen reicht es vollkommen aus, festzustellen, dass es zu einer Systemfunktion noch Nacharbeiten gibt. Diese müssen erledigt werden. Wenn der Eindruck entsteht, dass Nacharbeiten hätten vermieden werden können, dann sollte man darüber in der Retrospektive sprechen und gemeinsam nach Verbesserungsmöglichkeiten suchen. Die Schuldfrage sollte uns dabei nicht im Weg stehen.

Und was ist bei Festpreisverträgen? Da muss entschieden werden, wer die Kosten für die Nacharbeiten trägt. Das bedeutet schlicht: Festpreisverträge richten Interessen von Kunden und Entwicklern entgegengesetzt aus und führen zu suboptimalen Ergebnissen. Wer wirklich gute Software schreiben (lassen) will, sollte die Finger von Festpreisverträgen lassen.

Deadline der XP-Days Germany verlängert bis 27.07.2008

2008-07-13T10:35:00.001+02:00

Wir haben bereits ein gute Sammlung hochwertiger Session-Vorschläge für die XP-Days Germany 2008. Da der offene Review-Prozess gut funktioniert, werden wir weniger Zeit für die finale Begutachtung der Beiträge im Programm-Komitee brauchen. Daher haben wir die Deadline für Einreichungen verlängert bis zum 27.7.2008.

Das bedeutet auch, dass bis dahin existierende Beiträge noch überarbeitet und Reviews geschrieben werden können / sollen.

http://www.xpdays.de

Lisp auf der Java-VM

2008-07-11T14:26:00.001+02:00

als alter Lisp-Fan lese ich sowas natürlich gerne: Exploring LISP on the JVM

Testen mit C++, EXPECT und ASSERT

2008-07-11T11:07:00.003+02:00

Im Google-Testing-Blog ist ein Artikel über das Unit-Testen mit C++ erschienen: EXPECT vs. ASSERT. Der Artikel ist auch deshalb großartig, weil hier die längst vergessen geglaubte Kunst des ASCII-Comics wieder auflebt. Aber auch der Einhalt ist interessant. Für C++-Entwickler scheint ein relevantes Problem adressiert zu werden. Für mich bleibt die Erkenntnis: "Ein Glück, dass ich nicht C++ programmieren muss. Diese Art von Problemen wäre nicht für mich."

Separation of Concerns: Application Logic vs. Creation Logic

2008-07-11T10:58:00.003+02:00

Im Google-Testing-Blog ist mal wieder ein schöner Artikel erschienen: How to Think About the "new" Operator with Respect to Unit Testing. Inhaltlich ist es nicht wirklich neu: Objekterzeugung mit new in Klassen mit Logik ist gefährlich, weil das isolierte Testen kleiner Einheiten erschwert wird. Stattdessen sollte man die Objekterzeugung separieren und Dependency-Injection verwenden.
Auch wenn diese Erkenntnis nicht neu ist, kann sie wahrscheinlich gar nicht oft genug wiederholt werden - viel zu vielen Entwicklern scheint sie fremd zu sein.

Und dann schimmert durch den Artikel noch eine generelle Forderung durch: "Trenne Anwendungslogik immer von Erzeugungslogik". Die meisten Entwickler, die sich der new-Problematik bewusst sind, lagern nicht alle Objekterzeugungen aus. Sie machen das nur an den Stellen, wo es zum Testen auch notwendig ist und das sind längst nicht alle Stellen. Die Erzeugung generell auszulagern, bedeutet etwas erhöhten Programmieraufwand (weil man z.B. Factories schreibt, obwohl man von der Flexibilität zur Zeit keinen Gebrauch macht). Möglicherweise lohnt sich dieser Zusatzaufwand: man muss weniger überlegen, bekommt einheitlicheren Code im Team und muss die Erzeugung später nicht refaktorisieren, wenn man doch isolieren will.

REST für Geschäftsanwendungen

2008-07-02T08:05:00.002+02:00

Dem REST-Architekturstil wird häufig "vorgeworfen", er würde für komplexe Situationen / Geschäftsanwendungen nicht funktionieren. Tatsächlich gibt es bisher wenig Erfahrungen mit REST in Geschäftsanwendungen. Es gibt aber Beispiel-Geschäftsanwendung, die zeigt, dass REST durchaus auch für Geschäftsanwendungen funktionieren kann.

InfoQ: Komplexität rund um Einfachheit

2008-07-02T07:49:00.002+02:00

Gerade ist ein InfoQ-Artikel The Complexity Around Simplicity erschienen. In dem Artikel wird eine "Erkenntnis" genannt, der ich zustimme: 'What is "simple" for one request may not be "simple" for the whole!'
Aber der genannten Konsequenz stimme ich so nicht zu: 'trying to simplify one part of the system may bring undue complexities in other parts of the system. There is a need to view the system as a whole.'
Das würde ja bedeuten, dass ich bei Projektstart doch alles wissen muss und letztlich agile Vorgehensweisen zu komplexen/schlechten Entwürfen führen müssen.
Ich würde aus der erstgenannten Erkenntnis eine andere Konsequenz ableiten: Die einfache Lösung muss für den Kern des Systems passen. Wenn das dazu führt, dass der Rand des Systems etwas komplexer zu realisieren ist, ist das vollkommen OK.
Konkretes Beispiel: Verteilte Transaktionen lassen sich mit EJBs verhältnismäßig einfach realisieren. Wenn ich keine verteilten Transaktionen brauche, bedeuten EJBs aber zusätzliche Komplexität. Aber woher weiß ich, dass ich keine verteilten Transaktionen brauchen werde? Ich kenne ja noch nicht alle Anforderungen. Ich kann es nicht wissen.
Viele Teams neigen dann dazu, EJBs auf Vorrat in das System einzubauen. Leider belasten sie dann das ganze System mit der damit einhergehenden Komplexität.
Ich gucke mir den Kern des Systems an, ob ich verteilte Transaktionen brauche. Wenn ich dort keine verteilten Transaktionen brauche, setze ich auch kein EJB ein. Wenn später dann am Systemrand verteilte Transaktionen benötigt werden, akzeptiere ich für diese paar Zeilen Code auch eine deutlich höhere Komplexität. Ich bin überzeugt davon, dass ich dadurch in der Gesamtsumme die einfachere Lösung bekomme.

XP-Days Germany 2008: Call for Sessions

2008-05-31T22:33:00.003+02:00

Der Call for Session für die XP-Days Germany 2008 ist draußen: http://xpdayblog.it-agile.de/blog/?p=128

Als diesjähriger Vorsitzender des Programm-Komitees freue ich mich über jede Menge Beiträge.

Dieses Jahr werden wir zum ersten Mal ein offenes Review-Verfahren einsetzen: Jeder Interessierte kann Beiträge begutachten und sein Feedback abgeben. Dadurch werden die potenziellen Teilnehmer an den XP-Days selbst an der Programm-Gestaltung beteiligt. Außerdem laufen Einreichungs- und Reviewprozess parallel. So können Einreicher auf Basis des Feedbacks ihre Vorschläge überarbeiten, so dass insgesamt ein noch besseres Konferenzprogramm entsteht. Wer nicht selbst einreichen, aber begutachten möchte, kann das nach Registrierung im Conf-Tool jederzeit gerne tun: http://www.conftool.com/xpdays2008

Wer zum Verfahren oder zur Konferenz noch Fragen oder Feedback hat, kann sich gerne an mich wenden: stefan AT stefanroock DOT com.

Erst wenn...

2008-05-07T20:44:00.001+02:00

Gerade habe ich diesen schönen Gedankenerguss irgendwo im Internet gefunden:

"Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, dass Anwälte nicht programmieren können!"

Übersichtsartikel zu eXtreme Programming

2008-03-26T11:26:00.003+01:00

Ich habe in der Zeitschrift dotnetpro einen Übersichtsartikel zu eXtreme Programming veröffentlicht (dotnetpro 02/2008 auf Seite 28). In der Ausgabe finden sich außerdem Artikel zu anderen agilen Methoden wie Scrum.

Software-Architektur mit Dependency-Injection

2008-03-18T09:16:00.006+01:00

Überblick

Dieser Artikel beschreibt meine Erfahrungen mit Dependency-Injection (DI) in mehrjährigen Großprojekten. Dabei geht es vor allem um die Best-Practices für Entwurf und Architektur.

Wir haben vor allem handprogrammierte DI, Pico-Container und Java-Server-Faces als DI-Container eingesetzt. Der Artikel bezieht sich primär auf Pico-Container. Die „Erkenntnisse“ lassen sich aber auf andere DI-Container übertragen.

In einem Großprojekt haben wir ein System mit vielen Singletons schrittweise auf Pico-Container umgestellt. Wir haben einige größere Refactorings in dem Projekt durchgeführt und bei vielen war der Nutzen letztlich zweifelhaft. Der Umbau auf Pico-Container gehört aber definitiv zu den Umbauten, die sich deutlich gelohnt haben.

Zielsetzungen

Mit DI kann man eine Reihe von Zielen erreichen:

Entwurf entkoppeln
Abhängigkeiten explizieren
Testbarkeit verbessern
Singletons und static-Attribute eliminieren

Entwurf entkoppeln

DI führt nicht automatisch zu einer Entkopplung der Systemkomponenten. Man kann sich auch mit DI eigenartige und unwartbare Abhängigkeitsgeflechte zusammenbauen. Ohne DI hingegen ist es in der Praxis fast unmöglich, entkoppelte Systeme zu bauen. In diesem Sinne ist DI eine notwendige, aber keine hinreichende Bedingung für Entkopplung. Wenn man zusätzlich zu DI noch Interfaces und testgetriebene Entwicklung einsetzt, bekommt man aber ohne größere Anstrengungen ein gut entkoppeltes System.

Abhängigkeiten explizieren

DI macht die Abhängigkeiten von Objekten an ihrer Schnittstelle deutlich. Dadurch ist erstmal natürlich nur ein wenig Dokumentation gewonnen. In unseren Projekten hat dieses kleine bisschen Mehr an Dokumentation aber erheblichen Einfluss darauf gehabt, wie gut man Entwürfe verstehen konnte.

Testbarkeit verbessern

Durch die Entkopplung ließen sich die einzelnen Komponenten besser testen. Hier fällt insbesondere die Harmonie von DI mit Mock-Testen[1] positiv auf. Zusammen mit testgetriebener Entwicklung entsteht ein schlagkräftiges Trio.

Nicht zuletzt laufen so entkoppelte Tests viel schneller ab als klassisch erstellte Unit-Tests (in einigen Fällen konnten wir Testlaufzeiten von mehreren Minuten auf unter 10 Sekunden reduzieren).

Singletons und static-Attribute eliminieren

Setzt man DI konsequent ein, braucht man weder Singletons noch irgendeine andere Form statischer Attribute. Dadurch werden Zustandsabhängigkeiten im System reduziert, so dass sich Systemteile besser unabhängig voneinander wieder verwenden und testen lassen.

In unseren Projekten sind durch die Umstellung von Singletons auf DI eine ganze Reihe eigenartiger Phänomene beim Ausführen und beim Testen verschwunden.

Pico-Container im Code

Pico-Container ist ein sehr leichtgewichtiger DI-Container, der programmatisch konfiguriert wird. Daher können programmatisch DI-Container erzeugt und an andere Objekte übergeben werden. Da ist eine Fußangel versteckt: Man sollte Pico-Container minimal-invasiv benutzen. Das bedeutet, dass möglichst wenig Code Kenntnis davon haben soll, dass Pico-Container (oder ein anderer DI-Container) eingesetzt wird. Folglich sollten die Pico-Container nur im Startup erzeugt werden. Weitere Klassen dürfen nicht vom Pico-Container abhängen. In der Schichtung des Systems liegt der Pico-Container also ganz oben.

Pico-Container in Tests

In Unittests hat Pico-Container nichts verloren. Sind die getesteten Klassen so kompliziert miteinander verflochten, dass man sie manuell nicht zusammenstecken kann, ist Refactoring angesagt – und zwar schleunigst.

Welche Klassen registriert man beim DI-Container?

In unseren Projekten haben sich drei Typen von Klassen etabliert, die wir typischerweise beim DI-Container registrieren.

Fabriken
Services
Objekte, die nur einmal existieren dürfen (ehemalige Singletons)

Wofür baut man Fabriken?

Wenn ein Objekt andere Objekte erzeugen will, kann man diese Objekte nicht über DI hineinreichen – man weiß ja noch nicht, wie viele Objekte erzeugt werden. In solchen Fällen reicht man stattdessen Fabriken per DI in das Objekt.

Fabriken werden häufig mit static-Methoden implementiert. Wenn man die Fabriken beim DI-Container registriert, wäre das jedoch einigermaßen witzlos. Also gilt: Fabriken sollten keine static-Methoden enthalten – static-Attribute sowieso nicht.

In vielen Projekten habe ich beobachtet, dass viel zu selten Fabriken benutzt werden! Fabriken (ohne static-Methoden) helfen bei DI und erleichtern das Testen mit Mocks ungemein[2]. Im Zweifel würde ich lieber eine Fabrik zuviel spendieren.

Abschluss

Unsere Erfahrungen mit Pico-Container haben wir in erster Linie in Rich-Clients gesammelt. Wir haben Pico-Container serverseitig nicht verwendet. Es sollte jedoch möglich sein, weil der Pico-Container sehr leichtgewichtig ist. Der Overhead für die Erzeugung bei jedem Request oder EJB-Aufruf sollte in den meisten Anwendungen zu verkraften sein. Wenn der Overhead zu groß wird, kann man den Pico-Container mind. bei Webanwendungen auch in der Session speichern.

Inzwischen kommen viele Server-Infrastrukturen aber bereits mit eigenen DI-Containern (Spring, JSF, EJB 3), so dass man serverseitig i.d.R. wahrscheinlich nicht in die Verlegenheit kommt, Pico-Container einzusetzen.

Referenzen

Easy Mock: http://www.easymock.org
EJB 3: http://java.sun.com/products/ejb/docs.html
Java Server Faces: http://java.sun.com/javaee/javaserverfaces
Pico Container: http://www.picocontainer.org
Spring: http://www.springframework.org

[1] z.B. mit Easy Mock

[2] Beim Testen gilt: Jedes Testproblem kann durch eine weitere Indirektion gelöst werden.

Grails-Anwendung: Team-Radar ist Live

2008-03-17T15:48:00.004+01:00

In einem früheren Post habe ich von den positiven Erfahrungen geschrieben, die Sebastian und ich zusammen mit Grails gemacht haben. Jetzt ist die zugehörige Anwendung online: Das it-agile Team-Radar führt ein Mini-Assessment für die Einführung agiler Vorgehensweisen durch. Bisher unterstützt Team-Radar Scrum. Andere agile Methoden wie eXtreme Programming und Feature Driven Development sind in Planung.

Junit 4.4: assertThat

2008-03-03T13:39:00.005+01:00

JUnit 4.4
Junit 4.4 ist bereits seit über einem halben Jahr verfügbar. Von den Projekten, die ich kenne, arbeiten viele aber noch mit JUnit 4.0 oder noch älter. Grund genug, einmal ein unscheinbar daher kommendes neues Feature zu betrachten.

assertThat
Zunächst gibt es eine neue assert-Methode namens assertThat. assertThat bekommt zwei Parameter übergeben, den tatsächlichen Wert (im Gegensatz zu assertEquals als ersten Parameter) und einen Matcher. Über die Matcher wird letztlich die zu testende Bedingung ausgedrückt.

Aus


assertEquals(10, list.size());

wird


import static org.hamcrest.core.Is.is;
...
assertThat(list.size(), is(10));

Diese Art der Notation geht in Richtung Fluent-Interface und ist aus meiner Sicht etwas besser lesbar als die klassische Notation.

Zusätzlich zu is() sind weitere Matcher verfügbar, so dass man im Wesentlichen mit assertThat auskommen sollte und die meisten anderen assert-Methoden nicht mehr braucht.

Ausdrucksstärker mit Hancrest
Die assertThat-Notation geht auf Hamcrest zurück. In JUnit 4.4 ist ein Teil davon enthalten - warum man da so halbe Sachen gemacht hat, erschließt sich mir nicht. Wenn man assertThat verwenden möchte, empfiehlt es sich aus meiner Sicht, Hamcrest komplett mit einzubinden. Dann hat man mächtige Matcher zur Verfügung, die die Tests nicht nur lesbarer, sondern auch kürzer gestalten. Möchte ich z.B. den Inhalt einer Liste testen, ist das mit Hamcrest ein Einzeiler:


import static org.hamcrest.Matchers.*;)
...
assertThat(list, hasItems("a", "b", "c"));

Bessere Fehlermeldungen
Nicht zuletzt generiert Hancrest bei fehlschlagenden Tests Fehlermeldungen, die häufig aussagekräftiger sind als bei JUnit-Classic. Bei JUnit-Classic war man außerhalb von assertEquals auf assertTrue oder assertFalse angewiesen und hat dann nur die Meldung bekommen, dass der Test fehlgeschlagen war. Die Gründe dafür konnte man in der Meldung aber nicht erkennen. Hamcrest hingegen generiert aus dem kompletten Matcher eine aussagekräftige Fehlermeldung:


assertThat(foo, anyOf(is(1), is(3)));

prüft, dass das foo den Wert 1 oder 3 hat (man möge mir das schwache Beispiel verzeihen). Wenn das nicht der Fall ist, erhalten wir in JUnit eine aussagekräftige Fehlermeldung:


java.lang.AssertionError:
Expected: (is <1> or is <3>)
    got: <2>

Fazit
Das assertThat-Feature kommt etwas unscheinbar daher. Ich finde, dass dem Feature mehr Ehre gebührt und dass es in der Praxis einen größeren positiven Effekt hat, als man zunächst meinen möchte.

Wer erinnert sich noch: Real Programmers Don't Use PASCAL

2008-02-02T20:06:00.000+01:00

Diese Woche war ich mit zwei Kollegen Essen. Ein Wort gab das andere und wir hatten viel Spaß. Aber als ich sagte "Ha, ha, ha. Und dann damals dieser Artikel 'Real Programmers Don't Use PASCAL'. Ein echter Hammer." sah ich in irritierte zwei Augenpaare. Und ich erkannte: "Die sind jung. Du bist alt - jedenfalls gemessen in IT-Jahren.".

Also hier für alle alten Säcke nochmal der Link auf den Artikel (damals kursierten schlechte Fotokopien davon, heute gibt es das Internet). Auf dass wir in sentimentalen "das waren noch Zeiten"-Gefühlen versinken...

Und vielleicht finden den Artikel ja auch die Jüngeren amüsant.

Real Programmers Don't Use PASCAL

Zertifizierung durch Community

2008-01-23T15:08:00.000+01:00

Das Thema Zertifizierung ist in der agilen Community umstritten. Scrum setzt stark auf Zertifizierungen, FDD etwas, XP gar nicht.
Auf der einen Seite wird argumentiert, dass Zertifikate dem Kunden eine Auskunft über bestimmte Minimalkriterien geben. Auf der anderen Seite steht, dass das Minimum möglicherweise nur aussagt, dass man eine bestimmte Zeit in einer Schulung abgesessen hat und das für den Kunden zu wenig aussagekräftig ist.
Daher haben sich viele auf den Standpunkt gestellt, Zertifikate bringen nur dann etwas, wenn man zu ihrer Erlangung auch Fähigkeiten nachweisen muss.
Es gibt jetzt eine neue Web-Site namens You Vouch For, die diesen Ansatz auf Community-Basis verfolgt. Man trägt sich dort ein und kann andere Leute "zertifizieren", also bescheinigen, dass sie bestimmte Dinge können.
Mir fallen sofort dutzende Gründe ein, warum das Vorhaben nicht funktionieren könnte. Ich finde es aber ausreichend interessant, dass man der Geschichte eine Chance geben sollte. Ich habe mich also gleich mal registriert...

Verteilte Meetings mit Card-Meeting

2008-01-04T14:03:00.000+01:00

Es gibt eine Internetanwendung namens Card-Meeting, mit der man kooperativ Karteikarten unterschiedlicher Farben beschreiben und anordnen kann. Ich habe das Tool im Dezember für eine verteilte Retrospektive verwendet, zusammen mit Skype. Es lief stabil und hat genau die wenigen Funktionen, die man braucht.

Drollige Geschichte am Rande: Einer der Teilnehmer wollte von zu Hause aus an der Retrospektive teilnehmen und hatte sich seinen Rechner zerschossen. Also ist er zu seiner Schwester und hat deren alten PC verwendet. Der Rechner war anscheinend etwas zu alt für Skype. Auf jeden Fall ist Nico immer wieder aus dem Chat geflogen. Das haben wir aber zuerst gar nicht bemerkt, weil wir Skype im Hintergrund hatten und Card-Meeting im Vordergrund.
Nico hat dann einfach eine rote Karte in Card-Meeting geschrieben "Nico wieder zu Skype einnladen" und hat damit in Card-Meeting rumgewedelt, so dass wir auf das Problem aufmerksam wurden.

mein erstes Grails-Projekt

2007-12-21T17:48:00.000+01:00

Eigentlich bin ich eher skeptisch, was neue Technologien angeht. Zu häufig wird viel zu viel versprochen und der Gesamtnutzen bleibt zweifelhaft. Viele Technologien lösen auch schlicht Probleme, die ich gar nicht habe.
Bei Groovy und Grails verhält es sich anders. Ich hatte jetzt das Glück, dass ich zum Jahresausklang ein kleines Grails-Projekt machen konnte. Ich hatte Grails bereits vorher ein wenig ausprobiert und hatte daher eine Idee, was mich erwartete. Und diese Erwartungen wurden noch übertroffen.
Wir haben in sehr kurzer Zeit eine kleine aber komplette Internetanwendung mit lächerlich wenig Code geschrieben. (Sobald die Anwendung Live ist, werde ich den Link hier mal posten.)
Besonders beeindruckt hat mich die Klarheit des Programmiermodells. Struts, JSF und Spring Web-MVC haben bei mir immer das Gefühl hinterlassen, dass intern Dinge passieren, die ich nicht ganz verstehe. Dieses Gefühl habe ich mit Grails nicht.
Weiterhin ist interessant, dass wir - obwohl es für alle das erste Grails-Projekt war - jedes Problem in weniger als 2 Stunden lösen konnten. Bei anderen Java-Technologien hatten wir immer wieder Fälle, wo wir uns Tage oder gar Wochen die Zähne ausgebissen haben; teilweise konnten wir die Probleme gar nicht lösen und mussten dann mit Work-Arounds arbeiten.

neues Buch zu Scrum

2007-12-15T14:15:00.001+01:00

Roman Pichler hat im dpunkt-Verlag ein deutschsprachiges Scrum-Buch veröffentlicht. Es ist angenehm dünn (gut 180 Seiten) und sehr pragmatisch und handlungsleitend. Es bietet insbesondere dem Einsteiger in agile Softwareentwicklung genau die Handreichungen, die benötigt werden. Der erfahrene Agilist kann dem Buch sicher noch die eine oder andere neue Idee oder Technik entnehmen und erhält einen guten Überblick über den aktuellen Stand von Scrum.

Korrektur zur DAO-Aussage im Hibernate-Buch

2007-12-15T13:31:00.000+01:00

In dem Hibernate-Buch von Arno, Robert, Sebastian und mir gibt es eine Falschaussage, die ich zu verantworten habe. In Abschnitt 8.2 steht, dass man mit Hibernate keine DAOs mehr braucht.

Das stimmt, wenn man DAOs nur zur Kapselung der DB bzw. von JDBC verwenden möchte. Denn das leistet Hibernate sehr gut. Dennoch sollte man seine Anwendung ohne Datenbank testen wollen, also Mocks einsetzen. Und dazu braucht man dann doch wieder sowas wie DAOs.
In unseren Projekten setzen wir da auf das Repository-Muster von Domain Driven Design (Eric Evans), was technisch den DAOs sehr ähnlich ist.

Sorry für die Falschaussage und Danke an Eberhard Wolff, dass er mich darauf aufmerksam gemacht hat.

Screencast zum Vortrag "Einfachheit in Softwareprojekten"

2007-12-15T13:17:00.000+01:00

Auf den XP-Days habe ich einen Vortrag mit dem Titel "Einfachheit in Softwareprojekten" gehalten. Den habe ich als Screencast aufgezeichnet und dabei leider das Mikro so übersteuert, dass der Ton unbrauchbar ist.
Glücklicherweise hat Jens Himmelreich den Ton separat aufgezeichnet und mir zur Verfügung gestellt. Nach ziemlich viel Arbeit habe ich es dann auch geschafft, Bild und Ton so zu mischen, dass sie synchron laufen.
Das Gesamtkunstwerk kann man sich hier ansehen (oder einfach nur den Ton oder die Folien als PDF runterladen).

Nochmal vielen vielen Dank an Jens Himmelreich. Ohne seine Ton-Aufnahme wäre das alles nichts geworden.

die zweite Internet-Blase?

2007-12-15T13:06:00.000+01:00

lustiges Video mit Musik dazu: http://valleywag.com/tech/online-video/here-comes-another-takedown-332666.php?autoplay=true

Lohnt sich Dependency-Injection

2007-12-08T19:33:00.001+01:00

Auf InfoQ ist gerade eine Zusammenfassung einer Diskussion erschienen, in der es um die Frage geht, ob sich Dependency-Injection auszahlt. Die einen sagen, dass DI nur dazu gut ist, damit man entkoppelt mit Mocks testen kann. Stattdessen könne man aber auch bessere Mock-Frameworks benutzen, die DI nicht erzwingen. Die anderen sagen, dass Testen DI erzwingt und dass daher DI automatisch gut ist.

Ich finde, die Diskussion geht etwas am eigentlichen Kern vorbei. DI ist erstmal nur eine Technik, genauso wie Mock-Testen. Keines von beiden ist generell gut oder schlecht. Genauso wie Entkopplung nicht automatisch gut ist. Man muss auch die richtigen Teile entkoppeln.

Meiner Meinung nach ist das Dependency-Inversion-Principle (DIP) das übergeordnete Konzept. DIP sagt, dass ein High-Level-Konzept nicht von Low-Level-Implementationen abhängen sollen. Demnach darf z.B. die Fachlogikschicht nicht von der Datenbankschicht abhängen. Begründung: Low-Level-Implementationen ändern sich häufiger als High-Level-Konzepte und die Änderungen finden nicht nur hinter dem API der Low-Level-Implementation statt, sondern schlagen häufig bis in die Klienten durch. Hängen die High-Level-Konzepte von den Low-Level-Implementationen ab, müssen sie unnötig häufig geändert werden.

Das bedeutet: DIP ist generell gut.

DI und Mocks erlauben mir, DIP umzusetzen. Daher sind DIP und Mocks mind. dann gut, wenn sie für DIP eingesetzt werden.

Interessanterweise korreliert DIP mit vielen Aspekten aus Quasar.

Warum einfach, wenn es auch kompliziert geht?

2007-12-08T18:05:00.000+01:00

Ich habe auf den XP-Days in Karlsruhe einen Vortrag über Einfachheit in Softwareprojekten gehalten, den ich hoffentlich bald als Screencast online stellen kann.
In dem Vortrag ich von einem Experiment berichtet, dass von Bavelas an der Stanford-Universität durchgeführt wurde. Man hat Propanden mit Bildern von Gewebezellen konfrontiert. Sie sollten ohne medizinische Vorkenntnisse diagnostizieren, ob die Zellen gesund oder krank sind. Sie bekamen als Feedback dann jeweils, ob sie richtig oder falsch gelegen haben. Aus dem Feedback entwickelten sie ein Modell darüber, woran man krankhafte Gewebezellen erkennt.
Allerdings hat man nur der einen Gruppe korrektes Feedback gegeben. Die andere Gruppe hat zufälliges Feedback erhalten.
Schließlich hat man Paare mit jeweils einem Vertreter jeder Gruppe gebildet, die dann gemeinsam Gewebezellen diagnostizieren sollten. Und dabei setzte sich meistens die Person durch, der man das zufällige Feedback gegeben hatte.
Begründung: Diese Person hat sich auf Basis des zufälligen Feedbacks ein sehr kompliziertes (aber falsches) Modell darüber gemacht, woran man krankhafte Zellen erkennt. Die Person mit dem korrekten und einfachen Modell war begeistert von der Detailtiefe des komplizierten Modells ("da habe ich selbst wohl etwas übersehen") und ist daher der meist falschen Einschätzung seines Partners gefolgt.
Und dieses Phänomen findet sich auch ständig in der Softwareprojekten. Es ist so verführerisch den komplizierten Architekturen, Technologien und Vorgehensmodellen zu folgen. Ich glaube jedoch, dass das meistens der falsche Weg ist: Komplizierte Lösungen sind auch dann falsch, wenn sie richtig sind.

Eine genauere Beschreibung des Experimentes findet sich in "Wie wirklich ist die Wirklichkeit?" von Paul Watzlawick im Kapitel ("Warum einfach, wenn es auch kompliziert geht?"). Der Text findet sich unter der gleichen Überschrift auch Online auf Seite 20ff.

Interview mit Weinberg

2007-11-26T18:31:00.000+01:00

Auf citerus.se gibt es ein Interview mit Gerald Weinberg, in dem er sich auch zu agilen Methoden äußert.

Wie viele Blogs?

2007-11-25T13:57:00.001+01:00

Ich unterscheide bisher meinen privaten und meinen IT-Blog. Ich mache das, weil ich seinerzeit das Gefühl hatte, das wäre nützlich für die Leserschaft.
Auf mehrfachen Wunsch eines einzelnen Herren überdenke ich diese Entscheidung gerade. Feedback dazu nehme ich gerne entgegen. Wollt Ihr lieber einen Gesamtblog lesen oder lieber getrennt nach privat und IT?

Audio gesucht zu "Einfachheit in Softwareprojekten"

2007-11-25T13:53:00.000+01:00

Ich habe auf den XP-Days einen Vortrag zum Thema "Einfachheit in Softwareprojekten" gehalten. Den habe ich als Screencast aufgenommen (also Folien und Ton). Leider ist die Tonspur übersteuert, so dass man fast gar nichts mehr versteht.
Mind. ein Teilnehmer hat den Ton auch aufgenommen. An den wendet sich dieser Post. Wenn Du das hier liest und der Ton einigermaßen brauchbar ist, schicke mir bitte, bitte, bitte den Ton an stefan AT stefanroock DOT de

Und wenn jemand einen Tipp hat, wie man eine übersteuerte Tonspur reparieren kann, immer her damit.

Termine, Termine, Termine

2007-11-25T13:34:00.000+01:00

Ich bin in meiner Beratertätigkeit oft an verschiedenen Orten und habe dort viele Termine. Für die Terminverwaltung habe ich auch dann noch einen Papier-Organizer verwendet, als alle anderen bereits PDAs hatten. Letztlich konnte ich meinen Papier-Organizer doch nicht mehr aufrecht erhalten: Meine Chefs wollten, dass meine Termine für sie und meine Kollegen sichtbar sind. Das kann ich auch gut nachvollziehen. Wenn neue Anfragen reinkommen, möchte man gerne schnell abschätzen können, ob noch irgendwo "Luft" ist und wenn man gesucht wird, ist es auch ganz nützlich zu seheh, wo man steckt. Nicht zuletzt hat sich der zentrale elektronische Terminkalender sehr bewährt, um Termine für Meetings zu finden.
Ich habe dann eine Weile versucht, den zentralen elektronischen Terminkalender manuell mit meiner Papier-Version zu synchronisieren. Erfolglos.
Also habe ich mir auch einen PDA zugelegt, einen Palm. Als zentralen Terminkalender hatten wir seinerzeit Netscape Calendar im Einsatz. Die Synchronisation zwischen beiden hat wirklich hervorragend geklappt. Und auch der Netscape-Calendar war einfach zu benutzen.
Der Netscape-Calendar wurde irgendwann aber nicht mehr weiterentwickelt, PDA und Telefon wurden eins (nämlich Nokia 9300i) und ich habe durch Arbeitgeberwechsel serverseitig mit Microsoft Exchange/Outlook zu kämpfen.
Seitdem ist das Synchronisieren eine Katastrophe. Denn zuerst muss ich mal das Handy mit meinem Notebook verbinden. Und dann muss sich die ganze Geschichte noch mit dem Exchange-Server verbinden. Und das funktioniert bei mir leider nicht stabil. Jedes mal, wenn ich mich am Synchronisieren versuche, dauert es mind. ein paar Stunden, manchmal sogar Tage, bis ich es hinbekommen habe: Handy und Notebook wollen sich nicht mehr erkennen. Die Anmeldung am lokalen Outlook funktioniert nicht. Und dann ist der Exchange-Server nicht erreichbar. Und natürlich bekomme ich bei keinem der Probleme eine aussagelräftige Fehlermeldung.
Das führt natürlich dazu, dass ich mich vor dem Synchronisieren drücke und es nächstes mal noch viel länger dauert.
Auf der Suche nach einem Ausweg bin ich auf Google-Calendar und GooSync gestoßen. Google-Calendar ist wunderbar einfach zu benutzen (fairerweise muss ich sagen: der Outllok-Kalender ist so schlecht auch nicht, wenn man mal den richtigen der mehreren möglichen Kalender zu fassen hat). GooSync sorgt für die Synchronisation zwischen Handy und Google-Calendar. Es gibt eine kostenfreie Standardversion und eine Premium-Version, die ich mit 20 Pfund / Jahr durchaus erschwinglich finde. Die Installation ist sehr einfach (man bekommt einfach eine SMS auf's Handy geschickt und wenn man die speichert, ist alles installiert). Und meine ersten Synchronisationsversuche lassen sich auch ganz gut an.
Jetzt muss nur noch der Outlook-Kalender weg und ich wäre wieder in dem Terminparadies, aus dem ich vor ca. 5 Jahren vertrieben wurde: Sync starten und alles flutscht.

P.S.: Es gibt auch Software, die Outlook mit dem Google-Calendar synchronisiert. Die behebt mein Problem aber nicht wirklich. Die Anmeldung an Outlook und am Exchange-Server bringt immer noch Probleme ohne Ende.

Dynamic Languages Shootout auf der OOP

2007-11-20T20:06:00.000+01:00

http://www.sigs-datacom.de/sd/kongresse/oop_2008/index.php?cat=dls_competition

13949712720901ForOSX

2007-11-09T13:03:00.000+01:00

Ich benutze bisher kein Apple, wünsche mir das aber mit jedem Tag der Windows-Benutzung ein wenig mehr. Ein echter Killer wäre es aber, wenn es Java nicht mehr auf dem Apple gibt. Daher nehme ich mit dieswem Blog-Post an einer interessanten Art der Abstimmung für Java auf Apple teil. Anschließend wird wohl gezählt, wie Google den Betreff im Web findet.
Details.

W-JAX: REST-Vortrag

2007-11-07T16:20:00.000+01:00

Gestern habe ich auf der W-JAX einen sehr interessanten Vortrag zu REST gehört von Stefan Tilkov. Der Vortragende hat lange Zeit mit Web-Services gearbeitet und propagiert heute REST.
Inzwischen gibt es den JSR-311 namens JAX-RS für ein standardisiertes API für REST, an dem Stefan Tilkov auch mitarbeitet. Der ist noch im Early-Draft-Stadium. Es sieht aber schon ganz nett aus.
Beim Vortrag habe ich denn auch ein Tool kennengelernt, dass wir bei unserem REST-Projekt auch benötigt hätten: curl. Mit dem Ding kann man HTTP über die Kommandozeile machen. Im Gegensatz um Browser kann man manuell den Header, die Methode (GET, POST, PUT, DELETE etc.) festlegt und auch den Body.

XML...

2007-10-30T21:55:00.000+01:00

http://c2.com/~ward/ascent.jpg

(Danke an Sebastian für den Link)

W-JAX 2007

2007-10-07T13:15:00.000+02:00

Nicht nur die XP-Days stehen vor der Tür, sondern auch die W-JAX. Meine Firma ist wieder mit Stand eine Vorträgen vertreten.

Gleich am Anfang des Agile Day halte ich zusammen mit meinem Kollegen Henning Wolf einen Vortrag über Festpreisverträge in agilen Projekten. Dieses Thema treibt uns ständig um. Auf der einen Seite ist klar, dass klassische Festpreiskonstellationen schlecht zu agilen Vorgehensweisen passen, weil sie unter anderem das Lernen "verbieten". Allerdings sind die Alternativen rar. Stattdessen Aufwandsprojekte vorzuschlagen, ist zu sehr aus der Perspektive der Entwickler argumentiert. Aber der Wurm muss dem Fisch schmecken und nicht dem Angler. Und das tut er bei Aufwandsprojekten in der Regel nicht. Denn der Auftraggeber verliert ein gutes Stück der Kontrolle über die Kosten-Nutzen-Relation seines Projektes. In dem Vortrag wird es also sehr stark um das gehen, was sich zwischen Festpreis und Aufwand abspielen kann.

Ich organisiere außerdem die Lightning Talks auf dem Agile Day. Im Gegensatz zu den Lightning Talks auf den XP-Days stehen auf der W-JAX die reinen Anfängerthemen nicht im Vordergrund.

Und wie bei den XP-Days gibt es es auch bei der W-JAX ein Speaker-Logo:

XP-Days 2007

2007-10-07T13:00:00.000+02:00

Die XP-Days 2007 stehen vor der Tür und zwar am 22. und 23. November in Karlsruhe. Das Programm bietet ein breites Themenspektrum.

Für Einsteiger in die agile Softwareentwicklung liefern die Lightning Talks am 22.11.07 einen guten Überblick. Neben den Inhalten ist die Präsentationsstruktur sehr interessant: viele kurze Vorträge, die jeweils eine Aussage genau auf den Punkt bringen.

Am 23.11.07 werde ich dann etwas zu einem meiner Lieblingsthemen sagen: Einfachheit in Softwareprojekten.

Aber eigentlich schreibe ich diesen Blog-Eintrag nur, damit ich Gelegenheit habe, das coole XP-Days-Speaker-Logo zu verwenden, das mein Kollege Bernd Schiffer erstellt hat.

Klassen und Methoden im Wandel

2007-10-06T15:11:00.000+02:00

Als ich studierte gab es genau eine Art, Klassen und Methoden zu benennen: Klassen wurden mit Substantiven benannt, die direkt dem ungesetzten Konzept bzw. ihrer Verantwortlichleit entsprechen sollten, z.B. Auftrag. Bei den Methoden wurde streng zwischen Funktionen und Prozeduren unterschieden. Funktionen liefern Werte und lassen den Objektzustand schön in Ruhe, während Prozeduren den Objektzustand ändern und keinen Rückgabewert haben. Ob etwas Funktion oder Prozedur ist, sollte nicht nur an der Signatur deutlich werden, sondern auch im Namen. Prozeduren werden immer in Befehlsform geschrieben (z.B. berechneSumme) während Funktionen eine Substantivform bekommen (ggf. mit einem 'get' als Präfix, z.B. 'getNummer'). Diese ganze Konzeption wurde z.B. von Bertrand Meyer vertreten und auch gut begründet:
Wenn man eine Klasse sucht, kann man sie leicht anhand ihres Namens finden. Und wenn man dann das API der Klasse liest, ist gleich klar, was die Methoden tun. Insbesondere ist klar, ob eine Methode nur einen Wert liefert oder ob sie gefährlich den Objektzustand manipuliert.

In den letzten Jahren hat sich an verschiedenen Stellen ein deutlich anderer Programmierstil entwickelt. Der primäre Fokus hat sich gewandelt. Es geht nicht mehr primär darum, dass man das API einer Klasse leicht lesen und verstehen kann. Stattdessen soll der Klientencode möglichst gut lesbar sein.

Bei der Benennung von Unit-Tests findet sich eine zarte Andeutung in diese Richtung. Statt AuftragTest.testSummenberechnung findet man heute immer häufiger AuftragTest.berechnetSummeDerPositionen. Die zweite Variante lässt sich als Spezifikation lesen "Auftrag berechnet Summe der Positionen".

Noch deutlicher wird es, wenn man sich Behaviour Driven Development (BDD) ansieht.

Schließlich nutzen die Fluent Interfaces dieses Konzept auch außerhalb des Testens bzw. Spezifizierens für Produktivcode.

Aus


TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

wird


TimeInterval meetingTime = fiveOClock.until(sixOClock);

Für viele Entwickler, die schon länger im Java- oder C++-Geschäft sind, sind diese fließenden Interfaces sehr gewöhnungsbedürftig. Allerdings wird eine Klasse viel häufiger eingesetzt als gelesen. Also scheint es nicht gerade abwegig, mehr Gewicht auf die Benutzbarkeit als die API-lesbarkeit zu legen.

Trotzdem wird man absehbar wohl nicht alle Klassen mit einem Fluent Interfaces versehen. Dazu ist der Aufwand zu groß. Aber bei den Klassen, die sehr häufig benutzt werden, sind Fluent Interfaces sicher eine Überlegung Wert.

Nachtrag: Ein Beispiel für ein Fluent Interface findet sich z.B. in Hibernate, wenn man eine Criteria zusammenbaut.

Ideenfluss

2007-09-30T15:19:00.001+02:00

Bei der Veranstaltung zum Lean-Management in der Nordakademie ist mir nochwas aufgefallen: Ideen nehmen manchmal merkwürdige Wege. Wir Softwareentwickler haben mit der ganzen agilen Softwareentwicklung die Prinzipien von Lean Production, Lean Product Development und Lean Management aus dem produzierenden Gewerbe (vor allem: Toyota) genommen und auf IT übertragen.
Jetzt kommt anderes produzierendes Gewerbe an und sagt: "Die ITler sind ja immer ganz vorne mit dabei. Die machen Scrum. Wie können wir das bloß auf unsere Probleme übertragen?"
Dabei müssten sie doch nur gucken, was Toyota macht. Das sollte sich sich deutlich einfacher übertragen lassen. Aber vielleicht ist das zu langweilig?

Agil: Wann was bewerten?

2007-09-30T13:34:00.000+02:00

Vor kurzem habe ich zusammen mit meinem Kollegen Henning Wolf einen Workshop bei der Nordakademie zum Thema Lean Management und Scrum mitgestaltet. Für uns war es eine besondere Erfahrung, weil unter den Teilnehmern so gut wie niemand war, der Software entwickelt. Ca. die Hälfte der Teilnehmer beauftragt die Entwicklung oder Einführung von Software, die andere Hälfte entwickelt physikalische Dinge wie Züge, Tablettenpressmaschinen oder Gabelstapler - individuell oder in Serie.
In diesem Sinne hatten wir interessante Diskussionen, die sich vor allem um die Frage drehte, wie man mit den Scrum-Sprints umgehen soll: Bei der Entwicklung eines Zuges hat man erst sehr spät den Zug und kann den nicht bereits am Anfang dem Kunden zeigen. Außerdem stand die Frage im Raum, wie man vom klassischen Vorgehen schrittweise in Richtung Scrum kommt. Dabei hat sich herauskristallisiert, dass es drei zusammenhängende Aspekte gibt, die man gemeinsam in Richtung Scrum entwickeln muss:

Was wird präsentiert?

Wem wird es präsentiert?

Wann wird es präsentiert?

Klassisch hat man einen Projektplan mit Meilensteinen. Bezogen auf die o.g. Fragen gilt für das klassische Projektvorgehen:

Was wird präsentiert? Immer unterschiedlich, je nach Meilenstein. Mal eine Konzeption, mal ein physikalisches Teil.

Wem wird es präsentiert? Manchmal dem Kunden. Häufig gibt es aber gar keinen richtigen Kunden für das, was das präsentiert wird. Es sind nur interne Dokumente.

Wann wird es präsentiert? In unregelmäßigen Abständen, jeweils wenn ein Artefakt fertig ist. Wenn es zum geplanten Zeitpunkt nicht fertig ist, wird der Termin häufig verschoben.

Scrum hingegen fordert:

Was wird präsentiert? Das, was der Kunde später auch bekommt, wofür er bezahlt.

Wem wird es präsentiert? Dem Kunden. Wenn es ein Serienprodukt für viele (vielleicht anonyme) Kunden ist, übernimmt ein Kundenvertreter (Produktverantwortlicher) die Kundenrolle.

Wann wird präsentiert? In der Regel alle 2 bis 4 Wochen, aber auf jeden Fall in regelmäßigen Abständen (Timeboxing).

Wie kommt man jetzt von Meilensteinen zu Scrum? Der erste Schritt ist einfach: Man macht Punkt drei genauso wie Scrum es fordert: Man definiert einen festen Rythmus, in dem man den Projektfortschritt bewertet und ggf. die Pläne anpasst. Seine Meilensteine kann man erstmal parallel dazu bestehen lassen. Es ist jedoch das Ziel, die Meilensteine komplett zu ersetzen.
Und jetzt muss man sich für die Punkte eins und zwei schrittweise an Scrum annähern. Derjenige, dem präsentiert wird, muss dem Kunden immer ähnlicher werden und das, was präsentiert wird, muss dem immer ähnlicher werden, wofür der Kunde bezahlt.
Das wird im ersten Schritt häufig bedeuten, dass man intern einen Kundenvertreter benennt, der den Kunden vertritt - selbst dann, wenn es einen echten Kunden gibt. Wenn sich mit dem Kundenvertreter das Vorgehen intern eingespielt hat, lädt man den Kunden zu den Präsentationen mit ein. Und schließlich kommt der interne Kundenvertreter nicht mehr. im gleichen Zuge wie der interne Kundenvertreter durch den echten Kunden ersetzt wird, muss sich das Artefakt ändern, das präsentiert wird. Schließlich muss der Kunde auch bewerten können, was er präsentiert bekommt. Und hier ist es natürlich auch bei der Entwicklung physikalischer Dinge so, dass man sie in Einzelkomponenten zerlegen kann. Und diese Einzelkomponenten werden weitgehend unabhängig voneinander entwickelt und getestet. Einige Einzelkomponenten können also auch bereits lange vor Ende des Projektes präsentiert werden. Und dort wo es nicht geht, muss man Dinge finden, die der Kunde versteht: Prototypen, Konzepte und Präsentationen in der Sprache des Kunden etc.

Fazit 1: So anders ist die Entwicklung physikalischer Dinge auch wieder nicht.
Fazit 2: Das skizzierte Vorgehen funktioniert genauso gut für Softwareprojekte, die den Sprung ins kalte Scrum-Wasser scheuen und sich lieber schrittweise vorarbeiten wollen.

Power-Point bei Google

2007-09-21T21:35:00.000+02:00

Neben einem Word- und einem Excel-Ersatz gibt es bei Google Docs jetzt auch ein Programm für Präsentationen. Von Power-Point-Ersatz kann bisher aber leider nicht die Rede sein. Man kann lediglich ein paar Texte und Listen anordnen. Das ging mit dem Word-Ersatz eigentlich auch schon ganz gut. Es fehlen die Möglichkeiten für Grafiken.

Von den Features her ist Zoho Show da deutlich weiter.

Video-Podcast zu Hibernate

2007-07-16T22:03:00.001+02:00

Bernd Oesterreich hat Robert und mich zum Hibernate-Buch interviewt. Aufgrund terminlicher Probleme fehlen Arno und Sebastian.

Agile Werbefilme

2007-07-16T21:44:00.000+02:00

Zur Zeit läuft unter dem Titel Agile Advert ein Wettbewerb, um den besten agilen Werbfilm (Bewertung läuft über You-Tube).
Da sind schon ein paar interessante Filmchen dabei - der Lego-Film zum Build-Prozess ist übrigens von uns (namentlich von meinem Kollegen Andreas).

XP-Day: Call for Sessions

2007-07-16T21:39:00.000+02:00

Der Call-For-Sessions für den XP-Day 2007 im November in Karlsruhe wurde verlängert. Neue Deadline ist der 22.07.2007. Seine Vorschläge kann man bequem hier elektronisch einreichen.