Rails und Scrum in großen Projekten
Ein Einblick in die Praxis
Phillip Oertel, betterplace.orgHPI Uni Potsdam, 10. November 2009
Überblick
• Intro
• Scrum
• ein typischer Tag ...
• Ruby, Rails
• Q&A Session
Intro
über mich
• seit 1999 Web-/Software-Entwickler
• Ruby on Rails seit 2005 (~4 Jahre)
• Scrum: 1½ Jahre
über mich
• zuletzt 3 Jahre Rails bei
• jetzt: technischer Leiter bei
großes Projekt?
Rails
Frontend
Tester
Product Owner
Scrum Master
0 10 20 30
Stan
d 09
.200
9
• 5tes Semester
• Aufgabe: ERP-System erstellen
• 13 Wochen-Projekt (80-100 Stunden)
• 13 Teams á 4-8 Studenten
• Projekt hat gerade angefangen
über Euch
über Euch
?
Zahlen, Zahlen, Zahlen.
• „68% aller IT-Projekte scheitern.“
• „Konventionelle Projekte scheitern öfter.“ 59% vs. 35% Prozent.
• „92% would recommend agile to others.“
http://fuwatch.wordpress.com
http://www.silicon.de/cio/strategie/0,39038989,39200412,00/68+prozent+aller+it_projekte+scheitern.htm
http://www.computerwoche.de/mittelstand/1907184/index3.html
http://www.succeedingwithagile.com/wp-content/uploads/2009/10/Reported-Benefits-of-Agile.ppt
agile ???
Agile Manifesto
http://agilemanifesto.org
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.
Scrum
SCRUMTeam
ZusammenarbeitDiskussion
Priorisierung
Unsicherheit
Mut
Lernen
Big Visible Charts
Iterativ
selbst rausfinden
Anpassen
hohe Eigenverantwortung
Schlank
Vertrauen
Fokus
Transparenz
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
XP
http://www.extremeprogramming.org/rules.html
sustainable pace
move people around
simplicity
spike solutionsYAGNI: don‘t add functionality early
refactor
agreed standards
test-first
pair programming
integrateoften collective
ownership
Kein Prozess und kein Tool der Welt erlauben es, sich zurückzulehnen und den Kopf abzuschalten ...
Scrum-Warnung 2
... außer nach Feierabend.
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.“
• Nutzt die Retrospektiven, und passt Euer Vorgehen an.
• Aber: „understand the rules before you break them.“ http://xprogramming.com/xpmag/jatBaseball
http://blog.brianhartsock.com/2009/11/04/an-outsiders-first-look-at-scrum/
Rollen in Scrum
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.
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
Achtung: Nichtfunktionale Anforderungen?
• Bsp: „System muß 1.000 Benutzer gleichzeitig verkraften“
• werden in Besprechung mit dem Team herausgefunden (z.B. Estimation Meeting)
TIP
• Beginnt früh mit der Anforderung, bei der die größte Unsicherheit besteht.
TIP
• Regelmäßige Treffen der Product Owner zur Abstimmung: Product Owner Team.
• ein für alle klares Projektziel
• hat auch einen (Teilzeit-)Scrum Master.
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.
Beispiel: Planning Board
https://scrumy.com/hpi-demo-1
Beispiel: Planning Board
FAIL!
https://scrumy.com/hpi-demo-1
Beispiel: Planning Board
Beispiel: Planning Board
RITE!YOU‘RE DOIN
‘ IT
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)
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?“)
# The title should describe an activityFeature: An Admin creates users# [...]# The scenario title should say what´s differentScenario: 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.infohttp://wiki.github.com/aslakhellesoy/cucumber/given-when-then
http://dannorth.net/introducing-bdd
Anforderungen mit beschreiben
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 ...“
ein typischer Tag ...
Sprint Planning Board
(c) http://www.flickr.com/photos/e-ality
(c) http://www.flickr.com/photos/e-ality
Red,Green,
Refactor!
TIP
• frühzeitig automatisieren (eigenes Team?)
• Ein Build pro Produkt
• Ein Integrations-Build mit allem
Meeten (=Reden)
Ruby
Ruby
offene Klassen# Inventar-Team programmiert:class Item def current_value 42 endend
# Finanzen-Team programmiert:class Item def current_value 47.11 endend
offene Klassen
# Lösung module Inventory class Item def current_value 42 end endend
module Finance class Item def current_value 47.11 end endend
assert_equal 42, @item.current_value
Ruby on Rails
Architektur 1:Namespaces
Archi-Variante 2: Engines
Architektur 3:ActiveResource
• „SOA Light“ mit REST-Architektur.
• Jede Anwendung/Dienst (Inventar, BenutzerAuth) ist ein eigener Prozess
• zusätzlicher Komplexitätgrad
Architektur 3:ActiveResource
MVC
• „fat model, skinny controller“Geschäftslogik ins Modell
• Controller ist Mediator
• View ist schlank und dumm
Eine kleine Geschichte
http://www.spiegel.de/spiegel/0,1518,634334,00.html
Der Release-Termin von Windows 7 wurde zweimal verschoben.
Eine kleine Geschichte
er wurde zweimal vorverlegt!
http://www.spiegel.de/spiegel/0,1518,634334,00.html
Eine kleine Geschichte
Microsoft arbeitet seit 3 Jahren mit XP,einem agilen Prozess.
http://www.spiegel.de/spiegel/0,1518,634334,00.html
diese Seite wurde absichtlich freigelassen.
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!
Länger so arbeiten?
Buchtips
Scrum-Basicskurz, gut, alles Wesentliche drin
http://tinyurl.com/2p5fqq
Scrum-Basics und kundenorientiertes
Anforderungs-Management
http://tinyurl.com/yfuruxt
Extras
Merkmale guter Anforderungen
• Unabhängig
• Verhandelbar
• Nützlich
• Schätzbar
• Klein
• Testbar
„Scrum“ - Roman Pichler, Seite 44-46
„Why the Waterfall model doesn‘t work“
„the requirements are reasonably well defined“
• „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
WRONG
ASSUMPTIO
NS
„Campus Management“
http://is.gd/4Rco7
Erstes Release ca. 2001; Einführung hier WS 2005.Die Bewertung ist aus dem Sommersemester 2006.