Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

• Folien zum regulären Vortrag
• Folien zum Pecha Kucha

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

Aikido master Endō Seishirō shihan stated: „It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.“ (from [1])

Shu-Ha-Ri in Scrum

These learning stages can be applied to Scrum, too. A team starts with Shu. It practices Scrum by the book: the flow with the roles, the meetings/ceremonies and the artifacts. Premature adaptations to Scrum in the Shu stage often lead to the famous ScrumBut situations (see [2], [3]). A team enters the Ha stage only after it has shown its ability to use Scrum as it was intended and has achieved a deep understanding of the spririt of Scrum. Then it may (and I think it should) adapt Scrum on their understanding of the spirit of Scrum. After a team has been in Ha state for a probably long period of time it may enter Ri and dismiss all rules.

From Shu to Ha

Two interesting (and interrelated) questions arise here:

1. How do you know that you have practiced enough in Shu state and you may enter Ha state?
2. What are typical adaptations for Scrum in Ha state?

From Ha to Ri

References

1. Wikipedia article about Shu Ha Ri: http://en.wikipedia.org/wiki/Shuhari
2. My presentation about ScrumBut and Shu-Ha-Ri (in german): http://www.slideshare.net/roock/scrum-but-agil-aber-xpdays-germany-2010
3. ScrumBut from Ken Schwaber: http://www.scrum.org/scrumbut
4. Agile Manifesto: http://agilemanifesto.org

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch „Implementing the Lean Startup“ heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

Dear Thought Leader,

I really appreciate what you did for our community and the progress of our industry in general.

But sometimes I am puzzled. That happens when you bash an idea or even worse a person. The ideas you had and the concepts you developed are great enough to stand for themselves. You don’t have to bash other ideas/persons to make your concepts look brighter.

Here are some examples that might highlight what I am talking about:

“X clearly didn’t understand what Y means.” How do you know? Did you do an in-person test with X to check his understanding of Y? How does it feel for X when you say that? What will be his reaction? Will he check his understanding or is it more likely that X just defends himself?

“In his blog entry X addresses Y but sadly stops at Z and didn’t thought of A.” How do you know that X didn’t thought of A? Perhaps he did and decided to leave it out to keep the article short?

„Y is a stupid idea. It would lead to (unwanted) Z.“ At least when people are involved how do you know that Y would lead to Z every time in every situation, especially when you tried Y never or only a few times? Do you think the advocate of Y is lying when he says that Y worked at his place?

I don’t suggest stopping arguing! Arguing is possible without devaluing other ideas/persons.

One could say “X wrote a nice blog post about Y. I’d like to add some thoughts on Z.” or “X presented Y in a way that puzzled me. I would rather think that …” or “Y didn’t work when I tried it. Therefore I tried something different that I’d like to present.” or even „Y simply does not resonate with me. Therefore I used Z.“

If you defined something very clear and X presented it just plain wrong you could just call or email X and make the correction. Don’t spend your previous keynote time correcting one person. There are hundreds in the audience who want to learn something from you.

My wish for the future is that we all learn to become better at arguing without bashing and devaluing.

Yours respectfully,

Stefan Roock

P.S.: I am am sure that I bashed other peoples/ideas as well but that doesn’t make it any better.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the „process“ is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named „Naked Planning“. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007): http://www.youtube.com/watch?v=6t4bZtnnQJA

„I love to code, but I have to coach.“

Viele Anwesende stimmten durch Gemurmel oder eindeutige Gesichtsausdrücke zu. Es findet sich hier ein durchaus gängiges Muster. Ein sehr guter Entwickler wird zum Coach, weil nur so höhere Gehälter zu erzielen sind. Und so landen Entwickler in Coaching-Jobs, die sie eigentlich nicht wollen.

Ich selbst habe mich auch immer – zumindest zum Teil – dazu gezählt. Ich hatte aber auch immer Spaß beim Coachen und Trainieren. Vor ein paar Jahren habe ich versucht, das für mich klar zu kriegen und dafür eine Vision für mich geschrieben. Hier einige Auszüge daraus:

Ich möchte mich in meinem beruflichen Leben kontinuierlich weiterentwickeln und wünsche mir Anerkennung meiner Arbeit und meiner Person. Dazu möchte ich in motivierten agilen Teams anspruchsvolle Software-Produkte entwickeln. Dabei spielt für mich ein großer Gestaltungsspielraum eine ebenso wichtige Rolle wie der enge Kontakt mit den Kunden/Anwendern. Meiner Meinung nach können nur im engen Kontakt zu Kunden/Anwendern Lösungen entstehen, die die Bedürfnisse der Kunden/Anwender befriedigen.

Das in den Projekten Erlernte möchte ich reflektieren und vergegenständlichen, als wichtige Elemente meiner Weiterentwicklung. Für das Vergegenständlichen funktioniert das Schreiben von Artikeln und Büchern sowie das Halten von Vorträge und Schulungen gut für mich.

Wie man sieht, stand das Programmieren im Zentrum. Alles, was sich um Coaching und Training drehte, war ein Anhängsel oder gar nicht erkennbar. Als ich die Vision aufgeschrieben habe, ist mir natürlich aufgefallen, dass diese Vision nicht wirklich zu meinem Job als Coach passte. Aber irgendwie fühlte ich mich mit dem Coaching-Job dann auch nicht so unglücklich. Tatsächlich war es sogar so, dass ich für Coachings und Trainings viel mehr Anerkennung erhalten habe als jemals zuvor für Programmierung.

Der oben zitierte Ausspruch auf der SoCraTes-Konferenz hat mich erneut an meine Vision erinnert und mein zwiegespaltenes Verhältnis zum Coaching. Ich habe das zum Anlass genommen, nochmal über meine persönliche Vision zu reflektieren. Dabei ist mir klar geworden, dass die Anerkennung nur eines meiner Bedürfnisse ist. Das andere Bedürfnis schien bereits in der originalen Vision durch: „Bedürfnisse von Anwendern befriedigen“. Tatsächlich geht mein Bedürfnis noch weiter: Ich möchte Fußspuren hinterlassen, etwas verändern, einen Impact haben. Das geht über die Entwicklung von Software. Aber wenn ich ehrlich bin, war das meistens nicht der Fall. Die meisten Systeme hatten keine nennenswerte Auswirkung. Das geht viel einfacher, wenn ich als Coach und Trainer arbeite! Tatsächlich glaube ich, dass ich durch meine Arbeit nicht nur Unternehmen wirtschaftliche Vorteile sondern nebenbei auch die Arbeitssituation vieler Entwickler verbessert habe.

Seit mir das klar geworden ist, fühle ich mich viel besser in meiner Rolle als Coach und Trainer. Trotzdem habe ich auch weiterhin Spaß am Programmieren. Nicht umsonst investiere ich viel Zeit in CodersDojo. Ich würde aber nicht mehr jedes Programmierprojekt machen wollen. Es sollte schon herausfordernd sein und in Clojure oder mindestens Ruby entwickelt werden. Und wahrscheinlich würde ich mich auf jeden Fall in die Product-Owner einmischen wollen. Wer so ein Projekt zu bieten hat, kann sich gerne bei mir melden. Solange mache ich meine Hobby-Projekte und bin als Coach und Trainer glücklich.

P.S.: Ich weiß von Beraterkollegen, dass sie nicht sehen, dass sie Anerkennung für ihre Coaching-Arbeit bekämen oder wirklich etwas verändern würden. So ging es mir am Anfang meiner Beratertätigkeit auch häufig. Mit der Zeit sind diese Situationen aber immer seltener geworden. Vielleicht muss man nur lange genug durchhalten, bis man die nötige Erfahrung hat

How it works
Single piece flow means that the whole team works at one User Story at any given point in time. Only when the whole User Story is done the team moves to the next User Story.

Why it
Single Piece Flow works due to several positive effects:

1. Single Piece Flow forces the whole team to cooperate continuously.
2. This ensures that every team member is informed about state and progress of each User Story. Furthermore the team members learn from each other through intense cooperation.
3. On this basis it is easy for team members to help each other.
4. Point 3 together with the fact that a team generally is faster in implementing a User Story leads to a shorter lead time of the User Story.
5. Shorter lead time and reduced Work-in-Progress means for the team that it has to remember only few things for a short period of time. And this fact reduces the number of bugs and decreases the time needed for bug fixing.

Really?
You may doubt what I wrote. Perhaps Single Piece Flow reduces the lead time per User Story. But does it enhance overall throughput or does it lead to under utilization of the team members and higher costs?
Maybe… Luckily it is easy to check. Just try it for one Sprint and then inspect&adapt. You are welcome to share your findings in the comments of this blog article.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

But I prefer a simpler mechanism and just adding impediments to the existing Task Board which I have described here in a PDF.

Every team member answers two questions:

1. What did I achieve since the last Daily Scrum? (and update the taskboard)
2. What are my impediments? (and make impediments visible at the taskboard)

Then the team updates the Sprint Burndown Chart (yes, let the team draw it on a big sheet of paper).
Now the team sees the current state of the Sprint at the taskboard and the prognosis at the Sprint Burndown Chart.
Then ask the third question in a slightly modified form: How can we as a team organize until the next Daily Scrum to create the most progress towards the Sprint Goal?

That will avoid stickyness to tasks (“I worked on the database schema and will work on it again”). Instead the team plans together who should work on what. Perhaps Henning should help Stefan with the database schema? Perhaps it would be better to stop working on the database schema for now and focus on another more important task?

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

While I think that Envisioning is often necessary I am often shocked when I see what companies do during „Envisioning“:

• The Envisioning lasts weeks or months when hours or days would have been sufficient.
• Comprehensive fine grained product backlogs are created.
• Detailed designs are created.
• etc.

That is not Envisioning. That are the early phases of a waterfall project. Therefore some people consider the Envisioning an anti pattern in Scrum.

Before I join these people I want to try to explain better what Envisioning should be and what not.

During Envisioning I value

• learning important things over designing things
• having business and technical people in the Envisioning team over having only the Product Owner doing the Envisioning
• Product Owner and Team listening to and working together with real customers and users over giving research orders to marketing
• checking assumptions about the market, customers, users over dealing with corporate stage gate processes
• checking technical assumptions with prototypes over having long design discussions within the team
• sketching things on flip charts over creating power point slides
  

At it-agile we created a Scrum team to restructure some aspects of our software development unit. For the first Sprint the Sprint Goal made it necessary to interview customers. So far so good.

But when I was at the site of a coaching client with potential interview partners it wasn’t that easy. I had a full email inbox and it was hard to get in touch with the potential interview partners. It would have been much more comfortable to postpone the interviews. And if I hadn’t committed to the Sprint Goal I would have postponed the interviews. But the commitment made me focus on what really mattered and it pulled me out of my comfort zone and do the interviews. And in the end it was the right thing to do. Learning something about customers was much more valuable than reading emails.

In this story my commitment to the Sprint Goal made me leave my comfort zone.

This is just one of the possible positive aspects of the commitment concept done right. Others include building trust, having an additional feedback mechanism, create focus etc.

Ein Buch, in dem ein windsurfender Scrum-Coach aus Norddeutschland mit Namen Stefan vorkommt, muss einfach ein großartiges Buch sein Die „Kraft von Scrum“ ist demnach großartig. Das Buch ist eine Scrum-Einführung nicht nur für Manager, verpackt in romanartige Geschichte, in der besagter Scrum-Coach Stefan einem angeschlagenen Software-Unternehmen durch die Einführung von Scrum den Weg aus der Krise weist.

In der Geschichte werden alle Elemente von Scrum am praktischen Beispiel eingeführt, so dass der Leser einen guten Eindruck davon gewinnt, was Scrum ist. Die Geschichte drumherum hat trotz windsurfendem Scrum-Coach keinen großen Inhalt. Sie ist halt Mittel zu dem Zweck, Scrum zu erklären und dafür ist sie vollkommen in Ordnung.

Das kleinformatige 150-seitige Buch lässt sich schnell durchlesen. An der im Vorwort genannten Lesezeit von 2-3 Stunden bin ich aber kläglich gescheitert. Naja, vielleicht habe ich einfach noch nicht die Qualitäten, um Manager zu werden…

Obwohl Scrum für mich nichts Neues mehr ist, hatte ich dennoch Spaß an der Lektüre und empfehle das Buch gerne weiter. Vielleicht ist es ja das passende Geschenk für den eigenen Chef? Für meinen Chef allerdings nicht; er hat das Buch schließlich ins Deutsche übersetzt und die Lokalisierung vorgenommen. In diesem Zuge wurde aus dem Scrum-Coach auch der windsurfende Stefan, warum auch immer

Direkt bei Amazon kaufen: „Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagement-Methode“

But why work physical tools better than software tools?

Software tools are used with another focus than physical tools. Software tools are used for managing (e.g. for managing the Sprint Backlog). Physical tools facilitate communication and cooperation. When somebody moves an index card at a card wall, the other team members can see that directly and step into a discussion. When somebody changes the status of a ticket in an issue tracker nobody notices immediately and starting a discussion is unlikely.

And facilitating communication is more important than easy management?

This question is easy to answer with a look at the agile manifesto: The first value statement of the agile manifesto reads „Individuals and interactions over processes and tools“. And principle number six says: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Yes, communication and cooperation is king.

So whatever tool is used communication and cooperation should be the goal, not management. And I think that this goal is easier to achieve with physical tools than with software tools. But in the end the decision is up to the team.

Things to try

• The team should at least try physical tools for one Sprint to make an informed decision.
• As ScrumMaster shield the team from existing tools and do the mapping from the physical tool to the software tool during the trial period.

Im Mai wird das Buch „Agile Entwicklungspraktiken mit Scrum“ im dpunkt-Verlag erscheinen. Roman Pichler und ich sind die Herausgeber. Wir wollten ein deutschsprachiges Buch herausgeben, in dem die in Scrum gängigen Entwicklungspraktiken nach dem aktuellen Stand der Technik beschrieben sind. Dazu haben wir namhafte Coaches angesprochen und sie gebeten, jeweils ein Kapitel beizusteuern. Wir selbst haben ebenfalls das eine oder andere Kapitel beigesteuert und versucht, für einen einheitlichen Stil des Buches zu sorgen, so dass sich eine möglichst durchgängige Leseerfahrung ergibt. Ich hoffe, das ist uns gelungen

Die Autorenliste umfasst Alex Bepple, Jens Coldewey, Jutta Eckstein, Peter Friese, Andreas Havenstein, Johannes Link, Martin Lippert, Bernd Schiffer und Henning Wolf. Die Themen des Buches umfassen die Architekturvision und den inkrementellen Entwurf, Continuous Integration, Testgetriebene Entwicklung, Refactoring mit und ohne Refactoring-Browser, automatisierte Akzeptanztests, Pair Programming, Collective Ownership, Coding-Dojos und Code-Katas, Modellgetriebene Entwicklung und Entwicklungspraktiken bei verteilter Entwicklung.

Es ist seit langem bekannt, dass in größeren Scrum-Projekten kein Weg daran vorbei geht, dass das Team passende Entwicklungspraktiken auswählt. Die Entscheidung, welche Techniken eingesetzt werden, obliegt in Scrum dem Team. Aus unserer Sicht sollte das Team aber die in Frage kommenden Techniken kennen und beherrschen, um eine qualifizierte Entscheidung treffen zu können. Wir hoffen, das unser Buch einen Beitrag dazu leistet.

Wer sich bereits intensiv mit eXtreme Programming auseinandergesetzt hat, dem wird vieles bekannt vorkommen. Wir hoffen, aber auch diesen Lesern einen Mehrwert bieten zu können, indem das Buch den aktuellen Stand der Technik beschreibt.

„Agile Entwicklungspraktiken mit Scrum“ bei Amazon bestellen!

Bedürfnisse und Features auseinander zu halten fällt vielen Product Ownern sehr schwer. Heraus kommen dann Formulierungen, in denen Bedürfnisse und Key-Features identisch sind – nur leicht anders formuliert. Beispiel: „Menschen, die andere Menschen anrufen wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“

Wenn man vor der Frage steht, ob etwas wirklich ein Bedürfnis ist, hilft die Maslowsche Bedürfnispyramide. Sie hat diese Stufen (von unten nach oben):

1. Physiologische Bedürfnisse: Atmung, Schlaf, Nahrung, Wärme, Gesundheit, Wohnraum, Kleidung, Sexualität, Bewegung
2. Sicherheit: Recht und Ordnung, Schutz vor Gefahren, festes Einkommen, Absicherung, Unterkunft
3. Soziale Bedürfnisse: Familie, Freundeskreis, Partnerschaft, Liebe, Intimität, Kommunikation
4. Anerkennungsbedürfnisse: Höhere Wertschätzung durch Status, Respekt, Anerkennung (Auszeichnungen, Lob), Wohlstand, Geld, Einfluss, private und berufliche Erfolge, mentale und körperliche Stärke
5. Selbstverwirklichung: Individualität, Talententfaltung, Perfektion, Erleuchtung, Selbstverbesserung

Jetzt müssen wir uns lediglich die Frage stellen, auf welche Stufe unser „Bedürfnis“ fällt. Wo würde man das vermeintliche Bedürfnis „telefonieren“ verorten? Genau! Es passt da nicht rein. Man kann telefonieren, um in Kontakt mit seiner Familie oder seinen Freunden zu bleiben. Dann wäre genau das das Bedürfnis und wir könnten z.B. schreiben: „Menschen, die im sozialen Kontakt mit ihrer Familie bleiben wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“

• Upfront Architekturvision vs. inkrementeller Entwurf während der Sprints
• die Rolle des Architekten in Scrum
• Einsatz von Tools zur Architekturüberwachung in Scrum

Das Interview gibt es in einer Kurzfassung (siehe http://vimeo.com/19394558, 42 Minuten) und vollständig (siehe http://vimeo.com/19389234, 53 Minuten).

Red Pencil Code Kata

Nützliche Test-Mnemomics finden sich hier: http://www.qualityperspectives.ca/mnemonics.html

Ich komme eher aus der Programmier- als der Testecke und fand die Testing-Dojos vor diesem Hintergrund sehr spannend. Ich konnte dort sehr effektiv mitkriegen, wie die Tester arbeiten. Ich empfehle damit explizit auch allen Entwicklern, Testing-Dojos zu besuchen. Es kann wirklich sehr wertvoll sein, die Arbeit der Tester besser zu verstehen. Und es ist natürlich sehr wertvoll, selbst besser testen zu lernen.

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 13,000 times in 2010. That’s about 31 full 747s.

In 2010, there were 41 new posts, growing the total archive of this blog to 506 posts. There were 37 pictures uploaded, taking up a total of 21mb. That’s about 3 pictures per month.

The busiest day of the year was January 7th with 150 views. The most popular post that day was Festpreise und schneller durch Scrum.

Where did they come from?

The top referring sites in 2010 were stefanroock.de, blogs.isixsigma.com, twitter.com, google.de, and stefanroock.blogspot.com.

Some visitors came searching, mostly for stefan roock, prolog cut, code kata, webcastellum, and roock.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Festpreise und schneller durch Scrum January 2010
4 comments

Kanban: Definition of Lead Time and Cycle Time March 2010
7 comments

Code Kata Bunkai: Prime Factors January 2010
11 comments

Profil ansehen February 2009

Scrum vs. Kanban: Ziel und Weg March 2010
4 comments

Das Buch kommt schnell auf den Punkt. Für jemanden, der Lisp noch nie gesehen hat und für den funktionale Programmierung ganz neu ist, könnte das Buch evtl. etwas schwer verständlich sein.

Ich finde, das Resultat ist eine einfache, fokussierte Sprache, die einfach zu lernen ist und Spaß macht. Dazu trägt auch bei, dass Clojure bewusst funktional ist und kein OO-Hybrid. So wird man als OO-Entwickler gezwungen, sich einer anderen Perspektive beim Programmieren zu öffnen und das ist auf jeden Fall nützlich – und sei es nur zur Horizonterweiterung.

Neben der eigentlichen Sprache bietet Clojure einige eigene Bibiotheken, insbesondere für die Programmierung paralleler Algorithmen. Durch die funktionale Struktur von Clojure-Systemen gestaltet sich dieses Themengebiet in Clojure viel einfacher als z.B. in Java. Ich bin zwar der Meinung, dass parallele Algorithmen im Moment deutlich überschätzt sind. Aber wenn man meint, dass man es braucht, dann sollte man sich Clojure auf jeden Fall mal ansehen.

Und wenn man keine parallelen Algorithmen braucht, sollte man sich Clojure auch ansehen und z.B. die eine oder andere Code-Kata in Clojure programmieren. Es hat schon seinen eigenen Charme, vollständig funktional zu programmieren.

1. Movement trumps sitting. So we moved all the time and sat down very seldom.
2. Talking trumps listening. We talked in pairs or in small groups during the whole training.
3. Images trump words. Whenever possible Sharon used drawings, metaphors, stories etc.
4. Writing trumps reading. We read few things and wrote down insights individually or as a workgroup.
5. Shorter trumps longer. The content delivery was split up in very small chunks, each shorter than 10 minutes.
6. Different trumps same. We applied lot’s of different practices to learn the content.

I highly recommend the training and the book to everybody who does training.

The Liskov Substitution Principle
The Liskov Substitution Principle (LSP): „[...] states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).“ (Source: Wikipedia).
The more formal definition of the LSP is: „Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.“ (Source: Wikipedia).
And to be complete, here is the definition of subtype: „In programming language theory, subtyping or subtype polymorphism is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program constructs, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype.“ (Source: Wikipedia).

While subtype and LSP sound similar, there is a difference: The subtype relation normally is interpreted as a syntactical property. If the required methods are available on an object, everything is valid. The Liskov Substitution Principle goes beyond that and adds a requirement on the semantics of the methods.

Example (in pseudo code)

class A {

    public void m() { ... do something ... }

}

class B extends A {

    public void m() {
        throw new Exception();
    }

}

In this case B is a subtype of A. B has the same methods as A. But the LSP may be violated. If the clients of A expect m to not throw an exception, B’s implementation of m breaks the LSP. Regarding the formal definition of the LSP („Let q(x) be a property provable about objects x of type T.“). The property q would be that the execution of m won’t throw an exception. This property is true for A’s implementation of m but not for B’s implementation of m. Therefore you shouldn’t use objects of class B where a client expects objects of class A. While that would be syntactically correct it isn’t semantically valid.

The Liskov Substitution Principle in class typed languages
In most statically typed object-oriented languages (like C++, Java, C#) the subtype relation is defined by inheritance between classes. When a class B inherits from a class A the defined type B is a subtype of A. The example above showed that the LSP may be violated due to specific method implementations provided by B.
Some languages (like Java) provide an interface concept. Interfaces only define the signature of methods but don’t provide method implementations. Classes implement interfaces and provide the method implementations. With interfaces the LSP is still a useful concept. The clients of an Interface C rely on a certain behaviour of the objects implementing the interface. Again the clients of C may assume that m won’t throw exceptions.

interface C {

    public void m();

}

class A implements C {

    public void m() {
        throw new Exception();
    }

}

In the example code A’s implementation of m will break the LSP.

These situations are clear and well understood. But what happens in programming languages with duck typing (like Ruby)?

The Liskov Substitution Principle in duck typed languages
In programming languages with duck typing (e.g. Ruby, Python, Smalltalk) classes don’t really define types. There is no type checking when assigning objects to variables or passing objects as method arguments. There is a kind of type checking when a method is called. It is checked that the method exists with a matching number of parameters.
Since classes don’t define types, inheritance in duck typed languages has nothing to do with the subtype relation or the LSP.
In a way clients define interfaces in an implicit way. Let’s look at an example:

def my_method1(a) do
    a.m1()
    a.m2()
    my_method2(a)
end

def my_method2(a) do
  a.m3()
end

Calling my_method1 with an object a will succeed if the object a provides the three methods m1, m2 and m3. This is the implicit interface the object a needs to implement. And with this implicit interface comes the clients expectation about the behaviour of m1, m2 and m3. That’s just the same as with the Java interface. If an object b provides m1, m2 and m3 but doesn’t fit the expected behaviour, the LSP is violated.

Conclusion
The LSP isn’t tied to inheritance or class based typing. It applies to duck types languages as well as to systems without inheritance. LSP is a concept that applies to all kinds of polymorphism. Only if you don’t use polymorphism of all you don’t need to care about the LSP.

Ich werde dort über ScrumBut vortragen und würde mich freuen, Euch zahlreich auf den XP-Days zu treffen.

Abstract meines Vortrags

Es gibt immer wieder die Frage nach Anpassungen an Scrum. Für Anpassungen, die man nur macht, um Probleme nicht lösen zu müssen, hat Ken Schwaber den Begriff ScrumBut geprägt. Im diesem Vortrag geht es um die Frage, welche Anpassungen an Scrum gerechtfertigt sind und von welchen man lieber die Finger lassen sollte.

Das Buch richtet sich an Produktmanager/Product Owner und ist aufgeteilt in drei Teile: People, Process, Product. Das Buch hat seinen Schwerpunkt auf Internet-Anwendungen. Viele der dargestellten Konzepte sind auf andere Anwendungstyper aber problemlos übertragbar.

Der People-Teil hat mir nicht so viel gegeben. Was dort steht, ist alles richtig, aber vieles davon schien mir selbstverständlich. Das ist vielleicht meinem agilen Hintergrund geschuldet. Anderes erschien mir zu unkonkret.

Die Teile über Prozess und Produkt fand ich viel besser. Hier stehen absolut richtige und wichtige Dinge für Produktmanager / Product Owner. Vor einem Scrum-Hintergrund liefert das Buch unter anderem konkrete und nützliche Hinweise dazu, was der Product Owner vor dem ersten Sprint zu tun hat. Besonders gut hat mir gefallen (weil es in der Praxis leider häufig anders gehandhabt wird):

• Cagan macht deutlich, dass es einen Unterschied zwischen Anwenderanforderungen und Produktfeatures gibt. Nicht alles, was sich Anwender wünschen, muss oder sollte umgesetzt werden.
• Das bedeutet aber nicht, dass der Produktmanager keinen Kontakt zu Anwendern haben muss. Das Gegenteil ist der Fall; er muss von Beginn an sehr engen Kontakt mit den Anwendern pflegen und kann diese Aufgabe auch nicht delegieren.
• Produktideen müssen validiert werden. Das kann bis zu einem gewissen Maße bereits vor Beginn der eigentlichen Entwicklung (erster Sprint) geschehen. Dazu sind Prototypen notwendig, die man direkt Anwendern zeigt und Feedback einholt. Auch das muss der Produktmanager persönlich tun und kann es nicht delegieren.

Es gab nur einen Punkt, wo ich eine andere Meinung vertrete als Cagan: Er erweckte bei mir mehrfach den Eindruck, als schwebe ihm eine sehr strikte Trennung zwischen Produktmanagement und Entwicklung vor. Ich glaube, dass man sich damit viele Chancen vertut und stattdessen eine sehr enge Zusammenarbeit zwischen beiden Parteien anstreben sollte, in der die Entwickler nicht einfach nur das liefern, was der Produktmanager bei ihnen bestellt, sondern zusammen mit dem Produktmanager konzipieren.

Fazit: Ein äußerst wertvolles Buch für jeden Produktmanager/Product Owner (auch wenn nach Wasserfall entwickelt wird).

Im Einzelnen (+ bedeutet, dass es besser ist als Thinkpad/Ubuntu, – bedeutet, dass es schlechter ist, = bedeutet, dass es ungefähr gleich ist):

Gehäuse
+ Aluminium fühlt sich edel an
- sieht aber mit etwas Abstand eigentlich genauso aus wie billiges Plastik
- ist etwas rutschig, wenn man zugeklapptes Gerät aufrecht trägt
- lädt sich bei passendem Wetter elektrostatisch auf, so dass man beim Anfassen manchmal leichte Stromschläge bekommt
- mattes Display kostet Aufpreis
+ Akku kann man nicht einfach so austauschen und es gibt anscheinend keinen Zweitakku
- es gibt keine Docking-Station, aber fast alles ist USB also tut es auch ein USB-Hub

Tastatur
+ beleuchtet
- Return-Taste sehr klein
- Cursor-Tasten sehr klein
- kein POS1/Ende: Im Prinzip durch andere Tastenkombinationen ersetzbar, aber die sind nicht in allen Apps verfügbar oder kollidieren mit Spaces
- keine Page-Up/Page-Down-Tasten
- Anschlag: nicht so gut wie bei Lenovo Thinkpad, aber besser als bei Billig-Dell
= Was auf PC „Ctrl“ heißt hier „Cmd“ und „Ctrl“ auf dem Mac ist was ganz anderes. Daran habe uch mich aber schnell gewöhnt.
- []|{} ist nicht auf die Tasten drauf gedruckt. Ich weiß, wo die Zeichen sind, habe beim Tippen aber doch immer eine leichte Verzögerung.

Trackpad
+ sehr groß und dadurch gewöhnungsbedürftig: am Anfang hatte ich da immer mehrere Finger drauf und habe versehentlich Gesten ausgeführt; daran habe ich mich aber schnell gewöhnt und habe jetzt Probleme mit den kleinen Trackpads der PC-Notebooks
+ durch die Größe arbeitet man eher mit beiden Händen (eine für Bewegung, eine für Klicken, was wiederum ganz angenehm sein kann)
+ Gesten für Scrollen, Zoomen, Drehen etc.

Sleep-Mode
+ Der Rechner erwacht super-schnell aus dem Sleep-Mode.

Betriebssystem/Oberfläche
+ die allermeisten Mac-Programme haben eine sehr gefällige und einheitliche Optik. Das ist deutlich angenehmer als unter Ubuntu.
- Spaces kommen nicht an Linux heran: sind mit der Maus nur umständlich zu benutzen
- Spaces: keine Visualisierung der offenen Fenster in der Menüleiste, dadurch schlechte Übersicht, was man wo auf hat
+ Dock: Nett
= Drucken ging nicht auf Anhieb mit MP620; ich musste Treiber bei Canon runterladen; immerhin gibt es welche für Mac und sie funktionieren auch gleich einwandfrei
= Spot-Light ist nützlich (ähnlich dem Ubuntu-Äquivalent)
- Finder kann kein FTP/SFTP (im Gegensatz zu Ubuntu Nautilus)
- Der Finder hat insgesamt ein paar nette Features und teilweise total verwirrendes Verhalten. Das scheint mir mal ein Komplett-Rewrite angesagt.
- Nach wir vor finde ich merkwürdig und auch eher störend, dass Programme weiterlaufen, auch wenn alle Fenster geschlossen sind.
- Die Anzeige der Akku-Restlaufzeit scheint mir ziemlich erratisch. Nach dem Laden des Akkus zeigt der Mac 5:30 Stunden an. Nach 30 Minuten harmloser Aktivität sind noch 2 übrig.

Applikationen
+ Skype ist einfacher zu installieren als unter Ubuntu; Video funktioniert auf Anhieb; keine Audio-Probleme
+ DVD geht sofort. Allerdings hat der mitgelieferte DVD-Player deutliche Usability-Defizite (z.B. beim Einschalten des Vollbild-Modus)
- MPEG, WMV gehen nicht auf Anhieb und man muss Zusatzkram im Internet finden und runterladen
- Safari öffnet Links immer in neuen Fenstern und man kann das in Safari selbst nicht umstellen. Wenn man „defaults write com.apple.Safari TargetedClicksCreateTabs -bool true“ in der Console startet und dann Safari neu startet, werden Links in Tabs geöffnet. Das ist mir alles zu nervig und ich benutze dann doch lieber Firefox auf Mac.
- Installation von Komponenten und Software ist in Ubuntu über das Software-Center viel eleganter gelöst als auf Mac. Aber vielleicht macht Apple hier ja mit dem geplanten Mac-App-Store Boden gut.
+ Synchronisation mit dem iPhone geht unter Mac natürlich nahtlos und ist unter Ubuntu leider eine ziemliche Katastrophe. Ubuntu erfordert eigentlich ein Android-Handy.

Programmierung
+ Ruby/Rails gleich drauf
= Installation aber sonst wie Linux: Compilefehler bei gem install webrat, weil man erst 2,5 GB XCode-Kram installieren muss
- Vervollständigung mit Tab in der Shell funktioniert nur Top-Level, aber nicht mehr danach (git pull origin master)
- Für Navigation in einer Zeile in der Shell muss man sich eigene Tastenkürzel merken oder irgendwas konfigurieren, was ich nicht verstanden habe.
+ TextMate ist ganz cool

Wie gesagt, meine persönliche Bewertung für meine speziellen Einsatzkontexte. Ich nutze z.B. durch meine Reiserei viele Multimedia-Funktionalitäten (DVD im Hotel), Skype zum Telefonieren etc. Wenn ich den Rechner nur zum Programmieren verwenden würde, würde ich Ubuntu den Vorzug geben.

We will puplish the results after the poll ended.

Die PDFs der Folien finden sich hier zum Download.

Ich hatte meinem Vortrag begonnen mit einem Beispiel für wirklich schlecht strukturierten Code (siehe Folien) und habe ein paar Fragen ans Publikum gestellt. Die Antworten finde ich ganz interessant (die Zahlen stimmen im Detail wohl nicht, weil ich sie aus der Erinnerung rekonstruiert habe – die Größenordung passt aber).

• Wer ist sich sicher, dass es so schlecht strukturierten Code bei ihm im Projekt/Unternehmen gibt? Meldungen: 40
• Wer ist sich sicher, dass es solchen Code bei ihm nicht gibt? Meldungen: 1
• Wer ist sich unsicher? Meldungen: 5
• Wer kennt TDD? Meldungen: 30
• Wer nutzt TDD? Meldungen: 20
• Wer kennt SOLID? Meldungen: 20
• Wer nutzt SOLID? Meldungen: 10

Das Ergebnis passte auf jeden Fall gut zur Argumentationslinie meines Vortrags. Obwohl zumindest ein Teil der Teilnehmer TDD und SOLID kennen und nutzen, scheint es nur geringe Auswirkungen auf die Code-Qualität zu haben. Nach meiner These nützt das beste Handwerkszeug nichts, wenn man es unter Druck nicht anwendet.

Daher mein Argument, wir müssten Berufsehre für unsere Branche etablieren: Wir sind stolz auf unseren Code und schreiben nichts, was unter diesem (subjektiven) Qualitätsstandard liegt. Nichts. Niemals. Und wenn wir dort angekommen sind, werden uns Vorgehensweisen wie TDD und Entwurfsprinzipien wie SOLID wirklich wichtige Dienste leisten.

Warum man das Manifesto for Software Craftsmanship unterzeichnen und sich ein Clean-Code-Armband besorgen sollte, steht in den Folien.

Inzwischen habe ich auch viele Beispiele aus meiner beruflichen Praxis, die die Handskizzen-These des Napkin-Ansatzes unterstützen. Ich arbeite z.B. in meinen Schulungen gänzlich ohne Folien, sondern erstelle Visualisierungen während der Schulungen auf Flipcharts. Es gab bisher keinen einzigen Teilnehmer, der das bemängelt hätte. Es gab aber sehr viele, die das Vorgehen explizit gelobt haben. Ein anderes Beispiel ist eine Konzeptarbeit für ein großes deutsches Unternehmen. Ich habe die ganze Konzeption am Flipchart gemacht und auch die Management-Präsentation der Ergebnisse mit Flipcharts gehalten. Die Resonanz war außerordentlich positiv. Auf Wunsch des Kunden hin habe ich danach die Flipcharts 1:1 nach Powerpoint überführt, nur eben professionell mit den Zeichen- und Formentools von Powerpoint. Kommentar des Kunden: „Danke für die Powerpoint-Präsentation. Hm. Die Flipcharts waren irgendwie doch besser.“

Unfolding the Napkin ist das Folgebuch zu The Back of the Napkin, das ich bereits in einem früheren Blogpost empfohlen hatte.

Beide Bücher widmen sich dem Thema der Visualisierung, um Probleme darzustellen und zu lösen. Der passende Untertitel zu „Unfolding the Napkin“ lautet entsprechend: „The hands-on method for Solving Complex Problems with Simple Pictures“. Während das erste Buch die Konzepte eher theoretisch erläutert, ist „Unfolding the Napkin“ ein Praxisbuch mit vielen Übungen, die man direkt für sich ausprobieren kann. Ich fand „The Back of the Napkin“ schon sehr schön, finde „Unfolding the Napkin“ aber noch besser. Ich vermute, dass man „Unfolding the Napkin“ auch dann sehr gut verstehen kann, wenn man „The Back of the Napkin“ vorher nicht gelesen hat.

Meiner Meinung nach ist das Buch extrem wertvoll für jeden, der Probleme oder Konzepte erstellen oder präsentieren will oder muss: Trainer, Berater, Entwickler, …

Kanban has two key properties:

1. Limit work in progress to an upper limit with a preference for lower limits.
2. Pull from upstream processes.

Therefore in Nabnak you would

1. Ensure that work in progress never falls below a bottom limit with a preference for higher limits.
2. Push work to downstream processes.

OK, that sounds completely ridiculous. But when would you possibly do such a thing. Perhaps when two conditions hold true:

1. Developers are so expensive that a high utilization outperforms all other metrics.
2. At the same time developers are too dumb to pull work. Somebody has to push the work to them.

These two conditions seem mutually exclusive. Therefore Nabnak is in fact complete nonesense. But guess what: I am not the inventor of Nabnak – I just gave it a fancy new name. Nabnak was formerly known as waterfall.

You may not like Kanban but it is not a new name for waterfall. If there is a new name for waterfall it is reversed Kanban: Nabnak.

P.S.: In fact there may be useful applications of a minimum work in progress limit for certain columns of a Kanban board. I may blog about that in another article.

Sorry, but that is bullshit. If the Scrum meetings feel like wasteful overhead, it is almost always your own failure.

Focus is one of the Scrum values. If your Scrum meetings feel wasteful, they need better focus. Stop doing the things that don’t provide value.

Let’s look at the meetings one by one.

Estimation Meeting

During the estimation meeting two things should happen:

1. The product backlog items are estimated by the team.
2. More important: Knowledge is shared between Product Owner and Team and the Team participates in definition, splitting and refining product backlog items.

If the Product Owner doesn’t have to forecast a release date or development effort, he could simply skip point 1. An alternative could be to use a very rough estimate and simply use an estimation of 1 story point for every backlog item.

If the product backlog items are simple and clear point 2 may not be neccessary. In that case you could simply skip it.

If both points aren’t neccessary you can skip the whole meeting. There is a reason that the estimation meeting is not an official part of Scrum.

Sprint Planning

The goal of the sprint planning is of course to plan the Sprint. It is dependent on the team how it is done best and how much effort the team has to invest. I have seen teams doing a Sprint Planning in a few minutes.

Doing a task breakdown is a proven practice during the Sprint Planning but it is not a must. If the team can generate value with only considering the stories, the team doesn’t need to do a task breakdown during the Sprint Planning. The team could do an ad-hoc task breakdown when it begins working on the story. If the stories are really tiny the team may need no task breakdown at all.

Sprint Review

If the Product Owner is colocated with the development team he should have seen the implemented stories before the Sprint Review. Therefore there may be no need to present the stories again to the Product Owner during the Sprint Review. But there is much more to the Sprint Review. The Product Owner should invite the stakeholders to the Sprint Review meeting so that they can get a first-hand impression about status and progress of the development.

Sprint Retrospective

The Sprint Retrospective is the focus point where the teams tries to improve. If the retrospectives feel like waste, the facilitator is probably not doing his job effectivly.

Daily Scrum

The 15 minutes of the Daily Scrum should help the development team to focus on the next step within the Sprint. The team finds out where it stands and defines the plan for the day. A team may or may not use the full 15 minutes. But if there is a team the members simply have to coordinate. Within very small teams (e.g. 2 persons) there may be no need for a Daily Scrum. But even in these cases I have seen Daily Scrums to be very useful.

Similar to the retrospectives: If the Daily Scrum feels like waste, probably the ScrumMaster isn’t facilitating effectivly.

Assumptions

There are two assumptions underlying this blog post:

• You want to work with a team and not just a group of people.
• You want to work with timeboxed Sprints.

If one of these assumptions doesn’t hold true, one may come to other conclusions.

Nützliche Literatur zu dem Thema findet sich z.B. in den beiden Büchern „Coaching – erfrischend einfach“ von Daniel Meier und Peter Szabo sowie „Wege zur erfolgreichen Teamentwicklung“ von Daniel Meier.

Das erste Buch erklärt die Ideen und Techniken des lösungsorientierten Coachings auf individueller Ebene. Der Hintergrund ist allgemeines Coaching und nicht speziell IT. Die beschriebenen Techniken lassen sich aber leicht auf IT-Kontexte (z.B. für die Arbeit als ScrumMaster) übertragen. Das Buch ist angenehm kurz und leicht verständlich geschrieben.

Das zweite Buch beschreibt, wie man Lösungsorientierung für Teams einsetzt. Auch dieses Buch ist leicht verständlich geschrieben.

Wer sich näher mit dem Thema Lösungsorientierung beschäftigen möchte, dem lege ich diese beiden Bücher als Einstieg nahe (und natürlich das oben beschriebene Retrospektiven-Training

it-agile bietet am 25.08.2010 ein eintägiges Training zur Vorbereitung und Durchführung bon Retrospektiven an. Es eignet sich für alle, die Retrospektiven durchführen wollen, z.B. für ScrumMaster.

Ich werde das Training mit Josef Scherer durchführen, der wie ich langjährige Erfahrungen in agilen Projekten mitbringt.

CodersDojo.org supports performing and improving Code Katas. Opening http://codersdojo.org with the internet browser of your choice shows the home page of CodersDojo.

By clicking „Enter the Dojo“ we enter the virtual Dojo, where we perform the Kata (until now only Ruby is supported).

In the right area a dummy test is displayed. We replace the dummy test with the first (test) step of our Kata (in this case the Fibonacci numbers). To make things simple we put production and test code in the same file.

With clicking „Run“ we run the test. The result is displayed in the left screen area.

Now we write only so much production code that the test succeeds.

This way we test drive the solution.

By clicking „Finish“ we get the analysis of the Kata.

There we see the overall duration of the Kata, the number of steps and a visualization of the TDD steps (red, green).

To improve the Kata we can give a collegue access to the Kata so that he can give feedback. We simply send him the link that is displayed at the bottom of the page. When the collegue opens the link he starts with the first step of the Kata. On the left side he can see the Code before and after the first „Run“. On the right side a text area waits for comments.

Our collegue can navigate forth and back through the Kata. When something strikes our collegue he adds his comment to the step.

Try it and give us feedback about CodersDojo!

Als Alternative gibt es die sogenannte Lösungsorientierung. Diesen Ansatz gibt es auch schon lange, aber er wird erst jetzt populärer. Beim lösungsorientierten Ansatz versucht man nicht, die Ursachen für Probleme zu analysieren. Stattdessen sucht man direkt nach Lösungsansätzen. Das geschieht z.B. so, dass man fragt, ob es Situationen oder Zeiten gab, in denen das Problem nicht oder weniger stark aufgetreten ist. Die gibt es eigentlich immer. Und dann fragt man, was in diesen Situationen anders war. Und diese andere versucht man dann, wieder herzustellen bzw. zu verstärken.

Problemorientierte Ansätze funktionieren offensichtlich nur dann, wenn es eine stabile und nicht zu komplexe Problem-Ursache-Beziehung gibt. Das ist z.B. in Build-Systemen der Fall oder eben in der Produktion bei Toyota. Wenn am dem Problem Menschen beteiligt sind, ist das häufig nicht der Fall. Dann hat man fluktuierende Ursachen oder die Beziehungen zwischen Problem und Ursachen sind so komplex, dass wir sie nicht analytisch durchdringen können.

Ich habe solche Situationen in Retrospektiven schon mehrfach gesehen. Da war es so, dass bei der Root-Cause-Analysis letztlich nur ein schlappes “OK, wir geben uns mehr Mühe” als Maßnahme herauskam. Oder es kamen konkrete Maßnahmen raus, aber nach deren Umsetzung war das Problem immer noch unverändert da. Und wieder und wieder…

In diesen Fällen kommt man mit problemorientierten Ansätzen also nicht weiter. Wenn man weiterkommen will, sind lösungsorientierte Ansätze Erfolg versprechender. Dabei besteht natürlich das Risiki, dass man die eigentliche Ursache nicht beseitigt und die ganze Zeit nur Work-Arounds baut. Aber das ist immer noch besser, als mit Aufwand Ursachen zu analysieren, die auf jeden Fall sinnlose Maßnahmen hervorbringen.

Ein weiterer Vorteil lösungsorientierter Ansätze ist, dass sie häufig viel schneller sind. Um eine Root-Cause-Analysis vernünftig durchzuführen, brauche ich in einfachen Fällen mind. 30 Minuten. Mit lösungsorientierten Ansätzen ist man häufig schon nach 5 Minuten durch.

Ich gucke da nicht so drauf, dass lösungsorientierte Ansätze generell besser sind als problemorientierte. Es sind einfach zwei Werkzeuge, die ich in unterschiedlichen Situationen anwende.

Ich führe zusammen mit Josef Scherer am 25.08.2010 in Hamburg eine Retrospektiven-Schulung durch, in der sowohl problem- wie auch lösungsorientierte Ansätze durchgenommen werden. Näheres dazu findet sich bei it-agile.

Wir sind in der Diskussion dann darauf gekommen, dass bzgl. der Sprints kürzer nicht unbedingt besser bedeuten muss. Bei sehr kurzen Sprints können folgende Probleme auftreten.

1. Es kann passieren, dass sich kein motivierendes Sprintziel mehr formulieren lässt.
2. Der Zeitrahmen im Sprint kann so eng werden, dass im Sprint nicht mehr konzeptionell gearbeitet werden kann. Das kann zu einer sehr strikten (tayloristischen) Arbeitsteilung zwischen Product Owner und Team führen.
3. Diese beiden Punkte zusammen können zu routinisierter langweiliger Arbeit führen. Und wenn das eintritt, wird es für das Team sehr schwer, innovative Verbesserungsvorschläge in Retrospektiven zu generieren.
4. Bei Fehlern hat das Team keine Zeit mehr, um den Sprint trotzdem noch zu schaffen. Das kann zu Defensivverhalten führen und dazu, dass nicht mehr experimentiert wird.

Tatsächlich habe ich solche Fälle auch gesehen, z.B. bei einem Team, das in einem lang laufenden Projekt mit einwöchigen Sprints gearbeitet hat. Das Team hatte eine sehr verlässliche Geschwindigkeit und hat fast alle seine Commitments gehalten. In dem Projekt hätten wir aber einen deutlichen Produktivitätsschub gebraucht. Tatsächlich haben aber die in den Retrospektiven generierten Maßnahmen aber vor allem dazu geführt, dass die Geschwindigkeit noch stabiler wurde. Damals konnte ich mir keinen Reim darauf machen und war sehr verwirrt. Aus heutiger Sicht halte ich es für wahrscheinlich, dass die kurze Sprintlänge mit verantwortlich war. Heute würde ich dem Team empfehlen, mal längere Sprints auszuprobieren.

Wie gesagt: Das muss nicht so passieren. Ich habe auch sehr erfolgreiche und kreative Teams mit einwöchigen Sprints gesehen und Ilja hat mir glaubhaft versichert, dass auch die zweitägigen Sprints sehr erfolgreich waren.

P.S.: Das ändert alles nichts daran, dass die Teams in der Lage sein sollten, bei Bedarf sehr kurze Sprints umsetzen zu können – also in sehr kurzer Zeit ein Done-Done Produktinkrement zu erstellen.

CodersDojo.org unterstützt Code-Katas. Nach Aufruf von http://codersdojo.org erscheint die Start-Seite.

Mit „Enter the Dojo“ betreten wir das virtuelle Dojo, in dem wir die Kata durchführen (bisher nur in Ruby).

Im rechten Bereich wird ein Dummy-Test vorgeschlagen. Wir ersetzen den Dummy-Test durch den ersten (Test-)Schritt unserer Kata (in diesem Fall die Fibonacci-Reihe). Um die Angelegenheit möglichst einfach zu gestalten, schreiben wir Produktiv- und Testcode in dieselbe Datei.

Durch click auf „Run“ führen wir unseren Test aus. Links wird das Ergebnis der Testausführung angezeigt.

Jetzt schreiben wir soviel Produktivcode, dass der Test durchläuft.

So entwickeln wir schrittweise testgetrieben unsere Lösung.

Durch click auf „Finish“ gelangen wir zur Auswertung der Kata.

Dort sehen wir die Gesamtdauer der Kata, die Anzahl der Schritte und eine Visualisierung der TDD-Schritte (rot, grün).

Zur Verbesserung der eigenen Fähigkeiten können wir die Kata einem Kollegen zur Kommentierung zur Verfügung stellen. Dazu senden wir ihm den Link, der unten auf der Seite angegeben ist. Öffnet der Kollege den Link, sieht er den ersten Schritt der Kata. Links sieht er den Code vor und nach dem ersten „Run“. Rechts steht ein Feld für seine Kommentare zur Verfügung.

Der Kollege kann durch die Kata navigieren. Wo ihm etwas auffällt, schreibt er seinen Kommentar zu dem Schritt dazu.

Probiert es einfach mal aus und gebt uns Feedback zu CodersDojo.

Wie schon in den letzten Jahren gibt es einen offenen Review-Prozess für die Einreichungen. In diesem kann jeder Feedback zu den Einreichungen geben und die Einreicher können auf Basis des Feedbacks ihre Einreichungen verbessern. Es lohnt sich also, seine Vorschläge sehr früh einzureichen. Iterativ können sie dann während des Review-Prozesses verbessert werden.

In letzter Zeit bin ich immer mal wieder auf die Annahme gestoßen, Scrum würde nicht zu Spezialisierungen passen. Das halte ich für Unsinn. Faktisch macht Scrum keine Aussage zu Spezialisierungen.

Scrum fordert Teamwork und crossfunktionale Teams. In diesen Teams dürfen natürlich Spezialisten sitzen. Damit diese Spezialisten als Team gut funktionieren, müssen sie ein Mindestmaß an gegenseitigem Verständnis aufbauen. Sonst können Sie sich untereinander nicht effektiv koordinieren. Die Frage, ob sie ihre Spezialisierungen dann ganz oder teilweise aufgeben, ist keine Scrum-Frage, sondern eine, die die Organisation bzw. das Team für sich beantworten muss.

Nochmal zusammengefasst: Scrum kann mit Spezialisten gut leben. Scrum kann mit nicht-Teamarbeit nicht gut leben.

Ein Release definiert eine Mission: Wir wollen mit dem System Live sein bis Datum X und wollen damit Ziel Y erreichen. Das ist relativ offensichtlich.

Eine Ebene darunter können wir die Sprints benutzen, um Missionen zu definieren. Besteht das Sprintziel nicht einfach nur darin, ein Sammelsurium von Anforderungen umzusetzen, sondern darin, ein fokussiertes Ziel zu erreichen, stiftet das Sprintziel die Mission. Ein Beipiel für ein solches Sprintziel könnte sein: „Wir haben die Review-Funktion von CodersDojo.com soweit fertig gestellt, dass wir selbst damit arbeiten mögen.“

Und selbst im Daily Scrum kann das Team seine Mission für den Tag definieren, z.B. „Heute schaffen wir es, dass die Reviews eingegeben und gespeichert werden können.“

Gut definierte Missionen erhöhen die Motivation der Beteiligten ganz erheblich und führen so zu deutlich höherer Produktivität. Denn man weiß heute, dass Motivation nicht durch Geld hergestellt wird, sondern durch

• Autonomy: Das Team entscheidet, welche Tasks es in welcher Reihenfolge wie erledigt.
• Purpose: Die Aufgabe und das Ziel erscheinen dem Team sinnvoll über das reine Geldverdienen hinaus.
• Mastery: Das Team „brennt“ für das, was es tut.

Autonomy wird in Scrum dadurch hergestellt, dass das Team und nur das Team bestimmt, wie es innerhalb des Sprints vorgeht. Gut definierte Missionen können Purpose und Mastery ganz erheblich unterstützen. Zu dieser Sicht auf Motivation siehe den ainimierten Vortrag „Drive“ auf YouTube. Nicht nur der Inhalt ist interessant, auch die Form der Visualisierung ist absolut sehenswert.

Der Missionsgedanke hat mich übrigens vor einiger Zeit dazu bewogen, einem Kunden zu empfehlen, seine Sprintzyklen von 2 auf 4 Wochen zu verdoppeln. Dem Kunden war es seinerzeit nicht möglich, 2-wöchige Sprints mit einer motivierenden Mission zu versehen. Die Mitarbeiter waren entsprechend „gelangweilt“. Mit 4-wöchigen Sprints war es aber möglich. Mir schien es in dem Kontext sinnvoll, etwas Feedback zu opfern und dafür höhere Motivation zu bekommen.

from danhollisterduck (flickr)

Kanban installs a continuous improvement process. It does not predefine the direction of the improvement, since it does not define a value system. Therefore Kanban itself is not agile and it is not anti-agile. It just doesn’t care.

To define a proper value system is up to the companies using Kanban. Do they value Scrum-like teamwork over silos or vice versa? Do they value face-to-face communication over written documents or vice versa? And so on …

I suspect the definition of an underlying value system is often not done. And then you get Zombie Kanban, something without a soul. Zombies have an impetus to eat others brains but what is their real (long term) goal? Zombie Kanban has the impetus to shorten cycle times but without having a purpose. (Of course it’s better to shorten cycle times than eating other peoples brains. But that is simply not enough )

Just installing an improvement process is not sufficient. You have to define a value system or purpose. (See also tip #2 of this blog post from LSS Academy).

Otherwise you can order some of these for your company:

from Shiny Things (flickr)

Wie viel „Scrum by the Book“ muss man in der Praxis wirklich machen? Nicht jede Anpassung führt direkt in die Hölle. Auf der anderen Seite sind viele in der Praxis anzutreffende Anpassungen Quick Fixes für organisatorische Defizite. Der Vortrag stellt dar, wann Anpassungen angebracht sind und wann man besser vorsichtig ist.

• Vortrag auf Slideshare
• Vortrag als PDF

During the preparation of the retrospective I speculated a while about what steps are neccessary and how long I should plan for these. I reproduce the actual timeline here. Perhaps that is useful for others facilitating a dispersed retrospective.

Perparation
I had created the meeting in CardMeeting.com long before the retrospective took place. I emailed the link and password to all participants and asked them to test if CardMeeting would work on their computers. CardMeeting uses Java Applets and doesn’t run on every system straightaway. But in the end everybody managed to get cardmeeting running on his PC – there was no pattern I could understand: some participants had to use IE on Windows while for others only Firefox worked. I for myself had to switch to Chrome on Ubuntu since Firefox didn’t want to start the applet correctly.

At the PC of one participant CardMeeting broke down ten minutes after the retrospective had started. He then joined a collegue in the next office and they paired on front of one PC during the retrospective.

10 minutes: Introduction
After I welcomed everybody to the retrospective we did the privacy contract: everything discussed during the retrospective would belong to the team privately unless everybody agrees to another handling of the informations at the end of the retrospective.

Then I gave a short introduction to CardMeeting. I showed how to create, edit, move and trash cards. (We didn’t use the billboards to keep things simple.)

For the rest of the retrospective I took orientation from retrospectives.com and used the proposed four key questions.

10 minutes for question 1: What did we do well, that if we don’t discuss we might forget?
I created a white card with the question. The participants added green cards with their thoughts and placed them around my white card.

Then a funny problem occurred. In CardMeeting a newly created card is visible to the other participants immediately even if the creator hasn’t written something on it. When 20 people create cards in parallel it is hard to tell which card belongs to whom. So we observed some card robberies. But the participants adapted fast: Immediately after one had created a new card he moved the card far away from the center of the action, edited the card and then moved it back to the center of the action. That worked out sufficiently well. I even think of the card robberies as a welcomed little entertainment.

10 minutes for question 2: What did we learn?
I created a white card with the question. The participants added their thoughts on blue cards.

10 minutes: Read and understand the cards
Everybody read all cards and asked questions via Skype audio for understanding.

10 minutes: Cluster the cards
The participants clustered the green and blue cards from the first two questions. They used red cards to give the clusters headlines. The clustering went surprisingly well without any intervention from my side.

15 minutes for question 3: What should we do differently next time?
Again I wrote the question on a white card. The participants added their thoughs on yellow cards.

We needed 15 minutes for this question (in contrast to the 10 minutes for the first two questions) to create focused cards. Some of the originally created cards didn’t describe what the team should do differently but what outsiders (managers, customers etc.) should do differently. Some other cards were somewhat fuzzy in a „we must try harder“ manner. I commented on these cards that they didn’t match the question exactly.

5 minutes: Read and rework cards
All participants read all cards and the authors integrated the comments. In this step identical and similar cards were merged so that we didn’t need an additional clustering step.

5 minutes: Prioritize the cards
The previous step resultet in 17 yellow cards. For the prioritization every participant was allowed to attach two green cards to his favourite yellow card(s). Everybody had the possibility to attach red veto cards to yellow cards.

After the voting we ordered the green cards by the number of votes.

15 minutes: Select cards and define action
With respect to the votes there was a clear gap between the most voted six cards and the remaining eleven cards. Every of the six cards had a lot of votes. The eleven cards had no votes or just one or two. Therefore the participants decided to discard the eleven cards and work with the high voted six cards.

For the six yellow cards we created action items on blue cards and attached them to the yellow cards. That was pretty easy since the yellow cards were already very close to action items.

BTW: The previous step created one veto. Since the veto card was attached to one of the discarded cards we didn’t have to discuss the veto.

10 minutes for question 4: What still puzzles us?
I created the question on a white card and the participants added their thoughts on yellow cards.

5 minutes: Cluster the cards
The participants clustered the cards and created a red headline card for every cluster. This step was shorter than the clustering done before since there were very few yellow cards to consider.

5 minutes: Closure
In the end I initiated a discussion about the privacy policy we defined in the beginning. The participants were very open and wanted to put all the cards in their wiki. Unfortunately there is no export function in CardMeeting. One has to transfer the cards one by one with copy&paste. Therefore the participants decided to only transfer the committed action items to the wiki.

All in all the retrospective lastet nearly two hours.

Wrap-Up
After the retrospective I sent a Google-Docs feedback form to all participants and asked for their impressions. The participants gave the retrospectice a positive ROTI (return of time invested) – the retrospective was worth it. But the energy level and the quality of the results were a bit lower than in a conventional face-to-face retrospective.

I think there is a common pattern of distributed work that applied to the retrospective: it is possible but it is less effective than co-located work.

The partipants found CardMeeting useful and Skype acceptable.

Personally I observed a few differences compared to face-to-face retrospectives:

1. CardMeeting doesn’t attach the author of a card to the card. Therefore it is impossible to see who wrote which card. That leads to a higher degree of anonymity.
2. There is less discussion via Skype audio compared to a face-to-face retrospective. And more cards are written. Maybe this allowes the shyer people to participate stronger.
3. As the moderator I had to adapt some of my moderation techniques (e.g. voting with dots vs. voting with cards).
4. I felt the need to prepare the retrospective more detailed and plan for shorter steps. In hindsight I think the detailed planning and the shorter steps were useful. Since there were less discussions the energy level decreased fast during the „write cards“ steps. With the short steps there was an intervention by me every few minutes that raised the energy level again at least to a medium level.

What would I do differently next time?

1. I would like to use an alternative tool to CardMeeting – one reason is that I have the impression that CardMeeting isn’t developed any further. Unfortunately I don’t know of other tools that may work as a replacement.
2. For a single session two hours is too long. It is hard to concentrate and my headset caved an interesting pattern in my head. I will plan for a five minute break for the next time.

• Ich habe deutlich mehr Erfahrungen mit Kanban in echten Projekten gesammelt und hatte einige Aha-Erlebnisse. Wenn ich mal dazu komme, werde ich darüber bloggen.
• Ebenfalls zum Thema Kanban habe ich den Kanban-Coaching-Workshop in Stockholm bei David Anderson besucht. Interessanterweise haben die Kanban-Projekte und der Workshop auch dazu geführt, dass ich Scrum noch besser verstanden habe.
• Ich habe „Clean Code“ von Robert Martin gelesen. Mein Blogartikel dazu findet sich hier.
• Ich habe eine ganze Menge Rails programmiert, um mich selbst bei Laune zu halten. Im selben Projekt habe ich als Product-Owner gearbeitet, was auch wieder interessante Erkenntnisse mit sich gebracht hat. Das zugehörige Projekt wird in Kürze veröffentlicht.
• Auf den XP-Days habe ich an einer Open-Space-Session zum lösungsorientierten Coaching bei Josef Scherer teilgenommen. Das fand ich sehr interessant und habe mich danach weiter in dem Thema vertieft. Dazu werde ich ebenfalls mal einen Blog-Eintrag schreiben, wenn ich mal wieder Zeit dazu habe.
• Und ich habe brav weiter schwimmen geübt. Brustschwimmen ist jetzt OK. Jetzt muss ich mich dem Kraulen stärker widmen.

Verglichen mit den vorhergehenden Quartalen ist das eine eher dürftige Ausbeute. Ich glaube, das liegt an dem Winter. Ich mag’ den Winter nicht. Der demotiviert mich. Aber jetzt wird es sicher besser

Also blieb da erstmal eine etwas resignierte Stimmung. Aber sollte das wirklich der Fall sein, dass es an dieser Stelle keinen Fortschritt geben kann? Wohl kaum. Nach etwas Nachdenken kam ich auf ein Function-Point-basiertes Modell. Der Auftraggeber würde einfach eine Produktvision mit High-Level-Backlog zur Verfügung stellen, damit der Anbieter weiß, wo es im Prinzip hingeht. Weiterhin würde der Auftraggeber die Anforderungen für den ersten Sprint fein granular beschreiben. Der Auftragnehmer würde die Anforderungen des ersten Sprints in Function-Points schätzen und ein Angebot auf Basis Euro/Function-Point abgeben. Auf diesen Preis würde er sich für einen gegebenen Zeitraum (z.B. 2 Jahre) verpflichten.

Damit hätte der Auftraggeber seine Basis für den Anbietervergleich, ohne dass man ein komplettes fein-granulares Lastenheft vorher braucht. Und zu allem Überfluss würde diese Art der Ausschreibung Ärger vermeiden, der heute durchaus an der Tagesordnung ist: jemand kauft sich das Projekt über einen Dumpingpreis und refinanziert es dann über überteuerte Change-Requests.

Ganz berauscht von meiner Idee habe ich mich etwas umgehört und konnte es kaum glauben: So innovativ ist meine Idee gar nicht. In den Behörden gibt es solche Überlegungen schon länger. Und anscheinend, ist das auch alles kompatibel mit dem deutschen Vergaberecht. Es findet sich nur auf Behördenseite kein Projektleiter, der bereit wäre, seine Ausschreibung so zu gestalten. Das finde ich aus agiler Sicht total schade und es hört sich so an, als würde hier eine Chance verschenkt, effektiver mit unseren Steuergeldern umzugehen.

Bei der Diskussion haben wir einen Punkt herausgearbeitet, den ich besonders hilfreich für die Differenzierung finde: Scrum hat ein bestimmtes Ideal vor Augen. (Wenn man das erreicht hat, sollte man sich natürlich noch weiterentwickeln.) Aber erstmal hat das Ziel eine klare Form.

Kanban hingegen installiert einen Verbesserungsprozess und lässt offen, wohin genau die Reise geht.

Dadurch ist es sehr einfach, Kanban zu machen. Setzt man auf Scrum, hat man erstmal eine Transitionsphase vor sich – die kann sehr lange dauern und durchaus schwierig sein. (Und so lange macht man eigentlich noch nicht richtig Scrum.) Natürlich kann man während der Transition auch in sehr kleinen Schritten vorgehen und damit eine behutsame Einführung von Scrum erreichen – ähnlich wie bei Kanban.

Auf der anderen Seite kann man mit Scrum etwas tun, was man mit Kanban nicht so gut tun kann: Man kann es als Revolution einführen. Und das kann tatsächlich sinnvoll sein. Ich habe immer wieder mit Unternehmen zu tun, die mit dem Rücken zur Wand stehen. Die brauchen einen schnellen und radikalen Wandel, wenn sie überleben wollen. Mit Kanban ist denen nicht geholfen. Die brauchen keinen Prozess, der sie schrittweise und risikoarm etwas besser macht. Die brauchen etwas, dass sie schnell viel besser macht. Und dafür sind sie bereit, auch die entsprechenden Risiken einzugehen.

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed.

This whole period of time is the lead time.

The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug.

Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live.

Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer.

In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time:

Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority.

With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.

Im Rahmen der Theory of Constraints gibt es sogar ein standardisiertes Verfahren zum Umgang mit Bottlenecks:

1. Identify. Identify the bottleneck of the system.
2. Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures, training, policies, etc.
3. Subordinate: Subordinate the throughput of all other work centers to this work center.
4. Elevate. Invest in this work center to increase its throughput – add equipment, manpower, etc.
5. Inertia. Start the process over on the line to determine the new bottleneck.

Das ganze kommt aus einer allgemeinen Systemtheorie und ist natürlich in der Produktion sehr wichtig und auch nützlich. Kanban für die Softwareentwicklung möchte die Theory of Constraints für die Softwareentwicklung auch anwenden. Und da lauert eine Fußangel, die ich auch nicht vorhergesehen habe.

Bei Kanban für die Softwareentwicklung bilden meistens Menschen das Bottleneck. Und wenn wir jetzt beginnen, diese als Bottleneck zu bezeichnen, fühlen sie sich häufig angegriffen. „Ich bin doch kein Bottleneck. Ich tue doch mein Möglichstes.“ etc. Auch wenn niemand diese Menschen angreifen wollte, sind sie nun zunächst in einer Verteidigungshaltung. Und das ist die denkbar schlechteste Voraussetzung dafür, mit diesen Menschen Veränderungen im Prozess und in den Arbeitsweisen herbeizuführen.

Ich habe dafür bisher keine Patentlösung. Der erste wichtige Schritt ist sicherlich, sich dieses Problems bewusst zu sein.

Zwei Stellen in dem Interview finde ich besonders interessant:

Frage: „Plädieren Sie für eine neue Preisformel bei Rüstungsaufträgen?“
Enders: „Ich plädiere für mehr Ehrlichkeit und Offenheit von Anfang an. Festpreisverträge machen nur dort Sinn, wo die Entwicklungsrisiken begrenzt sind und die Industrie auf vorhandenen Produkten aufbauen kann. Sie sind nicht vertretbar, wenn es um komplette Neuentwicklungen geht wie bei der A400M. [...]„
Der Mann plädiert für agile Vorgehensweisen, oder? Schön, dass solche Erkenntnisse auch langsam in die Bereiche der V-Modell-Hardliner vordringen.

An anderer Stelle allerdings:

Frage: „2003 hat Airbus vertraglich einen Fixpreis von 20 Mrd. Euro vereinbart. Nun soll das A400M-Programm 32 Mrd. Euro kosten. Warum ist ein unterschriebener Vertrag nicht mehr bindend?“
Enders: „Es ist richtig, dass die Industrie vor sieben Jahren Dinge versprochen hat, die, wie wir heute wissen, nicht realistisch waren. [...]„
Das sieht dann wieder nicht so aus, als meinte er es wirklich ernst. Wer ist denn „die Industrie“? Airbus, oder? Warum sagt er das nicht und übernimmt damit Verantwortung?

Kanban hat dieses Problem nicht. Es gibt keine Sprints/Iterationen und auch kein Commitment auf Sprint-Ziele.

Allerdings: Vor kurzem musste ich ein Teammitglied vertreten. Bei dem Kunden gibt es gleich zu Anfang auf dem Kanban-Board eine Spalte, in der die Tickets landen, wenn es einen technischen Lösungsvorschlag der Entwickler gibt. Wenn dieser akzeptiert wird, wird das Ticket in die nächste Spalte verschoben und die Entwicklung kann beginnen.
Ich war nun für die Freigabe der Tickets vorantwortlich und natürlich brauchte ich dafür viel länger als das Teammitglied, das ich vertreten habe. Ich wurde also zum Bottleneck im System. Und da war ich ganz plötzlich doch im Stress. Ich wusste, dass 10 Leute oder mehr ohne Arbeit dastehen, wenn ich nicht möglichst schnell die Tickets freigebe. Und ich würde auch bis spät in die Nacht arbeiten, um meine Teamkollegen mit ausreichend Arbeit zu versorgen.

Ähnlich wie bei den Scrum-Commitments handelt es sich hier um eine fehlerhafte Implementierung von Kanban. Tatsächlich ist die Existenz des Bottlenecks ein organisatorisches Problem. Dass meine Teamkollegen keine Arbeit mehr haben, ist gewollt. Es soll das eigentliche Problem deutlich zeigen und dann sollen wir als Team eine Lösung dafür finden und das Bottleneck beseitigen.

Hier scheint mir kein relevanter Unterschied zwischen Scrum und Kanban zu existieren: Beides kann missverstanden werden und so ein Missverständnis kann in Überlastung einzelner oder aller Teammitglieder enden.

Und dann habe ich ihn etwas ausgefragt, um mich selbst weiterzubilden. Mir ist z.B. notorisch unklar, ob es einen einheitlichen Stand der Kunst zur Definition von Klassen in Java-Script gibt. Und in dieser Diskussion sind wir auch auf private Felder und Methoden in Klassen gekommen. In Java-Script kann man beides machen, es sieht aber nicht so übersichtlich aus.

Daher macht mein Gesprächspartner das gar nicht und markiert Privates einfach mit einem führenden Unterstrich. Und das funktioniert nach seinen Aussagen auch sehr gut. Und zusätzlich muss man sich beim Unittesten nicht damit rumärgern, dass man an irgendwas nicht drankommt.

Und tatsächlich: Wenn ich an 12 Jahre Java-Entwicklung zurückdenke, habe ich kaum von privaten Methoden profitiert. Aber behindert haben sie mich ständig.

Ähnlich verhält es sich mit Konstanten. Klar muss man wissen, was konstant ist. Aber dafür reicht eine Namenskonvention. Hat mich jemals der Compiler darauf hingewiesen, dass ich versuche, eine Konstante zu ändern? Nicht, dass ich mich erinnern könnte.

Das Buch „Clean Code“ von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.

Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.

Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.

Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht „naja…“. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.

Fazit: Aus meiner Sicht ist „Clean Code“ ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.

Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.

Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran („Beginners Mind“) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.

Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein „Naturgesetz“ in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!

• Ich habe mir Cruise-Control Ruby angesehen und damit die Testausführung in einem Rails-Projekt automatisiert. Ich bin nicht überzeugt von dem Tool. Zu umständlich für das bisschen, was es leistet.
• Hudson kann mehr und ist auch nicht komplizierter.
• Ich habe weiter Rails programmiert und insbesondere mein Verständnis der DB-Migration verbessert.
• In diesem Zusammenhang habe ich mit auch jQuery und jQuery-UI angesehen und bin davon ganz angetan.
• Ich habe mehrere Präsentationen mit Prezi erstellt und gehalten. Das war lustig. Meiner Erfahrungen dazu hatte ich bereits in einem anderen Blog-Eintrag beschrieben.
• Im Rahmen einer Artikelvorbereitung habe ich mich näher mit BDD beschäftigt und etwas mit easyB programmiert. Ich finde easyB echt nett, um Tests äh Spezifikationen für Groovy-Code zu schreiben.
• Für ein Projekt habe ich Python-Skripte programmiert. Das war lustig. Nette Sprache.
• Ich habe bei einem Kunden mehr Kanban in der Praxis erlebt und dabei ein paar interessante Einsichten gewonnen. Mehr dazu auf der OOP und in späteren Blog-Einträgen.
• Ich habe gelernt, dass man in einer Linux-Shell Strg+R drücken kann, um in der Shell-History zu suchen. Das ist echt nützlich.
• Ich habe das Buch „Sexy Webdesign“ gelesen. Meine Einschätzung dazu hatte ich bereits in einem anderen Blog-Eintrag beschrieben.
• Durch das Buch bin ich auf die Layouthilfe 960.gs gestoßen. Das sieht auch echt nützlich aus.
• Ich habe etwas mit der A3-Analysetechnik aus dem Toyota-Production-System experimentiert und dabei festgestellt, dass das gar nicht so einfach ist. Aber hilfreich war es dann doch.
• Ich habe in einem Java-Projekt etwas Jersey programmiert, um ein REST-API zu erstellen. Schön einfach. Ist man von Java ja gar nicht gewohnt
• Für die XP-Days Germany musste ich mehrere Code-Katas vorbereiten. Dabei habe ich gemerkt, wie überraschend viel man lernen kann, wenn man mehrfach hintereinander dasselbe Beispiel programmiert. Diese Erfahrung habe ich in einem anderen Blog-Eintrag beschrieben.
• Ich habe das Buch X-Teams gelesen. Meine Einschätzung habe ich hier beschrieben.
• Nachdem ich mir von meinem Bruder im 3. Quartal die richtige Brustschwimm-Technik habe zeigen lassen, habe ich das Brustschwimmen geübt und kann das jetzt einigermaßen (letzter Wert: 1.000 Meter am Stück). Das war am Anfang wirklich ein komisches Gefühl: Ich paddel unbeholfen zwischen den ganzen Halbprofi-Schwimmern rum und mache mich dabei mehr oder weniger lächerlich. Das hat mir ein Gefühl dafür vermittelt, wie schwer es mitunter für Schulungsteilnehmer sein muss. Man macht in einem Bereich mehr oder weniger öffentlich, dass man in diesem Bereich von Tuten und Blasen keine Ahnung hat. Das kann schon eine ganz schöbe Überwindung bedeuten.

]]> http://stefanroock.wordpress.com/2010/01/14/lernen-im-4-quartal-2009/feed/ 0 SR http://stefanroock.wordpress.com/2010/01/07/code-kata-bunkai-prime-factors/ http://stefanroock.wordpress.com/2010/01/07/code-kata-bunkai-prime-factors/#comments Thu, 07 Jan 2010 07:46:42 +0000 stefanroock http://stefanroock.wordpress.com/?p=794 ]]> Bernd Schiffer has published a screencast of the Prime Factors Code Kata that we prepared.
When a programmer new to TDD watches such a code kata he has the same problem that an unexperiences karate student has when he watches a karate kata. He can see what’s happening but he has no idea why.
In karate there is a second kata flavour: Bunkai:

Bunkai literally meaning „analysis“ or „disassembly“, is a term used in Japanese martial arts referring to the application of fighting techniques extracted from the moves of a „form“ (kata) (see Wikipedia).

When watching a kata bunkai it becomes pretty obvious why the moves of the kata are done.
The same should be possible with code katas. Therefore we tried to transfer the bunkai concept to code katas. For now that simply means that the non obvious parts of the code kata are explained. I published the result for the prime factors code kata on YouTube.



I have to confess that I simply cut Bernds video. I think the real code kata bunkai should include the explanation in the kata – like it is in karate. We will work on that.


Tagged: Groovy, Refactoring, Testing ]]> http://stefanroock.wordpress.com/2010/01/07/code-kata-bunkai-prime-factors/feed/ 12 SR http://stefanroock.wordpress.com/2010/01/06/schneller-durch-scrum-und-festpreise/ http://stefanroock.wordpress.com/2010/01/06/schneller-durch-scrum-und-festpreise/#comments Wed, 06 Jan 2010 10:45:48 +0000 stefanroock http://stefanroock.wordpress.com/?p=792 ]]> Boris Gloger hat zwei Blogeinträge zu Festpreisen und Scrum geschrieben (hier und da) und dabei interessante Thesen vertreten. Die Abrechnung
nach Time&Material könne problematisch sein, wenn man nach Scrum arbeitet. Sein Argument ist, dass der Anbieter dann einfach Tagessätze abrechnet und keine große Motivation hat, effektiver zu arbeiten. Aber genau dafür sei Scrum da: effektiver Arbeiten. Ich finde das Argument soweit nachvollziehbar.

Eine Alternative dazu könne ein Festpreis sein – das vertritt auch Jeff Sutherland mit seinem „Money for Nothing, Change for Free“. Wer Scrum richtig macht, sei deutlich effizienter als ein klassischer Anbieter und könne daher mit Festpreisen sehr hohe Margen erreichen. Auch das finde ich erstmal nachvollziehbar.

Aber:

Wir haben uns vor ein paar Jahren um ein Multi-Millionen-Euro-Projekt beworben. Nach einigen Auswahlrunden waren noch wir übrig und ein anderer Anbieter. Der andere Anbieter geht klassisch vor und ist viel größer als wir. Wir haben die Entwicklung zu einem Bruchteil des Preises angeboten, die der andere Anbieter angeboten hat. Ich glaube, unsere Aufwandsschätzung hätte gepasst. Wir wären also tatsächlich deutlich effektiver gewesen als der Anbieter. Scrum sei Dank.

Und jetzt passierte etwas sehr Merkwürdiges. Der Auftraggeber meldete sich bei uns und meinte, unser Angebot sei zu billig und damit
unglaubwürdig. Uns wurde empfohlen, Aufwände für Projektleitung, Testen, Dokumentation etc. extra auszuweisen und damit den Aufwand in „glaubwürdige“ Regionen zu bringen. Also haben wir das gemacht. Letztlich waren wir damit immer noch erkennbar günstiger als der andere Anbieter, aber nicht mehr so dramatisch. Und wir haben unsere Margen erhöht.

Damit war der Auftraggeber zufrieden und hat sich für den anderen Anbieter entschieden. Die Argumentation des Vorstandes ging dann wahrscheinlich so: „OK, A ist etwas günstiger, aber B ist größer. Da sind wir auf der sicheren Seite. Also nehmen wir die Mehrkosten in Kauf.“

Dass wir soviel effektiver waren als die Konkurrenz hat uns also gar nichts genützt.

Ich glaube, es gibt jenseits von Time&Material und Festpreis andere Vertragsmodelle, die besser zu Scrum passen (und natürlich kann man prinzipiell Time&Material und Festpreise mit Scrum machen). Ich werde dazu später noch etwas schreiben.


Tagged: Scrum ]]> http://stefanroock.wordpress.com/2010/01/06/schneller-durch-scrum-und-festpreise/feed/ 5 SR http://stefanroock.wordpress.com/2009/12/26/katacast-screencast-zu-code-kata-primfaktorzerlegung/ http://stefanroock.wordpress.com/2009/12/26/katacast-screencast-zu-code-kata-primfaktorzerlegung/#comments Sat, 26 Dec 2009 19:04:37 +0000 stefanroock http://stefanroock.wordpress.com/?p=790 ]]> Ich habe zusammen mit Bernd Schiffer in mehreren Iterationen an der Code-Kata zur Primfaktorzerlegung gearbeitet. Jetzt hat Bernd den dazugehörigen Screencast veröffentlicht. Die Kata selbst führt Bernd vor.

]]> http://stefanroock.wordpress.com/2009/12/26/katacast-screencast-zu-code-kata-primfaktorzerlegung/feed/ 0 SR http://stefanroock.wordpress.com/2009/12/16/scrum-bei-startups/ http://stefanroock.wordpress.com/2009/12/16/scrum-bei-startups/#comments Wed, 16 Dec 2009 09:39:03 +0000 stefanroock http://stefanroock.wordpress.com/?p=788 ]]> In meinen Scrum-Kursen begegne ich immer häufiger Leuten, die direkt oder indirekt davon betroffen sind, dass Venture-Capital-Geber (VCs) wünschen, dass IT-Startups Scrum einsetzen. Bei einigen Geldgebern gibt es wohl gar keine Kohle mehr für IT-Startups, wenn sie nicht Scrum machen.

Das ist auf jeden Fall ein starkes Signal. Der Job der VCs besteht darin, die erfolgversprechenden Startups von denen zu unterscheiden, die keine Chance auf Erfolg haben. Und wenn die VCs jetzt immer stärker in Richtung Scrum drängen, dann bedeutet das wohl, dass sie Scrum als Erfolgsfaktor für Startups ausgemacht haben.

Das bedeutet natürlich noch lange nicht, dass die VCs wirklich verstanden haben, was Scrum ist. Aber das spielt in ihrer Position auch höchstens eine untergeordnete Rolle. Oder doch? Brauchen wir „Scrum für VCs“-Kurse?

Ob es viel bringt, die Startups zu Scrum zu zwingen kann man natürlich in Frage stellen. Wenn die Startups das nicht von sich aus wollen, werden sie Scrum wahrscheinlich auch nicht richtig hinkriegen. Sie werden Scrum bei Bedarf mit mehr oder weniger großem schauspielerischem Talent aufführen: Scrum-Schauspieler. Aber dadurch erreichen sie die erhofften Effekte nicht.

Es gibt allerdings auch Startups, die Scrum bisher einfach nicht oder nicht richtig kennen. Und da kann ein Schubs in Richtung Scrum durchaus hilfreich sein.


Tagged: Scrum ]]> http://stefanroock.wordpress.com/2009/12/16/scrum-bei-startups/feed/ 2 SR http://stefanroock.wordpress.com/2009/12/14/artikel-zu-low-tech-tools-in-jaxenter/ http://stefanroock.wordpress.com/2009/12/14/artikel-zu-low-tech-tools-in-jaxenter/#comments Mon, 14 Dec 2009 08:24:39 +0000 stefanroock http://stefanroock.wordpress.com/?p=785 ]]> Auf JAXenter ist ein Artikel von mir zu Low-Tech-Tools erschienen: http://it-republik.de/jaxenter/artikel/Low-Tech-Tools-2747.html

Tagged: eXtremeProgramming, Scrum ]]> http://stefanroock.wordpress.com/2009/12/14/artikel-zu-low-tech-tools-in-jaxenter/feed/ 0 SR http://stefanroock.wordpress.com/2009/12/04/buch-x-teams/ http://stefanroock.wordpress.com/2009/12/04/buch-x-teams/#comments Fri, 04 Dec 2009 19:01:51 +0000 stefanroock http://stefanroock.wordpress.com/?p=781 ]]> Ich habe gerade das Buch „x-teams“ von Deborah Ancona und Henrik Bresman gelesen.



Es geht im Buch um eine besondere Art von Teams, die sogenannten x-teams, die besonders gut in hochkomplexen Umgebungen funktionieren:

1. x-teams sind innovativ.
2. x-teams haben in ihrem Lebenszyklus unterschiedliche Schwerpunktsetzungen: Explore, Exploit, Export. Zunächst wird das Umfeld exploriert, um die Situation zu verstehen. Anschließend wird eine Idee oder ein Produkt ausgearbeitet und umgesetzt. Und zuletzt werden die Ergebnisse in den Markt und das eigene Unternehmen exportiert.
3. x-teams beschäftigen sich nicht primär mit sich selbst, sondern managen stets auch die Beziehungen zu ihrem Umfeld, den Stakeholdern etc.
4. x-teams haben wechselnde Mitglieder, abhängig von den Lebenszyklus-Phasen.

Diese Eigenschaften basieren auf Untersuchungen erfolgreicher Teams bei Microsoft, BP, P&G, etc. Bei diesen Teams handelte es sich nicht nur um IT-Teams.

Es gibt hier offensichtliche Parallelen zu Scrum oder anderen agilen Ansätzen:

1. Scrum dient der Entwicklung innovativer Produkte.
2. Meistens werden bei agilen Ansätzen zwei „Phasen“ unterschieden: Envisioning (=Explore) und Entwicklung (=Exploit). Der Export-Teil fehlt hingegen als explizites Element. Ich habe nur sehr fragmentarisches Wissen über die Ursachen, warum eXtreme Programming bei Crysler letztlich beendet wurde. Möglicherweise hat der Export gefehlt?
3. Scrum sieht den Product Owner als primäre Schnittstelle zur Außenwelt vor, in XP war es der On-Site-Customer. x-teams deuten darauf hin, dass wir diese Schnittstelle nicht zu strikt begreifen sollten. Alle Teammitglieder sollen und dürfen Kontakt zu Anwendern und anderen Stakeholdern haben. Es muss halt nur klar sein, wer letztlich den Geschäftswert einschätzt und die Priorisierung vornimmt.
4. Wir weisen immer gerne darauf hin, dass Teambildung erhebliche Kosten verursachen kann und man daher nicht jeden Sprint das halbe Team austauschen sollte. Wir sollten es damit aber auch nicht übertreiben und gar keinen personellen Wechsel mehr erlauben.

Aus meiner Sicht liefert das Buch ein paar neue Erkenntnisse und Denkmodelle, aber nichts gravierend Neues. Dadurch hat es sich für mich dann auch nicht so interessant gelesen.


Tagged: eXtremeProgramming, Scrum ]]> http://stefanroock.wordpress.com/2009/12/04/buch-x-teams/feed/ 1 SR Xteams http://stefanroock.wordpress.com/2009/12/03/xp-days-pecha-kucha-stop-the-line-in-der-softwareentwicklung/ http://stefanroock.wordpress.com/2009/12/03/xp-days-pecha-kucha-stop-the-line-in-der-softwareentwicklung/#comments Thu, 03 Dec 2009 08:07:53 +0000 stefanroock http://stefanroock.wordpress.com/?p=779 ]]> Die Folien zu meinem Pecha-Kucha-Vortrag „Stop the Line in der Softwareentwicklung“, den ich auf den XP-Days Germany in Karlsruhe gehalten habe, sind jetzt online auf Slideshare.

]]> http://stefanroock.wordpress.com/2009/12/03/xp-days-pecha-kucha-stop-the-line-in-der-softwareentwicklung/feed/ 0 SR http://stefanroock.wordpress.com/2009/12/02/vortrag-zum-inkrementellen-entwurf-auf-xp-days-und-scrum-gathering/ http://stefanroock.wordpress.com/2009/12/02/vortrag-zum-inkrementellen-entwurf-auf-xp-days-und-scrum-gathering/#comments Wed, 02 Dec 2009 11:54:20 +0000 stefanroock http://stefanroock.wordpress.com/?p=777 ]]> Die Präsentation zum inkrementellen Entwurf, die ich auf den XP-Days Germany in Karlsruhe gehalte habe, findet sich hier als Prezi-Flash-Präsentation.

Einen fast identischen Vortrag habe ich auch auf dem Scrum-Gathering in München gehalten. Hier ist die Prezi-Präsentation dazu.

Die Präsentationen habe ich mit Prezi erstellt. Die Vorteile von Prezi aus meiner Sicht, habe ich bereits in einem anderen Blogeintrag beschrieben.


Tagged: Architecture, eXtremeProgramming, Scrum, Testing ]]> http://stefanroock.wordpress.com/2009/12/02/vortrag-zum-inkrementellen-entwurf-auf-xp-days-und-scrum-gathering/feed/ 0 SR http://stefanroock.wordpress.com/2009/12/01/mikroschritte-in-code-kata/ http://stefanroock.wordpress.com/2009/12/01/mikroschritte-in-code-kata/#comments Tue, 01 Dec 2009 18:22:35 +0000 stefanroock http://stefanroock.wordpress.com/?p=772 ]]> Bernd Schiffer und ich haben eine Code-Kata mit TDD programmiert. Nach ein paar Refactorings hatten wir Groovy-Code, der ungefähr so aussah (ich habe das konkrete Beispiel gegen ein einfacheres ausgetauscht):


def toString(number, range = (1..number).reverse()) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}

assert '1' == toString(1)
assert '12' == toString(2)
assert '123' == toString(3)
assert '1234567891011' == toString(11)

"toString" liefert einen String mit den Zahlen 1 bis "number". In "range" finden sich die jeweils noch zu bearbeitenden Zahlen. Das kann man in Groovy natürlich viel einfacher hinschreiben:


def toString(number) {
	(1..number).join()
}


Aber für den Punkt dieses Blog-Beitrags bleiben wir bei der ursprünglichen Implementation. Wir bleiben also bei der "range" und fokussieren auf ein anderes Problem. Wir verdrehen bei der Erzeugung der Range die Reihenfolge mit "reverse" und greifen hinterher mit "last" darauf zu. Es wäre einfacher, wenn wir die Reihenfolge unverändert ließen und mit "first" auf das jeweils erste Element zugreifen würden. Wir brauchen also ein Refactoring, das diese beiden Stellen im Code ändert.

Dummerweise steht der Bernd davor. Er ist dagegen, dass wir einfach diese zwei Stellen im Code ändern. Er meint, das sei nicht der "grüne Weg", weil nach der ersten Änderung (entfernen von "reverse") die Tests (asserts) nicht mehr laufen. "Aber alle zwei Änderungen finden in derselben Methode statt. Das kann man doch problemlos in einem Schritt ändern und dann ist alles grün. So ist es doch viel schneller." Aber Bernd bleibt dabei. Das ist ihm zu großschrittig (ein Schulungsteilnehmer sagte einmal sinngemäß "Ich dachte immer kleiner als Elektron geht nicht, aber jetzt kenne ich den Bernd-Schritt als kleinstes Element."):

1. Wir arbeiten an einer Code-Kata. Dabei geht es darum, dass wir unsere Programmierfähigkeiten verbessern. Es geht nicht darum, die Kata in möglichst kurzer Zeit durchzuführen. Es geht darum, sie möglichst gut durchzuführen - wie bei einer Karate-Kata.
2. Wir stehen in der Praxis immer wieder vor großen Refactorings, die wir nicht in kleine Schritte zerlegt bekommen und die uns den letzten Nerv kosten. Je kleinschrittiger wir vorgehen können, umso besser können wir große Refactorings zerlegen. Wenn wir es schaffen, dass die Tests nach jeder Änderung eines Ausdrucks grün sind, dann können wir für jedes große Refactoring einen komplett grünen und damit sicheren Weg beschreiten.
3. Wenn wir mehrere Änderungen auf einmal durchführen, laufen wir immer Gefahr, versehentlich Funktionalität zu erweitern - die dann nicht durch Tests abgedeckt ist. Wenn wir jeweils nur einen Ausdruck ändern, können wir normalerweise sehr sicher abschätzen, ob wir die Funktionalität erweitert haben.

"OK, Bernd hat Recht. Versuchen wir es Kleinstschrittig. Äh, geht das denn überhaupt?"

Ja, es geht. Gleicht kommt die Lösung. Wer sich selbst an der Aufgabe versuchen möchte, sollte hier nicht weiterlesen und es erstmal selbst versuchen. Die Regel: Einen Ausdruck ändern, Tests ausführen, es muss alles grün sein. Danach der nächste Ausdruck.

Eine Lösung
Es gibt verschiedene Möglichkeiten, das Problem zu lösen. Hier eine mögliche Lösung:

Zuerst vereinfache ich den "range"-Defaultwert, indem ich das umdrehen der Elemente bereits beim Hinschreiben erledige:


def toString(number, range = number..1) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Jetzt kommt der interessante Teil. Die Reihenfolge der Elemente in "range" hängt direkt mit dem Zugriff über "last" zusammen. Wenn ich "last" durch "first" ersetzen möchte, muss ich dafür sorgen, dass in "range" am Anfang und Ende dasselbe Element steht. Das erreiche ich, indem ich "range" quasi verdoppele:


def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Dass "range" jetzt jede Zahl doppelt enthält, schadet nicht, weil "range - item" alle "item"s entfernt. Mit diesem verdoppelten Range liefert "last" dasselbe Ergebnis wie "first", so dass ich die Ersetzung problemlos vornehmen kann.


def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Jetzt kann ich den Default-Wert für "range" wieder vereinfachen:


def toString(number, range = 1..number) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Und fertig bin ich mit meinem Refactoring. Wir haben nach jeder Änderung eines Ausdrucks die Tests durchlaufen lassen und sie waren immer grün. In der Praxis würde man in diesem Beispiel vielleicht nicht so kleinschrittig vorgehen. Aber hier geht es um den Trainingseffekt!

Eine interessante Frage ist sicherlich, ob es immer solche kleinschrittigen Auflösungen gibt oder ob es Fälle gibt, wo das nicht funktioniert. Wenn Ihr Refactoring-Beispiele habt, von denen Ihr glaubt, dass es keine Kleinstschrittige Zerlegung gibt, schickt mir die! Entweder an stefan AT stefanroock DOT de (AT durch @ und DOT durch . ersetzen) oder als Kommentar an diesen Blog-Beitrag.


Tagged: Refactoring, Testing ]]> http://stefanroock.wordpress.com/2009/12/01/mikroschritte-in-code-kata/feed/ 10 SR http://stefanroock.wordpress.com/2009/11/29/programmierkatas/ http://stefanroock.wordpress.com/2009/11/29/programmierkatas/#comments Sun, 29 Nov 2009 21:36:06 +0000 stefanroock http://stefanroock.wordpress.com/?p=770 ]]> Auf den XP-Days Germany 2009 fand ein Format namens „TDD mit den Profis“ statt. Die Idee ist, dass Paare bestehend aus einem TDD-Profi und einem nicht so erfahrenen TDDler gegeneinander antreten. Die Paare führen in kurzer Zeit TDD und Pair-Programming vor. Bei den XP-Days hatten die Paare in der Vorrunde 5 Minuten Zeit und im Finale 8 Minuten.
Ich bin mit meiner Pair-Partnerin ins Finale gekommen, musste mich dort aber mit dem zweiten Platz zufrieden geben.

In der Vorrunde konnten sich die Paare sehr frei aussuchen, was sie vorführen. Im Finale gab es vorgegebene Code-Katas (siehe Konzept der Code-Katas siehe Wikipedia). Für die Vorrunde hatten wir mehrere Tage für die Vorbereitung Zeit, für das Finale 2 Stunden.

Code-Katas hatte ich vorher bereits programmiert. Allerdings nicht so, wie es für die XP-Days-Sessions notwendig war. In der Kürze der Zeit lässt sich nur dann sinnvoll etwas zeigen, wenn man die Übung auswendig und flüssig vorführen kann. Und dafür muss man sie einüben. Und das bedeutet, die Kata in der Vorbereitung mehrfach zu programmieren und immer wieder zu variieren, um den besten Ablauf zu finden.

Und dieses mehrfache Programmieren derselben Aufgabe war entgegen meinen Erwartungen nicht langweilig, sondern sehr interessant und lehrreich. So haben wir auf der Konferenz meine Finalaufgabe (Primfaktorzerlegung) nochmal während des Community-Day programmiert (im Rahmen eines Coding Dojos) und auf der Rückfahrt von Karlsruhe mit der Bahn nach Hamburg haben Bernd Schiffer und ich die Code-Kata nochmal programmiert.

Robert Martin hat die Code-Kata sogar zu Musik vorgeführt und damit Programmierung in die Nähe einer Kunstform gebracht.


Tagged: eXtremeProgramming, Testing ]]> http://stefanroock.wordpress.com/2009/11/29/programmierkatas/feed/ 2 SR http://stefanroock.wordpress.com/2009/11/29/iphone-und-ubuntu/ http://stefanroock.wordpress.com/2009/11/29/iphone-und-ubuntu/#comments Sun, 29 Nov 2009 20:20:24 +0000 stefanroock http://stefanroock.wordpress.com/?p=767 ]]> Seit kurzem besitze ich ein iPhone und habe damit als Ubuntu-Benutzer gleich das erste Problem: Man braucht iTunes für das Aktivieren des iPhone und zur Synchronisation von Musik etc.

Zuerst habe ich versucht, iTunes unter Wine zu installieren. Die aktuelle iTunes-Version bricht aber schon bei der Installation ab. Hier steht, dass iTunes 7.X funktioniert und wo man die alte iTunes-Version herkriegt. Tatsächlich lässt sich iTunes 7.X unter Wine installieren und ausführen. Allerdings lief es bei mir so instabil, dass ich nie zum Synchronisieren gekommen bin.

Also habe ich iTunes unter Windows über Virtual-Box verwendet. Das Aktivieren funktionierte problemlos. Die erste Synchronisation schlug allerdings fehl und hinterließ das iPhone im unbenutzbaren Recovery-Zustand. Das Wiederherstellen über iTunes unter Virtual-Box hat nicht funktioniert (Fehler 1601, 1604 und 1611).

Das iPhone ließ sich aber am Mac eines Kollegen wiederherstellen und danach auch über Virtual-Box synchronisieren.

Aus meinen eigenen Beobachtungen und Hinweisen im Internet habe ich mir dazu folgenden Theorie zusammengereimt: Bei der ersten Synchronisation hat iTunes festgestellt, dass das iPhone ein Firmware-Update vertragen kann. iTunes hat das Firmware-Update auf des iPhone übertragen und dann das iPhone neu gestartet. Ich vermute, dass nach dem Neustart die Verbindung iPhone zu iTunes nicht wiederhergestellt werden konnte – und das hat wahrscheinlich irgendwas mit der Durchleitung des USB-Ports durch Ubuntu zur Virtual-Box zu tun.

Beim Wiederherstellen aus dem Recovery-Mode wird das iPhone auch neu gestartet und dasselbe Problem tritt auf.

Daraus folgt:

1. iTunes unter Virtual-Box nicht automatisch synchronisieren lassen, so dass man jederzeit weiß, was passiert.
2. Keine Firmware-Updates durch iTunes synchronisieren lassen.
3. Wenn man feststellt, dass ein Firmware-Update notwendig ist, dies über einen Windows- oder Mac-Rechner erledigen. Dasselbe gilt für den Fall, dass das iPhone aus dem Recovery-Mode wiederhergestellt werden muss.
4. Feature-Request an Apple schreiben, auch Linux zu unterstützen. Wenn es stimmt, dass Apple im Grunde Unix als Betriebssystem ist, kann das doch kein so großes Drama sein.

P.S.: Liebe Leser dieses Blogs: Ihr braucht mir nicht empfehlen einen Mac zu kaufen oder ein Android-Phone zu benutzen. Das haben inzwischen ausreichend viele Leute getan


]]> http://stefanroock.wordpress.com/2009/11/29/iphone-und-ubuntu/feed/ 0 SR http://stefanroock.wordpress.com/2009/11/17/buch-sexy-webdesign/ http://stefanroock.wordpress.com/2009/11/17/buch-sexy-webdesign/#comments Tue, 17 Nov 2009 19:26:15 +0000 stefanroock http://stefanroock.wordpress.com/?p=763 ]]> Ich habe das Buch Sexy Webdesign von Elliot Jay Stocks gelesen.



Ich bin kein Web-Designer und habe auch keine Ambitionen, einer zu werden. Ich bin aber natürlich interessiert daran, besseres Webdesign zu machen. Damit stehe ich vielleicht nicht direkt im Zentrum der anvisierten Zielgruppe.

Persönlich konnte ich nicht viel mit dem Buch anfangen. Ich hatte das Gefühl, dass auf den ersten 80 Seiten nur Trivialitäten stehen. Immer, wenn es interessant wird, kommt nichts mehr – allenfalls ein Verweis auf andere Bücher. Dann kommen 20 Seiten, die einige interessante Informationen (vor allem in Form von Internetadressen) bieten. Danach kommen wieder Trivialitäten.

Immerhin ist das Buch optisch ansprechend gestaltet.

Hier meine persönlichen Erkenntnisse aus dem Buch:

• Der goldene Schnitt liefert eine gute Richtlinie für Seitenaufteilungen, die angenehm aussehen. Es gibt mit goldenratiocalculator.com einen Internet-Service, der hilft, Abmessungen nach dem goldenen Schnitt zu berechnen.
• Ausrichtung an Rastern ist sinnvoll – das ist trivial. Hilfestellung in Form von Vorlagen für CSS und Photoshop findet man bei 960.gs. Das sind wirklich interessant und nützlich aus. Das werde ich auf jeden Fall mal ausprobieren.
• Farben, die zusammenpassen, findet man mit Hilfe des Farbkreises. Auch hier helfen Internet-Services wie
  colorschemedesigner.com oder colourlovers.com.

]]> http://stefanroock.wordpress.com/2009/11/17/buch-sexy-webdesign/feed/ 1 SR http://stefanroock.wordpress.com/2009/11/15/gute-und-schlechte-vortrage-alles-eine-frage-der-geschichten/ http://stefanroock.wordpress.com/2009/11/15/gute-und-schlechte-vortrage-alles-eine-frage-der-geschichten/#comments Sun, 15 Nov 2009 12:55:46 +0000 stefanroock http://stefanroock.wordpress.com/?p=760 ]]> Ich glaube, dass ich inzwischen ein ganz gutes Gefühl dafür habe, wie gut meine Vorträge beim Publikum ankommen. Bei meinen schlechten Vorträgen bekomme ich während des Vortrags aus dem Publikum nichts zurück: kein Lachen, kein Murren, keine ungläubigen Gesichter.

Meine Selbsteinschätzung deckt sich meist mit dem Feedback, das die Konferenzorganisatoren einsammeln.

Lange Zeit war mir unklar, warum einige meiner Vorträge gut beim Publikum ankommen und andere nicht. Ich hatte bereits beoachtet, dass schlecht vorbereitete Vorträge besser ankommen als gut vorbereitete. Das fand ich schon immer sehr merkwürdig. Reicht es tatsächlich aus, schlecht vorbereitet zum Vortrag zu kommen und alles wird gut? Und warum zum Geier ist das so?

Inzwischen habe ich ein Erklärungsmodell gefunden, dass mir plausibel erscheint: Über Twitter hatte jemand seine Beobachtung auf einer Konferenz geschildert, dass die guten Vorträge immer mit einer Geschichte beginnen und daraus eine Einsicht ableiten.

Das passt sehr schön damit zusammen, dass der Fantasy-Autor Terry Pratchett immer wieder betont, wie wichtig Geschichten für uns Menschen sind. Er spricht vom Homo Narrativus. Geschichten transportieren Emotionen und die sind wichtig, damit wir interessiert sind.

Bleibt noch die Frage, wie das mit der schlechten Vortragsvorbereitung zusammenpasst. Ich glaube, das funktioniert so: Es ist ja nicht so, dass ich vollkommen ohne Vorbereitung zum Vortrag gehe. Ich habe nur entweder „zu spät“ mit der Vortragsvorbereitung begonnen oder kurz vor dem Vortrag nochmal das Gesamtkonzept umgeworfen. Ich habe also die Tage bzw. Nächte vor dem Vortrag an dem Vortrag gearbeitet. Gefühlt war die Zeit aber zu kurz und das zeigt sich an niedrig aufgelösten Bildern, Rechtschreibfehlern auf den Folien und allgemeinen Layout-Unschönheiten. Darüber scheinen die Teilnehmer aber gerne hinwegzusehen.

Dafür erscheine ich zum Vortrag emotional: Ich bin schlecht vorbereitet und habe schlechte Folien dabei und das weiß ich auch. Das sind keine positiven Emotionen, aber immerhin sind es Emotionen. Sie führen dazu, dass ich den Vortrag meistens emotionaler halte und nicht einfach kühl Fakten runterrattere.

Außerdem bin ich mit diesem Verfahren „voll im Thema“, wenn ich mit dem Vortrag beginne. Gut vorbereitete Vorträge habe ich schon Wochen vor dem Vortragstermin fertig. Wenn ich den Vortrag dann halte, kann ich mich bei einigen Folien nicht mehr erinnern, was genau ich mir dabei gedacht habe und bin auch zu den Folien distanziert.

Ich nehme also zwei Dinge für mich ganz persönlich mit (keine Ahnung, ob sie auch für andere funktionieren):

1. Beginne mit einer Geschichte und leite daraus Einsichten ab.
2. Bereite den Vortrag so spät vor, dass er gerade noch fertig wird. Gehe lieber das Risiko ein, mit schlechten Unterlagen zum Vortrag zu erscheinen als mit einem Vortrag, der schon Wochen vor dem Termin fertig war.

]]> http://stefanroock.wordpress.com/2009/11/15/gute-und-schlechte-vortrage-alles-eine-frage-der-geschichten/feed/ 17 SR http://stefanroock.wordpress.com/2009/11/04/ubuntu-9-10-und-flash-mal-wieder-kaputt/ http://stefanroock.wordpress.com/2009/11/04/ubuntu-9-10-und-flash-mal-wieder-kaputt/#comments Wed, 04 Nov 2009 08:33:10 +0000 stefanroock http://stefanroock.wordpress.com/?p=758 ]]> Ich habe gerade von Ubuntu 9.04 auf Ubuntu 9.10 aufgedated. Das war soweit problemlos. Einige Dinge sehen etwas schicker aus. Das Starten aus dem Sleepmode ist nochmal schneller geworden.

Einziges Problem bisher: Flash läuft (mal wieder) nicht mehr. Aber mit dieser Anleitung konnte ich es dann doch schnell wieder reparieren.


]]> http://stefanroock.wordpress.com/2009/11/04/ubuntu-9-10-und-flash-mal-wieder-kaputt/feed/ 0 SR http://stefanroock.wordpress.com/2009/10/22/prasentationen-mit-prezi/ http://stefanroock.wordpress.com/2009/10/22/prasentationen-mit-prezi/#comments Thu, 22 Oct 2009 21:09:57 +0000 stefanroock http://stefanroock.wordpress.com/?p=755 ]]> Auf dem Scrum-Gathering in München habe ich meine erste echte Prezi-Präsentation gehalten. Prezi hat einen neuartigen Ansatz für Präsentationen. Es gibt im Grunde nur eine riesige „Folie“, auf der man alle Inhalte platziert. Dann definiert man einen Pfad durch die Inhalte, der angibt, welche Ausschnitte wann angezeigt werden. Die Navigation entlang dieses Pfades visualiert Prezi dann durch coole Effekte (bewegen, drehen, zommen).
Ich habe mir Prezi ursprünglich angesehen, weil die Übergänge so cool aussahen. Das tun sie heute noch. Aber wahrscheinlich verbraucht sich dieser Effekt mit der Zeit – genauso wie die coolen Folienübergänge in Keynote.

Aber auf den zweiten Blick bietet Prezi eine ganz neue Art der Organisation der Präsentation. In Powerpoint und Keynote ordne ich die Folien streng linear an. Bei Prezi habe ich die X- und Y-Achse und außerdem das Herein- und Herauszoomen. Daher eignet sich Prezi auch, um eine Präsentation vorzubereiten und zu organisieren – Powerpoint und Konsorten eignen sich dafür nicht gut, weil sie durch ihre Linearität das Denken zu sehr beschränken.

Und dann spielt Prezi noch einen Vorteil aus, den ich sehr zu schätzen weiß: Prezi basiert auf Flash und läuft auf jedem Browser und offline überall dort, wo Adobe AIR läuft – also auch unter Ubuntu. Prezi ist also wirklich cross-plattform-fähig.

Wenn man sich das erste Mal mit Prezi beschäftigt, ist die Bedienung gewöhnungsbedürftig. Aber wenn man sich mal dran gewöhnt hat, ist sie sensationell gut.

Für einen ersten Eindruck, was mit Prezi möglich ist, siehe hier.


]]> http://stefanroock.wordpress.com/2009/10/22/prasentationen-mit-prezi/feed/ 2 SR http://stefanroock.wordpress.com/2009/10/14/lernen-im-dritten-quartal-2009/ http://stefanroock.wordpress.com/2009/10/14/lernen-im-dritten-quartal-2009/#comments Wed, 14 Oct 2009 17:45:37 +0000 stefanroock http://stefanroock.wordpress.com/?p=751 ]]> Damit habe ich mich im dritten Quartal 2009 beschäftigt:
• Ich habe das Buch Subject to Change gelesen. Meine Eindrücke habe ich bereits im Blog beschrieben: Es geht darum, wie heute Produkte und Services entwickelt werden müssen. Das ganze passt wenig überraschend mit agilen Ansätzen wie Scrum ganz wunderbar zusammen.
• Dann habe ich mich ziemlich intensiv mit Prolog beschäftigt und einige Beiträge in diesem Blog darüber veröffentlicht. Das war allemal horizonterweiternd – Prolog ist eben doch sehr anders als andere Programmiersprachen. Ich finde es nach wie vor Schade, dass Prolog heute ziemlich tot zu sein scheint und die Sprache nicht ernsthaft weiterentwickelt wird. Relektionen über Prolog.
• In Prolog habe ich ann auch gleich ein kleines BDD-Framework gebaut und damit mein BDD-Verständnis verbessert.
• Joseph Pelrine ist dafür verantwortlich, dass ich noch etwas über Teamdynamik gelernt habe: Hochproduktive Teams kochen.
• Von einem Kunden habe ich mich belehren lassen, was die mögliche Produktivität verteilter Teams anbelangt.
• Ein ganz kleines bisschen Perl habe ich gelernt. Und zumindest für kleine Skripte kann ich nicht erkennen, was an Perl schlecht sein soll.
• In einem Projekt habe ich Selenium RC eingesetzt und den designierten Nachfolger Google Web-Driver.
• Ich habe meine Rails-Kenntnisse deutlich vertieft. Dazu habe ich das Buch Rapid Web Development mit Ruby on Rails gelesen. Das ist nicht mehr ganz aktuell, aber ich hatte es ohnehin noch im Bücherregal stehen und für einen Überblick war es OK. Anschließend habe ich begonnen, eine echte (kleine) Anwendung in Rails zu programmieren und bin davon ganz angetan. Nur mit der Installtion unter Ubuntu hatte ich anfänglich einige Probleme.
• Im Rails-Zusammenhang habe ich mich auch mit RSpec, Cucumber und Webrat beschäftigt. Auch das sieht für mich alles sehr schön und elegant aus. Das Oberflächentesten mit Webrat ist z.B. sehr schön einfach und schnell.
• Bei einem Kunden habe ich mich etwas mit TestNG beschäftigt. Naja. Für TDD kann ich gegenüber JUnit keine Vorteile erkennen.
• Ich habe mit dem Buch SOA in Praxis ein weiteres Buch aus dem Regal geholt, dass dort schon eine Weile stand. Mein Review dazu habe ich im Blog beschrieben. Das Buch war durchaus lohnenswert, auch wenn ich kein SOA-Fan bin.
• Bei einem Kunden durfte ich erleben, wie Kanban in der Praxis eingesetzt wurde – zumindest anfänglich auch mit interessanten Schwierigkeiten.
• Neben CSM-Kursen biete ich inzwischen auch CSPO-Kurse an. Bei der Vorbereitung des CSPO-Kurses habe ich viele Dinge über Product-Owner-Arbeit reflektiert und neu gelernt.
• Und zum Beweis, dass ich noch nicht vollkommen Plem-Plem bin, habe ich auch etwas im Bereich außerhalb der IT gemacht. Ich habe beim Windsurfen Racejibe und Sinkerwende gelernt. OK, Racejibe geht bisher nur rechtsrum, aber das wird noch. Ich hoffe, auf einen milden und windreichen Jahresausklang.
• Und dann habe ich mir von meinem kleinen Bruder zeigen lassen, wie Brustschwimmen und Kraulen richtig funktioniert. Und siehe da: Das einzige, was ich bisher richtig gemacht habe, dass ich eine Badehose anhatte. Immerhin erklärt es, warum ich so ein schlechter Schwimmer bin. Jetzt muss ich die richtige Technik „nur“ noch üben.

Damit habe ich von dem, was ich mir für das dritte Quartal vorgenommen habe, fast alles geschafft. Nur Scala habe ich mir nicht angesehen. Ich fand es dann doch spannender einfach Rails zu programmieren und aus demselben Grund werde ich wahrscheinlich auch im vierten Quartal nicht dazu kommen, mir Scala anzusehen.


Tagged: Prolog, Ruby, Scrum, Testing ]]> http://stefanroock.wordpress.com/2009/10/14/lernen-im-dritten-quartal-2009/feed/ 0 SR http://stefanroock.wordpress.com/2009/10/14/buchtipp-soa-in-der-praxis-von-nicolai-josuttis/ http://stefanroock.wordpress.com/2009/10/14/buchtipp-soa-in-der-praxis-von-nicolai-josuttis/#comments Wed, 14 Oct 2009 17:10:25 +0000 stefanroock http://stefanroock.wordpress.com/?p=745 ]]> Ich weiß, dass ich etwas spät dran bin, wenn ich jetzt noch SOA-Bücher lese. Das dpunkt-Buch „SOA in der Praxis“ von Nicolai Josuttis aus dem Jahr 2008 hatte ich bereits kurz nach dem Erscheinen in meinem Bücherregal. Aber ich bin jetzt erst zum Lesen gekommen – wer bösartig ist, könnte das Buch heute auch als eine Art Nachruf auf SOA verstehen. Der SOA-Hype ist sicher inzwischen vorbei. Jetzt kann man sich trefflich darüber streiten, ob jetzt einfach der unspektakuläre SOA-Einsatz stattfindet oder ob schon Verwesungsgeruch in der Luft liegt.



Aber zum Inhalt: Der Autor beschreibt SOA vor dem Hintergrund seiner umfangreichen Praxiserfahrungen. (Für alle, die noch lahmer sind als ich: SOA steht für „Service Oriented Architecture“.) Und gerade diese Praxiserfahrungen mach einen erheblichen Unterschied zu vielen anderen SOA-Veröffentlichungen. Bei Josutti werden die ganzen unangenehmen Probleme beschrieben, die beim Einsatz von SOA zwangsläufig auftreten: Transaktionen, Versionierung, Migration, Verfügbarkeit etc. Diese und andere Probleme treten beim SOA-Einsatz auf. Sie können gelöst werden, aber nicht einfach. Josuttis schließt mit:

„Aus diesem Grund sollte SOA nie ein Selbstzweck sein. Wenn man Verteilung vermeiden kann, sollte man das tun.“

Ich empfehle das Buch jedem, der SOA einführen muss oder will. Diejenigen, die SOA einführen müssen, finden hier die zu erwartenden Probleme inkl. möglicher Lösungsstrategien. Diejenigen, die SOA einführen wollen, bekommen vor Augen geführt, wie komplex die ganze Angelegenheit ist und können sich dann nochmal ernsthaft überlegen, ob sie SOA wirklich wollen.

Ich bin nach dem Lesen des Buches jedenfalls froh, dass ich bisher nichts mit SOA zu tun hatte und hoffe, dass das auch so bleibt.

Trotzdem war die Lektüre keine Zeitverschwendung. Viele der Konzepte lassen sich in großen Systemen auch dann anwenden, wenn es nicht um SOA im eigentlichen Sinne geht. So ist das Thema Idempotenz beispielsweise relevant, wenn man seine Internetanwendung mit einer REST-Schnittstelle versieht. Die Diskussionen zu Entkopplung sind ebenfalls auch ohne SOA relevant. Etc.


Tagged: Architecture ]]> http://stefanroock.wordpress.com/2009/10/14/buchtipp-soa-in-der-praxis-von-nicolai-josuttis/feed/ 0 SR http://stefanroock.wordpress.com/2009/10/14/ubuntu-audiogerate-und-skype/ http://stefanroock.wordpress.com/2009/10/14/ubuntu-audiogerate-und-skype/#comments Wed, 14 Oct 2009 13:21:45 +0000 stefanroock http://stefanroock.wordpress.com/?p=742 ]]> Die Audioeinstellungen für Skype unter Ubuntu zum Laufen zu kriegen, kann ziemlich umständlich sein. Hier meine bisherigen Erkenntnisse.

Zuerst sollte man sicherstellen, dass die Soundwiedergabe unter Ubuntu überhaupt funktioniert. Dazu einfach ein YouTube-Video abspielen oder eine MP3-Datei mit Rythmplayer o.Ä. Meistens funktioniert die Soundwiedergabe aber per Default.

Jetzt sollte man prüfen, dass das Mikro prinzipiell unter Ubuntu funktioniert. Dazu den Audio-Rekorder (Menü Anwendungen->Unterhaltungsmedien) verwenden. Hier taucht dann häufig schon das erste Problem auf: Die Aufnahme funktioniert nicht. Jetzt:

1. Prüfen, dass man überhaupt die Rechte für den Zugriff auf das Mikro besitzt (Menü System->Systemverwaltung->Benutzer und Gruppen, Kartenreiter Benutzerrechte). Wenn die Rechte fehlen, „Entsperren“ anklicken und die Rechte ergänzen. Ich bin mir nicht sicher, ob man danach neu Booten muss oder sich zumindest neu anmelden.
2. Prüfen, ob das Mikro aktiviert ist. Dazu rechts oben auf dem Lautsprechersymbol rechte Maustaste drücken und sicherstellen, dass „Stummschalten“ nicht angehakt ist. Danach dort wieder rechte Maustaste und Menü „Lautstärkeregler öffnen“ anwählen. Dann „Einstellungen“ wählen und alle Aufnahmegeräte anwählen. Anschließend die Regler für die Aufnahmegeräte hochdrehen und ggf. Mikros aktivieren.
3. Pulse-Audio scheint bei mir immer das Mikro zu blockieren, manchmal auch die Lautsprecher. Wenn ich mit ps aux | grep pulse nach den entsprechenden Prozessen suche und diese kille, funktioniert wieder alles. Bisher ist mir noch unklar, warum diese Pulse-Audio-Prozesse überhaupt gestartet werden.

Wenn damit sichergestellt ist, dass Aufnahme und Wiedergabe unter Ubuntu prinzipiell funktionieren, kann man sich Skype zuwenden. in Skype „Optionen“ öffnen und dort „Audiogeräte“ auswählen. Standardmäßig stehen die Audiogeräte auf „Default“. Das hat bei mir noch nie funktioniert. Gute Erfahrungen habe ich mit „HDA Intel (hw:Intel,0)“ gemacht. Mit „Testklang abspielen“ kann man dann prüfen, ob die Lautsprecherwiedergabe funktioniert. Mit „Testanruf tätigen“ kann man auch die Mikrofunktion testen.

Mind. einmal hatte ich auch den Effekt, dass in Skype „Automatische Soundeinstellungen aktivieren“ nicht angehakt sein durfte: Wenn der Schalter angehakt war, hat Skype meine Mikro-Regler runtergeschoben.

Ergänzungen nehme ich jederzeit gerne hier auf.


]]> http://stefanroock.wordpress.com/2009/10/14/ubuntu-audiogerate-und-skype/feed/ 2 SR http://stefanroock.wordpress.com/2009/10/12/oop-2010-agil-auf-der-oop/ http://stefanroock.wordpress.com/2009/10/12/oop-2010-agil-auf-der-oop/#comments Mon, 12 Oct 2009 18:24:50 +0000 stefanroock http://stefanroock.wordpress.com/?p=739 ]]> 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.


]]> http://stefanroock.wordpress.com/2009/10/12/oop-2010-agil-auf-der-oop/feed/ 0 SR http://stefanroock.wordpress.com/2009/10/12/surfen-auf-rugen/ http://stefanroock.wordpress.com/2009/10/12/surfen-auf-rugen/#comments Mon, 12 Oct 2009 17:21:26 +0000 stefanroock http://stefanroock.wordpress.com/?p=736 ]]> Die ersten beiden Oktoberwoche war ich mit der Familie im Urlaub auf Rügen. Mit Pausen haben wir 8 Stunden für die Anreise gebraucht – wer hätte gedacht, dass man auf Rügen von links unten nach links oben mehr als eine Stunde brauchen kann… Aber die Insel war für mich dann doch überraschend groß und überall ist der Bodden im Weg, so dass man große Bogen fahren muss.

Windsurf-Reviere
Auf der anderen Seite bietet der Bodden coole Surfreviere. Wir haben in Dranske gewohnt. Dort kam allerdings der westliche Wind schräg ablandig und war durch die Abdeckung erst weit draußen einigermaßen stabil. Daher sind wir jeweils die 10 Minuten nach Wiek gefahren. Dort kann man (gegen Geld) direkt am Wasser parken, hat einen großen Stehbereich und Westwind kommt auflandig. Man hätte in Wiek auch direkt am Wasser wohnen können (z.B. Villa Maris, Strandhaus Wiek), aber das wussten wir vorher nicht.

Sowohl in Wiek wie auch in Dranske gibt es Surfstationen – die in Wiek sah aber etwas schäbig aus.

An einem Flautentag haben wir uns noch Surendorf auf Rügen angesehen. Dort hat man in der Breite 12 km Stehbereich, kommt aber nur über den Campingplatz ans Wasser. Sah aber auch sehr nett aus.

Der Wind
Mit dem Wind hatten wir Glück. Wir waren 14 Tage auf Rügen und hatten an zwei Tagen weniger als 4 Bft. Drei weitere Tage lagen bei 4 Bft., so dass man mit dem Kite oder großem Windsurf-Segel hätte auf’s Wasser gehen können. Das bedeutet, dass wir 9 Tage zwischen 5 und 9 Bft. hatten – eine ganz nette Wind-Ausbeute.

Das Wetter
Der erste Tag war sonnig und über 20 Grad warm. Danach kam der Temperatursturz auf 10-14 Grad. Allerdings hatten wir kaum Regen und häufig Sonne. So war es ganz gut auszuhalten.

Die Landschaft
Landschaftlich war Rügen überraschend hügelig und überraschend stark bewaldet. Auf jeden Fall sehr nett. Und obwohl Rügen eher dünn besiedelt ist, haben wir für die Kinder immer ausreichend Abwechslung gefunden. Dabei hat uns der Reiseführer Was machen wir morgen, Mama? sehr geholfen.

Die Leute
Wir hatten das Gefühl, dass die Leute im Service im Schnitt unfreundlicher und weniger aufmerksam waren, als wir das in anderen deutschen Urlaubsgebieten erlebt haben. Es gab aber auch Ausnahmen, wie z.B. unseren Vermieter der Ferienwohnung Alter Schwede.

Mein Fazit
Kann man mal wieder machen. Mehr Infos zu Rügen findet man z.B. unter http://www.ostsee24.de/ostseekueste/insel-ruegen.


Tagged: Windsurfing ]]> http://stefanroock.wordpress.com/2009/10/12/surfen-auf-rugen/feed/ 0 SR http://stefanroock.wordpress.com/2009/09/21/uberstunden-go-oder-no-go/ http://stefanroock.wordpress.com/2009/09/21/uberstunden-go-oder-no-go/#comments Mon, 21 Sep 2009 18:40:16 +0000 stefanroock http://stefanroock.wordpress.com/?p=731 ]]> Insbesondere mit dem Scrum-Commitment gibt es immer wieder Diskussionen über die ungeliebten Überstunden. Muss das Team Überstunden schieben, um sein Commitment zu halten? Diese Diskussion will ich hier aber gar nicht führen – vielleicht später. Bei der Diskussion um Überstunden habe ich häufig das Gefühl, dass es sich in der agilen Welt um eine heilige Kuh handelt. Überstunden sind ein No-Go und fertig. Tatsächlich glaube ich, dass wir uns mit dieser Haltung einer Option berauben, die man in der passenden Situation durchaus in Betracht ziehen sollte.

Und genau zu so einer Situation habe ich ein Praxisbeispiel. Wir haben vor einiger Zeit ein Projekt angenommen, in dem wir eine Webanwendung für eine Versicherung entwickeln sollten. Für das Projekt hatten wir 2,5 Monate Zeit und die Deadline war ebenso hart wie sportlich. Und da der Termin so eng war, haben wir gemeinsam im Team beschlossen, dass jeder von Beginn an soviele Überstunden macht, wie er selbst verantworten kann. Wir haben alle eine ganze Weile Überstunden geschoben. Die Menge hat aber über die Zeit abgenommen, weil wir immer sicherer wurden, dass wir den Termin halten können. Letztlich haben wir den Termin auch gehalten und es wurde eines der produktivsten und befriedigsten Projekte, an dem ich bisher beteiligt war – und das bei wirklich konsequentem TDD, sehr hoher Testabdeckung und sehr gut strukturiertem Code.
Bei der Retrospektive haben alle Teammitglieder die Überstunden-Maßnahme begrüßt. Sie wurde in einer „Jo, wir schaffen das“-Atmosphäre geboren (im Gegensatz zur sonst üblichen „Wir arbeiten soviel wir können, damit wir hinterher keinen Anschiss kriegen“-Atmosphäre). Es war also „Play to win“.

Zur Klarstellung: Ich rede hier nicht von Überstunden, die irgend jemand anordnet. Ich rede davon, dass das Team Überstunden bewusst und gewollt über einen kurzen und verantwortbaren Zeitraum einsetzt.


Tagged: eXtremeProgramming, Scrum ]]> http://stefanroock.wordpress.com/2009/09/21/uberstunden-go-oder-no-go/feed/ 1 SR http://stefanroock.wordpress.com/2009/09/18/13-leute-5-firmen-3-standorte-unmoglich-oder/ http://stefanroock.wordpress.com/2009/09/18/13-leute-5-firmen-3-standorte-unmoglich-oder/#comments Fri, 18 Sep 2009 14:30:59 +0000 stefanroock http://stefanroock.wordpress.com/?p=727 ]]> „Unser Team besteht aus 13 Leuten, die aus 5 Unternehmen stammen und an drei Standorten (inkl. Offshore) arbeiten. Die Teammitglieder sind deutlich erkennbar spezialisert: Neben Java-Entwicklern gibt es Web-Entwickler, Leute für den Content und Qualitätssicherer. Wir haben nicht einen PO, sondern zwei. Und ein Teil der Leute ist auch nur Teilzeit verfügbar. Ach ja: Wir haben übrigens das Product Backlog direkt vor dem Sprint nochmal ordentlich umgekrempelt.“
Wenn man mich vor drei Wochen gefragt hätte, wie groß ich die Erfolgswahrscheinlichkeit für dieses Team einschätzen würde, hätte ich wahrscheinlich „sehr niedrig“ gesagt. Und das ist wahrscheinlich auch die korrekte Antwort. Aber „sehr niedrig“ ist eben doch etwas mehr als 0, sprich: Das Team hat wirklich sehr gut als Team gearbeitet und ein sehr schönes Ergebnis produziert.

Sehen wir uns dazu einmal ein paar Eckdaten an:

• Es wurde nach Scrum gearbeitet.
• Es gab zwei Product Owner, aber es war klar, wer von den beiden im Zeifel die Hosen anhat.
• Je Standort gab es Colocation inkl. der Product Owner.
• Der Sprint hatte ein klares, ziemlich wichtiges Ziel: Das System geht für einen definierten Anwenderkreis live.
• In der Sprint-Planung wurde ein Task-Breakdown durchgeführt. Die Tasks wurden nicht in Stunden geschätzt. Stattdessen gab es die Regel, dass ein Task maximal einen Tag dauern darf und dann wurden die Tasks einfach gezählt.
• Der ScrumMaster hat bei der Sprint-Planung und während des Sprints dafür gesorgt, dass in Bezug auf dieses Ziel Minimalismus galt. Es wurden nur die Stories aufgenommen, die unbedingt für das Sprintziel notwendig waren.
• Die Anforderungen wurden als sehr kleine User-Stories formuliert. Noch während der Sprint-Planung wurden die User-Stories weiter in kleinere User-Stories aufgeteilt, so dass die User-Stories danach nur jeweils einen Umfang von wenigen Tagen hatten.
• Es gab jeden Tag zwei Daily Scrums. Zuerst eines über Skype mit den Standorten und danach noch eines am Hauptstandort.
• Der ScrumMaster hat insbesondere beim Daily Skype Scrum dafür gesorgt, dass Probleme auch sichtbar und bearbeitet wurden.
• Am Hauptstandort stand auch das Taskboards und die Sprint-Burndowns (geführt nach Anzahl Tasks und nach Anzahl Story Points).
• Die Burndowns wurden von Hand auf Flipchart-großem Papier erstellt und gepflegt. Die Stories waren natürlich auch elektronisch vorhanden, aber das elektronisch generierte Burndown war nie wirklich korrekt – die Ursachen dafür zu erklären, führt hier zu weit. Auf jeden Fall waren die händisch erstellten Burndowns die führenden Burndowns.
• Es gab einen ständig aktiven Skype-Chat für alle Team-Mitglieder.
• Das Sprint-Review nach dem Sprint war öffentlich im Unternehmen. Die Anzahl der zusätzlichen Teilnehmer war sehr überschaubar. Da aber der zuständige Fachbereichsleiter auch anwesend war, wurde die große Bedeutung des Sprints explizit. Außerdem war damit klar, dass man im Sprint-Review nicht mit einem zufälligen Herumgeclicke durch die Tür kommt.

Das Team hat es genau geschafft, das Sprintziel zu erreichen und das System termingerecht live zu stellen. Das Team ist sehr stolz auf seine Leistung und die Product Owner sind sehr zufrieden mit dem Erreichten.

Damit hier kein falscher Eindruck entsteht. Das war kein einfacher Sprint, den man mal so runterarbeitet. Es gab einen ganz Zoo von Problemen während des Sprints. Die Qualitätssicherer waren zunächst nicht so verfügbar, wie geplant, so dass dort ein Bottleneck entstand. Die Build-Infrastruktur ist bezogen auf automatisierte UI-Akzeptanztests faktisch zusammengebrochen (und während des Sprints auch nicht wieder auferstanden), etc. Aber das Team hat pragmatische und gangbare Lösungen gefunden. Und die bestanden nicht einfach darin, Qualität zu opfern. In dem Projekt wurden sehr viele automatisierte Akzeptanztests geschrieben und die entstandenen Code- und Teststrukturen können sich sehen lassen.

Meine ganze persönliche Bewertung der Geschichte: Ich glaube, dass Fokussierung ausschlaggebend für den Erfolg des Teams war. Dazu hat es z.B. sehr geholfen, nur die Stories einzuplanen, die unbedingt für das Sprintziel notwendig waren. Das Team hätte sich während des Sprints zusätzliche Stories geben lassen, wenn es schneller gewesen wäre als geplant. Dazu ist es aber nur in ganz kleinem Umfang gekommen. Stattdessen gab es auch keine „Versuchung“ schnell noch ein paar optionale Stories umzusetzen. Stattdessen wurde mehr Wert auf Qualität und Tests gelegt.

Und einen wesentlichen Anteil an der Fokussierung hatte der ScrumMaster. Das Projekt ist ein schönes Beispiel dafür, wieviel Unterschied ein guter ScrumMaster machen kann.

P.S.: Ich schreibe das hier nicht, um mich selbst zu loben. Ich habe den ScrumMaster nicht ausgebildet und für das Team kein Scrum-Coaching gemacht – ich war für ein anderes Thema als Coach im Team und bezogen auf Scrum hier nur staunender Beobachter.


Tagged: Scrum ]]> http://stefanroock.wordpress.com/2009/09/18/13-leute-5-firmen-3-standorte-unmoglich-oder/feed/ 1 SR http://stefanroock.wordpress.com/2009/09/18/xp-days-germany-am-26-28-11-09-in-karlsruhe/ http://stefanroock.wordpress.com/2009/09/18/xp-days-germany-am-26-28-11-09-in-karlsruhe/#comments Fri, 18 Sep 2009 08:17:36 +0000 stefanroock http://stefanroock.wordpress.com/?p=725 ]]> XP Days Germany ist die größte deutschsprachige Konferenz zur agilen Softwareentwicklung. Sie findet dieses Jahr vom 26. bis 28. November in Karlsruhe statt.

Einige Highlights:

• Keynote von Alistair Cockburn
• Zwei Halbtagestutorials mit begrenzter Teilnehmerzahl
• Vier parallele Tracks am Hauptkonferenztag
• Mehrere Pecha-Kucha-Blöcke
• Community Day mit Open Space und World Cafe

Das detaillierte Programm,den Link zur Anmeldung und zahlreiche weitere Informationen gibt es auf www.xpdays.de

Laufende Neuigkeiten über Teilnehmerzahlen, freie Plätze, Programmänderungen etc. werden über Twitter verbreitet. Informationen dazu gibt es hier: http://xpdays.de/2009/twitter.html

Ich selbst werde mit einem Vortrag zum inkrementellen Entwurf und einem Pecha-Kucha-Vortrag zu Stop-the-Line vertreten sein.

Ich hoffe, wir sehen uns auf den XP-Days.


Tagged: Architecture, eXtremeProgramming, Lean, Refactoring, Scrum, Testing ]]> http://stefanroock.wordpress.com/2009/09/18/xp-days-germany-am-26-28-11-09-in-karlsruhe/feed/ 1 SR http://stefanroock.wordpress.com/2009/09/17/skriptsprachen/ http://stefanroock.wordpress.com/2009/09/17/skriptsprachen/#comments Thu, 17 Sep 2009 06:58:04 +0000 stefanroock http://stefanroock.wordpress.com/?p=719 ]]> Die Verfechter von Ruby, Python etc. sprechen von dynamischen Skriptsprachen. Ich war bisher immer der Meinung, dass der Hauptunterschied zu Sprachen wie C++ und Java im Typsystem besteht. Java und Konsorten sind statisch getypt. Ruby, Python etc. sind je nach Sprechweise dynamisch getypt oder ungetypt.
Daher war ich der Meinung, man müsste eher ungetypt/dynamisch getypt gegen statisch getypt stellen. Und dann wären Sprachen wie Smalltalk oder Lisp eben auch in der Gruppe der ungetypten/dynamisch getypten Sprachen.

Neulich habe ich aber gemerkt, dass der Aspekt der Skriptsprache doch wichtiger ist, als ich angenommen hatte. Ich musste auf meinem Rechner einen Proxy-Server installieren, um bestimmte URLs umzulenken. Und dazu musste man ein Skript (z.B. in Perl) schreiben, das die URLs in die Ziel-URLs umwandelte.

Ich habe mir dazu ein Perl-Skript als Vorlage aus dem Internet besorgt. Mit meinen beschränkten Perl-Kenntnissen habe ich das Skript nicht wirklich verstanden, aber das schien mir auch nicht notwendig.

Das hat natürlich erstmal alles nicht funktioniert. Es wurden keine URLs umgelenkt. Und natürlich war mir auch unklar, wo das Problem liegt. War die Konfiguration des Proxy-Servers falsch oder stimmte etwas mit dem Perl-Skript nicht?

Das ließ sich aber ganz leicht herausfinden. Einfach das Perl-Skript mal so starten.
./redirect.pl
An der Fehlermeldung konnte man sofort sehen, dass das Skript Daten über die Pipe erwartet. Das ergibt auch Sinn: Der Proxy-Server gibt die aktuelle URL per Pipe an das Perl-Skript. Auch diese Situation kann ich direkt auf der Linux-Shell nachstellen:
echo http://meineUrl.de | ./redirect.pl
Und siehe da, das Skript läuft durch, erzeugt aber nicht die Ausgaben, die ich erwartet habe. Folgerung: Mit dem Skript stimmt etwas nicht. Mit Quellcode-Anstarren und etwas Internet-Recherche habe ich das Problem dann auch schnell identifiziert und das Skript korrigiert.

Stellen wir uns zum Vergleich vor, das Redirect-Skript wäre in Java programmiert gewesen (C++ stellen wir uns hier lieber nicht vor…). Dann hätte ich das Programm nicht einfach so aufrufen können. Ich hätte erstmal den Classpath zusammenstellen müssen. Oder ich hätte mir einen Unittest geschrieben, um das Skript zu testen. Und für das Austesten direkt zusammen mit dem Proxy-Server hätte ich immer wieder neu compilieren müssen. Auf jeden Fall wäre das ganze ein gutes Stück schwergewichtiger mit deutlich längeren Turn-Around-Zeiten gewesen.

Und dieser Vorteil zeigt sich nicht nur bei so kleinen Hilfsskripten. Auch in echten Anwendungen ist es nützlich, wenn man einen verdächtigen Teil seiner Anwendung einfach so aus der Shell starten kann.


]]> http://stefanroock.wordpress.com/2009/09/17/skriptsprachen/feed/ 1 SR http://stefanroock.wordpress.com/2009/08/21/xp-days-germany-2009/ http://stefanroock.wordpress.com/2009/08/21/xp-days-germany-2009/#comments Fri, 21 Aug 2009 07:46:04 +0000 stefanroock http://stefanroock.wordpress.com/?p=716 ]]> Das Programm der XP-Days Germany 2009 ist jetzt online: http://xpdays.de/2009/programm.html

Ich selbst bin am Freitag mit einem Vortrag über „Inkrementelles Design“ vertreten. Da ich ein Verfechter kurzer Vorträge bin, habe ich das Thema als 30-Minuten-Vortrag eingereicht. Einige der Reviewer hatten Zweifel, ob das Thema in 30 Minuten untergebracht werden kann. Das ist gut. Ich mag Herausforderungen.

Am Donnerstag halte ich eine Pecha-Kucha-Session zum Thema „Stop the Line in der Softwareentwicklung“. Pecha-Kucha ist ein modernes Vortragsformat, in dem genau 20 Folien für jeweils genau 20 Sekunden gezeigt werden. Der ganze Vortrag dauert dann exakt 6:40 Minuten. Bei der JAX 2009 haben wir das bereits einmal ausprobiert. Naja, ok: Ich habe ausprobieren lassen und mich auf die Organisation beschränkt. Auf den XP-Days muss ich jetzt selbst zeigen, ob ich das Format gut ausgefüllt bekomme.

Auf der JAX 2009 hatte mein Kollege Bernd Schiffer einen Pecha-Kucha-Vortrag über „Inkrementelles Design“ gehalten, der jetzt auch als Video verfügbar ist. Für alle, die bei den XP-Days (oder der W-JAX oder sonstwo) einen Pecha-Kucha-Vortrag halten, ist das Video sicher eine ganz gute Inspiration und es zeigt auch, dass 20 Sekunden je Folie manchmal ziemlich lang sein kann


Tagged: Architecture, eXtremeProgramming, Scrum, Testing ]]> http://stefanroock.wordpress.com/2009/08/21/xp-days-germany-2009/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/29/scrum-bei-xing/ http://stefanroock.wordpress.com/2009/07/29/scrum-bei-xing/#comments Wed, 29 Jul 2009 15:27:33 +0000 stefanroock http://stefanroock.wordpress.com/?p=713 ]]> Xing setzt für die Softwareentwicklung auf Scrum und hat dazu drei Blog-Artikel verfasst:
1. Einführung von Scrum bei XING – Ein Erfahrungsbericht
2. Einführung von Scrum bei XING – ein Erfahrungbericht #2: Die Schwierigkeiten
3. Einführung von Scrum bei XING – ein Erfahrungbericht #3: Ein Fazit

Tagged: Scrum ]]> http://stefanroock.wordpress.com/2009/07/29/scrum-bei-xing/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/28/hochproduktive-teams-kochen/ http://stefanroock.wordpress.com/2009/07/28/hochproduktive-teams-kochen/#comments Tue, 28 Jul 2009 08:46:28 +0000 stefanroock http://stefanroock.wordpress.com/?p=709 ]]> Joseph Peline schreibt an einem Buch über hochproduktive, selbstorganisierte Teams. Ein paar Draft-Auszüge hat er in seinem Blog veröffentlicht, die bereits sehr interessant aussehen.

Joseph verwendet Kochen als Metapher. Zu wenig Hitze und das Essen wird nicht gar, zuviel Hitze und das Essen verbrennt. Und dieses Modell wendet Jospeph auf Teams an. Sie sollen „kochen“. Das ist der Zustand, in dem das Team wirklich hochproduktiv arbeitet, Gerade weil die Teammitglieder ihre Komfortzone verlassen müssen.

die Herausforderung besteht jetzt also darin, die Teams mit dem richtigen Maß an Hitze zu versorgen. Ich hatte zuerst Schwierigkeiten mit dem Modell, weil ich unterbewusst Hitze mit Druck gleichgesetzt habe. Aber so ist es sicher nicht gemeint – jedenfalls nicht Druck im klassischen Sinne („Ihr müsst genau diese Funktionen, zu genau dieser Zeit zu genau diese Deadline schaffen, sonst….“). Mit Hitze ist hier das gemeint, was notwendig ist, um die Teammitglieder zu aktivieren, dafür zu sorgen, dass sie ihre Komfortzone verlassen.

So betrachtet hilft das Modell, Phänomene zu verstehen, die mir immer wieder über den Weg laufen. Da gibt es z.B. Scrum-Teams, die jedes Commitment halten und auch der Product-Owner ist zufrieden. Trotzdem fühlt es sich so an, als wäre irgendetwas nicht richtig. Man spürt keine Energie. Nach Josephs Koch-Metapher sind wir auf Level 3: Cooling (Stagnation). Das Team erledigt seine Arbeit verlässlich und routinisiert, aber es arbeitet letztlich deutlich unter seinen Möglichkeiten und zumindest mir würde die Arbeit in so einem Team auch keinen Spaß machen.

Ich bin wirklich sehr gespannt, wie sich Joseph’s Buch weiterentwickelt und hoffe, dass es bald komplett veröffentlicht wird.

Hier sind die bisher veröffentlichten Ausschnitte:

1. Turning up the heat – introduction
2. Turning up the heat – the basic model
3. Turning up the heat – the levels

Tagged: Scrum ]]> http://stefanroock.wordpress.com/2009/07/28/hochproduktive-teams-kochen/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/27/bdd-for-prolog-how-to/ http://stefanroock.wordpress.com/2009/07/27/bdd-for-prolog-how-to/#comments Mon, 27 Jul 2009 17:05:01 +0000 stefanroock http://stefanroock.wordpress.com/?p=706 ]]> ProSpec is a RSpec (http://rspec.info) inspired BDD framework for Prolog. I created it during my experiments with Prolog. I suspect that I did some strange things. I would be pleased by any feedback on how to improve ProSpec or the examples. Send me an E-Mail: stefan AT stefanroock DOT de

Every ProSpec specification starts with describe(FixtureName) and ends with end_describe. Within these two predicates every specification is declared with it(SpecName/SpecCode).

We start with a very simple BDD spec for bowling.

bowling_spec.pro:

:- ensure_loaded('ProSpec.pro').
:- ensure_loaded('bowling.pro').

:- describe('Bowling'). 

generate_bowling_hits(_, 0).
generate_bowling_hits(Hit, Count) :- bowling_hit(Hit), Count2 is Count-1, generate_bowling_hits(Hit, Count2).

:- it('should score 0 for gutter game'/(
	generate_bowling_hits(0, 20),
	bowling_score(Score),
	assert_that(Score, equals:0)
)). 

:- end_describe.

bowling.pro:

bowling_hit(Count).
bowling_score(0).

With „run_specs.“ the BDD spec runs:

Bowling...
...should score 0 for gutter game (passed)
Passed:1

1 specs passed

In the next step with specify the next behaviour increment:

bowling_spec.pro:

:- ensure_loaded('ProSpec.pro').
:- ensure_loaded('bowling.pro').

:- describe('Bowling'). 

generate_bowling_hits(_, 0).
generate_bowling_hits(Hit, Count) :- bowling_hit(Hit), Count2 is Count - 1, generate_bowling_hits(Hit, Count2).

:- it('should score 0 for gutter game'/(
	generate_bowling_hits(0, 20),
	bowling_score(Score),
	assert_that(Score, equals:0)
)). 

:- it('should sum hits of a game'/(
	generate_bowling_hits(2, 20),
	bowling_score(Score),
	assert_that(Score, equals:40)
)). 

:- end_describe.

„run_specs.“ shows that this spec fails:

Bowling...
...should score 0 for gutter game (passed)
...should sum hits of a game
	Expected 40 equal to 0

We extend the bowling implementation:

bowling_hit(Count) :- assert(bowling_hit_def(Count)).

bowling_score(Score) :-
	findall(Hit, bowling_hit_def(Hit), Hits),
	sumlist(Hits, Score).

Now the spec succeeds, but only once. The reason is the growing number
of „bowling_hit_def“ facts. To avoid this problem ProSpec offers „setup_spec“.

bowling_spec.pro:

:- ensure_loaded('ProSpec.pro').
:- ensure_loaded('bowling.pro').

:- describe('Bowling'). 

generate_bowling_hits(_, 0).
generate_bowling_hits(Hit, Count) :- bowling_hit(Hit), Count2 is Count - 1, generate_bowling_hits(Hit, Count2).

:- dynamic(setup_spec/0).

setup_spec :-
	retractall(bowling_hit_def(_)).

:- it('should score 0 for gutter game'/(
	generate_bowling_hits(0, 20),
	bowling_score(Score),
	assert_that(Score, equals:0)
)). 

:- it('should sum hits of a game'/(
	generate_bowling_hits(2, 20),
	bowling_score(Score),
	assert_that(Score, equals:40)
)). 

:- end_describe.

Now the spec succeeds every time.

There is a bunch of other assert_that predicates in ProSpec.pro. Have a look
and proceed: http://github.com/stefanroock/ProSpec/


Tagged: Prolog, Testing ]]> http://stefanroock.wordpress.com/2009/07/27/bdd-for-prolog-how-to/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/27/reflektionen-uber-prolog/ http://stefanroock.wordpress.com/2009/07/27/reflektionen-uber-prolog/#comments Mon, 27 Jul 2009 16:46:21 +0000 stefanroock http://stefanroock.wordpress.com/?p=696 ]]> Ich erkläre meine Experimente mit Prolog jetzt erstmal für beendet und schließe mit ein paar Reflektionen über Prolog. Es ist durchaus möglich, dass ich an der einen oder anderen Stelle einem Irrtum aufgesessen bin. In diesem Fall freue ich mich über entsprechende Kommentare.
1. Prolog als Sprache fand ich ganz lustig, auch weil die Ansätze so anders sind als das, was man sonst so in Programmiersprachen vorfindet. In diesem Sinne war die Beschäftigung mit Prolog auf jeden Fall zur Horizonterweiterung nützlich.
2. Für Prolog gibt es einen ISO-Standard, so dass Prolog-Systeme verschiedener Hersteller kompatibel sein sollten. Das ist eigentlich ganz nett. Aber je mehr Programmiersprachen mit ISO-Standard ich kennenlerne, umso mehr habe ich den Eindruck, dass eine ISO-Standardisierung die Fahrkarte ins Reich der toten Programmiersprachen ist.
3. Möglicherweise ist das auch der Grund dafür, warum es keine Weiterentwicklung von Prolog zu geben scheint. Das finde ich persönlich schade, weil ich die Ansätze vielversprechend finde. Aber irgendwie müsste man die Konzepte noch in die heutige Zeit bringen.
4. Und ein Nutzen wäre da. Soweit ich das überblicken kann, macht eine Rule-Engine ungefähr, das was Prolog macht – nur eben in einer proprietären Sprache. Wenn man Pech hat, kommt auch noch XML ins Spiel die ganze Geschichte wird auch noch schwer lesbar. Wäre es nicht viel smarter, Prolog dafür zu verwenden?
5. Prolog hat den Anspruch, den Entwickler weitestgehend von Algorithmen zu entlasten und stattdessen nur noch Spezifikationen schreiben zu lassen. Das finde ich einen lohnenswerten Ansatz. Ich hatte das Gefühl, dass ich tatsächlich weniger Algorithmik betreiben muss. Ich muss aber im Gegenzug wissen, wie Prolog die Regeln auswertet – also letztlich welche Algorithmen Prolog anwendet. Und das fand ich nicht immer trivial. Daher hatte ich auch so meine Schwierigkeiten, den Cut-Operator sinnvoll einzusetzen. Aber vielleicht wird das einfacher, mit mehr Übung?
6. In die gleiche Problemkategorie fällt, dass ich zwischendurch immer mal Situationen hatte, wo eine Regelauswertung auf einmal 20 Sekunden gedauert hat – bei einer handvoll Fakten. Und mir war nicht immer klar, wie das passiert ist. Insgesamt sollen aber Prolog-Programme auch nicht langsamer sein als Programme, die in anderen Programmiersprachen entwickelt werden.
7. Beeindruckend fand ich, dass ich mein Terminplaner-Beispiel in Prolog mit extrem wenigen Zeilen Code schreiben konnte, ohne dass der Code schwer verständlich wurde. Allerdings hat das Beispiel wieder Benutzungsoberfläche noch Datenbank. Wenn beides dazukommt und man die Lösung mit Rails oder Grails vergleicht, ist der Unterschied vermutlich nicht mehr so drastisch. Schließlich ist SQL ja sowas wie Prolog-Light.
8. Apropos Benutzungsoberfläche und Datenbank: Prolog ist keine isolierte Regel-Auswertungsmaschine. Anbindungen an Rich-Client-Libs, HTTP und Datenbanken existiert in Form von Libraries.
9. Durch sein Pattern-Matching ist es mit Prolog ganz einfach, eine internen DSL zu formulieren – auch wenn man sich wünschen würde, die Klammern der Root-Regel noch loswerden zu können.
10. Regeln haben in Prolog keinen Rückgabewert. Stattdessen werden als Variablen angegebene Parameter zu diesem Zweck verwendet. Das in sehr flexibel und funktioniert eben auch für mehrere Rückgabewerte. Auf der Negativseite steht, dass man für einfache Ausdrücke eigene Variablen einführen muss. Möchte man an eine Regel index+1 übergeben, muss man dazu eine Extra-Variable einführen. Das finde ich definitiv umständlich.
11. Die meisten Prolog-Systeme bieten ein Modulkonzept. Das ist nicht im ISO-Standard enthalten, aber zwischen die Prolog-Systemen aber sehr ähnlich. Ich habe das Modulsystem nicht benutzt, aber es sieht vernünftig aus.
12. Außerdem gibt es sowas wie Objektorientierung (mind. in SWI-Prolog), aber das sieht echt merkwürdig aus.
13. Und dann ist da noch die Datenbasis mit den Regeln und Fakten. Durch diese Datenbasis lassen sich viele Dinge sehr einfach und elegant formulieren. Allerdings stellt sie auch globalen Zustand dar – mit den üblichen Nachteilen globaler Variablen. So muss man z.B. bei Tests selbst dafür sorgen, dass die Datenbasis aufgeräumt wird. Positiv an der Datenbasis ist allerdings, dass nach Programmausführung bzw. Test die Daten für Post-Mortem-Debugging verfügbar sind.

Hat jemand andere oder ergänzende Erfahrungen? Dann immer her damit!


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/27/reflektionen-uber-prolog/feed/ 1 SR http://stefanroock.wordpress.com/2009/07/27/beispiel-fur-closure/ http://stefanroock.wordpress.com/2009/07/27/beispiel-fur-closure/#comments Mon, 27 Jul 2009 10:58:51 +0000 stefanroock http://stefanroock.wordpress.com/?p=692 ]]> Gerade habe ich einen Anwendungsfall für Closures. Ich habe sequenziellen Code a la:

tueA();
tueB();
tueC();

Ich möchte gerne mitloggen, wie lange die einzelnen Schritte dauern (um das Beispiel zu vereinfachen, logge ich durch Ausgabe auf die Konsole):

long startTime = System.currentTimeMillis();
tueA();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

startTime = System.currentTimeMillis();
tueB();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

startTime = System.currentTimeMillis();
tueC();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

Das funktioniert, nur den eigentlichen Code kann man kaum wiederfinden. Wenn ich Closures (wie z.B. in Groovy) zur Verfügung habe, ist es ganz einfach:

def timeLogged (Closure c) {
    long start = - System.currentTimeMillis()
    c.call()
    println "duration in sec: " + (System.currentTimeMillis() + start) / 1000;
}

timeLogged { tueA() }
timeLogged { tueB() }
timeLogged { tueC() }

Das ist kürzer, redundanzfreier und meiner Meinung nach deutlich besser lesbar.

P.S.: Redundanzfrei kann es ohne Closures in Java natürlich auch hinkriegen, mit anonymen Inner Classes. Dummerweise wird der Code dann noch länger und noch schwerer lesbar.


Tagged: Groovy ]]> http://stefanroock.wordpress.com/2009/07/27/beispiel-fur-closure/feed/ 3 SR http://stefanroock.wordpress.com/2009/07/26/verantwortung-in-der-praxis/ http://stefanroock.wordpress.com/2009/07/26/verantwortung-in-der-praxis/#comments Sun, 26 Jul 2009 18:26:30 +0000 stefanroock http://stefanroock.wordpress.com/?p=688 ]]> Bernd Schiffer hat ein interessantes Foto geschossen:

http://twitpic.com/bmajr

Da ist also eine Fahrtreppe der Deutschen Bahn außer Betrieb. Als Grund wird angegeben, dass der namentlich genannte Lieferant nicht rechtzeitig geliefert habe.

Diese Aktion der Deutschen Bahn finde ich seltsam. Ich habe den Eindruck, die Bahn will damit die Verantwortung für die nicht-funktionierende Fahrtreppe auf den Lieferanten abwälzen. Allerdings kaufe ich mein Ticket ja bei der Deutschen Bahn und nicht bei deren Lieferanten. Und wenn die Lieferanten nicht funktionieren, liegt die Verantwortung letztlich auch bei der Deutschen Bahn. Diese hat ja schließlich die Lieferanten ausgewählt.

Die ganze Geschichte ist aber keineswegs einmalig, sondern sehr häufig anzutreffen. Wenn Teams mit Scrum beginnen, zeigen sie im ersten Sprint-Review häufig ähnliche Verhaltensweisen: „Ja, wir haben unser Commitment nicht gehalten. Das ist aber nicht unsere Verantwortung. Das liegt nur daran, dass der Datenbank-Administrator unsere Tabellen nicht reichtzeitig angelegt hat.“ Und dann sprechen wir über Verantwortung und Commitment. Auch wenn ich von jemand anderem abhängig bin, ändert das nichts an meiner Verantwortung, die ich mit dem Commitment eingegangen bin. Entweder muss ich herausfinden, wie ich mein Commitment trotzdem halten kann oder ich darf kein Commitment abgeben.


Tagged: Scrum ]]> http://stefanroock.wordpress.com/2009/07/26/verantwortung-in-der-praxis/feed/ 3 SR http://stefanroock.wordpress.com/2009/07/21/bdd-for-prolog/ http://stefanroock.wordpress.com/2009/07/21/bdd-for-prolog/#comments Tue, 21 Jul 2009 19:38:50 +0000 stefanroock http://stefanroock.wordpress.com/?p=686 ]]> During my experiments with Prolog I needed a test framework. I startet with the unit test framework written by Ken Egozi. Over time I tried to migrate it to a more BDD like style. I named the result „ProSpec“. Here is the code (Open-Source-License):

it(Spec_Desc/Spec):-
    current_fixture(Fixture),
    retractall(spec_def(Fixture/Spec_Desc/Spec)),
    assert(spec_def(Fixture/Spec_Desc/Spec)). 

describe(Fixture) :-
    retractall(spec_def(Fixture/_/_)),
    assert(current_fixture(Fixture)). 

end_describe:-
    retractall(current_fixture(_)). 

run_one_spec(Pred/Name) :-
	spec_def(Pred/Name/Spec),
	setup_spec,
	call(Spec).

run_specs :-
    dynamic(setup_spec/0),
    dynamic(specs_stats/2),
    write('Run Specs '), nl,
    bagof(Fixture/Specs, bagof((Spec_Desc/Spec), spec_def(Fixture/Spec_Desc/Spec), Specs), SpecsPerPredicate),
    run_specs(SpecsPerPredicate, Passed/Failed),
    write_specs_summary(Passed/Failed). 

run_specs(SpecsSpecsPerPredicate, TotalPassed/TotalFailed) :-
    run_specs(SpecsSpecsPerPredicate, 0/0, TotalPassed/TotalFailed). 

run_specs([], Passed/Failed, Passed/Failed):-!. 

run_specs([Fixture/Specs|Rest], Passed/Failed, TotalPassed/TotalFailed):-
    nl, write(Fixture), write('...'), nl,
    foreach_spec(Specs, PassedInPredicate/FailedInPredicate),
    write('Passed:'), write(PassedInPredicate),
    (FailedInPredicate > 0, write(' Failed:'), write(FailedInPredicate) ; true),
    nl,
    Passed1 is Passed + PassedInPredicate,
    Failed1 is Failed + FailedInPredicate,
    run_specs(Rest, Passed1/Failed1, TotalPassed/TotalFailed). 

foreach_spec(Specs, Passed/Failed):-
    foreach_spec(Specs, 0/0, Passed/Failed). 

foreach_spec([], Passed/Failed, Passed/Failed):-!.
foreach_spec([Spec_Desc/Spec|Rest], Passed/Failed, NewPassed/NewFailed):-
    (
	setup_spec, call(Spec), !,
        NextPassed is Passed + 1,
        NextFailed is Failed,
        write('...'), write(Spec_Desc), write(' (passed)'), nl
    ;
        NextFailed is Failed + 1,
        NextPassed is Passed,
        write('...'), write(Spec_Desc), write(' (FAILED)'), nl
    ),
    foreach_spec(Rest, NextPassed/NextFailed, NewPassed/NewFailed). 

write_specs_summary(Passed/0) :- !,
    nl,
    write(Passed), write(' specs passed'),
    nl.
write_specs_summary(Passed/Failed) :-
    nl,
    write(Passed), write(' specs passed,'), nl,
    write(Failed), write(' specs failed'),
    nl. 

reset_all_specs:-
    retractall(spec_def(_/_/_)).

run_spec(Spec) :-
    call(Spec),!,
    specs_passed(X),
    retract(specs_passed(X)),
    NewX is X + 1,
    assert(specs_passed(NewX)).
run_spec(Spec) :-
    failing_specs(X),
    retract(failing_specs(X)),
    NewX = [Spec|X],
    assert(failing_specs(NewX)).

% Asserts
assert_that(Actual, equals:Expected) :-
	Actual \= Expected, nl, write('Expected '), write(Expected), write(' equal to '), write(Actual), nl, fail;
	Actual == Expected.

assert_that(Actual, not_equals:Expected) :-
	Actual == Expected, nl, write('Expected '), write(Expected), write(' not equal to '), write(Actual), nl, fail;
	Actual \= Expected.

assert_that(Actual, is_true) :-
	Actual;
	nl, write('Expected '), write(Actual), write(' to be true '), nl, fail.

assert_that(Actual, is_false) :-
	Actual, !, nl, write('Expected '), write(Actual), write(' to be false '), nl, fail;
	true.

assert_that(Actual, fails) :-
	assert_that(Actual, is_false).

assert_that(Actual, is_empty) :-
	Actual \= [], nl, write('Expected '), write(Actual), write(' to be empty '), nl, fail;
	Actual == [].

assert_that(Actual, has_member:Member) :-
	not(member(Member, Actual)), nl, write('Expected '), write(Actual), write(' to has member '), write(Member), nl, fail;
	member(Member, Actual).

assert_that(Actual, has_no_member:Member) :-
	member(Member, Actual), nl, write('Expected '), write(Actual), write(' to has no member '), write(Member), nl, fail;
	not(member(Member, Actual)).

assert_that(Actual, contains_all:Sublist) :-
	not(contains_all(Actual, Sublist)), nl, write('Expected '), write(Actual), write(' to contain all members of '), write(Sublist), nl, fail;
	contains_all(Actual, Sublist).

contains_all(_, []) :- true.
contains_all(List, [Member]) :- member(Member, List).
contains_all(List, [Member|Rest]) :- member(Member, List), contains_all(List, Rest).

The whole ProSpec can be downloaded from github.


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/21/bdd-for-prolog/feed/ 1 SR http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-8-datenbasis/ http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-8-datenbasis/#comments Tue, 21 Jul 2009 18:12:40 +0000 stefanroock http://stefanroock.wordpress.com/?p=683 ]]> In den vorigen Blogposts haben wir Fakten, Regeln, das Prolog-System, Pattern-Matching, Rekursion, Fail und den Cut-Operator betrachtet. Damit haben wir die grundlegenden Dinge beisammen, um Prolog-Programme zu schreiben. Jedenfalls fast. Wir müssen noch ein paar Dinge über die Prolog-Datenbank für Fakten und Regeln lernen. Wir können die Datenbasis nämlich zur Programmlaufzeit dynamisch verändern!

Mit assert können wir Fakten und Regeln zur Laufzeit hinzufügen.

assert(benutzer(levi)).

fügt den neuen Fakt „Levi ist ein Benutzer“ zur Datenbasis hinzu.

Mit „asserta“ wird an den Anfang und mit „assertz“ ans Ende der Datenbasis hinzugefügt.

Den Effekt kann man mit „listing“ überprüfen:

listing.

listet alle Fakten und Regeln der Datenbasis auf.

Mit „retractall“ werden alle Fakten/Regeln aus der Datenbasis entfernt, die zum angegebenen Fakt/Regel passt.

retractall(benutzer(_)).

Anmerkung: Der Unterstrich ist übrigens eine anonyme Variable, die man immer dann einsetzt, wenn man an dem konkreten Wert der Variablen nicht interessiert ist.

Und nicht zuletzt kann man mit „findall“ Regeln und Fakten in der Datenbasis suchen:

findall(Benutzer, benutzer(_), BenutzerListe).

liefert alle Regeln namens „benutzer“ mit einem Parameter.


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-8-datenbasis/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-7-cut-operator/ http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-7-cut-operator/#comments Tue, 21 Jul 2009 17:49:52 +0000 stefanroock http://stefanroock.wordpress.com/?p=670 ]]> Das Prolog-System sucht stets nach allen möglichen Lösungen für eine Anfrage und liefert diese nacheinander als Ergebnis. Manchmal möchte man das aber gar nicht. Stattdessen ist man mit dem erstbesten Ergebnis vollkommen zufrieden.

Nehmen wir ein selbstgebautes IF-THEN-ELSE-Konstrukt als Beispiel. Eine erste Implementation könnte so aussehen:

if_then_else(P, Q, R) :- P, Q ; R.

Wenn die Bedingung Q wahr ist, wird die Then-Regel Q aktiviert. Wenn Q nicht wahr ist, greift die zweite Definition von „if_then_else“ und es wird die Else-Regel R aktiviert. (Wir erinnern uns: Komma bedeutet „und“, Semikolon bedeutet „oder“).

Wenn man die if_then_else-Regel so aktiviert, dass die Else-Bedingung aktiviert wird, ist das Ergebnis erwartungskonform.

if_then_else(false, write('then'), write('else')).

gibt „else“ aus und hat „true“ als Ergebnis.

Anders sieht es aus, wenn wir „true“ als Bedingung übergeben.

if_then_else(true, write('then'), write('else')).

schreibt zuerst „then“ und hat „true“ als Ergebnis. Aber als nächstes wird „else“ ausgegeben und wieder „true“ geliefert. Nanu? Was ist denn da los?

Die Ursache ist das Auswertungsverfahren, dass Prolog einsetzt. Zuerst wird geprüft, ob P gilt. Wenn das der Fall ist, wird Q ausgewertet. Und danach wird R auch noch ausgewertet – weil nichts dagegen spricht.

Prolog unterscheidet sich hier von dem, was die meisten anderen Programmiersprachen machen. Die meisten Programmiersprachen brechen die Auswertung eines Ausdrucks ab, wenn die weitere Auswertung das Ergebnis nicht mehr ändern kann. Mit dieser Auswertungsregel bräuchte man R nicht mehr auswerten. Die if_then_else-Regel ist durch den ersten Teil der Oder-Klausel bereits „true“.

Um mit dieser Problematik umzugehen, bietet Prolog den Cut-Operator „!“. Der Cut-Operator setzt eine Grenzlinie, über die Prolog bei der Auswertung einer Regel nicht zurück darf (das sogenannte Backtracking wird eingeschränkt). Mit Hilfe des Cut-Operators sieht unsere if_then_else-Regel so aus:

if_then_else(P, Q, R) :- P, !, Q ; R.

und jetzt verhält sich die Regel auch erwartungskonform.

if_then_else(true, write('then'), write('else')).

schreibt zuerst „then“ und hat „true“ als Ergebnis und mehr passiert nicht.

Anmerkung: Man hätte den Cut-Operator auch noch eine Position weiter nach hinten schreiben können, also hinter Q.

Prinzipiell gibt es zwei Anwendungsbereiche für den Cut-Operator: Logik und Performance. Wir haben den Cut-Operator angewendet, weil unser Programm sonst nicht richtig funktioniert. Manchmal wendet man den Cut-Operator auch an, um aus Performancegründen unnötige Auswertungen zu unterbinden.

Und leider ist der Cut-Operator nicht-trivial. Mit meinen bisherigen Prolog-Kenntnissen kann ich häufig nicht auf Anhieb sagen, ob und wo genau ein Cut-Operator notwendig ist. Ich sehe erst beim Ausprobieren meiner Regeln, dass sie nicht richtig funktionieren – das zeigt sich häufig in Form von Endlosrekursion. Aber vielleicht wird man da mit der Zeit geübter.

Auf jeden Fall muss man für die Anwendung des Cut-Operators ziemlich genau wissen, wie Prolog die Regeln auswertet. Und das finde ich etwas skurril. Schließlich ist Prolog mit dem Anspruch angetreten, dass man sich um die Algorithmik nicht mehr kümmern muss und seine Logik nur noch spezifiziert. Insgesamt hat Prolog da auch Beeindruckendes zu bieten. Aber der Cut-Operator passt da nicht so gut ins Bild. Immerhin habe ich den Cut-Operator in meinen Beispielprogrammen bisher nur selten benötigt.


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-7-cut-operator/feed/ 1 SR http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-6-fail/ http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-6-fail/#comments Tue, 21 Jul 2009 17:45:55 +0000 stefanroock http://stefanroock.wordpress.com/?p=668 ]]> Das Prolog-System sucht stets nach allen möglichen Lösungen für eine Anfrage und liefert diese nacheinander als Ergebnis. Nehmen wir einmal an, wir wollen alle Benutzer ausgeben, die wir mit Fakten wie benutzer(stefan). definiert haben. Nehmen wir für unser Beispiel an, wir haben drei Benutzer definiert:

benutzer(stefan).
benutzer(mika).
benutzer(silke).

Dann könnte eine erste Version der Regel zur Ausgabe aller Benutzer so aussehen:

schreibe_alle_benutzer :- benutzer(X), write(X), nl.

Die Anwendung liefert drei Ergebnisse (in SWI-Prolog „n“ nach jedem „true“ getippt):

stefan
true;
mika
true;
silke
true

Das ist nicht ganz das, was wir wollen. Wir wollen, dass alle Benutzer auf einmal geschrieben werden. Das können wir dadurch erreichen, dass wir die Regel absichtlich fehlschlagen lassen. Damit zwingen wir das Prolog-System, alle möglichen Belegungen für „X“ durchzugehen:

schreibe_alle_benutzer :- benutzer(X), write(X), nl, fail.

Damit erhalten wir:

stefan
mika
silke
false

Das ist schon deutlich besser, aber das „false“ am Ende ist etwas störend. Wenn wir „schreibe_alle_benutzer“ aus anderen Regeln aufrufen wollen, wird es sogar unangenehm, weil diese Regel immer scheitert. Das Problem lässt sich aber ganz leicht lösen, indem wir das Ergebnis der Regel verodern (; bedeutet in Prolog „oder“):

schreibe_alle_benutzer :- benutzer(X), write(X), nl, fail; true.

Damit erhalten wir:

stefan
mika
silke
true


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-6-fail/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-5-rekursion/ http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-5-rekursion/#comments Tue, 21 Jul 2009 16:47:12 +0000 stefanroock http://stefanroock.wordpress.com/?p=666 ]]> In Prolog gibt es keine Schleifenkonstrukte wie FOR oder WHILE im klassischen Sinne. Stattdessen wird Rekursion verwendet. Häufig trifft man Rekursion in Prolog im Zusammenhang mit Listen an.

Wollen wir beispielsweise alle Elemente einer Liste ausgeben, so können wir dies durch folgende Regeln erreichen:

schreibe_liste([]).
schreibe_liste([H|T] :- write(H), write(','), schreibe_liste(T).

Diese Definition liest sich so: Wenn wir eine leere Liste haben, schreiben wir nichts. Ansonsten schreiben wir das erste Element, gefolgt von einem Zeilenumbruch „nl“ und schreiben den Rest der Liste.

Durch die Definition von „schreibe_liste([])“ haben wir die Abbruchbedingung für die Rekursion definiert. Hätte man diese Definition weggelassen, würde die Ausgabe immer noch korrekt erfolgen, „schreibe_liste“ würde aber immer „false“ liefern – weil die rekursive Regelanwendung irgendwann bei der leeren Liste ankommen würde, die sich nicht weiter aufsplitten lässt. Bei anderen Definitionen kann das Weglassen der Abbruchregel leicht zu Endlosrekursionen führen.


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/21/prolog-grundzuge-5-rekursion/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-4-pattern-matching/ http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-4-pattern-matching/#comments Mon, 20 Jul 2009 20:09:58 +0000 stefanroock http://stefanroock.wordpress.com/?p=664 ]]> Eine weiteres sehr nützliches Prolog-Feature ist das Pattern-Matching. In den meisten Programmiersprachen wird zur Auswahl einer Funktion oder Prozedur nur der Name herangezogen, bei Java und Konsorten auch noch die Anzahl und der statische Typ der Parameter. Bei Prolog wird außerdem die Form der Argumente herangezogen.

So kann man in einer Regeldefinition z.B. den Split-Operator für Listen (den wir im letzten Blogeintrag kennen gelernt haben) verwenden und sowas schreiben:

liste([H,T], H, T) :- true.

tut dasselbe wie die Regel „liste“ aus dem letzten Blogeintrag. Dort war „liste“ definiert als:

liste(EineListe, H, T) :- [H|T] = EineListe.

Wir werden beim Thema Rekursion sehen, dass es hier nicht nur darum geht, Regeln etwas kürzer aufschreiben zu können. Das Pattern-Matching ist letztlich die Voraussetzung dafür, dass sich Rekursion in Prolog überhaupt elegant benutzen lässt.

Und über das Pattern-Matching kann man benannte Parameter realisieren, ohne dass Prolog dieses Konzept direkt unterstützt:

fuelle_liste([Wert], mit:1, mal:Wert) :- !.
fuelle_liste(Liste, mit:Anzahl, mal:Wert) :- AnzahlRed is Anzahl - 1, fuelle_liste(Liste2, mit:AnzahlRed, mal:Wert), Liste = [Wert|Liste2].

So kann man jetzt die Abfrage sprechend formulieren:

?- fuelle_liste(Liste, mit:4, mal:a).

Liefert „[a, a, a, a]„. Hier sieht man außerdem eine Besonderheit von Prolog. Wenn man Berechnungen durchführt, darf man diese nicht mit = auf eine Variable zuweisen. Stattdessen muss man is verwenden. Das Ausrufezeichen ! ist übrigens der Cut-Operator. Aber um den kümmern wir uns später.

Noch eine Schmankerl zum Schluss: Regeln die immer „true“ liefern, unterscheiden sich nicht von Fakten, so dass wir die Regel „liste“ noch etwas kürzer schreiben können:

liste([H,T], H, T).


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-4-pattern-matching/feed/ 0 SR http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-3-listen/ http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-3-listen/#comments Mon, 20 Jul 2009 17:12:10 +0000 stefanroock http://stefanroock.wordpress.com/?p=662 ]]> Eine Liste schreibt man in Prolog kommasepariert und umgeben von eckigen Klammern auf: [a,b,c] definiert eine Liste aus dem Symbolen a, b und c. Mit dem Pipezeichen | kann man eine Liste zerlegen – in das erste Element und den Rest. Man kann z.B. schreiben:

liste(EineListe, H, T) :- [H|T] = EineListe.

H und T sind in Prolog übliche Variablennamen, wenn es um das Aufsplitten von Listen geht. H steht für „Head“ und T für „Tail“. Die Regel „liste“ können wir vielfälig verwenden:

?- liste([a,b,c], H, T).

liefert „H=a, T=[b,c]„.

Wir können so auch feststellen, wie eine Liste aufgesplittet wird, die nur ein Element hat

?- liste([a], H, T).

liefert „H=a, T=[]„. Eine einelementige Liste besteht also aus dem Element und der leeren Liste.

Und wie sieht es mit der leeren Liste aus?

?- liste([], H, T).

liefert „false“. Die leere Liste lässt sich nicht weiter aufsplitten. Damit lässt sich die Regel nicht erfolgreich anwenden und das quittiert das Prolog-System mit „false“.

Wie wir schon im ersten Blogeintrag gesehen haben, kann man viele Regeln auch umgekehrt anwenden. Mit der Regel „liste“ können wir nicht nur Listen zerlegen, wir können auch Listen damit zusammenbauen.

?- liste(L, a, [b,c]).

liefert „L=[a,b,c]„.


Tagged: Prolog ]]> http://stefanroock.wordpress.com/2009/07/20/prolog-grundzuge-3-listen/feed/ 1 SR