Eigentlich ist ein Bug
“an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” (Wikipedia)
Also auf die Software bezogen, erstmal unabhängig von der Ursache. Weil die Entwickler dann analysieren und SM, PO, PM, BA und QS nicht viel machen können, wird Bug oft gleichbedeutend mit “Fehler der Entwickler” verstanden, obwohl die eigentliche Ursache noch gar nicht klar ist. Eventuell gab es implizite Anforderungen, die verloren gegangen sind, oder etwas wurde nachträglich anders gestaltet. Bevor die genaue Ursache bekannt ist (fehlerhafte Entwicklung, mangelnde Spezifikation, keine QS, …) betrifft ein Bug alle am Produkt arbeitenden Personen. Jeder sollte sich fragen, was er hätte tun können, um diesen Bug zu vermieden. Die falsche Vorstellung, dass ein Bug erstmal ein Entwicklungsfehler ist, führt oft zu heimlicher Schuldzuweisung, Frustration und Rechtfertigung der Entwickler. Zusammengefasst, einer kontraproduktiven Fehlerkultur. Wenn sich diese falsche Vorstellung manifestiert, kann es helfen, die Namen der Artefakte und damit deren verstandene Bedeutung zu ändern. Wundern Sie sich aber nicht, wenn das auf Widerstand stösst. Immerhin ist es für viele Nicht-Entwickler eine komfortable Situation per Default “nicht schuld zu sein” und die Verantwortung bei den Entwicklern zu wissen.
Weniger (be)wertend
Bug oder Defekt zu einer Story ist zu sehr wertend (“schlecht”, “falsch”). Das unterstützt und vereinfacht Schuldzuweisung bewusst oder unbewusst. Zwar kann man sagen, das sind “fachliche” Defekte, aber eigentlich ist das immer ein “Problem” mit dem Produkt der Entwickler. Und damit überträgt sich das wertende auf die Arbeit der Entwickler. Die Entwickler können schuld sein, dann wäre diese Sichtweise richtig. Die Entwickler können aber auch nicht Schuld sein, dann wäre es die falsche Sichtweise. Die Ursachen eines Bugs oder Defektes sind vielfältig, warum haben wir also ein Wort gewählt, das implizit die Entwickler “beschuldigt”, ob wir das wollen oder nicht? Sinnvoll wäre ein wertfreier Begriff wie Verbesserung oder Erweiterung, der sich auf alles anwenden lässt. Schließlich wäre die einzig zielführende Reaktion eine Anpassung, egal was die Ursachen sind.
Unterscheidung CR und Bug
Unter einen solchen neutralen Begriff würde auch der CR fallen. Man hätte statt zwei also nur noch ein Artefakt. Angeblich ist die Unterscheidung aber für die Messung und Begründung der internen Wirtschaftlichkeit wichtig. Kein Wunder also, dass alles Bugs und Defekte sind ;). UserStory ist neutral genug. Man könnte trotzdem ein neutrales Artefakt Anpassung haben und für die Unterscheidung verschiedene Eigenschaften wählen. Welche Eigenschaften sollte es geben?
Was wir nicht wollen sind Schuldfragen und Verantwortlichkeit der Mehrarbeit:
- Entwickler-Schuld
- BA-Schuld
- Kunde-Schuld
- Ungewiss-wer-Schuld-ist
Besser wären verschiedene Bezeichnungen für verschiedene Dinge:
- Technischer/semantischer Fehler (es funktioniert nicht oder falsch (Rechtschreibfehler))
- Übersehene Anforderung (es steht auf der Story)
- Neue Anforderung (es steht nicht auf der Story)
Oder einfach nur
- Auf Kosten des Teams
- Auf Kosten des Kunden
Weniger abstraktes, mehrdeutiges, unklares und vorallem weniger Schuldzuweisung, Frustration und Rechtfertigung. Softwareentwicklung betrifft das gesamte Produktteam und nur gemeinsam ist es stark.
halllo welt 