Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps

Größe: px

Ab Seite anzeigen:

Download "Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps"

Liese Siegel
vor 8 Jahren
Abrufe

1 Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps Steffen Hess

2 Mobile Business Apps Business Prozesse Services Backend 2

3 3 Potential von mobilen Business Apps

4 Hohe Usability und User Experience 4 Hohe Usability und User Experience

5 5 Klarer und limitierter Funktionsumfang

6 Integration in die existierende IT Infrastruktur 6 Integration in die existierende IT-Infrastruktur

7 Unterstützung verschiedener Geräte und Geräteplattformen 7 Unterstützung verschiedener Geräte und Geräteplattformen

8 Kurze Entwicklungszyklen 8 Kurze Entwicklungszyklen

9 Zufriedenstellung von Benutzern, Kunden und allen anderen involvierten Stakeholdern maßgeschneiderte Engineering-Lösungen 9 Folgerung

10 User-Centered Leichtgewichtig Integriert mconcappt Methode 10 Lösungsansatz

11 Vorgelagerte Aktivitäten mconcappt Methode Overview Business Analyse Architektur Testen mconcappt Entwicklung Visual Design Projekt Management Nachgelagerte Aktivitäten 11

12 Vorgelagerte Aktivitäten mconcappt Methode Overview Business Analyse Architektur Testen mconcappt Entwicklung Visual Design Projekt Management Nachgelagerte Aktivitäten 12

13 mconcappt Methode Überblick Interaction Design Eclitation Interaction Design Spezifikation Interaction Design Kommunikation Interaction Design Validation 13

14 Phase 1: Interaction Design Elicitation Durchschnittliche Dauer Workshop Vorbereitung 3h Interaction Design Workshop 5,5h Workshop Dokumentation 15h 14

15 Workshop Teilnehmer RE/IAD Experte (1-2) (Lead) User (2-4) Projekt Management (1) Business Analyst (1) Kunde 15

Workshop Resultate Erhebung der Stakeholder und Nutzerrollen User Persona As-is Erhebung To-be Erhebung Wichtigste Systemfunktionen Stakeholder Name Travel Management Item ID Stakeholder Rolle

16 Workshop Resultate Erhebung der Stakeholder und Nutzerrollen User Persona As-is Erhebung To-be Erhebung Wichtigste Systemfunktionen Stakeholder Name Travel Management Item ID Stakeholder Rolle Stakeholder Hauptziele Benutzt den Einfache Output des Beschreibung Weiterverarbeitung der Systems Reiseabrechnung, Eindeutige Bezeichnung Zeitersparnis Reisender Name Benutzer Name der Systemfunktion Vereinfachung von Reiseabrechnungen, Eingabedaten Daten, die ins Zeitersparnis, System eingegeben Verringerung werden des Cognitive Load Item Beschreibung Unternehmens- Vorbedingung Entscheidungsträger Vorbedingung Vereinfachung des Systems der internen leitung Kontext Benutzungskontext Prozesse, des aktuellen Beschreibung Tasks Schrittweise Kosteneinsparung Beschreibung der Systemaktivitäten Vorbedingung Vorbedingung, die zur Ausführung des Ausnahmen Tasks Ausnahmen, führt die auftreten können Schritt 1-N Geschäftsregeln Nachbedingung Qualitätsanforderungen Ausgabedaten Nachbedingung Schritte, die ausgeführt werden Adressierte Geschäftsregeln inklusive auftretender Probleme Zustand, Qualitätsanforderungen, nach dem Task die sich erreicht direkt ist auf diese Systemfunktion beziehen Daten, die vom System ausgegeben werden Nachbedingung des Systems 16

17 Praktische Erfahrungen Nur ein Requirements Workshop benötigt Teilnahme aller Rollen notwendig Vorbereitung des Workshops Informationen im Voraus erheben Kompetenz des Moderators Benutzer befreien 17

18 Phase 2: Interaktion Design Spezifikation Key Funktionalität Durchschnittliche Dauer 1h Spezifiziere Interaction Cases 30 min pro Interaction Case Interaction Case Flow 15 min Wireframes erstellen 5 bis 20 min pro Wireframe Iteration Screen Flow 20 min 18

19 Key Funktionalität Auf Basis des to-be Szenarios Welche Schritte benötigen wirklich mobile Unterstützung Scope der App 19

20 Spezifiziere Interaction Cases Use Case mit Interaktionsfokus Human Action System Action Mehrere User Stories Item ID Usage Context Human Action 1 System Action 1 Nachbedingung Beschreibung Eindeutige des Interaction Case Plausible Beschreibung der aktuellen Umgebung und Situation basierend auf Annahmen wie der Interaction Case ausgeführt wird. Instanziierung des eher generellen Usage Context in der Beschreibung der to-be Situation Eine Human Action wird vom Benutzer auf dem Eingabegerät ausgeführt und wird durch einen konkreten Usage Type (z.b. double tap) beschrieben Beschreibung der zugehörigen Systemausgabe. Hierbei ist explizit zwischen Eingabefeedback und eigentlicher Ausgabe zu unterscheiden Die Nachbedingung zeigt explizit wo sich der Benutzer jetzt im System befindet 20

21 Interaction Case Flow IC1: Select trip IC2: Track time IC3: Add artifact IC4: Show artifact IC5: Edit artifact Finale Entscheidung über den Scope der App wird getroffen 21

22 Wireframes erstellen Papier Leichtgewichtige Tools (z.b. Balsamiq) Fertige App 22

23 Screen Flow 23

24 Praktische Erfahrungen Der RE/Interaktionsdesigner sollte selbst extensiver Nutzer der adressierten Geräteklasse und des Betriebssystems sein Der Schlüssel zum Erfolg liegt in der Entscheidung welche Funktionalität auf dem Backend und welche in der App realisiert wird Frühe Kommunikation von Ideen und Sketches verbessert die Qualität Großes Konfliktpotential zwischen Interaktionsdesign und Architektur UX und Architektur beeinflussen sich erheblich Das eigentliche App Frontend ist sehr von der Performanz im Backend abhängig 24

25 Phase 3: Interaction Design Kommunikation Durchschnittliche Dauer Aufnahmeskript 3h Aufnahme der Clips 10min pro Clip Schneiden 30min pro Clip Rendern 25

26 Aufnahmeskript (Optional) Basierend auf Interaction Cases und Wireframes Ideen und Begründungen von Designentscheidungen Screen Transitionen Gesten Eingabefeedback Fancyness Item Interaction Case Screen Arrangement 1 Human Action 1 System Action 1 Nachbedingung Beschreibung Name des Interaction Case Erklärung des Screen Arrangements. Inkludiere Begründungen für Designentscheidungen in die Beschreibung Beschreibe, wie die Benutzerinteraktion abläuft insbesondere welche Aktion der Benutzer genau tätigen muss Beschreibe, wie genau das System auf diese Benutzerinteraktion reagiert. Beschreibe das Eingabefeedback und die Screen Transition Die Nachbedingung zeigt explizit wo sich der Benutzer jetzt im System befindet 26

27 Aufnahme der Clips Max. 5 Minuten pro Clip Einfaches Setting Wizard of Oz 27

28 Schneiden und Rendern 28

29 Praktische Erfahrungen Video + Text ist der präferierte Ansatz in verteilten Teams und Projekten Face to Face Kommunikation sollte bevorzugt werden Leichtgewichtige Dokumentation ist Pflicht 29

30 Phase 4: Interaction Design Validation Testbaren Prototyp erstellen Durchschnittliche Dauer 1h Tests durchführen 1h pro Test Test Nachbereitung 4h 30

31 Testbaren Prototyp erstellen Low - Fidelity Auf dem tatsächlichen Gerät Tool Support 31

32 Test durchführen 4 Benutzer 4 Iterationen Im tatsächlichen Nutzungskontext Keine klinische Umgebung 32

33 Wenn eine Person mehrere Rollen einnimmt führt dies zu Konflikten Aufklärung der Nutzer - nicht alle Aktivitäten die möglich sind, müssen auch mobil durchzuführen Das mobile Gerät ist in der Regel ein zusätzliches Gerät Durchführung in 2 Wochen (3 Iterationen) machbar Zeiten korrelieren aber mit der Erfahrung der beteiligten Personen Kreative Schritte und Kommunikation erfordern einen hohen Zeitaufwand 33 Generelle Praktische Erfahrungen

34 mconcappt Methode unterstützt bei der Durchführung von leichtgewichtigem Requirements Engineering und Interaktionsdesign Hohe Usability und UX Klarer und limitierter Funktionsumfang Kurze Produktentwicklungszyklen Nutzerzentrierung und Leichtgewichtigkeit Unsere Kunden waren sehr zufrieden mit der durchschnittlichen Dauer von 4-6 Wochen bis zum ersten Release einer neuen Mobile Business App 34 Zusammenfassung

35 Klare Definition und Ausgestaltung der Schnittstellen zu anderen Aktivitäten (z.b. Visual Design, Architektur) Präzisere Definition der ausgetauschten Artefakte Integration von leichtgewichtigen Kreativmethoden in die Requirements Engineering Aktivitäten Unterstützung von verschiedenen Plattformen und Geräteklassen (Skalierung) Tool Support insbesondere für die Kommunikationsaktivitäten Weitere Validierung der Methode 35 Aktuelle und künftige Aktivitäten

36 36 Steffen Hess

Ähnliche Dokumente

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben