MSP: Moderierte Rednerliste

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Dokumentation
Arbeitstitel MSP: Moderierte Rednerliste
Kurs Methoden des Software-Entwicklungsprozesses
Semester WS 08/09


Im Rahmen der Veranstaltung Methoden des Softwareentwicklungsprozesses (MSP) wollen wir als Projektgruppe die Projektarbeit Moderierte Rednerliste für das eModerationsmodul bearbeiten. Das Team wird zunächst innerhalb des Kurses einen YAML-basierten Style für eStudy erstellen. Dieser Style positioniert das Portal als seriöse in der IT-Branche einsetzbare Kollaborationsplattform. Nach dieser Aufgabe widmen wir uns der Projektaufgabe: Moderierte Rednerliste!

Innerhalb dieses Artikels befindet sich zunächst das Vision Document, welches die Projektvision beinhaltet. Es erklärt, wie sich das Team seine Aufgabe der moderierten Rednerliste vorstellt und umsetzen möchte. Dieses Dokument beschreibt das Projekt neutral, sodass es auch dem Kunden vorlegt werden kann.

Im darauf folgenden Abschnitt steht unser Mission Statement. Hierbei handelt es sich um Vereinbarungen, die innerhalb des Teams getroffen wurden. Im Normalfall wird der Kunde dieses Dokument nicht zu sehen bekommen. Es ist ein rein internes Dokument, welches Eskalationsstufen beschreibt, falls es zu unstimmigkeiten innerhalb der Gruppe kommen sollte oder anderweitige Probleme auftreten. Auch die Organisation zur Durchführung der Aufgabe wird erläutert. Hier sei unter anderem die Testgetriebene Entwicklung genannt.

Der letzte Abschnitt widmet sich unseren Hausübungen. Hier wird nochmals auf die einzelnen Vision Documents der Teammitglieder verwiesen, die die Hausübungen der einzelnen Teammitglieder beschreiben.

Inhaltsverzeichnis

Vision Document

Introduction

Laufende eModeration OHNE Moderierte Rednerliste

Moderationstechnik laut Metaplan vs. eModeration der Kollaborationsplattform eStudy

Das eStudy Modul eModeration basiert auf den von Metaplan definierten Arbeitsweisen. Bei dieser Moderationstechnik gibt es drei Rollen, die des Moderators, die des Butlers und die des Teilnehmers. Betrachten wir die zwei zentralen Rollen: Moderator und Teilnehmer.


  • Moderator

Der Moderator hat die klassische Funktion, ein Gespräch bzw. eine Moderation zu moderieren. Eine Moderation besteht bei Metaplan aus Pinnwänden, Karten und vielen weiteren Materialien.

  • Teilnehmer

Teilnehmer beschriften Karten, heften Klebepunkte an die Pinnwand (siehe nebenstehendes Bild) oder haben sonstige Einwände.


Das bestehende Modul eModeration ermöglicht es bereits, virtuelle Pinnwände bereit zu stellen. Auf diesen Pinnwänden können Karten, Überschriftswolken, Überschriftsbalken, Klebepunkte und weitere Materialien angebracht werden. Der Moderator kann dabei bestimmen, ob er selbst die Materialien (eine beschriftete Karte) eines Teilnehmers an die Pinnwand heftet, oder ob der Teilnehmer selbst dazu aufgefordert ist.

Dieses Szenario kann verteilt oder in einem Vorlesungssaal/Hörsaal stattfinden. Dafür gibt es zwei getrennte Ansichten, auch hier die des Teilnehmers und die des Moderators.

Das Problem bei einem verteilten Szenario besteht darin, dass es derzeit keine Funktion innerhalb des Moduls gibt, wo sich die Teilnehmer untereinander austauschen können, oder ein Teilnehmer einen Einwurf einbringen kann. Hierzu soll das Teilprojekt Moderierte Rednerliste dienen.

Wie kann die Moderierte Rednerliste eingesetzt werden

Besonders in verteilten Szenarien nimmt die Moderierte Rednerliste dem Moderator die Arbeit ab, die Reihenfolge der Sprecher verwalten zu müssen. Ohne diese Möglichkeit müsste der Moderator dies alles selbständig tun. Besonders wenn er die Teilnehmer nicht vor sich hat, ist dies ein sehr aufwändiger Prozess, da er nicht auf Handzeichen zurückgreifen kann. Die Moderierte Rednerliste stellt daher im Prinzip ein virtuelles Handzeichen inklusive Verwaltung der Sprecher-Reihenfolge für den Moderator dar.

Wie ist die Moderierte Rednerliste zu verwenden

Teilnehmer können sich über einen Ich möchte sprechen-Knopf beim Moderator bewerben. Nimmt der Moderator keine Änderungen vor, reihen sich die Teilnehmer durch ihre Bewerbung automatisch in eine Warteschlange ein. Der Moderator kann dann mit einem Klick den nächsten Redner aus der Warteschlange nehmen. Dem Redner wird signalisiert, dass er an der Reihe ist und kann zu sprechen beginnen. Nach Ablauf der festgelegten Sprechzeit muss der Teilnehmer zum Ende kommen.

Business Needs/Requirements

Das Tool Moderierte Rednerliste kann durch seine Funktion der Kollaborationsplattform eStudy und insbesondere dem bereits vorhandenen Modul eModeration viele Vorteile bringen. Um diese Vorteile zu herauszuarbeiten stellt sich zunächst die Frage, wozu dieses eingesetzt werden soll. Diese Frage soll im weiterem Textverlauf geklärt werden und die Vorzüge einer Moderierten Rednerliste erörtert werden:

  • Bei einem verteilten Szenario, bei dem sich der Moderator und die Teilnehmer nicht im selben Raum befinden, kann weder der Moderator noch die anderen Teilnehmer erkennen, ob jemand etwas sagen möchte.
  • Ein weiterer Vorteil den das Tool Moderierte Rednerliste bietet ist, dass die Moderationsteilnehmer Eigeninitiative ergreifen können. Sie müssen/können sich als Redner bewerben, um eine Ergänzung oder einen Einwand einzubringen.
  • Bei einem Szenario mit einer unüberschaubaren Teilnehmerzahl ist es dem Moderator sowie den Moderationsteilnehmern unmöglich, jeden Teilnehmer zu kennen. Befindet man sich in großen Hörsälen, ist es zudem oft der Fall, dass die Teilnehmer alle in eine Richtung blicken und sich somit nur schlecht gegenseitig sehen können. Auch hier bietet das Tool Abhilfe: Durch die Abbildung eines Fotos und des Namens eines Redners, kann dessen Stimme einer Person zugeordnet werden. Anonymität ist oftmals unerwünscht, Interaktivität aber ist gewünscht. Die Teilnehmer sollen sich persönlich kennen lernen und auch ansprechen können.
  • Mit Hilfe des Tools kann die Sprechzeit erteilt und festgelegt werden. Der Gedanke hinter dieser Funktion ist, dass nicht ein Teilnehmer alleine die ganzen Einwände bringt und eine einseitige Diskussion entsteht. Ziel ist eine Diskussion, geleitet durch den Moderator.

Product/Solution Overview

Das Endprodukt wird die "Moderierte Rednerliste" sein. Hier wird es Informationen zum aktuellen Sprecher geben, zum Beispiel in Form von Vor- und Nachname, Bild und ein Zeitticker. Der Ticker gibt an, wie lange der aktuelle Redner noch sprechen darf. Die Zeit, die einem Redner zur Verfügung steht, wird vom Moderator festgelegt. Der Standardwert beträgt 30 Sekunden.

Da mehrere Teilnehmer Einwände oder Anmerkungen haben könnten, ist eine Redner-Warteschlange notwendig. Darin wird jeder Teilnehmer, der den "Ich möchte sprechen"-Button betätigt, eingetragen.

Beispiel, wie eine Moderierte Rednerliste aussehen könnte

Für den Fall, dass der Teilnehmer seine Rednerbewerbung zurückziehen möchte, wird eine weitere Funktion erstellt, über die der Teilnehmer aus der Rednerliste entfernt werden kann. Der Moderator soll in der Lage sein, einem Teilnehmer zu unterbrechen oder ihm seine Rednerrechte gänzlich zu entziehen.

Die nebenstehende Grafik zeigt, wie eine Moderierte Rednerliste/Speakerbox aussehen könnte. Die zuvor genannten Informationen wie Bild, Name und Zeit sind enthalten.

Major Features

Die wichtigsten Funktionen der moderierten Rednerliste sollen im Folgendem dargestellt werden:

  • Der Moderator kann Teilnehmern das Rederecht entziehen. Dies wird dem Redner über eine grafische Anzeige vermittelt.
  • Der Moderator bestimmt den Zeitpunkt, an dem die Teilnehmer Sprachbeiträge leisten dürfen. Dies ist wichtig, damit der Fluss der Moderation nicht unterbrochen wird.
  • Der Teilnehmer kann jederzeit seine eigene Rednerbewerbung zurückziehen, sollte sich z.B. sein Einwand mittlerweile erübrigt haben.
  • Der Redner wird mittels eines zuvor eingestellten Fotos / Avatars in der Rednerliste hervorgehoben, damit jederzeit klar ersichtlich ist, welcher Teilnehmer gerade spricht. Dies ist vor allem dann nützlich, wenn die Teilnehmer nicht persönlich bekannt sind.
  • Der Moderator kann die dem Redner zur Verfügung gestellte Redezeit frei einstellen und diese auch während des Gespräches verkürzen / verlängern. Somit hat der Moderator die Möglichkeit, die Diskussion in die gewünschte Richtung zu lenken.
  • Wenn ein Teilnehmer das Rederecht erhält, so wird ihm dies durch eine grafische Anzeige deutlich vermittelt, um Unterbrechungen im Ablauf zu vermeiden.

Scope & Limitations

Es sind einige Einschränkungen bei diesem Tool zu beachten, die nicht von der Kollaborationsplattform beeinflusst werden können. Darunter fallen zunächst:

  • der DSL Anschluss bzw. die zur Verfügung stehende Bandbreite des Moderationsteilnehmers.

Das Modul eModeration ist über das Internet erreichbar. Es wird darauf geachtet, dass das Datenvolumen möglichst gering gehalten wird.

  • Sprachsoftware

In Anbetracht der Zeit ist es nicht möglich (und auch nicht sinnvoll), eine komplett eigene Sprachsoftware zu implementieren. Hier muss auf ein bestehendes Tool/Produkt zurückgegriffen werden. Dies könnte mit Hilfe der Externen Tools, wie es bereits durch Wiki, Blog, Mantis oder Jabber bekannt ist, geschehen. Hier wurden bisher Teamspeak oder Skype in Betracht gezogen. Eine endgültige Entscheidung wurde nicht getroffen.

  • Bilder der Personen müssen bereits im eStudy Profil verfügbar sein

Ein weiterer Aspekt sind die Benutzerbilder der Moderationsteilnehmer. Es ist vorgesehen, die Profilbilder der Benutzer der Kollaborationsplattform eStudy zu verwenden. Hier müssen Bilder der Teilnehmer vorliegen, sonst kann kein Teilnehmerbild in der Speakerbox/Rednerliste angezeigt werden.

  • Hardware

Die Hardware in Form eines Client- / Moderator-PCs sowie Headset, Mikrofon oder Lautsprecher wird ebenfalls nicht bereitgestellt. Sie muss vom Moderator und/oder den Moderationsteilnehmer selbstständig beschafft werden.

Other Needs

  • Die Rednerliste sollte dahingehend erweitert werden, dass der Moderator die Möglichkeit erhält, mehreren Teilnehmern gleichzeitig das Rederecht zu erteilen. Diese Option soll Diskussionen zu einem Thema unterstützen und muss durch eine geeignete Mittel zur Kommunikation unterstützt werden. Die Rednerliste bietet lediglich die Möglichkeit der Verwaltung der "Rednerechte". In das Modul ist keine eigene Sprachsoftware eingebunden.
  • Falls es das Budget erlaubt, wird die Möglichkeit geprüft, ein Videokonferenz-Modul in eStudy einzubinden. Das Einbinden der Videokonferenz-Funktionalität könnte ebenfalls über die Externen Tools geschehen, wie es auch bei der Sprachsoftware angedacht ist. Ein geeignetes Tool hierfür muss erst recherchiert werden.

Links

Mission Statement

Die Gruppe

Die Gruppenmitglieder des Teams Moderierte Rednerliste sind:

  • Christoph Thelen (Projektleiter)
  • Sascha Henry (stlv. Projektleiter)
  • Paul-Christian Volkmer
  • Henrik Leupold
  • Sebastian Philippi
  • Christian Ketter
  • Christian Thomas Weber

Vereinbarungen

Regelmäßiges Treffen

Die regelmäßigen Treffen der Gruppe finden Montags von 08.00 Uhr bis 11.20 Uhr statt. Weitere Treffen können bei Bedarf festgelegt werden.

Kommunikationsmedien

Als Kommunikationsmedien werden die nachstehenden Medien verwendet:

  • eMail
  • Kollaborationsplattform eStudy (Forum, Dateien und Links,...)
  • Jabber
  • ICQ
  • evtl. Skype

Maßnahmen bei (unentschuldigtem) Fehlen

Es kann selbstverständlich vorkommen, dass Teammitglieder, aus den verschiedensten Gründen einmal verhindert sind und deshalb nicht am Teammeeting teilnehmen können. Für diesen Fall gibt es allerdings auch Regeln:

  • Sollte man nicht an einem Teammeeting teilnehmen können, so ist die Projektleitung selbständig zu kontaktieren und sein Fehlen zu begründen/entschuldigen.
  • Sollte Punkt Eins ausgelassen werden, wird die Projektleitung ein Gespräch mit dem betroffenen Teammitglied suchen.
  • Bei mehrmaligen unentschuldigtem Fehlen, wird die Projektleitung die Kursleitung kontaktieren und das Teammitglied des Projektes verweisen.

Eine Entschuldigung bei Fehlen muss bis zum folgenden Teammeeting vorliegen, sonst wird das Fehlen als unentschuldigt betrachtet.

Rechte der Projektleitung und der Projektmitglieder

Die Projektleitung ist dazu berechtigt Aufgaben an die Teammitglieder zu delegieren. Diese können den Auftrag in Absprache ablehnen. Dafür sollte es plausible Gründe geben, zum Beispiel:

  • a) Auftrag liegt nicht im Budget des Projektmitglieds
  • b) Mitglied hat nicht das nötige Wissen, um die Aufgabe im vorgesehenen Zeitraum zu bewältigen, weiß aber genau, dass ein anderes Mitglied die Aufgabe umsetzen könnte und auch, dass dies in dessen Budget passt.

Maßnahmen bei Nichtreagieren oder Aufgabenwahrnehmung der Projektleitung

In einem Projekt muss die Projektleitung für Fragen oder auch Kritik ansprechbar sein. Weiterhin gilt es als Aufgabe der Projektleitung den Stand des Projektes zu einem lauffähigen Release zu bringen. Hier muss es auch Regeln geben, was passiert, wenn die Projektleitung ihre Aufgaben nicht wahrnimmt.

Testgetriebene Entwicklung

Vorgesehen ist die Testgetriebene Entwicklung mit PHPUnit und Selenium. Codefragmente ohne Tests werden als nicht lauffähig betrachtet. User Stories sind nur dann abgeschlossen, wenn die zugehörigen Akzeptanztests erfolgreich absolviert wurden.

Einarbeitung in den bestehenden Quellcode / in Aufgaben

Es wird davon ausgegangen und erwartet, dass jedes Teammitglied selbständig arbeitet. Das bedeutet, dass jeder sich in seine Aufgaben einarbeitet, z. B. in bestehenden Quellcode oder Dokumentation.

Dokumentation der Teammeetings

Die teaminternen Meetings werden reihum von den Teammitgliedern dokumentiert und zeitnah den anderen Teammitgliedern bereitgestellt.

Implementierung der Moderierten Rednerliste

Während der Entwicklung der moderierten Rednerliste wurden verschiedene Techniken verwendet. Hierzu zählten vor allem die Vorgehensweise nach XP sowie das Tool XP-Web und das Planspiel-Modul aus eStudy. Um die Gewichtung der zuvor in einem Kundengespräch definierten User-Stories festzulegen, wurde in einem Treffen das Planning Poker gespielt. Dabei stellten sich die folgenden User-Stories als die wichtigen heraus:

  • Rednerliste soll von jedem Teilnehmer einsehbar sein
  • Die Rednerliste soll auf einer eigenen Pinnwand dargestellt werden. Diese Pinnwand sollte wie gewohnt bearbeitet werden können.
  • Ein Redebeitrag sollte mit Betreff und Anreißer auf der Pinnwand dargestellt werden.
  • Die Rednerliste soll archiviert werden können.

Anpassung / Erweiterung des eModerations-Moduls

Für die Umsetzung des Projektes wurden zahlreiche Quelldateien bearbeitet. Zunächst eine kleine Übersicht der letzten Änderungen:

Angepasste Dateien

Es folgt eine Liste aller Dateien, die bearbeitet wurden:

Allgemein
WSDL
Unit Tests
Selenium Tests
JavaScript
Kartenset Klassen
Persistenz Klassen
Nachrichtensystem
Bildexport
Templates
Webservice

Designunterlagen

Architektur der eModeration in GML

Am grundlegenden Design der eModeration hat sich nichts geändert. Für die Umsetzung der Moderierten Rednerliste wurde es lediglich erweitert. Eine vollständige Dokumentation befindet sich bereits im Kurs MSP unter Dateien & Links > Team "Moderierte Rednerliste" > Lernunterlagen > Grundlegendes zur eModeration. Eine weitere gute Dokumentation und gleichzeitig eine detaillierte Beschreibung der Sicherheitsfeatures findet sich im Artikel WebSecurity eModeration. Von dem aktuellen Stand der Serverseitigen-Codeänderungen wurde eine Dokumentation mit Doxygen erstellt.

Webservice Erweiterung

Der Webservice hat vier neue Funktionen bekommen [1]:

  • getSpeakers Parameter: ID der Moderation

Diese Funktion liefert alle Redner in der Warteschlange und alle Redner, die zu diesem Zeitpunkt gerade sprechen.

  • applyForSpeaker Parameter: Rede-Objekt

Mit einem Betreff und einem Anreißer bewirbt sich der Redner über diese Funktion.

  • promoteSpeaker Parameter: Sprecher-Objekt

Der übergebene Sprecher darf mit seiner Rede beginnen.

  • dismissSpeaker Parameter: ID des Spechers

Der Redner mit der übergebenen ID wird "entlassen", so dass er nicht mehr sprechen darf.

Datenbank

Um die Rednerliste zu persistieren, war eine neue Datenbanktabelle nötig. Diese wird ausschließlich vom Webservice angesprochen. Im Folgenden eine Aufstellung dieser neuen Tabelle "mod_rednerliste":

Spaltenname Beschreibung
id ID des Redebeitrages.
mod_id ID der Moderation zu der dieser Redebeitrag gehört.
pin_id ID des Pinboards zu der der Redebeitrag gehört.
user_id ID des Redebeitrag-Urhebers.
betreff Thema des Redebeitrages in Textform.
inhalt Anreisser des Redebeitrages in Textform.
status Status des Redebeitrags (0 angemeldet, 1 aktiv, 2 abgeschlossen).
applicationtime Uhrzeit zu der die Anmeldung in die Rednerliste erfolgt ist.
starttime Uhrzeit zu der der Redebeitrag gestartet wurde.

Nachrichtensystem

Die neuen Funktionen des Webservice werden über die neue Rednerlisten-Klasse im Nachrichtensystem angesprochen. Die Klasse führt sowohl Lade- als auch Speicheroperationen auf die Funktionen durch. Außerdem erweitert sie die erhaltenen Daten um wichtige Informationen über die Rechte des jeweiligen Benutzers. Damit ist gewährleistet, dass zum Beispiel nur der Moderator alle Redebeiträge entfernen kann und ein Teilnehmer nur seine eigenen.

Oberfläche

Jeder Teilnehmer sieht den Knopf "Als Redner bewerben". Ein Klick öffnet einen Dialog, wo der Betreff und ein Anreißer des Redebeitrags formuliert werden müssen. Für die beiden Felder ist die Eingabe von BBCode möglich. Nach Abgabe der Bewerbung erscheint der Teilnehmer automatisch in der Rednerliste unterhalb der Teilnehmerliste. Über ein Tooltip wird der Inhalt der geplanten Rede verraten. Ein Teilnehmer kann sich auch jederzeit wieder aus der Liste entfernen. Der Moderator kann sogar allen Teilnehmern einzeln das Rederecht entziehen. Der Beitrag wurde außerdem automatisch auf einer Pinnwand archiviert. Der Moderator gibt den Startschuss für einen Redebeitrag über seinen Knopf "Nächster Redner". Die Moderation des entsprechenden Redners geht danach automatisch in den Redemodus über. Die verbleibende Zeit wird dabei deutlich angezeigt. Für alle anderen Teilnehmer und für den Moderator wird ein kleines Rednerfenter angezeigt.

Kartenset

Die eModeration verwendet sogenannte Kartensets, in denen alle dem Moderator zur Verfügung stehenden Karten enthalten sind. Diese Kartensets können über ein Zeichenprogramm frei erstellt werden. Dies stellt aber gleichzeitig eine Einschränkung für die Moderierte Rednerliste dar. Denn auf der Pinnwand platzierte Karten können nur dann angezeigt werden, wenn sie in dem in der Moderation aktiviertem Kartenset vorhanden sind. Daher musste ein internes Kartenset erschaffen werden, das automatisch allen anderen Kartensets zugewiesen wird. Dadurch können dem eigentlichen Kartenset fremde Karten dargestellt werden. Gleichzeitig kann dieses Kartenset wie alle anderen über das Zeichenprogramm angepasst werden.

Unit Tests

Die Funktionalität in Bezug auf die Oberfläche wurde mittels zwei Unit Tests entwickelt [2] [3]. Um die korrekte Verwendung des internen Kartensets sicherzustellen, wurden hierfür ebenfalls Unit Tests erstellt. Da das Erstellen von Fixtures recht aufwändig sein kann, haben wir zwei zusätzliche Klassen entwickelt: PinboardSetBuilder und PinboardSetContainerBuilder. Diese Klassen verfügen über ein Fluent Interface, so dass simple und sehr elegante Testklassen geschrieben werden können. Der Name der Klassen verrät außerdem den Einsatz des Builder-Musters. Folgender Auszug aus der Klasse PinboardSetTest zeigt deutlich, wie einfach das Erstellen von Fixtures geworden ist; hier wird ein Kartenset mit drei Karten und jeweils einer Einzelkarte erstellt:

public function testShouldFindCardById() {
  $set = $this->builder->card( $this->builder->container()->id(100)->build() )
                       ->card( $this->builder->container()->id(200)->build() )
                       ->card( $this->builder->container()->id(300)->build() )
                       ->build();
  
  $card = $set->getCardById(200);
  
  $this->assertEquals(200, $card->id);
}

Selenium Tests

Neu hinzugekommen sind mehrere Selenium Tests. Diese Tests sollen das Prozedere der moderierten Rednerliste nachspielen und natürlich die volle Funktionalität testen. Außerdem können damit etwaige Konfigurationsschritte schnell erledigt werden.

Zusammenfassung

Im Rahmen unserer Projektarbeit konnten die wichtigsten Features bereits umgesetzt werden. Dazu zählen die im Punkt "Implementierung" genannten User-Stories.

Im Rahmen der Projektarbeit wurde deutlich, dass sehr viele der im Modul verwendeten Java-Script Dateien eines umfassenden Refactoring bedürfen um diese in einem angemessenen Zeitrahmen warten und erweitern zu können. Die Entwicklung eines Verständnisses dieser Dateien verbrauchte ein unangemessen grosses Budget. Dieses Refactoring konnte mit dem vorgegeben Budget nicht durchgeführt werden und sollte deshalb tunlichst im Rahmen einer anderen Vorlesung thematisiert werden.

Als Erweiterung der Moderierten Rednerliste wäre ein Konferenzmodus denkbar. Dieser wurde bisher nicht implementiert.

Prozessanalyse

Zusammenarbeit im Team

Die Zusammenarbeit innerhalb des Teams funktionierte während des gesamten Projektes sehr gut. Dies lag vor allem daran, dass wir einen festen wöchentlichen Arbeitstermin hatten. Da also immer das komplette Team anwesend war, waren die Mitglieder auch stets motiviert. Neben diesem Termin fanden zusätzliche Treffen nur statt, wenn etwas wichtiges anstand. Ansonsten wurde auch zum größten Teil auf das Arbeiten zu Hause verzichtet, da es nicht notwendig war. Außerdem hat dies erheblich die Kommunikation erleichtert, da keine zusätzlichen Kanäle bemüht werden mussten.

Die einzelnen Teammitglieder hatten einen unterschiedlichen Wissenstand und teilweise auch etwas weniger Erfahrung. Diejenigen, die bereits viel mit eStudy gearbeitet haben, halfen daher den übrigen Entwicklern. Die Aufgaben wurden also nicht zwangsläufig so vergeben, dass sie von dem jeweiligen Entwickler auch wirklich ausgeführt werden konnten. Statt dessen haben wir bewusst auf das Prinzip "Pair Programming" gesetzt, um einen Wissenstransfer zu schaffen.

Verspätungen zu den Treffen wurden immer angekündigt und waren manchmal schon Tage vorher bekannt, was sehr gut war. Es gab daher überhaupt keine Probleme in diesem Bereich. Generell war die Atmosphäre sehr locker und angenehm.

Einige Tage vor dem nächsten Treffen wurde von der Teamleitung die Agenda bekannt gegeben, die dann abgearbeitet wurde. Die Mitglieder teilten sich dabei freiwillig ein. Protokolle wurden mit einigen Ausnahmen keine geschrieben.

Zusammenarbeit mit der Kursleitung

Neben den offiziellen Terminen gab es zwei Treffen mit der Kursleitung. Beim ersten Treffen wurden zusammen mit dem Kunden die User Stories verfasst. Später wurde dann das aktuelle Zwischenergebnis vorgestellt. Die offiziellen Termine waren gut, um auch den Stand der anderen Teams zu sehen.

Die Kursleitung setzte ein hohes Maß an Fachwissen voraus, was nicht jedem Mitglied gefallen hat. Um den Start in das Projekt zu erleichtern, wurde außerdem eine Entwickler-DVD bereitgestellt. Diese Idee fanden alle sehr gut. Leider wurden einige Mängel festgestellt, die immer wieder unnötig Zeit gekostet haben. Die DVD muss also dringend weiterentwickelt werden.

Die "Start-Stop-Wieder-tun"-Liste

Was wir das nächste Mal beginnen werden, zu tun, ist...

  • noch gezielter die Aufträge zu verteilen
  • eine allgemeine Projekt-Roadmap zu erstellen
  • Zeiten der einzelnen Mitglieder rigoroser einzufordern

Was wir das nächste Mal nicht mehr tun werden, ist...

  • zu viel Zeit mit den HÜs zu verbrauchen
  • eine Aufgabe übermäßig von nur einem Mitglied erledigen zu lassen

Was wir das nächste Mal wieder tun werden, ist...

  • einen einheitlichen Projekttermin zu haben, wo die meiste Arbeit erledigt wird
  • die lockere Atmosphäre beizubehalten
  • noch mehr Fokus auf die handwerklichen Aspekte der Software-Entwicklung zu legen

Hausübungen der Teammitglieder

Abschluss-Metriken

Budget Burndown

BB-15.png

Budget Verbrauch der Mitglieder

BV-15.png

Style Aufwendungen

SA 15.png

HÜ Aufwendungen

HA 15.png

Projekt Aufwendungen

PA 15.png

StoryCards

SC 15.png

Glossar

Anreißer

Der Vortragende reißt kurz den Inhalt seines Beitrags an, damit sich der Moderator und auch die übrigen Teilnehmer im Vorfeld darüber informieren können.

Einzelkärtchen

Viele einzelne Kärtchen ergeben eine Karte. Ein Kärtchen kann zum Beispiel ein einzelnes Feld in der Karte einer Gewichtungsfrage sein.

Karte

Eine Collage von Einzelkärtchen. Eine Karte gehört zu einem Karten-Set. Im Karten-Set-Editor wird eine Karte als "Tab"-Element dargestellt. Der Moderator platziert diese Karten auf der Pinnwand.

Karten-Set

Eine Zusammenstellung von vielen Karten. Der Moderator kann ein Karten-Set für seine Moderation auswählen und die darin enthaltenen Karten auf seiner Pinnwand platzieren.

Moderator

Der Moderator ist der "Leiter" einer Moderation. Er ist üblicherweise dafür Verantwortlich, die Diskussion auf der Pinnwand zu dokumentieren.

Pinnwand

Auf einer Pinnwand wird die Diskussion dokumentiert. Zu einer Moderation gehört eine beliebige Anzahl an Pinnwänden.

Teilnehmer

Jeder Benutzer in einer Moderation, der nicht der Moderator ist, ist automatisch ein Teilnehmer.

Warteschlange

Die Rednerliste stellt eine Warteschlange dar. Neue Redner müssen sich hinten anstellen (FIFO).


--Henry-SHe 11:05, 3. Nov. 2008 (UTC)

--Thelen-CTh 15:13, 4. Nov. 2008 (UTC)

--Philippi-SPh 12:57, 2. Feb. 2009 (UTC)