Hinweis: Die aktuelle OOP-Konferenz finden Sie hier!
SIGS DATACOM Fachinformationen für IT-Professionals

COMPLEXITY:
Managing Today's Challenges

München, 03. - 07. Februar 2014

Konferenz

1) Impact Maps und Story Maps: liefern was wirklich zählt
Christian Hassa
2) Continuous Documentation statt Endless Specification - den Fokus auf nachhaltige Artefakte legen
Susanne Mühlbauer

Datum:06.02.2014
Uhrzeit:09:00 - 10:30
Vortrag: Do 7.1
cart

09:00-09:45
Impact Maps und Story Maps: liefern was wirklich zählt
Christian Hassa

Agile Projektentwicklung erfüllt oft nicht die hoch gesteckten Erwartungen aller Beteiligten. Impact Maps und Story Maps unterstützen einen wichtigen Mechanismus, der agile Projekte erfolgreich macht und der häufig außer Acht gelassen wird: Build-Measure-Learn. Der Vortrag gibt eine Einführung in das Konzept von Impact Maps und Story Maps und zeigt deren praktische Anwendung an Hand konkreter Projektbeispiele.

Zielpublikum: Product Owner, Business Analyst, Projektsponsoren, Projektmanager, Technical Leads, Architekten
Voraussetzungen: Basiswissen über agile Werte und Prinzipien, idealerweise erste praktische Erfahrungen
Schwierigkeitsgrad: Fortgeschritten

Sie lernen:
1) Die Wichtigkeit von flexiblen Scope, damit agile Methoden die versprochenen Vorteile realisieren können
2) Methoden des Anforderungsmanagement, mit denen diese Flexibilität unterstützt wird
3) Praktische Tipps für die Umsetzung in der Projektentwicklung

Ausführliche Beschreibung:
Viel zu oft werden Product Backlogs durch althergebrachtes Vorgehen bei der Anforderungserhebung mit einer Flut von User Stories überfrachtet, wodurch der agile Kernmechanismus blockiert wird: Build – Measure – Learn. Wenn dieser Motor im Projekt nicht anspringt, hilft weder die eifrige Befolgung agiler Rituale, noch die Lieferung in kurzen Iterationen. Die Umstellung auf agile Softwareentwicklung bringt daher häufig nicht jene Effekte, die erhofft und möglich wären.
Impact Maps und Story Maps sind Methoden, mit denen dieser Motor in Gang gebracht werden kann: Sie unterstützen beim iterativen Produktdesign, das bei der bloßen Priorisierung einer Liste von User-Storys im Product Backlog häufig Acht gelassen wird. Die Methoden sind hoch-visuell und unterstützen das gesamte Projektteam bei der gemeinsamen Entdeckung, Priorisierung und Detaillierung von Kundenwünschen.
Neben der Einführung in das Konzept von Impact Maps und Story Maps bringt der Vortrag Beispiele aus Projekten, wie Story Maps eingesetzt wurden und welche Wirkung dadurch erzielt wurde. Ebenso erhalten Sie praktische Hinweise zur täglichen Arbeit mit Story Maps.


09:45-10:30
Continuous Documentation statt Endless Specification - den Fokus auf nachhaltige Artefakte legen
Susanne Mühlbauer

Wie weiß man bei agiler SW-Entwicklung, was das System tut, wenn die Anforderungen weggeworfen werden? Ist es andererseits möglich, eine Spezifikation tatsächlich aktuell zu halten? Ist der Aufwand gerechtfertigt? Agile Methoden setzen auf kontinuierliche Konversation, nach der Umsetzung dürfen die Anforderungen weggeworfen werden. Konventionelle Methoden nutzen eine schriftliche Spezifikation und halten diese laufend aktuell. Der Vortrag zeigt auf, wie mittels Continuous Documentation nachhaltige Artefakte geschaffen werden können.

Zielpublikum: Projektleiter, Requirements Engineers, Business Analysten, Enwickler, Architekten
Voraussetzungen: Erfahrungen mit Requirements
Schwierigkeitsgrad: Fortgeschritten

Sie lernen:
Waste im Entwicklungsprozess vermeiden; bessere Produktdokumentation und weniger Projektdokumentation, Umdenken und Einsatz agiler Methoden auch in einem regulierten Umfeld, in dem Systemdokumentation extrem wichtig ist.

Ausführliche Beschreibung:

Agile Vorgehensweisen setzen auf kontinuierliche Konversation zwischen Anforderer (vertreten durch den Product Owner) und Entwicklungsteam während der gesamten Entwicklungszeit. Während der Entwicklung entstehen neue Anforderungen, die über das Product Backlog wieder in eine Konversation einfließen. Nach der Umsetzung dürfen die Anforderungen (z.B. User Stories) entsorgt werden.
In konventionellen Vorgehensweisen bedient man sich einer Spezifikation, die vor Entwicklungsbeginn beschreibt, was das System tun soll und die laufend um Änderungswünsche aktualisiert wird. Ziel dieser Vorgehensweise ist unter anderem, Auswirkungen von Änderungen auf die Entwicklung vorab analysieren zu können und stets zu wissen, welche Anforderungen das spätere System enthalten wird.
Gehen wir davon aus, dass eine Spezifikation vor Entwicklungsbeginn beschreibt, was das System tun soll, während eine Dokumentation nach Entwicklungsende beschreibt, was das System tut. In konventionellen Vorgehensmodellen werden alle Änderungen während der Entwicklung zuerst in der Spezifikation beschrieben und somit sind Spezifikation und Dokumentation stets aktuell bzw. sogar ein und dasselbe Artefakt.
In der Praxis ist dies nur mit sehr viel Aufwand und Disziplin möglich und wird leider auch nur in den seltensten Fällen durchgehalten.
In diesem Vortrag betrachten wir, wie in agilen Vorgehensweisen mit dieser Herausforderung umgegangen wird und was konventionelle Vorgehensweisen von einer konsequenten iterativ, inkrementeller Vorgehensweise lernen können.
Der Kniff liegt dabei in der kontinuierlichen Dokumentation der Umsetzung innerhalb jeder einzelnen Iteration.