akquinet Anforderungen, Usability und Agilität Stefan Roock

Transkript

1 Anforderungen, Usability und Agilität Stefan Roock

2 Unser Hintergrund IT-Beratung aus Hamburg Mitglied in der akquinet AG mit ca. 160 Mitarbeiter in Hamburg, Berlin, Bremen, Kiel + international Arbeit mit agilen Methoden seit 1999 Agile Individualprojekte (meist XP) Beratung und Schulung zu agiler Softwareentwicklung 2

3 Anpassbarkeit statt Planbarkeit * Natürlich suchen wir auch Frauen und sind beim Alter nicht festgelegt. 3

4 Stellenwert agiler Softwareentwicklung akquinet Wasserfallmodell war zyklisch gemeint. Erste explizit agile Methode: 1986 (Scrum) Zweite Generation agiler Methoden verfügbar (XP in zweiter Auflage, IXP). Standish Group empfiehlt im CHAOS-Report 2004 agile Methoden. V-Modell XT (XT = extreme Tailoring) lässt Tailoring für agiles Vorgehen zu. Microsoft, SAP, Google, Eclipse (IBM) setzen agile Methoden ein Agile Softwareentwicklung == Lean Development 4

5 Bedarf und Umsetzung Nutzendefizit (Was fehlt.) Was man braucht. Was man bekommt/ hat. Was man nutzt. Was man will. Was man verlangt. Folie nach: Jürgen Ahting 5

6 Die Grenzen unseres Verständnisses akquinet 6

7 sind viel schneller erreicht, als wir glauben wollen. 7

8 Und dann ersetzen Pläne Zufall durch Irrtum 8

9 Bedarf und Umsetzung: real Was man will. Was man braucht. Was man bekommt/hat. Was man verlangt. Folie nach: Jürgen Ahting 9

10 Agil: Anpassbarkeit statt Planbarkeit akquinet Big Design Up Front Abb. nach 10

11 Anpassbar ist, was einfach ist "Ein Ding ist nicht dann perfekt, wenn man nichts mehr hinzufügen kann, sondern dann, wenn man nichts mehr weglassen kann." Antoine de Saint-Exupéry 11

12 Aus der Werbung eines großen deutsche IT-Dienstleiders Softwaresysteme sind komplex. Die Fähigkeit, sie voll und ganz zu durchdenken, ist rar. 12

13 Der Prozessansatz Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten 13

14 Die Verantwortlichkeiten Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten Verantwortlich für Geschäftswert Verantwortlich für Technologie 14

15 Typischer zeitlicher Projektverlauf akquinet Release- Planung (Release <6 Monate) Erstes Release häufig Exploration Release- Review. I.d.R. Auslieferung Release Release Iteration Iteration Iteration Iteration Iteration Iteration Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Aufgabe Iterationsplanung (Iteration <1 Monat) Iterationsreview Aufgaben sind i.d.r. so geschnitten, dass der Kunde die Erledigung feststellen kann. 15

16 Also gleich losprogrammieren? Agil == Hacking? 16

17 Small Upfront Design 17

18 Das Projektziel SMART Specific Measurable Achievable Relevant Time Based 18

19 Das Projektziel: Beispiel Apple itunes: 1 Mio. Downloads im ersten Monat SMART Specific Measurable Achievable Relevant Time Based 19

20 Gemeinsame Vision über das Projekt Projektziele Grobe Gesamtschätzung Releaseplan Risikoliste Oberflächenprototypen Fachliches Kernmodell Architekturvorstellung Kern-Technologien Gemeinsame Sprache 20

21 Prototyping Zusammen mit den Anwendern Flipcharts Word 21

22 Gute Anforderungen: INVEST I ndependent - Möglichst unabhängig von anderen Anforderungen. N egotiable - Details & Realisierung sind verhandelbar. V alueable - Nützlich (=generiert Geschäftswert) E stimatable - Schätzbar (trotz fehlender Details ist die Komplexität bekannt) S mall - Klein genug zum Schätzen T estable - Testbar (Akzeptanztest) 22

23 Mini-Features für die Anforderungsbeschreibung Geschäftsbereich (Business Area) Geschäftstätigkeit (Business Activity) Feature Feature-Schema: <Aktion> <Ergebnis> <Objekt> Zählermanagement Disponiere Tagesarbeit Zählerwechsel Zeige Verfügbarkeit der Mitarbeiter an. Weise Arbeitsauftrag an Mitarbeiter zu. 23

24 Explorationsphase: 2-3 Wochen für 6 Monate Entwicklung 24

25 Inkrementeller Entwurf 25

26 DTSTTCPW Do The Simplest Thing That Could Possibly Work Immer den Weg des geringsten Widerstandes gehen vs. einfacher Entwurf. 26

27 Wer kann was? Anzahl inkrementeller Meister Methode Klasse Komponente Architektur Architekturstil 27

28 Vorsicht vor NDUF No Design Up Front Die meisten Projekte brauchen einen leicht verständlichen und klaren Rahmen, in dem der inkrementelle Entwurf stattfindet. 28

29 Wie weit in die Zukunft sehen? Kosten je Feature Sweet-Spot Vorausschau 29

30 Inkrementelles User Interface Design 30

31 Aufgabenangemessenheit Entwickler brauchen Verständnis über die Arbeitssituationen der Anwender. Wenige Tage Praktikum / Hospitation nützen enorm viel. 31

32 Iterations- und Releasereviews liefern nützliches Feedback Wie funktioniert das System in der Praxis? 32

33 Anpassbarkeit Kann ich mein UI entsprechend dem Feedback anpassen? 33

34 Agiler UI-Rahmen Verwendung der UI-Elemente z.b. Unterscheidung Button, Grafik und Link im Web Funktionsweise der UI-Elemente z.b. Sortierung in Tabellen Anordnung der UI-Elemente 34

35 Wieviel UI-Rahmen? Niemand liest dicke Dokumente. Regele nur das, was sich später schwer ändern lässt. Sehr unterschiedlicher Regelungsbedarf HTML & CSS vs. handcodiertes Grafik-UI in C 35

36 UI-Designer Vollzeit ins Team integrieren oder punktuell extern zuarbeiten lassen Hängt vom Projekttyp ab 36

37 Low Tech Tools Direkte persönliche Kommunikation Karteikarten Flipcharts Wenn elektronisch: Immer auch ausgedruckt! 37

38 Hört die Signale Wer hat die besten Internet-Anwendungen? 38

39 Ziel [des Requirements Engineering] ist eine vollständige, eindeutige, widerspruchsfreie Spezifikation aller Anforderungen. Reiterer & Memmel 39

40 40

41 Eat Your Own Dogfood Henry Ford: Jedes Unternehmen muss soviel Wasser flusssaufwärts einleiten, wie es flussabwärts entnimmt. 41

42 Ziel des agilen Requirements Engineering ist eine wertvolle Software. Dazu werden Anforderungen kontinuierlich während des Entwicklungsprozesses erhoben und nach dem INVEST-Schema definiert, so dass sie gerade rechtzeitig (Just-In-Time) für die Entwicklung bereit stehen. 42

43 Zusammenfassung Persönliche Zusammenarbeit und Kommunikation ersetzt schwerfällige Dokumente und Tools. Small Upfront Design dauert max. 3 Wochen RE und UE begleiten kontinuierlich das Projekt. Feedback über Iterations- und Releaseergebnisse steuern weiteren Verlauf von RE und UE. Entwickler kennen die Arbeitssituationen der Anwender. 43

44 Vielen Dank für die Aufmerksamkeit akquinet Noch Fragen? 44

45 S-,P- und E-Probleme M.M. Lehmann: Programs, Life Cycles, and Laws of Software Evolution, Man kann Problemstellungen in der Softwareentwicklung klassifizieren nach S-, P- und E. 45

46 S-Probleme S: Spezifikationsproblem, Bsp.: Quadratzahl berechnen vollständig, widerspruchsfrei, korrekt Problem Spezifikation Programm Mathematische Transformationen, beweisbar 46

47 P-Probleme P: Real World Problem, Bsp.: Schach, Wettervorhersage unvollständig, widerspruchsfrei, korrekt Problem Spezifikation Programm Abstraktion und Heuristiken notwendig. Auswirkungen häufig schwer absehbar. Iterationen mind. im Labor notwendig. 47

48 E-Probleme E: Sozial eingebettete Probleme unvollständig, widersprüchlich, falsch Arbeitswelt Problem Programm Spezifikation Programm verändert den Problemkontext. Auswirkungen nicht absehbar. Iterationen notwendig mit Systemeinsatz. 48