#3: Der Defect

Nachdem im ersten Blogbeitrag dieser Serie ein allgemeiner Überblick gegeben wurde und im zweiten Teil die erste Vertiefung mit dem „Bug“ erfolgte, wollen wir uns im dritten Teil mit dem Defect beschäftigen.

Ein Defect beschreibt einen Fehler, der in der übergebenen Software gefunden wurde. Die Ursachen für dieses „fehlerhafte“ Verhalten können in der Implementierung, der Anforderung an die Software oder in den Spezifikationen und Dokumentationen der Software liegen. Typischerweise werden Defects während der Test-, Integrations-  oder Deployment-Aktivitäten identifiziert. Das heißt, die Entwicklungsteams haben aus ihrer Sicht lauffähigen Code übergeben – ein Hand-over hat stattgefunden.

Abbildung 1: Artefakte des Change Management im ALM

Wird ein Defect innerhalb einer Entwicklungs-Organisation gemeldet und verarbeitet, muss zunächst qualifiziert werden, ob tatsächlich ein „fehlerhaftes“ Verhalten vorliegt. Häufig werden vermeintliche Defects eingestellt, die aus Sicht der Entwicklung aber ein gewolltes oder toleriertes Verhalten darstellen – frei nach dem Motte „It’s Not a Defect, It’s a Feature“.

In den meisten Fällen wird bei der Analyse der Defect bestätigt und die Ursachen werden identifiziert. Auf dieser Basis lassen sich spätestens jetzt geeignete Lösungsalternativen konzipieren und schätzen. Die Defects können dann in die nächsten Entwicklungszyklen einfließen.

Damit haben wir jetzt die dritte essentielle Eigenschaft eines Defect herausgearbeitet:

1. das „Hand-over“ der Entwicklungsteams, die lauffähige Software geliefert/übergeben haben, damit weitere Test-, Integrations- oder Deployment-Aktivitäten durchgeführt werden können
2. jeder Defect muss qualifiziert und analysiert werden, ggf. werden Lösungsalternativen konzipiert und geschätzt
3. Defects (die nach der Analyse anerkannt sind und behoben werden sollen) stehen in Ressourcen-Konkurrenz mit neuen User Stories, neuen Features oder neuen Arbeitspaketen, die geplant von den Entwicklungsteams umgesetzt werden sollen.

Denn anders als neue User Stories, neue Features oder neue Arbeitspakete, treten konkrete Defects ungeplant auf und erzeugen somit einen weiteren Ressourcenkonflikt.

Damit grenzen sich Defects auch hervorragend von Bugs ab, die wie im vorherigen Serienbeitrag beschrieben: nur Fehler im Code darstellen, die ausschließlich zur Zeit der Implementierung dokumentiert werden und zur Selbstverwaltung des Bug-fixing der Entwickler dienen.

Auch später nach der Auslieferung der Software z.B. in der Operate-Phase können Defects von Kunden über Tickets gemeldet werden. Mit dem Ticket, als weiteres Artefakt und als Eingangskanal, kann „fehlerhaftes“ Verhalten der Software von außen in die Entwicklungs- und Serviceorganisation gemeldet werden.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.