Dienstag, 25. November 2014

Fehlermanagement in mehreren Entwicklungslinien

In der Regel hat man ja verschiedene Versionen (Releases) einer Software. Eine beim Kunden verfügbare Version und mindestens eine Variante für die Weiterentwicklung. Nun tritt in einer Komponente (unterschiedliche Versionen) ein Fehler auf. Wie organisiert man nun das Bug-Tracking und den Ausbau? Dazu gibt es zwei prinzipielle Ansätze:
  1. Im Bug-Tracker wird für jeden Softwarestand ein Bug angelegt
  2. Im Bug-Tracker hat man einen Bug, der für alle Versionen gilt.
Was bedeutet dies nun, wenn man für jede Version einen Bug im System hat (1):
  • Für jede Version muss man einen Bug im System einstellen (Aufwand ist aber eher ein kleiner) und bearbeiten.
  • Transparenz, wie weit die Umsetzung für die jeweilige Version ist. Das ist gut für das Team, da beim Ausfall eines Kollegen (z. B. Krankheit) sofort offensichtlich wird, was noch offen ist.
  • Es wird offensichtlich, in welchen Versionen der Fehlerausbau zu testen ist (unabhängig ob dies automatisiert oder manuell geschieht).
Und wie sieht es beim Ansatz (2) aus:
  • Haben die Entwickler ihre Aufgaben wirklich gut im Griff (keine Ablenkung durch neue Prioritäten, neue Probleme etc.) reicht nur ein Eintrag im Bug-Tracker. Bei kleinen Teams ist dies ggf. eine praktikable Vorgehensweise.
  • Es ist allerdings zu klären für welche Version der Bug im System angelegt wird (das wird vor allem schwer, wenn verschiedene Releases beim Kunden verfügbar sind).
  • Die Transparenz über den Fortschritt bei Fehlerausbau und Test in den verschiedenen Versionen hat man natürlich nicht. Und wenn der Entwickler mal krank wird, ist nicht so einfach erkennbar, was bereits erledigt wurde.
Gerade in größeren Teams und Organisationen und bei Verfügbarkeit von drei (Freigabe-Release, Pilot-Release, aktuelles Release in der Entwicklung) oder mehreren Releases tendiere ich wegen der Übersichtlichkeit zur Lösung (1). Auch weil jeder Bug gleichzeitig ein Requirement für ein Release ist und damit deutlich wird was alles für das Release zu tun ist. Aber letztendlich muss jeder für sich entscheiden, welche Vorgehensweise für die eigene Organisation besser geeignet ist.