Softwareentwicklung im Team – Teil 7 – Informationspolitik

Das Thema Dokumentation hatten wir hier schonmal. Dort hatte ich auch erwähnt, dass Dokumentation zugänglich sein muss. Das gilt allerdings nicht nur für die Dokumentation, sondern auch für andere Informationen wie z.B. offene Tasks, Fehlerreports, Roadmaps, etc.
Wir hatten damals Mantis als Bugtracker aufgesetzt (welcher sporadisch verwendet wurde, wenn man die Fehler, die per Mail ankamen, nicht sofort abgearbeitet hat), ein Wiki (welches mehr Marketing Bla Bla enthielt, als Nützliches) und einen E-Mail-Client (welcher neben Skype das wohl DAS Programm schlechthin für die Kommunikation war).

6. Problem / Beispiel
Informationspolitik

Zur Zeit verwenden wir ab und zu Mantis als Bugtracker, das Wiki hat sich nie wirklich etabliert, Dokumente / Informationen werden per Skype oder Mail versendet. Letzteres ist die häufigste Form der digitalen Kommunikation. Eine zentrale Stelle, zu welcher alle Entwickler Zugang haben, gibt es leider nicht.
Häufig auftretende Fragen (z.B. wie binde ich einen neuen Menüpunkt ein), sind nirgends kurz dokumentiert.

Lösungsvorschlag
Das Programm Redmine (http://www.redmine.org/) vereint Bugtracker, Wiki, Forum, Dokumenten- und Dateiablage. Redmine ermöglicht es, mehrere Projekte zu managen und den Zugang feingranular zu regulieren.

Vorteile
– alle Entwickler können sich auf den gleichen Stand bringen
– Möglichkeit der offenen Diskussion über neue Features
– Sind offene Aufgaben dokumentiert, entsteht kein Leerlauf (insbesondere für die Studenten), sollten mal die “Entscheider” in Meetings verhindert sein
– Nachvollziehbarkeit, warum Entscheidungen für oder gegen eine Vorgehensweise gefallen ist, soweit Redmine als Kommunikationsplatform genutzt wird
– Entwickler können Aufwandsschätzungen für einzelne Tasks abgeben, woraus sich automatisch Gantt-Charts generieren lassen können

Nachteile / Probleme
– Es muss aktiv genutzt werden! Anfangs würde es meines Erachtens nach schon langen, wenn vorhandene Dokumente dort eingepflegt werden, sowie neue Fehler nicht mehr per Mail sondern dort eingetragen werden. Setzt man dies konsequent durch, dürfte einer Etablierung nichts im Wege stehen.

Aufwand
Das Aufsetzen von Redmine ist relativ problemlos (Redmine benötigt Ruby) und bietet auch einen Konverter für Mantis an. Das Wiki ist bei uns so überschaubar, dass sich das von Hand nachpflegen lassen könnte, sollte es dafür keinen Konverter geben. Das Aufsetzen selber sollte nicht länger als einen halben Tag einnehmen

Rückblickend gesehen
Eins der größten Probleme war wohl, dass wir als kleines Team in einem Großraumbüro saßen und eigentlich alles auf Zuruf machen konnten und teilweise auch getan haben. Dokumente wurden via Skype oder Mail versandt und wenn das Dokument nicht mehr zum Code passte, fragte man in den Raum hinein, wer den aktuellen Stand hat. Das ging in der Anfangsphase natürlich recht gut, aber je mehr Zeit ins Land zog und unsere grauen Zellen älter wurden, umso schwieriger war es, Sachen zu erinnern und/oder nachzuvollziehen.
Wir haben tatsächlich eine Redmine-Installation aufgesetzt, welches die Situation ein klein wenig verbesserte. Aber nicht wesentlich. Zu häufig verfiel man in alte Gewohnheiten zurück (insbesondere die nicht-Programmierer). Zumal nur die wesentlichen Features verwendet wurden. Zeitschätzungen wurden in der Regel nicht eingetragen, was dazu führte, dass man keinen groben Überblick darüber hatte, wie lange ein Milestone noch dauern würde. Das wurde dann doch eher aus dem Bauch heraus entschieden. Schade eigentlich.

Zusammenfassung
Auch wenn es bei uns nicht den durschlagenden Erfolg hatte, den ich mir gewünscht hatte, halte ich ein Tool wie Redmine (oder ein ähnlich geartetes Projekt, wie z.B. Trac) für unverzichtbar. Das Schöne an Redmine ist, dass man alles in einem Tool hat und nur eine Seite ansurfen muss und nicht diverse (wie es anfangs bei uns der Fall mit Mantis und Wiki war).
Ich selbst verwende selbst für private Projekte Redmine. Zum einen um einen zentralen Sammelpunkt für neue Ideen zu haben und zum anderen, um Entscheidungen zu dokumentieren (und natürlich zum Bugtracking). Es ist mir schon mehr als einmal passiert, dass ich mich selbst gefragt habe, warum ich etwas so umgesetzt habe, wie ich es getan habe und nicht anders, nur um die Antwort dann in Redmine zu finden.

Ausblick
Als nächstes lasse ich mich über etwas aus, was bereits im letzten Artikel angesprochen wurde: Unit-Tests.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>