Redmine

Eric Davis - langjähriger Committer der Projekt-Management Software Redmine - hat heute ChiliProject als Fork von Redmine angekündigt. Als einen der Hauptgründe für den Fork stellt er die mangelnde Transparents des Redmine Projekts sowie die für ihn ungenügende Übernahme von Beiträgen der Redmine Community in das Projek in den Vordergrund.

Auf dem letzten Treffen der JUG Metropolregion Nürnberg habe ich einen kurzen Vortrag über das Projektmanagement-System Redmine gehalten. Ziel des Vortrags war es, den anwesenden Entwicklern und Projektleitern einen kurzen Überblick über die Möglichkeiten von Redmine zu geben.

Bereits seit mehreren Jahren arbeite ich mit Linux. Auf dem Server ist dieses Betriebssystem für mich die erste Wahl. Alle von mir benötigten Dienste stellt mit derzeit ein Server unter Debian 5.04 zur Verfügung. Meine letzten Erfahrungen mit Linux auf dem Desktop sind allerdings fast 2 Jahre alt. So ist es wieder einmal an der Zeit den aktuellen Stand von Linux auf meinem Arbeitsplatz unter die Lupe zu nehmen.

In anderen Beiträgen habe ich das Projekt-Managementsystem Redmine bereits kurz vorgestellt und auf die Möglichkeit zur Integration von Redmine in eclipse mittels des Redmine-Mylyn Connectors hingewiesen. Jetzt ist es an der Zeit die praktische Arbeit mit dem System zu beschreiben.

Wer jetzt eine umfangreiche Einführung in Redmine erwartet, wird enttäuscht werden. Für eine grundlegende Einführung in die Nutzung von Redmine möchte ich auf den Remine guide verweisen. Eine gute Einführung gibt auch das Kapitel 6 des Buches „Konfigurationsmanagement mit Subversion, Maven und Redmine“ von Gunther Popp.

Ich werde im Folgenden Hinweise auf die Nutzung von Redmine aus meiner eigenen Praxis geben. Daher wird dieser Artikel in Zukunft auch laufend ergänzt und aktualisiert werden.

Mit dem Projekt-Management System Redmine lassen sich die bei der Entwicklung einer Software anfallenden Arbeiten sehr gut koordinieren. Die Möglichkeiten reichen von der Verwaltung von offenen Punkten / Tickets, über eine Release-Planung bis zur Speicherung von Texten (WIKI) und Dokumenten / Dateien zum Projekt.

Das Plugin Mylyn stellt in eclipse ein System zur Verfügung, mit dem sich Entwickler Aufgaben zusammenstellen und diese „aufgabefokusiert“ abarbeiten können. Hierzu werden jeder Aufgabe einzelne Entwicklungsdokumente (Klassen, Dokumente, etc.) zugeordnet. In einer speziellen Sicht werden dann nur die für die Abarbeitung der Aufgabe benötigten Dokumente angezeigt.

Der Einsatz einer Quellcode-Verwaltung (cvs, Subversion, etc.) ist für uns bereits seit Jahren selbstverständlich. Änderungen können über mehrere Versionen hinweg nachvollzogen und bei Bedarf wieder rückgängig gemacht werden. Nicht mehr benötigter Code wird nicht auskommentiert sondern wirklich gelöscht. In der Quellcode-Verwaltung ist der "alte" Code ja immer noch vorhanden.

Wie aber verwaltet man die ToDos, die während der Entwicklung einer Software für jeden Entwickler entstehen? Notizzettel? Text-Datei? Wiki? Alles Lösungen, die wir genutzt haben, von denen aber keine wirklich gut funktioniert hat. Mit den ersten Testversionen kommen noch Bug-Reports von den Testern hinzu. Und dann gibt es weitere Informationen, die jedem Entwickler schell zur Verfügung stehen sollten: fachliche und technische Richtlinien, Spezifikationen, Besprechungs-Protokolle, HowTos, etc.