Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Schluss mit Verschlimmbesserung

Schluss mit Verschlimmbesserung

Keynote am DevDay 2015, Dresden

Dr. Gernot Starke

May 27, 2015
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. 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 [email protected] www.arc42.de
  2. 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.    
  3. 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  
  4. 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 Configuration consists-of Goals Constraints impose ➤ has explicit and implicit ➤ complies with ➤ restrict ➤ ➤ aim42  domain  model  
  5. warum  diese  Trennung?   •  rich-g:     – wich6ge  Probleme

     lösen   •  schlechter:   – einfache  Probleme  lösen   •  ganz  schlecht:   – interessante  Problemlösungen  umsetzen   – Ak-onismus   €  
  6. profi-eren  vom  Problem,     haben  das  Problem  erschaffen,  

    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  
  7. Die  Mikroskop-­‐Falle   Wenn  Sie  NUR  im  Code  suchen,  

      werden  Sie  NUR  DORT  Probleme  finden...   im  Code  suchen  ist  rich-g  und  wich-g,  aber  NUR  dort  suchen  ist  fatal!  
  8. 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
  9. 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  
  10. Stakeholderanalyse   •  Stakeholder  kennen  Probleme   – nehmen  Probleme  aus

     ihrer  Perspek-ve  wahr   (subjek-v)   – nennen  o#mals  Symptome,  keine  Ursachen   – äußern  Vermutungen   •  Vorsicht:     – Gewöhnungseffekt   – Angst  vor  Änderung     Anwender,  Entwickler,  Support,   Fachleute,  BackOffice,  Architekten,   Betreiber,  Au#raggeber,  Tester,  Admins,   Projekt-­‐/Linienverantwortliche,   Controller,  CEO,  COO,  CFO  ...  
  11. 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!!  
  12. 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  
  13. Kontextanalyse  (1)   •  Fachlicher  Kontext   – System-­‐Scope   – Externe

     SchniYstellen   •  Daten-­‐Eingang   •  Daten-­‐Ausgang   •  UI   •  Events   •  Technischer  Kontext   – Kanäle   – Protokolle  
  14. Kontextanalyse  (2)   Mögliche  Risiken  im  Kontext:   •  Abhängigkeiten

     bzgl.  Qualitätszielen   –  Verfügbarkeit,  Robustheit,     –  Sicherheit   –  Kosten   –  Performance   •  Fehlende     SchniYstellen   Risiko  bzgl.   Performance-­‐   Anforderung  
  15. 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)  
  16. „Improve  Analyzability“   Verbessern  Sie  die  Möglichkeiten,     Probleme

     zu  finden!     •  zur  „Root-­‐Cause-­‐Analyse“   •  zum  Beweis  von  Vermutungen   •  Instrumen-erung,  z.B.   – (fachliches/technisches)  Logging   – Tracking  von  Qualitätseigenscha#en  
  17. Prozessanalyse   •  Anforderungsprozesse   –   erheben,  klären,  managen  

    •  Entwicklungs-­‐  /Entwurfsprozesse   – Architektur,  Implemen-erung,  Dokumenta-on   •  Betrieb   – Deployment,  Rollout,  Administra-on,  Monitoring   •  Management   – Team-­‐  und  Taskmanagement,  Risikomanagement  
  18. warum,  warum,  warum...   offshore-­‐   Dienstleister   Abnahme  erteilt,

      Basis  „Funk-onsprüfung“   Abnahmeprozess   auf  Durchsatz  op-miert   he#iges  Risiko   bzgl.  Verfügbarkeit  
  19. Sta-sche  Codeanalyse   •  Kopplung   •  Komplexität   • 

    Kohäsion  (inhaltlicher  Zusammenhang)   •  Konsistenz  (iden-sche  Probleme  ähnlich  gelöst)   •  Duplizierter  Code   •  Verletzung  von  Idiomen  (Style-­‐Checking)  
  20. Korrelierte  Codeanalyse   Abgleich  unterschiedlicher     Beobachtungen/Messungen    

    Beispiele:   •  Fehler  pro  Komponente  /  Subsystem   •  Benö-gte  Zeit  pro  Bugfix  pro  Komponente   •  Benö-gter  Aufwand  pro  Feature  pro   Komponente  
  21. Datenanalyse  (1)   •  Struktur   •  Typen   • 

    Zugriffe   –  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?  
  22. Laufzeitanalyse   •  Debugger   •  Logfile-­‐Analyse     • 

    Performance-­‐Analyse,  Profiling   •  Ressourcenverbrauch  zur  Laufzeit   •  Analyse  von  Benutzerverhalten   •  Analyse  fachlicher  Abläufe  
  23. Fazit:  Analyse  in  Vogelperspek-ve   Issues & Improvements system analyisis

    existing organization & processes existing system findings & 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 findings & suggestions 8 8
  24. Verbesserung  im  Großen...     Grundprinzipien,     Verhaltensregeln  

        kleine,  lokale   Verbesserungen       langfris6ge,  strategische   Ansätze     3   2   1   Fundamentals Approaches Practices
  25. 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 Butterfly Bridge To New Town Change By Extraction Change On Copy
  26. 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
  27. Big  Bang  (aka  Cold  Turkey)   Client Code Flawed System

    User 1 New System Client Code User Entwickle  ein  neues   System  parallel  zu   Betrieb  und  Pflege   des  alten.  
  28. 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  
  29. 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
  30. Change  By  Split  (2)   Client Type 1 Reduced to

    Type 1 Client Type 2 Reduced to Type 2 New Commons Op-miere  spezifische   Teilsysteme  („Splits“)   4 New Type 1 System Client Type 1 Client Type 2 New Commons New Type 2 System
  31. Change  By  Split   Vorgehen   1.  Iden-fiziere  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  
  32. 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
  33. 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  
  34. 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  
  35. 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
  36. Dr.  Gernot  Starke     [email protected]     hYp://gernotstarke.de  

    hYp://innoq.com     hYps://www.flickr.com/photos/foto_db/16000636092  
  37. 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  
  38. 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:    [email protected]