What can we learn from Asian cultures, to improve the way we approach software and system development.

1. Everything is Connected!
Was Softwareentwickler von fernöstlicher Philosophie lernen
können
Philipp Schneider, Phonak AG
philipp.schneider@phonak.com

2. http://www.zeno.org/Bildpostkarten/M/Schwarze/Unsere+Marine/'Wenn+jemand+eine
+Reise+tut...'
Agenda
Was können wir von fremden Kulturen lernen?
Unterschiede westlicher und asiatischer Kultur
Anwendung auf die Softwareentwicklung
Beispiele aus der Praxis
- Software Architektur und User Experience Design
Zusammenfassung

3. Was können wir von fremden Kulturen lernen?

4. Unterschiede westlicher und asiatischer Kultur
Indische Buddhismus Psychologie
Philosophie
Westen Osten
Teile und Herrsche Zusammenhänge erkennen
Symptom eliminieren Blockaden lösen
Änderung erzwingen Effektiv arbeiten

5. Teile und Herrsche
Urs Wehrli – Kunst Aufräumen
ISBN: 3-0369-5200-4

7. Teile und Herrsche Zusammenhänge
erkennen
Mein Verständnis der Arbeitsumgebung beeinflusst mein Handeln
Das integrierte System ist mehr als die Summer der Einzelteile
Ich bin ein Teil, innerhalb des Systems „Softwareentwicklung“
Als Teil kann ich das System nur ändern, indem ich mich ändere

8. Symptom eliminieren Blockaden lösen
Mit der richtigen Medizin kann man ein Symptom schnell eliminieren,
dies ist aber meistens nicht nachhaltig
Zusammenhang zwischen Symptom und Ursache ist meistens nicht
einfach erkennbar
Annahme: „Natürliches“ Gleichgewicht in der Softwareentwicklung
stellt sich ein, wenn Blockaden entfernt werden

9. Änderung erzwingen Effektiv arbeiten
Widerstand in der Entwicklung als positive Herausforderung sehen
Selbstverantwortung übernehmen und entscheiden, wie man eigene
Arbeitskraft am effizientesten einsetzten kann
Grenzen erkennen, lernen damit umzugehen aber auch immer wieder
einen neuen Anlauf unternehmen

10. Anwendung auf die Softwareentwicklung
Zusammenhänge erkennen
Blockaden lösen
Effektiv arbeiten

11. Hörsystementwicklung in der Phonak

12. Zusammenhänge in der Hörsystementwicklung

13. Pulsdiagnose: Softwarearchitektur

14. Best Practice: Architekturzentriertes Arbeiten

15. Symptom 1: Architekturdokumente sind vorhanden und korrekt. Aber
was bedeuten die vielen Diagramme in meiner täglichen Arbeit?

17. Symptom 2: Die Architekten befassen sich fast ausschliesslich mit
Infrastruktur. Der Bezug zum Problem das es zu lösen gilt geht
verloren.

18. Ohr mit
Hörgerät
Funktions-
blöcke
Domänen-
modell
Umsetzung
in Code

19. Domain Model

21. Symptom 3: Es gibt eine gute Architekturdokumentation, die aber
leider immer nur zu 80% stimmt und wichtige „Details“ einfach
ignoriert.

23. Behandlung Softwarearchitektur
Befassen sie sich in der
Softwarearchitektur nicht nur mit den
nicht-funktionalen Eigenschaften des
Systems!
Modellieren sie Struktur und Verhalten
der Domäne gemeinsam mit den
Experten.
Stellen sie eindeutige Regeln auf, wie
Diagramme in Textfiles und
Verzeichnisstruktur abgebildet werden.
Generieren sie Architekturdiagramme
direkt aus den Textfiles und den
Architekturregeln.

24. Pulsdiagnose: User Experience Design

25. Best Practice: User Centred Design

26. Symptom 1: Es kommt mehr und mehr Funktionalität dazu, welche
die Applikation immer komplizierter macht.

27. Für Einsteiger Für Professionals

28. Symptom 2: Das Feedback der Anwender führt dazu, dass von
einfachen Interaktionsprinzipien abgewichen wird.

29. A
A B C D
A
B
A + B auf einem Tool!
A B C D A

30. Symptom 3: Trotz Feedback der Anwender, wird nicht von etablierten
Interaktionsprinzipien abgewichen.

31. Tools Anzeige

33. A
A

34. Symptom 4: Obwohl man mit dem eigenen Produkt nicht zufrieden
ist, investiert man in Usabiltiy Studien

35. Lösung A Lösung B
Lösung C

36. Behandlung User Experience Design
Versuchen sie zu verstehen, welche
Funktionen ihr Produkt im Markt
einmalig und begehrt machen.
Erarbeiten sie einfache, klare
Interaktionsprizipien und wenden sie
diese durchgängig an.
Hinterfragen sie einfache, klare
Interaktionsprizipien, wenn sie auf
unlösbare Probleme stossen.
Ermuntern sie alle Beteiligten
mitzuhelfen die User Experience ihres
Produktes zu verbessern. Aber
bestimmen sie gleichzeitig den „Chief
Design Officer“.
Die User Experience fühlt man erst so
richtig am fertigen Produkt. Planen sie
daher schon vorgängig eine UE
Refactoring.

37. Zusammenfassung
Blockaden lösen
Zusammenhänge
erkennen
Effektiv arbeiten