Der Prozess mobiler Entwicklungsprojekte: Muster agiler Methoden: Herausforderungen und Lösungen in der professionellen App-Entwicklung

Von Florian Siebler-Guth

Suchen Sie ein Prozessmodell für ein mobiles Entwicklungsprojekt? Sie fragen sich, nach welchem Prozessmodell Apps in der Praxis entwickelt werden?
Suchen Sie ein Prozessmodell für ein mobiles Entwicklungsprojekt? Sie fragen sich, nach welchem Prozessmodell Apps in der Praxis entwickelt werden? Florian Siebler-Guth zeigt in seinem Buch, dass in der Praxis kein anerkanntes Prozessmodell für mobile Entwicklungsprojekte verwendet wird. Herkömmliche Methoden – Scrum und XP – könnten zwar angepasst werden, sie berücksichtigen aber nicht die Besonderheiten mobiler Entwicklungsprojekte und sind vielen Teams zu formal. Daher fokussiert der Autor auf die Gemeinsamkeiten agiler Methoden, die sogenannten „Muster agiler Methoden“, beispielsweise auf Muster wie „Iteration“ im Sinne eines inkrementell-iterativen Vorgehens oder wie „Informelle Kommunikation“. Basierend auf Interviews mit professionellen App-Entwicklern aus der Praxis wird klar: DieMuster werden in Abhängigkeit vom Entwicklungskontext unterschiedlich gewichtet. Aufbauend auf den Erkenntnissen der geführten Interviews entwickelt Florian Siebler-Guth mit „Crystal Mobile“ ein Prozessmodell für das Mobile App Development. Mit dem gewichteten Musterkatalog und mit „Crystal Mobile“ liefert er einen Werkzeugkasten, der in keiner Software-Schmiede fehlen darf – besonders, wenn darin Apps produziert werden. Ein spannendes Buch für alle, die mehr über Agilität und agile Handlungsweisen, insbesondere in der mobilen Entwicklung erfahren wollen.

• Sprache: Deutsch
• Herausgeber: Springer Vieweg
• Erscheinungsdatum: 25. Feb. 2020
• ISBN: 9783658267315

Buchvorschau

Teil ITheoretischer Teil

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019

F. Siebler-GuthDer Prozess mobiler Entwicklungsprojekte: Muster agiler Methodenhttps://doi.org/10.1007/978-3-658-26731-5_1

1. Das methodische Vorgehen beschreiben

Florian Siebler-Guth¹ 

(1)

Bad Honnef, Deutschland

If something can go wrong, it will – at the worst possible moment.

If nothing can go wrong, it still will.

If nothing has gone wrong, you have overlooked something.

Ed Murphy

In diesem Kapitel lesen Sie, welche Forschungsfrage meine Studie geleitet hat, und wie ich diese beantwortet habe. Ich beschreibe und begründe die Auswahl der Methode und der Werkzeuge. Außerdem benenne ich meine impliziten Annahmen.

1.1 Die Ausgangslage beschreiben

Im Januar 2019 schloss ich mein Masterstudium erfolgreich ab. In meiner Masterarbeit beschäftige ich mich mit dem Prozess der App-Entwicklung. Im vorliegenden Buch stelle ich Ihnen die Studie, die die Grundlage meiner Masterarbeit war, vor.

Was hat mich motiviert, diese Studie durchzuführen? Ich habe zahlreiche Berichte im Internet gelesen und mit einigen professionellen App-Entwicklern gesprochen. Dabei fiel mir auf, dass einige Entwickler angeben, dass sie ihre Projekte in der Regel erfolgreich abschließen. Die Mehrzahl der Berichte zeichnet hingegen ein düsteres Bild. Beispielsweise schreibt Feigl, dass Terminprobleme die Normalität seien und nicht die Ausnahme (siehe Feigl 2013).

Ich entwickle seit Jahren nicht-mobile Software bzw. betreue nicht-mobile Entwicklungsprojekte. Daher habe ich mir zunächst die Frage gestellt, worin sich mobile und nicht-mobile Entwicklungsprojekte unterscheiden. Die zweite Frage, die ich mir stellte, war, ob sich im Prozess erfolgreicher Entwicklungsprojekte Gemeinsamkeiten finden lassen.

Hinweis für weitere Forschung

Ich bezeichne ein Entwicklungsprojekt dann als erfolgreich, wenn Software mit der gewünschten Funktionalität im definierten zeitlichen und finanziellen Rahmen in hoher Qualität ausgeliefert wird.

Es wird Gegenstand weiterer Forschung sein, zu definieren, wann ein Projekt als „erfolgreich abgeschlossen" gelten darf. Dabei ist eine Vielzahl von Fragen zu berücksichtigen, beispielsweise:

Was ist „hohe Qualität"?

Welchen Einfluss hat es, wenn Budget oder Zeitrahmen nur minimal überschritten werden?

Die hier getroffene Festlegung dient lediglich der sprachlichen Vereinfachung.

Lesen Sie die folgenden Abschnitte nicht!

Das restliche Kapitel widme ich der Beschreibung meiner Forschungsmethode und erläutere ausführlich meine Vorgehensweise. Wenn Sie dieses Buch lesen, weil Sie sich eher für die praxisrelevanten Themen interessieren, könnten die folgenden Abschnitte vielleicht langweilig für Sie sein. Springen Sie in diesem Fall lieber zu Kap. 2. Begeben Sie sich direkt dorthin. Gehen Sie nicht über „Los". Ziehen Sie nicht 4000,- Mark ein!

1.2 Die impliziten Annahmen benennen

Keine Studie entsteht in abgeschiedener Einöde, frei von äußeren Einflüssen. Jeder Forscher hat ein bestimmtes Weltbild bzw. trifft Annahmen über die ihn umgebende Welt. Sein Weltbild unterliegt subjektiven Erfahrungen und Bewertungen. Diese Subjektivität ist per se nichts Schlimmes. Der Autor einer Forschungsarbeit muss seine impliziten Annahmen jedoch nennen. Stellen Sie sich vor, Sie leben im Mittelalter und ein Forscher legt Ihnen eine Studie vor, in der er die Frage untersucht, wie weit ein Schiff segeln kann, bis es von der Erde herunterfällt. Diese Studie können Sie nur nachvollziehen, wenn Sie das Weltbild des Forschers („Die Erde ist eine Scheibe") kennen. Wenn Ihr Weltbild davon abweicht, Sie also davon ausgehen, dass die Erde eine Kugel ist, werden Sie die Arbeit beiseitelegen, ohne das Gefühl zu haben, etwas verpasst zu haben. Insofern ist es auch eine Dienstleistung, die der Autor für seinen Leser erbringt, wenn er sein Weltbild offenbart.

Die impliziten Annahmen sind nicht Gegenstand der Forschung, sondern werden im Forschungsprozess als gegeben hingenommen (Brühl 2011). In diesem Abschnitt nenne ich meine impliziten Annahmen und begründe diese in der gebotenen Kürze.

1.2.1 Erste Annahme

Es gibt verschiedene Ansätze, ein Prozessmodell für mobile Entwicklungsprojekte zu definieren.

Der eine Ansatz ist, ein Prozessmodell speziell für mobile Entwicklungsprojekte zu entwickeln. Beispielsweise hat Pekka Abrahamsson 2004 das CMMI-zertifizierte Prozessmodell Mobile-D beschrieben (Abrahamsson 2004). Die erste Handy-App wurde 1983 entwickelt (Alfajhan 2016). Die heutige Smartphone-Ära, in der jeder Apps entwickeln und anbieten kann, begann jedoch erst 2007, als das erste iPhone auf den Markt kam (Schilling 2016, S. 2 ff.; Knoll und Meinhardt 2016 S. 28; Knott 2016, S. 14; Alfajhan 2016). Ich weiß nicht, ob Abrahamsson die Schwierigkeiten mobiler Entwicklungsprojekte so weit im Voraus erahnen konnte. Spataru weist in seiner Masterarbeit außerdem nach, dass Mobile-D die Belange mobiler Entwicklung nicht vollständig abdeckt (Spataru 2010). Im Ergebnis haben Mobile-D, aber auch andere mobile Prozessmodelle wie SLeSS, HME oder MASAM „in der Praxis […] keine große Verbreitung gefunden" (Barton et al. 2016, S. 100).

Ein anderer Ansatz ist, etablierte nicht-mobile Prozessmodelle anzupassen. Beispielsweise konnten Scharff und Verma im Laborversuch zeigen, dass Scrum sich für mobile Entwicklungsprojekte eignet (Scharff und Verma 2010). Die Adaption von Scrum scheint in der Praxis nicht unproblematisch zu sein. Die Interviewpartner haben mehrheitlich geäußert, dass Scrum für mobile Entwicklungsprojekte mit kleinen Entwicklungsteams zu formal bzw. „over-engineered" ist. Außerdem setzt Scrum zwingend ein Team voraus. Gerade in kleinen Teams – oder bei Freelancern – sind die Rollen von Product Owner und Scrum Master nicht eindeutig besetzt.

Ich nehme daher an, dass es für mobile Entwicklungsprojekte kein allgemein anerkanntes, praxisrelevantes Prozessmodell gibt.

1.2.2 Zweite Annahme

Ende der Sechzigerjahre befand die Softwareentwicklung sich in einer Krise, der sogenannten Softwarekrise. Im Oktober 1968 fand auf Initiative des Nato Science Committee eine Konferenz in Garmisch statt, die sich mit den Problemen der Softwareentwicklung beschäftigen sollte. Im Rahmen dieser Konferenz wurde der Begriff Software Engineering geprägt, um die Notwendigkeit ingenieurmäßigen Vorgehens bei der Softwareentwicklung zu betonen. In diesem Zusammenhang wurde auch die Notwendigkeit angesprochen, ein Prozessmodell zu haben. Moritz et al. fassen zusammen, dass die Entwicklung der Informatik vom Handwerk zur Ingenieurwissenschaft, dem Software Engineering, die Antwort auf die Softwarekrise war (Moritz et al. 2010, S. 191).

Ich nehme daher an, dass der Prozess der entscheidende Faktor ist, um Software erfolgreich zu realisieren.

Beschränkung auf den Prozess als Erfolgsfaktor

Die Gründe für Erfolg oder Misserfolg eines mobilen Entwicklungsprojektes können vielfältig sein. Die Interviewpartner haben zahlreiche Gründe genannt, von denen ich einige an dieser Stelle exemplarisch nennen möchte:

Der Markt ist bereits gesättigt.

Der Druck durch die Mitbewerber ist extrem hoch.

Der Auftraggeber hat ein mangelhaftes technisches Verständnis.

Programmierer mit Spezialwissen (z. B. iOS-Programmierer) fehlen.

Da ich den Anspruch meiner Studie auf ein handhabbares Maß beschränken musste, habe ich mich vor dem Hintergrund meiner Annahme entschieden, mich auf den Prozess als relevanten Faktor zu konzentrieren.

1.2.3 Dritte Annahme

Einerseits wird beschrieben, dass plangetriebene Prozessmodelle in der Praxis Anwendung finden, wenn Apps extern entwickelt und Festpreis- bzw. Werkverträge geschlossen werden (Barton et al. 2016, S. 100). Andererseits ist zu lesen, dass mobile Vorhaben den Voraussetzungen für den idealen Einsatz agiler Methoden entsprechen (Abrahamsson 2015). Ich habe Erfahrung mit agilen nicht-mobilen Entwicklungsprojekten und favorisiere den agilen Ansatz.

Ich nehme daher an, dass auch mobile Entwicklungsprojekte eine größere Erfolgsaussicht haben, wenn sie nach agilem Ansatz realisiert werden.

1.2.4 Konsequenz aus den Annahmen

Ich gehe davon aus, dass es kein allgemein verwendetes, praxisrelevantes Prozessmodell gibt. Folglich thematisiere ich in diesem Buch kein bestimmtes Prozessmodell, sondern stelle die Gemeinsamkeiten ausgewählter agiler Methoden, die sogenannten Muster agiler Methoden, in den Vordergrund.

1.3 Die Forschungsfrage formulieren

Aus den vorgenannten Überlegungen resultiert die Forschungsfrage, die meiner Studie zugrunde liegt. Mit leitfadengestützten Interviews möchte ich ermitteln, welche Muster agiler Methoden in den mobilen Entwicklungsprojekten professioneller Entwickler eine Rolle spielen. Für den Gültigkeitsbereich dieser Entwickler frage ich:

Welche Muster agiler Methoden werden angewandt, um mobile Entwicklungsprojekte zu unterstützen?

1.4 Grundlegende Struktur dieses Buches aufzeigen

Dieses Buch gliedert sich in einen theoretischen und einen praktischen Teil.

Im theoretischen Teil beschreibe ich zunächst den Projektverlauf und das methodische Vorgehen. Anschließend definiere ich einige relevante Begriffe. Schließlich benenne ich im Rahmen einer Literaturübersicht die besonderen Herausforderungen mobiler Entwicklungsprojekte.

Im praktischen Teil entwickle ich auf Grundlage der Literaturübersicht einen Fragebogen, der Interviews mit professionellen App-Entwicklern leitet. Die Interviews dienen dazu, herauszufinden, wie die Interviewpartner in der Praxis Apps entwickeln. Den Fragenkatalog teste ich in einem Probeinterview, modifiziere ihn gegebenenfalls und teste ihn erneut. Erst wenn der Test des Fragenkataloges erfolgreich war, führe ich weitere Interviews durch. Ich zeichne diese auf Tonband (Diktiergerät, Skype-Mitschnitt o. ä.) auf und transkribiere sie anschließend. Die Transkripte lese ich mit dem Ziel, zu verstehen, ob ein Muster agiler Methoden aus dem Musterkatalog von Steyer (2010) im Arbeitsalltag des Gesprächspartners eine Rolle spielt. In diesem Fall gilt es als für diesen Gesprächspartner relevant. Um über den Einzelfall hinaus eine Aussage über die Relevanz eines Musters treffen zu können, zähle ich aus, für wie viele Entwickler dieses Muster relevant ist.

Schließlich fasse ich die Arbeit und deren Ergebnisse zusammen und unterziehe sie einer kritischen Betrachtung.

Die Abb. 1.1 zeigt den Ablauf des Projektes im Überblick.

../images/468570_1_De_1_Chapter/468570_1_De_1_Fig1_HTML.png

Abb. 1.1

Überblick: Ablauf des Projektes

1.5 Rückgriff auf sozialwissenschaftliche Methoden begründen

In diesem Buch bearbeite ich ein Thema der Informatik mit Methoden der Sozialwissenschaften. In diesem Abschnitt beschreibe ich das methodische Vorgehen.

1.5.1 Eine Methode auswählen

In diesem Abschnitt beschreibe ich, welche Methoden ich einsetze, nenne Alternativen und begründe die Auswahl meiner Methoden und Werkzeuge.

Der sozialwissenschaftliche Anspruch dieses Buches

Wenn Sie Psychologie studieren, kann es sein, dass sich ein Viertel Ihres Grundstudiums mit Methodenlehre beschäftigt (Hussy et al. 2013, S. 2). Da ich meine Masterarbeit im Bereich des Software Engineering Leadership geschrieben habe, kann ich diesen Erfahrungsschatz nicht vorweisen. Um in die Denk- und Arbeitsweise der Sozialwissenschaften einzufinden, habe ich mich mithilfe mehrerer Lehrbücher in die Materie eingearbeitet. In erster Linie und für eine grundlegende Einarbeitung war das Buch „Forschungsmethoden in Psychologie und Sozialwissenschaften für Bachelor" von Hussy et al. hilfreich; Sie finden das Buch im Literaturverzeichnis (Hussy et al. 2013). Die Praxis qualitativer Sozialforschung habe ich mit Philipp Mayring (2016) vertieft. Details zu Experteninterviews habe ich Gläser und Laudel (2010) sowie Robert Kaiser (2014) entnommen. Wertvolle Hinweise gab mir auch die Einführung von Uwe Flick (2014).

Um meine Arbeit vorzubereiten, habe ich zudem einige mit „gut oder „sehr gut bewertete Masterarbeiten mit dem Augenmerk darauf gelesen, ob ich die theoretischen Konzepte der Lehrbücher in den Masterarbeiten wiederfinde. Meine Arbeit wurde positiv bewertet. Ich gehe daher davon aus, dass ich die sozialwissenschaftliche Methode ordentlich übernommen habe. Da ich aber selbst kein Sozialwissenschaftler bin, möchte ich Ihnen dieses Buch jedoch nicht als „Musterbeispiel" für eine sozialwissenschaftliche Arbeit vorstellen. Sie lesen hier meinen Bericht, wie ich ein Thema der Informatik unter Zuhilfenahme sozialwissenschaftlicher Verfahren und Werkzeuge bearbeitet habe.

1.5.1.1 Leitfadengestützte Experteninterviews

In Abschn. 1.3 habe ich die Forschungsfrage formuliert. Es ist offensichtlich, dass ich, um diese Frage beantworten zu können, viel Wissen über die Praxis mobiler Entwicklungsprojekte (sogenanntes „Spezialistenwissen") aufbauen und auswerten muss. Ich verfüge über dieses Wissen nicht und konnte auch keine Veröffentlichung finden, in der die Realität mobiler Entwicklungsprojekte hinreichend beschrieben worden wäre.

Eine Möglichkeit, an dieses Wissen heranzukommen, wäre, mehrere mobile Entwicklungsprojekte teilnehmend zu begleiten. Dies hätte einerseits den Umfang einer Masterarbeit in einem berufsbegleitenden Studiengang überstiegen. Andererseits, wäre fraglich gewesen, ob professionelle App-Entwickler mich über einen längeren Zeitraum in ihren Geschäftsräumen geduldet und mir ihre Geschäftsgeheimnisse – und möglicherweise auch die ihrer Kunden – offengelegt hätten. Diese Option scheidet aus offensichtlichen Gründen aus. Das Spezialistenwissen musste ich mir also auf andere Art zugänglich machen.

Eine andere Möglichkeit, an das Wissen zu kommen, ist, professionelle App-Entwickler, also Experten auf diesem Gebiet, selbst zu befragen. Anders formuliert: Meine Aufgabe bestand darin, ein Umfeld zu schaffen, in dem die Informanten ihr Wissen auf eine für Außenstehende nützliche Weise kommunizieren können. Dieses Umfeld wird durch die Interviews geschaffen. Ich habe also die „Forschungsfrage in Fragen an [meine] Gesprächspartner" übersetzt (Gläser und Laudel 2010, S. 39).

Die Technik der Datenerhebung ist für Gläser und Laudel (2010, S. 39) die wichtigste Klassifizierung von Interviews. Dabei unterscheiden sie zunächst nach dem Grad der Standardisierung. Denkbar sind vollstandardisierte Interviews, halbstandardisierte Interviews und nichtstandardisierte Interviews (Gläser und Laudel 2010, S. 41).

Für Gläser und Laudel sind bei vollstandardisierten Interviews Fragewortlaut und -reihenfolge, aber auch die Antwortmöglichkeiten vorgegeben. Vollstandardisierte Fragebögen zeichnen sich beispielsweise dadurch aus, dass Sie entweder mit „ja oder „nein antworten können. Alternativ geben Sie eine Zufriedenheit auf einer Skala von 1 bis x an. Diese Interviewform gehört zur quantitativen Sozialforschung.

Quantitative Methode

Die Definition von Hussy et al. (2013, S. 20) ist für mich schlüssig. Daher zitiere ich sie an dieser Stelle:

Die quantitativen Methoden werden im Rahmen der quantitativen Forschung eingesetzt und repräsentieren eine Vorgehensweise zur numerischen Darstellung empirischer Sachverhalte.

Bei halbstandardisierten Interviews sind Fragewortlaut und -reihenfolge vorgegeben, die Antwortmöglichkeiten jedoch nicht. Halbstandardisierte Interviews spielen in der Forschungspraxis eine untergeordnete Rolle (Gläser und Laudel 2010, S. 41).

Merkmal nichtstandardisierter Interviews ist, dass weder Fragewortlaut noch Fragereihenfolge noch die Antwortmöglichkeiten vorgegeben sind. Nichtstandardisierte Interviews gehören zur qualitativen