Gerrit Beine http://gerritbeine.com Software-Architektur & Agile Methoden Sat, 20 Dec 2014 18:43:18 +0000 de-DE hourly 1 Apple SuperDrive am USB-Hub http://gerritbeine.com/blog/2014/12/20/apple-superdrive-am-usb-hub/ http://gerritbeine.com/blog/2014/12/20/apple-superdrive-am-usb-hub/#comments Sat, 20 Dec 2014 18:43:18 +0000 http://gerritbeine.com/?p=1146 Weiterlesen ]]> Apple empfiehlt das SuperDrive nur an USB-Ports direkt am Mac zu betreiben.
Nun stellt selbst das MacBook Pro leider nur zwei USB-Ports zur Verfügung, was das Ganze ziemlich lästig macht.

Hängt man das Laufwerk an einen USB-Hub, erhält man die lapidare Meldung, dass dieses Gerät mehr Strom benötigt. Dabei gibt es durchaus USB-Hubs, die genügend Strom für das SuperDrive bereitstellen.

Damit OS X das SuperDrive an so einem USB-Hub akzeptiert, muss man den Kernel wie folgt motivieren.

Als root muss man die Boot-Parameter editieren:

vi /Library/Preferences/SystemConfiguration/com.apple.Boot.plist

In der Datei ergänz man dann mbasd=1, so dass sie folgendermaßen ausschaut:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Kernel Flags</key>
        <string>mbasd=1</string>
</dict>
</plist>

Jetzt noch ein Neustart, und das SuperDrive läuft am USB-Hub.

Achtung: Wenn der USB-Hub tatsächlich zu wenig Strom zur Verfügung stellt, kann es zu Datenfehlern kommen. Ein USB-Hub, der auf zwei Power-Ports ausreichend Strom liefert, ist der DUB-H7 von D-Link.

Referenz: How to Run a SuperDrive on a Targus Hub

]]>
http://gerritbeine.com/blog/2014/12/20/apple-superdrive-am-usb-hub/feed/ 0
Vertraue der Macht – Schätzen ohne Bezugssystem http://gerritbeine.com/blog/2014/10/31/vertraue-der-macht-schaetzen-ohne-bezugssystem/ http://gerritbeine.com/blog/2014/10/31/vertraue-der-macht-schaetzen-ohne-bezugssystem/#comments Fri, 31 Oct 2014 13:27:04 +0000 http://gerritbeine.com/?p=1105 Weiterlesen ]]> Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.

Eine Methode, die genau das möglich macht und sich bei der initialen Schätzung von Backlogs schon oft bewährt hat, ist die Magic Estimation. Ich kenne etliche verschiedene Ausprägungen, wie eine Magic Estimation im Detail ablaufen kann.

Für die oben beschriebene Situation empfehle ich in der Regel folgenden Ablauf: Aus dem Backlog werden Items ausgewählt, auf Karten geschrieben und an die Teammitglieder verteilt, so dass jedes Teammitglied zwei bis vier Karten erhält. Die gewählten Backlog Items werden dann im Team und mit dem Product Owner diskutiert. Das geschieht in einer festen Timebox. Empfehlenswert ist, maximal eine Stunde dafür aufzuwenden. Nachdem die Items diskutiert wurden, beginnt die eigentliche Schätzung. Dafür wird ein langer Tisch benötigt, dessen gegenüberliegende Seiten mit „Klein“ und „Groß“ beschriftet werden.

Während der Schätzung darf nicht gesprochen werden. Die Teammitglieder dürfen in jeder Iterator zwei Backlog Items auf dem Tisch bewegen. Eine Bewegung ist das Hinlegen eines neuen Items oder das Verschieben eines Items, das schon auf dem Tisch liegt. Die Items sollen anhand ihrer Größe verglichen werden, gleich große Items werden untereinander gelegt, verschieden große Items nebeneinander. Die Orientierung dafür geben die Seiten des Tisches. Die Teammitglieder treten nacheinander an den Tisch heran, so lange, bis entweder die Timebox aufgebraucht ist oder sich das Bild auf dem Tisch stabilisiert. Das dauert meist nicht länger als eine halbe Stunde.

Auf dem Tisch haben sich nach Ablauf der Timebox in der Regel fünf Cluster ähnlich großer Backlog Items gebildet, mal einer mehr, mal einer weniger. Diesen Cluster werden nun von „Klein“ nach „Groß“ Story Points zugewiesen. Der Cluster, der am weitesten bei „Klein“ liegt, bekommt die Karte mit der 1 und alle folgenden Cluster die nächsthöhere Karte.

Die große Frage ist: Warum funktioniert das und wie zuverlässig ist diese Schätzung?
Die Antwort besteht aus mehreren Aspekten. Diese Schätzung funktioniert, weil sie auf einer Fähigkeit basiert, die Menschen sehr gut beherrschen, nämlich dem Vergleichen. Sie ist valide, weil die Story Points eine abstrakte Einheit sind, die erst durch die Velocity des Teams in eine Planungsgröße konvertierbar wird. Und sie ist zuverlässig, weil sie auf dem Intelligenz des Schwarms basiert. Die Backlog Items werden diskutiert, aber nicht, wie häufig beim Planning Poker, en detail zerredet.

Als Nebeneffekt entsteht durch die Magic Estimation eine Eichung der Größe von Backlog Items in Story Points für alle Größenordnungen – und diese ist wesentlich besser als Grundlage für Planning Poker Sessions geeignet, als die berühmte einzelne Referenz-Story. Das Team hat durch die Magic Estimation ein ganzes Set von Referenz-Items geschaffen, an denen sich zukünftige Schätzrunden orientieren können.

]]>
http://gerritbeine.com/blog/2014/10/31/vertraue-der-macht-schaetzen-ohne-bezugssystem/feed/ 0
Mein privates Git Cheat Sheet http://gerritbeine.com/blog/2014/09/13/mein-privates-git-cheat-sheet/ http://gerritbeine.com/blog/2014/09/13/mein-privates-git-cheat-sheet/#comments Sat, 13 Sep 2014 09:22:06 +0000 http://gerritbeine.com/?p=1127 Weiterlesen ]]> Da ich in verschiedensten Projekten regelmäßig mit Git arbeite, habe ich mir überlegt, die wichtigsten Szenarien, denen ich begegne, in einem privaten Cheat Sheet zusammenzufassen.

Ich weiß, dass ich der Welt damit nichts Neues offenbare, aber es ist praktisch, das alles mal an einem Ort versammelt zu haben.

Aktualisieren von Upstream-Repositories

Ich arbeite häufig mit Upstream-Repositories, von denen ich aus irgend einem Grund einmal einen Clone erstellt habe. Damit ich bei diesem Repositories auf dem Laufenden bleibe, füge ich sie meiner lokalen Arbeitskopie als Remote-Repository hinzu.

Ein Beispiel dafür ist mein Fork von Homebrew auf GitHub. Damit dieser nicht zu weit hinter dem offiziellen Homebrew-Repository läuft, aktualisiere ich ihn regelmäßig. Dazu habe ich auf meinem lokalen Clone (origin ist git@github.com:gbeine/homebrew.git) das Homebrew-Repository hinzugefügt:

git remote add upstream https://github.com/Homebrew/homebrew.git

Jetzt kann ich mein Fork Repository mit vier einfachen Schritten auf den aktuellen Stand des offiziellen Homebrew-Repositories bringen:

  1. Die Daten von Remote Repository holen:
    git fetch upstream
  2. Auf den master wechseln (ich arbeite hier normalerweise mit Branches):
    git checkout master
  3. Den master auf den Stand des upstream aktualisieren:
    git rebase upstream/master
  4. Den aktualisierten master auf origin veröffentlichen:
    git push origin master

Damit sind alle Änderungen aus dem offiziellen Repository in meinen Fork übernommen worden.

Mergen von Upstream-Repositories

Das zuerst beschriebene Szenario funktioniert gut, so lange man keine Änderungen auf dem master macht, die man veröffentlichen möchte. Macht man solche Änderungen, muss man entweder auf einen anderen Branch ausweichen oder die folgenden Schritte verwenden.

Als Beispiel dafür verwende ich meinen Fork des MediaWiki-Repositories. Auf GitHub habe ich einen Fork von https://github.com/wikimedia/mediawiki-core.git erstellt und einen lokalen Clone erzeugt. origin ist git@github.com:gbeine/MediaWiki.git.

Ich habe Änderungen auf dem master meines Clones gemacht und auch veröffentlicht. Dennoch möchte ich meine private Version von MediaWiki auf dem aktuellen Stand des offiziellen Repositories halten. Das geht ebenfalls mit einem Upstream-Repository und einem zusätzlichen Branch.

Zunächst muss ich wieder das offizielle Remote-Repository hinzufügen:

git remote add upstream https://github.com/wikimedia/mediawiki-core.git

Jetzt kann ich meinen master mit den folgenden Schritten auf den aktuellen Stand bringen:

  1. Die aktuellen Daten von Upstream-Repository holen:
    git fetch upstream
  2. Auf den Branch für upstream wechseln (-B benötigt man nur beim ersten Mal):
    git checkout -B upstream
  3. Den upstream aktualisieren:
    git merge upstream/master
  4. Optional, aber sinnvoll: den Branch upstream veröffentlichen:
    git push -f origin upstream
  5. Auf den master wechseln:
    git checkout master
  6. Vom Branch upstream auf den master mergen:
    git merge --no-ff upstream
  7. Den master veröffentlichen:
    git push origin master

Sofern man noch keine Änderungen auf dem master gemacht hat, kann man beim Schritt drei auch git rebase upstream/master verwenden. Das ist auf jeden Fall der beste Weg! Zur Not geht man für den upstream-Branch einige Commits zurück.

Wichtig ist, dass man beim Aktualisieren des master keinen Fast-Forward-Merge durchführt. Deshalb habe ich Fast-Forward-Merges für meinen master abgeschalten:

git config branch.master.mergeoptions "--no-ff"

Löschen von Branches

Die Möglichkeit, Branches zu löschen, benötige ich ebenfalls wegen meiner Homebrew-Aktivitäten. Das Löschen von Branches ist mit Git denkbar einfach.

  1. Remote Branch löschen:
    git push origin :mybranch
  2. Lokalen Branch löschen:
    git branch -d mybranch

Branches verfolgen

Einen lokalen Branch an einen bestimmten remote Branch zu binden, ist kein Problem:

git branch -u upstream/remote_branch local_branch

Branches veröffentlichen

Neue Branches lassen sich sehr einfach veröffentlichen:

git push git@github.com:gbeine/homebrew.git newbranch

Upstream mit Subversion

Das oben beschriebene Konzept der Upstream Branches lässt sich natürlich auch mit Subversion-Repositories anwenden. Wenn das Subversion-Repository der Upstream sein soll, funktioniert das wie folgt:

  1. Clonen des Git-Repositories als origin:
    git clone "git-url"
  2. Auf upstream Branch wechseln:
    git checkout -B upstream
  3. Verbinden mit Subversion-Repository als upstream:
    git svn init —prefix upstream/ -s "svn-url"`
  4. Daten von Subversion holen:
    git svn fetch
  5. Den upstream auf den aktuellen Stand bringen:
    git svn rebase
  6. Den upstream Branch veröffentlichen:
    git push origin upstream
  7. Zum master Branch wechseln:
    git checkout master
  8. Die Änderungen aus Subversion übernehmen:
    git merge --no-ff upstream
  9. Den master Branch veröffentlichen:
    git push origin master

Jetzt kann man wie oben beschrieben, Änderungen von Subversion nach Git mergen. Die Aktualisierungen aus Subversion zieht man immer in den upstream Branch und kann diesen auch im Remote Git-Repository veröffentlichen.

Löschen von Commits

Es passiert mir manchmal, dass ich etwas committe, das ich dann doch nicht so haben will. Dann muss der letzte Commit wieder gelöscht werden. Das geht mit diesem Kommando:

git reset —soft HEAD~1

Quellen

Da das alles nur gut geklaut ist, hier die URLs der Seiten, die mich inspiriert und illuminiert haben:

]]>
http://gerritbeine.com/blog/2014/09/13/mein-privates-git-cheat-sheet/feed/ 0
Back to COBOL – natürlich mit Unit Tests http://gerritbeine.com/blog/2014/09/08/back-to-cobol-natuerlich-mit-unit-tests/ http://gerritbeine.com/blog/2014/09/08/back-to-cobol-natuerlich-mit-unit-tests/#comments Mon, 08 Sep 2014 21:08:37 +0000 http://gerritbeine.com/?p=1121 Weiterlesen ]]> Ich hätte nie gedacht, dass ich mich nach über 10 Jahren noch einmal mit COBOL beschäftigen würde. Aber nun habe ich ein Team, das mit COBOL arbeitet und Scrum machen soll.

Nun sind COBOL und Scrum zwei Dinge, die die meisten Menschen, die ich so kenne, nicht oft in einem Satz verwenden. Das soll aber kein Grund sein, sich nicht mit der Materie zu beschäftigen. Letztes Wochenende habe ich OpenCOBOL – neuerdings GNU-Cobol – via homebrew auf dem Mac verfügbar gemacht.

Das war aber nur der erste Schritt, denn mein eigentliches Ziel war die Grundvoraussetzung für agile Software-Entwicklung mit COBOL zu nutzen. Na? Genau: Unit Tests! Mit CobolUnit gibt es dafür auch ein Framework, das aber schon seit einer Weile nicht maintained wird. Die letzten Commits sind von 2009, das versprach ein Abenteuer.
Und das wurde es dann auch. Ich habe mich von Fehlermeldungen wie
error: indirect goto in function with no address-of-label expressions
zu
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/Users/gbeine/GitHub/gbeine/COBOLUnit/COBOLUnitLib/lib/libCobolUnit.dylib' for architecture x86_64
durchgearbeitet.

Am Ende ist es mir gelungen, CobolUnit mit GNU-Cobol in der Version 1.1 und dem GCC 4.9.1 zum Laufen zu bringen. Das Resultat schaut recht erfreulich aus:

|--- Suite1
| Test 'CTU0S1T1 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
| Test 'CTU0S1T2 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

|--- Suite2
| Test 'CTU0S2T1 * SUCCESS * (008 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

********************************************************************
* SUCCESS *
* (003 test cases, 003 success, 000 failures, 000 errors) *
********************************************************************
(00 min:00 sec:01 ms)

Meine Änderungen dazu habe ich – natürlich – auf GitHub zur Verfügung gestellt. Nur für den Fall, dass das außer mir noch irgendwo auf der Welt irgendjemand nutzen möchte…

]]>
http://gerritbeine.com/blog/2014/09/08/back-to-cobol-natuerlich-mit-unit-tests/feed/ 0
Einheit Story Points? http://gerritbeine.com/blog/2014/08/04/einheit-story-points/ http://gerritbeine.com/blog/2014/08/04/einheit-story-points/#comments Mon, 04 Aug 2014 09:20:23 +0000 http://gerritbeine.com/?p=1076 Weiterlesen ]]> Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.

In der Diskussion auf der Agile World kam die Aussage auf, Story Points wären eine einheitenlose Größe (Quantity). Das kann nicht korrekt sein, denn Story Points beschreiben lediglich die Größe (Size) von Backlog Items. Das könnte man auch mit T-Shirt Sizes oder anderen abstrakten Mechanismen erreichen. Tatsächlich kann man sogar eine Umrechnung von Story Points in T-Shirt-Sizes definieren. Demzufolge können Story Points keine Größe (Quantity) sein. Und tatsächlich sind Story Points keine quantifizierende Eigenschaft von Backlog Items, sondern nur die Maßeinheit des Wert einer solchen Größe (Quantity), nämlich der Größe (Size) des Backlog Items. Die Größe (Size) des Backlog Items ist – nach Mike Cohn – eine Funktion f(Aufwand, Risiko, Unsicherheit) und mit einer gewissen statistischen Unsicherheit – die aus Risiko, Unsicherheit und Schätzfehlern resultiert – in Aufwand umrechenbar ist.

Bestätigt wird das auch durch den üblichen Sprachgebrauch. Mir ist noch niemand begegnet, der von den Story Points seines Backlogs als Eigenschaft gesprochen hätte. Man spricht immer nur von der Größe des Backlogs in Story Points. Oder T-Shirt Sizes. Oder Schokostreuseln.

Der Trugschluss, Story Points seien keine Einheit, kommt meiner Meinung nach daher, dass man vermeiden möchte, auf eine feste Formel festgenagelt zu werden, mit der man Story Points in Aufwand umrechnen soll. Ich kann mir gut vorstellen, dass es Leute gibt, die solche Dinge verlangen. Dass es nur mit statistischer Varianz möglich ist, zeigt Mike Cohn in dem oben zitierten Artikel. Und dass man es nicht benötigt, weil man auch ohne Umrechnung zu den Aussagen kommt, die relevant sind, wird von Henrik Kniberg in seinem Product Owner in a Nutshell erklärt.

]]>
http://gerritbeine.com/blog/2014/08/04/einheit-story-points/feed/ 0
“Ich will mein Vetorecht!” – Über Vertrauen in agilen Projekten http://gerritbeine.com/blog/2014/07/31/ich-will-mein-vetorecht-ueber-vertrauen-in-agilen-projekten/ http://gerritbeine.com/blog/2014/07/31/ich-will-mein-vetorecht-ueber-vertrauen-in-agilen-projekten/#comments Thu, 31 Jul 2014 13:04:40 +0000 http://gerritbeine.com/?p=1100 Weiterlesen ]]> Agile Vorgehensweisen benötigen Vertrauen. Dieses Vertrauen muss innerhalb des Teams entstehen, es muss zwischen dem Auftraggeber und dem Team entstehen – und es muss zwischen Führungskräften und dem Team entstehen.

Wenn ich Teams begleite, entsteht das Vertrauen innerhalb des Teams häufig sehr schnell und stabilisiert sich. Gelingt es einem Team, früh Resultate zu zeigen, wird es zumeist mit dem Vertrauen des Auftraggebers belohnt. Dieses Vertrauen wächst mit der Kontinuität, in der das Team wertvolle Software liefert.

In Workshops zu Einführung agiler Softwareentwicklung gehe ich immer auf dieses notwendige Vertrauen ein. Ich spreche es gegenüber dem Team an, gegenüber den Kunden – sofern diese teilnehmen – und natürlich gegenüber den Führungskräften. Mit letzteren erlebe ich allerdings sehr oft etwas, das mich immer auf’s Neue zum Nachdenken bringt.

Natürlich wollen Führungskräfte, dass sich ihre Teams gut fühlen. Das lernt man heute selbst in den ganz schlechten Leadership-Seminaren. Die Führungskräfte finden es auch logisch, dass man dem Team vertrauen muss, damit es eine agile Arbeitsweise entwickeln kann. Und dann, wenn das Commitment der Führungskraft zur Agilität schon fast erreicht scheint, kommt der entscheidende Satz: „Ich möchte mir aber bei allen Entscheidungen ein Vetorecht vorbehalten.“

Die anderen Teilnehmer in den Workshops verdrehen in dem Moment zumeist die Augen, stöhnen oder machen sich im Nachhinein über das Vetorecht lustig. Das ist aber noch die harmlosere Auswirkung dieser Aussage.

Die nicht so harmlose Wirkung dieser Aussage ist eine ganz andere, geht viel tiefer und stört den Beginn der agilen Arbeitsweise massiv: Die Führungskraft bringt mit dem Verlangen nach einem Vetorecht zum Ausdruck, dass sie dem Team nicht vertraut. Und schlimmer noch, sie bringt damit zum Ausdruck, dass sie sich selbst nicht für fähig hält, ein agiles Team zu führen.

Natürlich geschieht das nicht bewusst. Bewusst ist nur die Idee, dass man als Führungskraft ja die letztendlichen Entscheidungen treffen muss. Immerhin trägt man ja auch die Verantwortung. Aus diesem Gedanken heraus entsteht der Wunsch, Entscheidungen des Teams revidieren zu können, sollten sie sich als falsch herausstellen. Dieser Wunsch ist völlig legitim, benötigt aber kein Vetorecht. Wenn das Team eine falsche Entscheidung trifft, merkt es das Team schneller als die Führungskraft und wird die Entscheidung korrigieren. Als Führungskraft muss ich diesen Erkenntnisprozess nur ermöglichen. Mit einem Vetorecht behindere ich ihn, weil ich dem Team den Mut nehme, potentiell falsche Entscheidungen zu treffen. Zusätzlich stelle ich meine Kompetenz über die des Teams, gehe also implizit davon aus, die Konsequenzen der Entscheidungen des Teams besser beurteilen zu können als das Team selbst. Ich kenne keine Führungskraft, die das wirklich leisten kann, denn auch Führungskräfte sind nur Menschen und als Individuen notwendigerweise nur begrenzt intelligent.

Glück haben all jene Führungskräfte, die ihr Vetorecht nie ausüben müssen. Sei es, weil das Team nicht den Mut hat, Entscheidungen zu treffen oder sei es, weil das Team zufälligerweise immer die richtigen Entscheidungen trifft. Wirklich schlimm ist aber, was passiert wenn eine Führungskraft ihr Vetorecht tatsächlich ausüben muss. Dann erklärt sie nämlich, ihrer eigentlichen Aufgabe nicht gerecht geworden zu sein. Sie hat es nicht geschafft, ihr Team zu einer guten Entscheidung zu führen. Genau das ist aber Aufgabe einer Führungskraft.

Das Vetorecht von Führungskräften wird von Mitarbeitern auch in agilen Teams normalerweise nicht in Frage gestellt. Es aber für sich einzufordern führt auf einen falschen Pfad. Stattdessen sollten sich Führungskräfte in agilen Projekten damit auseinandersetzen, wie sie ihren Teams die Ziele der Organisation klar vermitteln und einen Raum schaffen können, der es Teams ermöglicht, zu richtigen und guten Entscheidungen zu finden.

]]>
http://gerritbeine.com/blog/2014/07/31/ich-will-mein-vetorecht-ueber-vertrauen-in-agilen-projekten/feed/ 0
User Stories der Größe 1 http://gerritbeine.com/blog/2014/07/24/user-stories-der-groesse-1/ http://gerritbeine.com/blog/2014/07/24/user-stories-der-groesse-1/#comments Thu, 24 Jul 2014 16:33:07 +0000 http://gerritbeine.com/?p=1065 Weiterlesen ]]> Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.

Abgesehen davon widerspicht eine solche Aussage massiv dem agilen Manifest. Dort heißt es nämlich: Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Und das Festlegen darauf, dass alle User Stories die Größe 1 haben sollen ist nichts anderes als Befolgen eines Plan. Pläne haben aber einen massiven Nachteil, wenn sie mit der Realität konfrontiert werden: Es kann sein, dass die Realität anders funktioniert, als der Plan vorsieht. Gerade bei Softwareentwicklung machen wir diese Erfahrung immer wieder. Was macht man dann mit einer Story die doppelt so groß ist? Ablehnen? Zerschneiden, auch wenn die einzelnen Stories dann keinen Business Value mehr beinhalten? Als Pragmatiker nehme ich in so einem Fall einfach eine Story der Größe 2 ins Backlog. Das klappte bisher immer hervorragend ;-)

Ein weiterer Grund für meine Ablehnung solcher Aussagen ist, dass sie auf dem Confirmation Bias beruhen. Jemand, der so eine absolute Aussage trifft, hat in der Regel in einem bestimmten fachlichen Kontext die Erfahrung gemacht, dass sein Ansatz funktioniert. Daraus schließt er, dass dieser Ansatz valide ist – was für diesen Kontext auch zutrifft – und läuft los, um Bestätigung zu suchen. Und hier schlägt der Confirmation Bias zu. Menschen neigen dazu, nur bestätigende Informationen aufzunehmen, wenn sie von etwas überzeugt sind. Ein korrektes Vorgehen wäre es, nach Beispielen zu suchen, die eine solche Aussage widerlegen, denn sie ist von Natur aus nicht beweisbar.

Natürlich bin ich ein Verfechter möglichst kleiner User Stories. Kleine User Stories reduzierten das Risiko für eine Fehlentwicklung, sind leichter zu schätzen und ermöglichen einen höheren Fluss bei kleinerem Work In Progress. Nichtsdestotrotz sollten User Stories so beschaffen sein, dass sie Business Value in die Software bringen und keinen toten Code hinterlassen. Ich habe die Erfahrung gemacht, dass folgende Daumenregel sehr gut funktioniert: User Stories sollten kleiner sein, als die Hälfte der Velocity. Aber auch dafür gibt es Ausnahmen, so ist das Leben.

Im ditten Teil meiner Nachbrenner zur Agile World geht es dann um die Frage zur Einheit von Schätzgrößen.

]]>
http://gerritbeine.com/blog/2014/07/24/user-stories-der-groesse-1/feed/ 0
Antifragilität und Software-Architektur http://gerritbeine.com/blog/2014/07/24/antifragilitaet-und-software-architektur/ http://gerritbeine.com/blog/2014/07/24/antifragilitaet-und-software-architektur/#comments Wed, 23 Jul 2014 22:32:52 +0000 http://gerritbeine.com/?p=1083 Weiterlesen ]]> Ich bin ja seit längerem ein Anhänger von Nassim Nicholas Taleb. Seine Art, Risiken und Wahrscheinlichkeiten zu betrachten hat mich beeindruckt und geprägt. In meiner Arbeit als Agile Coach und Software-Architekt kann ich die Ideen zu Schwarzen Schwänen fast jeden Tag sinnvoll anwenden. Insofern wundert es mich nicht, dass Antifragilität als Konzept auch Einzug in die Welt der Softwarearchitektur hält.

Sein Buch Antifragilität führt als Untertitel “Eine Anleitung für eine Welt, die wir nicht verstehen”. Wenn man das Buch aufmerksam liest und auch mit dem Schwarzen Schwan und den Narren des Zufalls vertraut ist, versteht man aber schnell, dass dieses Buch keine Anleitung für die Welt ist. Es ist eine Anleitung, sich selbst Anleitungen zu erdenken. Also eine Meta-Anleitung.

Taleb definiert Antifragilität als das Gegenteil von Fragilität, als die Eigenschaft eines Etwas, im Falle des Eintritts eines Schwarzen Schwans, also eines unvorhersehbaren Ereignisses, besser zu werden. Üblicherweise werden Robustheit oder Resilienz als das Gegenteil von Fragilität betrachtet, aber beide gehen Taleb nicht weit genug, sorgen sie im besten Fall doch nur für die Erhaltung des Status Quo, wenn ein Schwarzer Schwan eintritt.

Russ Miles’ Idee, antifragile Software-Architekturen auf Microservices basieren zu lassen, wird in meinen Augen Talebs Ideen nicht gerecht. Was Taleb als Antifragilität beschreibt, ist eine Eigenschaft, die durch zwei Dinge ermöglicht wird: Zufall oder Lernen. Ein Beispiel für Antifragilität, die aus Zufall resultiert, ist die Natur. Taleb selbst verwendet dieses Beispiel in seinem Buch, um Antifragilität (Natur) von Resilienz (ein Wald) und Robustheit (ein einzelner Baum) zu unterscheiden. Antifragilität, die aus Lernen resultiert, lässt sich nicht so leicht in Metaphern kleiden und ist weniger offensichtlich.

Um sie zu verstehen, muss man zunächst die 5 Orders of Ignorance von Phillip G. Armour verstehen. Johann-Peter Hartmann hat sie in seinem Talk über Management Brainfucks sehr gut in deutscher Sprache zusammengefasst:
(0OI) Lack of Ignorance: Ich weiß etwas
(1OI) Lack of Knowledge: Ich weiß etwas bestimmtes nicht.
(2OI) Lack of Awareness: Ich weiß nicht, was ich nicht weiß.
(3OI) Lack of Process: Ich weiß nicht, wie ich herausfinde, was ich nicht weiß.
(4OI) Meta Ignorance: Ich weiß nicht, dass es unterschiedliche Arten von Nichtwissen gibt.

Antifragilität durch Lernen bedingt, dass man um die Existenz der Meta Ignoranz weiß. Nur dann kann man sich mit der Ignoranz zweiter und dritter Ordnung beschäftigen. Diese beiden Stufen des Nichtwissens sind nämlich genau die, denen ein Schwarzer Schwan zu verdanken ist. Dinge, die ich weiß oder Dinge, von denen ich weiß, dass ich sie nicht weiß, sind harmlos, denn sie können mich nicht überraschen. Es ist möglich, sich auf sie vorzubereiten – also entweder die Fähigkeit zur Robustheit oder zur Resilienz in Bezug auf sie zu entwickeln.

Genau in diese Kategorie fallen alle Konzepte von Software-Architekturen, wie z.B. Komponentenbasierte Architekturen, Serviceorientierte Architektur und auch Paradigmen wie Verteilung, ReST, BigData – und eben die Microservices. (Hint: Als alter Unixer sind die für mich absolut nichts Neues – SCNR)

Was ich an Russ Miles’ Ideen kritisiere, ist die Verbindung von Antifragilität mit einem konkreten Architekturkonzept. Keine Architektur, die wir als Softwerker heute umsetzen können, bewahrt uns von Schwarzen Schwänen oder wird bei ihrem Eintreten besser. Das kann Software-Architektur heute nicht leisten und das wird sie auch in Zukunft nicht leisten können. Denn die Software-Architektur selbst kann nur die Ignoranz nullter und im besten Fall erster Ordnung adressieren.

Um Antifragilität in die Software-Achitektur zu bringen, darf man sich nicht auf die Technik, Konzepte oder Paradigmen konzentrieren. Diese sind per se nicht Antifragil, da sie sich weder zufällig weiterentwickeln noch selbst lernen können. Man muss sich also auf die Menschen konzentrieren, die solche Architekturen konstruieren. Diese Menschen, wir Software-Architekten, können lernen und erfüllen somit eine der Vorbedingungen für Antifragilität. Und was wir lernen müssen, um Software-Achitektur antifragil zu machen, zeigen die zweite und dritte Stufe des Nichtwissen. Wir müssen lernen, mit Dingen umzugehen, von deren Existenz man nichts weiß und wir müssen lernen, solche Dinge systematisch zu erkennen.

Dieses systematische Erkennen geht mit etwas einher, das in der Welt der Software-Entwicklung nur ungern akzeptiert wird: der Akzeptanz des Unvorhersehbaren, des nicht Planbaren, jenen Dingen, die Software-Entwicklung vermeintlich kompliziert und teuer machen. Diese Akzeptanz ist aber notwendig, um Antifragilität in die Welt der Software-Architektur zu bringen. Es ist unabdingbar, die Existenz von Ignoranz zweiter und dritter Ordnung akzeptieren und damit auch die Unmöglichkeit, Architekturen, ja noch nicht einmal Meta-Architekturen, zu konstruieren, die per se antifragil sind. Antifragile Software-Architektur bedeutet bewussten Umgang mit Nichtwissen und Akzeptanz von Emergenz durch den Software-Architekten.

Antifragilität, die Verbesserung durch den Eintritt eines Schwarzen Schwans, ist dann nicht mehr eine Eigenschaft der Architektur, sondern vielmehr des Architekten.

]]>
http://gerritbeine.com/blog/2014/07/24/antifragilitaet-und-software-architektur/feed/ 0
Schätzereien http://gerritbeine.com/blog/2014/07/03/schaetzereien/ http://gerritbeine.com/blog/2014/07/03/schaetzereien/#comments Thu, 03 Jul 2014 21:30:50 +0000 http://gerritbeine.com/?p=1062 Weiterlesen ]]> Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.

Vorab muss ich sagen, dass ich zum Thema Schätzen keine absolute Meinung vertrete. Ich habe in Projekten gearbeitet, in denen Schätzungen hervorragend funktionierten, ebenso wie ich bereits in Projekten unterwegs war, die ohne Schätzungen sehr gut zurecht gekommen sind.
Gut gefahren bin ich bisher mit der Daumenregel, dass im Product Backlog geschätzte Elemente enthalten sein sollten, im Sprint Backlog nicht. Möchte ein Team das Sprint Backlog schätzen, finde ich das aber auch ok. Das Team muss sich gut damit fühlen und solange die Schätzung die Koordinationskosten nicht extrem in die Höhe treibt, kann ich damit leben.

Ist Schätzen sinnvoll?

Wenn ich als Product Owner unterwegs bin, brauche ich Schätzungen. Wozu, hat Henrik Kniberg in seinem Video Product Owner in a Nutshell hervorragend erklärt. Ohne Schätzungen kann ein Product Owner keinen Forecast machen. Der Forecast ist aber wichtig, um Investoren ein gutes Gefühl zu geben.
Wenn ich Investor bin und mein Geld in ein Softwareprojekt stecke, möchte ich wissen, wann – nach welcher Menge investierten Geldes – ich mit einem Ergebnis rechnen kann. Das muss nicht beim ersten Sprint klappen, auch nicht beim zweiten. Aber wenn die ersten fünf Sprints ergebnislos bleiben, werde ich mich einmischen. Das ist mein gutes Recht, es ist schließlich mein Geld.
Natürlich interessiert es mich als Investor nicht, wie viele Stunden für welches Feature investiert werden. Aber nach fünf Sprints möchte ich vom Product Owner wissen, wie die Velocity des Teams ist und wie die Items im Backlog geschätzt sind. Nur so kann ich entscheiden, ob das Projekt die Investition wert ist oder nicht.
Das vergessen viele vermeintliche Agilisten leider viel zu häufig. Dabei steht genau das im ersten der zwölf Prinzipien des Agilen Manifest:

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Das wichtige Wort dabei ist wertvoll. Die Frage, wann eine Software wertvoll ist, hängt für einen Investor – neben vielen anderen Dingen – eben auch vom Aufwand ab, der bezahlt werden muss.

Für Investoren – und damit auch den Product Owner – ist Schätzen also durchaus sinnvoll. Das Team zieht keinen unmittelbaren Nutzen aus einer Schätzung. Deshalb sollte auch nicht das Team entscheiden, ob geschätzt wird oder nicht. Es darf aber darauf bestehen, dass die Schätzung auch als solche betrachtet wird und keine Garantie ist.

Im nächsten Eintrag werde ich auf User Stories der Größe 1 eingehen.

]]>
http://gerritbeine.com/blog/2014/07/03/schaetzereien/feed/ 0
David J. Anderson: Kanban http://gerritbeine.com/blog/2014/06/28/david-j-anderson-kanban/ http://gerritbeine.com/blog/2014/06/28/david-j-anderson-kanban/#comments Sat, 28 Jun 2014 11:52:33 +0000 http://gerritbeine.com/?p=1053 Weiterlesen ]]>
David J. Anderson: Kanban

David J. Anderson: Kanban

Andersons Kanban-Buch kann man als Meilenstein des Change Managements im IT-Bereich betrachten.
Nicht nur, dass es Anderson gelang, mit Kanban eine konsequente Übertragung der Prinzipien des Lean Manufacturing auf den Bereich der Softwareentwicklung zu übertragen. Vielmehr hat er es geschafft, darüber hinaus die Einführung solcher Prinzipien methodisch so aufzubereiten, dass es Managern möglich wird, die notwendigen Veränderungen systematisch durchzuführen.

Das Buch ist in vier Teile gegliedert.
Zunächst wird dem Leser das Dilemma des agilen Managers, nämlich die Suche nach einer konstanten Arbeitsgeschwindigkeit und die grundlegende Funktionsweise eines Kanban-Systems nahegebracht. Im zweiten Teil erläutert Anderson die fünf Schritte, die eine Einführung von Kanban ermöglichen und erklärt anhand von Beispielen aus seiner Management-Praxis, wie sie umgesetzt werden können. Abgeschlossen wird der zweite Teil des Buches mit einer Betrachtung von Kaizen-Kultur.
Im dritten Teil geht es dann mit den praktischen Fragestellungen richtig los. Visualisieren der Prozesse, Einsatz von Kanban zur Koordination, Lieferrhythmen und Work-in-Progress-Limits, um ein paar Stichworte zu nennen. Natürlich geht Anderson auch auf Reporting, Metriken zum Monitoring des Fortschritts und des Reifegrades der Kanban-Implementierung und auf das Thema Skalierung ein. Extrem positiv fallen die vielen verschiedenen Szenarien auf, anhand derer Anderson seine Ideen erklärt.
Der vierte Teil beschäftigt sich mit Problemen, die sich auf die kontinuierliche Verbesserung des Kanban beziehen, wie Variabilität bei den Aufgaben und begrenzt verfügbaren Ressourcen. Abgeschlossen wird das Buch durch den Kanban-Einführungsbericht eines Unternehmens.

Was mir nicht gefallen hat, war Andersons Bashing von Daily Standup Meetings. Hier gehen unsere Meinungen weit auseinander, insbesondere, weil das Standup Koordinationsaufwände transparent macht – etwas, das Anderson immer wieder als wichtig beschreibt. Die deutsche Übersetzung ist an einigen Stellen holprig, referenziert zum Teil völlig anders beschriftete Abbildungen und – das hätte ich bei einem korrigierten Nachdruck nicht erwartet – strotzt nur so vor Rechtschreibfehlern.

Fazit: Das Buch gehört zu den Must-Reads für Agilisten, denn viele Konzepte aus der Welt des Lean können auch in Scrum und Extreme Programming erfolgreich angewandt werden.

]]>
http://gerritbeine.com/blog/2014/06/28/david-j-anderson-kanban/feed/ 0