Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbare Software.pdf
0 gefällt mir31 aufrufe
Das Dokument beschreibt neun Hacks zur Verbesserung der Wandelbarkeit von Software und betont die Notwendigkeit von Modularisierung, Simplifizierung und effektiver Dokumentation. Es thematisiert Herausforderungen wie Softwarealterung und technische Schulden und schlägt organisatorische Ansätze vor, um Kommunikation und Teamarbeit zu optimieren. Zudem wird auf die Bedeutung von adaptive Designansätzen und Innovationsförderung innerhalb von Softwareentwicklungsteams hingewiesen.
![Isomorphe Struktur
Teams
Modularisierung
+
„Organisationen, die Systeme entwerfen, […] sind gezwungen,
Entwürfe zu erstellen, die die Kommunikationsstrukturen
dieser Organisationen abbilden.“ – Melvin Conway
Avatare: freepik.com
Conways Law
Sales Support Backoffice
Cross Functional Teams
Product Owner
Tech. Owner
Developer (Biz, UX, Code , Ops)
Technische
Produktlandschaft
Team A Team B](https://image.slidesharecdn.com/thementag202306diesesmalmachenwirallesrichtig-9hacksfurwandelbaresoftware-231016084038-b54ef40b/85/Thementag-2023-06-Dieses-Mal-machen-wir-alles-richtig-9-Hacks-fur-wandelbare-Software-pdf-23-320.jpg)
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbare Software.pdf
- 1. Dieses Mal machen wir alles richtig! Wie wir mit 9 Hacks die Wandelbarkeit von Software verbessern IKS Gesellschaft für Information-und Kommunikationssysteme GmbH T. +49 2103-5872-0 | www.iks-gmbh.com Projekte. Beratung. Spezialisten.
- 5. Software altert • Technische Schulden • Schnelle Lieferung bewusst priorisiert • Suboptimale Strukturen wider besseren Wissens • Können Evolvierbarkeit erschweren • Softwarealterung ist unvermeidbar
- 11. Teams wechseln 2010 2014 2018 Our “algorithm” is overly complex & not fully understood internally. People will discover many silly things , but we’ll patch issues as soon as they’re found! – Elon Musk 2023
- 12. Wo können wir ansetzen? Konzeption & Design Herstellung Teams
- 13. Konzeption & Design Herstellung Teams Anti Aging - Was können wir tun? Modularisierung Simplifizierung Dokumentation
- 14. BI Partner Risiko Sales GF Aufbauorganisation Domäne zuerst Konzeption & Design Technik Modularisierung +
- 15. Strategisch, fachliches Design BI Partner Risiko Sales GF Konzeption & Design Modularisierung +
- 16. YAGNI + MVP Minimal viable Product, … viable Experiment, … awesome Product Build Measure Learn Rule of Ten Konzeption & Design Simplifizierung Sense & Respond Mindset +
- 17. Visualisierung • Visualisierung als Werkzeug • Standards verwenden, z.B. Arch42 • Co-Creation erhöht Verständlichkeit • Neue Mitarbeiter als Supertester Architektur Arc42 ! Konzeption & Design Dokumentation +
- 18. Softwaredesign Package Interface Service API Application Webcomponent Attributes Events, … Self contained system Artefakt Repo Backend Frontend Herstellung Modularisierung +
- 19. Paketierung V1 V1 V1 V1 V1 V1 V1 V1 V2 V3 V3 V4 V1 Pakete package hello; Artefakte hello.jar Repos git clone …/hello Images kubectl apply hello.yaml Komplexität 1 Komplexität 2 Komplexität 3 Komplexität 1000 • Angemessenes , evolvierbares Design • Thinnest possible plattform Herstellung Simplifizierung +
- 20. KISS Prinzip Konstruktive Kontroverse - Beispiele • Brauchen wir Framework X wirklich? • Welche Nachteile bringt das Eventdriven Paradigma? • Müssen wir zusätzlich Mongo DB einsetzen? • Wird die Qualität durch 80% Testcoverage wirklich besser? • Können wir einen Low Code Ansatz verfolgen? Erfordert Offenheit, Mut, Respekt Achtung: Mode & Groupthink Herstellung Simplifizierung +
- 21. DBBYC Prinzip • Don‘t build just because you can • Dienen Design und Architektur dem Ziel? Selbstreflektion - Mache ich es weil… … ich Lust darauf habe? … mich andere für smarter halten? … es meine Reputation steigert? Herstellung Simplifizierung +
- 22. Dokumentation as Code • Konzept = Code • API First design • APIs mit OpenAPI, AsyncAPI • Modelle mit Plantuml • Visualsierter Code Herstellung Dokumentation +
- 23. Isomorphe Struktur Teams Modularisierung + „Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“ – Melvin Conway Avatare: freepik.com Conways Law Sales Support Backoffice Cross Functional Teams Product Owner Tech. Owner Developer (Biz, UX, Code , Ops) Technische Produktlandschaft Team A Team B
- 24. Teamgröße Teams Simplifizierung + n=2 K=1 K = n(n-1)/2 n=3 K=3 n=4 K=6 Teamgröße n Kommunikationsbeziehungen K Aufwand für Kommunikation n=5, K=10, Zeit = 1,6 Stunden n=7, K=21, Zeit = 3,5 Stunden n=9, K=36, Zeit = 6,0 Stunden
- 25. Kognitive Last Teams Simplifizierung + Team A Team B Team C Intrinsisch (Skill) = Handwerkszeug Extraneous (Mechanismus) = Orga, Deployment Germane (Domain focus) = Kunde, Domäne
- 26. Autonomie Unabhängigkeit fördern • Vollständige Autonomie • Shared nothing (Team und Codebase) Koordination und Flow verbessern • Kooperation organisieren • Priorisierung gemeinsamer Initiativen Teams Simplifizierung +
- 27. Langlebige Teams • Kontextwissen ist kaum zu dokumentieren • Starkes Lernen ermöglichen (Motivation sticht Expertenskill) • Kopfmonopole vermeiden (Pairing) • Viele Fähigkeiten (BizDevsOps) • Modernisierung als Auftrag • Mindset: Dokumentieren für die, die nach uns kommen Teams +
- 28. Konzeption & Design Herstellung Teams Fazit Modularisieren Simplifizieren Dokumentieren