Use Cases und die Organisationsstruktur

Erstellt am 3 April 2019
von Schreibe einen Kommentar

Use-Case-Diagramme sind ein bekanntes Mittel, um den Scope eines Systems festzulegen. Aber auch bei der Gestaltung der Struktur Ihrer Produktentwicklungsorganisation können Use Cases helfen.

Hier sehen wir ein Use-Case-Diagramm, das die Use Cases eines Online-Flugbuchungssystems zeigt:

Use Case Diagramm eines Online-Flugbuchungssystems

Wie Sie sehen können, zeigt das Diagramm die Ziele, die die Nutzer haben: Ein Endkunde möchte einen Flug buchen. Das Diagramm zeigt nicht die Schritte, um zu diesem Ziel zu gelangen. Das wäre beispielsweise die Suche nach einem Flug.

Ein agiles Team sollte unabhängig von anderen Teams Wert liefern. Ein Use Case stellt solch einen unabhängigen Wertumfang dar. Denn wenn agile Teams für ganze Use Cases verantwortlich sind, ist die Notwendigkeit der Kommunikation mit anderen Teams sehr begrenzt.

Der Use Case Flug buchen ist beispielsweise für sich genommen wertvoll. Was heißt das? Nun, er ist direkt aus dem Bedürfnis der Benutzer abgeleitet, von A nach B zu gelangen. Deshalb ist er ein eigenständiges Verkaufsargument für die Software.

Probieren Sie in der Praxis aus, Teams nach Use Cases zu schneiden, und lassen Sie es mich wissen, wie es funktoniert hat!

Das Zusammenspiel von Use Cases und User Stories habe ich in einem anderen Blogbeitrag erläutert.Wenn Sie mehr über Use Cases in der agilen Produktentwicklung erfahren wollen, besuchen Sie unser HOOD CARS-Training.

Die 3 größten User-Story-Mythen

Erstellt am 27 Februar 2019
von Schreibe einen Kommentar
User Story Mythen

In meiner Arbeit mit agilen Teams und als Trainer höre ich immer wieder Aussagen über User Stories, die von der ursprünglichen Intention abweichen und in der Praxis Probleme verursachen. Zeit, mit ein paar der häufigsten Mythen aufzuräumen.

Mythos #1: In Scrum wird eine Anforderung als User-Story dokumentiert.

Das kann man so machen, muss man aber nicht. Der Scrum Guide lässt völlig offen, wie Backlog Items zu dokumentieren sind. Ich persönlich mag User Stories, weil sie die Perspektive vom System auf den Nutzer verschieben. Aber vorgeschrieben ist das nicht.

Mythos #2: Wenn man User-Stories schreibt, dann muss man ein bestimmtes Template benutzen.

Wahrscheinlich denken Sie an: Als <Nutzer> möchte ich <Funktion> damit <Erfülltes Bedürfnis>.
Das Konzept der User Story hatte ursprünglich nichts mit diesem Template zu tun. Mike Cohn hat das Template dann später populär gemacht. Es ist genauso möglich, User Stories informell zu dokumentieren und auf das Template zu verzichten.

Mythos #3: User Stories werden mit Story Points geschätzt.

Als Scrum Master habe ich Teams beobachtet, die sich mit Diskussionen um Story Points, Schätzungen und Velocity verrückt gemacht haben.

Es gibt eine einfache Alternative. Das Team vereinbart kleine Stories. So 1-2 Umsetzungstage für das Team. Dann zählt es nach dem Sprint die Stories, die es fertiggestellt hat. Schon hat man die Velocity.


Sie sehen: Der Umgang mit User Stories ist in der Praxis gar nicht so schwierig. Wie setzen Sie User Stories in der Praxis ein? Ich freue mich über einen Kommentar!


Veranstaltungstipp

Die perfekte Gelegenheit zum weiteren Aufräumen der Mythen finden Sie in knapp zwei Wochen auf der REConf 2019 vom 11.-15. März in München.




Was ist Empirisches Requirements Engineering?

Erstellt am 6 Februar 2019
von Schreibe einen Kommentar

Als Apple das iPhone 2007 veröffentlichte, löste es eine Revolution auf dem Mobilfunkmarkt aus. Steve Jobs wurde als innovatives Genie gefeiert.

Heute haben alle Smartphones Touchscreens. Damit kann man niemanden mehr begeistern. Innovation bedeuetet, am Puls der Zeit zu bleiben. Und ein Augenmerk auf die Kundenbedürfnisse zu haben.

Genau darum geht es in der agilen Entwicklung laut Jeff Sutherland, Vater von Scrum, dem erfolgreichsten agilen Framework:

Innovation is what agile is all about.

Quelle: Embracing Agile, https://hbr.org/2016/05/embracing-agile

Kern von Scrum ist die Entwicklung in Sprints von wenigen Wochen. Am Ende des Sprints steht ein „Produkt-Inkrement“. Zum Beispiel fertig entwickelte, getestete und dokumentierte Software.

So kann das Team regelmäßig Feedback einholen. Die wichtigsten Stakeholder sind die externen Kunden. Durch das Einarbeiten ihres Feedbacks maximiert man ihre Zufriedenheit.

Empirisches Requirements Engineering heißt: Das Team vereinbart erst am Anfang des Sprints die umzusetzenden Anforderungen. Basierend auf aktuellem Wissen.

Man versucht nicht, Entwicklungsumfänge Monate im Voraus detailliert zu planen. Fachkonzepte, Lastenhefte oder Pflichtenhefte sind passé.

Stattdessen akzeptiert man, dass Anforderungen veralten. Während der Entwicklung gewinnt das Team neue Erkenntnisse über Kundenbedürfnisse. Und über die technologische Umsetzung. Details von Anforderungen werden erst kurz vor der Umsetzung festgelegt.

Empirisches Requirements Engineering: Die 3 Planungsebenen

Heißt das, man muss jede Planung aufgeben, die über einen Zwei-Wochen-Horizont hinausgeht? Nein!  Nur: je weiter man in die Zukunft plant, desto gröber wird die Planung. Dadurch wird die Planung robuster gegen Änderungen.

In der Praxis haben sich drei Planungsebenen für ein Produkt bewährt:

  • Man muss das große Ganze im Blick behalten. Eine Produktvision ist der Nordstern für die Entwicklung. Sie adressiert die Kundenbedürfnisse und gibt die Richtung vor. Sie sorgt für Motivation, als Team an einem Strang zu ziehen.
  • Die Planung der Lieferung kann mehrere Sprints umfassen. In der Softwareentwicklung wird auch von Releaseplanung gesprochen. Wichtig ist, dass man auf Details der Anforderungen weitgehend verzichtet. Eine gut geeignete Praktik ist Story Mapping.
  • Die Planung des Sprints erfolgt in Scrum mit Hilfe der Backlogs. Das Team legt die Details der Anforderungen fest. Also zum Beispiel die Akzeptanzkriterien von User Stories. Auch während des Sprints kann das Team Anforderungen noch detaillieren.

Wenn Sie mehr über Empirisches RE wissen wollen, treffen wir uns im CARS-Kurs. Mehr zur Wandlung der Märkte lesen Sie in diesem Blogbeitrag.


Epics sind tot

Erstellt am 2 Januar 2019
von Schreibe einen Kommentar

Was wurde nicht schon alles für tot erklärt? Schon vor Jahren wurde Test Driven Development beerdigt. Merkwürdigerweise verbreitet es sich trotzdem immer weiter. Natürlich ist auch Agil tot. Obwohl  selbst traditionsreiche Unternehmen mittlerweile mit Scrum in Berührung gekommen ist.
Totgesagte leben länger, sind aber immer gut für eine schmissige Überschrift.
In diesem Sinne. Werden Sie Zeuge, wie ich Epics als agile Praktik zerstöre.

Agile Antipatterns – Teil 1: Projektbudgetierung

Erstellt am 8 Mai 2018
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Agile Antipatterns

Die gewünschten Vorteile der agilen Entwicklung sind vielfältig:

  • Die Kunden sind zufriedener und damit kaufbereiter.
  • Die Zeit von der Idee bis zur Lieferung an die Kunden ist kürzer.
  • Die Mitarbeiter sind motivierter und leisten mehr.

Hört sich doch gut an, oder? In der Praxis stehen bestimmte Verhaltensweisen den genannten Vorteilen im Weg. Weil ich als Scrum Master und agiler Coach dieselben Muster in vielen Firmen immer wieder sehe, schreibe ich in dieser Artikelserie darüber.

Anforderungen langfristig dokumentieren, im agilen Umfeld

Erstellt am 10 Mai 2017
von 1 Komment

 

In unserem CARS-Training diskutieren wir viele Themen, unter anderem: wie dokumentiert man Anforderungen langfristig, im agilen Umfeld?

Diese Frage ist für uns deshalb so wichtig, weil der Wert der Dokumentation mit der Zeit zunimmt.

Die abgespeckte Sprint-Retrospektive

Erstellt am 24 November 2016
von Schreibe einen Kommentar

Wenn Sie als Scrum Master arbeiten, dann erleben retro Sie wahrscheinlich auch, dass die Retrospektive nicht zu den heiß geliebten Scrum-Events gehört. Ich habe aber die Erfahrung gemacht, dass Retrospektiven wirklich etwas bringen, nämlich Reflektion und Kommunikation darüber, was verbessert werden kann.

Ich bin daher ständig auf der Suche nach neuen Formaten, die von den Teams als nützlich empfunden werden. Das strikte Festhalten an 5 aufeinander folgenden Phasen ist meiner Erfahrung nach nicht notwendig, und manchmal sogar kontraproduktiv.

Wenn der Sturm sich nicht legt, dann bauen wir eben Windmühlen

Erstellt am 27 September 2016
von Schreibe einen Kommentar

Titel-FallschirmspringerAufblende: Seit einem halben Jahr diskutieren Sie nun ein fachliches Thema mit mehreren Fachabteilungen. Aber der Sturm der Konflikte will einfach nicht aufhören. „Soll ich etwa eine Windmühle bauen?“ denken Sie, schon fast verzweifelt.

Scrum – the hard parts 2: sprint harder

Erstellt am 9 August 2016
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Scrum - the hard parts

Sprint_harder

Quelle: pixabay

Im ersten Teil dieser Serie habe ich meine persönliche Favoritenliste der „hard parts“ von Scrum vorgestellt und wie Sie diese gekonnt umschiffen können.

Auch im zweiten Teil möchte ich Ihnen einen bunten Strauß an Bad Practices und Workarounds anbieten – aus der Praxis, für die Praxis. Scheitern garantiert.

Viel Spaß!