Wer schon mal an einem Projekt gearbeitet hat, an dem mehr als 1 Person beteiligt war, der weiss, wie schwierig die Koordination manchmal sein kann. Alleine? Kein Problem. Man hat einen Bug gefunden -> Schnell flicken oder irgendwo auf ein Post-it schreiben und dann später flicken.
Was aber, wenn mehrere Entwickler beteiligt sind? Beta Tester? End-Kunden? Dann wird es spätestens so nicht mehr haltbar, denn:
Der Beta Tester findet einen Fehler. E-Mail schreiben an den Entwickler, aber es gibt ja vielleicht mehrere Entwickler. So nimmt das Chaos seinen Lauf. Daher ist es eigentlich absolut notwendig, einen Issue Tracker zu haben. Natürlich sind auch noch andere Dinge notwendig, z.B. SVN/CVS Server, falls neue Module geschrieben werden und ein Testserver. Möchte jedoch ein bisschen näher auf den Issue Tracker eingehen.
Was ist ein Issue Tracker (oder auch Bug tracker)? Nun, es ist ganz einfach ein Tool, welches Bugs (Fehler) verwaltet. Ein klassisches Usecase sieht wie folgt aus: Der Beta Tester findet einen Fehler. Er geht zum Bug Tracker und erstellt dort einen neuen Bug (meistens werden diese mit diversen Metadaten gekennzeichnet, unter anderem der Status und die Priorität). Einer der Entwickler kann sich dem Bug widmen und dran arbeiten und über den Status alle anderen Projektteilnehmer darüber informieren.
Drupal.org ist ein rieser Bug Tracker. Z.B. vom Fast Gallery Modul. Füe jedes Modul ist os ein Bug Tracker vorhanden. Ein Bug Tracker ist jedoch nicht nur für Entwickler sinnvoll, sondern auch für Leute, welche mittels Drupalmodulen eine Seite bauen. Beispiel:
Ich bin gerade daran eine grössere Plattform für die Verwaltung eines grösseren Bauprojektes am Bauen. Das ganze ist recht kompliziert mit OG, CCK und Views und diversen von OG abhängigen Berechtigungen. Das Projekt ist sehr prototypisch, da der Kunde zum ersten Mal eine solche Plattform einsetzen will. Daher sind auch die Bedürfnisse überhaupt nicht klar definiert. Anforderungen können von Tag zu Tag ändern und es kommen halt auch manchmal Fehler vor: Beschriftung nicht so wie sie sein sollte, Views nicht praktisch, Inhaltstyp braucht noch ein Feld mehr usw.
Ohne Bug Tracker wäre das Projekt schon lange gestorben. Der Bug Tracker ist der ruhende Pol im Projekt. Er ist auch eine Quelle, welches Vertrauen fördert, da der Kunde sehen kann, dass etwas gemacht wird. Auch wenn vielleicht ein Fehler nicht behoben werden kann, können schon mal Informationen dazu gegeben werden.
Was sind die wichtige Features eines Bug Trackers:
- Prioritäten setzen
- Status setzen
- Möglichkeit notifications zu verschicken (per E-mail)
Das ist es eigentlich auch schon. Drupal Project ist eigentlich wunderbar dafür geeignet. Im Moment ist es nur für D5 erhältlich, aber es wird eifrig an einer D6 Version gearbeitet. Aber auch eine D5 Version ist vollkommen ausreichend. Es ist ja lediglich ein Arbeitstool, welches die Funktionalität bringen muss.
Im Moment setze ich für jedes Projekt einen neuen Bug Tracker auf. Mein Ziel wäre eigentlich, eine Plattform, welche mehrere Projekte verwalten kann. Mehrere Projekte ist kein Problem (siehe Drupal.org), aber es müssen entsprechende Berechtigungen gesetzt werden, sprich Benutzer von Projekt A, darf nicht in Projekt B sein. Ich denke, mittels OG und OG_access liesse sich etwas entsprechendes realisieren, aber ich bin leider noch nicht dazu gekommen.
Fazit:
Wer bisher noch ohne Bug tracker in einem Projekt mit mehr als 2 Leuten gearbeitet hat, sollte vielleicht mal die Lage überdenken.