Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- se:scrummaster [2008-08-03 16:06]
stefan
+++ se:scrummaster [2008-08-07 15:11]
stefan
@@ Zeile 22: / Zeile 22: @@
     * Vorarbeiten für Retrospectives von Teams einfordern
   * 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?
-    * Was bleibt mir von diesem Sprint besonders in Erinnerung?
   * Kontrolle/Administration Ticket System
   * Trac-Ausfälle dokumentieren/Bergmann kontaktieren
@@ Zeile 30: / Zeile 30: @@
 ==== Offene Punkte ====
-  * Stand Simulation
+  * Product Owner
-    * Konflikte?
+    * Kunden an die Ergebnisse lassen ("rumspielen")?
-    * Einarbeitung Jean
+    * Sprint Review mit PO abstimmen (Produktdemo am Ende des Sprints)
-    * Unfaire Aufteilung Zeitaufwand
+    * Zusammenarbeit mit PO klären
-    * Benötigen sie noch Unterstützung?
-  * Kunden an die Ergebnisse lassen ("rumspielen")?
   * https://141.75.245.203/trac/mse07/wiki/ScrumProzessbeschreibungEtc
   * Videos
@@ Zeile 42: / Zeile 40: @@
     * http://www.youtube.com/watch?v=fb9Rzyi8b90&eurl=http://inside-scrum.blogspot.com
   * SVN-Refactoring
-  * Blog Team Editor
   * [[https://141.75.245.203/trac/mse07/wiki/GesamtImpedimentList|Impediment List]] durchgehen
   * Ticket System
-    * Feld ReqID nachtragen
+    * <del>Feld ReqID nachtragen</del>
     * Frist zum Eintragen der anstehenden Aufgaben setzen
-    * Möglichkeit für Burndown-Chart schaffen
+    * <del>Reports für Sprint 7 anlegen</del>
-    * Reports für Sprint 7 anlegen
     * Gibt es noch andere sinnvolle Reports?
+    * <del>Tickets der Datenbank werden nicht im Report angezeigt</del>
   * Retrospectives an Andert
   * Einheitliche XML-Beispieldatei erzeugen
-  * Zuordnung SM/PO in Trac nachtragen
+  * <del>Zuordnung SM/PO in Trac nachtragen</del>
-  * Zusammenarbeit mit PO klären
+  * Trac
-  * Wiki aufräumen
+    * Möglichkeit für Burndown-Chart schaffen
-  * Erwartungen der Teammitglieder an den SM in Erfahrung bringen
+    * Wiki aufräumen
-  * Sprint Review mit PO abstimmen (Produktdemo am Ende des Sprints)
+    * Scrum-Plugins
-  * Zeitprobleme ansperechen -> viele schreiben die Klausuren nicht mit
+      * [[http://trac-hacks.org/wiki/ScrumBurndownPlugin|ScrumBurndownPlugin - Trac Hacks - Plugins Macros etc. - Trac]]
-  * Tickets der Datenbank werden nicht im Report angezeigt
+      * [[http://trac-hacks.org/wiki/TimingAndEstimationPlugin|TimingAndEstimationPlugin - Trac Hacks - Plugins Macros etc. - Trac]]
-  * Vortrag von Robra
+      * [[http://jeffsutherland.com/scrum/2007/03/scrum-burndown-using-trac.html|Scrum Log Jeff Sutherland: Scrum Burndown using Trac]]
+      * [[http://weblogs.asp.net/bsimser/archive/2008/02/09/scrumming-with-the-trac-project.aspx|Scrumming with the Trac Project - Fear and Loathing]]
   * SVN
     * https://141.75.245.203/trac/mse07/discussion/1/11
     * https://141.75.245.203/trac/mse07/discussion/1/9/47#47
+  * Vortrag von Robra
+  * <del>Abstimmung zu den letzten Klausuren</del>
 ==== Retrospective ====
@@ Zeile 68: / Zeile 68: @@
 === 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
-    * coulon.j
+  * Mi, 13.08. 20:00 Uhr Editor
-    * robert.stumpe
-    * p.keinath
-    * andreas.macher1
   * ab 12.08. Steuerung
@@ Zeile 163: / Zeile 159: @@
     * Grundlegendes Sprint-Ziel wurde erreicht.
   * Schlecht
-    *Problem: Zeitplanung im Sprint 06 war schlecht. D.h. am Anfang wurde von mehreren im Team wenig gemacht und viel Arbeit auf das Ende verschoben. Gegenseitige Abhängigkeiten der einzelnen Aufgaben haben das Problem noch verschärft. Team verständigt sich darauf, dass dies ein Problem darstellt.
+    * Zeitplanung im Sprint 06 war schlecht. D.h. am Anfang wurde von mehreren im Team wenig gemacht und viel Arbeit auf das Ende verschoben. Gegenseitige Abhängigkeiten der einzelnen Aufgaben haben das Problem noch verschärft. Team verständigt sich darauf, dass dies ein Problem darstellt.
-      * Maßnahme: Im nächsten Sprint soll konsequent von Anfang an für das Projekt gearbeitet werden (Urlaub oder wichtige geschäftliche Verpflichtungen stellen eine begründetet Ausnahme dar). Falls das Problem wieder auftritt, kann dies von jedem Teammitglied angesprochen werden. Am Ende von Sprint 07 wird bewertet, ob die Vereinbarung von allen eingehalten wurde.
+      * Im nächsten Sprint soll konsequent von Anfang an für das Projekt gearbeitet werden (Urlaub oder wichtige geschäftliche Verpflichtungen stellen eine begründetet Ausnahme dar). Falls das Problem wieder auftritt, kann dies von jedem Teammitglied angesprochen werden. Am Ende von Sprint 07 wird bewertet, ob die Vereinbarung von allen eingehalten wurde.
-    * Problem: Entwicklungsumgebung für DB wurde während des Sprints von SQL-Skripten auf den Oracle-JDeveloper umgestellt. Daraufhin traten unvorhergesehene Probleme mit dem JDeveloper auf, welche sich auch auf die Web-Entwicklung ausgewirkt haben.
+    * Entwicklungsumgebung für DB wurde während des Sprints von SQL-Skripten auf den Oracle-JDeveloper umgestellt. Daraufhin traten unvorhergesehene Probleme mit dem JDeveloper auf, welche sich auch auf die Web-Entwicklung ausgewirkt haben.
-      * Maßnahme: Grundsätzlich soll der JDeveloper als Entwicklungsumgebung für die DB beibehalten werden. Da verschiedene Dinge beachtet werden müssen, wird es zukünftig ein Haupt-SQL-Skript geben, welches weitere SQL-Skripte aufruft. Dieses Skript muss nach Aktualisierungen getestet werden und funktionieren, damit es von allen im Team ohne Hintergrundwissen verwendet werden kann.
+      * Grundsätzlich soll der JDeveloper als Entwicklungsumgebung für die DB beibehalten werden. Da verschiedene Dinge beachtet werden müssen, wird es zukünftig ein Haupt-SQL-Skript geben, welches weitere SQL-Skripte aufruft. Dieses Skript muss nach Aktualisierungen getestet werden und funktionieren, damit es von allen im Team ohne Hintergrundwissen verwendet werden kann.
-    * Problem: Während des Sprints entstand eine verwirrende Anzahl von unterschiedlichen Schematas auf dem zentralen DB-Server.
+    * Während des Sprints entstand eine verwirrende Anzahl von unterschiedlichen Schematas auf dem zentralen DB-Server.
-      * Maßnahme: Zukünftig werden nur noch folgende Schemata verwendet: WEB/FPLAN für Entwicklung/Test (DB als Hilfs-Benutzer für SQL-Skripte) und WEB-KUNDE für Produktion.
+      * Zukünftig werden nur noch folgende Schemata verwendet: WEB/FPLAN für Entwicklung/Test (DB als Hilfs-Benutzer für SQL-Skripte) und WEB-KUNDE für Produktion.
-    * Problem: Zeitbelastung durch das Projekt war höher als geplant.
+    * Zeitbelastung durch das Projekt war höher als geplant.
-      * Maßnahme: Jeder im Team ist bereit auch zukünftig mehr zu geben, um ein fertiges und gutes Produkt zu erstellen.
+      * Jeder im Team ist bereit auch zukünftig mehr zu geben, um ein fertiges und gutes Produkt zu erstellen.
-    * Problem: Notwendige Rails-Einarbeitung hält uns bisher noch von schnellerem Vorankommen ab.
+    * Notwendige Rails-Einarbeitung hält uns bisher noch von schnellerem Vorankommen ab.
-      * Maßnahme: Diese Problem sollte sich von selbst erledigen, da die grundlegenden Rails-Mechanismen nun bekannt sind.
+      * Diese Problem sollte sich von selbst erledigen, da die grundlegenden Rails-Mechanismen nun bekannt sind.
-    * Problem: Das Product-Backlog enthält veraltet bzw. bereits gestrichene Anforderungen. Außerdem wurden die einzelnen Anforderungen im Sprint-Backlog nicht direkt berücksichtigt.
+    * Das Product-Backlog enthält veraltet bzw. bereits gestrichene Anforderungen. Außerdem wurden die einzelnen Anforderungen im Sprint-Backlog nicht direkt berücksichtigt.
-      * Maßnahme: Product-Backlog wird zukünftig als Basis für die Sprint-Planung verwendet. PB-Einträge werden laufend vom Team geprüft und über Stefan/Andreas aktualisiert.
+      * Product-Backlog wird zukünftig als Basis für die Sprint-Planung verwendet. PB-Einträge werden laufend vom Team geprüft und über Stefan/Andreas aktualisiert.
-    * Problem: Es existiert kein Visual Prototype auf dem die Web-Entwicklung basiert. Widerspruch zwischen Theorie und Praxis, da die Theorie viel Zeitaufwand verursacht, welcher nicht geleistet werden kann.
+    * Es existiert kein Visual Prototype auf dem die Web-Entwicklung basiert. Widerspruch zwischen Theorie und Praxis, da die Theorie viel Zeitaufwand verursacht, welcher nicht geleistet werden kann.
-      * Maßnahme: Visual Prototype wird nicht umgesetzt, da die benötigte Zeit nicht zur Verfügung steht und die Entwicklung bisher auch ohne funktioniert hat.
+      * Visual Prototype wird nicht umgesetzt, da die benötigte Zeit nicht zur Verfügung steht und die Entwicklung bisher auch ohne funktioniert hat.
+==== TKs mit den einzelnen Teams ====
+=== Allgemeine Punkte ===
+  * Erwartungen der Teammitglieder an den SM in Erfahrung bringen
+    * Meinung zu TK mit mir zu Beginn, Anfang und Ende jedes Sprints.
+  * Was ist zur Zeit das größte Hindernis bei der Gesamtprojektarbeit?
+    * Meinung zur Zusammenarbeit mit den anderen Teams -> Gibt es Probleme?
+  * Zeitprobleme ansprechen -> viele schreiben die Klausuren nicht mit
+  * Anregungen/Wünsche für Trac (Wiki, Tickets) und SVN
+  * Gibt es noch Fragen zu Scrum? Probleme bei der Umsetzung? Unklarheiten?
+  * Impediment List
+    * Teilweise bestimmen einzelne Personen im Team mit ihren Meinungen die Vorgehensweise. Es werden keine demokratischen bzw. Mehrheitsentscheidungen getroffen bzw. es ist nicht ersichtlich, ob diese von einem größeren Teil des Teams so gewünscht sind.
+    * Nicht alle halten sich an das Glossar.
+    * Inhalte in der XML-Datei komplizierter dargestellt als sie sein müssten (Identifier/String-Parsing und zwei XML-Dateien). Integrationsteam muss die Unstimmigkeiten mit der XML-Datei klären.
+=== 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
+  * Sprint Backlog in OO? Warum nicht Tickets?
+=== Steuerung ===
+  * Retrospective
+    * Gut: effizientere TKs, Besprechung der Sprintziele mit dem PO in der Präsenzphase, methodisches Vorgehen
+    * Schlecht: nichts
+  * Impediment List
+    * Entwicklungskomplexität in der vom Kunden vorgegebenen Programmiersprache (C++).
+=== Web/DB ===
+  * Retrospective
+    * Gut: hohe Einsatzbereitschaft, effizientere TKs, bessere Nutzung Tickets, Abstimmung mit PO
+    * Schlecht: hoher Zeitaufwand, mangelnde Zeitplanung, Umstellung der IDE, unterschiedliche Schemata, lange Einarbeitungszeit für Rails, Abstimmung Requirements mit PO, kein Visual Prototype
+  * Zusammenlegung der Teams
+    * Hat es gut geklappt?
+    * Hat jeder feste Aufgaben oder wechseln die Mitglieder untereinander?
+  * Kommunikation mit anderen Teams (insb. FPL)
+    * Wer ist Hauptansprechpartner z.B. für Erstellung eines neuen Views?
+    * Kein View -> keine Möglichkeit für FPL weiterzumachen

Stefans Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge