se:scrummaster
**Dies ist eine alte Version des Dokuments!**
Scrum Master
Aufgaben nach Scrum
Nach Schwaber
Ensures that the team is fully functional, productive and improves quality.
Enables close cooperation across all roles and functions and removes barriers.
Shields the team from external interferences.
Ensures that the process is followed.
Teaches Product Owner and Team how to fulfill their roles.
aus Schulungsunterlagen
Guards and supports the Scrum process
Facilitates team decision-making and team maturity
Removes impediments
Protects the team from external interruptions
Acts as chief communicator – coordinates communications between team and external stakeholders, management, and other corporate communication
Regelmäßige Aufgaben
Projektbesprechung in Nürnberg planen
Sprint Retrospectives erstellen
Was bleibt mir von diesem Sprint besonders in Erinnerung?
Was war gut?
Was lief schlecht und was können wir tun, um diese Punkte zu beheben/verbessern?
Kontrolle/Administration Ticket System
Trac-Ausfälle dokumentieren/Bergmann kontaktieren
TK mit Teams zu Beginn (Retrospective), in der Mitte (aktueller Stand) und am Ende (Sprint Review inkl. Demo des Produkts) des Sprints
Offene Punkte
Product Owner
Kunden an die Ergebnisse lassen ("rumspielen")?
Sprint Review mit PO abstimmen (Produktdemo am Ende des Sprints)
Zusammenarbeit mit PO klären
-
Videos
SVN-Refactoring
-
Ticket System
Feld ReqID nachtragen
Frist zum Eintragen der anstehenden Aufgaben setzen
Reports für Sprint 7 anlegen
Gibt es noch andere sinnvolle Reports?
Tickets der Datenbank werden nicht im Report angezeigt
Retrospectives an Andert
Einheitliche XML-Beispieldatei erzeugen
Zuordnung SM/PO in Trac nachtragen
Trac
SVN
Vortrag von Robra
Abstimmung zu den letzten Klausuren
Retrospective
TKs
Mi, 06.08. 19:00 Uhr FPL
Mi, 06.08. 20:00 Uhr Editor
Do, 07.08. 18:30 Uhr Web/DB
Do, 07.08. 19:00 Uhr Simulation
ab 12.08. Steuerung
Editor
Steffen
Highlight: Besonders gut haben mir die kurzen Telefonkonferenzen (10-20 min) gefallen. Diese haben wir dadurch erreicht, dass mittels eines Blogs über unsere Tätigkeiten ein öffentliches "Tagebuch" geführt haben. Somit wusste jeder Bescheid, was gut läuft und was nicht.
Gut: Unser Blog und unsere kurzen Konferenzen.
Schlecht: Was mir nicht so gut gefallen hat, ist die Tatsache, dass jeder in allen Programmmodulen arbeitet und somit Konflikte vorprogrammiert waren. Um das Problem zu beheben würde ich Vorschlagen Verantwortlichkeiten für die Module festzulegen.
Andreas
Highlight: Mementoerstintegration hat funktioniert. Gemeinsames Debugging am Editor hat Spass gemacht.
Gut: Einführung des Editor-Team Blogs hat Kommunikation und Effizienz gesteigert. Spontante Reaktion bei akuten Probemen möglich. Reduzierung der TK-Dauer durch festes Schema/Gliederung in Grundzügen gelungen.
Schlecht: XML Schemadefinition läuft im Gesamtteam nicht zufriedenstellend. Jochen ohnehin stark durch Projekt belastet → Gesamtlösung muss gefunden werden!
Jochen
Highlight: Die zeitliche Verbesserung der TKs. Wir haben versucht Herrn Anderts Weisungen zu befolgen und es hat sich sehr gut (noch nicht ganz perfekt) umsetzen lassen.
Gut: Wir haben einen Team-eigenen Blog eingeführt, bei dem jeder seinen Status und Probleme schildern konnte. Dies als Ersatz für das Daily-Meeting. Es wurde rege genutzt und half für eine schnelleren Informationsweg.
Schlecht: Die 2 1/2 h pro Woche Projektarbeit ist leicht untertrieben. Alleine meine Arbeitszeit für das Projekt (ohne zu Lernen) hat das 10 fache pro Woche leicht überschritten. So sollte es zukünftig nicht weiterlaufen.
Fertigungsplanung
Patrick
Gut: stetige Erreichbarkeit von Stefan
Schlecht: zu wenig Rückmeldung vom Unterdachziegel (Info bei Einchecken, Zwischeninfo)
Bewegend: toller Buildprozess, erbarmungsloser Einsatz aller TM
Tina
Gut: Team, Kommunkation und Telkos
Schlecht: zu spät die IF selbst abzustimmen, nachzudenken
Bewegend: Joker, geschoben
Stefan
Gut: siehe bewegend
Schlecht: Dachziegelkonzept selbst nicht umzusetzen geschafft
Bewegend: sehr großer Fortschritt im Projekt, es läuft alles, was sollte
Kathrin
Gut: Fortschritt deutlich sichtbar
Schlecht: Rückmeldung fehlt zu Problemmail und Codecheckermail
Bewegend: Erfolg bei CodeChecker
Schlecht allgemein
Sprintplanung verbessern und Abhängigkeiten am Anfang klären
Problemliste in Telko ⇒ Problem nach 2 Tagen Nichtrückmeldung
Unterdachziegel schickt Benachrichtigung an Dachziegel, dass jetzt bitte mal gucken
"Strafe", wer zu viel in Problemliste steht, gibt Eis aus
Kathrin soll direkter fragen
Simulation
Steuerung
Highlight
erste Erfolge bei den Design- und Implementierarbeiten
Methodisches Vorgehen: Schnittstellen entwickeln, implementieren und parallel dazu funktionale Teile entwickeln.
Gut
Schlecht
Web/DB
TKs mit den einzelnen Teams
Allgemeine Punkte
Erwartungen der Teammitglieder an den SM in Erfahrung bringen
Was ist zur Zeit das größte Hindernis bei der Gesamtprojektarbeit?
Zeitprobleme ansprechen → viele schreiben die Klausuren nicht mit
Anregungen/Wünsche für Trac (Wiki, Tickets) und SVN
Editor
Retrospective
Gut: Kurze TKs, Blog
Blog
Prinzipiell eine gute Sache, aber warum außerhalb von Trac?
* Schlecht: Keine klaren Verantwortlichkeiten, XML-Datei, viel zu hohe zeitliche Belastung
* Brauchen sie Unterstützung?
* Jochen sagt schon, dass er zu wenig Zeit hat.
* Andreas wird für zwei Sprints Scrum Master.
* Wenn ja, müssen wir das Problem jetzt schon angehen, da kurzfristige Einarbeitung eines Externen sehr schwierig wird.
Fertigungsplanung
Simulation
Retrospective
Gut: Einsatz der Teammitglieder, effizientere TKs
Schlecht: keine Tagesordnung, Punkte werden mehrmals diskutiert, unterschiedliche Aufteilung Zeitaufwand, Einarbeitung Jean, Code-Probleme, unsachliche Diskussionen
Brauchen sie Unterstützung? Wenn ja, dann jetzt melden!
Tagesordnung im Wiki → siehe FPL
Scrum Master als Vermittler zwischen den Fronten
Steuerung
Web/DB
se/scrummaster.1217928217.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)