Ist es die Komplexität der Aufgabe, die sich ergebende Design-Erosion oder sind es falsche Entscheidungen, die zu Problemen führen? Der Vortrag zeigt auf, wie man von üblichen Failures/Symptomen zu möglichen Faults/Ursachen und Gegenmaßnahmen kommt. Dabei kann man Failures messen, mögliche Faults bestimmen und Maßnahmen überprüfen, sodass ein Lernprozess etabliert wird. Zum Beispiel kann eine hohe Fehlerdichte auf schlechte Code-Dokumentation, diffuse Verantwortlichkeit oder hohe Featurekopplung gewisser Codemodule zurückgeführt werden.

Zielpublikum: Architekt:innen, Projektleiter:innen, Key Developer, Management, Entscheidungsträger
Voraussetzungen: Architekt:innen, Projektleiter:innen, Key Developer, Management, Entscheidungsträger
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist es die Komplexität der Aufgabe, die sich ergebende Design-Erosion oder sind es falsche Entscheidungen, die zu Problemen führen? Führt die Komplexität zu früher Design-Erosion? Oder war die Diagnose falsch, die dazu geführt hat, dass trotz Gegenmaßnahmen zur Design-Verbesserung die Implementierung neuer Features sich weiterhin schwierig gestaltet? Der Vortrag zeigt auf, dass es zu üblichen Failures (als Symptome) mehrere mögliche Faults (d.h. Ursachen) geben kann. Failures und mögliche Faults müssen als Metriken gemessen werden, um daraus auf eine gute Diagnose und die richtigen Gegenmaßnahmen zu schließen.

Wir gehen im Vortrag auf einige Failure/Faults/Maßnahmen-Ketten ein und zeigen für Manager:innen und Entwickler:innen ein Vorgehen auf, was und wie zu messen wäre, um einen Lernprozess zu etablieren. Statt Vollständigkeit wollen wir Beispiele (anhand konkreter Projekte) liefern:

- wie z.B. für eine hohe Fehlerdichte mit vielen follow-up Bugs (Failure) mehrere potenzielle Ursachen (Faults) infrage kommen können: schlechte Code-Dokumentation, diffuse Verantwortlichkeit der Entwickler oder hohe Featurekopplung der entsprechenden Code-Module. Und wie man anhand von Messungen zu einer Diagnose und möglichen Gegenmaßnahmen kommt, deren Effekt auf Faults und Fehlerdichte wiederum gemessen werden kann.

- wie man die Schwierigkeit messen kann, neue Features hinzufügen (Failure) und trotz gelegentlichem Refactoring den mangelnden Effekt auf noch nicht ausreichendes oder Refactoring der falschen Codestellen (Faults) zurückführen kann. Und wie man Aufwände und die Effektivität von Verbesserungsmaßnahmen verfolgen kann.

- oder wenn man angesichts eines aufwendigen Releases mit vielen neuen Features, aber unzufriedenen Kunden wohl trotz agiler Entwicklung am Bedarf vorbei entwickelt hat. Und welche möglichen Ursachen infrage kommen und daraus Empfehlungen ableiten kann, sei es konzeptioneller Art zur besseren Erfassung des Benefits eines Features bis zu technischen Mitteln zur Messung der Nutzung der Features.