Redmine in der Praxis

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 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.

Tickets

Das Ticket ist das zentrale Element in Redmine. Ein Ticket wird zum einen dazu verwendet, Teilaufgaben bei der Entwicklung einer Software zu definieren und diese Aufgaben den einzelnen Software-Entwicklern zuzuweisen. Zum anderen dienen Tickets aber auch zur Erfassung und Bearbeitung von Fehlern im System, die von den Entwicklern selbst oder Testern festgestellt worden sind.

Tracker

Jedem Ticket wird ein Typ (= Tracker) zugewiesen. Über den Tracker wird festgelegt, ob es sich bei dem Ticket um ein zu entwickelndes Feature oder einen zu behebenden Fehler handelt. Neben diesen beiden Typen ist in der Standardkonfiguration von Redmine auch noch der Tracker Support hinterlegt. Mit ihm können Aufgaben definiert werden, die direkt an einem installierten System durchgeführt werden müssen. Die drei vorgegebenen Tracker (Error, Feature und Support) können um beliebig viele weitere Tracker erweitert werden. Die Tracker werden global – unabhängig vom Projekt – festgelegt.

Ich verwende Redmine in einem Projekt von Anfang an. Für jede Teilaufgabe lege ich ein Ticket vom Typ Feature an. Alle Notizen und Bemerkungen, die bei der Abarbeitung anfallen, werden in den Notizen (Beschreibung) des Tickets oder durch zusätzliche Kommentare festgehalten. Somit habe ich keine fliegenden Zettel und finde die Information sofort bei der entsprechenden Aufgabe wieder.

Je nach Projekt verwende ich auch gerne einen selbst angelegten Tracker User-Story. Dadurch nutze ich Redmine bereits bei der Analyse. Die einzelnen User-Stories werden zentral erfasst und können jederzeit neu sortiert oder bearbeitet / erweitert werden. Durch die Verwendung von entsprechenden Kategorien behält man auch bei einer sehr umfangreichen Liste an Stories den Überblick.

Der für den Tracker User-Story hinterlegte Workflow entspricht dabei exakt dem Workflow für den Tracker Feature.

Status

Der Tracker beschreibt den Typ / Zweck des Tickets. Durch den Status wird festgelegt, was gerade mit dem Ticket passiert.

Die Status Neu, Zugewiesen und Erledigt sprechen für sich. Neu eingetragenen Tickets erhalten erst einmal den Status Neu. Übernimmt ein Entwickler die Bearbeitung des Tickets wechselt der Status nach Zugewiesen und verbleibt dort bis zur endgültigen Erledigung. Ist das Ticket abgeschlossen, wechselt der Status nach Erledigt.

Den Status Feedback verwende ich um zu kennzeichnen, dass das Ticket derzeit nicht von einem Entwickler bearbeitet werden kann. Es wird auf Feedback aus der Fachabteilung, von einem Anwender oder einer anderen “externen” Person gewartet. In den Zustand Feedback kann nur aus dem Zustand Zugewiesen gewechselt werden. Weiterhin wird wechselt der Status des Tickets von Feedback entweder nach Zugewiesen oder Erledigt.

Um deutlich zu machen, dass die Abarbeitung eines Tickets gerade beim Testen ist, kann man noch einen Status Test einfügen. Dann ist allerdings darauf zu achten, den Workflow für die Tracker Feature und Error entsprechend anzupassen.

Kategorien

Schlüsselt man die einzelnen Aufgaben in einem Projekt sehr stark auf, entsteht schnell eine große Liste an Tickets. Um hier den Überblick zu halten ist es sinnvoll, die Tickets in eine Kategorie zuzuordnen. Die Kategorien werden für jedes Projekt neu festgelegt. Somit lege ich die Kategorien sehr speziell für jedes Projekt fest.

In der Praxis bewährt hat sich für mich die Aufteilung der einzelnen Tickets auf die einzelnen Komponenten. Beim Einsatz von User-Stories lege ich auch gerne Kategorien für die einzelnen Entities / Domänen Objekte an.

Durch den Einsatz von Filtern in der Ticket-Ansicht kann man nun sehr einfach einzelnen Listen für jede Kategorie anlegen. Setzt man bei der Definition eines Filters die Option Öffentlich, müssen auch nicht alle Projektbeteiligten die Filter selbst definieren.

Projektarchiv

Die Einbindung des Quellcode-Repositories in Redmine ist eine feine Sache. Es ist aber nicht nur die Möglichkeit aus Redmine heraus auf die einzelnen Revision zuzugreifen, die aktuellen Stände der Quellen anzuzeigen und sich die Unterschiede ausgeben zu lassen die Redmine als Funktion zur Verfügung stellt. Redmine bietet die Möglichkeit Changesets / Revisionen Tickets zuzuordnen.

Dadurch erhält man zum einen eine Dokumentation, welche Änderungen am Quellcode zur Bearbeitung eines Tickets durchgeführt wurden. Zum anderen spart sich der Entwickler aber auch die “doppelte” Eingabe von Kommentaren. Es reicht aus beim Check-In zu beschreiben, welche Änderungen durchgeführt wurden und evtl. warum diese durchgeführt worden sind und den Kommentar mit Schlüsselworten und der Ticket-Id zu versehen. Redmine ordnet anschließend den Check-In Kommentar dem Ticket zu. Je nach Schlüsselwort findet nur eine Zuordnung des Changesets statt oder es wird zusätzlich das Ticket auf erledigt gesetzt.

Die Schlüsselworte werden für alle Projekte global in der Redmine-Konfiguration festgelegt. Es gibt Schlüsselwörter für Beziehungen (z.B. refs, references, IssueID) und Statusänderungen (z.B. fixes, closes). Die Ticket-Id wird hinter dem Schlüsselwort mit einem # Zeichen angegeben.

Neben dieser Zuordnung eines Changesets zu einem Ticket werden weiterhin alle Changesets in der Liste der Aktivitäten eines Projekts aufgelistet. Zu beachten ist allerdings, dass in der Standardeinstellung Redmine nur dann neue Changesets aus dem Projektarchiv ausliest, wenn ein Benutzer auf den Menüpunkt Projektarchiv klickt. Wenn man diesen Vorgang automatisieren möchte, kann man sich einen Cron-Job einrichten, der die Synchronisierung z.B. alle 5 Minuten durchführt.

Wiki

Sehr häufig nutze ich das Modul Wiki, dass für jedes Projekt aktiviert werden kann. Bisher sind während der Entwicklung immer wieder Zettel und Dokumente entstanden, die relativ unstrukturiert die Basis für entstandenen Quellcode waren. Auch Bemerkungen und Hinweise für evtl. Erweiterungen oder die Ergebnisse einer Recherche zu einem Problem wurden so festgehalten.

Handelt es sich um Notizen, die für die Erledigung eines Tickets erfasst wurden und für keine weiteren Aufgaben im Projekt mehr benötigt werden, gebe ich die Notizen in der Beschreibung oder in einem Kommentar dazu ein. Wenn die Notizen aber für das ganze Projekt von Bedeutung sind oder evtl. später auch von anderen Projektteilnehmern benötigt werden, bietet sich ein Eintrag im Wiki an.

Das Wiki kann von jedem Projektteilnehmer eingesehen werden. Auch ist es möglich, dass Einträge von jedem Entwickler geändert bzw. korrigiert werden können. Die Syntax des Wikis von Redmine ist sehr einfach gehalten. Eine Dokumentation kann dem Redmine guide entnommen werden.

Redmine Consulting

Meinen Artikeln über Redmine ist sicherlich zu entnehmen, dass ich von diesem System begeistert bin. Es nimmt mir als Software-Entwickler eine Menge Arbeit ab, ist dabei leicht zu bedienen und hilft die Arbeit besser zu strukturieren und zu dokumentieren.

Wer jetzt auf den Geschmack gekommen ist und gerne selbst Redmine in seiner Entwicklungs-Abteilung / seinem Projekt nutzen möchte, dem stehe ich gerne beratend zur Seite. Telefonnummer und eMail-Adressen finden sich hier.