Sicherstellen der Betrachtung von nicht-funktionalen Anforderungen in SCRUM- Prozessen durch Etablierung von Feedback

Transkript

1 Sicherstellen der Betrachtung von nicht-funktionalen Anforderungen in SCRUM- Prozessen durch Etablierung von Feedback Gregor Engels, Silke Geisen, Olaf Port, Stefan Sauer 4. Workshop: Vorgehensmodelle in der Praxis - Evolution und Wandlungsfähigkeit 29.September 2009

2 Motivation Ziel agiler Projekte: schnell neue Funktionalität liefern! Problem: Hauptfokus Funktionalität => häufig fehlen nicht-funktionale Anforderung im Product Backlog Mögliche Konsequenzen:??? Lösungsidee: Feedback etablieren durch zusätzliche Tätigkeit 2

3 Scrum-Flow Probleme P2 Fehlende nicht-funktionale Anforderungen P2 Fehlende nichtfunktionale Anforderungen P1 Hauptfokus Funktionalität P5 Zu wenig Zeit für NF-Test P4 Zu kurzes Review-Meeting P3 Kein bzw. zu wenig Feedback Quelle: Boris Gloger: Scrum,

4 Lösungsansatz (1) Einführung einer neuen QS-Tätigkeit durch den Kunden: QS-Tage Sprint Planning 1 Selected Product Backlog Sprint Planning 2 Retrospektive New Scrum Flow Sprint Backlog RESULT 1-3 QS-Tage n day sprint every 24 hours Neue Funktionalität QS-Tätigkeit durch Kunde QS-Tage Sprint 4

5 Lösungsansatz (2) n day sprint every 24 hours Neuer Task wird beachtet und bearbeitet P1, P2 1-3 QS-Tage P4 Neuer Eintrag/Task im Sprint Backlog QS-Tätigkeit durch Kunde QS-Tage Konkretes User-Feedback P3 Neue Planung nicht ok ok RESULT Zusätzlich: Anwendertage und Performanztests in Kunden- Umgebung, z.b. am 3. QS-Tag (P5) 5

6 Lösungsansatz Ergebnis P2 Fehlende nicht-funktionale Anforderung P1 Hauptfokus Funktionalität P2 Fehlende nichtfunktionale Anforderung P5 Zu wenig Zeit für NF-Test P4 zu kurzes Review-Meeting P3 Kein/ zu wenig Feedback 6

7 Evaluierung in der Praxis (1) Projekt bei der S&N AG: Entwicklung einer Web-Anwendung Wenig Erfahrung mit agilen Vorgehensweisen Vorgehensweise angelehnt an Scrum: 30-tägige Sprints Team: Größe variiert zwischen 8-15 Personen, interdisziplinär Daily Scrum 2 mal wöchentlich Minuten => Product Owner und Scrum Master nicht vor Ort Product Owner: Kunden-Team von 5 Personen Zusätzliche Person für Qualitätssicherung 7

8 Evaluierung in der Praxis (2) Einführung der QS-Tage bei S&N während des laufenden Projektes Anpassung der QS-Tage von Sprint zu Sprint: Zunächst 1 Tag später Erweiterung auf 3 Tage Interdisziplinäres Kunden-QS-Team aus IT-Spezialisten QS-Team gibt Feedback & erstellt ggf. neue PBL-Einträge QS-Team nimmt neue Funktionen ab Ab Sprint 7 regelmäßige Last-Tests in Kundenumgebung und Anwendertage 8

9 Evaluation (2) Beispiel Performanz Performanz wird sichtbar Performanz wird optimiert Stabilität Performanz durch weitere Betrachtung 9

10 Evaluierung in der Praxis (2) Ergebnisse: Durch Feedback rückten nicht-funktionale Anforderungen in den Fokus => Beispiel Performanz Wichtigkeit der Performanz wird dem Kunde bewusst => Aufnahme ins Product Backlog + dessen Priorisierung Dynamische Anpassung der Priorisierung beim Auftreten von Problemen Evolution und Anpassung des gesamten Prozesses im laufenden Projekt 10

11 Zusammenfassung und Ausblick Erweiterung des Scrum-Prozesses durch QS-Tätigkeit Zusätzliche Anwendertage und Lasttests Lösung bzw. Minimierung der Probleme (P1 P5) Anpassung des Scrum-Prozesses während des laufenden Projekts und von Sprint zu Sprint möglich Nicht-funktionale Anforderungen gelangen in Fokus =>Bewusstseinsschärfung von Kunde und Team => auch nicht-funktionale Anforderung im PBL => nicht-funktionale Probleme werden zum richtigen Zeitpunkt entdeckt und entsprechend priorisiert Nicht-gelöstes Problem: Initiale Betrachtung nicht-funktionaler Anforderungen 11

12 Vielen Dank für Ihre Aufmerksamkeit! Software Quality Lab (s-lab) Universität Paderborn Warburger Str Paderborn Tel.: / ,