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

mein erstes Grails-Projekt

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.

Post bewerten

neues Buch zu Scrum

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.

Post bewerten

Korrektur zur DAO-Aussage im Hibernate-Buch

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.

Post bewerten

Screencast zum Vortrag "Einfachheit in Softwareprojekten"

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.

Post bewerten

die zweite Internet-Blase?

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

Post bewerten

Lohnt sich Dependency-Injection

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.

Post bewerten

Warum einfach, wenn es auch kompliziert geht?

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.

Post bewerten

Interview mit Weinberg

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

Post bewerten

Wie viele Blogs?

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?

Post bewerten

Audio gesucht zu "Einfachheit in Softwareprojekten"

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.

Post bewerten

Termine, Termine, Termine

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.

Post bewerten

Dynamic Languages Shootout auf der OOP

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

Post bewerten

13949712720901ForOSX

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.

Post bewerten

W-JAX: REST-Vortrag

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.

Post bewerten

XML...

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

(Danke an Sebastian für den Link)

Post bewerten

W-JAX 2007

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:

Post bewerten

XP-Days 2007

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.

Post bewerten

Klassen und Methoden im Wandel

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.

Post bewerten

Ideenfluss

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?

Post bewerten

Agil: Wann was bewerten?

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:

1. Was wird präsentiert?


2. Wem wird es präsentiert?


3. Wann wird es präsentiert?

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

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


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


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

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


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


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

Post bewerten

Power-Point bei Google

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.

Post bewerten

Video-Podcast zu Hibernate

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

Post bewerten

Agile Werbefilme

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

Post bewerten

XP-Day: Call for Sessions

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.

Post bewerten

Oho Zoho

Ich hatte gejammert, dass Google zwar Word- und Excel-Clones für das Web anbietet, aber nichts für Power-Point. Ich wollte auch gar keine Präsentation im klassischen Sinne erstellen. Wir mussten aber kooperativ an einer Abbildung arbeiten. Und das mit Hin- und Herschicken von Power-Point-Dateien zu machen, ist einigermaßen umständlich.

Mein Bruder Arne wusste aber Rat: Zoho bietet eine kostenlose Präsentationssoftware als Web-Anwendung, mit der man kooperativ auch Abbildungen erstellen kann. Und ich konnte sogar unsere bereits mit Power-Point begonnene Abbildung importieren.

Interessanterweise hat Zoho nicht nur einen Power-Point-Clone im Angebot, sondern auch noch einen Word-Clone, einen Excel-Clone, eine Planungssoftware mit ToDo-Listen und Kalender, ein Wiki, ein CRM-System etc (siehe http://www.zoho.com). Also deutlich mehr als z.B. Google zu bieten hat. Nach kurzem Draufgucken sah das ganze auch sehr passabel aus.

Aber es gibt leider einen Pferdefuß: Die Performance ist nicht ausreichend für professionellen Einsatz. Für den Power-Point-Clone kann ich damit leben, weil ich keine Alternative kenne. Aber bei den anderen Services nehme ich dann doch lieber andere Anbieter.

Aber vielleicht kriegen die Zoho-Leute die Performance-Probleme ja noch in den Griff.

Post bewerten

Technorati

Jetzt bin ich auch bei Technorati.

Technorati Profile

Post bewerten