Einführung in SCRUM. Helge Baier

Größe: px

Ab Seite anzeigen:

Download "Einführung in SCRUM. Helge Baier 21.01.2010"

Kornelius Adenauer
vor 8 Jahren
Abrufe

1 Einführung in SCRUM Helge Baier

2 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische Scrum Erfahrung bei der Verlagsgruppe Weltbild

Entwicklung Zertifizierung zum Scrum Master (2009)

3 Agenda 1 Überblick 2 Rollen 3 Meetings 4 Artefakte 5 SCRUM@Weltbild IT/E-Commerce

4 Überblick Begriff Scrum ist die englische Bezeichnung für eine Spielsituation im Rugby ( Gedränge) Historie Scrum wurde erstmals 1986 im Artikel "The New New Product Development Game von Hirotaka Takeuchi und Ikujiro Nonaka beschrieben Anfang der 90er Jahre entwickelten Ken Schwaber und Jeff Sutherland Scrum für die Software- Entwicklung

Development Game von Hirotaka Takeuchi und Ikujiro Nonaka beschrieben Anfang der

5 Scrum Theorie Scrum ist ein Rahmenwerk für die Entwicklung komplexer Produkte und Systeme. Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und Risikokontrolle basiert auf der Theorie der empirischen Prozessteuerung, die auf 3 Säulen aufgebaut ist: Transparenz Inspektion Adaption [Quelle: SCRUM Alliance]

Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der

6 Der Scrum Prozess [Quelle: Sprint IT / Andreas Schliep]

7 Scrum passt auf einen Bierdeckel... [Quelle: it agile GmbH]

8 Agenda 1 Überblick 2 Rollen 3 Meetings 4 Artefakte 5 SCRUM@Weltbild IT/E-Commerce

9 Rollen Primäre Scrum Rollen Product Owner Team ScrumMaster Sekundäre Rollen Kunde Lieferant Manager.

10 Der Product Owner ist verantwortlich für den Erfolg der gesamten Entwicklungsvorhaben eines Produktes oder einer Produktlinie. bringt die Produktvision ins Team. beschreibt die Anforderungen und verwaltet das Product Backlog. erstellt den Releaseplan und die Releaseberichte. managt die Stakeholder und arbeitet eng mit dem Team während der gesamten Projektlaufzeit zusammen.

beschreibt die Anforderungen und verwaltet das Product Backlog.

11 Das Team ist verantwortlich für die Lieferung produktionsreifer Ergebnisse. besteht aus unterschiedlichen Spezialisten, damit alle notwendigen Kenntnisse zur Realisierung des Produktes vorhanden sind. muss die Vision und die Sprint Ziele des Product Owners verstehen, um funktionsfähige Produktinkremente zu liefern. agiert selbstorganisiert und besteht idealerweise aus 5 bis 9 Mitgliedern.

12 Der ScrumMaster ist verantwortlich für die Einhaltung des Prozesses. unterstützt und beschützt das Team. stellt die direkte Arbeit zwischen ProductOwner und Team sicher. verwaltet das Impediment-Backlog, beseitigt Hindernisse und hilft dem Team, seine Produktivität kontinuierlich zu steigern. ist der Trainer und Moderator des Teams. hält die "Inspektion und Adaption" Zyklen von Scrum unter Kontrolle.

verwaltet das Impediment-Backlog, beseitigt Hindernisse und hilft dem Team, seine Produktivität

13 Agenda 1 Überblick 2 Rollen 3 Meetings 4 Artefakte 5 SCRUM@Weltbild IT/E-Commerce

14 Meetings Daily Scrum Sprint Planning Sprint Review Sprint Retrospektive Estimation Meeting

15 Daily Scrum ist ein Abstimmungsmeeting für die Teammitglieder. findet jeden Tag zur gleichen Zeit und am gleichen Ort statt. Die Dauer des Meetings ist auf 15 Minuten beschränkt. jedes Teammitglied beantwortet die folgenden 3 Fragen: Was habe ich seit dem letzten Daily Scrum erreicht? Was hat mich daran behindert? Was werde ich bis zum nächsten DailyScrum erreichen?

Die Dauer des Meetings ist auf 15 Minuten beschränkt.

16 Sprint Planning I + II Sprint Planning I Das Team und der Product Owner bestimmen gemeinsam das Sprint-Ziel (Goal) und das Selected Product Backlog (Liste der zu implementierenden Funktionalitäten für den kommenden Sprint), basierend auf der Aufwandsschätzung, der Priorität und der aktuellen Situation im Team. Sprint Planning II Während des Sprint Planning II erarbeitet das Team das prinzipielle Design der zu liefernden Arbeitsergebnisse und definiert Arbeitschritte (Tasks) zu jedem Backlog-Eintrag. Der Aufwand für einen Task sollte nicht größer als ein Arbeitstag sein.

17 Sprint Review Besprechung, die am Ende des Sprints stattfindet. Ziel der Sitzung ist es, die entstandenen Arbeitsergebnisse zu begutachten und den Projektfortschritt transparent zu machen. der ProductOwner überprüft, ob das Team alle Anforderungen, zu denen es sich verpflichtet hat, erfolgreich umgesetzt hat.

und den Projektfortschritt transparent zu machen.

18 Sprint Retrospektive Besprechung, die am Ende des Sprints im Anschluss an das Sprint Review stattfindet. Zielsetzung ist, die Zusammenarbeit innerhalb des Teams und die Anwendung des Prozesses zu verbessern. Analysieren und Verbessern" ist eines der grundlegenden Prinzipien von Scrum.

Zielsetzung ist, die Zusammenarbeit innerhalb des Teams und die

19 Estimation Meeting Der Product Owner und das Team erarbeiten gemeinsam die Aufwandsschätzung des gesamten Product Backlogs (Anforderungsliste). Diese wird als Basis für die Release- und Sprint-Planungen benutzt. Das Team trifft sich regelmäßig mit dem Product Owner, um neue Features zu schätzen.

Diese wird als Basis für die Release- und Sprint-Planungen benutzt.

20 Agenda 1 Überblick 2 Rollen 3 Meetings 4 Artefakte 5 SCRUM@Weltbild IT/E-Commerce

21 Artefakte Vision User Story Product Backlog Selected Product Backlog / Sprint Backlog Sprint Burndown Chart Release Burndown Chart Impediment Backlog

22 Vision Kommunikation strategischer Idee kurz, prägnant, plakativ einprägsam, allen Beteiligten verständlich von den Beteiligten teilbar ambitioniert, motivierend akzeptiert

23 User Story kurze Beschreibung einer (funktionalen) Anforderung aus der Sicht des Anwenders. besteht aus einem Namen, aus einer kurzen textuellen Beschreibung der Anforderung und aus Akzeptanzkriterien. üblicherweise wird folgende Form verwendet: Als <Benutzerrolle> möchte ich <Funktionalität> so dass <Begründung>

24 Product Backlog Liste von User Stories strenge Reihenfolge nach Wichtigkeit ( Business Value ) Schätzung durch das Team verwaltet vom Product Owner Änderungen nach jedem Sprint Basis für Sprint- und Releaseplanung

25 Selected Product Backlog ist das Zwischenergebnis der Sprint-Planung. definiert die Menge der Stories, die das Team am Ende des Sprints liefern will. bleibt während des ganzen Sprints unverändert.

26 Sprint Backlog beinhaltet alle Tasks (Aktivitäten), die zur Umsetzung der Stories aus dem Selected Product Backlog notwendig sind. das Team benutzt es, um die Arbeit der Teammitglieder zu synchronisieren.

27 Sprint Burndown Chart Diagramm, das den Fortschritt im Sprint visualisiert. stellt die erledigten Tasks auf Tagesbasis dar. Beispiel:

28 Release Burndown Chart Diagramm, das den Fortschritt eines Releases visualisiert. führt die Summe der Aufwände im Product Backlog am Ende jedes Sprints auf und stellt somit die verbleibende Arbeit am Produkt bzw. am Release über die Zeit dar. Beispiel:

29 Impediment Backlog Liste von Hindernissen und Problemen, die das Team in seiner Arbeit behindern. der ScrumMaster besitzt das Impediment Backlog. das aus dem Weg Schaffen der Impediments ist der wichtigste Beitrag des Scrum Masters für das Team.

30 Agenda 1 Überblick 2 Rollen 3 Meetings 4 Artefakte 5 SCRUM@Weltbild IT/E-Commerce

31 IT/E-Commerce Treibende Kraft hinter der Einführung von Scrum: Stefan Korsch, Bereichsleiter IT/E-Commerce vorerst nur im Bereich IT / E- Commerce Bereichsleitung Abteilungsleitung Abteilungsleitung Abteilungsleitung TL TL TL TL TL TL Team Team Team Team Team Team

32 Die Ausgangssituation unterschiedliche fachliche und technologische Spezialisierungen der Mitarbeiter bedingt u.a. durch heterogene Systeme. mehrere organisatorische Teams, fachlich von Teamleitern geführt. die meisten Teams sind sowohl für die Entwicklung als auch den Betrieb einer Komponente bzw. eines Systems verantwortlich. kein klassisches Vorgehensmodell. Projekte mit unterschiedlichen Projektleitern konkurrieren um Ressourcen.

33 Die Scrum Implementierung sonstige Fachbereiche "CPO" I PO Entwicklungsteam 1 PO "Shared Services" PO Entwicklungsteam 2 Hindernisse Backlog Backlog Backlog I Hindernis- Liste ScrumMaster I I I Scrum of Scrums I

34 Positive Erfahrungen + direkte Kommunikation zwischen Entwicklern und Fachbereich (PO) + höhere Transparenz und besseres Verständnis für die Arbeit der anderen Teammitglieder + Bessere Planungs- und Steuerungsmöglichkeit für die Fachbereiche + Steigerung des Projektdurchsatzes

35 Was nicht optimal ist - Projektleiter in der Rolle des Product Owners - Steuerung des Betriebs mit Scrum - mehrere Entwicklungsteams mit verschiedenen unabhängigen Product Backlogs, die am gleichen Code arbeiten - gemeinsame Verantwortung = keine Verantwortung? - mehrere Backlogs / Product Owner für ein Team - Umgang mit Kleinanforderungen - Spezialisierung vs. Generalisierung

36 Fragen

37 Quellen & weiterführende Links it agile GmbH: Henrik Kniberg, Scrum and XP from the Trenches, Andreas Schliep (Scrum Coach & Trainer): Scrum Alliance: Ken Schwaber: Sprint IT: Jeff Sutherland: Takeuchi H., Nonaka I., The new new product development game, Harvard Business Review, v64, 1986, S

Ähnliche Dokumente

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische