1 Prof. Dr. Bernd Hafenrichter
1 Prof. Dr. Bernd Hafenrichter
1 Prof. Dr. Bernd Hafenrichter
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Scrum<br />
1
Scrum - Überblick<br />
Summe 175<br />
Trend Velocity pro Monat 12<br />
Nr Thema Priorität Schätzung<br />
P1 Mapping Entwicklung eines Mapping-Designers für Orchestra Hoch 20<br />
P2 Mapping Entwicklung einer Ausführungsschicht für die Mappings Hoch 10<br />
P3 Mapping Definition eines Darstellungsformates für Orchestramappings Hoch 5<br />
P4 Prozess Entwicklung eines Prozess-Designers für Orchestra Hoch 20<br />
P5 Prozess Entwicklung einer Ausführungsschicht für Prozessmodelle Hoch 20<br />
P6 Prozess Definition eines Darstellungsformats für Prozesmodelle Hoch 10<br />
P7 Adapter Entwicklung eines generellen Frameworks für die Darstellung und Konfiguration von Adapter Hoch 10<br />
P8 Adapter Entwicklung eines Frameworks zur Ausführung und Monitoring von Adapters Hoch 10<br />
P9 Adapter Definition einer Testumgebung. Adapter sollen bereits zur Designzeit getestet werden Hoch 10<br />
P10 Adapter Entwicklung eins SAP-Adapters Mittel 20<br />
P11 Adapter Entwicklung eines Web-Service-adapters Mittel 20<br />
P12 Adapter Entwicklung eines FTP-Adapters Mittel 20<br />
Product<br />
Backlog<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Daily<br />
Scrum<br />
Work<br />
item<br />
Work<br />
item<br />
Work<br />
item<br />
Work<br />
item<br />
Work<br />
item<br />
Sprint<br />
Backlog<br />
Max 30<br />
Tage<br />
Sprint<br />
Product<br />
inkrement<br />
2
Sprints<br />
• Scrum-Projekte schreiten in Serien von Sprints iterativ voran<br />
• Die typische Sprintdauer beträgt 1 – 6 Wochen<br />
• Das Produkt wird während des Sprints entworfen, kodiert und getestet<br />
• Am Ende steht ein auslieferbares Stück Software<br />
klassisch Scrum/Sprints<br />
Anforderungen<br />
Design<br />
Implementierung<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Test<br />
Anforderungen<br />
Design<br />
Impl.<br />
Test<br />
Anforderungen<br />
Design<br />
Impl.<br />
Test<br />
Anforderungen<br />
Design<br />
Impl.<br />
Test<br />
3
Sprints<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Keine Änderung der<br />
Anforderungen während<br />
des Sprints<br />
Zu viele Änderungen führen zu geringerer<br />
Produktivität und<br />
machen jegliche Planung überflüssig.<br />
4
Rollen – Product Owner<br />
• erfasst Bedürfnisse der Kunden und Stakeholder<br />
• Pflegt das Produkt-Backlog<br />
• bestimmt Auslieferungsdatum und Inhalt<br />
• ist verantwortlich für Produkt und Projekterfolg (u.a. ROI)<br />
• definiert und priorisiert Features abhängig von deren Geschäftswert<br />
• passt Features und Prioritäten für jeden Sprint an<br />
• akzeptiert oder weist Arbeitsergebnisse zurück<br />
• darf das Team bis zu 10% seiner Zeit in Anspruch nehmen<br />
• für konzeptionellen Arbeiten und Schätzklausuren<br />
• zusätzlich Sprint Planning und Sprint Review<br />
• muss mind. 80% seiner Zeit für das Projekt zur Verfügung stehen<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
5
Rollen – Scrum Master<br />
•ist verantwortlich für die Einhaltung von Scrum-Werten und -Techniken<br />
•ist ein Coach für die eingesetzten Techniken<br />
•hilft beim Beseitigen von Hindernissen<br />
•unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen<br />
•schützt das Team vor äußeren Störungen<br />
•bringt idealerweise Ingenieur- und Entwicklerfähigkeiten mit<br />
•versucht Lernprozess und Selbstorganisation des Teams anzustoßen<br />
•moderiert die diversen Meetings und hilft bei deren Vorbereitung<br />
•repräsentiert das Team gegenüber dem Management<br />
•darf nicht inhaltlich arbeiten<br />
•ist nicht Teil des (Umsetzungs-)Teams<br />
•hat keine Weisungsbefugnis gegenüber dem Team<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
6
Rollen – Scrum Team<br />
• Typischerweise 5-9 Personen<br />
• Funktionsübergreifend:<br />
• QS, Programmierer, UI-Designer, etc.<br />
• Mitglieder sollten Vollzeitmitglieder sein<br />
• Wenige Ausnahmen (z.B. Systemadministratoren)<br />
• Das Team steuert sich selbst<br />
• Mitglieder übernehmen Aufgaben, bekommen sie nicht zugewiesen<br />
• Es darf alles tun, was für die Zielerreichung notwendig ist<br />
• Mitgliedschaft kann sich nur zwischen Sprints verändern<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
7
Was macht das Team aus?<br />
Eine Gruppe: 5 - 9<br />
• Personen mit organisatorischem Zusammenhalt<br />
Ein Team:<br />
• gemeinsames Ziel<br />
• selbstloses Handeln<br />
Ein Team zeigt Commitment<br />
• Jeder arbeitet 100%ig an der gemeinsamen Aufgabe<br />
• Jeder setzt die Teamentscheidungen um, auch wenn<br />
er persönlich anderer Meinung ist<br />
• Keine Sabotage, kein Schlechtreden,<br />
• kein „Ich habe es ja vorher gewusst“<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
8
Selbst-organisiert, -gesteuert und -<br />
bestimmt<br />
• Jede Gruppe organisiert sich - irgendwie - selbst<br />
• Selbstgesteuerte Teams arbeiten zielgerichtet<br />
• Selbstbestimmte Teams setzen sich ihre Ziele selbst<br />
• Vorteile der Eigenverantwortung<br />
• Die Entscheidungen selbstgesteuerter Teams habeneine höhere Qualität<br />
• Selbstgesteuerte Teams können effektiver sein<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
9
Das Produktbacklog<br />
• Eine Liste aller gewünschten funktionalen und nicht-funktionalen<br />
Anforderungen<br />
• Idealerweise soll jeder Eintrag wertvoll für Benutzer des Produktes<br />
oder Kunden sein<br />
• Vom Produkt-Owner priorisiert<br />
• Vom Team geschätzt<br />
• Höher priorisierte Einträge sind detaillierter dargestellt<br />
• Jeder kann Einträge beisteuern<br />
• Sichtbar für alle<br />
Summe 175<br />
Trend Velocity pro Monat 12<br />
Nr Thema Priorität Schätzung<br />
P1 Mapping Entwicklung eines Mapping-Designers für Orchestra Hoch 20<br />
P2 Mapping Entwicklung einer Ausführungsschicht für die Mappings Hoch 10<br />
P3 Mapping Definition eines Darstellungsformates für Orchestramappings Hoch 5<br />
P4 Prozess Entwicklung eines Prozess-Designers für Orchestra Hoch 20<br />
P5 Prozess Entwicklung einer Ausführungsschicht für Prozessmodelle Hoch 20<br />
P6 Prozess Definition eines Darstellungsformats für Prozesmodelle Hoch 10<br />
P7 Adapter Entwicklung eines generellen Frameworks für die Darstellung und Konfiguration von Adapter Hoch 10<br />
P8 Adapter Entwicklung eines Frameworks zur Ausführung und Monitoring von Adapters Hoch 10<br />
P9 Adapter Definition einer Testumgebung. Adapter sollen bereits zur Designzeit getestet werden Hoch 10<br />
P10 Adapter Entwicklung eins SAP-Adapters Mittel 20<br />
P11 Adapter Entwicklung eines Web-Service-adapters Mittel 20<br />
P12 Adapter Entwicklung eines FTP-Adapters Mittel 20<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
10
:<br />
Weiterführende Themen<br />
Schätztechniken ??<br />
Grundsätzlich: Alle Artefakte innerhalb des Produkt- bzw. Sprintbacklog sind<br />
zu schätzen.<br />
• Schätzen idealen Tagen<br />
• Schätzen in abstrakten, vergleichenden „Story-Punkten“<br />
Punktwert Semantik<br />
0 Kein Aufwand<br />
1 Sehr kleiner Aufwand<br />
2 Kleiner Aufwand: doppelt so groß wie kleiner Aufwand<br />
3 Mittlerer Aufwand: so groß wie ein sehr kleiner und kleiner Aufwand<br />
5 Großer Aufwand: so groß wie ein kleiner + mittlerer Aufwand<br />
8 Sehr großer Aufwand: so groß wie mittlerer + großer Aufwand<br />
13 Riewsiger Aufwand: so groß wie ein großer und sehr großer Aufwand<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
11
:<br />
Weiterführende Themen<br />
Schätztechniken ??<br />
Planungspoker<br />
• Vorbereitung: Jedes Teammitglied bekommt einen<br />
Stapel Karten mit allen möglichen Story-Points<br />
• Product-Owner wählte einen Eintrag des Product-<br />
Backlogs<br />
• Fragen werden zwischen Team- & Produkt-Owner<br />
direkt geklärt<br />
• Alle Mitglieder drehen Ihre Schätzkarten<br />
gleichzeitig um<br />
• Liegt kein Konsens vor erklären die<br />
Teammitglieder mit den Extremwerten den Grund<br />
für die Einschätzung.<br />
• Danach erfolgt eine neue Schätzrunde<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Product-Owner<br />
Stellt Backlog-Eintrag<br />
vor<br />
Kein<br />
Konsens<br />
Abklären von<br />
Unklarheiten<br />
Jedes Teammitglied<br />
Deckt Karte mit<br />
Schätzwert auf<br />
Abklären der<br />
Extermwerte<br />
Ergebnis<br />
Festhalten.<br />
12
Das Sprintbacklog<br />
• Team-Mitglieder wählen Tasks aus, die Arbeit wird nie zugewiesen<br />
• Der geschätzte Restaufwand wird täglich aktualisiert<br />
• Alternative 1: Nur fertige Tasks werden auf 0 gestellt<br />
• Alternative 2: Nur fertige Stories werden auf 0 gestellt<br />
• Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern<br />
• Überarbeitung des Sprint Backlogs sobald neue Informationen vorliegen<br />
• An prominenter Stelle sichtbar machen<br />
• z.B. Whiteboard im Team-Raum<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Summe 52<br />
Trend Velocity pro kw 7<br />
Produktitem Thema Schätzung<br />
P1 Mapping Wizard zum Erzeugen von Mappings: Selektion quelldatentyp, Selektion Zieldatentyp 2<br />
P1 Mapping Darstellen von Mappings über das integrierte Framework 10<br />
P1 Mapping Erstellen eines Mappingtester-Dialog 2<br />
P3 Mapping Serlialisieren einer Mappingdefinition über xml 2<br />
P3 Mapping DeSerialisieren einer Mappingdefinition über xml 2<br />
P2 Mapping Deployment von Mappings auf der Runtime-Umgebung 2<br />
P2 Mapping Erstellen eines Mapping-Serices. Verwaltet alle deployten mappings und stellt eine Ausführbare version bereit 4<br />
P3 Mapping Darstellungsformat definieren 2<br />
P4 Prozess Wizard zum Erzeugen eines Prozessmodells 2<br />
13
Die Sprintdetail-Planung<br />
• Team wählt Punkte, zu deren Implementierung es sich verpflichten<br />
kann, aus dem Product Backlog aus.<br />
• Product-Owner steht für Fragen zur Vergügung<br />
• Sprint Backlog wird erstellt<br />
•Tasks werden identifiziert und geschätzt (1-8 Stunden, 1-2 Tage)<br />
•Dieses wird gemeinschaftlich getan, nicht vom ScrumMaster allein<br />
Entwicklung<br />
eines Mapping-<br />
Designers für<br />
Orchestra<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Wizard zum Erzeugen von Mappings: Selektion quelldatentyp,<br />
Selektion Zieldatentyp (2PT)<br />
Darstellen von Mappings über das integrierte Framework (10PT)<br />
Erstellen eines Mappingtester-Dialog (2PT)<br />
Produktbacklog Sprintbacklog<br />
14
Das Sprint-Burndown<br />
Aufwand<br />
50<br />
45<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Sprint Burndown<br />
KW1<br />
KW2<br />
KW3<br />
KW4<br />
KW5<br />
KW6<br />
KW7<br />
KW8<br />
KW9<br />
KW10<br />
KW11<br />
KW12<br />
KW13<br />
Woche<br />
Aufwand Aktuell<br />
Geplant<br />
15
Das Sprint-Burndown<br />
Aufwand<br />
60<br />
50<br />
40<br />
30<br />
20<br />
10<br />
0<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Sprint Burndown<br />
KW1 KW2 KW3 KW4 KW5 KW6 KW7<br />
Woche<br />
KW8 KW9 KW10 KW11 KW12 KW13<br />
Aufwand Aktuell<br />
Geplant<br />
16
Das Scrumboard<br />
Zeigt alle Aktivitäten des aktuellen Sprints.<br />
Evtl. auch sog. Impediments (=Hinderniesse)<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
17
Das Daily-Scrum<br />
• Parameter:<br />
• Täglich, selber Ort, gleiche Zeit<br />
•
Das Daily-Scrum<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
19
Das Daily-Scrum<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
Was hast du seit dem letzten Mal geschafft?<br />
Was wirst du bis zum nächsten mal tun?<br />
Was behindert dich beim vorwärts kommen<br />
• Keine Statusberichte für den Scrum-Master, sondern<br />
Abstimmungsinformationen für die Kollegen<br />
• Weiterführende Diskussione werden im Anschluss geführt<br />
1<br />
2<br />
3<br />
20
Weitere Meetings<br />
• Sprint-Review-Meeting<br />
• Das Team präsentiert, was es während eines Sprints erreicht hat<br />
• Typischerweise in Form einer Demo<br />
• Das ganze Team nimmt teil<br />
• Laden Sie die ganze Welt ein!<br />
• Product Owner und andere geben Feedback<br />
• Sprint-Retrospektive<br />
• Was lief gut während des Sprints?<br />
• Was kann im nächsten Sprint verbessert werden?<br />
• Diskussion der identifizierten Probleme<br />
• Identifikation von wenigen „Action Items“<br />
• Schätzklausuren<br />
• Teambesprechungen<br />
• Anforderungsworkshops<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
21
:<br />
Weiterführende Themen<br />
Was bedeutet fertig ??<br />
Grundsätzlich: Alle Mitglieder des Teams müssen das gleiche Verständnis<br />
von „fertig“ haben<br />
• Code eingecheckt<br />
• Alles kompiliert fehlerfrei<br />
• Alle automatischen Unit Tests laufen<br />
• Alle automatischen Akzeptanztests<br />
• Performance-Tests wurden durchgeführt<br />
• Manuelle Tests wurden durchgeführt<br />
• System wurde in Testumgebung deployt<br />
<strong>Prof</strong>. <strong>Dr</strong>. <strong>Bernd</strong> <strong>Hafenrichter</strong><br />
22
Change language