Scrum: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Rkr (Diskussion | Beiträge) |
Rkr (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
||
Zeile 36: | Zeile 36: | ||
*Anforderungen mit den größten Risiken werden zuerst angegangen (um schnell andere Richtung einschlagen zu können) | *Anforderungen mit den größten Risiken werden zuerst angegangen (um schnell andere Richtung einschlagen zu können) | ||
*Aufgaben/Features sind erst erledigt und werden "released", wenn wirklich alles fertig ist (auch Doku etc.) | *Aufgaben/Features sind erst erledigt und werden "released", wenn wirklich alles fertig ist (auch Doku etc.) | ||
*Sprint-Ende wird niemals verlängert | |||
===Scrum erfordert=== | ===Scrum erfordert=== | ||
Zeile 47: | Zeile 48: | ||
**Team wählt aus dem Product Backlog Anforderungen aus, die im Sprint umgesetzt werden sollen. Diese werden ins Sprint Backlog übernommen. | **Team wählt aus dem Product Backlog Anforderungen aus, die im Sprint umgesetzt werden sollen. Diese werden ins Sprint Backlog übernommen. | ||
*Daily Scrum Meeting (alle, Product Owner optional) | *Daily Scrum Meeting (alle, Product Owner optional) | ||
**Jedes | **Jedes Team-Mitglied berichtet über seine Aktivitäten der letzten Arbeitsstunden und über die nächsten Schritte. Hindernisse werden angesprochen. | ||
*Sprint Review Meeting (alle) | *Sprint Review Meeting (alle) | ||
**Arbeitsergebnisse werden dem Product Owner vorgestellt und von diesem abgenommen. | **Arbeitsergebnisse werden dem Product Owner vorgestellt und von diesem abgenommen. | ||
Zeile 59: | Zeile 60: | ||
*ist verantwortlich für das Produkt (Deliverables) bzw. Ergebnisse des Projekts | *ist verantwortlich für das Produkt (Deliverables) bzw. Ergebnisse des Projekts | ||
*vereint die klassischen Rollen des Produktmanagers (Chief Engineer), des Projektmanagers (aus Business-Sicht) und in Teilen des Solutionmanagers | *vereint die klassischen Rollen des Produktmanagers (Chief Engineer), des Projektmanagers (aus Business-Sicht) und in Teilen des Solutionmanagers | ||
*erstellt und pflegt Produktvision ( | *erstellt und pflegt Produktvision (Releaseplan, Big Picture) | ||
*ist verantwortlich für finanzielle Ergebnisse und wirtschaftliche Ziele (Budget, Marge) | *ist verantwortlich für finanzielle Ergebnisse und wirtschaftliche Ziele (Budget, Marge) | ||
*Schnittstelle zwischen Team und Stakeholdern (Kunde, Vertrieb, Support, 3rd Party, etc.) | *Schnittstelle zwischen Team und Stakeholdern (Kunde, Vertrieb, Support, 3rd Party, etc.) | ||
Zeile 76: | Zeile 77: | ||
*eigenverantwortlich für Produktentwicklung und technische Umsetzung | *eigenverantwortlich für Produktentwicklung und technische Umsetzung | ||
*organisiert sich selbst (ohne Leader) | *organisiert sich selbst (ohne Leader) | ||
*legt selbst verbindlich fest, welche Anforderungen (Requirements) zu einer vorgegebenen Zeit (Sprint) bearbeitet und als User Stories umgesetzt werden (Commitment) | *legt selbst verbindlich fest, welche und wieviele Anforderungen (Requirements) zu einer vorgegebenen Zeit (Sprint) bearbeitet und als User Stories umgesetzt werden (Commitment) | ||
*erstellt sich selbst Aufgaben (Tasks), um die Features (User Stories) umzusetzen | *erstellt sich selbst Aufgaben (Tasks), um die Features (User Stories) umzusetzen | ||
*wähle kleine Tasks <= 1 Arbeitstag | |||
*dokumentiert Zustand der Tasks im Sprint Backlog (mit Angabe der noch benötigten Zeit) | *dokumentiert Zustand der Tasks im Sprint Backlog (mit Angabe der noch benötigten Zeit) | ||
*Nicht die Zahl der Arbeitsstunden zählt sondern der geleistete Mehrwert | |||
*80% der Arbeitszeit als Netto-Auslastung für das Projekt (Kapazität) | |||
=== Scrum Master === | === Scrum Master === | ||
*in Teilen mit der klassischen Rolle des Projektmanagers vergleichbar (nur als Projektbegleiter) | *in Teilen mit der klassischen Rolle des Projektmanagers vergleichbar (nur als Projektbegleiter), ist aber nicht der Projekt Manager | ||
*Agile Leader, Team-Coach, Moderator | *Agile Leader, Team-Coach, Moderator | ||
*verantwortlich für Einhaltung der Scrum-Regeln und Methoden | *verantwortlich für Einhaltung der Scrum-Regeln und Methoden | ||
Zeile 97: | Zeile 101: | ||
*Anpassung an Unternehmensstrukturen nötig | *Anpassung an Unternehmensstrukturen nötig | ||
*Es ist nicht immer einfach, Prioritäten bei vielen Stakeholdern zu bestimmen. | *Es ist nicht immer einfach, Prioritäten bei vielen Stakeholdern zu bestimmen. | ||
*Beseitigung von Risiken und Hindernissen oft nicht in der Hand des Projekts (je weniger man abhängig ist von äußeren Einflüssen desto besser) | *Beseitigung von Risiken und Hindernissen oft nicht in der Hand des Projekts (je weniger man abhängig ist von äußeren Einflüssen desto besser) -> externe Abhängigkeiten | ||
*Alle am Produkt beteiligten müssen Scrum verstehen und daran beteiligt sein | *Alle am Produkt beteiligten müssen Scrum verstehen und daran beteiligt sein | ||
*Das Scoping im Team muss mit den Kundenwünschen übereinstimmen, was über die Priorität gesteuert wird. Das muss dem Kunden aber auch so "verkauft" worden sein. | *Das Scoping im Team muss mit den Kundenwünschen übereinstimmen, was über die Priorität gesteuert wird. Das muss dem Kunden aber auch so "verkauft" worden sein. |
Version vom 17. September 2009, 12:39 Uhr
Überblick
Was ist Scrum
- Scrum ist eine Methodologie bzw. ein Vorgehensmodell für die Entwicklung von Produkten
- iterativer und inkrementeller Prozess
- für Produktentwicklung und Projektmanagement
- oft und ursprünglich in der Softwareentwicklung
- klassische Rollen und Strukturen werden ersetzt durch agile Methoden und Abläufe
Vorteile von Scrum
Wenn Scrum richtig angewandt wird, können sich folgende Vorteile ergeben:
- schnellere Reaktion auf Kundenanforderungen durch frühzeitige Rückmeldungen
- schneller Richtungswechsel möglich
- klares Scoping gemäß Wert für den Kunden
- kleine Produkt-Inkrements (Releases) mit wenigen Features, die dann aber auch funktionieren
- kein endloses Entwickeln (mit zu vielen Features)
- Ergebnisse sind schneller am Markt / beim Kunden
- höhere Identifikation der Beteiligten am Produkt
- größere Kreativität, Effizienz und Produktivität (und damit auch die Mitarbeiterzufriedenheit)
- bessere Produkte
Drei Rollen
Scrum kennt drei gleichberechtigte Management-Rollen:
- Product Owner
- Scrum Master
- Team
Eigenschaften von Scrum
- eingeteilt in Sprints (kurze zeitliche Projektabschnitte bzw. Arbeitszyklen) fester Länge
- basiert oft auf Schätzungen (Zeit)
- hohes Maß an Selbstorganisation (kein Teamleiter vorhanden)
- Kundenzufriedenheit und Menschen stehen im Mittelpunkt (Vermeidung von Überlastungen)
- Arbeitsweise und das Produkt werden fortlaufend bewertet und angepasst
- Es werden nur Anforderungen umgesetzt, die einen Mehrwert bieten
- Anforderungen mit höchster Priorität werden zuerst angegangen
- Anforderungen mit den größten Risiken werden zuerst angegangen (um schnell andere Richtung einschlagen zu können)
- Aufgaben/Features sind erst erledigt und werden "released", wenn wirklich alles fertig ist (auch Doku etc.)
- Sprint-Ende wird niemals verlängert
Scrum erfordert
- große Disziplin
- hohe Selbstverantwortung
- direkte Kommunikation aller Beteiligten (möglichst räumlich nahe)
- Umdenken bei allen Beteiligten bzgl. der Rollen
Organisation
- Sprint Planning Meeting (alle)
- Team wählt aus dem Product Backlog Anforderungen aus, die im Sprint umgesetzt werden sollen. Diese werden ins Sprint Backlog übernommen.
- Daily Scrum Meeting (alle, Product Owner optional)
- Jedes Team-Mitglied berichtet über seine Aktivitäten der letzten Arbeitsstunden und über die nächsten Schritte. Hindernisse werden angesprochen.
- Sprint Review Meeting (alle)
- Arbeitsergebnisse werden dem Product Owner vorgestellt und von diesem abgenommen.
- Sprint Retrospektive Meeting (alle)
- Reflexion des Sprints
- Was war gut bzw. schlecht ? Was kann verbessert werden ?
- Product Backlog und Sprint Backlog als wichtige Mittel zur Dokumentation des Projekts
Rollen
Product Owner
- ist verantwortlich für das Produkt (Deliverables) bzw. Ergebnisse des Projekts
- vereint die klassischen Rollen des Produktmanagers (Chief Engineer), des Projektmanagers (aus Business-Sicht) und in Teilen des Solutionmanagers
- erstellt und pflegt Produktvision (Releaseplan, Big Picture)
- ist verantwortlich für finanzielle Ergebnisse und wirtschaftliche Ziele (Budget, Marge)
- Schnittstelle zwischen Team und Stakeholdern (Kunde, Vertrieb, Support, 3rd Party, etc.)
- erstellt Requirements aus den Kundenanforderungen (im Product Backlog)
- in Zusammenarbeit mit dem Kunden
- sortiert nach Priorität gemäß Wert für den Kunden (Business Value)
- möglichst über den nächsten Sprint hinweg (im voraus)
- erstellt User Stories (im Product Backlog)
- detaillierte Beschreibung dessen, was vom Team geliefert werden soll (Features)
- aus Sicht des Kunden und anderer Stakeholder
- prüft Ergebnisse des Teams am Ende des Sprints (Abnahme)
- prüft Qualität
- Eigenschaften: kommunikativ, diplomatisch, technisches Wissen
Team
- eigenverantwortlich für Produktentwicklung und technische Umsetzung
- organisiert sich selbst (ohne Leader)
- legt selbst verbindlich fest, welche und wieviele Anforderungen (Requirements) zu einer vorgegebenen Zeit (Sprint) bearbeitet und als User Stories umgesetzt werden (Commitment)
- erstellt sich selbst Aufgaben (Tasks), um die Features (User Stories) umzusetzen
- wähle kleine Tasks <= 1 Arbeitstag
- dokumentiert Zustand der Tasks im Sprint Backlog (mit Angabe der noch benötigten Zeit)
- Nicht die Zahl der Arbeitsstunden zählt sondern der geleistete Mehrwert
- 80% der Arbeitszeit als Netto-Auslastung für das Projekt (Kapazität)
Scrum Master
- in Teilen mit der klassischen Rolle des Projektmanagers vergleichbar (nur als Projektbegleiter), ist aber nicht der Projekt Manager
- Agile Leader, Team-Coach, Moderator
- verantwortlich für Einhaltung der Scrum-Regeln und Methoden
- verantwortlich für das Beseitigen von Hindernissen und Konflikten, die das Team am weiterentwickeln hindern
- schafft optimale Arbeitsbedingungen für das Team (Infrastruktur, Kommunikation, Tools, etc.)
- sollte kein Entwickler sein (höchstens in einem anderen Projekt), da er sonst nicht objektiv genug seine Rolle wahrnehmen kann
- auch hat er keine Personalverantwortung für das Team
- Bindeglied zwischen Product Owner und Team, aber letztendlich nicht verantwortlich für Projekterfolg
- je besser das Team Scrum anwendet, desto geringer wird die Rolle des Scrum Masters
Probleme und Schwierigkeiten
- Team soll eigentlich die Anforderungen (Requirements) mit höchster Priorität bearbeiten, was viel Disziplin erfordert
- Product Owner muss viele Talente (Skills) haben: Bei komplexen Themen und großen Projekten ggf. ein Product Owner Team bilden
- Neue Rolle für den klassischen Projektmanager bestimmen: Product Owner (Business, Budget, Customer, Controlling) oder Scrum Master (Agile Leader, Prozess, als Projektbegleiter)
- Anpassung an Unternehmensstrukturen nötig
- Es ist nicht immer einfach, Prioritäten bei vielen Stakeholdern zu bestimmen.
- Beseitigung von Risiken und Hindernissen oft nicht in der Hand des Projekts (je weniger man abhängig ist von äußeren Einflüssen desto besser) -> externe Abhängigkeiten
- Alle am Produkt beteiligten müssen Scrum verstehen und daran beteiligt sein
- Das Scoping im Team muss mit den Kundenwünschen übereinstimmen, was über die Priorität gesteuert wird. Das muss dem Kunden aber auch so "verkauft" worden sein.
- da Product Owner und Scrum Master nicht Mitglied des Entwicklungsteams sein sollen, sind mindestens 4-5 Personen pro Scrum-Projekt nötig.
- Je größer das Projekt ist und je mehr Entwicklungsprojekte involviert sind, desto umfassender müssen die Anpassungen im Unternehmen sein (Enterprise Scrum).
- Das Team soll die für die Entwicklung nötigen Tools selbst aussuchen können. Je nach Projekt sind verschiedene Tools nötig, die ggf. im Unternehmen nicht "unterstützt" werden. Beispiel: Revision Control Systeme.
- wie werden Change Requests bearbeitet ?
Literatur / weitere Infos
- Scrum in der Wikipedia, en
- Agile Softwareentwicklung in der Wikipedia
- Scrum Alliance
- Scrum Methodology
- UserStories.com
- Introduction of Scrum Agile Process - Development (mountaingoatsoftware.com)
- Agile Modeling
- inside-scrum Blog (de)
- Agile FAQ Blog
- Agile24 (Agilo for Scrum)
- Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag; ISBN: 3898644782