Successfully reported this slideshow.

2009 - Basta!: Agiles requirements engineering

594 Aufrufe

Veröffentlicht am

Agiles requirements engineering

  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

2009 - Basta!: Agiles requirements engineering

  1. 1. Agiles Requirements-Engineering Daniel Fisher daniel.fisher@devcoach.com
  2. 2. Lennybacon.com Daniel Fisher | CTO & Software Architect MCP, MCTS, MCPD… daniel.fisher@devcoach.com Mit-Gründer und Geschäftsführer von devcoach.com www.devcoach.com Mitglied von www.solution-EXPERTS.de Mit-Gründer und Vorstand der gemeinnützigen www.just community.de e.V. Veranstalter des größten Entwickler & IT-Pro Community Events in Deutschland: www.nrwconf.de Mit-Gründer und Leiter der INETA Usergroup Düsseldorf www.NetUG-NiederRhein.de Mitglied im Microsoft Community Leader & Insider Program (CLIP) Connected Systems Advisory Board Expertengruppe für WCF, WF & BizTalk
  3. 3. devcoach.com • Leistungen – Architektur-Beratung • Strukturierter und effizienter zu einer wartbaren Anwendung. – Prozessoptimierung • BPM • FDD, TDD, MSF Agile & SCRUM – Software-Entwicklung • Team-out-of-the-box (Near-shoring) • Objektmodelle und Datenzugriff • Kommunikations-Infrastrukturen • Identitäts- und Berechtigungsmodelle • Web 2.0 und Rich Internet Applikation – Coaching & Training • Technologien schneller verstehen und richtig einsetzen. • Technologien – Microsoft Windows & .NET Framework • ASP.NET, WCF, WF, WPF, Silverlight & Geneva • Kunden – Versicherung, Finanzindustrie, Mittelstand, Handel, Kommunikation, Softwarehersteller u.v.a. • Bundesamt für Sicherheit in der Informationstechnologie, Microsoft, Dresdner Bank… Project Experience Technology Know-how devcoach®
  4. 4. Agile Anforderungsanalyse...
  5. 5. Warum sind die Anforderungen so wichtig?
  6. 6. Der Erfolg eines Software-Projektes hängt von verschiedenen Faktoren ab!
  7. 7. Heisst das wenn man eine Anforderungsanalyse betreibt erhält man gute Software?
  8. 8. Die bloße existenz ist keine Garantie Wie bei allen anderen Faktoren!
  9. 9. Das ist nicht nur in der Software-Industrie so...
  10. 10. Ein Brot ist immer so gut wie seine Zutaten und sein Bäcker
  11. 11. Oder?
  12. 12. Wenn aus Eisen kein Gold werden kann... kann ein Prozess allein keine Gute Software machen!
  13. 13. Sehen wir uns die "Zutaten" mal an...
  14. 14. Customer Requirements
  15. 15. Functional Requirements
  16. 16. Non-functional Requirements
  17. 17. Derived Requirements
  18. 18. Allocated Requirements
  19. 19. Stakeholder identification
  20. 20. Stakeholder interviews
  21. 21. Requirements lists
  22. 22. Measurable goals
  23. 23. Prototypes
  24. 24. Use cases
  25. 25. Und trotzdem...
  26. 26. Sehen wir uns das Problem mal genauer an...
  27. 27. Der Kunde weiss gar nicht was er will?
  28. 28. Der Kunde will eine Software! Wenn er ein Auto kauft muss er das ABS dazu auch nicht selbst erfinden...
  29. 29. Der Kunde weiss gar nicht wie er die Anforderungen formulieren soll?
  30. 30. Der Kunde hat ein Geschäft, dass er kennt! Zu 99,9% ist das nicht das schreiben von Anforderungen...
  31. 31. Die Anforderungen des Kunden ändern sich mit der Zeit!
  32. 32. Die Welt dreht sich. Märkte ändern sich! Warum sollten Anforderungen in Stein gemeisselt sein...
  33. 33. Die Kommunikation mit dem Kunden ist schwer!
  34. 34. Jeder spricht die Sprache seiner Fachdomäne! Techniker auch...
  35. 35. Der Kunde hat keine Ahnung von Technologie
  36. 36. Woher soll der Kunde die Technologie kennen wie wir? Kennen wir seine Fachdomäne wie er?
  37. 37. Der Kunde versteht den Entwicklungs-Prozess nicht!
  38. 38. Verstehen wir seinen Geschäftsprozess ohne, dass er diesen erklärt?
  39. 39. Der Entwickler verfasst oder interpretiert Anforderungen!
  40. 40. Der Entwickler kennt die Technologie! Nicht die Fachdomäne...
  41. 41. OK, Probleme identifiziert!
  42. 42. Aber wie kann uns "Agil" helfen?
  43. 43. Agil != Funky
  44. 44. agil <Adj.> [frz. agile < lat. agilis] (bildungsspr.): von großer Beweglichkeit zeugend; regsam, flink, gewandt und wendig (bes. Körperlich und geistig).
  45. 45. Messen, messen, messen! Nicht nur einmal raten!
  46. 46. Ein Projekt hat ein meist fixes Budget Für das Software Programmiert werden kann
  47. 47. Ein Projekt hat ein meist eine Deadline Bis zu der Software Programmiert werden kann
  48. 48. Agilität heisst Kurskorrekturen ein zu planen Das Ziel genauer zu treffen!
  49. 49. Wie kann man denn Aufwände schätzen wenn der Umfang nicht von vorne herein klar ist?
  50. 50. Heisst das nicht, dass vieles doppelt entwickelt wird?
  51. 51. Ist so ein Ansatz denn schon Reif?
  52. 52. Ein Beispiel aus einem Projekt...
  53. 53. The Manual
  54. 54. Small iterations Gather Requirements Design DevelopTest Review
  55. 55. Und die Tools?
  56. 56. A fool with a tool is still a fool! Besonders bei agilen Methoden!

×