Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Creasoft - Software QS
Creasoft - Software QS
Cargando en…3
×

Eche un vistazo a continuación

1 de 52 Anuncio

Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten

Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.

Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.

Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.

Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.

Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Anuncio

Similares a Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten (20)

Más reciente (20)

Anuncio

Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten

  1. 1. Creasoft Akademie Diszipliniertes Anforderungsmanagement in agilen Projekten
  2. 2. Stefan Matt Geschäftsleitung / Software - Entwickler
  3. 3. Themen • Agiles Anforderungsmanagement? • Arten von Anforderungen • Umsetzen von Anforderungen • Ausblick / Offene Punkte Quelle: Google Bildsuche
  4. 4. Themen • Agiles Anforderungsmanagement? • Arten von Anforderungen • Umsetzen von Anforderungen • Ausblick / Offene Punkte Quelle: Google Bildsuche Requirements
  5. 5. Anforderungsmanagement? Top Tens Lists of Software Project Risks: Evidence from the Literature Survey By Tharwon Arnuphaptrairong 2011 1. Misunderstanding of the requirements 2. Lack of management commitment and support 3. Lack of adequate user involvment 4. Failure to gain user commitment 5. Changes to requirements 6. Lack of an effective project management methodology
  6. 6. Agiles Anforderungsmanagement? • Bei der agilen Vorgehensweise geht es vor allem darum, wie Anforderungen umgesetzt werden. • Sie kümmern sich nicht darum wie Anforderungen gefunden oder gewürdigt werden. • Das ursprüngliche Konzept der ‚User Story‘ ist nicht leistungsfähig genug.
  7. 7. Iteratives Vorgehen ‚klassisch‘ agil! Einsatz + Feedback • User Anforderungen erarbeiten • PO, Team Anforderungen umsetzen • Team Testen • Team, Tester Abnahme Sprintende • PO • Iteration über den ganzen Zyklus um Anforderungen zu klären ist ineffizient!
  8. 8. Iteratives Vorgehen in Stufen! • Weitere Feedbacks einführen. • Das steigert Effizienz und reduziert Risiko • Schleifen können parallel laufen Analyse Spezifikation Prototyp Feedback Akzeptanz (Feedback) Architektur Entwickeln Test Stabilisieren Feldtest Feedback Anforderungen Entwicklung Konsolidierung Evolution Planung
  9. 9. Anforderungen dokumentieren • Agile manifesto: Working software is valued more than documentation. • Aber: Es heisst nicht ‚Dokumentation ist verboten‘ • Xtreme Programming: ‚The tests are the documentation.‘ • Erstellen der Anforderungsdokumentation ist nicht geregelt. • ‘Analysis Paralysis’ vermeiden
  10. 10. Resultate dokumentieren • The tests are the specification  Das kann nur ein Entwickler sinnvoll finden • Der Feedback Loop vom Backlog in eine Produktspezifkation fehlt in der Theorie völlig. • Es ist somit schwierig zu belegen oder zu dokumentieren (Handbuch) was die Software eigentlich kann. • Es ist schwierig, sich einen Überblick zu verschaffen
  11. 11. Themen • Agiles Anforderungsmanagement? • Arten von Anforderungen • Umsetzen von Anforderungen • Ausblick / Offene Punkte Quelle: Google Bildsuche
  12. 12. Arten von Anforderungen Klassische (und nützliche) Sicht der Anforderungen: Business Requirements Vision and Scope Document Quelle: Karl E. Weigers User Requirements Use Cases Functional Requirements Software Requirements Specification Quality Attributes Other nonfunctional Requirements
  13. 13. Eine andere Sicht Lösung Anforderungen Erfordernisse Nutzungskontext LösungsraumProblemraum Empirische Basis Inspiration: Thomas Geis, ProContext (Needs) (Requirements) Nutzungsanf. Systemanf.
  14. 14. Eine andere Sicht Lösung Anforderungen Erfordernisse Nutzungskontext LösungsraumProblemraum Empirische Basis Inspiration: Thomas Geis, ProContext (Needs) (Requirements) Nutzungsanf. Systemanf. Darum geht’s heute
  15. 15. Themen • Agiles Anforderungsmanagement? • Arten von Anforderungen • Umsetzen von Anforderungen • Ausblick / Offene Punkte Quelle: Google Bildsuche
  16. 16. Umsetzen von Anforderungen • Wer beschäftigt sich mit Anforderungen? • Strukturmodell Anforderungen • Dokumentation von Anforderungen • Management von Anforderungen
  17. 17. Umsetzen von Anforderungen • Wer beschäftigt sich mit Anforderungen? • Strukturmodell Anforderungen • Dokumentation von Anforderungen • Management von Anforderungen
  18. 18. Wer beschäftigt sich im Agilen mit Anforderungen? • Xtreme Programming: Onsite Customer • Scrum: Product Owner Probleme: • Single Ressource • Das funktioniert beim Outsourcing nur bedingt • Gute Leute haben meist keine Zeit übrig
  19. 19. Ein Vorschlag An Anforderungsmanagement Projektleiter Software Produktmanager Kunde
  20. 20. Project - Stakeholder Quelle: www.loggerbleiben.de
  21. 21. Rollen im Projekt Produkt entwickeln Entwickler Software entwicken Tester Anforderungen managen Projektleiter Endbenutzer Produktmanager Big Boss
  22. 22. Aufgaben Produktmanager • Blick zum Markt • Produkt Roadmap ca. 1 Jahr voraus detaillieren • Release Planung grob mit Projektleiter • Release Backlog zusammen mit Projektleiter verwalten (Feature Ebene) • Priorisieren (!) • Akzeptanzkriterien mit Benutzern (und Testern) erarbeiten • Budgetkontrolle • Abnahme von Features und Stories
  23. 23. Aufgaben Projektleiter • Blick zum Projekt • Release Backlog zusammen mit Produkt Manager verwalten • Releaseplanung im Detail • Features in Stories der passenden Grösse aufteilen • Genügend Stories in Zustand ‘Ready’ bringen für Entwicklung • Koordination von Entwicklern + Testern • Spezifikation auf Stand halten • Budgetkontrolle • Reviews
  24. 24. Aufgaben Big Boss • Produkt Vision • Grobe Roadmap für die nächsten Jahre • Budget bereitstellen Bild: distility.com
  25. 25. • Information über Erfordernisse • Typische (und untypische!) Szenarien schildern • Hilfe bei Akzeptanzkriterien • Feldtest Aufgaben Benutzer
  26. 26. Umsetzen von Anforderungen • Wer beschäftigt sich mit Anforderungen? • Strukturmodell Anforderungen • Dokumentation von Anforderungen • Management von Anforderungen
  27. 27. Begriffe Begriff Erklärung Backlog Item Etwas, das im Backlog steht Feature Features werden in Releases realisiert. Sind wie grosse User Stories beschrieben Story Stories werden in Iterationen (Sprint) realisiert. Es gibt verschiedene Arten von Stories. User Story Als Benutzer [A] kann ich [B] tun um [C] zu erreichen Problem Fehlverhalten im gelieferten Produkt Spec Change Etwas passt nicht, war aber auch nicht spezifiziert Other Work Item Technische Stories z.B. Refactoring, Architektur, Planung Acceptance Test Szenarien, mit denen die Funktion eines/r Feature/Story geprüft wird.
  28. 28. Strukturmodell Anforderungen Specification Nonfunctional Requirement Use Case Backlog Item Functional Requirement determines Epic Feature Story User Story Problem Spec Change Other Work Item Task Bug Fix 1..* 1 contains 0..*1 contains 1..* 1 provides context for 0..* 0..* constrains System Qualities Test 0..* 1..* Compliant when passes 0..*1 is implemented by1..*0..1 is realized by1..*0..1 is realized by Story Acceptance Test 1..* 1 is done when passes Feature Acceptance Test 1..* 1 is done when passes Vision Theme 1..* 0..1 is realized by Unit Test 0..* Inspiration: Dean Leffingwell, Agile Software Requirements
  29. 29. Struktur Ausschnitt SpecificationUse Case 1..* 1 contains Nonfunctional Requirement 0..*1 contains Backlog Item 1..* 1 provides context for 0..* 0..* constrains Feature Story 1..*0..1 is realized by Feature Acceptance Test 1..* 1 is done when passes Story Acceptance Test 1..* 1 is done when passes User Story Problem Spec Change Other Work Item Inspiration: Dean Leffingwell, Agile Software Requirements
  30. 30. Umsetzen von Anforderungen • Wer beschäftigt sich mit Anforderungen? • Strukturmodell Anforderungen • Dokumentation von Anforderungen • Management von Anforderungen
  31. 31. Dokumentation von Anforderungen • Die Spezifikation hat nicht ausgedient. • Projektstart auf jeden Fall mit Spezifikation in ausreichendem Detailierungsgrad • Evolution der Anforderungen im Backlog • Rückübertragung vom Backlog in die Spezifikation nach Abnahme eines Features
  32. 32. Auch hier ein Zyklus Spezifikation erstellen/nachführen Features ins Backlog stellen Realisieren
  33. 33. Struktur der Spezifikation • Es gibt viele Beispiele und Vorlagen im Internet  eine auswählen und anpassen. • Wichtig: Die richtigen Fragen stellen! • Richtig: Was tut der Benutzer? • Falsch: Was kann das Programm?
  34. 34. Abnahmekriterien • Abnahmekriterien gehören dazu, wenn ein Feature fertig spezifiziert sein soll • Es ist möglich, diese schon zum Zeitpunkt der Spezifikationserstellung in hoher Qualität fertigzustellen • Man hat immer Zeit nachher zu reparieren, aber nie vorher nachzudenken.
  35. 35. Umsetzen von Anforderungen • Wer beschäftigt sich mit Anforderungen? • Strukturmodell Anforderungen • Dokumentation von Anforderungen • Management von Anforderungen
  36. 36. Management der Anforderungen Ein paar Schlagworte: • Backlog • Release • Features und Stories • Confirmed / Accepted • Defintion of Ready / Definition of Done • Iteration • Backlog Item Lifecycle
  37. 37. Backlog • Enthält Schritte für die Umsetzung der Spezifikation • Sammelbecken für Ideen • Muss durchsuchbar und sortierbar sein • Gegliedert nach Releases • Zugriff für Product Manager ( Hauptaufgabe) • Muss gepflegt werden (Grooming)
  38. 38. Release / Iteration Release 2013 Q1 Release 2013 Q2 Release 2013 Q3… … … …… Iterationen Iterationen Iterationen • Release: Richtgrösse 3 Monate • In Releases werden Features realisiert • Iteration: Richtgrösse 2 – 3 Wochen • In Iterationen werden Stories realisiert
  39. 39. Release Release Planning • Monatlich 1h • Priorisierung von Features und Stories, Aufräumen • Product Manager + Projektleiter Product Roadmap Planning • Planung vierteljährlich 2h-4h • Product Manager + Projektleiter • Roadmap als Schriftstück, das sichtbar ist Plan einhalten! Schnellschüsse vermeiden!
  40. 40. Iteration • Planung alle 2 Wochen durch Entwicklungsteam am Iterationsende / Start • Realisierung von Stories die ‘Ready’ sind durch ‘Tasks’ • Erzeugen eines ‘Potentially Shippable Increment’ • Möglichst keine Änderungen an geplanten Stories während der Iteration • Gleichzeitig vorbereiten der nächsten Iteration durch Projektleiter
  41. 41. Features / Stories • Features werden in Releases realisiert • Stories werden in Iterationen realisiert • Features können in Stories aufgeteilt werden • Stories (und kleinere Features) werden mittels Tasks implementiert • Tasks werden von den Entwicklern angelegt • Tasks werden innert eines Tages erledigt
  42. 42. Priorisieren • 1 Ohne dieses Feature ist das Release nicht brauchbar • 2 Dieses Feature bringt Nutzen und Wert. Ein Fehlen macht das Release aber nicht unbrauchbar. • 3 Nur erledigen wenn noch Zeit vorhanden.
  43. 43. Definition of Ready (DoR) Was ist nötig, damit mit der Entwicklung begonnen werden kann? Bei Creasoft: • Spezifikation erstellt • Grössenschätzung • Grösse passt • Akzeptanzkriterien sind bekannt • OK von Entwicklung + Testern • Risiken betrachtet
  44. 44. Defintion of Done (DoD) Wann ist die interne Entwicklung fertig? Bei Creasoft: • Alle untergeordneten Aufgaben erledigt • Code ist dokumentiert • Code kompiliert ohne Warnungen • Alle automatischen Tests laufen ok • Übersetzungen zu Texten erstellt • Manuell getestet • Falls Review nötig? durchgeführt? • Spezifikation nachgeführt?
  45. 45. Lifecycles von Backlog Items • Verschiedene Arten von Items können verschiedene Lifecycles haben • An die eigenen Firma anpassen • Pragmatisch sein
  46. 46. Lifecycle Story/Feature ohne Stories open confirmed ready (DoR) activated in progress closed accepted done (DoD) in test implemented reject
  47. 47. Lifecycle Feature mit Stories open confirmed in progress closed accepted done reject
  48. 48. Minimize ‘Work in Progress’ • Eine Person sollte nur an einer Sache gleichzeitig arbeiten • Vermeiden von vielen Stories und Tasks die gleichzeitig ‘in progress’ sind. • Arbeiten abschliessen und an Kunden zur Abnahme weiterleiten. • KANBAN
  49. 49. ‘Work in progress’ sichtbar machen • Taskboard • Mittels Zetteln oder elektronisch
  50. 50. Themen • Agiles Anforderungsmanagement? • Arten von Anforderungen • Umsetzen von Anforderungen • Ausblick / Offene Punkte Quelle: Google Bildsuche
  51. 51. Ausblick / Offene Punkte • Verbesserung Backlog Management (Suchen, Gruppieren, Grooming (!), etc.) • DoR / DoD konsequent anwenden • Online Release Planung • Kapazitätsplanung • Generierung der Spezifikation aus DB
  52. 52. Vielen Dank für Ihre Aufmerksamkeit Für Fragen und Diskussion stehen wir gerne zur Verfügung

×