The Art of Software Reviews

Jede Software besitzt "Potential", also "besser geht immer". Aber bevor wir anfangen, wild an unseren Systemen zu verschlimmbessern, benötigen wir zuerst einen ordentlichen Überblick über dessen Stärken und Schwächen.

Der Vortrag zeigt methodisches Vorgehen solcher Reviews, beginnend mit dessen konkreten Zielen, dem (schwierigen) Scope sowie den notwendigen Personen (aka Stakeholder).
Anschliessend schauen wir etwas genauer auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und
den Entwicklungs- und Rollout-prozessen. Ein Kernbegriff dabei lautet "iterative Breitensuche", wobei wir die bedarfsgerecht durch Tiefensuche ergänzen. Zu jedem Untersuchungsbereich gebe ich Beispiele und zeige methodische Werkzeuge um effektiven und praxisnahen Einsatz.

Schliesslich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Der Vortrag richtet sich an Software-Entwicklungsteams, Architekt*innen, Product-Owner sowie technisches Management.

Transcript

1. Software Reviews und was die mit The Police zu tun haben... Dr. Gernot Starke
2. Dr. Gernot Starke INNOQ Fellow üArchitektur-Verbesserer üCoach, Trainer ü arc42, aim42 ü iSAQB e.V.
3. Software Reviews ???
4. Software Reviews Warum – Was – Wer - Wie Agenda
5. Warum – Was – Wer - Wie Warum Software Reviews?
6. These: Jedes System hat Potenzial Photo by John Hult on Unsplash
7. Reviews vermeiden... lösungsgetriebenen Aktionismus
8. Behandlung ohne Untersuchung …
9. Cannabidiol 100mg/Tag
10. • Übersicht: Stärken+Schwächen als Grundlage für Verbesserung • Neutrale Meinung Extremfall: Juristisch relevante Gutachten • neue Ideen / Anregungen • Bestätigungvon Vermutungen Warum – Was – Wer - Wie
11. • steigende Zahl „Prio-1 Fehler“ • Entwicklung wird immer langsamer • (Neues) Management benötigt „neutrale“ Einschätzung Warum – Was – Wer - Wie Beispiele
12. Warum – Was – Wer - Wie Was betrachten wir? (scope)
13. *: XY z.B. Warenwirtschaft, online-Shop, Planungssystem, ERP-System, whatever-you-develop unser XY* externe Nachbarsysteme 3rd Party Zulieferung („Framework“) Datenquel le Datenquel le Datenquel le Datenquelle Vor- verarbeitung nachgelagerte Verarbeitung mobile App Fremd- firmen Fremd- firmen etc.
14. Warum – Was – Wer - Wie Scoping ernst nehmen!
15. • internes Konzern-CRM: • Prozesse: Content-Akquise, Aufbereitung, Freigabe • Projektorganisation • SW-Technik • kein Betrieb Warum – Was – Wer - Wie Beispiele
16. • (Groß-)Maschinenbau: • SW-Architektur + Implementierung • on-Device, Konfigurations- /Planungssystem • Projektorganisation • keine Datenquellen / -senken Warum – Was – Wer - Wie Beispiele
17. Warum – Was – Wer - Wie Wer reviewt?
18. + unabhängig + neutral + neue Impulse - längere Einarbeitung - Risiko „oberflächlich“ - höhere Kosten + fachliche Erfahrung + im Unternehmen vernetzt + kostengünstig - Risiko „befangen“ - Risiko „betriebsblind“ - kein Benchmarking - „Prophet im eigenen Land“ Warum – Was – Wer - Wie
19. • Automotive (Zulieferer): • 1 Person extern max. 10 PT) (Qualitative Analyse analog ATAM), • 2 Personen intern Warum – Was – Wer - Wie Beispiele Zukunftssicherheit der Architektur „Multimedia-Framework“
20. • (Riesen-)Online-Shop: • 4 Personen extern (INNOQ), ca. 100 PT • 3 Personen intern, 30+ PT • Verpflichtung, 24 Monate keine weiteren Aufträge für dieses Unternehmen Warum – Was – Wer - Wie Beispiele Zukunftsfähigkeit von Architektur und Implementierung
21. • Telco („Billing-Kette“): • 3 externe Dienstleister, jeweils 2-3 Personen, gesamt ca. 200 PT • 2-3 Personen intern, 30+ PT • Aufteilung entlang der Prozesskette (u.a. Wirknetz, Pre-/Post-Billing) Warum – Was – Wer - Wie Beispiele Tragfähigkeit der Architektur sowie Integration von Standardprodukten
22. Warum – Was – Wer - Wie Wie geht das?
23. Access All Areas
24. Access ALL Areas. Breitensuche Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security .... Analyze
25. Breitensuche:
26. Stakeholder kennen viele Probleme (+ Lösungen).
27. • (Riesen-)Online-Shop: • Interviews zeigten: • (krasse) Diskrepanzen in Sichtweisen Management + Entwicklungsteams • Architekturprobleme, die beim Management nicht bekannt waren Warum – Was – Wer - Wie Beispiele Zukunftsfähigkeit von Architektur und Implementierung
28. Warum – Was – Wer - Wie Metriken • Kopplung / Abhängigkeiten • Code-Komplexität • Performance • … gut
29. Warum – Was – Wer - Wie Metriken • Kopplung / Abhängigkeiten • Code-Komplexität • Performance • … • Fehler pro Baustein • Know-How pro Baustein • Änderungshäufigkeit • … gut besser
30. • Telekommunikation: • Management beobachtet (Java-) Metriken nach Ampel-System (CAST Application Intelligence Platform) • >70% des Systems in xslt implementiert • nicht von CAST erfasst Warum – Was – Wer - Wie Beispiele Ziel: „Benchmarking“: Produktivität von Entwicklung prüfen
31. komplexer Code, der häufig geändert wird. Beachte Hotspots
32. Warum – Was – Wer - Wie Breitensuche Metriken Struktur Anwendungs- daten Qualität (ATAM) Security Prozesse
33. • „Warenwirtschaft“: • Fachlich sauber strukturiert • In vielen Teilen (nearly) clean-code • Datenbank + -strukturen völlig desolat Warum – Was – Wer - Wie Beispiele Ziel: Verschiedene Wege zur „ganzheitlichen Verbesserung“ aufzeigen
34. • (Groß-)Maschinenbau: • Prozessproblem (Know-How „Flaschenhals“) führt zu erheblichen Risiken in Code Beispiele Ziel: Möglichkeiten zur Verbesserung der Architektur aufzeigen Warum – Was – Wer - Wie
35. Warum – Was – Wer - Wie Der Abschluss... Bericht: • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge gut
36. Warum – Was – Wer - Wie Der Abschluss... Bericht: • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge 2 Vorträge: • Vorab „in kleiner Runde“ • Feinschliff • Abschluss „in großer Runde“ gut besser
37. • Spezial-Maschinenbau: • Management fokussiert auf mögliche Problemen • Abschlusspräsentation fokussiert auf Stärken der Teams + des Systems Warum – Was – Wer - Wie Beispiele Ziel: „Benchmarking“ Architektur und Entwicklung
38. Fazit 1. Ziele und Scope klären 2. (mehrere!) Stakeholder involvieren 3. Schwerpunkte aus Zielen ableiten 4. Breiten- vor Tiefensuche 5. Mehr als Code untersuchen!! 6. Ergebnisse präsentieren
39. Danke. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke www.innoq.com