Blog-Einträge jetzt bewertbar

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

Post bewerten

Pull und Kanban - über die Entwicklung hinaus

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

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

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

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

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

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

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

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

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

Post bewerten

Direkte Kommunikation in Konfliktsituationen

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

Post bewerten

Pecha Kucha

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

Post bewerten

Präsentieren mit ZEN

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

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

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

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

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

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

Post bewerten

Wann auf TDD verzichten?

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

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

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

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

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

Post bewerten

stilversprechend.de

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

Post bewerten

Stehen, stehen, immer nur stehen?

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

Post bewerten

Artikelserie Perspektivenwechsel in Java-Magazin und auf JAXenter

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

Post bewerten

Toyoto Product System Details

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

Post bewerten

One Piece Flow

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

Post bewerten

Kundenorientierung und Kommunikation extrem

absolut lesenswerter Artikel

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

Post bewerten

XP and Frameworks

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

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

Post bewerten

Technical Debt

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

Post bewerten

Color Modeling

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

Post bewerten

TDD-Einsichten

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

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

Post bewerten

W-JAX: Hochperformante Webanwendungen

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

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

Post bewerten