Scrum: Unterschied zwischen den Versionen

aus www.kruedewagen.de, Homepage von Ralf und Judith Krüdewagen (Kruedewagen)
Zur Navigation springen Zur Suche springen
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 Teammitglied berichtet über seine Aktivitäten der letzten Arbeitsstunden und über die nächsten Schritte
**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 (Roadmap, Big Picture)
*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:38 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 - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag; ISBN: 3898644782

Siehe auch