Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik

Transkript

1 SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik Scrum Einführung Do, Hoang Freie Universität Berlin, SoSe 2013

2 Rollen Product Owner Definiert die Ziele Product Backlog Scrum Master Garantiert die Einhaltung der Scrum Regel Das Team Umsetzung Sprint Backlog Weitere Rolle: Stakeholder 2

3 Meetings Sprint Planning Meeting I und II Ziele der Woche festlegen Jeden Montag; Dauer: 2 Stunde Daily Scrum Tägliches Meeting Di / Mi / Do / Fr Dauer: 2 Min pro Person Sprint Review Sprint Retrospektive Demonstration; Vortrag Jeden Freitag Dauer: 90 Minuten 3

4 Meetings Sprint Planing Meeting I und II Introduction Product Owner erläutert Product Backlog Product Backlog ist eine priorisierte und gewichtete TODO-Liste von Features auf der Business Ebene. Commitment Das Team wählt die Einträge für die Woche aus, die es in dieser Woche umsetzen kann. Das Team verpflichtet sich dazu die gewählten Elemente zu schaffen. Keine nachträgliche Änderungen während des Sprints möglich. Planing Das Team erstellt mit dem Scrum Master das Sprint Backlog für das anstehende Sprint Sprint Backlog ist eine TODO-Liste des Teams. Ein Eintrag wird Task genannt und darf nicht mehr als ein Tag in Anspruch nehmen. 4

5 Beispiel: Webentwicklung Priority Title Description Effort 1000 User sign up As a Guest I want to create a user account on XYZ by sign up so that I can sign in the website and set up my preferences Cancel Account As a registered User I want to cancel my user account so that I can quit using the product without leaving any information

6 Beispiel: Spieleentwicklung Priority Title Description Effort 1000 Sprungaktion vom Hauptfigur Als Spieler kann ich meine Figur springen lassen, damit sie nicht so wohlgenährt ist Rohstoffe sammeln Als Spieler kann ich meine Figur Kräuter sammeln lassen damit ich später anderes tolles Zeug herstellen kann

7 Meetings Daily Meetings Overview Die Mitglieder im Team behalten den Gesamtüberblick im Team Update Aktualisieren des Sprint Backlogs Mikromeilenstein 3 Magic Questions Was habe ich (gestern) geschafft? Was schaffe ich heute? Welche evtl. Probleme könnten mich/das Team am Erreichen meiner Ziele hindern? Meeting Voraussetzungen: Im Stehen: Verringert Ablenkung und das Interesse an langen Reden 7

8 Meetings Review & Retrospektive Demonstration Das Team zeigt die implementierten Features Suggestion Bei Bedarf hält Scrum Master einen Vortrag als Anregung Best Practices Das Team reflektiert über den letzten Sprint und optimiert sein Prozess. 8

9 Artefakten Product Backlogs Priorisierte ToDo Liste auf Business Ebene Sprint Backlogs Priorisierte ToDo Liste auf technische Ebene Für die Abarbeitung eines Task, darf maximal ein Tag aufgewendet werden. Bei Problemen, an Scrum Master wenden. ACHTUNG: er couch den Teilnehmer! Er macht NICHT seiner Arbeit. Taskboard Visualisierungsform des Sprint Backlogs (Burndown Chart) 9

10 Häufig gemachte Fehler 10

11 Häufig gemachte Fehler Scrum Master ist kein Projektleiter Kernidee vom Scrum: Das Team ist Herr seines Kompetenzfeldes vgl. Paketlieferant Scrum Master überwacht und regt Entwicklung die gewünschte Richtung (Coach) Das Team ist autonom Product Owner kümmert sich um den Business Value Technische Kompetenz vom Team ist weit über dem vom PO, oftmals auch Scrum Master Er definiert das WAS nicht das WIE! Daily Meeting ist ein Monolog Probleme, die nicht das ganze Team betreffen, sind nach dem Meeting zu klären! Keine Laptops, niemand sitzt 11

12 Häufig gemachte Fehler Review ist kein Interview Es geht nicht darum zu erzählen, wer was gemacht hat! Vorsicht mit Unity Library und Szenen Viele Probleme im Web reportet Ich warte gerade auf Nutzt Interfaces Macht einen anderen Task Im Daily Scrum müsst ihr etwas auf Done setzen Task maximal einen Arbeitstag lang 12

13 Häufig gemachte Fehler Agile ist ein Prozessmodell!!! Ein Sprint liefert eine Deliverable! (tested, refactored, documented) Keine Interpretation von Product Backlog Items Das, was im TFS steht ist richtig, ansonsten das Wort der Stakeholders Prototyp & Refactoring Versucht nicht von Anfang an die beste Architektur zu designen 13

14 Hinweis zum Code Blockweise kommentieren Semantik kommentieren, nicht die Syntax! Variablen, Methoden, Klassen kommentieren XML Documentation Gemeinsame Namenskonvention lowercamelcase UpperCamelCase Source Code komplett in englisch (Namen, Dokumentation) 14