Mehr Softwarequalität: Technische Schulden

Thementag 25.11.2014, Technische Schulden
1| 56
Projekte. Beratung. Spezialisten.
Technische SchuldenRisiko und Chance für mehr Softwarequalität
IKS-Thementag
25.11.2014
Autor:Dr. Reik Oberrath

2| 56
Definition 1
„Technische Schuld oder Technische Schulden (engl. technicaldebt) ist eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software…
Der Begriff … wird von Informatikern … verwendet, um Managern … klarzumachen, dass die Hintanstellung von Maßnahmen zur Sicherung … technischer Qualität die Softwareentwicklung … verlangsamt…“
http://de.wikipedia.org/wiki/Technische_Schuld
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back…”
Ward Cunningham: The WyCashPortfolio Management System.
In: OOPSLA '92 Experience Report. 26. März 1992
first time code is like going into debt. A little debt speeds development so long as it is paid back… Every minute spent on not-quite-right code counts as interest on that debt.”
debt. Entire engineering organizations can be brought to a stand-still under the debt load…”
Begrüßung | Einleitung| Mögliche Kategorisierungen | Best-Practices | Tilgen oder Schulden zahlen? | Im größeren Kontext | Schlussteil

Auf der Baustelle arbeiten
Schick machen
Refactoring
First Time Code
Not-Quite-RightCode
Auf der Baustelle arbeiten
Clean Code

Ward Cunningham:
“A little debt speeds development..”
Altlasten als langfristige Kostentreiber
Zeit
Summe
realisierter
Feature
Amortisierungsgrenze
Mit Refactoring
Mit Technischen Schulden
Nach http://martinfowler.com/bliki/DesignStaminaHypothesis.html
Ward Cunningham:
“…stand-still under the debt load…”
Verlorene
Ressourcen

5| 56
Grundidee
“Shipping first time code” Schulden
“It is paid back”Tilgung
“Every minute spent on not-quite-right code” Zinsen
“Stand-still under the debt load”… Bankrott
Bildnachweis:
http://www.wissen.de/redewendung/ein-klotz-am-bein-sein-2013-05-17
500 Mrd$ *
* Vom Marktforschungsunternehmen Gartner geschätzt für aktuellen den globalen IT-Altlastenberg
siehe http://www.datacenter-insider.de/software-on-premise/anwendungen/articles/459751/index3.html
** Vom Wirtschaftsprüfungsunternehmen Deloittegeschätzt für Sourcecode-Fehlersuche in 2012

6| 56
Strategisches Design
1. Niedrige Zinsen nutzen
2. Aktuelle Marktvorteile nutzen

Thementag 25.11.2014, Technische Schulden 7 | 56
Grenzen der Metapher
Schuldenfreie Softwareentwicklung gibt es nicht
Bei wem macht man Technische Schulden? Wer ist die Bank?
Technische Schulden erlöschen nach dem Betrieb der Software
Technische Schulden werden nicht in vielen kleinen verbindlichen Raten
zurückgezahlt
Viele Technische Schulden entstehen unbewusst, echte Schulden aber i.d.R.
halbbewusst oder ganz bewusst
Begrüßung | Einleitung | Mögliche Kategorisierungen | Best-Practices | Tilgen oder
Schulden zahlen? | Im größeren Kontext | Schlussteil

8| 56
Definition 2
B) Technische Schuld im weiteren Sinneist die Summe aller Defizite einer Software, also alles, was dem Clean-Code-Gedanken widerspricht.
Siehehttp://www.clean-code-developer.de/ http://www.clean-coding-cosmos.de/
A) Technische Schuld im engeren Sinneist die Summe aller Defizite einer Software, für die sich die Akteure bewusst (oder wenigstens halbbewusst) entschieden haben.
Siehe
https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

Einleitung
Kategorien von Technischen Schulden
Best-Practices im Umgang mit Technischen Schulden
Tilgen oder Zinsen zahlen?
Technische Schulden im größeren Kontext
Zusammenfassung

11| 56
Bewusstseinsarten (Motivation, Einstellung)
Konsequenzen und Gegenmaßnahmen
bewusst?
Nein
Ja
Schulden bewusst?
Nein
Ja
„Was ist das Problem?“
Erst im Nachhinein:
„Ach so, wenn wir das vorher gewusst hätten, hätten wir die Chance gehabt, das sauber zu erledigen.“
Nachhttp://martinfowler.com/bliki/TechnicalDebtQuadrant.html
„Wir verzichten auf die saubere Lösung. Die entstehenden Probleme sind bekannt und werden beherrscht.Wir müssen jetzt liefern.“
„Ok, sauber geht anders, aber über eine saubere Lösung machen wir uns jetzt keine Gedanken. Wir müssen jetzt liefern.“

12| 56
Bewusstseinsarten (Motivation, Einstellung)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Sorglos
Bedacht
Unachtsam
Umsichtig
Kurzsichtig
Bewusst
Unbewusst
Weitsichtig

13| 56

14| 56
Strategiesorten (Ziele, Planung)
Nach
http://www.construx.com/10x_Software_Development/Technical_Debt/
Taktische Kurzzeit-Schulden
Bewusste Schulden
Strategische Langzeit-Schulden
Unbewusste Schulden
Viele kleine Defizite
Ein großes Defizit

15| 56
Strategiesorten (Ziele, Planung)
Langzeit-Schulden
Kurzzeit-Schulden
Grobgranular
Feingranular
„Wir realisieren kein ContinuousDeliverysolange der Kunde mit der Auslieferungsdauer zufrieden ist“
„Wir testen jetzt noch un- regelmäßig und erkennen viele Fehler zu spät. Ab der über- nächsten Auslieferung nutzen wir ContinuousIntegration.“
„Solange wir keine größeren Probleme mit der alten Technologie bekommen, stellen wir unsere Komponenten nicht um.“
„Unser Sourcecode-Analysetool (Sonar) meldet über 100 Probleme in unseren Sourcen. Nach der übernächsten Auslieferung müssen die behoben werden.“

16| 56

17| 56
Erscheinungsformen (Aussehen, Vorkommen)
Persönliche
Schulden
Organisatorische
Schulden
Prozess-bezogene
Schulden

18| 56
Persönliche Schulden
z. B. mangelnde Motivation der Akteure Neues zu lernen, auszuprobieren und sich an Neues anzupassen
Organisatorische Schulden
z. B. veraltete hierarchische Organisationsstrukturen (Gesetz von Conway)
Prozess-bezogenen Schulden
z. B. Anwendung von veralteten Vorgehensmodellen
Mehr Informationen dazu unter http://clean-coding-cosmos.de/techdebts-4

19| 56
Persönliche
Schulden
Organisatorische
Schulden
Prozess-bezogene
Schulden
Werkzeug-bezogene
Schulden
Test-bezogene
Schulden
Praktische
Schulden
Automations-bezogene
Schulden

20| 56
Praktische Schulden
z. B. nicht aus gemachten Fehlern lernen
Werkzeug-bezogene Schulden
z. B. zu großer Wildwuchs an eingesetzten Werkzeugen
Automations-bezogene Schulden
z. B. keine automatische Testausführung (ContinuousIntegration)
Test-bezogene Schulden
z. B. unzureichende Testabdeckung der implementierten Funktionalität

21| 56
Persönliche
Schulden
Organisatorische
Schulden
Prozess-bezogene
Schulden
Werkzeug-bezogene
Schulden
Test-bezogene
Schulden
Praktische
Schulden
Schulden
Betriebs-bezogene
Schulden
AM-bezogene
Schulden
Fachseite-
bezogene
Schulden
Kommunikations-
schulden

22| 56
Kommunikationsschulden
Unzureichende Kommunikation und Zusammenarbeit zwischen den Akteuren (vor allem zwischen Akteuren verschiedener Phasen im ALM)
ApplicationLifecycleManagement
Anforderungs-
analyst
Domänen-
Experte
Architekt /
Entwickler
Administrator
Kundenakzeptanz-
tester

23| 56
Persönliche
Schulden
Organisatorische
Schulden
Prozess-bezogene
Schulden
Werkzeug-bezogene
Schulden
Test-bezogene
Schulden
Praktische
Schulden
Schulden
Betriebs-bezogene
Schulden
AM-bezogene
Schulden
Fachseite-
bezogene
Schulden
Kommunikations-
schulden
Implementierungs-
schulden
Architektur-
schulden
Produkt-bezogene
Schulden
Produktions-bezogene
Schulden

24| 56
Produktions-bezogene Schulden
z. B. mangelnde Analysierbarkeit (Logging, Protokollierung, Monitoring)
Architekturschulden
z. B. mangelnde Berücksichtigung nicht-funktionaler Qualitätskriterien
Implementierungsschulden
z. B. Code-Vervielfachungen

25| 56
Persönliche
Schulden
Organisatorische
Schulden
Prozess-bezogene
Schulden
Werkzeug-bezogene
Schulden
Test-bezogene
Schulden
Praktische
Schulden
Schulden
Betriebs-bezogene
Schulden
AM-bezogene
Schulden
Fachseite-
bezogene
Schulden
Kommunikations-
schulden
Implementierungs-
schulden
Architektur-
schulden
Produkt-bezogene
Schulden
Produktions-bezogene
Schulden
Hauptverantwortung beim Entwicklungsteam
Verteilte Verantwortung

26| 56

Buchhaltungstypen (Schuldenverwaltung)
Produkt-bezogene „Schuldenbücher“:
Liste von TODOs und FIXMEs im SourceCode (Code-Tagging-System)
Ergebnisse von Sourcecode-Analysetools (z. B. Sonar)
Architekturdokumentation (Beschreibung von Schwächen und Risiken)
Prozess-bezogene „Schuldenbücher“:
„Projektdokumentation“ (Projekt-Handbuch, Retrospektive-Bericht)
Dokumentation der „ALM-Architektur“ (Leitfaden für die
Unternehmenskultur, Beschreibung der Konzernstruktur)
Schuldenkonto:
Issue Tracker (Jira, Bugzilla, …)

28| 56
Buchhaltungstypen (verantwortliche Rollen)
Typ 1: Projekt
Typ 2: ALM
Rahmenprozesse
Hauptverantwortung bei Entwicklungsteam
Verteilte Verantwortung
Typ 1a: Produkt
Typ 1b: Teamprozesse
Projektmanager
Scrum-Master
Entwicklungsteam
SW-Architekt
Entwicklungsteam
Techn. Projektleiter
Produktmanager
ProductOwner
Gesamtent- wicklungsleiter
Scrum-Master
Projektmanager
Produktmanager

Einleitung
Zusammenfassung

31| 56
Best PractisesI
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Implemen- tierung
1a
Codereviews,Sourcecode- Analysetool (z.B. Sonar)
-> Metriken
Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien anwenden
*http://clean-coding-cosmos.de/die-ccd-regeln

32| 56
Best PractisesI
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Implemen- tierung
1a
-> Metriken
Architektur
1a
Gute Architektur- Dokumentation (arc42)
(http://www.arc42.de),
ATAM
Entworfene Architektursauber umsetzen, schlechte Architektur ändern (http://aim42.org)

33| 56
Best PractisesI
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Implemen- tierung
1a
-> Metriken
Architektur
1a
Gute Architektur- Dokumentation (arc42)
(http://www.arc42.de),
ATAM
Entworfene Architektursauber umsetzen, schlechte Architektur ändern (http://aim42.org)
Persönliche
Schulden
alle
Selbstreflexion
Motivation fördern (Fortbildungen, Teamstimmung)

34| 56
Best PractisesII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Prozess- bezogene, organisa- torischeund Kommuni- kations-
Schulden
1b
2
2
Kritische Betrachtungder Organisationsstruktur und des ApplicationLifecycleManagements (ALM)
Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung,
Aufgabenverteilungen, … ändern

35| 56
Best PractisesII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Schulden
1b
2
2
Praktische Schulden
1b
Selbstreflexion, Retrospektive-Meetings
Prozesse verbessern, Fortbildung

36| 56
Best PractisesII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Schulden
1b
2
2
Praktische Schulden
1b
Selbstreflexion, Retrospektive-Meetings
Prozesse verbessern, Fortbildung
Werkzeug- bezogene
Schulden
1b
oder
2
Welche Tools haben wir,
welche werden vermisst,
und welche gibt es überhaupt noch?
Toolsmit Lizenzen bei Bedarf zu Verfügung stellen

37| 56
Best PractisesIII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Automations- bezogene
Schulden
1b
Ist die Kompilierung, Packetierung, Qualitäts- sicherung,der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert?
ContinuousIntegration,
ContinuousDelivery

38| 56
Best PractisesIII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Schulden
1b
ContinuousDelivery
Test-bezogene
Schulden
1b
Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung?
Vorgehensweisenwie z.B. TDD und BDD kultivieren,
für Automation sorgen

39| 56
Best PractisesIII
Erscheinungs- form
Buchh.-
Typ
Analyse
Gegenmaßnahme
Schulden
1b
ContinuousDelivery
Test-bezogene
Schulden
1b
Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung?
Vorgehensweisenwie z.B. TDD und BDD kultivieren,
für Automation sorgen
Betriebs-und
Produktions-
bezogene
Schulden
2
1a
Wie gut erfolgtdie Inbetrieb-nahme? Wie gut können Fehler in der Produktion analysiert werden?
DevOps
(Kommunikation fördern, gleiche Automationswege nutzen)

Einleitung
Zusammenfassung

41| 56
Tilgen oder Schulden zahlen?
Ein Qualitätsmodell:
oder
-
=
Kosten-
reduktion
Produktivitäts-
vorteil
Aufwand für
Qualitätsinvestitionen
-
=
Kosten-
reduktion
Nicht-Sanierungs-
kosten
Sanierungs-
kosten
Nach
„Qualitätsinvestitionen statt technischer Schulden“
im OBJEKTspektrumNr. 5 2014
Release 1
Release 2
Release 3
Release 4
entweder so:
oder so:

Es geht um das „Mindset Qualitätsinvestitionen“
„… es geht … nicht um stundengenaues Schätzen von Aufwänden“
„Meistens“ reicht es, wenn „Kosten und Nutzen … mit einer
Ordinalskala (gering < normal < hoch < sehr hoch) geschätzt
werden“
„In vielen Situationen reichen drei Fragen aus, um die Maßnahmen
… zu bestimmen:“
1. Welche Systemkomponenten werden oft geändert und wie ist
deren innere Qualität (i. Q.)?
2. Welche Maßnahmen zur Verbesserung der i. Q. bestehen …?
3. Welcher Nutzen steht diesen Investitionen … gegenüber?

43| 56
Schuldenberge bestaunen hilft alleine nicht weiter!
Deshalb die Empfehlung:
1.Technische Schulden bewusst machen und festhalten
2.Entscheiden mit welchen Qualitätsinvestitionen der größte Mehrwert erzielt werden kann und Ressourcen zur Realisierung bereitstellen
3. Umsetzung veranlassen und Ergebnisse von den Verantwortlichen einfordern
Begrüßung | Einleitung | Mögliche Kategorisierungen | Best-Practices | Tilgen oder Schulden zahlen?| Im größeren Kontext | Schlussteil

44| 56
Tilgungspläne
Release 1
Release 2
Release 3
Release 4
Keine Tilgung
Tilgungsplan A
Tilgungsplan B
+ einfaches Regressions-
testen
-Kein funktioneller
Fortschritt
+ kontinuierliche Verbesserung
der inneren Qualität
-Gefahr als Puffer für
funktionale Änderungen
zu dienen
Legende
Zinsen zahlen
Neue funktionale Änderungen
Schulden tilgen
Begrüßung | Einleitung | Mögliche Kategorisierungen | Best-Practices | Tilgen oder Schulden zahlen?| Im größeren Kontext | Schlussteil

Einleitung
Zusammenfassung

47| 56
Langfristig denken
ERROR

48| 56
Langfristiges Risiko ignorieren
Hauptsache mein Projekt läuft gut.
Projekt-Manager
Deliverin time!
Keep tothebudget!
Ob Schrott entsteht, ist egal.
Assureinternalquality!

49| 56
Wer ist hier der Boss?
Produktmanager
Projektmanager
Chance!
Risiko!
Kurzfristig gut!
Langfristig schlecht!
Time und Budget!
Innere
Qualität!
Technische
Schulden?

50| 56
Architektur
Design
Technologie
Code
Architektur
Design
Technologie
Code
Funktionalität
Testbarkeit
Wartbarkeit
Usability
Zuverlässigkeit
Modifizierbarkeit
Performanz
Sicherheit
Quelle : http://www.dadalos-d.org/frieden/images/eisberg-modell.jpg
Release- management
Deployment
Ressourceneffizienz
Kompatibilität
Portabilität
Äußere Qualität
Innere
Qualität

51| 56
Technische Schulden kurzfristig zurückzahlen
Zeit
Variante 2
(Verdeckter Kredit)
Variante 1
(Sichtbarer Kredit)
Release 1
Release 2

52| 56
Komplexität
in der Software
Effizienz in der
Softwareentwicklung
Technische Schulden i.w.S.
Best Practises
MittelfristigeKosten:
“…not-quite-right code counts as interest…”
LangfristigesRisiko:
“…can be brought to a stand-still under the debt load…”
KurzfristigeChance:
“A little debt speeds development..”
Zeitgewinn
Komplexität beherrschen
Zitatevon
Ward Cunningham
1992

Einleitung
Zusammenfassung

Zusammenfassung
Die Metapher „Technische Schulden“ ist und bleibt trotz ihrer Grenzen gut
Sie ist hilfreich das Problem „schlechter technischer Umsetzung“ zu
veranschaulichen und zu kommunizieren
Es gibt Schulden am Produkt, am Teamprozess und am ALM, für die
unterschiedliche Rollen verantwortlich sind
Es gibt unbewusste, halbbewusste und bewusste Schulden
Bewusste Schulden können gezielt verwaltet werden
Unbewusste und halbbewusste Schulden bringen ein unbekanntes oder
schwer abschätzbares Risiko mit sich
Manche Technische Schulden stellen eine große reale Gefahr für Projekte
und noch mehr für Produkte dar

Fazit
Schulden-Management:
Schulden bewusst machen und festhalten (Issue Tracker)
Mit gezielten Qualitätsinvestitionen risikoreiche Schulden abbauen
Schulden-Prophylaxe:
Langfristig denken und Schulden vermeiden (nur Notfall-Option)
Projektmanager auf messbare innere Qualität verpflichten
Doppelt und dreifach prüfen, ob ein möglicher Nutzen mögliche Risiken
den verschiedenen Stakeholdern (Produktmanager) wert sind
Knowhow der Mitarbeiter und Technologien in der Software nicht zu sehr
veralten lassen

Weiterführende Literatur
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://www.clean-code-developer.de
http://www.clean-coding-cosmos.de
https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt
http://www.construx.com/10x_Software_Development/Technical_Debt/
http://de.slideshare.net/jeffsch/beyond-technical-debt
http://martinfowler.com/bliki/DesignStaminaHypothesis.html
http://www.datacenter-insider.de/software-on-premise/
anwendungen/articles/459751/index3.html
http://jaxenter.de/artikel/Umgang-mit-technischen-Schulden-166985
http://clean-coding-cosmos.de/techdebts-1

59| 56
Projekte. Beratung. Spezialisten.

Mehr Softwarequalität: Technische Schulden

Weitere ähnliche Inhalte

Andere mochten auch

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH

Mehr Softwarequalität: Technische Schulden