Neulich im Blog vom Mike Cohn siehe unten…
Ich denke es macht ganz viel Sinn die in der agilen Welt verwendeten Themes nach den althergebrachten Use Cases zu strukturieren.
Was denkt ihr?
Wolfgang
siehe http://blog.mountaingoatsoftware.com/stories-epics-and-themes
Beitrag vom 11.4.:
Vienna Agile Requirements Circle 
Ein „Theme“ ist lediglich eine Sammlung von User Stories unter einer Bezeichnung, also z.B. „User Management“.
Ich sehe daher kaum einen Zusammenhang zwischen Theme und einem (high-level) Use Case.
Für die Modellierung eines Systems in agilen Projekten kann man User Scenarios schreiben die dann mit Story Maps strukturiert werden können (Jeff Patton).
Nunja, auch ein high-level Use Case kann als Sammlung von User Stories verstanden werden.
Und wenn ich statt „User Management“ „Benutzer verwalten“ schreibe, um eine Kurzbeschreibung ergänze dann habe ich einen perfekten High Level Use Case.
Auf der ReConf vor 4 Wochen war der große Bruch zwischen der RE und der agilen Community spürbar. Es gibt definitiv einen großen
Bedarf die beiden Disziplinen (und damit ihre Begriffswelten) zusammenzuführen. Gerade im agilen blühen noch so manche Konzepte die etwas zu „lean“ für den professionellen Umgang mit Requirements sind.
Ich sehe das (auch) so, dass UseCases sehr geeignet sind, um die Anforderungen in unterschiedlicher Ausprägung (und mehr oder weniger sind ja user stories und themes auch nicht) auf einem High-Level zusammenzufassen – das ist letzten Endes auch die Absicht hinter UseCases. Wenn man mal erklärt hat, was Strichmännchen und Ellipsen sind (und viel mehr steckt auch nicht dahinter), dann eignen sich UseCases auch zur Kommunikation mit den Stakeholdern, um eine funktionale Sicht des Gesamtsystems zu vermitteln.
In Folge fallen dann aus UseCases auch mehr oder weniger ein Kontextdiagramm heraus – oder auch umgekehrt, ich denke, die beiden Diagramme ergänzen sich iterativ.
Was ich (als nicht ständiger Beobachter der Szene) nicht ganz nachvollziehen kann ist, dass es hier einen Bruch geben soll oder gibt. Anforderungen sind in konventionellen und in agilen Projekten essentiell – vielleicht die Intensität je nach Projektstatus und der konkrete Umgang damit sind ein wenig unterschiedlich, aber nicht die Bedeutung an sich. Wenn ich in agilen Projekten nicht dennoch ein Gefühl für und eine Übersicht über das Ganze habe und bewahre, werde ich wohl mit sehr vielen Änderungen konfrontiert werden und letzten Endes auch nicht schneller sein. Wenn ich im Gegensatz in konventionellen Projekten glaube, dass ich für ein oder zwei Jahre korrekt planen kann so ist das schlichtweg ein Irrtum.
Ich ziehe zum Vergleich oft „Alice im Wunderland“ her: Alice frägt: „in welche Richtung geht es hier?“, die Katze frägt: „wo willst du denn hin?“, Alice sagt: „keine Ahnung“ und die Katze antwortet: „dann ist es auch egal in welche Richtung du weitergehst“. Und behalten wir uns auch im Hinterkopf, wo sich agile Methoden besonders gut eignen und auch wo nicht – kein Widerspruch, sondern eine je nach Situation angemessene Ergänzung und Vorgangsweise sollten im Vordergrund stehen.
Ich glaube auch, dass ein Use Case eine natürliche Sammlung von User Stories sein kann und oft mit einem Theme gleichgesetzt werden kann. Es hängt aber sicher davon ab, wie man einen Use Case schreibt. Die Bandbreite geht von einfacher verbaler Beschreibung bis zu detaillierten Beschreibungen inkl. UI Sketches bis hin Use Cases, die schon einen Design vorwegnehmen (vor allem wenn man die Business Domäne und Entwicklungstechnologie gut kennt).
Es gilt sicher je detaillierter und näher am Design umso weniger agil ist der Ansatz. Meine Erfahrung mit Endanwendern ist, dass ohne einen UI Entwurf die Requirements Analyse oft unvollständig bzw. missverständlich ist. Story Maps, wo man mit den UI Entwürfen konkrete Beispiele (Szenarien) durchspielt, sind sehr gut geeignet die Anforderungen auf den Punkt zu bringen.
Ob die Strukturierung von Anforderungen nun Themes oder Use Cases heißen, ist für mich wenig relevant, solange man die Abhängigkeiten innerhalb der Anforderungen bestimmen kann und die Granularität der Anforderungen für eine Aufteilung auf Sprints gegeben ist. Wenn man umfangreiche Use Cases schreibt, dann ist die Aufteilung auf Sprints schwieriger aber grundsätzlich lösbar. Andererseits sind die „uses“ und „extends“ Beziehungen in der Use Case Modellierung auch eine Hilfe bei der Strukturierung der Requirements.
So wie ich den Begriff Theme verstehe, ist das etwas ganz anderes als ein Use Case. Ein Theme ist eine Überschrift, Arbeit im Sekunden oder Minutenbereich, während ein Use Case ein Dokument ist, dass Stunden bis Tage zur Erstellung braucht. Also ein Riesenunterschied!
Natürlich kann man beide zur Gruppierung von Stories verwenden, aber diese Gemeinsamkeit rechtfertigt in meinen Augen nicht, das gleichzusetzen.
Auch ein Use Case ist zu Beginn eine Überschrift und eine Kurzbezeichnung. Cockburn und jetzt auch Jacobson forcieren das auch so.
Ich glaube auch dass genau in Deiner Interpretation das große Missverständnis zwischen den Agilisten und den Requirements Evangelisten liegt. Aber gemäß Coburn beginnt auch ein Use Case „Ultralight“ hat aber im Vergleich zu agileren Techniken wie Stories auch die Möglichkeit so detailliert wie erforderlich runterzubrechen. Und – ja – ich glaube es macht auch in der Agilität manchmal Sinn sehr weit runter zu Detaillieren (z.B. bei komplexen Kreditvergaberegeln, sehr komplexen Abläufen etc.) und hier steigen die agilen Techniken aus – einfach weil sie eigentlich keine Anforderungstechniken sondern planungstechniken sind.
Ich habe mal versucht, die Definitionen von Mike Cohn zu visualisieren:
