Feeds:
Beiträge
Kommentare

Software wird aus Elementen zusammengesetzt, die in Beziehungen stehen. Die Gesamtheit von Elementen und Beziehungen stellt eine Software-Architektur dar. Ich kann zu jedem Software-System eine Architektur vorgeben und die aktuelle Architektur feststellen. Die Differenz davon sind dann Architekturverletzungen. Gebe ich Regeln vor, wie die Elemente und Verknüpfungen eingesetzt werden sollen, kann ich eine Referenzarchitektur bzw. einen Architekturstil definieren.

Zur Übersicht des Podcasts geht es hier: https://wolfgideonbleek.wordpress.com/podcast

Podcast direkt abonnieren: RSS iTunes

Direkter Link zu dieser Podcast-Folge.

Zum Lesen

http://de.wikipedia.org/wiki/Softwarearchitektur

http://de.wikipedia.org/wiki/Architekturmuster

https://de.wikipedia.org/wiki/Schichtenarchitektur

http://de.wikipedia.org/wiki/Domain-Driven_Design

http://de.wikipedia.org/wiki/Mustersprache

http://subs.emis.de/LNI/Proceedings/Proceedings109/gi-proc-109-059.pdf

https://www.fbi.h-da.de/fileadmin/personal/b.humm/Publikationen/Siedersleben_-_Quasar_1__sd_m_Brosch_re_.pdf

http://sourceforge.net/projects/openquasar/

Und als Schmankerl

http://denkspuren.blogspot.de/2007/03/was-ist-software-architektur.html

http://it-and-more.blogspot.de/search/label/architecture

http://de.wikipedia.org/wiki/Gottobjekt

Advertisements

Ich komme mit vielen agilen Projekten in Kontakt und stolpere immer darüber, wie agile User Stories geschätzt werden.

Mittlerweile ist ja von vielen akzeptiert, dass ein Schätzen in Komplexitätsklassen besser funktioniert als in konkreten Zeitaufwänden. Die Argumentation dazu spare ich mir an dieser Stelle. Ich gehe auch davon aus, dass die Fibonacci-Zahlen als Schätzmaß akzeptiert sind. Wir haben also 1, 2, 3, 5, 8 und 13 als Beginn und machen dann mit 20, 40 und 100 weiter.

Dabei hat es sich in meiner Praxis bewährt, dass die einstelligen Schätzzahlen gute Komplexitäten sind, um sie in einem Sprint zu bearbeiten. Das ist eine Konvention. Natürlich geht es auch anders, aber ich halte es so für sinnvoll. Die zweistelligen Komplexitäten sind zu groß, als dass sie in einen Sprint genommen werden könnten. Dabei spielt die 13 eine besondere Rolle. Sie sagt aus, dass es zwar ein sehr komplexes Problem ist, aber prinzipiell noch mit Anstrengung in den Sprint passen würde. Die Story ist aber ein direkter Kandidaten für das Aufteilen. Stories mit den Schätzungen 20, 40 oder 100 haben nur grobe Aussagen über ihre Komplexität und müssen deshalb genauer betrachtet werden.

Schaue ich mir die einstelligen Schätzzahlen genauer an, kann ich noch weitere Aussagen darüber treffen. So möchte ich z.B. beim kleinsten Schätzwert die Möglichkeit haben, die Story in möglichst einem Arbeitstag abzuschließen. Ich will viele Erfolgserlebnisse und deshalb brauche ich kurzfristig Rückkopplung, ob die Story passt (z.B. ob der Product Owner sie richtig umgesetzt findet). Auf die gleiche Weise schaue ich mir die 8-Punkte-Story an. Wenn ich 13 Punkte in Ausnahmefällen noch für einen Sprint akzeptiere, muss eine 13-Punkte-Story in einen Sprint passen. Das bedeutet aber, dass eine 8-Punkte-Story etwa die Hälfte eines Sprints einnehmen kann. Das passt auch mit meiner Anforderung, dass ich sie möglichst in einer Arbeitswoche erledigt haben will.

In der Sprintplanung muss ich dann eine Zusammenstellung finden, die mit der gegebenen Teamgröße und Faktoren wie Pairing und Testing zusammen passt. Ich will außerdem zum Sprintende eher kleine Stories vorliegen haben, damit ich nicht sehenden Auges eine Story beginne, die ich nicht beenden kann.

Am 24. September 2013 findet in Frankfurt im Maritim Hotel der BITKOM Software Summit statt. Ich halte dort zusammen mit Frank Simon einen Vortrag mit dem Titel „Agile Entwickler und überzeugte Tester: Das neue Traumpaar„.

Ich freue mich über alle Besucher und einen spannenden Tag. Die Teilnahme ist für BITKOM-Mitglieder kostenfrei!

 

 

Wir erstellen beim Schreiben von Software unterschiedliche Einheiten: z.B. Methoden, Klassen, Packages. In der neuen Folge des Podcasts “Softwaretechnik kompakt” beschäftige ich mich mit der Frage, welche Beziehungen zwischen diesen Einheiten möglich sind, was diese Beziehungen ausdrücken und welchen Regeln ich beim in-Beziehung-setzen folgen sollte.

Zur Übersicht des Podcasts geht es hier: https://wolfgideonbleek.wordpress.com/podcast

Podcast direkt abonnieren: RSS iTunes

Direkter Link zu dieser Podcast-Folge.

Zum Lesen

http://de.wikipedia.org/wiki/Vererbung_(Programmierung)

http://de.wikipedia.org/wiki/Gesetz_von_Demeter

http://c2.com/cgi/wiki?LawOfDemeter


Zum Ausprobieren

http://docs.codehaus.org/display/SONAR/

Und als Schmankerl

http://www.spinellis.gr/sw/ckjm/

Ich bin letztens auf diesen Artikel gestoßen: http://spoonique.de/2012/09/18/agiler-mythos-1-management-ist-uberflussig/

Ich habe eine ähnliche Erfahrung gemacht. Nur weil Bücher zu agilem Vorgehen erst einmal nichts zum Projektmanagement sagen, heißt dies nicht, dass es keines Projektmanagements bedarf. Dieses Missverständnis habe ich bei vielen meiner Kunden vorgefunden.

Weil in der Scrum-Literatur von der Selbstorganisation des Teams die Rede ist, wird dies häufig über-interpretiert zu der Feststellung, dass kein zusätzliches Projektmanagement notwendig sein. Das ist aber nicht der Fall. Eine andere Motivation für das Weglassen des Projektmanagers ist, dass der Product Owner ja für viele fachbezogene Fragestellung der Entscheider ist.

Welche Fragestellungen aus dem Projektmanagement werden den typischerweise nicht bearbeitet:

  • Risikomanagement: Ein Klassiker. Scrum-Teams sind häufig zu sehr auf die Sache fokussiert und lassen die sachliche und systematische Betrachtung von Projekt-Risiken aus.
  • Kommunikations-Management: Ein Projekt muss – gerade in größeren Unternehmen – seinen Stand, seine Abgrenzung, die Zusammenarbeit und insbesondere Termine und Ergebnisse nach außen kommunizieren. Der Product Owner ist damit vielfach überfordert.
  • Ressourcen- und Budget-Management: Obwohl der Product Owner implizit über seine Sprintplanung Budget-Entscheidungen trifft, so ist es doch eine andere Ebene, z.B. einen externen Berater einzukaufen, Personen einzustellen, auszutauschen usw.
  • Personalplanung: Urlaube, Abteilungswechsel, Arbeitszeiten usw. sind in größeren Unternehmen über Matrixorganisationen schnell in ganz anderen Zuständigkeitsbereichen. Für das Projekt sind sie aber entscheidend, wenn es um Leistungsfähigkeit und Verlässlichkeit geht.

Gar keine gute Idee ist es, den Scrum Master in die Verantwortung für das Projektmanagement zu nehmen. Hier entstehen sofort Interessenkonflikte. Beispielsweise will der SM für Continuous Pace sorgen. Aus Projekt-Sicht sind aber Überstunden gefordert. Oder ein Mitarbeiter soll Urlaub abbauen, wird aber im Team unbedingt gebraucht.

Mir geht es deshalb darum, ein Verständnis für ein agiles Projektmangement zu bilden, in dem die Aufgaben zwischen den Scrum Mastern und Product Owner der Teams einerseits und einem Projektmanageer andererseits klar getrennt sind.

In größeren agilen Projekten kommt immer wieder die Frage auf, wie Sprintziele gewählt werden sollen. Unter einem großen Projekt verstehe ich hierbei eines, welches mit mehreren Teams gleichzeitig an einer Software arbeitet und wo es nötig geworden ist, die Gruppe der Product Owner mit einem Chief Product Owner zu hierarchisieren. Typischerweise geht das bei fünf bis acht Scrum-Teams zu je 8 bis 12 Personen los.

Das Sprintziel sollte in ein bis drei Spiegelstrichen ausgedrückt werden können (in Ausnahmen auch bis zu fünf). Formuliert werden sollten wirkliche Ziele, also was man erreichen möchte, nichts was man tun will, denn das steht ja schon in den Stories. Also: nicht „Refactoring der Datenbankschicht“ sondern „Entkopplung des Datenbankzugriffs vom Session-Parameter“ o.ä. nicht „Implementiere drei Varianten des Identity-Providers“ sondern „Umsetzung der gesetzlichen Mindestanforderungen für Identitätsprüfung“

Ein großes Projekt hat seine Zielsetzung allerdings durch ein Geschäftsziel, d.h. es gibt eine Management-Ebene, die ein Software-Projekt zur Erreichung eines gewissen Geschäftsziels eingesetzt hat. Insofern müssen die Sprintziele auch diesem Geschäftsziel zuarbeiten. Im Idealfall ist die Summe aller Sprintziele das, was man braucht, um das Geschäftsziel zu erreichen.

Die Aufgabe des Product Owners ist es nun, das Geschäftsziel über die Sprints herunter zu brechen in Sprintziele, die das Team versteht. Ein Geschäftsziel ist zu vage, um es zu operationalisieren. Stories sind zu konkret, um sie direkt auf ein Geschäftsziel zu beziehen.

Insofern sind inhaltliche Sprintziele für mich ein essentieller Bestandteil eines agilen Entwicklungsprozesses. Sie liefern konkrete Themen, an denen sich ein Team abarbeiten kann. Sie sind auch eine gute Grundlage für die täglichen Entscheidungen im Sprint. Ein Sprintziel sollte man unter keinen Umständen aufgeben. Eine Story kann man ggf. nicht umsetzen oder muss sie aufteilen.

Sprint Commitment

Ich finde das Sprint Commitment einen ganz wesentlichen Bestandteil von Scrum. Es gehört für mich dazu, wenn ich agil arbeite. Dabei wird das Sprint Commitment häufig falsch verstanden.

Ich habe Teams erlebt, die Sprint Commitments aufgrund von Story-Points abgeben. Das halte ich für Unsinn. Ich habe Teams erlebt, die Sprint Commitments aufgrund einer Story-Anzahl abgeben. Auch das halte ich für unsinnig. Ich habe Teams erlebt, die sich auf eine klar definierte Auswahl von Stories committen. Das halte ich nicht für effektiv. Ich glaube, dass man das Meiste herausholt, wenn man ein Team dafür gewinnt, das Sprint Commitment zum Sprintziel abzugeben.

Hier ist meine Erklärung dazu:

1) Sprint Commitment zu Story-Points
Die Story-Points sind ein Hilfsmittel, um Komplexität von Anforderungen abzuschätzen. D.h. ich möchte wissen, welche Herausforderung eine Story für das Team darstellt. Mit der Velocity, die ich über die zurückliegenden Sprints gemessen habe, kann ich eine ausreichend genaue Aussage über die Möglichkeiten des Teams treffen. Wenn sich das Team jetzt zu einer Story-Point-Anzahl committet wiederhole ich eigentlich nur die Berechnung unter Berücksichtigung der Inhalte. D.h. ich bekomme heraus, wie sicher sich das Team bei seiner Schätzung fühlt. Nachteil: Ich kann in zwei Drittel der Fälle nur verlieren, denn ein Team wird ggf. weniger Story-Points leisten oder nur genauso viel. Dann habe ich aber im Zweifel keinen gefühlten Erfolg. Nur wenn ich mehr schaffe, fühlt sich das richtig gut an, weil es ja ein abstrakter Wert ist. Außerdem bekomme ich als Product Owner keine inhaltliche Garantie. Im Zweifel zieht das Teams die „einfacheren“ Stories vor, um das Commitment zu schaffen.

2) Sprint Commitment zu Story-Anzahl
Das ist genauso zweifelhaft und verhält sich ähnlich zu den Story-Points.

3) Sprint Commitment zu einer Auswahl von Stories
Ja, das geht schon in die richtige Richtung. Ist aber leider auch falsch. Denn das Team hat keine Steuerungsmöglichkeiten mehr. Es befindet sich in der Falle. Kann eine der Stories nicht zu Ende bearbeitet werden ist das Commitment gerissen. D.h. je mehr Stories ich habe, desto wahrscheinlicher ist es, dass das Commitment nicht eingehalten wird. Das ist demotivierend und nicht zielführend.

Was ich eigentlich möchte ist ein Team, das eigenverantwortlich Entscheidungen trifft und auf ein mit dem Product Owner gemeinsam vereinbartes Ziel hinarbeitet. Das bekomme ich in den drei oben genannten Varianten aber nicht hin.

Ich ermögliche solch ein Handeln, wenn ich das Commitment auf das vom Product Owner gesetzte Sprintziel einhole. Und das geht so:

Der Product Owner kommt zum Planning mit seinem Sprintziel und den vorbereiteten Stories. Das Team wählt zusammen mit ihm die Stories aus, die notwendig und sinnvoll sind, um das Sprintziel zu erreichen. Bei der Auswahl wird die Velocity als Erfahrungswert berücksichtigt. Am Ende des Plannings stellt der Product Owner die Frage, ob sich das Team dem Sprintziel verschreibt (sich darauf committet). Das sollte ein Selbstgänger sein.

Was jetzt möglich wird ist, dass alle Entscheidungen während des Sprints an dem Sprintziel ausgerichtet werden können. Man kann sogar Stories kürzen, aufteilen, herausnehmen. Immer wenn man dadurch das Sprintziel weiterhin erreicht, ist es in Ordnung. Das Team trägt dafür die Verantwortung, denn es hat ja sein Commitment gegeben. Hier kommt es nicht auf Story-Points oder konkrete Stories an sondern darauf, das Sprintziel zu erreichen.