MSP:Projekt-Repository
Inhaltsverzeichnis
Team
- ****, Sebastian (Projektleiter)
- ****, Stefan (stellv. Projektleiter)
- ****, Paul Christoph
- ****, Oliver
- ****, Sebastian
- ****, Aydin
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
Mission Statement
Communication
- eCommunity "Projekt-Repository"
- 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.
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:
Unser Hauptanliegen waren folgende UseCases, da diese die Grundfunktionalität darstellen:
- View Current State
- Upload Files
- Download Files
Aufgabenverteilung:
Zeitaufwand pro Usecase:
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
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/websvn/classes/class.fileupload.inc.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/websvn/listing.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/websvn/fileupload.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/privatesvn/Privatesvn.mkf
Orginal WebSvn Verzeichniss(Anspassung von Web SVN siehe oben)
Shell Skripte
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/addUserToCourse.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/createUniqueDir.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/deleteRepository.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/deleteUserFromCourse.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/newRepository.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/svnAdd.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/svnCheckin.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/svnCheckout.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/scripts/svnCheckOutAddCheckIn.sh
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/createSystemPreconditions.sh
SubVersion
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/classes/class.functions.inc.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/classes/class.subversionautomation.inc.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/classes/VARS.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/auto.inc.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/sub_archiv.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/sub_help.php
- https://trac.mni.fh-giessen.de/eStudy/browser/branches/msp/web/subversion/Subversion.mkf
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
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
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
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
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