Johannes Link stellte auf Twitter eine sehr interessante Frage:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer wasserfall-artigen Arbeitsaufteilung?

(Im Dialog mit Johannes, den Sie auf Twitter nachlesen können, hatte ich Probleme, in 140 Zeichen darzustellen, was ich meine, deshalb hier dieser ausführliche Blog-Artikel.)

Der Grund für das, was die Kanban-Fans tun, ist wohl dieser: In Kanban gibt es fünf Schritte oder Kern-Eigenschaften der Methode:

1. Visualisiere den Workflow
2. Limitiere angefangene Arbeit (work in progress)
3. Messe und manage den Fluss
4. Mache Prozessrichtlinien explizit
5. Benutze Modelle (wie z.B. ToC), um Möglichkeiten zur Verbesserung zu erkennen

Der erste Schritt “Visualisiere den Workflow” tut genau das: Auf einem Taskboard stellt man dar, wie der aktuelle Workflow des/der Teams gerade ist. Nicht mehr und nicht weniger. Manche Teams beginnen mit Spalten wie “backlog, in progress, done” wie in XP oder Scrum und machen gute Erfahrungen damit. Andere Teams fügen weitere Spalten hinzu, wenn sie glauben, dass es nötig ist.

Beispiele für Workflow-Visualisierung

Ein Beispiel: In einem Scrum-Team, das ich aktuell coache, erkannten wir in einer Retrospektive, dass die Entwickler die Features oft sehr zeitnah entwickelten, die Karten auf dem Taskboard aber trotzdem sehr lange Zeit in der Spalte “in progress” verbrachten.

Der Grund war: Unsere Definition of Done schrieb vor, dass der Akzeptanztest durch den Product Owner Bestandteil des Begriffes “done” sein musste. Der Product Owner war jedoch in weiteren Projekten involviert und hatte fast nie sofort Zeit zu testen, sobald ein Feature fertig geworden war. Es bildete sich beim P.O. ein “Test-Stau” mit unangenehmem Ergebnis: Es gab öfters einmal ungetestete Karten, die dann eben nicht zum Sprint-Ergebnis gezählt werden konnten und sollten.

Dies wollten die Entwickler sichtbar machen und fügten dem Taskboard eine Spalte “acceptance test” hinzu. Nun konnte man erkennen, wie sich dort die Karten stapelten bis der Product Owner sie gegen Ende des Sprints abräumte – eine risikoreiche Vorgehensweise.

Ein anderes Scrum-Team, das ich kenne, verwendet eine separate Spalte mit der Überschrift “GUI design”. Dort werden Karten aufgehängt, die fast fertig entwickelt und auch schon inspizierbar sind, jedoch noch ohne eine richtig schöne und ergonomische Oberfläche, die danach erst durch eine externe UI-Designagentur geschaffen wird. Erst wenn die UIs von dort zurückkommen, wird die Karte auf “acceptance test”, danach auf “done” geschoben.

Vom Workflow zum Wasserfall

Zurück zur Frage von Johannes: Warum zeigen die Kanban-Leute wasserfall-artige Taskboards? Antwort: Sie tun es nicht – sie zeigen lediglich Workflows. Was ist der Unterschied? Ein Workflow ist einfach eine Reihe von Arbeitsschritten, die hintereinander ausgeführt werden. Um daraus einen Wasserfall zu machen, muss man mindestens noch folgende negative Eigenschaften hinzufügen:

1. Das “100% Losgröße”-Syndrom: Man führe jeden Workflow-Schritt mit 100% aller Anforderungen durch und gehe erst danach zum nächsten Schritt des Workflows. Auf keinen Fall das, was schon getan ist, schon mal in den nächsten Workflow-Schritt weiterreichen – das könnte ja unvollständig aussehen!
2. Das Isolations-Syndrom: Man lasse die Leute, die in einem Workflow-Schritt arbeiten, auf keinen Fall mit den Leuten aus einem anderen Workflow-Schritt zusammenarbeiten. Also darf ein Analyst niemals mit einem Architekten und dieser auch niemals mit einem Entwickler reden – alle dürfen nur über Dokumente miteinander kommunizieren, die durch ausführliche Reviews abgesichert und dann unterschrieben sind.

Kanban geht gegen den Wasserfall vor

In Kanban ist beides nicht der Fall. Mit der Kanban-Methode versucht  man im Gegenteil die Durchlaufzeit eines Features durch den Workflow zu minimieren. Wer Littles Gesetz kennt, weiß, dass das mit 100% aller Anforderungen nicht geht, sondern je weniger “work in progress” (angefangene Arbeit) man hat, desto kürzer ist die Durchlaufzeit. Deshalb limitiert man in Kanban die Zahl der gleichzeitig in Arbeit befindlichen Features.

Jeder, der arbeitet, soll die Gelegenheit haben, sich zu konzentrieren – also limitiert man die Zahl der Features z.B. auf 4, wenn man 3 Entwickler hat. Die drei Entwickler sollten im wesentlichen immer an je einem  Feature arbeiten, es sei denn, dieses ist blockiert, weil man auf eine Antwort wartet oder weil eine Ressource fehlt, die man braucht. Dann darf man sich ausnahmsweise ein 4. Feature ziehen.

Je geringer die Menge gleichzeitig angefangener Arbeit, desto geringer ist auch die Zahl der Fehler, die man einbaut. Menschen arbeiten wesentlich korrekter, wenn sie konzentriert sind. Dies reduziert die Zahl der Überarbeitungen, die notwendig sind, um ein Vielfaches!

Auch die Isolation, die im Wasserfall typisch ist, gibt es in Kanban nicht. Da Kanban aus dem agilen Umfeld stammt, ist Kommunikation ein hohes Gut. Man sollte immer mit den Leuten reden, die am selben Feature gearbeitet haben oder arbeiten werden wie man selbst. Der Entwickler wird den Business Analysten oder den Architekten fragen, der Tester wird den Entwickler fragen, was hinter gewissen Zusammenhängen eigentlich steckt. Viel besser ist es natürlich, wenn Business Analyst und Entwickler zum selben cross-funktionalen Team (wie in Scrum) gehören und das Feature gemeinsam analysieren und realisieren.

Die Kraft des Vakuums

Oben habe ich das Beispiel mit dem überlasteten Product Owner erwähnt, bei dem sich ein Test-Stau bildete. In Scrum würde man dies jetzt auf die Impediment-Liste des Scrum-Masters schreiben und dieser würde gegen den Effekt zu kämpfen beginnen. In Kanban würde man das vermutlich folgendermaßen lösen: Man würde für die Spalte “acceptance test” ein WIP-Limit einführen und z.B. auf die Menge einschränken, die der Product Owner in einem Time-Slot, den er sich bei seinen vielen Projekten nimmt, bewältigen kann. Hat er ab und zu mal zwei Stunden Zeit und kann darin 3 Features sauber testen, so würde man das “work in progress”(WIP)-Limit auf 3 setzen. Was würde dann passieren?

Schließen Sie die Augen und überlegen Sie eine Minute, bevor Sie weiterlesen!

Die Entwickler würden jedesmal, wenn sie etwas fertig haben, eine Karte in die Spalte “acceptance test” schieben. Kommt der Product Owner nicht zum Testen und enthält die Spalte nun 3 Karten, würden die Entwickler einfach aufhören zu entwickeln. Sie würden stattdessen vielleicht refaktorisieren, Urlaub machen, Schulungen besuchen, Kaffee trinken oder andere sinnvolle Tätigkeiten durchführen. Beim morgendlichen Stand-Up würden sie diese Tatsache auch sofort bekanntgeben.

Das Risiko, den Sprint mit einer ungetesteten Featuremenge zu beenden, würde dadurch drastisch abnehmen. Das Team inklusive P.O. wäre plötzlich als Gesamtsystem erkennbar, das einfach nicht in der Lage ist, mehr zu leisten als der P.O. fertigbekommt. Der P.O. wäre ganz klar als Bottleneck erkennbar.

Was würde als nächstes passieren, wenn niemand interveniert? Denken Sie einen Moment nach…

Das Vakuum greift um sich

Wenn die Entwickler weniger tun, staut sich plötzlich alles im Backlog zurück. Nehmen Sie an, wir hätten mittels Kanban auch die Länge des Backlogs limitiert. Die Leute, die bisher dem Product Owner geholfen haben, Features zu beschreiben und ins Backlog zu bringen (nennen wir sie “fachliche Analysten”), wären dann plötzlich ebenfalls arbeitslos, weil sie nichts mehr in das bereits volle (weil limitierte) Backlog stellen dürfen.

Oh, hier haben wir Analysten, also fachlich geschulte Leute, die frei sind! Was tun wir mit denen? Wir machen sie zu Testern, die zunächst einmal den Stau von Akzeptanztests abbauen und dadurch den P.O. entlasten. Damit wird die Spalte “acceptance test” wieder frei, die Entwickler nehmen die Arbeit wieder auf und produzieren wieder. Im Backlog werden dadurch wieder Plätze frei, also können die Analysten ihre eigentliche Arbeit wieder aufnehmen und neue Backlog-Items produzieren. Der Propfen löst sich.

Von der Taktik zur Strategie

Das gerade geschilderte Verhalten ist sicherlich nicht optimal, doch hat es erst einmal geholfen. Das Management wird inzwischen von der Aktion gehört haben und sich entscheiden, mehr Tester einzustellen, die dem Product Owner helfen. Die Tester kommen langsam auf Touren und der Propfen wird sich dann nicht mehr bilden müssen.

Die Antwort auf die Frage nach dem Wasserfall

Johannes Frage von oben könnte man nun anders formulieren:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer so ausführlichen Arbeitsaufteilung (so viele Spalten auf dem Taskboard)?

Weil sie zeigen wollen, was wirklich passiert. Das dreispaltige Scrum-Taskboard zeigt eben nicht, dass in der Sprint-Mitte typischerweise viel WIP entsteht, besonders bei unreifen Scrum-Teams, die noch nicht lange dabei sind. Führt man mehr Spalten ein, bildet man die Realität im Team u.U. besser ab und kann auf Effekte aufmerksam machen, die man vorher übersehen hat.

D’accord, Johannes?

Ich hatte mich entschieden, auf meinem Acer Aspire One Netbook eine neue Linux-Version (Ubuntu 10.04) zu installieren. Klappte auch wunderbar. Ubuntu heruntergeladen und auf einen USB-Stick geschrieben, mit dem Stick den Rechner gebootet und Ubuntu ganz einfach parallel zu Windows auf der Festplatte installiert. Rechner neu gebootet, und ich konnte mit Ubuntu oder Windows arbeiten, je nachdem, wie ich Lust hatte.

Doch leider: Beim einem der nächsten Restarts der Maschine kam es zu einem Black Screen Of Death, einem in der Acer-Community offenbar wohlbekannten Problem mit einem nicht mehr startbaren BIOS: Schwarzer Bildschirm nach dem Einschalten, keine Bootmeldungen, voller Stopp!

Gott sei Dank war das Problem relativ leicht zu beheben:

• Neues BIOS von der Acer-Supportseite laden.
• Auf einen frisch formatierten USB-Stick schreiben.
• Diesen magischen Anweisungen folgen und derweil beschwörende Sprüche murmeln.

Der Aspire One war danach wieder einsatzbereit. Manchmal hat man doch wirklich Glück, obwohl man es herausfordert.

Die Softwarearchitektur ist ein wichtiges Artefakt der Softwareentwicklung. Softwarearchitekten müssen kommunikationsstark sein, für die Durchsetzung der Architektur in den Projekten sorgen usw. Das ist die öffentliche Meinung. In der Projektrealität sieht es meist anders aus: Architekturdokumente werden mühsam erstellt, doch im Alltag nicht gelesen. Architekten versuchen, durch Predigen die Einhaltung der Architektur zu erreichen. Teams entwickeln, auch ohne auf die Architektur zu achten. Was wäre, wenn man Architektur emergieren lassen würde, quasi als “Ergebnis des Schwarms”, anstatt sie mit viel Kraft in Einzelleistung zu erstellen? Die folgende Geschichte ist ein Kondensat meiner Erfahrung aus vielen Projekten. Lesen Sie, warum Architektur letztlich nicht von Einzelnen gemacht werden kann, und erfahren Sie, was nötig ist, damit Emergenz möglich wird.

Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.

Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!

Hey, Uncle Bob is back at OOP,! For me this is very special because it was him who brought me to object oriented design/programming and to my first OOP conference, ever. And this was back in 1992 when I was a enthusiastic software developer, coding in C. Java did not exist in those days, design patterns were not published, there was no TDD – well, it was just the old days of poorly maintainable code!

Bob, when I came into your workshop about object oriented design at OOP, you started with a very simple example in C++ (at least, I thought it was): a car with an engine. You said something like this:

Bob: “OK, guys, lets define an accelerate() method on the car – what would be inside the body of this method?”. And my head started thinking. Somebody else: “The car should tell the carburator to increase the fuel to air ratio. And it should also tell the automatic transmission to shift one gear up!”

Bob: “OK, so Car::accelerate() calls Carburator::increaseFuelToAirRatio(), followed by Transmission::shiftUp(). Question to all of you: Is this a good design or a bad design?”

And poor me, inexperienced in OOD, could say neither yes nor no: “In fact, I don’t know!”.

Bob, you suddenly shouted “Of course, it is a BAD design, very bad design!”

Me: “Oh, why this?”

Bob: “What if you have a Diesel engine, without carburator? And: What if your car has an electric engine, without transmission?”

Me: “Hmmm… well, I guess, I would have to change the design significantly. Something like Thyristor::increaseElectricCurrent().”

Bob: “Exactly! So, how about introducing a neutral abstraction above all this? How about Engine::increasePower()? And with an intelligent Engine class that knows how to increase the power purely by itself? With nobody telling it how to do that?”

Me: “Aha!”

And so 1992 was the year when I became enthusiastic about object oriented design. Thanks a lot, Bob – I am really looking forward to see you again at this OOP. I guess, you won’t remember me but this is not a problem.

This is an interesting phenomenon that I am trying to study and understand. Maybe, it is possible to generate something entirely new.

Kunde: “Wir verstehen unser Framework nicht mehr. Es ist total verstrickt!”

Berater: “Aber Ihr habt doch gesagt, es sei erst zwei Jahre jung.”

Kunde: “Ja, und?”

Berater: “Sowas passiert doch sonst nur mit viel älterer Software!”

Kunde: “Nein, hier waren viele Externe vom Dienstleister XY dabei, da altert das Framework schneller!”

Berater: “Oh!???”

• Fixed a bug that caused a MissingPropertyException when user typed an OpenID that did not have a valid provider address
• Fixed a bug that caused a NullPointerException when user’s OpenID contained syntactical errors
• Simplified code in the controller so that it is now independent of the configured URL mapping

You can find more information about the plugin on the plugin’s Wiki page.

SplendiCon ist ein solches Produkt. Ich habe es vorige Woche online geschaltet. Es ist ein System, mit dem Sie Ihre eigene Konferenz organisieren können. Autoren/Sprecher/faszinierende Personen einladen, Beiträge in SplendiCon hochzuladen, mit einer Kurzbeschreibung und einer Datei. Qualifizierte Experten als Reviewer für diese Beiträge gewinnen und deren Ergebnisse einsammeln. Konflikte zwischen diesen Ergebnissen erkennen und in einer Programmkonferenz lösen. Zum Schluss das Konferenzprogramm, das verabschiedet wurde, downloaden.

Es hat Freude gemacht, dieses System in Groovy auf Basis von Grails zu entwickeln. Es läuft auf Tomcat, davor übernimmt Apache 2 die Rolle des Reverse Proxy, managt die SSL-Verbindungen und zeichnet die Webzugriffe im Logbuch auf. MySQL ist die verlässliche Datenbank im Backend. Linux als bewährtes Serversystem werkelt oberhalb der Silizium-Ebene und macht die Kraft der AMD-Prozessoren zugreifbar. SplendiCon spricht mit Paypal, dem Bezahldienst, sobald jemand eine Lizenz für eine Konferenz kauft.

Das Ganze performt sehr schön – ich bin gespannt, wie es weitergeht, sobald die Userzahlen steigen.

SplendiCon wird unterstützt von einem User Forum, in dem die Benutzer Fragen stellen und Antworten bekommen. Auch ein Bugtracker ist online, er nimmt Fehlermeldungen und neue Anforderungen auf.

Ich lade alle, die sich mit der Organisation von Konferenzen befassen, herzlich auf die SplendiCon-Plattform ein. Surfen Sie vorbei: http://www.splendicon.net oder melden Sie sich auf Twitter: @splendicon .

New features:

• The plugin now supports purchases with multiple items (using whatever shopping cart you like). Thanks to Matt Stine for the code!
• The plugin now records the information about the buyer that is supplied by Paypal after each transaction. This information includes name, address and email address, for example.

Bugs fixed:

• In some rare situations when an Apache reverse proxy was running as a front end for the Tomcat engine, the plugin could not redirect back to the original URI in case of an invalid payment. I replaced the URI by an absolute URL, now it works. Users of the plugin: Please change the parameter originalURI to originalURL and supply an absolute URL when you use the Paypal button tag, like this:

<paypal:button
    ...
    originalURL="${createLink(absolute: true, controller: controller, action: action, params: params)}"
/>

For users of Paypal Plugin V0.3: The schema has changed, the database needs to be migrated!

You can find the plugin homepage here.

Today, I released V0.3 of the Paypal plugin. You can install it as usual with

• grails install-plugin paypal

A description of the plugin is available at:

• http://grails.org/PayPal+Plugin

The main changes in release 0.3:
Bugfix:

• The plugin now gives a proper response to Paypal when Paypal sends an IPN. Before, the plugin did not send a response so that Paypal repeated the IPN message several times.

New feature:

• Analogous to the parameters ‘returnController’ and ’returnAction’, we now have ‘cancelController’ and ‘cancelAction’. You can specify a controller and an action to process the cancellation of a payment.

More changes are on the way. Matt Stine has written code that allows you to purchase an entire shopping cart full of items instead of a single item as the plugin can do today. The new code is still under test.

Cheers,
Matthias

Ich freue mich darauf, Sie am 30.6., 1.7 und 2.7. in diesem Vortrag zu sehen und mit Ihnen innovative Ideen zu diskutieren!

Mehr Info dazu finden Sie bei SIGS DATACOM.

1. Servlet Filter before chain.doFilter() (Acegi runs here)
2. GrailsDispatcherServlet.doDispatch() starts
3. Spring MVC Interceptors preHandle() (OSIVI opens session)
4. Grails Filters “before” closure
5. Controller beforeInterceptor
6. Controller action
7. Controller afterInterceptor
8. Grails Filters “after” closure
9. Spring MVC Interceptors postHandle
10. View rendering
11. Grails Filters “afterView” closure
12. Spring MVC Interceptors afterCompletion() (OSIVI closes session)
13. Grails DispatcherServlet.doDispatch() ends
14. Servlet Filter after chain.doFilter() (Sitemesh runs here)

Uff!

Leider gab es bei mir ein Problem: Ich habe eine Grails-Anwendung mit einem deutschen und einem Default-Bundle, das englische Texte enthält und immer dann zum Zuge kommen soll, wenn die Sprache des Browser-Clients eben nicht Deutsch ist. Also:

• messages_de.properties für Deutsch
• messages.properties für alle anderen Sprachen

Ich stellte meinen Browser auf Deutsch ein – alles wunderbar, die deutschen Texte kamen einwandfrei. Ich stellte den Browser auf Englisch ein – Enttäuschung: es kamen immer noch deutsche Texte!

Nach einigem Suchen im Quellcode von Grails (ValidationTagLib.groovy) fand ich heraus, dass für die Übersetzung ein Objekt vom Typ ReloadableResourceBundleMessageSource aus dem Spring-Framework verantwortlich ist. Dieses hat eine Property fallbackToSystemLocale, die auf true oder false stehen kann. Sie steht standardmäßig auf true, das heißt, wenn kein Text für das eingestellte Locale gefunden wird, wird nicht etwa der Text aus dem Default-Bundle genommen, sondern noch einmal in demjenigen Message-Bundle gesucht, das dem “system locale” entspricht. Meine Servermaschine läuft auch auf Deutsch, so dass nochmals auf die Texte in message_de.properties zugegriffen wurde.

Abhilfe:

Jetzt war klar, dass diese Property während der Initialisierung auf false gesetzt werden muss. Mit folgenden Zeilen in Boostrap.groovy war der Fehler behoben:

import org.codehaus.groovy.grails.commons.ApplicationAttributes

def init = { servletContext ->
    def ctx = servletContext.getAttribute(ApplicationAttributes.APPLICATION_CONTEXT)
    def messageSource = ctx.getBean("messageSource")
    messageSource.fallbackToSystemLocale = false
}

Wenn jetzt ein Request mit englischem Locale eintrifft, wird auf messages.properties zugegriffen, das ergibt das gewünschte Verhalten.

Heute hatte ich einen alten Film in Zweikanalton, der nach dem Digitalisieren (mit EyeTV) in Stereo mit zwei Sprachen wiedergegeben wurde (links Englisch, rechts Deutsch). Wenn ich diesen ohne Zögern auf DVD gebrannt hätte, würde die Zweisprachigkeit beim anschließenden Anschauen der DVD etwas gestört haben.

Also habe ich in EyeTV zunächst einmal Bild und Ton getrennt (demuxing im Menü Ablage, Exportieren, Format = MPEG Elementary Streams). Es ergaben sich eine *.mpv (Video) und eine *.mpa (Audio) Datei.

Die *.mpa Datei habe ich dann mit dem Audio-Editor Audacity in zwei Spuren geteilt, dann jeweils eine gelöscht und die andere als Mono-Audio-Datei im WAV-Format exportiert. Dabei den Pegel der englischen Spur noch etwas angehoben, denn er war geringer als der der deutschen Spur.

Die beiden WAV-Dateien habe ich dann mit ffmpegX nach Dolby Digital (*.ac3) konvertiert, mit 228 kBit pro Sekunde, um das Audioformat zu benutzen, das die Mehrzahl der DVD-Player (so sagt man im Netz) abspielen können. Danach konnte ich die Videodatei (*.mpv) wieder mit den beiden Dolby-Audio-Dateien “muxen”, ebenfalls mit ffmpegX. Das Ergebnis war eine neue MPEG-Datei, diesmal jedoch nicht mit einer Stereo-Audio-Spur, sondern mit zwei Dolby-Mono-Spuren.

Schließlich habe ich Windows XP unter Parallels hochgestartet und dort das Programm DVDFlick gestartet. Die MPEG-Datei habe ich importiert und bei jeder Audio-Spur separat angegeben, in welcher Sprache sie aufgenommen ist (Englisch, Deutsch). Jetzt am DVD-Anfang noch ein Menü hinzugeben, das die Auswahl der Sprache erlaubt, danach alles als ISO-Image generieren lassen, fertig ist die bilinguale DVD!

DVDFlick erzeugt am Anfang der DVD ein Menü, das noch wenig schön ist, doch damit kann ich leben. Ich habe sonst keinen freien DVD-Editor gefunden, der es erlaubt, die Sprache der Audiospuren festzulegen. Überhaupt ist DVD-Authoring anscheinend eine durchaus nicht-triviale Aufgabe, wie man an der großen Anzahl von kleinen Tools für diese Aufgabe erkennen kann.

House of the Rising Sun

Der Rest der Organisation bekommt langsam mit, dass Scrum ein erfolgreiches, motivierendes Verfahren sein könnte. Ich wurde gebeten, einen Vortrag darüber zu halten, was ich natürlich gern getan habe.

Das zweite Sprint-Planning ging viel besser als das erste – Stories in Tasks zerlegen und schätzen, Over- und Undercommitments ausbalancieren, alles diesmal sehr einfach und interaktiv. Die hypnotische Wirkung des Projektors, der das Bild des Bugtrackers an die Wand wirft, konnten wir diesmal fast neutralisieren.

Die Daily Scrums im zweiten Sprint gehen wie der Blitz. Die Teammitglieder haben schon die Kärtchen verschoben, ehe ich als ScrumMaster noch richtig gucken kann. Bin gespannt, wie es weitergeht.

Wir sollten nun noch einführen, dass wir JPEG-Fotos vom Taskboard jeden Tag per Email an die entfernten Teammitglieder schicken, damit sie wissen, wo das Team steht. Schon habe ich als ScrumMaster wieder eine neue Aufgabe!

Die Runde lief ganz fein, jeder erklärte, was er gestern gemacht hat, was er heute macht und welche Hindernisse im Weg stehen. Mehr oder weniger alle reden mich (den ScrumMaster) an, obwohl ich am Anfang des Meetings extra gesagt habe, dass das Mitteilungen für die Peers sind, kein Statusbericht an mich. Ich bin jetzt im Moment kein Manager!

Das Taskboard enthielt bereits zwei Tasks, die unter “done” einsortiert waren. Also konnten wir den Restaufwand auf dem Burndown-Chart bereits etwas verkleinern.

Mehrere Pigs berichten, dass sie nicht richtig fokussieren können, weil zu viele Chickens von außen Support brauchen. Klar, in den anderen Abteilungen draußen wird u.a. gegen unsere APIs, die wir herausbringen, programmiert. Kein Wunder, dass das legitime Fragen nach sich zieht. Mal schauen, wie viel Fokusfaktor uns das kosten wird.

Ich muss noch eine Wikiseite für die Impediment List anlegen und allen mitteilen, dass sie da ist.

Die Neuigkeit “die im Soundso-Team machen jetzt was Neues, es heißt Scrum” verbreitet sich in den anderen Teams. Einige fragen mich, ob sie auch eine Kopie des Büchleins von Henrik Kniberg bekommen könnten, das ich für die Pigs beschaffen ließ. Natürlich, im Moment sind genug Exemplare vorhanden.

Bin gespannt, wie es weitergeht und wann die erste ganze Story (nicht Task) auf “done” gesetzt wird.

Dieses Video auf YouTube zeigt, wie ein anderes Team (nicht unseres!) Papier sehr kreativ nutzt, um dem Product Owner eine Software vorzuführen, die es noch gar nicht gibt. Viel Spaß beim Anschauen!

Product Backlog, Sprint Backlog, Product Owner, Taskboard, testbare Features, Aufwandsschätzungen, Velocity-Ermittlung, alles da in zwei halben Tagen à vier Stunden! Einen Moment, ich muss zugeben, das Product Backlog haben wir mit dem Product Owner und dem Team schon vorher erstellt und dann in den letzten Tagen des alten Vorgehens ganz penibel sauber gemacht, bevor wir in dieses Planning Meeting gingen – das hat uns lange Diskussionen erspart!

Jetzt bin ich gespannt, was im Daily Scrum passiert…

Nächste Woche geht es los mit dem ersten Sprint für dieses Projekt. Das Projekt hat bisher schon einiges entwickelt, deshalb hatten wir die Idee, diese zurückliegende Zeit als einen gigantischen Sprint aufzufassen, den wir nun offiziell und regulär beenden, bevor wir nächste Woche einen neuen starten.

Wir haben also diese Woche ein Sprint Review Meeting gemacht mit einer Demo des aktuell lauffähigen Standes der Software. Heute habe ich dann mit dem Team eine Sprint-Retrospektive gehalten, eine wirklich tolle Sache.

Eine Metaplan-Wand hatte ich unterteilt in die Bereiche “Start doing”, “stop doing”, “continue doing” und “change”. Dort hefteten die Teammitglieder Karteikarten mit Themen an, die wir entweder neu starten, mit denen wir aufhören oder mit denen wir weitermachen wollen.

Interessant war, dass unter “start doing” bei weitem die meisten Karten angeheftet wurden. Unter “stop doing” tauchten auch einige auf und unter “continue” bzw. “change” ebenfalls einige. Also ist dieses Team der Meinung, dass wir noch vieles neu einführen müssen.

Wir haben die Metaplan-Wand fotografiert und uploaden das Foto ins Wiki. Unter das Foto kommt noch einmal die Liste der Vorschläge, die auf den Karten stehen, um eine Online-Diskussion zu ermöglichen und die Maßnahmen tatsächlich umsetzbar zu machen.

Nebenbei bemerkt: Die Kategorien “start doing”, etc. stellen sich als viel konkreter und motivierender heraus als die an sich äquivalenten, doch viel mehr nach Wertung klingenden Kategorien “good”, “needs improvement” und “bad”.

Ich bin gespannt, wie viele Maßnahmen wir bis zum Ende des Sprints tatsächlich umgesetzt bekommen.

Insert this virtual host declaration in /etc/apache2/vhosts.d/myown_vhost.conf:

<VirtualHost *:80>
ServerName www.myownhost.com
ServerAdmin webmaster@myownhost.com
# don't lose time with IP address lookups
HostnameLookups Off
# needed for named virtual hosts
UseCanonicalName Off
ProxyPass / http://localhost:80xx/
ProxyPassReverse / http://localhost:80xx/
</VirtualHost>

But this was not enough. Some application inside Tomcat calls request.getServerName() and still gets “localhost”. So, inside Tomcat, I had to edit conf/server.xml and modify the connector declaration:

<Connector port="8088"  address="localhost"  proxyName="www.myownhost.com"  proxyPort="80"
... other arguments here ...

After that, everything worked just fine.

For detailed information, see http://tomcat.apache.org/tomcat-6.0-doc/config/http.html