Scrum und Use Case Analyse. Agilität versus schwergewichtiger Analyse, ein Widerspruch?

Größe: px

Ab Seite anzeigen:

Download "Scrum und Use Case Analyse. Agilität versus schwergewichtiger Analyse, ein Widerspruch?"

Liese Holzmann
vor 8 Jahren
Abrufe

1 Scrum und Use Case Analyse Agilität versus schwergewichtiger Analyse, ein Widerspruch? 1

2 Über den Autor Praktiziert seit 1987 Aikido Jap. Kampfkunst Prinzipien Kraft aufnehmen, umlenken Angriff Ausweichen Situation wahrnehmen und kontrollieren Aikido ist eine agile Kampfkunst 2

Angriff Ausweichen Situation wahrnehmen und

3 Aikidofotos 3

4 Inhaltsübersicht Scrum - Überblick Projektüberblick Use Case Analyse - Überblick Sprint - Planung Tools Thesen 4

5 Motivation Unser Projekt besteht aus einer Produktfamilie von Anwendungen rund um Energiehandel, Kraftwerkseinsatzplanung, Prognosen (z.b. Wind), Netzfahrplänen u.v.a.m. Der Entwicklungsprozess ist im wesentlichen Scrum XP Einflüsse, wie Pair Programming UA Tests mit FEST ( Teilweise hochkomplexe Fachlichkeit 5

a.m. Der Entwicklungsprozess ist im wesentlichen Scrum XP Einflüsse, wie Pair

6 Scrum-Überblick Quelle: 6

7 Scrum Artefakte 7

8 Agiles Manifest Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Das heißt, während die Punkte auf der rechten Seite durchaus ihren Wert haben, bewerten wir die linke Seite höher. (Frei übersetzt aus dem Manifest) Quelle: 8

over following a plan Das heißt, während die Punkte auf der rechten Seite durchaus ihren Wert

9 Andere Agile Werte (XP) Test First Ansatz (TTD) Have the Customer in House Design Simple Systemmetapher 9

10 Wo stehen wir? Scrum ist agil Bestimmte Werte stehen im Vordergrund Demonstration lauffähiger Software Dokumentation (Achtung: bestimmte Arten von Dokumentation) steht im Hintergrund Scrum wird oft mit XP (Extreme Programming) kombiniert 10

11 Scrum hinterfragt Warum scheitert die Einführung von Scrum? - oder - Warum tritt der gewünschte Effekt von Scrum nicht ein? - oder - Was sollte man denn alles schon können, bevor man Scrum / XP einführt? Dazu mehr nach dem Projektüberblick 11

ein? - oder - Was sollte man denn alles schon können, bevor

12 Projektüberblick Auslandsfahrpläne Reservierung (Rechte) Anmelden (Fahrpläne) Meistens über eine genau definierte Leitung von einem Land ins andere Jahresrecht Monatsrecht Tagesrecht Rechte werden ersteigert Werden sie nicht ausgeschöpft müssen sie an der Börse verkauft werden 12

Land ins andere Jahresrecht Monatsrecht Tagesrecht Rechte werden

13 Beispiel-Ansicht Auslandsfahrplan für einen Planungstag Summe Tagesrecht Monatsrecht Jahresrecht Fast alle Sichten in den Anwendungen haben für die Tagesstunden jeweils eine Spalte Stunden können gegebenenfalls in 1/4 Stunden aufgesplittet werden Tagesrecht sind ein Profil, Monats- und Jahresrecht ein Band Fachbegriffe: Profil, Zeitreihe, Lastgang, Band 13

Monatsrecht 80 80 80 80 80 80 80 80 80 80 80 80 Jahresrecht 120 120 120 120 120 120 120 120 120 120 120 120 Fast alle Sichten in den

14 Zwei Sichten im Überblick Summe Tagesrecht Monatsrecht Jahresrecht ENDE Saldo Stahl AG Ziegelei Lieferant A Oben Auslandsfahrplan (für einen Planungstag) Unten Handels-Hub im Ausland (Regelzone / Bilanzkreis), mit Deals an einem Planungstag (die auch länger als einen Tag laufen können) Die Summe der übertragenen Energie im Auslandsfahrplan deckt das negative Saldo am Handels-Hub 14

120 120 120 120 120 120 120 120 120 120 1 2 3 4 5 6...... 21 22 23 24 ENDE Saldo -300-300 -300-300 -300-600 -600-600 -300-300 -300-300.

15 Gleich wird es kompliziert Das simple Beispiel wird schnell kompliziert Daher die Einführung in Use Case Analyse an Hand dieses Projektausschnitts 15

16 Use Case Analyse - Überblick Beschrieben in Object Oriented Software Engineering: A Use Case Driven Approach von Ivar Jacobson Siehe auch Software Reuse von Ivar Jacobson, M. Griss, and P. Jonsson Die UML definiert Use Case Diagramme Use Case - fachliche Anforderung mit Ablaufsbeschreibung Akteur - Rolle / Anwender oder externes System / Service Use Cases selbst sind Text, und können z.b. wie Stories auf Karteikarten geschrieben werden Im RUP sind Use Cases und Szenarien Grundlage für die Architekturdefinition (Komponenten / Services) Szenarien sind Grundlage für (UA-) Tests 16

Jonsson Die UML definiert Use Case Diagramme Use Case - fachliche Anforderung mit Ablaufsbeschreibung Akteur - Rolle / Anwender oder externes

17 Use Case Diagramm aus dem Projekt Jahres oder Monatsrecht ersteigen Fahrplan, Summe aller Rechte bzw. tatsächlich ausgeschöpften Reservierungen (man muss nicht alles anmelden, das man reserviert hat) 17

bzw. tatsächlich ausgeschöpften Reservierungen

18 Hm? Was ist der Unterschied? Händler kauft und verkauft Energie im Marktgebiet Dispatcher fährt das Kraftwerk 18

19 Use Case als Text Schablone Name: <Substantiv + Verb> Kurzbeschreibung: <max. 3 Sätze> Akteure: Ziel: <prägn. fachlicher Zustand > Auslöser: <fachliches Ereignis> Vorbedingung: <fachliche Zustände > Nachbedingung: <fachliche Zustände > Anlauf: 1) 2)... N) 19

fachlicher Zustand > Auslöser: <fachliches Ereignis>

20 Use Cases, Szenarien, Testfälle 20

21 Wo stehen wir? Eine Use Case Analyse scheint doch etliches an Dokumenten zu produzieren Diagramme erfordern vermutlich Tool-Einsatz nicht zu reden von Spezialwissen Schauen wir im folgenden, ob der Aufwand sich lohnt 21

22 Händler Kauft Energie die in einer Zone angeboten wird Deal Verkauft Energie (in der selben Zone) Angestrebt ist meist eine neutrale Bilanz (kein Energietransport notwendig) Deals können Tagsdeals sein oder langfristig sein 22

23 Dispatcher Fährt ein Kraftwerk weiß, wo die Energie hin geht, die er produziert kennt die Kosten der Erzeugung und des Transportes Kann bei Bedarf in der Handelszone handeln und sein Kraftwerk sowie die Transporte entsprechend anpassen (neue Anmeldung!) Dies macht der Dispatcher im Moment der Kraftwerkssteuerung 23

24 Fachliche Constraints Händler erzeugen Deals, die kurz- oder langfristig sind Fahrpläne werden i.a. 24h (da gibt es auch andere Regeln...) vor der Zeit angemeldet Langfristige Deals laufen also länger als ein Fahrplan! Macht der Dispatcher einen Deal, kann er nicht von jetzt auf sofort einfach seine Lieferung ändern es gibt Zeitfenster für Änderungen der Anmeldung 24

25 Fachliche Constraints II Der Händler kann nur Fahrpläne für den Folgetag anmelden Der Händler kann beliebige Deals machen Der Dispatcher kann nur neu Anmeldungen für den aktuellen Fahrplan machen (also heute) Der Dispatcher kann nur Deals bezüglich seines Fahrplans (als am Tag an dem er auch tatsächlich arbeitet) Der Tag ist in gleitende Zeitfenster unterteilt, Änderungen am Profil ab einem Zeitfenster müssen im vorigen Zeitfenster angemeldet werden 25

26 Bei der Use Case Analyse wurde erkannt Akteure dürfen grundsätzlich leicht verschiedene Dinge an der selben Sicht durchführen Alle Sichten verhalten sich anders, in Abhängigkeit davon, ob der angezeigte Planungstag der heutige ist, oder in der Zukunft liegt 26

27 Resumè Systemmetapher ist der Planungstag bzw. das 24h Profil Der Kunde hat so wenige Akteure, das das Tagesgeschäft sie kaum in unser Haus ließ Implementierungen müssen aber geschätzt und geplant werden Ist die Fachlichkeit zu komplex hilft das vom Kunden gelieferte Word-Dokument nur wenig 27

28 Unser Vorgehen Der Kunde pflegt das Backlog in Excel Der Auftragnehmer bekommt regelmäßig eine Kopie Der Auftragnehmer verwaltet Tasks aus dem Backlog (für den nächsten Sprint) im Issue Tracker als Issue Im Issuetracker wird jedes Issue mit Subtasks für Analyse, Design, Implementierung und Test versehen 28

29 Sprintplanung (nur Top-Prio Tasks) Ist ein Task klein genug geschätzt, wird er so wie er ist in den Sprint übernommen Gibt es einen Task, der zu groß ist, wird nur der Analyse-Subtask in den Sprint übernommen i.a. wurde die Analyse im ersten Sprint auf eine bestimmte Stundenzahl gedeckelt nach der Analyse kann der Task eventuell geteilt werden oder die Analyse geht im nächsten Sprint sogar weiter 29

30 Sprint Der Sprint enthält also als Delieveries nicht nur: Getesteten Code der demonstriert wird Sondern auch Analyse Ergebnisse, die erst im darauf folgenden Sprint (oder noch später) implementiert werden 30

31 Tools Excel für das Backlog / Sprint-Backlog Jira als Issue Tracker Use Cases als Text in Eclipse Diagramme im Enterprise Architect Versionsverwaltung mit CVS Check-Ins mit Issue Nummer verknüpfen CVS mit Jira Code + Use Case getagged im CVS Abrechnung und IST-Vergleich der Aufwände durch Buchung im Jira auf die Sub-Tasks FEST, ibatis und Junit für Tests

32 Antworten Eigentlich muss jeder selbst darüber nachdenken es gibt keine allgemeingültigen Antworten Überblick schafft Flexibilität Scrum hilft mit wenig Aufwand den Überblick zu bewahren Agil heißt, man passt sich flexibel den Änderungen an Heißt das aber nicht auch, das man beim Einführen von Agilität flexibel sein muss? 32

33 Thesen Einführung von Agilen Methoden scheitern dann, wenn sie unflexibel eingeführt werden Man muss sehen, was das Team gut macht und dies fördern Die Best-Practices der jeweiligen Methode (Scrum/XP o.ä.) stückweise einführen Eingeschliffenes, das gut funktioniert, erst mal stehen lassen (Weekendbuild läuft, muß man da sofort viel Aufwand in einen Daily Build investieren?) 33

34 Thesen II Einführung von neuem funktioniert am besten, wenn es alte Aufhängepunkte im existierenden Prozess/Team verwenden kann Verwendung der Use Case Analyse, als es notwendig war, war agiler, als zu warten, bis jemand eine XP basierte / Story getriebene Analyse machen oder leiten konnte Man kann auch Agil sein ohne Scrum zu machen Agil ist doch eher eine Lebenseinstellung, oder? Wie Aikido! 34

35 Vielen Dank Mein Dank geht an die IDOS AG in Karlsruhe, für ihre freundliche Unterstützung Für Fragen stehe ich jeder Zeit im Rahmen der ReConf oder per zur Verfügung Kontakt: 35

Ähnliche Dokumente

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was