Schluss mit Verschlimmbesserung

Slide 1

Slide 1 text

Schluss mit Verschlimmbesserung So#ware-‐Evolu-on, aber rich-g Dr. Gernot Starke DevDay-‐DD

Slide 2

Slide 2 text

Dr. Gernot Starke innoQ Fellow   Softwarearchitekturen Entwurf, Entwicklung, Management Evolution & Modernisierung Training   Mentoring und Coaching Analyse und Optimierung von Entwicklungsprozessen   Reviews, Audits, Retrospektiven +49 177 – 728 2570 gs@gernotstarke.de www.arc42.de

Slide 3

Slide 3 text

Der Normalfall...

Slide 4

Slide 4 text

Normalfall (2) Management: Zu teuer. Zu viele Fehler. Zu hohe Aufwände. Zu lange Time-‐to-‐Market. Techniker:-‐-‐-‐ Zu hohe technische Schuld. Zu wenig Verbesserung. Technologie zu schlecht. Zu wenig Innova-on. Zu wenig Budget. Zu wenig Zeit.

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

View-‐Pipeline (Apache Cocoon) Theorie: •  Separa-on of Concern Praxis: •  XSLT-‐Hölle •  Transformer ändern Daten •  Enge Kopplung der Filter (Steps) Step-1 Step-2 Step-3 Data Source-1 read Appl- Core-Old read / write Step-4 Appl- Services read hYp://cocoon.apache.org/2.1/userdocs/concepts/index.html

Slide 7

Slide 7 text

im normalen Leben... analyze evaluate improve

Slide 8

Slide 8 text

Systema-sch verbessern... Trenne „Probleme“ und „Lösungsvorschläge“ UID Description Cost Frequency Issue UID Description Cost Improvement 1..* * resolve ➤ resolved by ➤ Name System suffers from is remedy for UID Description Cost Frequency Issue Probability EarlyWarning Risk Cause UID Description Cost Improvement 1..* * resolve ➤ resolved by ➤ modify or create ➤ is real source of ➤ * * * * Name System Name Role Interests Experience Stakeholder Software Hardware Process Name Organization Documentation knows / informs about ➤ knows / informs about ➤ source of ➤ source of ➤ suffers from ➤ is remedy for Conﬁguration consists-of Goals Constraints impose ➤ has explicit and implicit ➤ complies with ➤ restrict ➤ ➤ aim42 domain model

Slide 9

Slide 9 text

warum diese Trennung? •  rich-g: – wich6ge Probleme lösen •  schlechter: – einfache Probleme lösen •  ganz schlecht: – interessante Problemlösungen umsetzen – Ak-onismus €

Slide 10

Slide 10 text

Die Rela-vitäts-‐Falle Des Einen Problem ist des Anderen Freund

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

proﬁ-eren vom Problem, haben das Problem erschaﬀen, greifen Sie und Ihre Vorschläge an sind am Problem schuld, stehen zu Ihnen in Konkurrenz, greifen Ihre Kompetenz an leiden nicht am Problem, leiden unter dessen Lösung tragen (Teil-‐)Schuld am Problem zweifeln Schlussfolgerungen an, zweifeln Ihre Kompetenz an, haben Angst vor Veränderung

Slide 13

Slide 13 text

Die Mikroskop-‐Falle Wenn Sie NUR im Code suchen, werden Sie NUR DORT Probleme ﬁnden... im Code suchen ist rich-g und wich-g, aber NUR dort suchen ist fatal!

Slide 14

Slide 14 text

hYps://www.ﬂickr.com/photos/jonasb/24341322

Slide 15

Slide 15 text

hYps://www.ﬂickr.com/photos/emiliano-‐iko/5354414276

Slide 16

Slide 16 text

Bauch – Beine – Po: Wo liegen die IT-‐Problemzonen? Legende Qualitative Analyse (ATAM) Context Analysis Issue Tracker Analysis Data Analysis Documentation Analysis Runtime Analysis Requirements Analysis Software Archeology Static Code Analysis Development Process Analysis Infrastructure Analysis User Analysis Stakeholder Analysis wichtig abhängig von

Slide 17

Slide 17 text

Probleme sammeln!! ID Beschreibung Häufigkeit Wert (min) Wert (max) Abhilfen PD-‐ 1 Falsche Berechnung Ar-kelpreis bei Kombina-on aus RabaYkarte, Einzelkunde und yxz-‐Konfigura-on zZt 3-‐5x pro Woche 110€ 550€ V-‐1 + V-‐2 PZ-‐ 1 Zu lange Warteschlangen (queues) in Entwicklungs-‐ prozess: wai-ng-‐-me für neue Anforderungen >6W 30x / Woche 300€ 15.000 € V-‐3 C-‐1 Zeit zur Iden-fika-on + Behebung von Laufzeitehlern zu lang (bis zu 5 T bei kri-schen Fehlern) 1x / Woche V-‐4 || V-‐3 C-‐2 Zeit für kompleYen Test der Anwendung > 10 T 4 x / Jahr V-‐4 Werkzeuge: •  (gut) Issue-‐Tracker (Voraussetzung: stabile URL‘s) •  (ok) Excel, Karteikarten, Flipchart •  (schlecht) Kopf

Slide 18

Slide 18 text

Stakeholderanalyse •  Stakeholder kennen Probleme – nehmen Probleme aus ihrer Perspek-ve wahr (subjek-v) – nennen o#mals Symptome, keine Ursachen – äußern Vermutungen •  Vorsicht: – Gewöhnungseﬀekt – Angst vor Änderung Anwender, Entwickler, Support, Fachleute, BackOﬃce, Architekten, Betreiber, Au#raggeber, Tester, Admins, Projekt-‐/Linienverantwortliche, Controller, CEO, COO, CFO ...

Slide 19

Slide 19 text

Stakeholder-‐Interviews (1) •  Breitensuche: Unterschiedliche Stakeholder – Mindestens: Anwender, Fachexperten, Entwickler, Support-‐Mitarbeiter, Tester, Betreiber, Manager •  Ungestörtes Umfeld – insbesondere: ohne Vorgesetzte – garan-erte Vertraulichkeit •  Keine unhaltbaren Versprechungen geben!!

Slide 20

Slide 20 text

Stakeholder-‐Interviews (2) •  Vorbereitung: individueller Vorab-‐Fragebogen – Zeigt Hochachtung vor Gesprächspartner – Siehe: hYp://aim42.github.io/#Stakeholder-‐Interview •  Fragen nach: – Problemen + Lösungsmöglichkeiten bezüglich •  System, •  Prozesse, •  Organisa-on

Slide 21

Slide 21 text

Kontextanalyse (1) •  Fachlicher Kontext – System-‐Scope – Externe SchniYstellen •  Daten-‐Eingang •  Daten-‐Ausgang •  UI •  Events •  Technischer Kontext – Kanäle – Protokolle

Slide 22

Slide 22 text

Kontextanalyse (2) Mögliche Risiken im Kontext: •  Abhängigkeiten bzgl. Qualitätszielen –  Verfügbarkeit, Robustheit, –  Sicherheit –  Kosten –  Performance •  Fehlende SchniYstellen Risiko bzgl. Performance-‐ Anforderung

Slide 23

Slide 23 text

Kontextanalyse (3) Mögliche Risiken im Kontext: •  Vola-le Nachbarsysteme Risiko / Problem bzgl. Stabilität der SchniYstelle Unser System Anderes (innova-ves) Projekt / System getImportantData( customerID)

Slide 24

Slide 24 text

„Improve Analyzability“ Verbessern Sie die Möglichkeiten, Probleme zu ﬁnden! •  zur „Root-‐Cause-‐Analyse“ •  zum Beweis von Vermutungen •  Instrumen-erung, z.B. – (fachliches/technisches) Logging – Tracking von Qualitätseigenscha#en

Slide 25

Slide 25 text

Prozessanalyse •  Anforderungsprozesse –  erheben, klären, managen •  Entwicklungs-‐ /Entwurfsprozesse – Architektur, Implemen-erung, Dokumenta-on •  Betrieb – Deployment, Rollout, Administra-on, Monitoring •  Management – Team-‐ und Taskmanagement, Risikomanagement

Slide 26

Slide 26 text

warum, warum, warum... oﬀshore-‐ Dienstleister Abnahme erteilt, Basis „Funk-onsprüfung“ Abnahmeprozess auf Durchsatz op-miert he#iges Risiko bzgl. Verfügbarkeit

Slide 27

Slide 27 text

Sta-sche Codeanalyse •  Kopplung •  Komplexität •  Kohäsion (inhaltlicher Zusammenhang) •  Konsistenz (iden-sche Probleme ähnlich gelöst) •  Duplizierter Code •  Verletzung von Idiomen (Style-‐Checking)

Slide 28

Slide 28 text

Korrelierte Codeanalyse Abgleich unterschiedlicher Beobachtungen/Messungen Beispiele: •  Fehler pro Komponente / Subsystem •  Benö-gte Zeit pro Bugﬁx pro Komponente •  Benö-gter Aufwand pro Feature pro Komponente

Slide 29

Slide 29 text

Korrelierte Codeanalyse (2)

Slide 30

Slide 30 text

Datenanalyse (1) •  Struktur •  Typen •  Zugriﬀe –  Read / write •  Volumen –  auch von Query-‐Results + Indizes •  Inhalte –  Korrektheit –  Schutzbedarf •  Durchsatz -‐> Laufzeitanalyse Struktur / Typen ungeeignet für das Problem Wonach ist Persistenz op-miert, read oder write? Haben wir besonders viel / groß von etwas? Haben wir falsche Daten?

Slide 31

Slide 31 text

Laufzeitanalyse •  Debugger •  Logﬁle-‐Analyse •  Performance-‐Analyse, Proﬁling •  Ressourcenverbrauch zur Laufzeit •  Analyse von Benutzerverhalten •  Analyse fachlicher Abläufe

Slide 32

Slide 32 text

Fazit: Analyse in Vogelperspek-ve Issues & Improvements system analyisis existing organization & processes existing system ﬁndings & suggestions stakeholder interviews stakeholder analysis development process development process analysis collected issues, suggested improvements collected issues, suggested improvements collected issues, suggested improvements collected issues, suggested improvements Stakeholders ﬁndings & suggestions 8 8

Slide 33

Slide 33 text

Verbesserung im Großen... Grundprinzipien, Verhaltensregeln kleine, lokale Verbesserungen langfris6ge, strategische Ansätze 3 2 1 Fundamentals Approaches Practices

Slide 34

Slide 34 text

Langfris-ge Ansätze... Determine Improvement Approach Strangulate Bad Parts Big Bang (Cold Turkey) Frontend Switch Keep Data, Toss Code Managed Evolution Change Via Split Data Migration Branch by Abstraction Chicken Little Butterﬂy Bridge To New Town Change By Extraction Change On Copy

Slide 35

Slide 35 text

Daten erhalten oder nicht? Wesentliche Entscheidung: Welche Daten müssen erhalten bleiben? Big Understructured Mess Very Valuable Data Big Understructured Mess Very Va Da alu ble at Valu ata alu ble at uable ta Big Understructured Mess Very Valuable Data

Slide 36

Slide 36 text

Big Bang (aka Cold Turkey) Client Code Flawed System User 1 New System Client Code User Entwickle ein neues System parallel zu Betrieb und Pﬂege des alten.

Slide 37

Slide 37 text

Big-‐Bang Vorgehen 1.  Spezifiziere neues System 2.  Entwerfe und implemen-ere neues System 3.  Nach Fer-gstellung & Abnahme werden Benutzer und Clients auf neues System umgestellt Risiken •  Spezifika-on aufgrund der Komplexität des alten Systems lücken-‐ oder fehlerha# •  Know-‐How-‐Flucht: Demo-vierte Mitarbeiter des alten Systems •  Das neue System vermeidet zwar bekannte Fehler, enthält jedoch neue •  Business erhält lange Zeit (Jahre!) keine signifikanten neuen Features •  Schwierige, aufwändige Datenmigra-on

Slide 38

Slide 38 text

Change By Split Client Type 1 Flawed System Client Type 2 Kopiere für alle Client-‐Typen 1 Client Type 1 Flawed System Client Type 2 Flawed System Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 Commons Reduziere und extrahiere Gemeinsamkeiten 2 Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Op-miere Gemeinsamkeiten 3

Slide 39

Slide 39 text

Change By Split (2) Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Op-miere speziﬁsche Teilsysteme („Splits“) 4 New Type 1 System Client Type 1 Client Type 2 New Commons New Type 2 System

Slide 40

Slide 40 text

Change By Split Vorgehen 1.  Iden-ﬁziere mehrere Benutzergruppen BG 2.  Klone gesamtes System für jede BG 3.  Reduziere für jede BG, extrahiere Gemeinsamkeiten (technische Basis) 4.  Op-miere für jede BG Risiken •  Gemeinsamkeiten schwer zu isolieren •  Mehrere Teams benö-gt (1 pro Klon + Basis) Voraussetzungen •  stark unterschiedliche Benutzergruppen

Slide 41

Slide 41 text

Strangulate Bad Parts (1) Ersetze einige schlechte Teile Ersetze weitere schlechte Teile Und noch mehr... 1 2 3 Client Code Flawed System User Client Code Flawed System User better Client Code Flawed System User better Better System Client Code User Flawed Parts

Slide 42

Slide 42 text

Strangulate Bad Parts Vorgehen 1.  Ersetze im bestehenden System sukzessive einzelne Komponenten Risiken •  Nebenwirkungen innerhalb des Systems schwer zu testen •  Hohe Aufwände, um übergangsweise mit „Altlasten“ zu arbeiten Voraussetzungen •  interne SchniYstellen / Modularisierung

Slide 43

Slide 43 text

Improve Processes Improve Iteratively Reduce Complexity Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Verify After Every Change Fast Feedback Explicit Assumptions Group Improvement Actions Prototype Improvement Übersicht: Prak-ken Fundamentals Approaches Practices Breites Spektrum an Op-onen

Slide 44

Slide 44 text

Improve Processes Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Improve Code Structure Introduce Interfaces Refactor Code Untangle Code Remove Nested Control Structures Deprecate Obsolete Parts Improve Responsibility Improve Code Layout Move Behavior Close To Data Split Up Oversized Parts Handle If-Else Chains Interface Segregation Anticorruption Layer Hide Unmaintainable Code Extract Reusable Component Integrate Reusable Component Remove Unused Parts Eliminate Navigation Code Toggle Feature Restructure Code Isolate Parts (Modularize) Prepare Change Break Dependencies

Slide 45

Slide 45 text

Fazit (1) 42 Führe •  Problem-‐Liste und •  Improvement-‐Backlog

Slide 46

Slide 46 text

Fazit (2) 42 Vorsicht: Mikroskop-‐Falle

Slide 47

Slide 47 text

Fazit (3) 42 Vorsicht: neue Feinde...

Slide 48

Slide 48 text

Dr. Gernot Starke gs@gernotstarke.de hYp://gernotstarke.de hYp://innoq.com hYps://www.ﬂickr.com/photos/foto_db/16000636092

Slide 49

Slide 49 text

Projekt 42

Slide 50

Slide 50 text

Prak-sch eingesetzt... ‣  2014: – Logis-k-‐Konzern (Audit Online-‐Sales System, >1MLOC) – ERP-‐Hersteller (Audit und Rebuild Kernsystem, 2 MLOC) – Finanzdienstleister, Modernisierung Core, 500kLOC •  Automo-ve: „Mul-media-‐Framework“ •  Rail-‐Service „Infrastruktur“ •  Mobilfunk „Billing“ •  Airport-‐Opera-ons „Luggage Handling“ •  Systemso#ware für Maschinenbau / LebensmiYelindustrie

Slide 51

Slide 51 text

Website Whitepaper

Slide 52

Slide 52 text

Code: github

Slide 53

Slide 53 text

Issues: viele...

Slide 54

Slide 54 text

Contributors... Beiträge willkommen!

Slide 55

Slide 55 text

Contribu-ons welcome •  Method guide: http://aim42.github.io – Source: hYps://github.com/aim42/aim42 •  https://github.com/aim42/aim42/ issues •  TwiYer: @arc_improve42 •  Mailing list: aim42@lists.innoq.com