Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Scrum

Agile Softwareentwicklung
by

reto kuhn

on 3 February 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Scrum

Scrum
Agile Softwareentwicklung
70er Jahre – buffered production
Geschichte
Winston Royce beschreibt das Wasserfallmodell in seiner Publikation «Managing the Development of Large Software Systems» aus dem Jahr 1970 als fehlerträchtiges und kostenrisikobehaftetes Modell der Softwareentwicklung; dabei bezieht er sich sowohl auf die einfache Variante als auch auf die erweiterte mit schrittweise erfolgenden Rücksprungmöglichkeiten. Stattdessen schlägt Royce in dieser Publikation ein wesentlich um iterative Elemente erweitertes Modell vor.
Das Toyota Produktionssystem (TPS) ist ein von Toyota in einem Zeitraum von über 50 Jahren entwickeltes Produktionsverfahren für die Serienproduktion. Dabei konzentrierte man sich auf die Verbesserung der organisatorischen Abläufe sowie auf die ständige Weiterentwicklung der Prozesse, Methoden, Arbeitsmittel, Mitarbeiter, Kunden und Partner. Ziel: höchste Qualität bei niedrigstem Aufwand. (Taiichi Ohno und Shigeo Shingo)

Scrum in Produktionsumgebungen wird zum ersten Mal im Artikel «The New New Product Development Game» erläutert und später in «The Knowledge Creating Company» weiter ausgeführt.
(Ikujiro Nonaka und Hirotaka Takeuchi)
80er Jahre – lean production
90er Jahre – agile production
Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch «Wicked Problems, Righteous Solutions» beschrieben.

Bei Scrum wird grundsätzlich angenommen, dass Produktfertigungs- und Entwicklungsprozesse so komplex sind, dass sie sich im Voraus weder in grosse abgeschlossene Phasen noch in einzelne Arbeitsschritte mit der Granularität von Tagen oder Stunden pro Mitarbeiter planen lassen. Somit ist es produktiver, wenn sich ein Team in einem festen äusseren Rahmen mit sehr grober Granularität selbst organisiert. Dieses selbstorganisierte Team übernimmt in diesem mit dem Product Owner abgestimmten Rahmen die gemeinsame Verantwortung für die Fertigstellung der selbstgewählten Aufgabenpakete.
2001 – agile manifesto
Scrum erfüllt als agile Methode die Bedingungen der agilen Software-Entwicklung, die
2001 im Agilen Manifest u. a. von Ken Schwaber und Jeff Sutherland mitformuliert wurden:
1. Individuen und Interaktionen gelten mehr als Prozesse und Tools
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen
4. Der Mut für Veränderungen steht über dem Befolgen eines festgelegten Plans
2003 – certified scrum master
Ken Schwaber initiiert ein Zertifizierungsprogramm für Scrum Master.
Das «Certified Scrum Master» Training wird unter der Schirmherrschaft der Scrum Alliance durchgeführt.
Scrum Definition
Scrum Zyklus
Product Owner
definiert Anforderungen und legt Ziele fest
stellt Budget zur Verfügung
bewertet und priorisiert regelmässig
greift nicht in die Organisation des Teams ein

Team
arbeitet selbstorganisiert
schätzt Aufwände (Story Points)
verteilt Aufgaben (Tasks)
geht Verpflichtungen ein (commitments)
implementiert und liefert
misst den eigenen Fortschritt
kommuniziert mit dem Product Owner

Scrum Master
überwacht Aufteilung der Rollen und Rechte
erkennt Verbesserungspotenziale
unterstützt den Product Owner
sorgt dafür, dass das Team produktiv sein kann
verbreitet Scrum im Unternehmen
Pigs and Chicken
Scrum Rollen
«Pig»-Rollen – committed = direkt am Projekt beteiligt
«Chicken»-Rollen – involved = indirekt am Projekt beteiligt
Stakeholder
ermöglicht das Projekt
rechtfertigt das Projekt
erhält einen vereinbarten Nutzen aus dem Projekt
prüft das Projekt laufend an den Sprint Reviews

Manager
organisiert Umfeld und Struktur des Projekts
hört sich Probleme an und löst diese
Scrum Artefakte
Product Backlog
enthält Features/User Stories
umfasst alle Funktionalitäten inkl. technischer Abhängigkeiten
Elemente werden vor jedem Sprint neu bewertet und priorisiert
je höher priorisiert die Elemente, umso detaillierter sind diese beschrieben

Sprint Backlog
enthält alle Aufgaben, um das Ziel des Sprints zu erreichen
enthält keine Aufgabe, welche länger als ein Tag dauert
enthält nicht mehr Aufgaben als Team-Kapazität vorhanden ist

Burndown Chart
grafische Darstellung des Restaufwands pro Sprint
lässt während des Sprints erkennen, ob der Aufwand umgesetzt werden kann

Impediment Backlog
enthält alle Hindernisse des Projekts
Hindernisse werden durch Scrum Master gemeinsam mit dem Team ausgeräumt
Sprint
Umsetzung einer Iteration
Feste Anzahl Tage/Wochen

Daily Scrum
tägliches Scrum Meeting nach Mittagessen (ca. 15 min.)
3 Fragen:
1. Was hast du seit dem letzten Meeting erreicht?
2. Was wirst du bis zum nächsten Meeting erreichen?
3. Gibt es ein Problem, das dich blockiert?

Review
Präsentation der Ergebnisse nach einem Sprint
Prüfung durch Product Owner/Stakeholder
Änderungen werden im Product Backlog dokumentiert

Retrospektive
Rückblick auf die Ereignisse des Sprints
2 Fragen:
1. Was war gut?
(Best practice)
2. Was könnte verbessert werden?
(Verbesserungspotential aufnehmen, priorisieren, zuordnen)
Das Angeordnete Gedränge (englisch scrum) ist in verschiedenen Varianten des Rugbysports die Standardsituation, um das Spiel neu zu starten.
Projektdreieck
Scrum ist keine Methode, sondern ein Framework
Scrum ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist. Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden

Empirischer Management- und Steuerungs-Prozess
Aufgebaut auf Feedback-Schleifen
Skalierbar für verteilte, grosse und lange Projekte
Kernelement kurze Iterationen/Sprints
In jeder Iteration entsteht ein lauffähiges System
Selbstorganisierte Projektteams
Spannungsdreieck des Projekts: Die Wechselbeziehungen von Zeit, Kosten und Umfang.
Wird eines dieser Elemente angepasst, so hat dies Auswirkungen auf die anderen beiden Elemente. Eine Änderung an einer der Steuergrössen führt automatisch zu Änderungen an einer oder beiden anderen Grössen.
Vorteile agiler Methoden
Flexibilität durch kurze Zyklen
Effektive Nutzung von Ressourcen
Führt schnell zu gewünschten Änderungen
Regelmässige Kontrolle der Steuergrössen
Nachteile agiler Methoden
Möglichkeit zur Verzettelung im Detail
Fehlender Projekt Gesamtüberblick
Mangelnder architektonischer Überblick durch fehlende Designphase
Hoher Kommunikations- und Abstimmungsaufwand
Emergente Strategie
(Emergenz = auftauchen, hervorkommen, sich zeigen)
Das Produkt entsteht aus einer vagen Idee emergent.
Planung und Steuerung
Full transcript