Markus studiert!

Leuchttisch Entwicklertagebuch 01

Willkommen zur ersten Ausgabe des Leuchttisch-Entwicklertagebuchs!

Das Projekt

Leuchttisch — so haben wir unser Projekt getauft — ist ein kollaborative Software zum Erstellen von Fotosammlungen und wird als Teil der Veranstaltung Softwaretechnik im 4. Semester des Studienganges Medieninformatik an der Hochschule RheinMain durch die Studenten entwickelt.

Die Rahmenbedingungen sind dabei vorgegeben: In 14 Wochen entsteht in Teams zu je etwa 10-12 Personen ein Standalone-Client auf Basis von WPF (C#), sowie auf Server, der in Java geschrieben wird. Client und Server dürfen nur über Schnittstelle miteinander kommunizieren und haben ansonsten keine gemeinsame Datenbasis.

Der Funktionsumfang ist ebenfalls abgesteckt: Zu erstellen ist ein interaktives System für eine verteilte Foto-Agentur mit Echtzeit-Interaktions-/Kollaborationsmöglichkeiten, mit dem Agentur-Mitarbeiter den Bildbestand sichten, taggen, durchsuchen, kategorisieren, beschreiben können und in Echtzeit Bildermappe mit Vorschlägen für einen Kunden vorbereiten und diskutieren können.

Natürlich soll sich auch der Kunde in die Diskussion mit einschalten können, und Fotografen laden ihre Fotos hoch.

Die Wochenberichte

Neben dem rein technischen Aspekt liegt auch ein großer Augenmerk auf der systematischen und organisierten Arbeit — meine Aufgabe als Projektleiter ist weniger das Programmieren sondern vielmehr das Organisieren und Planen. Ein Teil dieser Aufgabe sind auch wöchentliche Reportings an den Veranstaltungsleiter, deren Basis diese Wochenberichte bilden.

Die erste Woche: Projektstart

Nachdem am Donnerstag, den 17. März das Thema des Projekts vorgestellt wurde, hatten sich auch recht zügig unser Projekt-Team gefunden. Als erste Maßnahme musste die Projekt-Infrastruktur aufgesetzt werden, die Werkzeuge, die wir bis jetzt verwenden sind im Einzelnen:

Twitter

Im Team leider etwas unterrepräsentiert, für mich aber sehr hilfreich: ein eigener Twitter-Account für das Projekt: @swt2011

Dort fließen dann mit Hilfe von @twitterfeed die RSS-Feeds der Trac-Timeline hinein. So hat man immer schnelle, kompakte Infos darüber, was im Projekt geschieht.

Facebook

Im Gegensatz zu Twitter hat jeder im Team einen Account bei diesem Sozialen Netzwerk, hier ist also eine eigene, geschlossene Gruppe das Mittel der Wahl für schnelle Abstimmungen.

Google Docs

Die Office Suite von Google hat einen entscheidenden Vorteil: Alle Dokumente lassen sich gleichzeitig mit vielen bearbeiten — besonders in Meetings ist das extrem wertvoll, da so gemeinsam ein Protokoll entsteht, und jeder Ergänzungen und Korrekturen vornehmen kann.

Hierfür benötigt man ebenfalls ein eigenes Google-Konto, dieser "Aufwand" ist aber angesichts des Mehrwerts absolut sinnvoll.

Auch beim Erarbeiten von umfangreichen Dokumenten ist das Arbeiten in der Cloud unschlagbar — niemand überschreibt jetzt einen Stand und alle arbeiten stets mit der neuesten Version.

Als Workflow hat sich etabliert, Dokumente in Google Docs an zu legen, bis diese einen finalen Stand erreicht hat. Dieser wird dann zur Archivierung ins Trac Wiki übertragen.

Google Calendar

Alle Termine des Projekts werden in eine zentralen Google Calendar verwaltet. Dieser biete iCal-Exporte, so dass er auch in externen Kalender-Anwendungen importiert werden kann.

mite

Zeiterfassung ist ein wichtiger Bestandteil der Projektplanung und -kontrolle, daher setzen wir zur sekundengenauen Zeiterfassung auf mite.

Dropbox

Für die Fälle, in denen man Dateien mal eben schnell austauschen möchte, ist die Dropbox die erste Wahl — denn nicht alle Dateien müssen zwangsläufig mit einer SVN-Revision verewigt werden.

Doodle

Als unerlässliches Hilfsmittel bei der Entscheidungs- und Terminfindung hat sich Doodle bewährt — das intuitive Interface geht bei Abstimmungen einfach viel besser von der Hand, als in Trac Kommentare zu zählen. Die Funktionen zur Terminfindung sind gerade mit der Integration von Google Calendar grandios.

Trac

Neben Subversion war Trac als Mittel zur Organisation und Dokumentation der Entwicklung vorgegebenen — und wäre auch meine erste Wahl gewesen.

Hier habe ich das Wiki soweit wie möglich mit allen zum jetzigen Zeitpunkt bekannten Informationen befüllt, und Vorlagen für das Entwickler-Blog angelegt, die von jedem Projektmitarbeiter wöchentlich zu führen sind.

Subversion (+Git)

Mit Subversion als Versionsverwaltungssystem verbinden die meisten im Studiengang inzwischen eine Hassliebe — als Unterstützung nehmen wir je nach Geschmack noch GIT-SVN dazu.

Das erste Meeting

Im ersten Meeting ging es dann erst mal um banale Dinge. Im Vordergrund stand nebem dem Projektnamen — über den dann später in Doodle abgestimmt wurde — ging es mir vor allem um die Vorstellung der eben aufgezählten Werkzeuge und ihren jeweiligen Platz im Projektverlauf.

Ein wichtiger Punkt war die grundsätzliche Ausrichtung des Desktop-Clients: Wollen wir lieber den klassischen Fenster-Aufbau mit Menüleiste & Co oder bevorzugen wir einen eher haptischen Ansatz?

Da wir auch noch nicht besonders mit den Fähigkeiten von WPF vertraut sind, haben wir beschlossen, zwei Teams zu bilden, die jeweils einen sehr einfachen Prototyp entwickeln um ein Gefühl für die neue Umgebung zu bekommen, einmal in einer klassischen "Explorer"-Version und einmal in der "Advanced"-Variante.

Das zweite Meeting

Ein wichtiger Punkt dieses Meetings war neben der Festlegung der Teams für die Prototypen auch eine erste Planung der Termine für die vorgegebenen Meilensteine des Projekts zu erarbeiten.

Zwei feste Meeting-Termine pro Woche

Wir haben uns in der vergangenen Woche auf zwei fester Termine pro Woche geeinigt: Dienstags und Donnerstags. Diese etwa einstündigen Termine sind für alle Projektteilnehmer verpflichten und dienen dazu, regelmäßig den aktuellen Stand aus zu tauschen.

Projektfahrplan

Nach dem zweiten Meeting haben wir schon einen ungefähren Ablaufplan für das Projekt:

Projektdauer ab heute: ca. 14 Wochen

• Abgabe der Anforderungsspezifikation nach etwa 4 Wochen
• Abgabe der System-Architektur nach etwa 5 Wochen
• 1. Zwischendemo (Demonstriert elementare "round trips") nach etwa 6 Wochen
• 2. Zwischendemo (Kernanforderungen sind umgesetz) nach etwa 10 Wochen
• Release nach etwa 14 Wochen

Entsprechend den Aufwänden in Credit Points für das Fach Softwaretechnik errechnet sich ein geplanter Aufwand für die Umsetzung des Projekts wie folgt:

7 Creditpoints	· 30h	= 210
- 1,5h Vorlesung	· 13 Wochen	= -19,5h
- 3h Praktikum	· 4 Wochen	= -12h
		= 178,5h

Bei 11 Mitarbeitern stehen also für das Projekt theoretisch 1963h = 245 Manntage zur Verfügung, wobei sich eine wöchentliche Belastung von ca. 13 Stunden pro Person (zzgl. Vorlesung und Praktikum ergibt).

Das dritte Meeting: Feature-Brainstorming

In diesem gut zweistündigen Meeting haben wir uns intensiv mit dem Funktionsumfang der Anwendung beschäftigt und eine gut 40 Punkte umfassende Liste mit groben Feature-Beschreibungen erarbeitet und diese den verschiedenen Benutzerrollen zugeschrieben. In teils ausgiebiger Diskussion wurde Sinn und Unsinn von allen Vorschlägen abgewogen und letztendlich per Abstimmung festgelegt, welche Features dem Rotstift zum Opfer fallen.

Hier ist das Ergebnis des Brainstormings in voller Pracht.

Logo

Mittlerweile hat das Projekt auch ein Logo bekommen, damit es nicht so ganz nackt da steht.

Das Projekt in Zahlen

Zu guter Letzt noch einen Abzug der Zahlen aus mite für die vergangene Woche und den gesamten Projektverlauf (Endstand: Sonntag, 24 Uhr).

Projektbudget: 1.881h
Davon verbraucht: 78,5h (4%)

Entwicklung: 42h (53%)
Kommunikation: 37h (47%)

Erfasste Zeit nach Person