Als PDF, PPTX herunterladen
![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](https://image.slidesharecdn.com/unipotsdam2009-railsundscrumingroenprojekten-110320063414-phpapp02/75/Rails-und-Scrum-in-grossen-Projekten-35-2048.jpg)
Hochgeladen vonPhillip Oertel
Rails und Scrum in großen Projekten
Die Präsentation bietet einen praxisorientierten Überblick über den Einsatz von Scrum und Ruby on Rails in großen Projekten, basierend auf Erfahrungen des Autors. Es werden die Rollen und Verantwortlichkeiten innerhalb von Scrum-Teams erläutert, sowie Tipps zur effektiven Umsetzung und Anpassung von Prozessen gegeben. Zudem wird auf die Wichtigkeit von regelmäßigen Meetings, Transparenz und die Einhaltung agiler Prinzipien hingewiesen.
Weitere ähnliche Inhalte
Rails und Scrum in großen Projekten
- 1. Rails und Scrumin großen Projekten Ein Einblick in die Praxis Phillip Oertel, betterplace.org HPI Uni Potsdam, 10. November 2009
- 2. Überblick • Intro • Scrum •ein typischer Tag ... • Ruby, Rails • Q&A Session
- 3.
- 4. über mich • seit1999 Web-/Software-Entwickler • Ruby on Rails seit 2005 (~4 Jahre) • Scrum: 1½ Jahre
- 5. über mich • zuletzt3 Jahre Rails bei • jetzt: technischer Leiter bei
- 6. großes Projekt? Stand 09.2009 Rails Frontend Tester Product Owner Scrum Master 0 10 20 30
- 7. über Euch • 5tesSemester • Aufgabe: ERP-System erstellen • 13 Wochen-Projekt (80-100 Stunden) • 13 Teams á 4-8 Studenten • Projekt hat gerade angefangen
- 8.
- 9. 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
- 10.
- 11. Agile Manifesto Individuals andinteractions 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
- 12.
- 13. SCRUM Lernen selbst rausfinden Team Anpassen Diskussion Vertrauen Zusammenarbeit Transparenz Big Visible Charts Schlank Priorisierung Iterativ Fokus Mut hohe Eigenverantwortung Unsicherheit
- 16. Scrum-Warnung 1 „You don'tsee 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
- 19. Scrum-Warnung 2 Kein Prozessund kein Tool der Welt erlauben es, sich zurückzulehnen und den Kopf abzuschalten ...
- 20. ... außer nach Feierabend.
- 21. Scrum-Warnung 3 • „Thegood 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
- 22.
- 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ühmit der Anforderung, bei der die größte Unsicherheit besteht.
- 27. TIP • Regelmäßige Treffender 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.
- 29. Beispiel: Planning Board https://scrumy.com/hpi-demo-1
- 30. Beispiel: Planning Board L! A I F https://scrumy.com/hpi-demo-1
- 31.
- 32. Beispiel: Planning Board ‘ IT E ! T IN I E DO R U‘ R YO
- 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 ofScrums • Nach dem Daily Scrum des Teams geht ein Entwickler zum „Über-Daily-Scrum“ • dort: „was hat mein Team gemacht ...“, nicht „Was habe ich ...“
- 37.
- 39.
- 40.
- 41.
- 42.
- 44. TIP • frühzeitig automatisieren(eigenes Team?) • Ein Build pro Produkt • Ein Integrations-Build mit allem
- 45.
- 47.
- 48.
- 50. offene Klassen # Inventar-Teamprogrammiert: 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 moduleInventory 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
- 52.
- 53.
- 54.
- 55. Architektur 3: ActiveResource • „SOA Light“ mit REST-Architektur. • Jede Anwendung/Dienst (Inventar, BenutzerAuth) ist ein eigener Prozess • zusätzlicher Komplexitätgrad
- 56.
- 57. MVC • „fat model,skinny controller“ Geschäftslogik ins Modell • Controller ist Mediator • View ist schlank und dumm
- 58. Eine kleine Geschichte Der Release-Termin von Windows 7 wurde zweimal verschoben. http://www.spiegel.de/spiegel/0,1518,634334,00.html
- 59. Eine kleine Geschichte erwurde zweimal vorverlegt! http://www.spiegel.de/spiegel/0,1518,634334,00.html
- 60. Eine kleine Geschichte Microsoftarbeitet seit 3 Jahren mit XP, einem agilen Prozess. http://www.spiegel.de/spiegel/0,1518,634334,00.html
- 61. diese Seite wurdeabsichtlich freigelassen.
- 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
- 64.
- 65. Scrum-Basics kurz, gut, allesWesentliche drin http://tinyurl.com/2p5fqq
- 66. Scrum-Basics und kundenorientiertes Anforderungs-Management http://tinyurl.com/yfuruxt
- 67. gutes deutschsprachiges Rails-Buch http://tinyurl.com/yh6x9jg
- 68.
- 69.
- 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
- 72. „Campus Management“ Erstes Releaseca. 2001; Einführung hier WS 2005. Die Bewertung ist aus dem Sommersemester 2006. http://is.gd/4Rco7