Use Cases 2.0 -> vs. User Stories

Hallo,

Ivar hat es getan!

Er hat nach 25 Jahren ein Update seiner Use Case Idee publiziert das perfekt an die Agilität angepasst ist.

http://www.ivarjacobson.com/use_case2.0_ebook/

Die Grundidee ist es die Use Cases in „Use Case Slices“ aufzuteilen. Ein „Use Case Slice“ ist „one or more stories selected from a use case to form a work items that is of value to the customer“

Use Case Slices sind damit das perfekte Mittel um Teilfunktionalitäten zu Sprints/Inkrementen zuzuteilen. Sie stehen damit aus meiner Sicht massiv in Konkurrenz zu den weit verbreiteten User Stories.

Unbedingt lesen!

Freue mich über Eure Kommentare dazu

Wolfgang Göbl

Einladung zum 6. V-ARC Treffen „Kanban&Requirements“

Liebe Kollegen,

rechtzeitig zum Frühlingsbeginn blüht auch der V-ARC wieder auf mit einem Treffen zum Thema

„Kanban & Requirements“

Als Referent haben wir diesmal mit Dr. Klaus Leopold einen international tätigen Kanban Coach und Trainer.

Ort: Raiffeisen Bausparkasse, Wiedner Hauptstraße 94, 1050 Wien
Datum: Do 19.4. 15:00-18:00
Agenda:

* „Was möchte ich von Kanban wissen“ – Teilnehmer schreiben Karten
* Impulsvortrag ca. 45 Minuten der auf diese Themen eingeht, z.B.:
– Wie wird in Kanban mit Requirements
umgegangen? Unterschiede zu Scrum?
* Beantwortung der Fragen im Diskurs

Ich freue mich darauf möglichst viele von Euch zu sehen und auf die immer spannenden Diskussionen.

Viele Grüße
Wolfgang Göbl

Bericht von der ReConf 2012

Hallo,

anbei mein Bericht vom ersten Tag der ReConf 2012.

Insgesamt sehr spannend, gerade das Spannungsfeld der althergebrachten RE mit Agilität zu spüren. Beides kein Allheilmittel ist mein Konsens – aber im Detail siehe unten.

Liebe Grüße
Wolfgang

ALLGEMEINES

Die guten Nachrichten: das Thema Requirements wird scheinbar immer interessanter, die ReConf ist heuer um weitere 100 Teilnehmer auf >500 gewachsen. Das Thema Agil wird immer wichtiger in der Requirements Community. Die schlechte Nachricht: von den 4 Keynotes war keiner zum Thema Agilität und Requirements, von  den restlichen Vorträgen gerade mal 21% zum Thema.

Mein Track „Requirements und Agilität“ war ganz gut besucht (ca. 70 Leute waren konstant bei den 5 Präsentationen, weniger positiv gesprochen: trotzdem war die Mehrheit >400 Leute in den anderen 4 Tracks :-).

KONSENS&DISSENS zu meinem Vortrag

Nach meinem Vortrag (–> Praxisbericht Use Cases in agilen Projekten bei Raiffeisen Solution) herrschte Übereinstimmung zu folgenden Punkten:

  • Das Begriffswirrwarr (Epics, User Stories, Use Cases, Story Maps, ….) das durch die Vermischung agiler und RE Praktiken entsteht macht das Thema unübersichtlich.
  •  Use Cases sind in der agilen Community ein „No-No“, hier scheint einiges an verbrannter Erde aus der Wasserfalltradition und den bis auf den letzten Beistrich ausdefinierten Uses Cases entstanden zu sein.
  • Es braucht ein den User Story übergeordnetes fachliches Strukturierungsmittel – in meinem Vortrag sind das die „Use Cases“, andere bezeichnen das als Epics etc. Als ich den Aufbau unserer Use Cases präsentiert habe kam von einigen Zuhörern ein „das machen wir fast genauso, nur bei uns heisst das XYZ“
  •  Modellierung (Use Cases, Objektmodelle, Masken, etc.) soll zunächst interaktiv auf Papier passieren und erst nachträglich ins Tool übertragen werden

Dissens entstand wie zu erwarten war mit Menschen die stärker aus der agilen Community kamen und sich noch wenig mit dem RE Thema beschäftigt haben und rein auf „USer Stories“ als Spezifikationen setzen.

Angesprochen wurde ich nach dem Vortrag von einigen langgedienten Analytikeren die nach wie vor aus voller Überzeugung auf Use Cases und klassische RE Methoden setzen, so wie „endlich jemand der das Use Case Thema auch in der Agilen Welt für „cool“ hält.

GUTE PRÄSENTATIONEN
(die Folien dazu werden in Kürze auf der ReConf Homepage verfügbar sein)
„Interaktive Modellierung im Team“ (Hood)
Der gute Vortrag zeigte anhand eines durchgespielten einfachen Beispiels zu welchem Zeitpunkt typischerweise welche Modelle (Use Case Diagramm, Mockups, Ablaufdiagramme). Spannend dabei: das war nahezu 1:1 wie das was ich als Raiffeisen Solution Ansatz präsentiert habe, teilweise unter anderen Namen.

 – „Drei Metapattern des Requirements Engineering“ (oose)
Folien: Meta-Patterns-Requirements-Engineering.weilkiens.oose
Der Autor des brillianten Vortrags stellt drei Pattern vor, wie sie sowohl im klassischen als auch agilen RE vorkommen. Eine der Aussagen: RE hat in sich etwas träges, die Verwaltung von Trivialitäten nach genau vorgegebenem Prozess steht oft im Vordergrund vor Innovation und Kreativität. Kernaussage: So gehts in RE nicht weiter, wenig Fortschritt“ – „Wir haben einen guten Methodenkoffer, er wird aber zu wenig „meisterlich“ eingesetzt. d.h. die richtige Methode zum richtigen Problem/Projektumfeld wird sehr selten ausgewählt.

Inhalt: – „Scrum ohne Murcs“ 
Folien: UPscaled Scrum ohne murcS
Ein ziemlich „augenöffnender“ und humoresker Vortrag, nicht wieder blind dem nächsten Hype hinterherzulaufen!

Scrum wird derzeit in vielen Firmen unreflektiert als Allheilmittel verwendet.
Die Aussage „Scrum führt zu besseren Produkten und das billiger“ ist laut Autor nirgendwo empirisch belegt, Scrum stellt das aber in den Raum.

Der Vortrag relativiert Scrum als Allheilmittel stark. z.B. sind eine Vielzahl bestehender Firmen kulturell „Controll“ orientiert und das macht in diesen Branchen oft auch Sinn (z.B. Brückenbau, Medizintechnik). Scrum kommt so daher dass sich die Unternehmenskultur halt an Scrum anpassen soll, was auch etwas naiv ist – in solchen Umfeldern macht oft KANBAN Sinn.
Ob Scrum in großen Projekten skaliert wird auch sehr hinterfragt

Ein weiteres Beispiel: Wenn ich von Wien nach Hamburg fahren will dann tue ich das nicht agil sondern plane genau im Vornherein und überprüfe nicht in Salzburg ob es nicht eine bessere Verbindung gibt. Agilität hat hier einfach keinen Sinn weil die „Domäne“ sicher und bekannt ist. Wenn nun die Bahn streiken würde (hohes Maß an Ungewissheit) dann macht
Agilität sinn. Der Vortrag gibt ca. 12 Kriterien wann eher Agilität und wann eher vorab geplantes Vorgehen sinn macht.

ZUSAMMENFASSUNG

  • Weiterhin ist ein starker Bruch zwischen der agilen und der RE Community spürbar. Die Agile Community geht sehr naiv mit RE um und es gab einen Vortrag eines agile Begeisterten, der User Stories als alleinige Anforderungsspezifikation sieht und dabei aber sehr dünn blieb – aus meiner Sicht eine klare Missverwendung des Konzepts
  • Auf der anderen Seite empfinden manche Analytiker mit langjähriger Erfahrung den sehr schwach reflektierten Hype zu Scrum als Bedrohung etablierter Techniken.
  • Mehrmals wurde spürbar dass es eine Sehnsucht danach gibt nach Jahrzehnten endlich das Thema RE so aufzusetzen dass es nachweislich zu besseren Ergebnissen führt. Am ehesten als sich Vertreter der Agilität und der Althergebrachten RE im selben Raum befanden

Checkliste des Agilen Anforderungsmanagements

Im Rahmen von v-arc haben wir uns gefragt, wäre die Agile Anforderungsmanagement-Methode (agiles RE) für jene Projekte in welchen wir gerade arbeiten, geeignet. Die Antwort was sofort „Es kommt darauf an…“, also es gibt keine allgemeingültige.

Wir haben schnell festgestellt, daß es von vielen Faktoren abhängt: von der Organisation in welcher man arbeitet, vom Umfeld, von der Projektart usw.  Projektart selbst kann viele Dimensionen haben, und diese benötigen unterschiedliche Herangehensweise an die methodische Einführung des agilen RE.

In diesem Artikel, suchen wir aus unserer Sicht die geeigneten Schritte für die Einführung des agilen RE, sowie die notwendigen Rahmenbedingungen, damit die Anwendung der Methode ein Erfolg wird.

Wir wollen dabei eine Art Checkliste erstellen, welche man durchlaufen muß, und in den einzelnen Schritten die relevanten  Einflußfaktoren berücksichtigen sollte.

Was ist das Ziel?

Was ist das minimale Zielzustand, welches wir erreicht haben wenn wir meinen „wir praktizieren Agiles Anforderungsmanagement“? Was ist eigentlich unser Ziel?

Ziel ist eigentlich nicht agiles RE selbst zu praktizieren, sondern die Zielgenauigkeit der IT Lösungen zu erhöhen, wobei diese die angedachten Geschäftsziele unterstützen.

Dieses Ziel zu erfüllen, hilft die agiles RE in dem sie die Ergebnisse eines wiederholten (iterativen) Anforderungsprozesses in ein genauso wiederholbares Entwicklungsprozeß  mündet, und die Ergebnisse – die Softwareinkremente den Benutzern, Anforderen, Analytikern, und dem Team präsentiert. Durch die Präsentation der Ergebnisse, entsteht ein wertvolles Feedback, welches in die nächste Analyse-Iteration einfließt.

Somit sind wir überzeugt, daß agiles RE als „Insel-Praktika“ ohne dahinterliegender Entwicklung keinen Sinn ergibt.

Also, hier kommt eine – bestimmt unvollständige Liste der Schritte, welche zu dem erfolgreichen agilen RE in einem Projekt führen.

Check #1: „Analyse Jour Fixe etablieren“

Etabliere ein regelmäßiges Analysetermin mit Anforderern/Kunden und der Entwicklung um Slots zu haben, wo die agile Praktiken gelebt werden: Backlog – Priorisierung, Präsentation der Zwischenergebnisse, Aufwandsschätzung-Kommunikation.

In der iterativen Vorgehensweise ist es essentiell eine Kultur der immer wiederkehrenden Tätigkeiten zu etablieren. Dazu ist es sinnvoll sog. „Analyse-Serie“ zu etablieren.

Plane die „Analyse-Serie“ in 1-2 Monaten in der Zukunft, definiere  zu besprechenden Themen, damit Kunde (Anforderer-Team) die richtigen Ansprechpartner holen kann.

Definiere die Praktiken in dem Analysetermin und klare Ergebnisse:
–    Präsentation der Zwischenergebnisse geht immer auf der Grundlage der definierten Akzeptanzkriterien.
–    Aufwandsschätzung ist immer die Schätzung des Entwicklers(Teams) ohne Puffer
–    Feedback mündet nur in das Backlog

Check #2: „Analyse Backlog etablieren“

Erarbeitung des Analyse Backlogs ist einer Grundlage für den iterativen Analyseprozess.

Die Fähigkeit, die kommunizierten Anforderungen so zu „schneiden“ damit sie klein aber zugleich sinnvoll sind, ist ein Paradigmenwechsel und benötigt einen Umdenkprozeß – ähnlich dem Umstieg eines Entwicklers von einer prozeduralen auf eine objektorientierte Programmiersprache.

Ein Beispiel in Scrum ist z.B. Anspruch daß die User Stories Charakteristiken erfüllen sollen, welche unter dem Akronym „INVEST“ zusammengefaßt sind (siehe z.B. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/)

Check #3: „Dokumentation der Analyseergebnisse – Kollaboration über die Inhalte statt Review- und Freigabeprozesse “

Ausgehend von den Punkten aus dem Agilen Manifesto:

–    Funktionierende Software mehr als umfassende Dokumentation
–    Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

ist es essentiell daß man in Projekten, in welchen sich starre Review- und Freigabeprozesse der großen Dokumente etabliert haben, versucht aufzuweichen.

Die Kultur des Einfrierens der Dokumente (Spezifikationen) muß aufgebrochen werden, und Team dazu bewogen, daß man die Dokumente jederzeit ändern kann.

Dokumentation ist da, den aktuell korrekten Stand der geplanten Entwicklung abzubilden, und als Träger für die Entwicklung bzw. QA zu dienen.

Dabei sollte man jene Dokumentationswerkzeuge auswählen, wo die Veränderung automatisch nachvollziehbar ist, und somit jegliche Diskussionen darüber auf die Seite legt.

Check #4: „Timeboxing Kultur etablieren“

Der wahre Enabler der Agilen Umsetzung ist eine Kultur des Timeboxings in der Analyse und der Umsetzung zu etablieren.

Wenn man schafft, die einzelnen Iterationen (Timeboxing) als die fixe Konstante zu etablieren, und Inhalt als Variable zu akzeptieren, dann bekommt man ein wichtiges Management-Werkzeug in die Hände: Die Möglichkeit daß man die Mitarbeiter ohne wenn und aber, zu festgelegten Zeitpunkten immer wieder neu ausrichten kann.

Matrix „Projektcharakteristik/Agile Requirements Praktiken“

Liebe Kollegen,

wir haben am Contributor Workshop 24.1. eine Matrix erarbeitet, in der Typische Projektcharakteristika (Größe, Komplexität, uvm) agilen Requirements Praktiken zugeordnet werden.

V-ARC Projektkriterien-Praktiken Matrix

Das Ziel ist es in den nächsten Monaten ein gemeinsames Bild zu entwickeln welche Praktik in welchen Projektsituationen gut geeignet ist oder nicht. d.h. die relevanten Zellen sollen mit +++/++/+/0/-/–/— bewertet werden.

Im Anhang die unbefüllte Matrix (Version 0.1). Wir laden Dich ein die Zellen der Matrix aus Deiner Sicht zu befüllen und hier zu posten. Gut wäre auch wenn Du (wo relevant) Deine Bewertung mittels Excel „Kommentar einfügen“ Funktion kommentieren könntest.

Wir konsolidieren das dann im Laufe der nächsten Wochen.

Viele Grüße

Wolfgang Göbl

Fragestellungen für nächstes Treffen „Schätzen und Planen“ am 23.2.

Liebe Kollegen,

anbei die Fragestellungen die wir beim nächsten Treffen 23.2. behandeln wollen.

Falls Dich noch andere Fragen in diesem Kontext interessieren bitte hier als Kommentar posten.

Falls Du gerne zum Thema referieren möchtest bitte um email an wolfgang.goebl@r-solution.at

Requirements Management -> Schätzen und Planen im agilen Umfeld“

Fragestellungen die behandelt werden sollen:

  • Macht ihr bevor man mit dem ganzen Team in die Sprints losstartet eine Scoping Phase?
  • Wenn ja:
    – mit wievielen Personen?
    – Welche (Analytiker, Architekt)?
    – Mit welchem Aufwand?
    – Wie genau wird dann die Schätzung?
    – Was wird dabei erstellt (z.B. grobes Objektmodell, grobes Architekturbild?)
    – Welche Vorteile/Nachteile sind dadurch entstanden?
  • Wenn nein:
    – welche Vorteile/Nachteile sind dadurch in der Praxis entstanden?
  • Planning Poker: wieviel Voranalyse braucht es damit das Team gute Schätzungen beim Planning Poker machen kann?
  • Zusammenspiel Requirements Management -> Erstellung Product Backlog
  • Um ein Product Backlog (=Planungsinstrument) erstellen zu können braucht es Analyse. Wer macht das? (Scrum Master, Analytiker, Team)

Termin:
Do 23.2. 15:00-18:00
Thema: „Schätzen und Planen“
EBCONT enterprise technologies GmbH
Millennium Tower
Handelskai 94-96
1200 Wien