Markus studiert!

Leuchttisch Entwicklertagebuch 03

Willkommen zur dritten Ausgabe des Leuchttisch-Entwicklertagebuchs, in der ich die Ereignisse in der Zeit von Montag, den 4. bis Sonntag, den 10. April 2011 beleuchten werde.

GUI-Prototypen

In dieser Woche haben die Frontendentwickler die Ergebnisse ihrer GUI-Prototyp-Entwicklung vorgestellt. Beide Gruppen haben nach knapp zwei Wochen beachtliche Ergebnisse vorzuweisen — mit der Erkenntnis, dass C# und WPF so komfortabel grafisch aufwändige GUIs ermöglichen, dass wir in der finalen Version eine grafisch ansprechende Umsetzung anstreben, die sich nicht durch ein Standardbaukasten an Frames und starren Unterteilungen einschränken lassen wird. Angestrebt ist die Möglichkeit, alle Unterfenster der Anwendung — Panels genannt — frei bewegen, skalieren und ein- und ausblenden zu können.

Explorer Prototyp: Fullscreen Modus

Zum Start der Entwicklung der GUI, nach der Fertigstellung des Designdokuments, wird das GUI-Team, beide Prototypen zusammenführen um die besten Elemente beider zu kombinieren.

Domänenmodell und Pflichtenheft

Nach zwei Wochen Einarbeitung in die neuen Werkzeuge — die auch das Backend-Team genutzt hat, um sich mit Fragen rund um die Schnittstellen zum Server zu beschäftigen, sind wir nun in der Einschätzung der Aufgabe sicher genug, um uns an die Finalisierung des Entwurfs zu machen.

Das Backend-Team entwickelt neben dem Domänenmodell auch bereits das Konzept für die Schnittstellen — das alles natürlich im Austausch mit dem Frontend-Team, dass sich um die schriftliche Niederlegung der bereits im Feature-Brainstorming erarbeiteten Anwendungsfälle kümmert.

Alle diese Arbeiten bilden die Grundlage für das Pflichtenheft, dass ebenfalls bereits in der Entstehung ist und nächste Woche abgegeben wird.

Work packages

Ein alter bekannter aus dem letzten Semester ist auch wieder mit dabei: die Ampel. Sie kommt seit ein paar Tagen auf einer Seite im Wiki zum Einsatz, in der die Tickets in work packages gruppiert werden.

Diese Einteilung soll den Projektverlauf einfacher dokumentieren und bildet die Basis für meinen wöchentlichen Projektleiter-Bericht.

Für Entwickler sind work packages ein gutes Mittel, um schnell einen Überblick über aktuell anstehende Aufgaben zu bekommen und sie gruppieren die vielen Tickets eines Meilensteins in mehrere kleinere, übersichtlichere Einheiten.

Workpackages sind kein Feature von Trac sondern kombinieren nur geschickt verschieden Funktionen, die bereits zur Verfügung stehen. Aus meiner Dokumentation zu diesem Feature lässt sich die Funktion der Seite am besten erklären:

WorkPackages unterteilen das Projekt in kleinere Aufgaben-Pakete, ähnlich den Meilensteinen, nur dass WorkPackages thematisch zusammengehörige Tickets gruppieren.

Diese Seite wir automatisch aus den Tickets vom Typ workpackage zusammen gestellt, und berücksichtigt dabei die Angaben @start und @end in der Ticket-Beschreibung, sowie den Owner und die Einträge im Feld CC, wobei die Usernamen dort mit der Liste der Entwickler abgeglichen wird.

Der Status des Tickets bestimmt die Einordnung in Aktive WorkPackages (accepted, assigned, reopened), ausstehende WorkPackages (new) und erledigte Workpackages (closed).

Die Ampel des WorkPackages wird durch den Tag @status bestimmt, der standardmäßig auf grün steht. Mögliche weitere Werte sind rot und gelb.

Der Owner eines Workpackages ist für dessen Umsetzung verantwortlich, die Personen im Feld CC sind ebenfalls mit der Umsetzung beauftragt.

Tickets ordnet man einem Workpackage zu, in dem man in den Keywords des Tickets das Keyword des Workpackages einträgt, z.B. workpackage-115.

Die Kommentare, die in einem WorkPackage-Ticket hinterlassen werden, sind das Protokoll über den Verlauf des WorkPackages.

Auszug aus der Wiki-Seite WorkPackages

Probleme

Inzwischen sind die Anlaufschwierigkeiten bei Pflegen der Entwickler-Blogs behoben und auch die Zeiterfassung hat sich eingespielt. Das Team arbeitet motiviert und vor allem engagiert.

Die nächsten Schritte

In dieser Woche steht das Pflichtenheft (Abgabe nächsten Montag) und das Designdokument im Mittelpunkt der Arbeiten.

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: 342h (18%)

Entwicklung: 185h (54%)
Kommunikation: 157h (46%)

Erfasste Zeit nach Person