Schluss mit Verschlimmbesserung

Keynote am DevDay 2015, Dresden

Transcript

1. Schluss  mit   Verschlimmbesserung   So#ware-­‐Evolu-on,  aber  rich-g   Dr.  Gernot  Starke   DevDay-­‐DD  
2. 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
3. Der  Normalfall...  
4. 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.    
6. 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  
7. im  normalen  Leben...   analyze evaluate improve
8. 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  
9. warum  diese  Trennung?   •  rich-g:     – wich6ge  Probleme  lösen   •  schlechter:   – einfache  Probleme  lösen   •  ganz  schlecht:   – interessante  Problemlösungen  umsetzen   – Ak-onismus   €  
10. Die  Rela-vitäts-­‐Falle   Des  Einen  Problem  ist   des  Anderen  Freund  
12. 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  
13. 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!  
14. hYps://www.flickr.com/photos/jonasb/24341322  
15. hYps://www.flickr.com/photos/emiliano-­‐iko/5354414276  
16. 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
17. 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  
18. 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  ...  
19. 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!!  
20. 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  
21. Kontextanalyse  (1)   •  Fachlicher  Kontext   – System-­‐Scope   – Externe  SchniYstellen   •  Daten-­‐Eingang   •  Daten-­‐Ausgang   •  UI   •  Events   •  Technischer  Kontext   – Kanäle   – Protokolle  
22. Kontextanalyse  (2)   Mögliche  Risiken  im  Kontext:   •  Abhängigkeiten  bzgl.  Qualitätszielen   –  Verfügbarkeit,  Robustheit,     –  Sicherheit   –  Kosten   –  Performance   •  Fehlende     SchniYstellen   Risiko  bzgl.   Performance-­‐   Anforderung  
23. 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)  
24. „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  
25. Prozessanalyse   •  Anforderungsprozesse   –   erheben,  klären,  managen   •  Entwicklungs-­‐  /Entwurfsprozesse   – Architektur,  Implemen-erung,  Dokumenta-on   •  Betrieb   – Deployment,  Rollout,  Administra-on,  Monitoring   •  Management   – Team-­‐  und  Taskmanagement,  Risikomanagement  
26. warum,  warum,  warum...   offshore-­‐   Dienstleister   Abnahme  erteilt,   Basis  „Funk-onsprüfung“   Abnahmeprozess   auf  Durchsatz  op-miert   he#iges  Risiko   bzgl.  Verfügbarkeit  
27. Sta-sche  Codeanalyse   •  Kopplung   •  Komplexität   •  Kohäsion  (inhaltlicher  Zusammenhang)   •  Konsistenz  (iden-sche  Probleme  ähnlich  gelöst)   •  Duplizierter  Code   •  Verletzung  von  Idiomen  (Style-­‐Checking)  
28. 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  
29. Korrelierte  Codeanalyse  (2)  
30. 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?  
31. Laufzeitanalyse   •  Debugger   •  Logfile-­‐Analyse     •  Performance-­‐Analyse,  Profiling   •  Ressourcenverbrauch  zur  Laufzeit   •  Analyse  von  Benutzerverhalten   •  Analyse  fachlicher  Abläufe  
32. 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
33. Verbesserung  im  Großen...     Grundprinzipien,     Verhaltensregeln       kleine,  lokale   Verbesserungen       langfris6ge,  strategische   Ansätze     3   2   1   Fundamentals Approaches Practices
34. 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
35. 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
36. 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.  
37. 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  
38. 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
39. 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
40. 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  
41. 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
42. 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  
43. 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  
44. 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
45. Fazit  (1)  
    42 Führe     •  Problem-­‐Liste  und     •  Improvement-­‐Backlog  
46. Fazit  (2)  
    42 Vorsicht:  Mikroskop-­‐Falle  
47. Fazit  (3)  
    42 Vorsicht:  neue  Feinde...                              
48. Dr.  Gernot  Starke     gs@gernotstarke.de     hYp://gernotstarke.de   hYp://innoq.com     hYps://www.flickr.com/photos/foto_db/16000636092  
49. Projekt  
    42
50. 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  
51. Website   Whitepaper  
52. Code:  github  
53. Issues:  viele...  
54. Contributors...   Beiträge     willkommen!
55. 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