Technische Schulden: Risiko und Chance für mehr Softwarequalität

Transkript

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

2 Definition 1 Technische Schuld oder Technische (engl. technical debt) 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 Shipping first time code is is like like going into into debt. debt. A little A little debt debt speeds speeds development so long so as it long is paid as it back is paid back Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load Ward Cunningham: The WyCash Portfolio Management System. In: OOPSLA '92 Experience Report. 26. März 1992 Thementag , Technische 2 56 Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

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

4 Altlasten als langfristige Kostentreiber Summe realisierter Feature Mit Refactoring Verlorene Ressourcen Mit Technischen Amortisierungsgrenze Ward Cunningham: A little debt speeds development.. Zeit Ward Cunningham: stand-still under the debt load Nach

5 Grundidee Shipping first time code It is paid back Every minute spent on not-quite-right code Stand-still under the debt load Tilgung Zinsen Bankrott 500 Mrd $ * Bildnachweis: * Vom Marktforschungsunternehmen Gartner geschätzt für aktuellen den globalen IT-Altlastenberg ** Vom Wirtschaftsprüfungsunternehmen Deloitte geschätzt für Sourcecode-Fehlersuche in 2012 siehe

6 Strategisches Design 1. Niedrige Zinsen nutzen 2. Aktuelle Marktvorteile nutzen Thementag , Technische 6 56 Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

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

8 Definition 2 A) Technische Schuld im engeren Sinne ist die Summe aller Defizite einer Software, für die sich die Akteure bewusst (oder wenigstens halbbewusst) entschieden haben. Siehe B) Technische Schuld im weiteren Sinne ist die Summe aller Defizite einer Software, also alles, was dem Clean-Code-Gedanken widerspricht. Siehe Thementag , Technische 8 56 Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

9 Agenda Einleitung Kategorien von Technischen Best Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag , Technische 9 56 Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

10 Kategorien von Technischen 1. Bewusstseinsarten (Motivation, Einstellung) 2. Strategiesorten (Ziele, Planung) 3. Erscheinungsformen (Aussehen, Vorkommen) 4. Buchhaltungstypen (verwaltung, verantwortliche Rollen) Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

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

12 Bewusstseinsarten (Motivation, Einstellung) Sorglos Kurzsichtig Umsichtig Weitsichtig Bedacht Bewusst Unachtsam Unbewusst Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

14 Strategiesorten (Ziele, Planung) Ein großes Defizit Viele kleine Defizite Strategische Langzeit- Taktische Kurzzeit- Unbewusste Bewusste Nach Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

15 Strategiesorten (Ziele, Planung) Grobgranular Feingranular Langzeit- Wir realisieren kein Continuous Delivery solange der Kunde mit der Auslieferungsdauer zufrieden ist Solange wir keine größeren Probleme mit der alten Technologie bekommen, stellen wir unsere Komponenten nicht um. Kurzzeit- Wir testen jetzt noch unregelmäßig und erkennen viele Fehler zu spät. Ab der übernächsten Auslieferung nutzen wir Continuous Integration. Unser Sourcecode-Analysetool (Sonar) meldet über 100 Probleme in unseren Sourcen. Nach der übernächsten Auslieferung müssen die behoben werden. Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

17 Erscheinungsformen (Aussehen, Vorkommen) Organisatorische Prozess-bezogene Persönliche Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

18 Persönliche z. B. mangelnde Motivation der Akteure Neues zu lernen, auszuprobieren und sich an Neues anzupassen Organisatorische z. B. veraltete hierarchische Organisationsstrukturen (Gesetz von Conway) Prozess-bezogenen z. B. Anwendung von veralteten Vorgehensmodellen Mehr Informationen dazu unter Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

19 Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Test-bezogene Praktische Organisatorische Prozess-bezogene Persönliche Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

20 Praktische z. B. nicht aus gemachten Fehlern lernen Werkzeug-bezogene z. B. zu großer Wildwuchs an eingesetzten Werkzeugen Automations-bezogene z. B. keine automatische Testausführung (Continuous Integration) Test-bezogene z. B. unzureichende Testabdeckung der implementierten Funktionalität Mehr Informationen dazu unter

21 Kommunikationsschulden Unzureichende Kommunikation und Zusammenarbeit zwischen den Akteuren (vor allem zwischen Akteuren verschiedener Phasen im ALM) Application Lifecycle Management Administrator Kundenakzeptanztester Architekt / Entwickler Anforderungsanalyst Domänen- Experte Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

22 Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Organisatorische Persönliche Test-bezogene Betriebs-bezogene AM-bezogene Produkt-bezogene Fachseitebezogene Produktions-bezogene Implementierungsschulden Architekturschulden Kommunikationsschulden Prozess-bezogene Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

23 Produktions-bezogene z. B. mangelnde Analysierbarkeit (Logging, Protokollierung, Monitoring) Architekturschulden z. B. mangelnde Berücksichtigung nicht-funktionaler Qualitätskriterien Implementierungsschulden z. B. Code-Vervielfachungen Mehr Informationen dazu unter Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

24 Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Organisatorische Persönliche Test-bezogene Betriebs-bezogene AM-bezogene Produkt-bezogene Fachseitebezogene Produktions-bezogene Implementierungsschulden Architekturschulden Kommunikationsschulden Prozess-bezogene Hauptverantwortung beim Entwicklungsteam Verteilte Verantwortung

26 Buchhaltungstypen (verwaltung) Produkt-bezogene bü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 bücher : Projektdokumentation (Projekt-Handbuch, Retrospektive-Bericht) Dokumentation der ALM-Architektur (Leitfaden für die Unternehmenskultur, Beschreibung der Konzernstruktur) konto: Issue Tracker (Jira, Bugzilla, ) Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

27 Buchhaltungstypen (verantwortliche Rollen) Techn. Projektleiter Typ 1: Projekt Typ 2: ALM Hauptverantwortung bei Entwicklungsteam Verteilte Verantwortung Typ 1a: Produkt Typ 1b: Teamprozesse Rahmenprozesse SW-Architekt Entwicklungsteam Produktmanager Product Owner Projektmanager Entwicklungsteam Scrum-Master Gesamtentwicklungsleiter Produktmanager Projektmanager Scrum-Master

28 Agenda Einleitung Kategorien von Technischen Best Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

29 Best Practice No. 1 Bekannte Probleme in einem Issue Tracker festhalten! Am besten nach Strategiesorte, Erscheinungsform und Buchhaltungstyp getrennt! Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

30 Best Practices I Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Implementierung 1a Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien* anwenden * Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

31 Best Practices I Implementierung Erscheinungsform Buchh.- Typ 1a Analyse Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Architektur 1a Gute Architektur- Dokumentation (arc42) ( ATAM Gegenmaßnahme Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien* anwenden Entworfene Architektur sauber umsetzen, schlechte Architektur ändern ( * Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

32 Best Practices I Implementierung Erscheinungsform Buchh.- Typ 1a Analyse Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Architektur 1a Gute Architektur- Dokumentation (arc42) ( ATAM Persönliche Gegenmaßnahme Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien* anwenden Entworfene Architektur sauber umsetzen, schlechte Architektur ändern ( alle Selbstreflexion Motivation fördern (Fortbildungen, Teamstimmung) * Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

33 Best Practices II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

34 Best Practices II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Praktische 1b Selbstreflexion, Retrospektive-Meetings Prozesse verbessern, Fortbildung Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

35 Best Practices II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Praktische 1b Selbstreflexion, Retrospektive-Meetings Prozesse verbessern, Fortbildung Werkzeugbezogene 1b oder 2 Welche Tools haben wir, welche werden vermisst, und welche gibt es überhaupt noch? Tools mit Lizenzen bei Bedarf zu Verfügung stellen Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

36 Best Practices III Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Automationsbezogene 1b Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Continuous Integration, Continuous Delivery Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

37 Best Practices III Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Automationsbezogene 1b Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Continuous Integration, Continuous Delivery Test-bezogene 1b Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung? Vorgehensweisen wie z.b. TDD und BDD kultivieren, für Automation sorgen Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

38 Best Practices III Automationsbezogene Test-bezogene Betriebs- und Produktionsbezogene Erscheinungsform Buchh.- Typ 1b 1b 2 1a Analyse Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung? Wie gut erfolgt die Inbetriebnahme? Wie gut können Fehler in der Produktion analysiert werden? Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil Gegenmaßnahme Continuous Integration, Continuous Delivery Vorgehensweisen wie z.b. TDD und BDD kultivieren, für Automation sorgen DevOps (Kommunikation fördern, gleiche Automationswege nutzen)

40 Tilgen oder zahlen? Ein Qualitätsmodell: = Kostenreduktion Produktivitätsvorteil - Aufwand für Qualitätsinvestitionen oder = - Kostenreduktion Nicht-Sanierungskosten Sanierungskosten entweder so: Nach Qualitätsinvestitionen statt technischer im OBJEKTspektrum Nr oder so: Thementag , Technische Release 1 Release 2 Release 3 Release 4

41 Tilgen oder zahlen? 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? Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

42 Tilgen oder zahlen? berge bestaunen hilft alleine nicht weiter! Deshalb die Empfehlung: 1. Technische 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 Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

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

45 Zeitdruck Rahmenbedingungen Mangelnde Kommunikation Technische Fehlendes Wissen Technologischer Fortschritt Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

46 Langfristig denken ERROR

47 Langfristiges Risiko ignorieren Assure internal quality! Deliver in time! Keep to the budget! Ob Schrott entsteht, ist egal. Hauptsache mein Projekt läuft gut. Projekt-Manager Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

48 Wer ist hier der Boss? Risiko! Langfristig schlecht! Technische? Kurzfristig gut! Chance! Innere Qualität! Time und Budget! Produktmanager Projektmanager Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

49 Quelle : Usability Sicherheit Funktionalität Performanz Zuverlässigkeit Äußere Qualität Wartbarkeit Deployment Modifizierbarkeit Architektur Design Design Releasemanagement Ressourceneffizienz Technologie Architektur Code Code Testbarkeit Portabilität Kompatibilität Technologie Innere Qualität Thementag , Technische 49 56

50 Technische kurzfristig zurückzahlen Variante 1 (Sichtbarer Kredit) Variante 2 (Verdeckter Kredit) Release 1 Zeit Release 2

51 Komplexität beherrschen Komplexität in der Software Zitate von Ward Cunningham 1992 Langfristiges Risiko: can be brought to a stand-still under the debt load Effizienz in der Softwareentwicklung Mittelfristige Kosten: not-quite-right code counts as interest Best Practices Technische i.w.s. Zeitgewinn Kurzfristige Chance: A little debt speeds development.. Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

53 Zusammenfassung Die Metapher Technische ist und bleibt trotz ihrer Grenzen gut Sie ist hilfreich das Problem schlechter technischer Umsetzung zu veranschaulichen und zu kommunizieren Es gibt am Produkt, am Teamprozess und am ALM, für die unterschiedliche Rollen verantwortlich sind Es gibt unbewusste, halbbewusste und bewusste Bewusste können gezielt verwaltet werden Unbewusste und halbbewusste bringen ein unbekanntes oder schwer abschätzbares Risiko mit sich Manche Technische stellen eine große reale Gefahr für Projekte und noch mehr für Produkte dar Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

54 Fazit -Management: bewusst machen und festhalten (Issue Tracker) Mit gezielten Qualitätsinvestitionen risikoreiche abbauen -Prophylaxe: Langfristig denken und 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 Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

55 Weiterführende Literatur Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

56 Fragen Thementag , Technische Einleitung Mögliche Kategorisierungen Best Practices Tilgen oder zahlen? Im größeren Kontext Schlussteil

57

58 Projekte. Beratung. Spezialisten. Thementag , Technische 58 56