11. Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
that is, why there is value in things on the right, we value the
things on the left more.
http://agilemanifesto.org
13. SCRUM Lernen
selbst rausfinden
Team Anpassen
Diskussion
Vertrauen
Zusammenarbeit
Transparenz
Big Visible Charts Schlank
Priorisierung
Iterativ
Fokus
Mut
hohe Eigenverantwortung
Unsicherheit
14.
15.
16. Scrum-Warnung 1
„You don't see high performing
Scrum teams without XP
engineering practices.“
― Jeff Sutherland und Ron Jeffries
http://blog.crisp.se/henrikkniberg/2007/10/13/1192249140000.html
17. XP simplicity
test-first
YAGNI: don‘t add
functionality early spike solutions
sustainable pace
refactor
integrate
often collective
ownership
pair programming
move people around agreed standards
http://www.extremeprogramming.org/rules.html
18.
19. Scrum-Warnung 2
Kein Prozess und kein Tool der Welt
erlauben es, sich zurückzulehnen und
den Kopf abzuschalten ...
21. Scrum-Warnung 3
• „The good thing about Scrum is it doesn’t
claim to be right. It claims to be a flexible
foundation which will get better each iteration.“
http://blog.brianhartsock.com/2009/11/04/an-outsiders-first-look-at-scrum/
• Nutzt die Retrospektiven, und passt Euer
Vorgehen an.
• Aber: „understand the rules before you
break them.“ http://xprogramming.com/xpmag/jatBaseball
23. Rolle: Product Owner
• Holt Anforderungen vom Kunden ab
• bereitet sie für die Programmierung vor
• Priorisiert und stellt dem Team die gerade
wichtigsten vor
• Nimmt am Sprint-Ende Ergebnisse ab
• zentrale Rolle. Sagt Ja/Nein.
24. Beispiel:
Inventar-Software
1. Gegenstände erfassen
(Name, Kategorie (vorgegeben), eindeutige Id, Kaufdatum, aktueller Standort)
2. Aufkleber drucken
(eindeutige Id, Name der Firma)
3. Gegenstände auflisten
4. Gegenstände suchen
25. Achtung:
Nichtfunktionale
Anforderungen?
• Bsp: „System muß 1.000 Benutzer
gleichzeitig verkraften“
• werden in Besprechung mit dem Team
herausgefunden (z.B. Estimation Meeting)
26. TIP
• Beginnt früh mit der Anforderung, bei der
die größte Unsicherheit besteht.
27. TIP
• Regelmäßige Treffen der Product Owner
zur Abstimmung: Product Owner Team.
• ein für alle klares Projektziel
• hat auch einen (Teilzeit-)Scrum Master.
28. Rolle: Scrum Master
• Kennt Scrum und bringt es dem Team bei.
Ziel: sich selbst überflüssig machen
• Beseitigt aktiv Hindernisse (Impediments)
• Schützt das Team vor Störungen
• „Führt durch Dienen“. Hilft, gleicht aus,
coacht. Moderiert die Meetings, bereitet sie
vor und nach.
• Hat keine Macht: entscheidet nicht mit.
33. Rolle: Team (Entwickler)
• Implementieren die Anforderungen
• Planen den Sprint
• Schreiben Unit Tests
• Präsentieren am Sprint-Ende das Ergebnis
• Schätzen den Aufwand der Anforderungen
(Estimation Meetings)
34. Rolle: Team (Tester)
• Testet und gibt Feedback
• erstellt automatisierte Akzeptanz-Tests
• erarbeitet mit Product Owner die
Akzeptanz-Kriterien für Anforderungen
(„Wann ist etwas fertig?“)
35. Anforderungen mit beschreiben
# The title should describe an activity
Feature: An Admin creates users
# [...]
# The scenario title should say what´s different
Scenario: Add a user
# put the system in a known state
Given I am on "the add a user form"
# describe the key action(s)
When I enter correct user data
And I click on the CREATE button
# observe/test outcomes
Then I should see "the user detail page“ for the new user
http://cukes.info
http://wiki.github.com/aslakhellesoy/cucumber/given-when-then
http://dannorth.net/introducing-bdd
36. Tip: Scrum of Scrums
• Nach dem Daily Scrum des Teams geht ein
Entwickler zum „Über-Daily-Scrum“
• dort: „was hat mein Team gemacht ...“, nicht
„Was habe ich ...“
50. offene Klassen
# Inventar-Team programmiert:
class Item
def current_value
42
end
end
# Finanzen-Team programmiert:
class Item
def current_value
47.11
end
end
51. offene Klassen
# Lösung
module Inventory module Finance
class Item class Item
def current_value def current_value
42 47.11
end end
end end
end end
assert_equal 42, @item.current_value
62. Zusammenfassung
• Scrum-Grundregeln umsetzen, dann das
Vorgehen regelmäßig anpassen
• Rubys Stärken und Schwächen
kennen und entsprechend arbeiten
• habt nicht die Erwartung, das in eurem
kurzen Projekt alles auf Anhieb klappt!
63. Länger so arbeiten?
• betterplace.org
po@betterplace.org
• XING
alexander.greim@xing.com
70. Merkmale guter
Anforderungen
• Unabhängig
• Verhandelbar
• Nützlich
• Schätzbar
• Klein
• Testbar
„Scrum“ - Roman Pichler, Seite 44-46
71. „Why the Waterfall
model doesn‘t work“
G N S
N IO
O T „the requirements are reasonably
R P
W M well defined“
SU
A
S • „changes during development will be small“
• „system integration is predictable & plannable“
• „software innovation and R&D are predictable“
„Scaling Software Agility“, Dean Leffingwell, Seite 17-27
