Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- se:scrummaster [2008-08-03 15:54]
stefan
+++ se:scrummaster [2008-08-17 15:22]
stefan gelöscht
@@ Zeile 1: / Zeile 1: @@
 ===== Scrum Master =====
-==== Aufgaben nach Scrum ====
+==== Editor ====
-=== Nach Schwaber ===
+  * Steffen
-  * Ensures that the team is fully functional, productive and improves quality.
+    * 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.
-  * Enables close cooperation across all roles and functions and removes barriers.
+    * Gut: Unser Blog und unsere kurzen Konferenzen.
-  * Shields the team from external interferences.
+    * 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.
-  * Ensures that the process is followed.
+  * Andreas
-  * Teaches Product Owner and Team how to fulfill their roles.
+    * 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.
-=== aus Schulungsunterlagen ===
+==== Fertigungsplanung ====
-  * Guards and supports the Scrum process
+  * Patrick
-  * Facilitates team decision-making and team maturity
+    * Gut: stetige Erreichbarkeit von Stefan
-    * Divergence of ideas leading to informed convergence on decisions
+    * Schlecht: zu wenig Rückmeldung vom Unterdachziegel (Info bei Einchecken, Zwischeninfo)
-  * Removes impediments
+    * Bewegend: toller Buildprozess, erbarmungsloser Einsatz aller TM
-  * Protects the team from external interruptions
+  * Tina
-  * Acts as chief communicator – coordinates communications between team and external stakeholders, management, and other corporate communication
+    * 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
-==== Regelmäßige Aufgaben ====
+==== Simulation ====
-  * Projektbesprechung in Nürnberg planen
+  * Umsetzung seit letzem Mal
-    * Castello reservieren
+    * Petra mehr Engagement im Projekt; Ergebnis: zu 100% Umgesetzt Super Einsatz bei allen Teilmitgliedern.
-    * Vorarbeiten für Retrospectives von Teams einfordern
+    * Telkos Effizienter; Ergebnis: Verbessert, soll besser werden Andreas wünscht sich:
-  * Sprint Retrospectives erstellen
+      * Tagesordnung, Beschlüsse pro Tagesordnungspunkt
-    * Was war gut?
+    * Sonstige Verbesserungsvorschläge:
-    * Was lief schlecht und was können wir tun, um diese Punkte zu beheben/verbessern?
+      * Punkte nur EINMAL diskutieren; Entscheidungen nur in Frage stellen wenn die Mehrheit das wünscht.
-    * Was bleibt mir von diesem Sprint besonders in Erinnerung?
+      * Idee Andreas: "Es muss jemand sagen dass dieser Punkt nicht ganz ausdiskutiert werden soll"
-  * Kontrolle/Administration Ticket System
+  * Gut
-  * Trac-Ausfälle dokumentieren/Bergmann kontaktieren
+    * Die Eingesetzte Zeit wurde sehr effektiv genutzt, der von Herrn Andert wurde umgesetzt: Wir haben jeden Samstag von 9:00-16:00 miteinander zur gleichen Zeit gearbeitet, Kommunikation erfolgte während der Arbeit durch eine Skype Chat-Fenster mit anschließender Telko. Die Teilmitglieder arbeiteten meistens zusätzlich teilweise bis 19:30 weiter, teils auch unter der Woche.
-  * TK mit Teams zu Beginn (Retrospective), in der Mitte (aktueller Stand) und am Ende (Sprint Review inkl. Demo des Produkts) des Sprints
+    * Der Projektfortschritt war noch nie so gut und extrem enorm;
+    * Die Kundenpräsentation von Andreas ist beim Teilteam super angekommen. Obwohl von den Anforderungen eigentlich kein Punkt (nur einer) voll erfüllt war, konnte Andreas das was wir geleistet haben dem Kunden gut verkaufen. Andreas hat stets einen Kompetenten Eindruck vermittelt.
-==== Offene Punkte ====
-  * Stand Simulation
-    * Konflikte?
-    * Einarbeitung Jean
-    * Unfaire Aufteilung Zeitaufwand
-    * Benötigen sie noch Unterstützung?
-  * Kunden an die Ergebnisse lassen ("rumspielen")?
-  * https://141.75.245.203/trac/mse07/wiki/ScrumProzessbeschreibungEtc
-  * Videos
-    * <del>http://video.google.com/videoplay?docid=-7230144396191025011</del>
-    * http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland
-    * 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
-    * Frist zum Eintragen der anstehenden Aufgaben setzen
-    * Möglichkeit für Burndown-Chart schaffen
-    * Reports für Sprint 7 anlegen
-    * Gibt es noch andere sinnvolle Reports?
-  * Retrospectives an Andert
-  * Einheitliche XML-Beispieldatei erzeugen
-  * Zuordnung SM/PO in Trac nachtragen
-  * Zusammenarbeit mit PO klären
-  * Wiki aufräumen
-  * Erwartungen der Teammitglieder an den SM in Erfahrung bringen
-  * Sprint Review mit PO abstimmen (Produktdemo am Ende des Sprints)
-  * Zeitprobleme ansperechen -> viele schreiben die Klausuren nicht mit
-  * Tickets der Datenbank werden nicht im Report angezeigt
-  * Vortrag von Robra
-  * SVN
-    * https://141.75.245.203/trac/mse07/discussion/1/11
-    * https://141.75.245.203/trac/mse07/discussion/1/9/47#47
-==== 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
-    * coulon.j
-    * robert.stumpe
-    * p.keinath
-    * andreas.macher1
-  * ab 12.08. Steuerung
-=== Web/DB ===
-  * Highlight: Grundlegendes Sprint-Ziel wurde erreicht.
-  * Gut
-    * Bereitschaft des gesamten Teams gegen Ende des Sprints unter hohem Zeitaufwand das Sprint-Ziel zu erreichen (insbesondere von Patrick).
-    * Besprechungen wurden in Länge und Frequenz auf das wirklich Notwendige eingeschränkt. Dadurch wurde der Overhead gering gehalten.
-    * Nutzung/Aktualisierung der TRAC-Tickets wurde am Anfang des Sprints nur schlecht umgesetzt. Am Ende des Sprints war dies besser.
-    * Während des Sprints hat die Abstimmung mit dem PO über Stefan gut funktioniert.
-    * 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.
+    * Andreas hatte den Eindruck dass während des gemeinsamen Arbeitens der eine oder andere mal länger weg war; weil manchmal manche Antworten länger gedauert haben.
-      * 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.
+    * Andreas würde sich wünschen dass sich jeder abmeldet wenn er seinen Arbeitsplatz verlässt. Robert+Petra: Manchmal lässt man sich mit Antworten eben auch mal Zeit oder man fühlt sich nicht angesprochen.
-    * 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.
+    * Bei Telkos haben wir Jean nicht abgeholt (bringschuld).
-      * 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.
+    * Jean hat das abholen auch nicht eingefordert (holschuld).
-    * Problem: Während des Sprints entstand eine verwirrende Anzahl von unterschiedlichen Schematas auf dem zentralen DB-Server.
+    * Skype-Problem (schlechte Sprachqualität) bei Jean
-      * 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.
+    * Wunsch von Robert: Wenn Komponenten ausführlich Dokumentiert sind, möchte er dass das auch gelesen wird bevor email Fragen gestellt werden, da er nicht alles doppelt und dreifach schreiben möchte. Besser: Doku lesen und fragen was unklar ist.
-    * Problem: Zeitbelastung durch das Projekt war höher als geplant.
+    * Nichtimplementierte Interfaces haben zum drum-herumarbeiten geführt was Zeit gekostet hat.
-      * Maßnahme: Jeder im Team ist bereit auch zukünftig mehr zu geben, um ein fertiges und gutes Produkt zu erstellen.
+    * Nicht-Kompilierbarer Code von dem andere abhängig sind!!! nicht Einchecken
-    * Problem: Notwendige Rails-Einarbeitung hält uns bisher noch von schnellerem Vorankommen ab.
+    * Manchmal ist eine sachlichere Diskussion bessert
-      * Maßnahme: Diese Problem sollte sich von selbst erledigen, da die grundlegenden Rails-Mechanismen nun bekannt sind.
+  * Verbesserungen
-    * Problem: Das Product-Backlog enthält veraltet bzw. bereits gestrichene Anforderungen. Außerdem wurden die einzelnen Anforderungen im Sprint-Backlog nicht direkt berücksichtigt.
+    * Punkte siehe "Umgesetzte Ziele der letzten Retrospektive"
-      * 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.
+    * Jean möchte jeden anrufen zur Einarbeitung
-    * 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.
+    * EA Files besser Pflegen –>bessere Dokumentation -> bessere Einarbeitung von Jean; jeder soll die geänderten Packages aus seinem Replika exportieren und das exportierte einchecken + Simulation.ea updaten.
-      * 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.
+    * Generell mehr mit EA arbeiten -> Reverese-Engeneering-Feature -> Dokumentation geschieht von selbst
+    * Ordner Integrated: nur compilierbarer code
-=== Steuerung ===
+==== Steuerung ====
   * Highlight
     * erste Erfolge bei den Design- und Implementierarbeiten
@@ Zeile 111: / Zeile 78: @@
     * keine Anmerkung
-=== Editor ===
+==== Web/DB ====
-  * Steffen
+  * Highlight: Grundlegendes Sprint-Ziel wurde erreicht.
-    * 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
-    * Gut: Unser Blog und unsere kurzen Konferenzen.
+    * Bereitschaft des gesamten Teams gegen Ende des Sprints unter hohem Zeitaufwand das Sprint-Ziel zu erreichen (insbesondere von Patrick).
-    * 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.
+    * Besprechungen wurden in Länge und Frequenz auf das wirklich Notwendige eingeschränkt. Dadurch wurde der Overhead gering gehalten.
-  * Andreas
+    * Nutzung/Aktualisierung der TRAC-Tickets wurde am Anfang des Sprints nur schlecht umgesetzt. Am Ende des Sprints war dies besser.
-    * Highlight: Mementoerstintegration hat funktioniert. Gemeinsames Debugging am Editor hat Spass gemacht.
+    * Während des Sprints hat die Abstimmung mit dem PO über Stefan gut funktioniert.
-    * 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.
+    * Grundlegendes Sprint-Ziel wurde erreicht.
-    * Schlecht: XML Schemadefinition läuft im Gesamtteam nicht zufriedenstellend. Jochen ohnehin stark durch Projekt belastet -> Gesamtlösung muss gefunden werden!
+  * Schlecht
-  * Jochen
+    * 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.
-    * 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.
+      * 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.
-    * 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.
+    * 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.
-    * 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.
+      * 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.
+    * Während des Sprints entstand eine verwirrende Anzahl von unterschiedlichen Schematas auf dem zentralen DB-Server.
+      * 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.
+    * Zeitbelastung durch das Projekt war höher als geplant.
+      * Jeder im Team ist bereit auch zukünftig mehr zu geben, um ein fertiges und gutes Produkt zu erstellen.
+    * Notwendige Rails-Einarbeitung hält uns bisher noch von schnellerem Vorankommen ab.
+      * Diese Problem sollte sich von selbst erledigen, da die grundlegenden Rails-Mechanismen nun bekannt sind.
+    * Das Product-Backlog enthält veraltet bzw. bereits gestrichene Anforderungen. Außerdem wurden die einzelnen Anforderungen im Sprint-Backlog nicht direkt berücksichtigt.
+      * 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.
+    * 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.
+      * Visual Prototype wird nicht umgesetzt, da die benötigte Zeit nicht zur Verfügung steht und die Entwicklung bisher auch ohne funktioniert hat.

Stefans Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge