Kurzzusammenfassung der Session "Scrum & Technische Schulden"

 

SYMPTOMATIK

 

Stichwort "Komplexität"

 

Mit steigendem Alter wächst die Komplexität von Softwaresystemen.

Hierbei kann man zwischen nötiger (weil probleminhärenter) Komplexität und unnötiger Komplexität unterscheiden.

 

Ursachen unnötiger Komplexität können sein:

- Unklare Fachlichkeit ("Wir wissen gar nicht mehr genau, was unser System überhaupt genau macht bzw. machen sollte.")

- Generelle Undurchsichtigkeit des Systems ("Man sieht den Wald vor lauter Bäumen nicht.")

- Fehlende Dokumentation (evtl. auch im Code, wenn dieser nicht selbsterklärend ist - was natürlich zu bevorzugen wäre)

- pathologische Firmenpolitik (z. B. durch veraltete Arbeitsmittel)

 

Stichwort "Technische Schulden"

 

Unter der Metapher "Technische Schulden" wird die Tatsache verstanden, dass wir durch etwaige "Abkürzungen" bei der "Quick & Dirty"-Implementierung einer Funktionalität unseres Softwaresystems Schulden in technischer Weise aufnehmen.

 

Ursachen:

- Termindruck

- knappe Budgets

- mangelndes Qualitätsbewusstsein (hier sind Kunden, Manager und Entwickler gleichermassen gemeint)

 

Mögliche Auswirkungen:

- Verschlechterung der Velocity. Schlimmstenfalls wird die Velocity soweit verringert, dass der Aufwand, der in das "alte System" investiert werden müsste, um eine gewünschte Änderung durchzuführen, den Aufwand einer kompletten Neuentwicklung (mit evtl. weiteren Vorteilen) übersteigt. Allerdings: Ändert sich die Akzeptanz der technischen Schuldenaufnahme auch bei der Entwicklung des neuen Systems nicht, dann steht man mit dem neuen System sehr bald wieder vor der gleichen unbefriedigenden Situation.

- Verschlechterungen in der internen Qualität, z. B. bei Architektur, Design oder Code

- Code ist ungetestet oder gar untestbar

- Verschlechterungen in der externen Qualität, z. B. bei Usability

- Verschlechterung in der Wartbarkeit

- Fehler (bzw. hoher Anteil an Bugfixingaufwänden)

- Verschlechterung der Stimmung im Team

 

Stichwort "Fachliche Schulden"

 

Im Meeting wurde der Begriff "Fachliche Schulden" als Synonym für unklare Anforderungen/Anforderungsdokumente benutzt.

(Es kann hierzu allerdings angemerkt werden, dass ein Scrum-Team, welches solche unklaren Anforderungen erhält, natürlich auch Verantwortung für die Klärung etwaiger Unklarheiten trägt.)

 

 

BEHANDLUNG

 

Es bedarf der Einsicht bei den Projektbeteiligten, dass die ständige Aufnahme von technischen Schulden aus den o. g. Gründen und wegen den o. g. Auswirkungen untolerierbar ist.

Wurden bereits technische Schulden im grösseren Masse aufgenommen, dann müssen möglichst sofort Massnahmen zur Besserung umgesetzt werden. So wird die Schulden-Neuaufnahme gestoppt und ein weiteres Absinken der Velocity verhindert. Die folgende Liste kann hierbei eine Anregung geben:

 

Anpassung der Definitions of Done, z. B.

- Aufnahme von Tests

- Aufnahme von Reviews (z. B. in Teams oder auch nach dem Vieraugenprinzip)

 

Einführung neuer Entwicklungspraktiken, z. B.

- Design-Workshops

- Entwickler-Schulung und Awareness-Initiativen zur Codequalität

- "Delta-Testing" = Testen der neuen bzw. geänderten Programmteile

- Akzeptanztests

- Continuous Integration

- Pair Programming

- Reviews

- "Denkhorizont" Application Lifecycle/Total Cost of Ownership

- "Set-Based Engineering": Zu komplizierten Problemen mindestens 2 Alternativvorschläge erarbeiten, die Vorschläge evaluieren/diskutieren, den besten Vorschlag  weiterverfolgen

- Bugs: Einrichtung eines Firefighting-Teams (Jemand nannte das "Sacrifice the Person"-Pattern)

- "Nenn' es nicht Refactoring! :-)"

- Verbesserung der QA-Zusammenarbeit, z. B. durch explizite QA-Handover-Meetings, in denen den QA-Mitarbeitern die neuen oder geänderten Funktionen vorgestellt werden, damit diese an den betreffenden Stellen zielgerichtet und effektiv testen können.

- Verbesserung der Zusammenarbeit mit Operations, z. B. durch regelmässige Meetings in denen ungewünschte Produktionsereignisse besprochen werden, die dann zeitnah behoben werden.

- Usability-Tests mit realen Nutzern

 

In weiteren Schritten müssen technische Schulden wieder zurückgezahlt werden:

Dies kann z. B. so geschehen:

- Teil- bzw. Vollsanierung (z. B. durch Refactorings oder (teilweisen) Neubau) der durch technische Schulden in Mitleidenschaft gezogenen Bereiche.

 

 

Autor: Michael Mayr (Michael -PUNKT- Mayr -AT- tngtech.com)