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?

• betterplace.orgpo@betterplace.org

• XINGalexander.greim@xing.com

Buchtips

Scrum-Basicskurz, gut, alles Wesentliche drin

http://tinyurl.com/2p5fqq

Scrum-Basics und kundenorientiertes

Anforderungs-Management

http://tinyurl.com/yfuruxt

gutes deutschsprachiges Rails-Buch

http://tinyurl.com/yh6x9jg

Bitte um Feedback!po@betterplace.org

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.