MSP:Projekt-Repository

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Team

Vision Document

Introduction

Ziel unseres Projektes ist ein zentrales Dokumentenverwaltungsmodul für die Lernplattform eStudy, basierend auf der Open-Source-Software zur Versionsverwaltung Subversion. Das Dokumentenverwaltungsmodul wird eine Erleichterung für Projekte sein die viel Source Code, Dokumente, Pläne oder Skizzen beinhalten. Dieses Modul soll jeder eCommunity in eStudy zur Verfügung stehen und wird diese bei der Verwaltung von gemeinsamen Dokumenten unterstützen.

Business Needs/Requirements

  • PHP5
  • Tigris SVN WebClient
  • SVN Server

Product/Solution Overview

Unser Motto zum Projekt lautet: "Keep it simple." Wir wollen den eCommunities eine komplette Versionsverwaltung mit SVN zur Verfügung stellen leicht zu verstehen und zu bedienen ist.

Dazu zählt:

  • eine Simple Web-Oberfläche zur Versionsverwaltung
  • Up- und Download von Dokumenten über eine Web-Oberfläche
  • Zugriff auf SVN über externe SVN- Clients (z.B. Subclipse)

Major Features (hier: Features von SVN)

File- & Directory Versioning

Versionieren von Dateien & Verzeichnissen. Veränderungen an Verzeichnisbäumen werden erkannt und verarbeitet.

True Version History

Für jede Datei entsteht eine eigene, neue History (im Gegensatz zu CVS). Dadurch entsteht die Möglichkeit Dateien mit gleichem Namen anzulegen ohne die History der davor erstellten Datei(-en) zu erben. Zusätzlich werden Dateioperationen geloggt (wie z.B. kopieren, verschieben, umbenennen) und können so nachverfolgt werden.

Atomic Commits

Commits sind bei Subversion atomar. Entweder werden alle Veränderungen eines Commits ins Repository übernommen oder gar keine. Dieses Feature hilft Probleme zu vermeiden, die durch nicht vollständig durchgeführte Commits entstehen können.

Versioned Metadata

Jedes Objekt im Repository hat bestimmte Eigenschaften. Diese werden als Schlüssel-Wert (Tupel) abgespeichert. Man kann beliebig viele Tupel zu einem Objekt zuordnen (abspeichern).

Consistent Data Handling

Der "diff-Algorithmus" von Subversion funktioniert sowohl für Klartext-, als auch für Binärdateien. Es werden bei beiden Arten von Dateien nur die Änderungen auf dem Server gespeichert und über das Netzwerk übertragen.

Efficient Branching & Tagging

Beim Erstellen von Branches oder Tags verwendet Subversion eine den Hardlinks ähnliche Technik. Das Erstellen von Branches oder Tags benötigt dadurch nur sehr wenig Zeit.

Scope & Limitations

  • Kein automatisierter Konfliktlösungs- Algorithmus zur Versionierung

Meetings

Gemeinsame Treffen werden vom Projektleiter bzw. seinem Stellvertreter festgelegt und frühzeitig bekannt gegeben.

Datum Uhrzeit Thematik
10.11.2008 13:00 - 15:30

Links

http://subversion.tigris.org/

Mission Statement

Communication

  • eCommunity "Projekt-Repository"
  • E-Mail
  • ICQ
  • Telefon / Handy
  • SVN

Policy

  • Termine (Gruppenreffen/Abgaben) sind für alle Teammitglieder gleichermaßen bindend
  • Abwesenheit ist der Projektleitung zu melden
  • Jeder besitzt die nötigen Kontaktdaten (ICQ, E- Mail, Skype, Handy) von jedem Gruppenmitglied und ist auch selbst über diese erreichbar
  • Konstruktive Kritik an „Aufgabenverteilung & Anweisungen“ ist erwünscht, aber entgültige Entscheidungen des Projektleiters müssen respektiert und auch akzeptiert werden
  • Selbständiges Arbeiten wird vorausgesetzt
  • Aufgaben werdem immer an mindestens zwei Mitglieder vergeben
  • Bei gravierenden Problemen sollte sich das Gruppenmitglied frühzeitig an den Projektleiter bzw. seinen Stellvertreter wenden
  • Der Projektleiter sollte immer ansprechbar sein
  • Fahrlässige Verstösse gegen die hier benannten Richtlinien führen zu einer Abmahnung durch den Projektleiter


Implementierung des Dokumentenverwaltungstools

Unser Team stand nun vor der Aufgabe das Dokumentenverwaltungstool zu implementieren. Einige der Gruppenmitglieder hatten schonmal an dem selben Projekt gearbeitet. Also war unser erstes TODO zu überprüfen inwiefern wir den schon erzeugten Code für unser Projekt verwenden konnten. Wir kamen gemeinsam auf den Schluss das im vorherigen Projekt ein wichtiges Detail übersehen wurde und entschieden uns von vorne zu beginnen. Es war trotzdem sehr hilfreich schon im voraus über wichtiges Know How zu verfügen, welches mache Gruppenmitglieder aus dem äquivalentem Projekt mitbrachten.

Analyse

Unsere Aufgabe war es die Funktionalität eines SVN Servers auf eine vereinfachte Weise im Estudy Portal bereitzustellen. Funktionale Requirements: -Checkin von Datein -Browsen im Repositority

Bei unserem ersten Meeting sind wir auf ein naturgemäßes Problem gestoßen. SVN arbeitet mit sogenannten Workingcopys. Jeder SVN Nutzer hat in der Regel eine lokale Kopie des Projektes , welche geändert werden kann um sie später mit Veränderungen wieder einzuchecken. Durch Da unsere Hauptaufgabe darin besteht eine Webinterface für die SVN Funktionalität zu schaffen, ist es schwierig dafür zu sorgen das jeder Teilnehmer eine lokale Kopie des Projektes hat. Also haben wir uns dafür entschieden eine temporäre Workingcopy um die sich das Estudy Portal kümmert zu schaffen. Somit sind wir wieder in der Lage sauber Datein einzuchecken. Dadurch geht natürlich auch ein wenig von der SVN Funktionalität verloren zur Konfliktvermeidung bei gleichzeitigem verändern einer Datei von zwei verschiedenen Teilnehmern.

Daher war es uns wichtig eine Infrastruktur zu schaffen in der man in der Lage ist, auf das Estudy Webinterface zu verzichten und mit einem normalen SVN Client auf die Repostories zuzugreifen.

  • Diagramm SVN User. SVN Client, Estudy SVN Schnittstelle

Design

Als erstes haben wir uns Gedanken über den User gemacht. Was ist für einen Estudy SVN User wichtig? Nach einigen Überlegungen sind wir auf folgendes Ergebniss gekommen:

Use Case Diagramm


Unser Hauptanliegen waren folgende UseCases, da diese die Grundfunktionalität darstellen:

  • View Current State
  • Upload Files
  • Download Files


Aufgabenverteilung:

Diagramm SVN User. SVN Client, Estudy SVN Schnittstelle


Zeitaufwand pro Usecase:

Zeitaufwand

Zur Implemntierung haben wir folgendes OpenSource Projekt angepasst. WebSVN

Details

Testumgebung

Folgendes Skript ist notwendig um Zugriff auf den SVN-Server zu erhalten. 

#!/bin/sh

## This script sets the path in the PHP File and copy all scripts to the right
## location and alter then the /etc/sudoers
## Additional it creates the svnowner etc.

if [ "`whoami`" != "root" ] ; then
   echo "This Script requires root rights. If you are unsure what happens, just read trough it ;)" 
   exit 1
fi

## The Path to the scripts
## e.g. PATH_TO_SCRIPTS=/usr/local/bin
PATH_TO_SCRIPTS=/usr/local/bin

## The Server IP Address
## e.g. SERVER_ADDRESS=svnserver.mit.edu
SERVER_ADDRESS=192.168.0.20

## The svnowner data
SVN_OWNER_USERNAME=svnowner
SVN_OWNER_PASSWORD=svnpassword

## First create the php file that holds the variable
echo "<?php define(\"PATH_TO_SCRIPT\", \"$PATH_TO_SCRIPTS\"); define(\"SVN_USER    
\",\"$SVN_OWNER_USERNAME\"); ?>" > classes/VARS.php
## Then copy the scripts to the right location
cd scripts
chmod 755 *.sh
cp *.sh $PATH_TO_SCRIPTS/

## Create Server Entry in hosts because of sripts
echo "$SERVER_ADDRESS eStudySVNServer" >> /etc/hosts

## Now set the Path to the scripts in the sudoers
for script in *.sh; do
{
   echo "ALL ALL=($SVN_OWNER_USERNAME)NOPASSWD:$PATH_TO_SCRIPTS/$script" >> /etc/sudoers
}
done

## Now create the svn user
adduser --disabled-password --quiet --gecos "" $SVN_OWNER_USERNAME

## Create a key pair
echo "No generate the keys."
echo "The system askes for the Password of $SVN_OWNER_USERNAME@$SERVER_ADDRESS"
echo "Please type in the password of the user $SVN_OWNER_USERNAME on the SVN server $SERVER_ADDRESS"
sudo -u $SVN_OWNER_USERNAME ssh-keygen -q -t rsa -N "" -f /home/$SVN_OWNER_USERNAME/.ssh/id_rsa
sudo -u $SVN_OWNER_USERNAME ssh-copy-id -i ~/.ssh/id_rsa.pub $SERVER_ADDRESS

## Just perform a loggin to make sure everyting went fine
echo "Now we must login to the SVN server $SERVER_ADDRESS and call exit to make sure that the login
can perform well"
echo "Just type in the password of the $SVN_OWNER_USERNAME user on the remote machine"
echo "You also need to accept the server certificate"

sudo -u $SVN_OWNER_USERNAME ssh $SERVER_ADDRESS "exit;"

echo "All done. Hopefully everthing went well"
echo "Please make sure that you can loggin keyless on the svn server"
echo "If not maybe the ssh-copy-id command wasn't performed because of a wrong typed in password"


Erstellen des SVN Servers

1. Wir gehen von einer Debian 5.0 (Lenny) Installation aus, da Debian 4.0 beim Subversion Paket keine Unterstützung für die Authentifizierung über SASL bietet.

Ob der installierte Subversion Server mit SASL Unterstützung compiliert wurde läßt sich mit folgendem Befehl herausfinden: 

   $ svnserve --version

Wenn dann nicht folgender Satz erwähnt wird, dann bietet dieser Server keine SASL Unterstützung: 

   "Cyrus SASL authentication is available."

2. Mit aptitude folgende Pakete installieren oder sicherstellen das sie installiert sind: 

   - libsasl-modules
   - sasl2-bin
   - libsasl2-2
   - subversion
   - sudo

3. saslauthd Aktivieren. Dazu /etc/default/saslauthd mit einem Editor öffnen und die Variable START von 

   START = no

auf 

   START = yes

setzen. Des weiteren muss in der gleichen Datei die Option 

   MECHANISMS="pam"

auf 

   MECHANISMS="sasldb"

geändert werden.

Am Ende muss der saslautd Dienst neu gestartet werden: 

   $ /etc/init.d/./saslauthd restart

4. Danach in /etc einen Ordner Namens sasl2 anlegen 

   $ mkdir /etc/sasl2

5. Und in /etc/sasl2/ eine Datei Namens svn.conf anlegen. Die Datei sollte folgenden Inhalt haben: 

     pwcheck_method: auxprop
     auxprop_plugin: sasldb
     sasldb_path: /etc/sasldb/sasldb
     mech_list: DIGEST-MD5

Mit der Option "mech_list" können weitere Authentifizierungsmechanismen für SASL ausgewählt werden, DIGEST-MD5 ist nur einer davon. Weiterführende Informationen dazu gibt es in der Dokumentation zu SASL. Sowie auf folgender Webseite: 

   http://svnbook.red-bean.com/nightly/de/svn.serverconfig.svnserve.html

Wichtig: 

            Alle svn Clients vor Version 1.5 können mit SASL nicht umgehen.
            Ein update dieser alten Clients auf die Version 1.5 oder neurer ist also zwingend
            erforderlich, damit auch eine verschlüsselte Datenübertragung zum Subversionserver 
            stattfinden kann und der Login zum Subversionserver funktioniert.
            Denn der Subversionserver ist so eingestellt, dass er nur Zugriffe über SASL 
            zulässt, der normale Zugriff auf den SVN Server ohne SASL Unterstützung
            wäre zwar möglich, aber müsste erst manuell eingestellt werden und
            wäre unsicher, da die Verschlüsselung von SASL über den normalen einfachen Zugriff
            nicht genutzt werden würde. Das ist auch der Grund, warum der normale Zugriff auf den SVN
            Server ohne SASL deaktiviert ist.

6. Mit adduser einen neuen User Namens svnowner anlegen. 

   $ adduser svnowner

7. Im Home Verzeichnis von svnowner ein Verzeichnis Namens repository anlegen. 

   $ mkdir /home/svnowner/repository

8. Danach svnowner als Besitzer und Gruppe dieses Ordners mit chown festlegen: 

   $ chown svnowner.svnowner /home/svnowner/repository

9. Nun einen Symlink in /srv/ auf /home/svnowner/repository erstellen 

   $ ln -s /home/svnowner/repository/ svn

10. Einträge für sudo erstellen. Damit man die SASL Accountdatenbank und den Subversion Server mit den Rechten von svnowner starten kann, müssen entsprechende Einträge für sudo in /etc/sudoers angelegt werden: 

     svnowner  ALL=(root)NOPASSWD:/usr/sbin/saslpasswd2
     svnowner  ALL=(root)NOPASSWD:/usr/sbin/sasldblistusers2
     svnowner  ALL=(root)NOPASSWD:/usr/bin/svnserve

11. Nun den SASL Auth Server neu starten: 

   $ /etc/init.d/./saslauthd restart

12. Nun die Gruppenrechte der Datei sasldb2 so ändern, dass die Gruppe svnowner Leserechte auf die Datei sasldb erhält: 

   $ chown root.svnowner /etc/sasldb/sasldb

Falls diese Datei noch nicht existiert, dann gelingt dies durch anlegen eines SASL Benutzeraccounts. Siehe weiter unten.


13. Zum Schluss den SVN Server mit sudo als Dienst starten. Dazu in die Datei /etc/rc.local folgenden Befehl eintragen: 

      sudo -u svnowner svnserve -d -r /srv/svn

Und anschließend rc.local ausführen: 

   /etc/./rc.local


Optional zum Testen

14. Erstellen eines Test Repositories:

Als svnowner einloggen und ein Repository zum Testen erstellen. Im Beispiel trägt es den Namen "projekt1": 

   $ svnadmin create /srv/svn/projekt1

Wenn das Test Repository erstellt wurde, muss noch die Datei svnserve.conf im conf Verzeichnis des Projektes konfiguriert werden. 

   $ nano /srv/svn/projekt1/conf/svnserve.conf

In dieser Datei muss nun sichergestellt werden, dass die Option "use-sasl" auf "true" gesetzt ist und diese Option auskommentiert ist, d.h. das # Zeichen davor entfernt wird. Aus 

   # use-sasl = true

wird also 

   use-sasl = true

Wichtig ist bei der svnserv.conf Konfigurationsdatei, dass vor allen auskommentierten Optionen kein Leerzeichen steht!

Des weiteren muss die min-encryption auf mindestens 128 gesetzt werden 

   min-encryption = 128

und hier ebenfalls, sowie für max-encryption, das Kommentarzeichen # entfernt werden. 

   max-encryption = 256

Dann müssen noch die Kommentarzeichen # vor 

   # anon-access = read

und 

   # auth-access = write

entfernt werden, so dass am Ende folgendes dran steht: 

   anon-access = read
   auth-access = write

Auch sollte die Option anon-access von 

   anon-access = read

auf 

   anon-access = none

umgestellt werden, weil sonst jeder lesend auf das Repository zugreifen kann.


Zum Schluss geben wir der "realm" Option noch einen Namen. Zu beachten ist hierbei, dass dieser Name keine Leerzeichen enthalten darf. Dieser Name wird später nämlich von SASL verwendet werden. Wichtig ist dabei auch, dass dieser "realm" Eintrag mit dem realm Namen des SASL Account identisch ist. Zum SASL Account später mehr siehe Punkt 15.

In unserem Beispiel geben wir dem projekt1 den "realm"-Namen "projekt1" D.h. aus: 

   # realm = My First Repository

wird: 

   realm = projekt1

Das Kommentarzeichen # vor realm muss ebenfalls wieder entfernt werden.

15. Erstellen eines SASL Accounts zum Testen:

Der Befehl zum SASL Account lautet 

     saslpasswd2 -c -f /etc/sasldb/sasldb -u realm username

Wobei wir hier den Parameter "realm" mit dem realm Namen versehen, welchen wir auch in der svnserve.conf Datei verwendet haben. Im Fall für unser Test Repository also "projekt1"

Und für den Parameter username wird zum Schluss dann noch ein entsprechend passender Name für den Benutzer gewählt, der Zugriff auf das Repository haben soll. Z.B. oscar.

Der Befehl lautet also: 

   $ sudo saslpasswd2 -c -f /etc/sasldb/sasldb -u projekt1 oscar

Die Einträge in der SASL-Datenbank kann man mit folgendem Befehl anzeigen: 

   $ sudo sasldblistusers2 /etc/sasldb/sasldb

Geänderte/Neuerstellte Datein

Orginal WebSvn Verzeichniss(Anspassung von Web SVN siehe oben)

Shell Skripte

SubVersion

Abschluss Stand

In diesem Abschnitt stellen wir die Abschließenden Stand unseres Projektes vor. Sowie eine kurze Anregung für Leute die an diesem Projekt weiter arbeiten wollen.


Das Projektarchiv Modul

Projektarchiv Modul

Hier sehen wir den Startbildschirm von unserem Modul. In Kursen in denen das Modul aktiviert ist taucht in der Menüleiste ein Link auf, der den Namen Projekt Archiv trägt. Wie wir später sehen werden ermöglicht unsere Bedienfreundlichkeit auch nicht professionellen PC Anwendern das verwenden von SVN funktionalität.


Weitere Funktionen

Projektarchiv Modul

Hier können wir die angebotenen Funktionen sehen. Das Bild sollte soweit selbst erklärend sein. Wir bieten hier

  • Kennung Anlegen
  • Archiv
  • Login Updaten
  • Hilfe


Hilfe Seite

Projektarchiv Modul Hilfe

Auf der Hilfe Seite unseren Projektes findet man folgende Buttons:

  • Login Aktualisieren

Falls man seine external Tools Kennung ändert kann man das hier aktualisieren.

  • Wiki Artikel

Ihr seit bereits hier ;)
Die beiden letze Punkte * Subversion Tigris und * Online Handbuch sind für Leute die gerne mehr über SVN erfahren wollen, um z.B. einen nativen Client zu benutzen


Projektarchiv Upload und Browsen

Upload Browsen

Auf diesem Bild sehen wir ein leeres Projekt(deswegen auch Revision -1). Auf der rechten Seite des Bildes sehen wir den SVN Browser, dieser ermöglicht eine angenehme Art und Weise in den Projekt Datein zu serven. Um neue Datein oder geänderte Datein hochzuladen kann man einfach direkt den Durchsuchen Button drücken und nach der Auswahl auf Upload. Man sollte zu jeder Änderung oder Neuerstellung von Datein einen Kommentar abgeben, damit es den Teammitgliedern leichter fällt die Änderungen nachzuvollziehen. Dies kann man direkt über dem upload button tun. Ausserdem bieten wir noch die Möglichkeit Verzeichnisse zur Strukturierung des Projektes über die Webschnittstelle anzulegen.

Schließlich ist noch zu erwähnen das wir unser Ziel den SVN Server auch über einen gewöhnlichen SVN Client ansprechen zu können einhalten konnten. Damit ist gemeint das jedes Mitglied sofern es möchte auch direkt mit einem SVN Client auf den SVN Server das Projekt verwalten können.

Weiterführende Arbeit am "Projekt Archiv" Modul

Durch das Webinterface bedingt kann es noch zu Konfliktproblemen kommen. D.h. falls zwei Leute an der selben Datei arbeiten der eine die Datei hochläd und der andere kurze Zeit später werden die Änderung von der ersten Person gelöscht. Wir warnen aber explizit davor das die Datei überschrieben wird. Hier wäre es wünschenswert einen Compare(Vergleich) der Datein anzubieten die Änderungen dann zu mergen(zusammenzuführen) und erst dann hochzuladen. Diese Funktionalität ist den meisten Software Entwicklern aus z.B. SVN Projekten in der Eclipse bekannt. Eine Ajax Oberfläche würde hier sehr zur Bedienbarkeit beitragen.

Prozess Analyse

Einführung

Das Projekt als solches ist, was den Praktischen Teil betrifft, gut vorrangekommen. Leider ist durch mangelde Teamarbeit die Dokumentation teilweiße auf der Strecke geblieben. Von den 7 veranschlagten Personen, haben sich leider nur 3-4 Aktiv mit dem Projekt befasst. Aufgrund des hohen Implementierungs- Aufwandes, ist der Wiki Artikel und sonstige nicht technischen Dinge etwas auf der Strecke geblieben. Zum Ende des Projektes wurden jedoch alle Anforderungen erfüllt und die Einbindung ins eStudy vollbracht.

Positive Erfahrungen

  • Positives Betriebsklima
 Unter denjenigen die aktiv an dem Projekt gearbeitet haben herrschte stehts ein gutes Klima. Sie haben sich gut verstanden und kooperativ gearbeitet.
  • Peer Programming
 Hat sich als sehr nützlich herausgestellt, da fehler schnell gefunden wurden, die Qualität des Codes verbessert und effektiver gearbeitet wurde.
  • Gute Arbeit einzelner Teammitglieder
 Einzelne Teammitglieder haben stehts gute Arbeit abgeliefert und diese auch sehr gut dokumentiert.

Negative Erfahrungen

  • Schlechte Kommunikation mit dem Team
 Aufgrund der unterschiedlichen Herrkunft (Diplom, Master) und der versetzten Stundenpläne, war ein regelmäßiges Treffen inklusive
 regelmäßiger Kommunikation erschwert. Trotz dieses großen Handycaps ist das Ergebnis sehr gut.
  • Wenig Präsenz Treffen
  • Zeitkollisionen

Beschreibung

Projekt Planung

Die Projekt Planung war Anfangs sehr gut und sehr strukturiert. Das Team sollte sich nach dem XP-Softwareentwicklungs Modell formatieren. Leider haben die Einwände der Kursleitung die Struktur etwas durcheinander gebracht. Durch die steige Belastung durch Mehrarbeit (Css-Style, Planspiel, XPWeb uvm.) war ein eigenständiges Arbeiten nur bedingt möglich. Es wurden wöchentliche Meetings angesetzt. Später wurden dann Aufgaben fair auf alle Mitglieder anhand eines Aufwand Modells vergeben.

Zusammenarbeit innerhalb des Projektteams

Schon von Anfang an wurden alle Erwartungen festgehalten. Höchste Priotiät hatte das fertigstellen des Projektes eStudy SVN. Zuerst wurden fachliche Fertigkeiten wurden analysiert und Aufgabengebiete zugewiesen. Die Kompetenzen waren sehr gut verteilt, sodass in dem Team ein guter Ausgleich bestand. Als Vereinbarung, bezüglich der Verhaltensregeln und Pflichten, wurde, eine Team Policy aufgesetzt, die man auch hier im Wiki findet. Teammeetings fanden einmal wöchentlich statt und wurden Anfangs auch wahrgenommen. Später flachten diese Aufgrund der Präsenzzeiten einiger Teammitglieder ab. Während eines Meetings gab es einen Protkollanten und der Teamleiter hat das Meeting moderiert. Der Wissensaustausch hat bis auf Einzelfälle gut funktioniert und am Ende eines Meetings wusste jeder, was er zu tun hat. Die Motivation war an sich sehr gut und die Arbeitsbereitschaft sehr hoch. Projektaufgaben wurden anhand von Kompetenzen verteilt und wurde so auch Akzeptiert. Im Nachhinein war die Zusammenarbeit auf das ganz Team betrachtet sehr schlecht. Später hat sich dann eine Teilmenge von drei Personen herauskristallisiert; Dessen Zusammenarbeit war sehr gut und überaus produktiv.

Zusammenarbeit mit der Kursleitung

War praktisch nicht vorhanden. Es gab keine Treffen, bis auf zwei. In diesem Meetings ist aber leider keine Produktive Lösung rausgekommen.

Bewertung

Das Team bestand aus kompetenten Mitarbeitern. Anfangs war eine gute Motivation zu verzeichnen. Leider haben dann die Aufgaben der Kursleitung ein selbstständiges Arbeiten behindert. (Vorallem die Chorgeographie) Das Team wollte sich nach dem XP Modell formieren, welches dann durch die Ständige Einstreuung von Planspiel etc.unmöglich wurde. Später dann in der eigentlichen Implementierungsphase des SVN Projektes, kam dieses Modell (XP) relativ gut zum Tragen. Positiv war, das die Arbeitsbereitschaft sehr hoch war. Anfangs stellte sich auch heraus, das kleine Aufgaben zu verteilen und durch komplexe Kommunikation bewältigen zu lassen, in keiner Relation standen zum eigentlichen Aufwand der Aufgabe. Soll heißen wenn einer Aufgabe von Aufwand so gering ist, steht der daraus resultierende Overheat, 4 Teammitglieder daran arbeiten zu lassen, in keiner Relation zu den Tatsächlichen Aufwand, der zur Lösung der Aufgabe führen würde. Positiv aus dem Projekt, ist, dass im Endeffekt das Projekt durchgeführt werden konnte, durch starke Einzelleistung und gute mikrogruppen Arbeit. Negativ aus dem Projekt, ist, dass einige Teammitglieder die zugewießenen Aufgaben einfach nicht durchführten, oder schlicht nicht erreichbar waren.

Analyse

Die Probleme lagen vorrallem in der Herkunft der Teammitglieder. Relativ betrachtet zu den anderen Gruppen war das ein Handycap. Um diese genauer zu beschreiben hier die Erläuterung: Die meisten der jetzigen Master Studenten, sind noch die ersten Bachelor Studenten. Sie kennen sich seit dem 1. Semester und haben jetzt auch den selben Studenplan und daraus resultiert auch eine hohe Präsenzzeit. Unser Team bestand aus bunt gewürfelten Teammitgliedern, welche teilweiße sehr unterschiedliche Stundenpläne, Präsenszeiten und Motivationen hatten. Im Diplom ist dieser Schein wahlpflicht und Studienleistung, daher wurde er von einigen nicht ernst genommen. Manche standen vor den Diplom und nahmen die Sache sehr ernst. Dort hat die zusammenarbeit dann auch sehr gut funktioniert. Eigenständigesarbeiten wurde durch die Unklarheit über die Rolle der Kursleitung behindert. Konkret stand am Anfang die Frage im Raum, ob wir uns selbst organisieren und das Projekt nach dem XP Modell durchführen, oder den Anweisungen der Kursleitung folgen. Die führte zur Verwirrung und machte eine strukturierte Vorgehensweise sehr schwer.

Synthese

Nächstes Projekt härter an einzelne Team Mitglieder ran und die Motivation sehr früh analysieren um evtl. schläfer auszuschließen. Bei Organisation komplett die Kursleitung außen vor zu lassen (nur die Requirements sammeln).


Die „Start-Stop-Wieder-tun“-Liste

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

  • Enger mit dem Kunden zusammenzuarbeiten
  • Frühzeitig technische Probleme anzusprechen
  • Frühzeitig interne Probleme zu beseitigen

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

  • Fehlen bei den Treffen zu tolerieren
  • Interne Terminabsprachen nicht einzuhalten

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

  • Regelmäßige Treffen
  • Aufgaben in 2er Teams zusammenzufassen
  • Sich untereinander jederzeit zu unterstützen

Hausübungen der Teammitglieder

Abgerufen von „https://wiki.thm.de/w/index.php?title=MSP:Projekt-Repository&oldid=7393“