03.10.2013 Aufrufe

Markus Schramm - myScrum - Scrum in der Praxis - Compeople

Markus Schramm - myScrum - Scrum in der Praxis - Compeople

Markus Schramm - myScrum - Scrum in der Praxis - Compeople

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

<strong>my<strong>Scrum</strong></strong><br />

<strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

<strong>Markus</strong> <strong>Schramm</strong><br />

compeople AG Frankfurt


Überblick<br />

• Agilität und <strong>Scrum</strong><br />

Grundlagen <strong>der</strong> agilen Softwareentwicklung<br />

• Rahmenbed<strong>in</strong>gungen<br />

bei <strong>der</strong> E<strong>in</strong>führung e<strong>in</strong>es agilen Projektvorgehens<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Erfahrungen mit <strong>Scrum</strong> im Projekt<br />

An welchen Schrauben kann man drehen<br />

• Hilfsmittel<br />

Was erleichtert das Leben e<strong>in</strong>es <strong>Scrum</strong>masters<br />

1


<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Warum agil entwickeln?<br />

• Komplexe Systeme<br />

Aufgrund sich verän<strong>der</strong>n<strong>der</strong> Anfor<strong>der</strong>ungen ke<strong>in</strong>e vollständige Planung<br />

vorab möglich<br />

• Ständige Verbesserung des Prozesses<br />

Durch Aufdecken von Fehlern und H<strong>in</strong>terfragen des Prozesses<br />

• Hohe Qualität<br />

Aufgrund ständiger Reviews und Prozessanpassung<br />

2


Agilität<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Leichtgewichtig adaptiver Prozess<br />

hochgradig geregelten Prozess<br />

• ‚So wenig Regeln wie möglich‘<br />

stark reglementiertes Vorgehen<br />

• Unterstützung <strong>der</strong> Mitarbeiter<br />

• Agiles Manifest<br />

3


Agiles Manifest<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Kent Beck, Alistair Cockburn, Ward Cunn<strong>in</strong>gham und Mart<strong>in</strong> Fowler 2001<br />

• Individuen und Interaktionen gelten mehr als Prozesse und Tools<br />

• Funktionierende Programme gelten mehr als ausführliche<br />

Dokumentation<br />

• Die stetige Zusammenarbeit mit dem Kunden steht über<br />

Verträgen<br />

• Der Mut und die Offenheit für Än<strong>der</strong>ungen steht über dem<br />

Befolgen e<strong>in</strong>es festgelegten Plans<br />

4


<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

E<strong>in</strong>e agile Methode: <strong>Scrum</strong><br />

• Schwaber, Sutherland und Beedle<br />

1990 als agile Methode e<strong>in</strong>geführt<br />

• Begriff aus dem Rugby<br />

Köpfe zusammenstecken vor jedem Angriff<br />

• 30 tägige Iterationen<br />

liefern lauffähige Produkte<br />

5


• Product Owner<br />

<strong>Scrum</strong> Rollen<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Gibt das Ziel vor, stellt das Budget, bearbeitet das Product-Backlog<br />

• <strong>Scrum</strong>master<br />

Achtet auf E<strong>in</strong>haltung des <strong>Scrum</strong>-Prozesses, beseitigt Probleme, schirmt<br />

das Team ab<br />

• Team<br />

Teamgröße ~ 7 Personen<br />

Verantwortlich für Analyse, Design, Cod<strong>in</strong>g, Test<strong>in</strong>g und Dokumentation<br />

6


<strong>Scrum</strong> Begriffe (I)<br />

• Product Backlog<br />

Liste aller zum Produkt gehörenden Teile<br />

• Iterationen<br />

Aufteilung <strong>der</strong> Gesamtanfor<strong>der</strong>ung <strong>in</strong> mehrere Teile<br />

• Spr<strong>in</strong>t Backlog<br />

Liste aller Aufgaben <strong>in</strong>nerhalb e<strong>in</strong>es Spr<strong>in</strong>ts<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

7


Product Backlog<br />

Spr<strong>in</strong>t Backlog<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

8


<strong>Scrum</strong> Begriffe (II)<br />

• Spr<strong>in</strong>t<br />

E<strong>in</strong>e Iteration, Ziel: lauffähiges System<br />

• Daily <strong>Scrum</strong> (<strong>Scrum</strong> Meet<strong>in</strong>g)<br />

tägliches 15-m<strong>in</strong>ütiges Treffen<br />

• Burndown Graph<br />

Zeitlicher Verlauf <strong>der</strong> Restaufwände<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

9


Daily <strong>Scrum</strong><br />

Spr<strong>in</strong>t<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

10


Burn-Down Graph<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Der Burn-Down-Graph gibt zu jedem Zeitpunkt Rückschluss über den<br />

verbleibenden Restaufwand. Bei kont<strong>in</strong>uierlichem Projektfortschritt ergibt<br />

sich e<strong>in</strong>e stetig fallende L<strong>in</strong>ie<br />

„If you don‘t know where you<br />

are, a map won‘t help“<br />

Watts Humphrey<br />

11


• Review<br />

<strong>Scrum</strong> Begriffe (III)<br />

• Je<strong>der</strong> ist e<strong>in</strong>geladen<br />

• Demo des Projekt-Inkrements<br />

• Positionsbestimmung<br />

• Retrospektive<br />

• Was lief gut und was nicht<br />

• Impediment List<br />

• Ergebnisse mit hoher Priorität <strong>in</strong> nächsten Spr<strong>in</strong>t<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

12


<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Review<br />

Retrospektive<br />

13


Warum <strong>my<strong>Scrum</strong></strong><br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Projekte s<strong>in</strong>d unterschiedlich<br />

• Produktentwicklung<br />

• Anwendungsentwicklung<br />

• Wartungsprojekte<br />

• Menschen s<strong>in</strong>d unterschiedlich<br />

• Auftraggeber<br />

• Entwickler<br />

• Unternehmen s<strong>in</strong>d unterschiedlich<br />

• Kle<strong>in</strong> bis groß<br />

• Konservativ bis <strong>in</strong>novativ<br />

14


Der Auftraggeber<br />

• Bereitschaft<br />

Ist er bereit, das Projekt agil entwickeln zu lassen?<br />

• Vertragliche Aspekte<br />

Lässt sich das Projekt vertraglich so gestalten?<br />

• Ke<strong>in</strong>e Störung <strong>der</strong> Timebox<br />

Ke<strong>in</strong>e Än<strong>der</strong>ungen während e<strong>in</strong>er Phase<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

15


Das Team<br />

• Bereitschaft zur Transparenz<br />

Offene Kommunikation über alle Themen<br />

• Commitment zum Team<br />

Das Team steht geme<strong>in</strong>sam für Erfolg und Misserfolg<br />

• Commitment zu <strong>Scrum</strong><br />

Das Team lebt den <strong>Scrum</strong>-Gedanken<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

16


Das Umfeld<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Arbeitsumfeld<br />

Kann sich jedes Teammitglied nach se<strong>in</strong>en Fähigkeiten entwickeln?<br />

• Projektumfeld<br />

Akzeptieren an<strong>der</strong>e nicht-agile Projekte das Vorgehen?<br />

• Unternehmensumfeld<br />

Unterstützt das Unternehmen agile Methoden<br />

17


Erfahrungswert Storyboard<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Jedes Projektmitglied sollte je<strong>der</strong>zeit den Stand des Gesamtprojekts<br />

e<strong>in</strong>sehen können. Die Bedienung muss e<strong>in</strong>fach se<strong>in</strong>.<br />

• Wiki<br />

• Whiteboard<br />

• Excel<br />

• P<strong>in</strong>wand<br />

18


Erfahrungswert Spr<strong>in</strong>tlänge<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Die Literatur spricht von e<strong>in</strong>er Spr<strong>in</strong>tlänge von 30 Tagen. Je nach<br />

Projektart und Anfor<strong>der</strong>ung muss die Spr<strong>in</strong>tlänge <strong>in</strong>dividuell<br />

gewählt werden.<br />

• 30 Tage<br />

Literaturempfehlung<br />

• 14 Tage<br />

Möglichkeit für schnelle Feedbacks<br />

• 1 Woche<br />

Für e<strong>in</strong>en vollständigen <strong>Scrum</strong>zyklus zu kurz, da Rüstzeiten<br />

prozentual zu groß<br />

19


Erfahrungswert Meet<strong>in</strong>gs<br />

• Daily <strong>Scrum</strong> morgens<br />

• 15 M<strong>in</strong>uten s<strong>in</strong>d genug<br />

• Wichtige Meet<strong>in</strong>gs vormittags<br />

• Wenige Meet<strong>in</strong>gs pro Tag<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

20


Erfahrungswert Timebox<strong>in</strong>g<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Beschreibt e<strong>in</strong>e fix vorgegebene zeitliche E<strong>in</strong>heit für e<strong>in</strong> Ereignis<br />

• Immer<br />

Zeiten müssen kalkulierbar se<strong>in</strong><br />

• Meet<strong>in</strong>gs<br />

E<strong>in</strong>halten <strong>der</strong> angesetzten Dauer<br />

• Spr<strong>in</strong>ts<br />

Die Spr<strong>in</strong>tlänge ist fix<br />

21


<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Erfahrungswert Kommunikation<br />

• Räumliche Nähe !<br />

• Chat-Tool (googletalk, Jabber, …)<br />

• Mail<br />

• Wiki<br />

22


Synchronisation<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Mit an<strong>der</strong>en <strong>Scrum</strong>s kommunizieren<br />

S(crum) O(f) S(crums)<br />

• Mit an<strong>der</strong>en Projekten kommunizieren<br />

Coffee & more<br />

• Milestones<br />

zum Synchronisieren verschiedener Teilprojekte<br />

23


„<strong>Scrum</strong>smells“<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Wechselnde Ressourcen<br />

Än<strong>der</strong>ung <strong>der</strong> Teamzusammensetzung während e<strong>in</strong>es Projekts<br />

• Agil Chaos Verständnis<br />

Missverständnis, dass während e<strong>in</strong>es Spr<strong>in</strong>ts Aufgaben beliebig geän<strong>der</strong>t<br />

werden können: „Ich kann me<strong>in</strong>e Me<strong>in</strong>ung jeden Tag än<strong>der</strong>n“<br />

• Mangelnde Diszipl<strong>in</strong> beim daily<strong>Scrum</strong><br />

Teammitglie<strong>der</strong> müssen zum daily<strong>Scrum</strong> gerufen werden<br />

• Product Owner unterm<strong>in</strong>iert Spr<strong>in</strong>tplanung<br />

Der Product Owner nimmt E<strong>in</strong>fluss auf die Entwickler<br />

24


Ke<strong>in</strong> dedizierter<br />

Product Owner<br />

<strong>Scrum</strong><br />

my<br />

<strong>Scrum</strong>master ist<br />

auch Entwickler<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

Daily <strong>Scrum</strong> per<br />

Telefon<br />

14 Tage Spr<strong>in</strong>ts<br />

Review alle 3 Spr<strong>in</strong>ts<br />

Retrospektive …<br />

25


Literaturquellen<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

• Agile Software Development with <strong>Scrum</strong><br />

Ken Schwaber, Mike Beedle [Prentice Hall 2001]<br />

• Agile Project Management with <strong>Scrum</strong><br />

Ken Schwaber [Microsoft 2004]<br />

26


Internetadressen<br />

• <strong>Scrum</strong>alliance<br />

http://www.scrumalliance.org<br />

• <strong>Scrum</strong><br />

http://www.controlchaos.com<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />

27


<strong>Markus</strong> <strong>Schramm</strong><br />

Vielen Dank<br />

compeople AG<br />

Unterma<strong>in</strong>anlage 8<br />

60329 Frankfurt/Ma<strong>in</strong><br />

Telefon: 069 – 27 22 18 0<br />

Telefax: 069 – 27 22 18 22<br />

E-Mail: markus.schramm@compeople.de<br />

Web: www.compeople.de<br />

<strong>Markus</strong> <strong>Schramm</strong>, compeople AG<br />

<strong>my<strong>Scrum</strong></strong>, <strong>Scrum</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!