Qualitätserlebnis statt Qualitätssicherung. Eine Mehrfachfallstudie agiler Teams

bearbeitet von: Holger Schmeisky

Expose

In meiner Masterarbeit werde ich in einer Mehrfachfallstudie untersuchen wie 2 Berliner Softwareunternehmen auf untraditionelle Weise externe ihre Qualität sichern und warum das funktioniert

Traditionelle Qualitätssicherung versucht Testen und Entwicklung möglichst getrennt zu halten um beste Ergebnisse zu erzielen, während agile Entwicklung Testen und Entwicklung (und damit Qualitätssicherung) eng integriert [1]. Die agile Qualitätssicherung wird von Vertretern der traditionellen Qualitätssicherung mit Skepsis betrachtet, und sie fürchten dass unter Ihnen die Qualität leidet. Leider gibt es zur agilen Qualitätssicherung nur wenig empirische Forschung ([3],[4]).

Daher möchte ich folgende Frage untersuchen:

• Wie und unter welchen Bedingungen funktioniert agile Qualitätssicherung? Wenn sie gut funktioniert, warum funktioniert sie?

Ich habe Unternehmen gesucht, in denen ich diese Forme der Qualitätssicherung beobachten kann und habe zwei gefunden:

• SoundCloud (http://www.soundcloud.com) - Musikstreamingwebsite, ca. 100 Entwickler
• Immobilienscout24 (http://www.immobilienscout24.de u.a.) - Immobilienportal (und andere), ca. 100 Entwickler

Beide Firmen betreiben Webplattformen, sind aber hinreichend verschieden. Statt Entwickler und Tester, die in seperaten Abteilungen arbeiten hintereinander arbeiten, ist die Qualität zu sichern feste Verantwortlichkeit des Entwicklers und eng mit dem Entwickeln verbunden.

Die Firmen möchte ich in einer Mehrfachfallstudie untersuchen [2]. Der Unit of Analysis ist das Team, da es in den untersuchten Firmen keine Firmenweite QS-Strategie gibt, sondern jedes Team seine eigene Variante.

Die Hauptdatenquelle werden semi-strukturierte Interviews mit mindestens einem Entwickler jeder Organisation und mit jemanden, der gegenüber der Geschäftsleitung verantwortlich für die Qualität der Software ist. Da ich keine der Firmen von innen kenne, werde ich versuchen vorher einen Entwickler mehrere Tage bei der Arbeit zu begleiten, um mir "stilles Wissen" um die Firma, die Software, die Arbeitsabläufe und das ganze drumherum zu sammeln. Eventuell werde ich noch weitere Datenquellen benutzen. Bei Souncloud und Firma B besteht sicher die Möglichkeit einen Qualitätsverantwortlichen zu interviewen, bei Firma C muss ich noch fragen.

Die Untersuchungen in den Firmen werde ich iterativ durchführen, um immer Zeit und Möglichkeit für Anpassungen zu lassen und in die Firmen zurückzukehren um weitere Daten zu sammeln. Beginnen möchte ich ungefähre Ende Juli 2013 und fertig sein um März 2014:

• Literaturrecherche, Methodik und Instrumente
• SoundCloud Daten sammeln
• SoundCloud anfangen zu analysieren
• Immobilenscout24 Daten sammeln und erste Gemeinsamkeiten identifizieren
• SoundCloud mit vorhandenen Daten zu Ende analyieren
• daraus und aus erstem IS24 Eindruck neue Fragen an SoundCloud formulieren, Hypothesen skizzieren
• IS24 analysieren
• Hypothesen formulieren und zweite Datensammlung um sie zu beantworten designen
• Zweite Datensammlung in beiden Firmen
• abschließende Analyse
• Vorbereitung der Ergebnisse als Masterarbeit

Bie Fallstudien ist es schwierig als bei anderen Forschungsmethoden die Validität zu gewährleisten, da der meiste Teil der Arbeit qualitativ ist und es kein einheitliches Vorgehen gibt. Ich werde explizit auf Methoden zur Sicherung der Validität eingehen, u.A. werde ich die Ergebnisse in einer Datenbank in einer Form sammeln, dass andere sie analysieren können und bei meiner eigenen Analyse eine klare Beweiskette von den Schlüssen bis zu den Daten herzustellen.

Ich hoffe mit der Studie eine Antwort auf die Frage zu finden, wie diese Firmen mit ihren unkonventionellen QS-Methoden externe Qualität sicherstellen.

Ergebnisse

Ziel der vorliegenden Arbeit war es, die Qualitätssicherung in agilen Teams zu untersuchen. Dieses Ziel wurde gewählt, weil die Forschung, wie im entsprechenden Kapitel gezeigt wurde, zu diesem Thema eine Lücke aufweist. Um dieses Ziel zu erreichen, habe ich eine explorative Mehrfachfallstudie in mehreren agilen Teams durchgeführt. Diese Methode habe ich erfolgreich angewendet und als wesentliches Ergebnis, als Gegensatz zu traditioneller Qualitätssicherung, das Qualitätserlebnis herausgearbeitet.

Ein weiteres wichtiges Ergebnis sind die umfangreichen Daten zu den Teams. Sie stehen im Netzwerk der Freien Universität zur Verfügung und können von anderen Forschern für weitere Untersuchungen verwendet werden. Die weiteren Ergebnisse, wie die Probleme mit Integrationstests, die Verwendung nur sehr weniger Kommentare, die Auswirkungen des Bereitschaftsdienstes, die Rolle der separaten Tester und des Engineer in Test können Ausgangspunkt für weitere Untersuchungen sein.

Zwei der drei untersuchten Teams arbeiten ohne nachgelagerte Qualitätssicherung. Sie entwickeln schnell, aber sicher, weil sie ein starkes Qualitätserlebnis haben. Die Feedbackschleife für die Qualität ihrer eigenen Arbeit ist sehr kurz und sehr stark. Dadurch entdecken und korrigieren sie Abweichungen in der Qualität sehr schnell.

Für Forschung und Praxis sind die Gründe für dieses starke Qualitätserlebnis von hoher Relevanz. Um diese Gründe zu identifizieren, habe ich die Unterschiede und Gemeinsamkeiten der Fälle verglichen und folgende Säulen für die Stärke des Qualitätserlebnis herausgearbeitet: Die Fähigkeit, (1) hohe Qualität zu erzeugen, (2) die Qualität der eigenen Arbeit zu erkennen und (3) das Schicksal des Produkts zu bestimmen. Die Fähigkeit hohe Qualität zu erzeugen hängt von einer guten, deutlichen Produktivision und der Fähigkeit hohe interne Qualität zu erzeugen, ab. Die Fähigkeit, die Qualität der eigenen Arbeit zu erkennen hängt von der Zeit bis zur Veröffentlichung von Änderungen, automatisiertem Feedback, Überwachung der Software im Betrieb und klaren Grenzen in der Software ab. Die Möglichkeit, das Schicksal des Produkts zu bestimmen hängt von der Motivation der Entwickler, ihrer Möglichkeit die Entwicklung des Produkts mit zu bestimmen, ob von ihnen Rechenschaft gefordert wird, ob sie die Verantwortung für die Veröffentlichung tragen und wiederum von klaren Grenzen in der Software ab. Interessanterweise ist der zugrundeliegende Faktor, der fast alle anderen stark beeinflusst, die Modularisierung auf Teamebene. Wenn ein Team ein Modul alleine kontrollieren kann, können die Faktoren für ein starkes Qualitätserlebnis besser umgesetzt werden.

Wöchentlicher Status

KW 32

• Begleitung bei Soundcloud

Aktivitäten

• Entwickler begleitet

Ergebnisse

• Firma ausreichend kennengelernt, um Interview zu führen

Nächste Schritte

• Interview vorbereiten

Probleme

• Wie soll ich die Daten organisieren?

KW 33

• Vorbereitung der Interviews

Aktivitäten

• Daten gesichtet
• Fragen formuliert
• Literatur zu Interviews gelesen

Ergebnisse

• Fühle mich auf Interview mit Entwickler vorbereitet

Nächste Schritte

• Interview vorbereitenFirma ausreichend kennengelernt, um Interview zu führen

KW 34

• Interview mit Entwickler und Sean

Aktivitäten

• Entwickler interviewen
• Datenanalyse vorbereiten
• Datenanalyse anfangen
• Sean interviewen

Ergebnisse

• Interview geführt
• Tool angeschaut und installiert

Nächste Schritte

• Daten analysieren

Probleme

• Zuviele Daten
• Sean hatte keine Zeit, Interview musste vertag werden

KW 35

• Interview mit QA Engineer
• Urlaub

Ergebnisse

• Interview mit QA Engineer

KW 36

• Sean interviewen
• Unit of Analysis mit Franz diskutieren
• SoundCloud Bericht grob beginnen
• Kontakt zur nächsten Firma aufbauen

Ergebnisse

• Interview mit Sean geführt

KW 37

• Datenanalyse durch Bericht schreiben
• Kontakt zu immoscout aufbauen

Ergebnisse

• Kontakt zu Immoscout Entwickler hergestellt, gehe nächste Woche zu einem Treffen
• Soundcloud Bericht zu Firma, Kontext des Teams grob fertig

Ergebnisse

KW 38

• SoundCloud Bericht grob fertigstellen (insb QS-Strategie und Interviews analysieren)
• Review mit Tobi (gegen Ende der Woche)
• immoscout Entwickler kennenlernen

Ergebnisse

• Interviews analysiert
• Story im Bericht gefunden
• Nur den Kontext fertig

KW 39

• SoundCloud Bericht grob fertig stellen
• immoscout Vorstudie

Ergebnisse

• immoscout Vorstudie durchgeführt, fühle mich vorbereitet auf das Interview
• Studiendesign eventuell anpassen: Kernapplikation bei immoscout als 3. Fall?
• SoundCloud Bericht ist noch nicht fertig

KW 40

• Urlaub
• SoundCloud Bericht grob fertigstellen, damit Franz ihn lesen kann

KW 41

• Interviews bei Immoscout
• Interviews durchhören und abtippen
• Review SoundCloud Bericht durch Franz

KW 42

• SoundCloud überarbeitung mit Franzs Kommentaren
• Antrittsvortrag vorbereiten

KW 43

• SoundCloud überarbeitung
• Mit Franz erste Hypothesen ausarbeiten vom ersten Eindruck IS24

KW 44

• SoundCloud grob fertigstellen, nochmal Franz geben
• Review SoundCloud durch Tobi
• Hypothesen skizzieren
• Immobilienscout vielleicht anfangen

KW 45

• SoundCloud letzte Überarbeitung vor nächster Runde
• Immobilienscout Analyse

KW 46

• Immobilienscout Analyse

KW 47

• Immobilienscout Analyse

KW 48

• Hypothesen formulieren. Nächste Runde Datensammlung vorbereiten
• Nächste Runden Datensammlung bei beiden Firmen

KW 49-52

• Analyse neuer Daten, einbauen, Hypothesen prüfen

KW 1-4

• Nochmal Review durch Entwickler
• Weitere Analyse

KW 5-13

• Weitere Analyse
• Das ganze in eine Abschlussarbeit gießen

Literatur

[1] Itkonen, J.; Rautiainen, K. & Lassenius, C. Towards understanding quality assurance in agile software development ICAM 2005, 2005

[2] Runeson, P. & Höst, M. Guidelines for conducting and reporting case study research in software engineering Empirical Software Engineering, Springer, 2009, 14, 131-164

[3] Talby, D.; Keren, A.; Hazzan, O. & Dubinsky, Y. Agile software testing in a large-scale project Software, IEEE, IEEE, 2006, 23, 30-37

[4] Kettunen, V.; Kasurinen, J.; Taipale, O. & Smolander, K. A study on agility and testing processes in software organizations Proceedings of the 19th international symposium on Software testing and analysis, 2010, 231-240

Comments