• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rails und Scrum in großen Projekten
 

Rails und Scrum in großen Projekten

on

  • 1,615 views

 

Statistics

Views

Total Views
1,615
Views on SlideShare
1,615
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rails und Scrum in großen Projekten Rails und Scrum in großen Projekten Presentation Transcript

    • Rails und Scrum ingroßen Projekten Ein Einblick in die Praxis Phillip Oertel, betterplace.org HPI 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? Stand 09.2009 Rails Frontend TesterProduct Owner Scrum Master 0 10 20 30
    • über Euch• 5tes Semester• Aufgabe: ERP-System erstellen• 13 Wochen-Projekt (80-100 Stunden)• 13 Teams á 4-8 Studenten• Projekt hat gerade angefangen
    • über Euch ?
    • Zahlen, Zahlen, Zahlen.• „68% aller IT-Projekte scheitern.“ http://www.silicon.de/cio/strategie/0,39038989,39200412,00/68+prozent+aller+it_projekte+scheitern.htm• „Konventionelle Projekte scheitern öfter.“ 59% vs. 35% Prozent. http://www.computerwoche.de/mittelstand/1907184/index3.html• „92% would recommend agile to others.“ http://www.succeedingwithagile.com/wp-content/uploads/2009/10/Reported-Benefits-of-Agile.ppt http://fuwatch.wordpress.com
    • agile ???
    • Agile ManifestoIndividuals and interactions over processes and toolsWorking 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
    • Scrum
    • SCRUM Lernen selbst rausfinden Team Anpassen Diskussion VertrauenZusammenarbeit Transparenz Big Visible Charts Schlank Priorisierung Iterativ Fokus Mut hohe EigenverantwortungUnsicherheit
    • Scrum-Warnung 1„You dont see high performingScrum teams without XPengineering practices.“― Jeff Sutherland und Ron Jeffries http://blog.crisp.se/henrikkniberg/2007/10/13/1192249140000.html
    • XP simplicity test-firstYAGNI: don‘t addfunctionality early spike solutions sustainable pace refactorintegrate often collective ownership pair programming move people around agreed standards http://www.extremeprogramming.org/rules.html
    • Scrum-Warnung 2Kein Prozess und kein Tool der Welterlauben es, sich zurückzulehnen undden Kopf abzuschalten ...
    • ... 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.“ 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
    • 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-Software1. Gegenstände erfassen (Name, Kategorie (vorgegeben), eindeutige Id, Kaufdatum, aktueller Standort)2. Aufkleber drucken (eindeutige Id, Name der Firma)3. Gegenstände auflisten4. 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 L! A I F https://scrumy.com/hpi-demo-1
    • Beispiel: Planning Board
    • Beispiel: Planning Board ‘ IT E ! T IN I E DO R U‘ R YO
    • 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?“)
    • Anforderungen mit beschreiben# 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.info http://wiki.github.com/aslakhellesoy/cucumber/given-when-then http://dannorth.net/introducing-bdd
    • 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ösungmodule Inventory module Finance class Item class Item def current_value def current_value 42 47.11 end end end endend endassert_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 Der Release-Termin von Windows 7 wurde zweimal verschoben. http://www.spiegel.de/spiegel/0,1518,634334,00.html
    • Eine kleine Geschichteer wurde zweimal vorverlegt! http://www.spiegel.de/spiegel/0,1518,634334,00.html
    • Eine kleine GeschichteMicrosoft arbeitetseit 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.org po@betterplace.org• XING alexander.greim@xing.com
    • Buchtips
    • Scrum-Basicskurz, gut, alles Wesentliche drin http://tinyurl.com/2p5fqq
    • Scrum-Basics und kundenorientiertesAnforderungs-Managementhttp://tinyurl.com/yfuruxt
    • gutes deutschsprachiges Rails-Buchhttp://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“ G N S N IO O T „the requirements are reasonably R P W M well defined“ SUA 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
    • „Campus Management“Erstes Release ca. 2001; Einführung hier WS 2005.Die Bewertung ist aus dem Sommersemester 2006. http://is.gd/4Rco7