Planet OOP 2010

Erfolgreiche Typen haben immer klare Ziele. Ohne Ziele geht nix. ?10% mehr  Umsatz im nächsten Jahr!? oder ?Maximal 1 Bug Report pro Monat im Support? oder ?Feature X bis zum 30.6.2010 realisieren? ? das sind Ziele für echte Männer (und gern auch Frauen, wenn sie sich angesprochen fühlen). Die sind auch total SMART ? ist zumindest in Bezug auf A=Attainable und R=Relevant zu hoffen. Soweit der

Das war mir doch ein Experiment wert: Wie würden es Entwickler aufnehmen, wenn quasi alle Parameter von Methoden (zumindest in den Kontrakten von Komponenten) nicht primitiv sein sollen? Auf dem Coding Dojo in München habe ich es ausprobiert. Das Beispielszenario dort war eine Rechtschreibprüfungsanwendung. In der gibt es dann irgendwo eine Funktion WortKorrekt() o.ä. Deren Signatur würde

Auch mal anonym sein dürfen, ist ne schöne Sache. Keine Frage. Deshalb lieben wir das Bargeld immer noch. Ihm haftet nichts von uns an; damit können wir genauso Geschenke wie ?Schmuddelkram? kaufen, ohne dass eine Spur auf dem Bankkonto entstünde, die uns verraten könnte. Und auch sonst finden wir es entspannend, nicht überall und immer erkannt zu werden. Die Berühmten beneiden wir ja eher nur,

Schon interessant, was zu Wellen im Twitter-Teich führt. Da stolpere ich während der Lektüre von ?Projektmanagement? von Thorsten Reichert beim ?Zusammenfassungsservice? getAbstract über den Satz ?Viele Unternehmen haben nie Zeit, Dinge richtig zu tun, aber stets Zeit, Dinge mehrmals zu tun.? Den twittere ich ? und erzeuge unerwartet weitreichende Reaktionen. Wow! Nicht, dass mich die

Grad kommt alles zusammen. Ich lese einen Thriller über die Evolution, die auf einer abgeschiedenen Insel zu sehr bösen Kreaturen geführt hat (?Biosphere? von Warren Kaye). Dann höre ich Jens Coldewey auf der SET in Zürich, der darüber spricht, wie böse es für Projekte ausgehen kann, wenn sie sich nicht gegen Inseln wehren, gegen Wissensinseln. Und dann spreche ich am selben Tag mit Ivan Engler

Erst ein Feiertag, jetzt ein Sonntag und die Diskussion um ?Null oder nicht Null? geht weiter. Als hätten diese Softwareentwickler nichts anderes zu tun? ;-) Ilker hat versucht, einen ausbalancierenden Schlussstrich unter die Diskussion zu ziehen, um uns wenigstens ein Rest schönes Wetter genießen lassen zu können. Doch mich wurm da noch etwas. Und weil der Stein, an dem ich mich da anstoße, bei

 In Objektspektrum 3/2010 steht ein Artikel auf der Höhe der Zeit: ?Emergente Architektur: Der machtlose Architekt?. Denn davon spricht man auch hier oder hier. Und woanders mag es auch Emergent Design heißen. ?Emergenz? scheint ein neues Zauberwort zu sein. Es bedeutet soviel wie Entstehung von etwas Ganzem, ohne dass dieses Ganze so geplant worden wäre. Eine Termitenbau entsteht auf diese

Habe ich Ihre Aufmerksamkeit? Architekten programmieren nicht, ja das glaube ich ? und stehe damit wohl gegen den (agilen?) Mainstream. Aber etwas ?Gegenstrom? macht frisch und kregel ;-) Wer etwas auf sich hält, sagt mal etwas zur Rolle des Architekten. Nach Lektüre eines weiteren Artikels von Neal Ford habe ich mir gedacht, darin sollte ich anderen nicht nachstehen. Also hier mal einige

This year?s OOP conference in Munich has been a lot of fun. I met Markus Völter, Stefan Tilkov, Floyd Marinescu, Jan Bosch, Eric Evans, Philippe Kruchten, Roman Pichler, Peter Hruschka, Kersten Auel, Rene Schönfeldt,  Klaus Rohe, Matthias Bohlen, Gernot Starke, Jutta Eckstein, Nico Josuttis, Gregor Hohpe, Robert C. Martin, Matthias Bohlen, Kevlin Henney and my good ole friend Frank Buschmann. Especially the networking part was overwhelming. So many speakers and participants you can learn from.The talks and keynotes are definitely helpful to hear about new trends, perspectives and experiences. But the personal communication is the essence of such conferences. That?s the reason why I don?t believe in online events. Sure, it?s a nice add-on but it cannot substitute the ?human? factor. In the middle of the week we had a meeting of the Siemens Senior Software Architects where I enjoyed meeting some of the aforementioned celebrities but also the smart senior architects within Siemens who do excellent work day by day. They might not be that much in the limelight, but those people are  the real heroes of software engineering among all those ?nameless? other heroes such as development heads, team leads, testers or developers. As Jan mentioned: there are two types of architects. Those talking about software architecture and those practicing it. Fortunately, I am a hybrid belonging to both types.

This year?s keynotes  offered excellent quality. I?ll never forget Uncle Bob?s entertaining talk on the polyglot programmer where he dived into the history of programming languages in a very entertaining way. Or two speakers from Zühlke Engineering who presented a great keynote on functional programming. Not to forget Gernot Starke with his talk on software architects and stealing in your neighbor?s garden. Unfortunately, I could not make it to his keynote but from what I heard it was one of the highlights.

Most of the topics presented in talks and tutorials covered the typical topics you?d expect. Cloud Computing and Functional Programming as well as Agility represented the hot topics. What I liked most were all these more practice-oriented talks offering some insights for practioners and also revealing some real life show cases. For instance, I enjoyed Kurt Höpli?s talk on building and controlling environmental sensors in a project in Switzerland. And I also experienced a lot of fun in Markus Völter?s talk on how to apply Model-Driven-Software-Development  within an embedded systems context. Never I will forget how Eric Evans and Hans Dockter presented Domain-Driven-Design convincing some attendees to participate as actors. And I?ll remember also Lothar Mieske who presented the real look-and-feel of all those Cloud Computing platforms. I could add much more but this should give you an impression and suffice as a pars pro toto.

Personally, I have been very busy the week. First, I gave a full-day tutorial on Software Architecture ? From Requirements to Architecture. It was the tutorial with the largest numbers of attendees. This makes interaction somewhat difficult but nonetheless worked much better than expected. My talk on Hitchhiker?s Guide to Cloud Computing had about 80-100 attendees. To my pleasure the Global Technology Field Cluster Lead of my organization also attended the talk. For me, it was the biggest surprise that the talk ?Introduction to Scala? had attracted so many people. I was totally electrified and I mean this literally cos? static charge hit me whenever I pressed the page-down key. When people are interested, I will record this talk with Camtasia and publish the video clip in YouTube and other media. All in all, I got really overwhelming feedback. Thank you to all attendees for their nice evaluation sheets :-)

Next year the OOP will celebrate its 20th anniversary. Hope that many of you will join the event. It is really an extraordinary experience.

In Italien ist jeder ein Experte für Espresso – alle wissen: “Per un buon caffè, ci vogliono cinque ‘M’: miscela, macinatura, macchina, mano e mente.” (Für einen guten Espresso braucht man die fünf ‘M’: Mischung, Mahlung, Maschine, Hand und Geist).

Ist das in der Software-Entwicklung genauso? Die OOP hat sich ja in diesem Jahr auch so ein Motto auf die Fahne geschrieben: people, process, technology. Prüfen wir doch mal: people = mano e mente, process = macinatura, technology = macchina – nanu, wo bleibt miscela, die Mischung, der Rohstoff, aus dem die Software entstehen kann?

Alistair Cockburn hat diese Frage 2006 in einem Artikel beantwortet: “Software engineering … is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory.” Die Mischung besteht also aus den bisher unvalidierten Entscheidungen, die in der Mühle und der Maschine immer weiter verarbeitet werden, bis der Benutzer seine neue Software in Händen hält.

Beispiele für solche unvalidierten Entscheidungen sind:

• Jede Anforderung ist eine Entscheidung, die auf einem bestimmten Geschäftsklima basiert. Wenn sich das Klima ändert, könnte die Entscheidung falsch werden.
• Eine Architektur ist eine Entscheidung, die auf Technologie und Business basiert. Wenn sich die Technologie verändert bevor die Software genügend Wert für das Business eingespielt hat, ist die Entscheidung verschwendet.
• Jede Zeile Code ist eine Entscheidung, basierend auf Anforderungen, Technologie und Ästhetik. Sollte eines davon obsolet werden bevor die Software genügend Geld für die Firma verdient hat, dann war auch das Verschwendung.

Halten wir also am besten die Zyklen kurz und schlank und erzeugen nur so wenig unvalidierte Entscheidungen wie möglich. Über Anforderungen rasch entscheiden, Entwurf und Programmierung zeitnah durchführen, dem Benutzer lauffähige Systeme in die Hand geben, die er sofort validieren kann. So bleibt der Kaffee frisch, weil die Bohnen nicht lange liegen.

Ich lade Sie ein, mit mir auf der OOP einen Kaffee zu trinken!

Mein aktueller Kunde hat ein Stakeholder-Gremium, das sich regelmäßig trifft, um neue Anforderungen zu priorisieren, die das Entwicklungsteam baldmöglichst umsetzen soll. Es besteht aus Vertretern der relevanten Geschäftsbereiche, die jeweils mit einem Teil der Anforderungen im selben lauffähigen System zu unterschiedlichen Zeitpunkten “live” gehen wollen. Die Stakeholder müssen sich also (trotz unterschiedlicher Interessen) auf einheitliche Priorität einigen, die der Product Owner dann dem Entwicklungsteam gegenüber vertritt.

Ausgangssituation: Priorität gemeinsam festlegen

Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:

• Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
• Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
• Was meinen die anderen Stakeholder dazu?
• Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?

Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)

Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.

Spielregeln

Die Spielregeln für “Buy a feature” sind sehr einfach und wirkungsvoll:

• Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
• Jedes Feature hat einen “Preis”, der durch den Entwicklungsaufwand bestimmt wird.
• Stakeholder “kaufen” nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
• Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.

Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.

Die Randbedingungen hatte ich wie folgt gesetzt:

• Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
• Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
• Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste “Launch” des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.

Der Ablauf des Spiels

Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.

Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.

Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.

Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: “Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.” Wer hätte das für möglich gehalten?

Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.

Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: “Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?”. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.

Feedback vor und nach dem Spiel

Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: “Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.” Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.

Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:

• “Die Visualisierung der Entscheidungen ist sehr gut.”
• “Man kommt sehr schnell zu einer Einigung.”
• “Es lockert diese Meetings auf und macht Spaß.”

Tja, da bleibt mir nur ein “Danke” an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!

Wie bereits im vergangenen Jahr findet auch auf der OOP 2010 wieder mal
ein echtes Highlight für die Kommunikationsfähigkeit von IT'lern statt:

Alice Heiliger, Rody Shaw und Andreas Goerlich präsentieren ihren
ganztägigen Workshop:

Wie dirigiere ich (m)ein Team?

Am Montag den 25. Januar erleben, lernen und üben Sie dabei Teamdynamik und Führung "live". Die Trainer arbeiten mit professionellen Musikern, und Sie schlüpfen in die Dirigentenrolle.

Aus dieser Analogie (Dirigent = Team-/Projektleiter) leiten die drei
wertvolle und zeitlose Tipps und Praktiken für den täglichen Umgang
von Menschen miteinander ab - interessant, spannend und für uns IT'ler
sehr nützlich.

Ich durfte diesen Workshop in einer Kurzform im letzten Jahr genießen - und möchte ihn wirklich weiterempfehlen!!

Gestern war ich in einem Gebäude mit Erdgeschoss und 8 anderen Stockwerken. Der Aufzug brachte mich in den 7. Stock, dann konnte ich mir aussuchen, auf einer Treppe oder mit einem anderen(!) Aufzug in den 8. Stock zu kommen, wo ich den Besprechungsraum, mein eigentliches Ziel, finden würde.

Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”

Allgemeines Gelächter in der Gruppe.

Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.

Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.

Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?

January 26-28 we'll be at OOP in Munich again. I'll do a talk on "REST with Java", and we (innoQ) will have a booth in the exhibition area, too (more about some of the stuff we'll talk about later). Send me an e-mail if you want to schedule a meeting ?

Thesen zum Einstieg

These 1: Menschen leisten am meisten, wenn sie motiviert sind. Zumindest, wenn das Rennen über eine längere Strecke gehen wird. Kurze Strecken hoher Leistung sind auch rein aus Anstrengung machbar, bei längeren Strecken kommt die Energie am besten aus der Begeisterung. Softwareentwicklung gehört zu den längeren Rennen.

These 2: Softwareentwicklung ist ein Spezialfall von Arbeit mit Wissen, und zwar mit einem Wissen, das nicht von Anfang an komplett vorhanden ist, sondern eines, das wie ein stetiger Strom während der gesamten Projektlaufzeit ins Team fließt.

These 3: Wissensarbeit ist wie ein kooperatives Spiel – es gibt dabei keinen, der vernünftigerweise allein bestimmen könnte, was als Nächstes der beste Spielzug ist. Das gilt insbesondere sogar für den Projektleiter – er muss die Entscheidung über den besten nächsten Zug seinen Mitarbeitern überlassen.

Formen der Führung

Je nach der Komplexität der Arbeit, die die Teams leisten, muss der Führungsstil angepasst werden, damit die Sache ein Erfolg wird. Sehr einfache Arbeit kann man mittels Kommando und Kontrolle managen. Für etwas komplexere Aufgaben sind Zielvorgaben und Belohnung bei Zielerreichung das Richtige. Noch komplexere managt man durch charismatische Führung. Für höchst komplexe Tätigkeiten wie die Softwareentwicklung erreicht man die besten Ergebnisse, wenn man Selbstorganisation zum Prinzip macht. Niemand anderes als das Team weiß am besten, was in der aktuellen Situation zu tun ist. Als Manager nutzt man dieses Wissen und stellt dem Team lediglich eine Dienstleistung namens Führung zur Verfügung.

Robert K. Greenleaf hat vor einigen Jahrzehnten schon Essays dazu verfasst, das gemeinsame Thema hieß Servant Leadership, im Prinzip “Führung als Dienstleistung”. James A. Autry hat Greenleafs Erkenntnisse weiter konkretisiert, in seinem Buch von 2001: The Servant Leader: How to Build a Creative Team, Develop Great Morale, and Improve Bottom-Line Performance. Darin finden sich einige interessante Kernaussagen:

1. Bei Führung geht es nicht um das Steuern von Leuten; es geht darum, für Leute zu sorgen und eine nützliche Ressource für die Leute zu sein.
2. Führung bedeutet nicht, der Boss zu sein; es geht darum, für Leute präsent zu sein und eine Gemeinschaft am Arbeitsplatz aufzubauen.
3. Bei Führung geht es nicht um die Verteidigung von Territorium; es geht darum, Ihr Ego loszulassen, Ihren Geist mit zur Arbeit zu bringen und Ihr bestes und möglichst authentisches Selbst zu sein.
4. Führung befasst sich nicht so sehr damit, Anfeuerungsreden zu halten, sondern damit, wie man einen Platz schafft, an dem Leute gute Arbeit machen können, darin einen Sinn finden und ihren Geist zur Arbeit mitbringen.
5. Führung ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.
6. Führung erfordert Liebe.

Motivation und Produktivität

Wenn ich die obigen Kernaussagen von Autry lese, denke ich “Wow, so möchte ich als Teammitglied geführt werden!” Ein Manager ist in der Lage, eine Umgebung für Motivation und gute Arbeit zu schaffen, wenn er diese Sätze tief verinnerlicht und danach handelt. Nebenbei: Dann wird ihm sein Job auch richtig Spaß machen, weil er mit dem, was sein Team braucht, in Resonanz kommt.

Produktivität stellt sich dann durch Selbstorganisation des Teams ein, bei der der Manager lediglich Unterstützung leistet. Soziale Systeme entwickeln Verhalten, sie organisieren sich selbt aufgrund von Regeln, Feedback und Diskurs. Es beginnt mit einfachen Regeln, z.B. “Wir wollen nur Code einchecken, der den Build übersteht und fehlerfrei durch alle Unit-Tests geht.” Wenn jemand eine solche, gemeinsam anerkannte Regel verletzt, indem er schlechten Code eincheckt, bekommt er von den Teamkollegen (und vom CI-Server) Feedback. Er wird sich vermutlich wundern, mit seinen Kollegen ins Gespräch kommen. Zuletzt wird er die Ursache herausfinden und beheben, indem er vor dem Einchecken zunächst seine Arbeitsumgebung aktualisiert, alle Unit-Tests laufenlässt und Fehler lokal behebt, bevor er nochmals eincheckt. Das ist eine Verhaltensveränderung, Selbstorganisation durch Feedback und Diskurs. Die Produktivität des Teams wird ansteigen, weil wieder einer weniger “im Weg steht”.

Der Manager als Mentor

Als Manager oder Coach kann ich diesen Prozess der Selbstorganisation fördern, indem ich genug Quellen für Feedback schaffe, Menschen ermutige, Feedback zu geben und in den Diskurs zu gehen. Ich kann das Team fragen, welche anerkannten Regeln für das gemeinsame Handeln gelten müssen und die Verabschiedung dieser Regeln fördern. Ich kann Regeln auch hinterfragen (lassen), wenn mehrfach gegen sie verstoßen wird oder wenn das Team so reif wird, dass sie weniger Regeln brauchen.

Das alles ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.

Ein paar Gedanken zum Zeitbegriff in agilen Verfahren.

In allen agilen Methoden versucht das Entwicklungsteam, dem Kunden ein gewünschtes Feature möglichst schnell zur Verfügung zu stellen. Das ist ein wichtiger Bestandteil des Entwicklungsprozesses: zeitnahe Lieferung löst zeitnahes Feedback aus und hilft, das Projekt auf der Spur zu halten.

Die agilen Methoden können dabei von den jahrzehntelangen Erfahrungen aus der Lean Production profitieren. Kanban tut das explizit, XP und Scrum tun das implizit. Die Frage ist nur : Was heißt eigentlich “schnell” oder “zeitnah”? Über welche Zeit reden wir da eigentlich?

Lead time

Die für den Kunden interessante Zeit ist eigentlich diese: “Wenn ich heute ein Feature in die Entwicklung gebe, wann kann ich es in der lauffähigen Software erkennen und testen?”. Diese Zeit nennt man in der Lean-Welt lead time. Ihre Einheit ist tatsächliche, abgelaufene Zeit (elapsed time). Sie enthält sowohl die Zeit für den Fertigungs-Workflow (also Analyse, Design, Unit-Test, Implementierung, Integration, etc.) als auch eventuelle Wartezeiten vor der Fertigung, weil das Team gerade noch andere Features zu entwickeln hatte.

Cycle time

Eine andere Zeit, die weniger für den Kunden und mehr für die Entwickler und deren Manager interessant ist, nennt man in der Lean-Welt cycle time. Ihre Einheit ist nicht tatsächlich abgelaufene Zeit (elapsed time), sondern der Rhythmus (engl. cadence), wie oft der Entwicklungsprozess ein Feature fertigstellt. Um den Unterschied zu verstehen, ein Beispiel: Ein GUI-Designer wird beauftragt, eine größere Anzahl bereits fertig entwickelter HTML-Seiten (z.B. 100 Stück) graphisch schön aufzubereiten. Sagen wir, er liefert jede Woche (5 Arbeitstage) 20 Stück, dann beträgt die cycle time pro HTML-Seite 2 Stunden (5 Tage mal 8 Stunden = 40 Stunden, dividiert durch 20 Stück, also 2 Stunden pro Stück).

Littles Gesetz und Work in Process

Wie stehen nun diese beiden Zeiten in Beziehung? Das fand John D.C. Little schon 1961 heraus. Damals formulierte er es so: In einem stabilen Wartesystem (Beispiel: Supermarkt) ist die durchschnittliche Anzahl von Kunden gleich dem Produkt aus Ankunftsrate und der durchschnittlichen Verweildauer im System.

Was heißt das, übertragen auf lead time und cycle time? Nun, die Ankunftsrate ist der Kehrwert der cycle time, die Verweildauer ist gleich der lead time und die durchschnittliche Kundenanzahl entspricht der Anzahl der Features, an denen das Team im Durchschnitt gleichzeitig arbeitet. In der Lean-Welt nennt man das work in process.

Also können wir Littles Gesetz so umstellen: lead time = work in process * cycle time.

Wenn der oben erwähnte GUI-Designer zu viele Aufträge hat, weil er für zu viele Kunden gleichzeitig arbeitet, ist seine work in process sehr hoch, z.B. befinden sich 100 HTML-Seiten bei ihm in Arbeit. Wenn ein Kunde nun eine neue Seite zum “Schönmachen” beauftragt, bekommt er sie erst nach einer lead time von durchschnittlich 5 Wochen zurück (100 Seiten x 2 Stunden/Seite, geteilt durch 40 Stunden pro Woche). Der Kunde wird unzufrieden sein, und der GUI-Designer sollte sich überlegen, ob er nicht mehr Aufträge ablehnen oder seinen Kollegen weitergeben sollte.

Handlungempfehlung

Was lernen wir daraus, wenn wir zu einem Software-Entwicklungsteam gehören oder ein solches managen? Um den Kunden zufrieden zu machen, sollte das Team die lead time optimieren. Das Einfachste ist, die work in process zu reduzieren, also einfach nicht an so vielen Sachen gleichzeitig zu arbeiten. Das Schwierigere ist, die cycle time zu reduzieren, also effizienter zu arbeiten. Dazu braucht es Methode. Wenn Sie Lust haben, zeige ich Ihnen , wie auch das geht. Rufen Sie mich an.

Die Objektorientierung steht uns im Weg zu evolvierbareren Programmen. Ja, das glaube ich immer mehr. Nicht, dass ich Objekte missen möchte ? sie sind nützliche und wichtige Strukturierungsmittel für Software. Ich will natürlich Funktionseinheiten mit eigenem Zustand definieren können. Aber die Sprache der Objektorientierung wie sie C++, Java, C# und auch VB vorgeben, ist einfach nicht für

The OOP is very special because it offers you a whole range of practially-oriented international software experts easily accessible in Munich.

Robert Martin will hold a keynote and session on Thursday.

Philippe Kruchten holds a full-day tutorial on Software Architecture on Monday.

Michael Mah holds a full-day tutorial on measurement and estimation and a session in the management & metrics track on Tuesday reporting on data from agile projects.

Eoin Woods holds a night school on Monday on Agile Software Architecture and a session on Tuesday on the top 10 software architecture mistakes.

Gary McGraw holds a keynote on software security on Tuesday.

Diomidis Spinellis holds a talk on performance issues and a full-day tutorial open Open Source on Friday.

Kevlin Henney on Unit Testing in C++ and Modelling in the Age of Agility both on Thursday and in full-day tutorial with Frank Buschmann on "Beyond the Gang of Four" on Friday.

Jan Bosch holds the opening session of the Product-Line-Engineering (PLE) track on Wednesday and also has a talk in the Architekturtag on Thursday.

Nenad Medvidovic has two presentations, one in PLE-Track on a framework for modeling product lines and the other (on non-functional properties) in the architecture track.

Eric Evans on Domain-Driven Design in 2 half-day workshops (morning basic, afternoon strategy) on Friday.

Gregor Hohpe has a presentation in the architecture track on Distributed Computing the Google Way and one in the SOA track on Coupling, Messaging, and Conversations.

Don't miss taking advantage of this once-in-a-lifetime opportunity to have these experts here in Germany!

Frances Paulisch

At the OOP 2010 conference, Robert C. Martin will give a keynote about polyglot programming, called “The Polyglot Craftsman”.

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.

Design for Testability ist auch Design for Flexibility. Deshalb liebe ich TDD. Allerdings bin ich dabei immer wieder über einen Problemfall gestolpert: die Prüfung des Zustands eines system under test (SUT). Als Beispiel hier ein typischer (nicht unbedingt optimaler) Ansatz bei der bekannten und beliebten KataPotter. Viele denken bei der Implementierung der Preisberechnung für die KataPotter an

Anlässlich einiger Code Katas, die ich in letzter Zeit gemacht habe, hier ein paar Gedanken zu Nutzen und Grenzen von TDD (Test-Driven Development oder Test-Driven Design): Was leistet ein Test? Er prüft die Korrektheit der Funktionsweise einer Codeeinheit. Klingt selbstverständlich. Die Erkenntnis durch TDD liegt für mich aber in der Umkehrung: Nur, was als eigene Codeeinheit vorliegt, kann

Jetzt ist es wieder passiert: Ein Manifest hat das Licht der Softwarewelt erblickt. Dieses Mal ist es das SOA Manifest. 2001 hatte das Agile Manifest den Anfang gemacht, 2009 kam das Software Craftsmanship Manifest dazu und nun ebenfalls noch in 2009 die SOA-Fraktion. Was ist nur los? Was will uns die SOA-Welt sagen? Die naheliegende Antwort findet sich natürlich im Manifest selbst. Doch darum

Grad scheint Microsoft wieder mal ?the best thing since sliced bread? erfunden, wie es scheint. Der Reactive Framework (Rx) zaubert jedenfalls einiges breites Grinsen auf Gesichter bei Microsoft, hier der Erfinder des Ganzen, Erik Meijer, in einem Interview über Rx. (Achtung: Dieses Interview ist auf sehr hohem Abstraktionsniveau! Eine Beschreibung von Rx für Praktiker sucht man hier

Die OOP Konferenz im Januar 2010 hat einiges an agilen Themen zu bieten:

• Am 25.01.2010 gibt es von Jens Coldewey, Henning Wolf, Bernd Schiffer und Johannes Link ein Tutorial Agile Praxis erleben.
• Am gleichen Tag bietet Jutta Eckstein ein Tutorial Agile Softwareentwicklung mit verteilten Teams an.
• Eoin Woods lädt zur Nighschool am selben Tag: Agile Software Architecture ? How Much is Enough?
• Am 26.01.2010 gibt Sue McKinney eine Keynote mit dem Titel Backing into Agile Leadership
• Am selben Tag berichtet Markus Andrezak von den Erfahrungen mit Kanban bei mobile.de: Kanban for large scale Off-Shored Product Maintenance at mobile.de
• Michael Mah hat ebenfalls am 26.01. eine Session mit dem Titel The Good, Bad, and the Puzzling: The Agile Experience at Five Companies
• Bernd Oestereich spricht am 27.01.2010 über Agiles Requirements-Engineering – Der erfolgreiche Product Owner ohne Überforderung
• Michael Schmücker und Markus Wittwer berichten ebenfalls am 27.01. über Scaling.agile@allianz.de: ein Erfahrungsbericht
• Bernd Schiffer und Heiko Henßler berichten von agiler Softwareentwicklung bei 1&1: Scrum@1&1: ein Erfahrungsbericht
• Ursula Meseberg hält einen Vortrag zu So kommen Farbe und Form ins Spiel: Usability Engineering in Projekten nach Scrum
• Am 28.01.2010 haben Ralf Westphal und Stefan Lieser einen Vortrag zu Clean Code Developer – Eine Initiative für mehr Softwarequalität. Das Thema ist zwar erstmal nicht spezifisch für agile Softwareentwicklung, aber es kommt aus der Ecke und harmoniert gut mit agilen Gedankengut.
• Aus dem gleichen Grund verorte ich Robert C. Martins Vortrag über S.O.L.I.D. auch im agilen Bereich.
• Roman Pichler hält am selben Tag einen Vortrag über die Arbeit des Product Owners: Product Owner – Fehler vermeiden
• Ebenfalls am 28.01.2010 berichten Henning Wolf und Sven Günther über Einführung agiler Softwareentwicklung in einem Multiprojektumfeld bei Otto
• Johannes Mainusch und Susanne Reppin erlauben uns Einblicke auf die Entwicklung mit Scrum bei Xing: Wer am Ziel ist, irrt sich! Agil bleiben – Motorhaube auf bei XING
• Marcel Baumann nimmt sich des Themas Scrum in reguliertem Umgebungen an: Scrum in FDA regulatory environment: How to use Scrum in MedTech projects
• Björn Feustel und Steffen Schluff nehmen sich das Thema Testen vor: Testest Du noch oder entwickelst Du schon (wieder)?
• Zusammen mit Bernd Schiffer versuche ich etwas Licht in die Kanban-Frage zu bringen: Was ist dran an Kanban?
• Jens Coldewey und Henning Wolf beschäftigen sich mit Wissensinseln: Wissensinseln – Schadbild, Bekämpfung und Vorbeugung
• Kevlin Henney nimmt sich Modellierung vor: Modelling in the Age of Agility
• Am 29.01.2010 folgt noch ein Tutorial von Roman Pichler: Product Backlog Grooming ? Das Product Backlog richtig pflegen

Das sind insgesamt 21 Sessions zu agilen Themen – von unsgesamt knapp 130 Sessions. Das ist schon nicht schlecht, zumal es mir damit das am stärksten vertretene Einzelthema zu sein scheint. SOA hingegen scheint vollkommen tot zu sein.

Wir zahlen zuwenig. Dieser Gedanke ist mir gestern gekommen. Ich hatte mit Google Reader meine RSS-Feeds durchstöbert, dann bei InfoQ geblättert und schließlich eine neue Zeitschrift zur Hand genommen, von der ich ein Probeexemplar bestellt hatte: NOVO argumente. Ganz normal hatte ich also im Überfluss an Lesestoff ein Bad genommen. Ganz normal hatte ich dabei cherry picking betrieben: nur, was

Quote of the Day:
"Software and cathedrals are much the same ?
first we build them, then we pray."
Samuel T. Redwine

It is clear that it is essential to have a solid foundation when building a complex software-based system and this is particularly true when using this foundation as the common basis of a set of products or systems.
But the benefits in terms of reduced effort, reduced time-to-market and increased quality are high -- if one is able to do it right. And that is what you can learn at the OOP.

At the OOP we have a 2-day track, organized and moderated by Christa Schwanninger, on Product Line Engineering (PLE) headed by an opening track-keynote by Jan Bosch on Software Product Lines. The second day of the track focusses on the modelling aspects and includes presentations by Markus Völter, Peter Manhart (Daimler), and Neno Medvidovic, a software architecture specialist from the University of Southern California. In the night school on Wednesday night we offer a PLE-Tutorial by Prof. Klaus Schmid. In this track we address many aspects of PLE including the technology, the business case, concrete examples, and future directions of this important topic area.

The OOP 2010 conference program is now online.

The conference motto is "Productivity: People, Process, and Technology" and we will show how many of the topics this conference addresses relate to increased productivity. The OOP also has many sessions on current topics like dynamic languages, cloud computing, and multicore.

This year we have a particularly interesting set of international speakers on the program. Stay tuned for more details.

Frances Paulisch
Technical Chair of the OOP software engineering and management conference