ALM mit Redmine, Teil 2

Im ersten Teil hatte ich ja bereits angekündigt, dass ich über unsere Erfahrungen mit Redmine weiter berichten werde. Leider hat sich das Ganze anders entwickelt als gedacht. Da bei uns vornehmlich Outlook zum Einsatz kommt und wir auch alle unsere Kundendaten im Outlook haben, nutzen wir jetzt doch eine Kommerzielle Erweiterung für Outlook um unsere Support-Anfragen zu bearbeiten. Aber nichts des do trotz arbeite ich jetzt erst mal alleine mit Redmine.

Da ich mehrere kleine und große Projekte habe, die ich in Eigenregie plane und Entwickle ist eine gute Aufgabenplanung unerlässlich. Mit Redmine habe ich jetzt endlich ein vernünftiges Werkzeug dafür gefunden. Ich habe mehrere Projekte und Unterprojekte in denen vor allem die drei Tracker “Bug”,  “Feature” und “Anforderung” zum Einsatz kommen. Für Bugs war das ganze ja sowieso gedacht, jetzt kommt der Bugtracker halt zum Einsatz wenn ich selber Fehler finde oder der Kunde mir direkt welche schickt. Im Tracker “Feature” landen Ideen für Erweiterungen unserer Produkte.

Besonders wichtig ist für mich in letzter Zeit der Tracker “Anforderung” geworden. Da es sich hier um konkrete Aufgaben handelt, welche für den Kunden abgearbeitet werden müssen, ist das der Tracker mit den meisten Tickets. Außerdem nutze ich den Tracker dafür, meine Aufwände zu Planen. Ich zerlege die Aufgaben so, dass ich bei Maximal ein bis zwei Tagen, am besten jedoch bei ein bis zwei Stunden rauskomme. Somit kann ich bei einem Angebot ziemlich zuverlässig sagen wie viel Manntage bezahlt werden müssen.

Damit die Planung auch Sinnvoll und Realistisch ist, muss natürlich der tatsächliche Aufwand mit erfasst werden. Erst dadurch ist es möglich die Abschätzungen zu überprüfen und bei neuen Aufgaben genauere Zahlen zu liefern. Damit man nicht ständig auf die Uhr schauen muss wenn man an einer Aufgabe arbeitet, gibt es zum Glück das TimeTracker Plugin. Es zeigt in der rechten oberen Ecke einen Button “Start #xxx” mit dem die Zeiterfassung für die aktuelle Aufgabe begonnen werden kann. Wenn der Timer läuft wird an dieser Stelle immer die aktuell benötigte Zeit angezeigt. Und da es wahrscheinlich vielen so geht wie mir, die beim Arbeiten durch Telefonate oder Sonstiges abgehalten werden, gibt es einen Pause-Button, welcher die Zeitmessung unterbricht. Drück man schließlich auf den Stopp-Button öffnet sich automatisch die Aufwands-Erfassungsmaske, in der die benötigte Zeit, in Stunden umgerechnet, bereits eingetragen ist. Hier kann man nun noch ein Kommentar mit einer Beschreibung der Tätigkeit eingeben und das Ganze als Tätigkeit für die Aufgabe speichern.

Da bei mir der Berg an Papier mit Feature-Wünschen und Anpassungen von unseren Kunden immer weiter gewachsen ist und ich da nicht mehr wirklich durchgesehen habe, wird so etwas jetzt immer eingescannt. Die PDF Datei hänge ich dann an die konkrete Aufgabe oder den Fehler als Anlage mit dran. Somit entfällt das lange Gesuche nach irgendwelchen Blättern mir Designvorgaben und Co. Das gleiche gilt natürlich auch für Dokumente oder Screenshots die ich per Mail erhalten habe. Sollte solch eine Datei mehrere Aufgaben betreffen, gibt es in Redmine die Möglichkeit, Dokumente zu einem Projekt zu speichern. Diesen Dokumenten gibt man einen Namen und eine kurze Beschreibung. Per document#xxx (xxx ist die ID des Dokuments) kann man dann schließlich in der Beschreibung einer Aufgabe oder einem Kommentar auf das Dokument verlinken. Hierbei wird der Ausdruck mit dem Dokumentnamen ersetzt. Es gibt übrigens eine ganze Reihe solcher Ausdrücke , um zwischen Dokumenten, Wiki-Einträgen und anderen Aufgaben zu verlinken. Eine Übersicht dafür liefert die Wiki-Seite von Redmine.

ALM mit Redmine, Teil 1

Kürzlich war ich auf der Suche nach einem guten Bugtracker, um den Support in unserer Firma etwas zu unterstützen und um so eine Art Wissensdatenbank aufzubauen. Zur Zeit werden bei uns Fehlermeldungen und Probleme von Kunden unserer Produkte vom Support-Mitarbeiter entgegengenommen und so weit geholfen wie möglich. Wenn unser Support-Mitarbeiter nicht mehr weiter weiß, wird das Problem telefonisch oder per E-Mail an den entsprechenden Entwickler dieser Software weitergeleitet. Der bearbeitet dann das Ganze und schickt dem Kunden eine Lösung bzw. verweist ihn auf ein kommendes Update der Software. Es ist natürlich ungünstig für den Entwickler, wenn ähnliche Probleme immer wieder bei ihm auf den Tisch landen und ihn von der eigentlichen Arbeit abhalten.

Um diesen Missstand zu beheben wollen wir jetzt einen Bugtracker einführen welcher den Support-Mitarbeiter bei der Fehlerbehebung unterstützt. Einmal aufgetauchte Fehler oder auch nur Anfragen werden in den Bugtracker eingetragen und kategorisiert. Wenn der Fehler nicht gleich behoben werden kann, kümmert sich der entsprechende Entwickler darum und trägt die Lösung ein bzw. verweist auf die Programmversion, in der der Fehler behoben ist. So weit der Plan jedenfalls!

Bei meiner Suche nach entsprechenden Lösungen bin ich natürlich auf tausende von Systemen und Programme gestoßen. Da das Ganze aber so kostengünstig wie möglich sein soll, blieben nur ein paar wenige Open-Source Programme übrig. Die da wären Bugzilla, Mantis, Trac und schließlich Redmine.

Von den ganzen Programmen hat mir Redmine am besten gefallen. Bugzilla war zwar gut, aber die Installation ist einfach unmöglich. Mantis ist vom Umfang her auch recht gut, aber die Oberfläche sieht einfach altbacken aus. Und Trac schließlich hat keine wirklich zufriedenstellende Multi-Projekt-Unterstützung und eine zu komplizierte Oberfläche. Redmine war mir vorher total unbekannt, aber dank Bitnami und ihren fertigen All-in-one-Installern bzw. ihren fertigen Virtuellen Maschinen konnte ich den Bugtracker ohne Probleme ausprobieren.

Also läuft jetzt bei uns erst mal eine VM mit Ubuntu 10.10, Apache, MySql, Ruby und Redmine zum Testeinsatz. Dank der Weboberfläche war es das schon fast mit der Installation der Software im Unternehmen. Jetzt bracht nur noch jeder Mitarbeiter ein Login und den Link mit der IP der VM und dem Programm. Die Weitere Einrichtung des Programmes sowie unsere Erfahrungen damit, werden in den kommenden Teilen beschrieben.