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:

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

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:

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

Aktivitäten

Ergebnisse

Nächste Schritte

Probleme

KW 33

Aktivitäten

Ergebnisse

Nächste Schritte

KW 34

Aktivitäten

Ergebnisse

Nächste Schritte

Probleme

KW 35

Ergebnisse

KW 36

Ergebnisse

KW 37

Ergebnisse

Ergebnisse

KW 38

Ergebnisse

KW 39

Ergebnisse

KW 40

KW 41

KW 42

KW 43

KW 44

KW 45

KW 46

KW 47

KW 48

KW 49-52

KW 1-4

KW 5-13

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