Scrum Foundation Level Training Scrum Scrum Foundation Foundation Level Level Training Training by binaris by education binaris education
Die Konzepte hinter Scrum
Scrum ist ein agiles Projektmanagement Framework
das agile Manifest Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen & Interaktionen funktionsfähige Produkte Zusammenarbeit mit dem Kunden das Eingehen auf Änderungen haben Vorrang vor Prozessen & Werkzeugen ausgedehnter Dokumentation Vertragsverhandlungen strikter Planverfolgung Wir Schätzen auch die Punkte auf der rechten Seite, die auf der linken Seite wertschätzen wir jedoch mehr! www.agilemanifesto.org
Leichtgewichtig So wenig Formalismen wie irgendwie möglich Nur so viele Vorgaben wie unbedingt nötig
Die Magie hinter Scrum Plan Adapt Do Check
Produkt Prozess
In Scrum heißen Iterationen Sprints Jeder Sprint beinhaltet alle Projektphasen Jeder Sprint erzeugt ein Produktinkrement Sprint Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Die Rollen
Die Rollen in Scrum Team Product Owner Scrumteam Scrum Master
besteht aus allen Personen, die fortwährend zur Erstellung des Produktes benötigt werden, wie z.b. Entwickler, Tester, Designer, Architekten Größe: 3 9 Personen Das Team
Der Product Owner Fachlich Verantwortlich für das Produkt Entscheidet: Welche Anforderungen werden im Produkt berücksichtigt In welcher Reihenfolge werden die Anforderungen eingeplant (Priorisierung) Hat idealer weiser Budgetverantwortung Pflegt das Product Backlog Ist kein Vorgesetzter des Teams Ein Product Owner betreut idealerweise ein Team (offiziell sind mehr erlaubt) Jedes Team hat einen Product Owner Die Rolle Product Owner ist ein Vollzeitjob!
Der Scrum Master verantwortlich für den Scrum Prozess ist kein Vorgesetzter kann nur überzeugen, nicht vorschreiben Lehrer und Coach für Team und Product Owner jedes Team hat einen Scrum Master ein Scrum Master kann mehrere Teams betreuen Pflegt das Impediments Log Beseitigt Hindernisse des Teams ist nicht Teil des Teams Moderiert die Meetings
Die Stakeholder Alle Personen, Gruppen oder Organisationen, die Einfluss auf das Projektergebnis nehmen wollen, wie z.b.: Kunden Fachabteilungen Anwender Geschäftsführung Vertrieb Betrieb Gesetzgeber etc.
Der Ablauf
Der Ablauf eines Sprints Sprint Retrospektive Stakeholder Anforderungsmanagement Product Backlog Sprint Review Auslieferbares Produktinkrement Release Burndown Schätzen & Priorisieren Sprint Planning Sprint Backlog Sprint Sprint Burndown
Planning Meeting Teilnehmer: Product Owner, Scrum Master, Team Ziel: Gefülltes Sprint Backlog für den nächsten Sprint Ablauf: Product Owner stellt den oberen Teil des Product Backlogs vor und welches Ziel er in dem Sprint gerne erreichen möchte. Team gibt ihm Feedback aus technischer Sicht zur Reihenfolge der Anforderungen Team bestimmt, wie viel Aufwand (z.b. in Story Points) es sich in diesem Sprint vornehmen möchte Product Owner stellt nun nacheinander die Stories im Detail vor Team bricht die jeweilige Story in Tasks (ToDos) runter Team entscheidet, ob die Story mit ihren Tasks noch in den Sprint passt Das Ganze solange, bis Team entscheidet, dass der Sprint voll ist Wenn Sprint voll, Commitment vom Team zu dem Sprintziel Product Owner entscheidet über die Reihenfolge der Stories! Team entscheidet, wie viele Stories in den Sprint kommen!
Scrum Wand backlog in process done Sprint Burndown Story Item Item Item Item Story Item Item Item Item Story Item Item Item Item Item Impediments Impediment Story Story Item Item Item Item Item Item Item Item Item Impediment Impediment
Daily Scrum Teilnehmer: Product Owner, Scrum Master, Team, weitere Personen (nur als Zuhörer) Jeden Tag am selben Ort und zur selben Uhrzeit Dauer maximal 5 Minuten! Jeder Teilnehmer beantwortet folgenden drei Fragen: Was habe ich seit dem letzten Daily Scrum gemacht? Was plane ich bis zu nächsten Daily Scrum zu machen? Was behindert mich? Es wird im Daily Scrum nicht diskutiert! Wer Diskussionsbedarf hat, klärt den im Anschluss mit den Betroffenen Scrum Master dokumentiert die Hindernisse im Impediment Backlog Im Anschluss an das Daily Scrum, die Scrum Wand und den Sprint Burndown Chart aktualisieren
Sprint Burndown Chart Restaufwand 20 9 8 7 6 5 4 3 2 0 9 8 7 6 5 4 3 2 Idealkurve initial einzeichnen (blaue Linie Den im Sprint verbliebenen Restaufwand eintragen (rote Linie) Täglich (zum Daily Scrum) aktualisieren Kurve zeigt den Verlauf des Sprintfortschritts an 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 20 Tag
Review Meeting Teilnehmer: Product Owner, Scrum Master, Team, ausgewählte Stakeholder Ziel: Präsentation des Sprintergebnisses und fachliche Abnahme der neuen Features Vorbereitung: Bei einem Softwareprojekt erzeugt das Team einen aktuellen Build und deployed den auf einem Demonstrationsrechner. Außerdem werden Testdaten gemäß der Akzeptanzkriterien in der Datenbank bereit gestellt Team erklärt kurz, wie der Sprint verlaufen ist und lässt dann den Product Owner und die anwesenden Stakeholder den aktuellen Build ausprobieren Product Owner testet die im Sprint Backlog als Fertig vermerkten Stories gegen die Akzeptanzkriterien und nimmt diese dabei fachlich ab. Stories werden nur ganz oder gar nicht abgenommen! Das Review Meeting ist kein technischere Abnahmetest! Product Owner und Stakeholder geben dem Team Feedback zum aktuellen Entwicklungsstand des Produktes. Ggfs. Entstehen dabei neue Anforderungen Product Backlog Die Summe der Aufwände aller abgenommener Stories ergibt die Entwicklungsgeschwindigkeit des abgelaufenen Sprints Aktualisierung des Velocity Reports Aktualisierung des Release Burndown Charts Das Review Meeting dient der Optimierung des Produktes!
Retrospektive Teilnehmer: Product Owner, Scrum Master, Team, ggfs. weitere Personen Ziel: Maßnahmen zur Verbesserung des Prozesses Findet zum Abschluss jedes Sprints statt! Regeln: Offene und ehrliche Kommunikation Konstruktive Kritik Trennung von Person und Sache Gegenseitiger Respekt Moderation durch den Scrum Master, außer er ist aktuell Teil des Problems, dann externer Moderator Es ist nicht notwendig, in einer Retrospektive direkt alle Themen zum Prozess erschöpfend bearbeiten zu müssen. Fokussierung auf die zwei oder drei wichtigsten. Zum Abschluss des nächsten Sprints gibt es ja die nächste Retrospektive Kaizen Die Retrospektive dient der Optimierung des Prozesses!
Ablauf einer Retrospektive (Beispiel) Check-In durch den Moderator (Begrüßung, Erläuterung von Ziel, Regeln und Ablauf, Stimmungsabfrage) Daten sammeln Alle Teilnehmer schreiben jeder für sich Punkte zum aktuellen Sprint auf Karten. Pro Karte ein Punkt. Klassifizierung der Punkte in positiv oder negativ. Dauer 5 0 Minuten Die Teilnehmer hängen nacheinander unsortiert ihre Karten an eine Metaplanwand. Pro Karte kurze Erklärung. Keine Diskussion! Wenn alle Karten hängen, dann gemeinsames Gruppieren der Karten in Themen. Solange bis ganze Gruppe damit zufrieden ist. Wenn gewünscht, Überschriften für Themen definieren Priorisierung der Themen durch Dot-Voting. Jeder Teilnehmer kann nach Belieben drei Klebepunkte auf die Themen verteilen. Die zwei oder drei Themen mit den meisten Klebepunkten werden in dieser Retrospektive bearbeitet Daten bearbeiten Pro Thema (höchsten drei in einer Retrospektive) feste Zeitbox vereinbaren Klären, was genau in diesem Sprint in diesem Thema passiert ist Gründe dafür analysieren Maßnahmen beschließen, mit denen das Thema ab dem nächsten Sprint geklärt werden kann Maßnahmen öffentlich aufhängen (Flipchartbogen oder Karteikarten an Wand im Teamraum) Metaretrospektive Wie ist die Retrospektive gelaufen und wie kann die nächste noch besser werden Check-Out durch den Moderator (Zusammenfassung der beschlossenen Maßnahmen, Bedanken für die gute Zusammenarbeit, Verabschiedung)
Dauer der Meetings Beispiel bei einem 4 Wochensprint (bei kürzeren Sprints entsprechend kürzer) Planning Meeting: 8 h Review Meeting: 4 h Retrospektive: 4 h Daily Scrum: maximal 5 min Schätzrunden: maximal 30 min (Ausnahme: Schätzen des initialen Product Backlog: -2 h) In der Retrospektive kann beschlossen werden, die Länge der Meetings anzupassen. Teams mit mehr Erfahrung werden nach und nach weniger lange für die Meetings benötigen
Zeitliche Organisation der Sprints Sprints nicht am Montag beginnen und am Freitag beenden! Beispiel für einen 4 Wochensprint: Donnerstag: Planning Meeting Sprint Freitag: Start Entwicklungsphase / Sprintarbeit vier Wochen später Dienstag Nachmittag: Eincheckstop / Code freeze Mittwoch Vormittag: Vorbereitung Review Meeting / Durchführung Review Meeting Mittwoch Nachmittag: Retrospektive Donnerstag: Planning Meeting Sprint 2 Es gibt keine Zeit außerhalb des Sprints!
Anforderungen
Anforderungen Anforderungen Product Owner Transformation Entwicklerteam Produkt Stakeholder
Customer # First name Last name Total sales $ 234 Robert Smith $ 2,956.00 6523 Nancy Smith $ 5,299.00 Cust.No. First name Last name search Als Sachbearbeiter möchte ich in einer Suchmaske Kundennummer, Vorname und/oder Nachname zu Kunden eingeben können und als Ergebnis eine Liste aller Kunden mit Kundennummer, Vorname, Nachname und Gesamtumsatz des letzten Jahres am Bildschirm sehen, die die Suchkriterien erfüllen.
Konkrete Beschreibung von Beispielfällen Verhalten als Ergebnis auf bestimmte Eingaben Nichtfunktionale Anforderungen Performance, Antwortzeiten, Einschränkungen, etc. Woran würde ich merken, dass die Anforderung erfüllt ist? Helfen dem Product Owner bei der sinnvollen Beschreibung der Anforderung Helfen dem Team bei der korrekten Umsetzung der Anforderung Sind die Basis für die Akzeptanztests Sind die Abnahmekriterien im Review Meeting
Jede Anforderung: soll einen Businessmehrwert generieren soll möglichst unabhängig von anderen sein soll möglichst klein sein muss in einem Sprint umsetzbar sein
Das Product Backlog
Product Backlog tabellarische Liste aller Anforderungen wird vom Product Owner gepflegt eindeutig priorisiert geschätzt lebendes Dokument (kein Einsendeschluss)
Fachkonzepte Sketches Big Picture Flow Charts Einzelne Anforderungen Story # Story Effort 470 2 47 5 472 473 2 477 2 393 3
Detaillierungsgrad Priorität nächster Sprint evtl. übernächster Sprint später
Prioritäten sehr wichtig wichtig normal wäre schön wird niemals gemacht das Product Backlog ist eindeutig priorisiert!
Risiko minimieren Business Value maximieren
Agiles Schätzen
agiles Schätzen eine Schätzung ist eine Schätzung Anforderungen können mehrfach geschätzt werden geschätzt wird immer durch das Team Schätzungen sind ein Hilfsmittel und kein eigener Mehrwert den Aufwand für das Schätzen möglichst gering halten
Schätzeinheiten Ideale Tage Story Points
Story Points ein relatives Schätzmaß Aufwand/Dauer/Komplexität/Risiko einer Anforderung im Verhältnis zu anderen Anforderungen Individuell für jedes Team
Fibonaccizahlenreihe als Story Points original Fibonaccizahlenreihe 0..2.3..5 8..3..2...34 55.34. angepasste Fibonaccizahlenreihe 0..2.3..5...8..3.20..40......00
0 = kein Aufwand = sehr kleiner Aufwand 2 = kleiner Aufwand 3 = mittlerer Aufwand 5 = großer Aufwand 8 = sehr großer Aufwand 3 = riesiger Aufwand 20 = unfassbarer Aufwand 40 = gigantischer Aufwand 00 = unmöglich/ absolut keine Idee
Team Estimation Game schnelles Schätzen einer großen Anzahl von Anforderungen in kurzer Zeit gut geeignet zum Schätzen des initialen Product Backlogs Ablauf: Alle Anforderungen sind als Karten in einem Stapel vorhanden Jedes Teammitglied agiert nacheinander und hat dabei folgenden Optionen: Neue Karte ziehen: Karte vom PO erklären lassen und an der Wand einsortieren im Verhältnis zu anderen Karten. Oberhalb ist weniger Aufwand, unterhalb mehr Aufwand, rechts daneben genauso viel Aufwand. Entscheidung mit einem Satz begründen, der Rest der Gruppe kommentiert das nicht! Karte umhängen: Eine Karte an der Wand umhängen, Klebepunkt anbringen, kurz erklären, keine Diskussion! Passen: Diese Runde aussetzen. Passen alle Teammitglieder in der Runde, ist diese Phase des Team Estimation Game beendet Das Ganze solange bis alle Karten an der Wand hängen oder alle Teammitglieder in einer Runde gepasst haben Anlegen der Metrik links neben die Gruppen, dabei Fragen, ob die oberste Gruppe wirklich kein Aufwand ist oder eher ein sehr kleiner Aufwand Weiterspielen und dabei im Verhältnis der Metrik evtl. Gruppen zusammenfassen oder Anforderungen umhängen. Solange bis Team vollständig damit einverstanden. Werte bei allen Anforderungen vermerken
Planning Poker Gut geeignet, um schnell weitere Anforderung für das Backlog schätzen zu können Jedes Teammitglied hat ein Kartenset bestehend aus allen verfügbaren Schätzwerten Ablauf pro Story: Product Owner liest Story vor und erklärt kurz Jedes Teammitglied schätz für sich den Aufwand und legt die entsprechende Karte verdeckt vor sich ab Wenn alle eine Schätzung abgelegt haben, decken alle gemeinsam auf Der mit dem niedrigsten und der mit dem höchsten Wert erklären kurz, warum dieser Wert. Die anderen diskutieren nicht mit! Danach neu schätzen Das ganze solange, bis ganze Gruppe einen gemeinsamen Wert hat. Ab dem dritten Durchlauf für eine Anforderung ist auch Handeln untereinander erlaubt
Die Qualität
Testen & Qualität in Scrum Idealziel: Jeder Sprint erzeugt ein potentiell auslieferbares Produktinkrement! Es gibt keine separate Testphase, die Qualität wird bereits beim Erstellen des Produktes erzeugt/sichergestellt Das Team ist verantwortlich für die technische Qualität des Produktes Qualität ist nicht verhandelbar technische Schulden Maßnahmen: Definition von Akzeptanzkriterien als teil der Anforderungsdefinition Tester (technisch/fachlich sind Teil des Teams) Tester testen direkt nach der Erstellung eines Features Tester arbeiten schon bei der Erstellung eines Features zusammen mit dem Entwickler Pair Programming Test Driven Development (TDD) Testautomatisierung Continuous Integration Erstellung einer Definition of Done durch Team und Product Owner Das Review Meeting ist nicht der früheste sondern der späteste Zeitpunkt, an dem der Product Owner neue Features gezeigt bekommt (ist bereits wären der Entwicklungsphase äußerst erwünscht)
Wann im Release testen? Testen erst Sprint Sprint 2 Sprint 3 im Releasesprint Release Sprint Testen im Sprint Sprint Sprint 2 Sprint 3
Wann im Sprint testen? Testen am Ende des Sprints Entwicklung Test Testen während des gesamten Sprints Entwicklung Test
Scrum Board mit Testphase backlog in process test done Sprint Burndown Story Item Item Item Item Story Item Item Item Item Story Item Item Item Item Item Impediments Impediment Story Item Story Item Item Item Item Item Item Item Item Impediment Impediment
Featuresprint Sprintarten neue Produktfeatures (neue Business Values) werden erstellt Erzeugt idealerweise ein potentiell auslieferbares Produktinkrement Releasesprint Der aktuelle Produktstand wird releasefähig gemacht (testen, dokumentieren, etc.) Nur notwendig, wenn nicht innerhalb der Featuresprints ein potentiell auslieferbares Produktinkrement erzeugt werden kann Explorationssprint Technisches oder fachliches Wissen wird erzeugt, um Anorderungen schätzen und planen zu können Es werden keine Features erzeugt, dieser Sprint erzeugt nur Wissen!
Releasemanagement
Planen in Scrum Wir planen in Scrum! so viel, wie sinnvoll nötig so wenig, wie sinnvoll möglich Je weiter in der Zukunft eine geplante Tätigkeit liegt, umso größer die Wahrscheinlichkeit, dass sie nicht oder anders als geplant durchgeführt wird Verschwendung der Zeit, die für das Planen verwendet wurde
Quelle: Mike Cohn Agile Estimating and Planning Cone of Uncertainty
Releasemanagement in Scrum Das Releasemanagement wird durch den Product Owner durchgeführt Das Projekt wird mit dem Product Backlog geplant und gesteuert Das Product Backlog ist ein offenes Dokument, d.h. es können jederzeit neue Anforderungen hinzukommen Der Velocity Report dokumentiert die Entwicklung der Entwicklungsgeschwindigkeit im Projekt und hilft bei der Einschätzung des zukünftigen Verlaufs Der Release Burndown Chart zeigt den aktuellen Projektfortschritt und die Entwicklung im Projekt. Er ermöglicht Prognosen über den Fertigstellungstermin
Velocity Report Realisierter Aufwand 00 95 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 5 0 5 Entwicklungsgeschwindigkeit des Teams Dokumentation der realisierten Aufwandspunkte im jeweiligen Sprint (rote Linien) Aktuelle Durchschnittsgeschwindigkeit (blaue Linie) Instrument für die Prognose der zukünftigen Entwicklungsgeschwindigkeit 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 20 Sprint
Release Burndown Chart Restaufwand 200 90 Den im Release verbliebenen Restaufwand eintragen (rote Linie) 80 70 60 50 40 30 20 0 00 90 80 70 60 50 40 30 20 0 Der Aufwand zu einer Story/einem Feature wird immer ganz oder gar nicht berücksichtigt nach jedem Sprint (Review Meeting) aktualisieren Kurve zeigt den Verlauf des Releasefortschritts an Durch Anlegen der aktuellen Entwicklungsgeschwindigkeit (aus dem Velocity Report) Prognose für den Fertigstellungstermin (blaue Linien) 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 20 Sprint
Einfache Releaseplanung (im Product Backlog) Realisierter Aufwand 00 95 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 5 0 5 2 3 Durchschnittliche Velocity 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 2 0 Sprint Achtung: Das ist nur eine Prognose! Sprint 7 Sprint 8 Sprint 9 Sprint 0 Sprint Sprint 2 Sprint 3 Sprint 4 Sprint 5 Story # Story Effort 470 Customer Search Formular 2 47 Schufa Information View 5 472 Changing Password for Customer 473 One-Click-Delete 2 477 Selection of new Colors 2 393 Logout with Browser Dropdown 3 470 Customer Search Formular 2 47 Schufa Information View 8 472 Changing Password for Customer 3 473 One-Click-Delete 477 Selection of new Colors 5 393 Logout with Browser Dropdown 5 470 Customer Search Formular 2 47 Schufa Information View 8 472 Changing Password for Customer 473 One-Click-Delete 2 477 Selection of new Colors 3 393 Logout with Browser Dropdown 3 470 Customer Search Formular 2 47 Schufa Information View 5 472 Changing Password for Customer 3 473 One-Click-Delete 3 477 Selection of new Colors 2 393 Logout with Browser Dropdown 5 470 Customer Search Formular 2 47 Schufa Information View 5 472 Changing Password for Customer 473 One-Click-Delete 5 477 Selection of new Colors 8 393 Logout with Browser Dropdown 3 470 Customer Search Formular 2 47 Schufa Information View 20 472 Changing Password for Customer 473 One-Click-Delete 2 477 Selection of new Colors 20 393 Logout with Browser Dropdown 8 470 Customer Search Formular 3 47 Schufa Information View 5 472 Changing Password for Customer 473 One-Click-Delete 20 477 Selection of new Colors 3 393 Logout with Browser Dropdown 3
Pflege des Product Backlogs Priority Minimum Required Feature Set Optional
Unsicherheiten in der Vorhersage und der Projektfortschritt (siehe auch Cone of Uncertainty) Restaufwand Restaufwand 200 90 80 70 60 50 40 30 20 0 00 9 0 8 0 7 0 6 0 5 0 4 0 3 0 2 0 0 200 90 80 70 60 50 40 30 20 0 00 9 0 8 0 7 0 6 0 5 0 4 0 3 0 2 0 0 2 3 4 5 6 7 8 9 0 2 3 Unsicherheit nach Sprint 4 4 5 6 7 8 9 2 0 Sprint 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 Unsicherheit nach Sprint 9 8 9 2 0 Sprint
Skalierung in Scrum
Skalierung in Scrum Organisation bei nur einem Team. Teamgröße maximal 9 Personen! PO Product Backlog Team SM
Skalierung in Scrum Organisation bei drei Teams. Teamgröße pro Team immer noch maximal 9 Personen! Product Owner Team CPO PO PO Team A Team B Team C SM
Skalierung in Scrum Szenario: Projekt besteht aus drei Teilsystemen, die Anforderungen sind gut auf die Teilsysteme aufteilbar. Jedes Team betreut ein Teilsystem. Für jedes Teilsystem wird jeweils ein Product Backlog gepflegt. Product Owner Team CPO PO PO Product Backlog Product Backlog Product Backlog Team A Team B Team C Planning Meeting Planning Meeting Planning Meeting Review Meeting Retrospective Retrospective Retrospective Jede 3. oder 4. Retrospektive zusammen
Skalierung in Scrum Szenario: Projekt besteht aus einem großen System, die Anforderungen sind nicht auf Teilsysteme aufteilbar. Alle Team arbeiten parallel auf der gemeinsamen Code Basis, es wird nur ein Product Backlog gepflegt. Product Owner Team CPO PO PO Product Backlog Team A Team B Team C Planning Meeting Part Planning Meeting Part 2 Review Meeting Retrospective Retrospective Retrospective Jede 2. Retrospektive zusammen
Scrum of Scrums Bei mehreren Scrum Teams im gleichen Projekt notwendig zur Abstimmung der Teams untereinander Vertreter aller Teams treffen sich zu einer Art Daily Scrum und beantworten für ihr Team folgende drei Fragen: Was haben wir seid dem letzten Scrum of Scrums gemacht? Was planen wir bis zum nächsten Scrum of Scrums zu machen? Was behindert uns derzeit? Keine Diskussion, wenn hier Abstimmungsbedarf festgestellt wird, beauftragen die Teamvertreter die jeweils Betroffenen in ihren Teams damit, sich mit den Betroffenen in den anderen Teams abzustimmen Findet alle ein bis drei Tage statt, je nachdem wie viel Abstimmungsaufwand in der Regel notwendig ist
Arten von Teams Featureteam Erstellt immer komplette Features durch alle Komponenten hindurch Durchstich Komponententeam Erstellt Funktionalität nur innerhalb einer Komponente. Keine kompletten vom Endbenutzer nutzbare Features Featureteam Komponententeam Featureteam Featureteam Featureteam UI Logik DB Komponententeam Komponententeam Komponententeam
Featureteam Featureteam Featureteam UI Logik Komponententeam DB
Projekte mit mehreren Teams und Querschnittsfunktionen Team A Team B Team C Team D Scrum Master Gruppe Entwickler Gruppe Tester Gruppe Integratoren SW Architekten Gruppe
Das Ende (fast)
Trivia Eine Einführung von Scrum betrifft alle Teile eines Unternehmens, die mit dem zu erstellenden Produkt zu tun haben Den größten Vorteil erzielt Scrum bei stabilen Teams mit längeren Projektlaufzeiten, da hier die Prozessverbesserungen besser zur Geltung kommen Da direkte Kommunikation ein Schlüsselfaktor von Scrum ist, ist räumliche Nähe sowohl innerhalb des Teams wie auch zwischen Team und Product Owner/Stakeholder von Vorteil
Bücher Weitere Quellen Scrum Agiles Projektmanagement erfolgreich einsetzen, Roman Pichler Agile Softwareentwicklung: Mit Scrum zum Erfolg!, Mike Cohn User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a., Mike Cohn Agile Estimating and Planning, Mike Cohn Management 3.0: Leading Agile Developers, Develope Agile Leaders, Jurgen Appelo PDFs Scrum and XP from the Trenches, Henrik Kniberg http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Podcasts Scrumidable, Carsten Czeczine http://www.scrumidable.de Videovortrag Scrum Was ist das?, Carsten Czeczine http://rheinjug.de/videos/gse.lectures.app/talk.html#scrum