Gearconf 2010 atdd_kunden_und_scrum

agile@silpion.de www.silpion.de | All rights reserved. Copyright © 2010.
Projektarbeit 2.0
Von ATDD, Kunden, Entwicklern und Scrum in
der Softwareentwicklung
1

Vorstellungsrunde
2

Wer seid ihr?
• Wer hat noch keine Erfahrung mit agilen Methoden?
• Wer hat Erfahrung mit agilen Methoden?
• Wer hat Erfahrung mit Kanban?
• Wer hat Erfahrung mit Scrum?
• Wer ist hier wegen (A)TDD/BDD?
• Wer ist hier wegen Java/Ruby/C#?
• Wer ist hier, weil er/sie unzufrieden ist, wie Kunde/Team „zusammenarbeiten“?
3

Es wäre schön, wenn...
• ihr Fragen stellt, so bald etwas unklar ist
• ihr Feedback gebt (also nicht nur Fragen stellen ;)
• es nur eine Unterhaltung zur Zeit gibt
• elektronische Geräte nur in Ausnahmefällen benutzt werden
• ihr was aus diesem Vortrag mitnehmen könnt
4

Was war geschehen?
5

Projektarbeit 1.0
• (Eher) Traditionelles Vorgehen
• Push-System
• Projekthierarchie (PL, TPL, Architekt, Senioren, Teamleiter, etc.)
• Ca$hcow Changerequest
• Dungeon Development
6

Projektarbeit 1.0 - Erfolge
• Angespannte Stimmung im Projekt
• Gereizte (und unzufriedene) Kunde
• Gereizte (und unzufriedene) Mitarbeiter
• Strapazierte Projektrahmen
• Leistungsumfang
• Budget
• Zeit
• Qualität
• „Feindbild“ Kunde
• Ca$h
7

(Traditionelle)
Software Projekte
• sollen die Bedürfnisse der Nutzer
decken
• sollen termingerecht abgewickelt
werden
• sollen im veranschlagten Budget
sein
• sollen die richtige Qualität liefern
Quelle: The Standish Group Chaos Report, 2006
8

(Traditionelle)
Software Projekte
• sollen die Bedürfnisse der Nutzer
decken
Quelle: The Standish Group, 2002 study
9

Unsere erste Wahl: Scrum
10

11

12

Eine Schlüsselrolle für den Erfolg: der PO
13

14

Produktvision
15

Produktvision - Ein Moment der Reﬂektion
• Wer ist die Zielgruppe des Projektes?
• Was ist denn das Bedürfnis des Zielgruppe? Warum sollten die das wollen? Bzw.
womit sind ist die Zielgruppe nicht zufrieden?
• Wie heisst das Projekt?
• In welche Kategorie kann man das Projekt einordnen?
• USP
• Wer ist der Hauptkonkurrent?
• Was wären weitere Differenzierungsmerkmale?
16

Das Elevator - Pitch - Template
FOR <target customer>
WHO <statement of the need>
THE <product name>
IS A <product category>
THAT <key beneﬁt>
UNLIKE <primary competitor>
OUR PRODUCT <further differentiation>
(From Geoffrey Moore, Crossing the Chasm)
17

Produktvision & Roadmap
18

Anforderungen
• Abstrakte Anforderungen, die auf einer hohen Ebene mehrere Funktionalitäten
bündeln
• Dazu werden dann User Stories erstellt
19

Product Backlog
• Enthält ungeplante Backlog Items
(User Stories etc.), keine
Anforderungen
• Sind in einer absoluten Reihenfolge
• Liefern die Produktvision
• Oben detailliert, unten grob
• (Hoch)dynamisch
20

User Story Format
As a
<type of user>
I want to
<do something>
so that
<I can achieve some
Business value>.
21

User Stories
• Wie schreibt man die?
• Wer macht was?
• Warum wird das gemacht?
• Sollte immer aus Sicht des Endnutzers formuliert sein!
• Aber:
• Woher weiss ich eigentlich, wann ich durch bin?
• Wie detailliert darf eine Story eigentlich sein?
22

INVESTiere in User Stories
•Independent
•Negotiable
•Valuable
•Estimable
•Small
•Testable
23

Wann weiss ich denn nun, wann ich fertig bin?
• Acceptance Criteria (Abnahmekriterien)
• Freitext
• Given-When-Then
• Deﬁnition of Done
24

25

Was gehört denn nun zum Job des PO?
• Anforderungsmanagement
• Planning
• Termin
• Leistungsumfang
• Stakeholdermanagement
• Risikomanagement
• Budgetmanagement
• etc.
26

Anforderungsmanagement mit Scrum (& Kanban)
in der Praxis
27

Wie der Kunde sich einbringen möchte...
• Extremata:
• Er will gar nicht!
• Er will immer alles kontrollieren!
• Was wir hatten:
• Ein Kunde, der zwar keine User Story schreiben will, aber die Stories abnehmen will.
• Selbiges gilt für Abnahmekriterien.
• 1 Meeting/Woche (Dauer: min. 4 Std.)
• Das Füllen des Backlog war nicht schnell & gut genug.
28

Unser Ansatz: Kanban zum Befüllen des Backlog
29

Die Icebox
30

Nächste Stories für das Product Backlog
31

Überarbeiten der Akzeptanzkriterien (1)
32

Überarbeiten der Akzeptanzkriterien (2)
33

Kundenreview
34

Anpassung
35

Abnahme
36

Ab ins Backlog
37

(A)TDD
38

From Brian Marick via Lisa Crispin and Janet
Gregory
Q2
Q1
Q3
Q4
Business-facing
Technology-facing
Supporttheteam
Critiquetheproduct
39

Testdriven Development
From Wikipedia, the free encyclopedia
40

Wer kann die Tests schreiben & lesen?
• Schreiben
• Entwickler
• Lesen
• Entwickler
• ggf. auch andere
41

Evolution...
UserStory!
Acceptance
Criteria!
Given-When-
Then!
Deﬁnition of!
Done!
UnitTests!
42

Speed up!
43

Next generation
UserStory!
Acceptance
Criteria!
Given-When-
Then!
Deﬁnition of!
Done!
Test::Unit! RSpec!
RSpec::UserStories!
ATDD/BDD!
44

Cucumber (http://cukes.info)
• Testdeﬁnition in natürlicher Sprache!
• Testausgabe in natürlicher Sprache!
45

Gherkin
• GIVEN
• WHEN
• THEN
• AND
• BUT
Scenario: Multiple Givens!
Given one thing!
Given an other thing !
Given yet an other thing !
When I open my eyes !
Then I see something !
Then I don't see something else!
Scenario: Multiple Givens!
Given one thing !
And an other thing !
And yet an other thing !
When I open my eyes !
Then I see something !
But I don't see something else!
46

Feature & Step definition
Feature definition (*.feature)
Step definition (*.steps)
47

Make it fail
48

Fix it
49

...und weiter
50

51

Das agile Heilmittel?
52

Risikominimierung durch schnelles Feedback
Quelle: The Business Value of Agile Software Development by Brad Swansons (Propero Solutions LLC) 2009
53

Planung &
Transparenz?
Vorgehen nach Phasen
vs.
Anzahl vollständiger, getesteter,
produktionsreifer Features
54

Qualitätsverbesserung
55

Schnelleres time-2-market
• Man baut nur die Dinge, die der Kunde aktuell benötigt
• Priorisiere, was gebaut werden soll
• Wichtiges wird nicht durch unwichtiges verzögert
• Man spart Zeit in Bezug auf Planung, Design und Overhead
• Man erstellt das System kleiner und sauberer. Dadurch wird es wartbarer und
kann leichter erweitert werden
• Kurze Iterationen verringern das Risiko von bösen Überraschungen am Ende des
Projekts
• oft Verzögerungen
• höhere Entwicklungskosten
56

Höhere Produktivität
• Cross-funktionale, hoch kollaborative, auf das Produkt fokusierte Teams
• Reduzierte Feedbackzeit, was die Produktivität erhöht
• Fokusiert auf klare, kurzfristige Zielefocused, was die Motivation erhöht
• Fokusiert auf die Beseitigung von Überﬂüssigem/Hinderlichen und kontinuierlich
am Verbessern des Prozesses
57

Besseres ROI
58

Agile Erfolge
59

Weitere Informationen
60

Vielen Dank für Ihre Aufmerksamkeit :)
61

Gearconf 2010 atdd_kunden_und_scrum

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (17)

Similaire à Gearconf 2010 atdd_kunden_und_scrum

Similaire à Gearconf 2010 atdd_kunden_und_scrum (20)

Gearconf 2010 atdd_kunden_und_scrum