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

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.

Post bewerten

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

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.

Post bewerten

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

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.

Post bewerten

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

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.

Post bewerten

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

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.

Post bewerten

Rezension zu: Refactorings in großen Softwareprojekten

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...

Post bewerten

Ab in den Hyperraum

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.

Post bewerten

Stories schneiden

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.

Post bewerten

Studie zu Projektmanagement

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

Post bewerten

Blog-Einträge jetzt bewertbar

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

Post bewerten

Pull und Kanban - über die Entwicklung hinaus

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!

Post bewerten

Direkte Kommunikation in Konfliktsituationen

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.

Post bewerten

Pecha Kucha

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.

Post bewerten

Präsentieren mit ZEN

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.

1. 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?
2. 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?
3. 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.

Post bewerten

Wann auf TDD verzichten?

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

1. Ich exploriere, ob und wie etwas funktioniert (z.B. eine neue Technologie).
2. Es gibt ein definitives Datum in der nahen Zukunft, ab dem das System nicht mehr weiterentwickelt und irgendwann stillgelegt wird.
3. 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.

Post bewerten

stilversprechend.de

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.

Post bewerten

Stehen, stehen, immer nur stehen?

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.

Post bewerten

Artikelserie Perspektivenwechsel in Java-Magazin und auf JAXenter

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.

Post bewerten

Toyoto Product System Details

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

Post bewerten

One Piece Flow

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.

Post bewerten

Kundenorientierung und Kommunikation extrem

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?".

Post bewerten

XP and Frameworks

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.
  

Post bewerten

Technical Debt

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

Post bewerten

Color Modeling

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.

Post bewerten

TDD-Einsichten

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/

Post bewerten

W-JAX: Hochperformante Webanwendungen

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.

Post bewerten

CookieSwap

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.

Post bewerten

Clipboard2Web mit Zuschneiden

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.

Post bewerten

Clipboard2Web-Service ist online

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.

Post bewerten

Scrum und XP

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.

Post bewerten

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Post bewerten

Hossa: Acrobat Reader

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.

Post bewerten

WerKannWann mit Uhrzeiten

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:

1. 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.
   
2. Man muss die Uhrzeiten nicht umständlich eintippen, sondern kann sie mit coolen Slidern definieren.
3. 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.
4. 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.
   
5. 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.

Post bewerten

Software-Putzer?

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.

Post bewerten

Priorisierung von Features

mal eine neue nette Idee zum Thema von David Anderson

Post bewerten

Aufgaben schätzen oder Aufgaben schneiden?

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.

Post bewerten

Wie misst man technical debt?

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...

Post bewerten

Einladung zu den XP-Days Germany 2008 in Hamburg

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!

Post bewerten

Scrum auf der ADC

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.

Post bewerten

Scrum-ban

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.

Post bewerten

Sind Aufwandsschätzungen Verschwendung?

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.

Post bewerten

Technical Debt und das geistige Taskboard

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?

Post bewerten

Können Anwender/Fachexperten modellieren?

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.

Post bewerten

TeamSpider

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.

Post bewerten

Taskboard: Gute geklaut...

...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:

1. Blockaden/Hindernisse
2. 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.

Post bewerten

Google-Testing-Blog: Testing Against Interfaces

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:

1. 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).
2. 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.

Post bewerten

Bug oder Featurewunsch?

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.

Post bewerten

Deadline der XP-Days Germany verlängert bis 27.07.2008

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

Post bewerten

Lisp auf der Java-VM

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

Post bewerten

Testen mit C++, EXPECT und ASSERT

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."

Post bewerten

Separation of Concerns: Application Logic vs. Creation Logic

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.

Post bewerten

REST für Geschäftsanwendungen

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.

Post bewerten

InfoQ: Komplexität rund um Einfachheit

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.

Post bewerten

XP-Days Germany 2008: Call for Sessions

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.

Post bewerten

Erst wenn...

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!"

Post bewerten

Übersichtsartikel zu eXtreme Programming

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.

Post bewerten

Software-Architektur mit Dependency-Injection

Ü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.

Post bewerten

Grails-Anwendung: Team-Radar ist Live

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.

Post bewerten

Junit 4.4: assertThat

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.

Post bewerten

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

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

Post bewerten

Zertifizierung durch Community

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...

Post bewerten

Verteilte Meetings mit Card-Meeting

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.

Post bewerten