von nicht-funktionalen Prozessen durch Etablierung von Feedback REConf März 2010

Transkript

1 Sicherstellen der Betrachtung von nicht-funktionalen Anforderungen in SCRUM- Prozessen durch Etablierung von Feedback Silke Geisen REConf März 2010

2 Software Quality Lab Wissenschaft Industrie Offenes Multi Private Public Partnership (Multi-PPP) Institut (Gründung 2005) Kompetenz- & Technologietransfer zu Themen der Softwaretechnik Erhöhung der Qualität in der industriellen Softwareentwicklung Impulse und damit die qualitative Verbesserung der universitären Forschung und Lehre Fünf Hochschullehrer h h Acht assoziierte Industriepartner + zehn Projektpartner Software Quality Lab (s-lab) 2

3 Kooperationsformen Forschungs- und Entwicklungsprojekte Auftragsforschung Gemeinsame Förderprojekte (BMBF, EU, usw.) Kleinprojekte (Studien, Beratung, Entwicklung) Bachelor-/Masterarbeiten Schulungen/Workshops Praktikum gemeinsame Marketing-Aktionen (Messe, usw.) Bilaterale und Multilaterale Projekte Software Quality Lab (s-lab) 3

4 Die Partner des s-lab Assoziierte Partner Projektpartner Software Quality Lab (s-lab) 4

5 Agenda Motivation Probleme Lösungsansatz Evaluierung in der Praxis Zusammenfassung und Ausblick Software Quality Lab (s-lab) 5

6 Motivation Ziel agiler Projekte: schnell neue Funktionalität liefern! Problem: Hauptfokus Funktionalität => häufig fehlen nicht-funktionale Anforderungen im Product Backlog Mögliche Konsequenzen:??? Lösungsidee: Feedback etablieren durch zusätzliche Tätigkeit Software Quality Lab (s-lab) 6

7 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, 2008 Software Quality Lab (s-lab) 7

8 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 Neue Funktionalität Software Quality Lab (s-lab) 1-3 QS-Tage QS-Tätigkeit durch Kunde QS-Tage n day sprint every 24 hours Sprint 8

9 Lösungsansatz (2) n day sprint every 24 hours Neuer Task wird beachtet und bearbeitet 1-3 QS-Tage P1, P2 P4 Neuer Eintrag/Task im Sprint Backlog QS-Tätigkeit durch Kunde QS-Tage Konkretes User-Feedback P3 Neue Planung nicht ok ok RESULT Software Quality Lab (s-lab) 9

10 Lösungsansatz (3) Zusätzlich: Anwendertage und Performanztests in Kunden-Umgebung, z.b. am 3. QS-Tag (P5) Zusätzliches Feedback durch Integration von Fachanwendern Planung von Usability Tests möglich Nicht-automatisierter Performanztest live mit konkreten Nutzern möglich Automatisierte ti i t Last- und dperformanztests t in Kundenumgebung während der QS-Tage Software Quality Lab (s-lab) 10

11 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 Software Quality Lab (s-lab) 11

12 Evaluierung in der Praxis S&N AG Gründung Umwandlung zur AG, nicht börsennotiert Aktuell ca. 200 Mitarbeiter i an verschiedenen Standorten Zentrale in Paderborn Niederlassungen in Parsberg, Eschborn (Rhein-Main), München, Berlin Softwareentwicklung und Beratung insbesondere für die Finanzindustrie Software Quality Lab (s-lab) 12

13 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 Software Quality Lab (s-lab) 13

14 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 Software Quality Lab (s-lab) 14

15 Evaluation (3) Beispiel Performanz Performanz/ Antwortzeiten (AZ) Priorisierung der Performance Absturz der Anwendung Erhebliche Verlangsamung AZ > 20 sec Hoch sehr langsam 8 sec < AZ < 20 sec langsam 4 sec < AZ < 8 sec Mittel akzeptabel 2 sec < AZ < 4 sec Gut/ Flüssig AZ < 2 sec 1 Stunde 2 Stunden 4Stunden 6 Stunden 8 Stunden > 8 Stunden Niedrig Sprint 1-5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 7 Sprint 8 Sprint 9 Sprint 10/ 11 Keine Betrachtung Interne Betrachtung Sichtbare Betrachtung durch PBL-Eintrag Performanz wird sichtbar Performanz wird optimiert Stabilität Performanz durch weitere Betrachtung Software Quality Lab (s-lab) 15

16 Evaluierung in der Praxis (4) 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 Software Quality Lab (s-lab) 16

17 Zusammenfassung 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 richtigen Zeitpunkt entdeckt und entsprechend priorisiert Software Quality Lab (s-lab) 17

18 Ausblick Übertragbarkeit auf weitere nicht-funktionale Anforderungen Initiale Betrachtung nicht-funktionaler Anforderungen? => Frage: Wann ist genau der richtige Zeitpunkt, um nicht-funktionale Anforderungen aufzunehmen? Weitere Details zu finden unter: Gregor Engels, Silke Geisen, Stefan Sauer, Olaf Port: Sicherstellen der Betrachtung von nichtfunktionalen Anforderungen in SCRUM-Prozessen durch Etablierung von Feedback. In Stefan Fischer, Erik Maehle, Rüdiger Reischuk (eds.): Informatik Im Focus das Leben., LNI, vol. 154, pp. 458 (2009) Weitere Fragen? Dann kontaktieren sie mich unter: sgeisen@s-lab.upb.de Software Quality Lab (s-lab) 18

19 Qualität ist kein Zufall Software Quality Lab (s-lab) Universität Paderborn Warburger Str Paderborn Tel.: / , Software Quality Lab (s-lab) 19