Scrum als Framework für die Entwicklung von Apps

Using Scrum as a framework for developing apps


Projektarbeit, 2012
33 Seiten, Note: 1,0

Leseprobe

Inhaltsverzeichnis

Abbildungs-, Tabellen- und Abkürzungsverzeichnis

1.Einleitung

2.Projektmanagement
2.1 Herkömmlich-klassisch versus agiles Projektmanagement
2.2 Scrum als Vorgehenskonzept 1o

3.Herausforderungen bei der Entwicklung von Apps
3.1 App-Entwicklung versus Projektmanagement-Konzepte
3.2 Anforderungen der App-Entwicklung an ein Projektmanagement-Konzept

4.Anwendungen
4.1 Allgemein
4.2 Case

5.Fazit

Literatur

Abbildungs-, Tabellen- und Abkürzungsverzeichnis

Abb. 1: Das "Magische Dreieck" des Projektmanagements

Abb. 2: Sequentielles Vorgehensmodell

Abb. 3: Entscheidungsmodell nach Boehm und Turner

Abb. 4: DerScrum Fluss

Tabelle 1: Klassifikation von Apps

1. Einleitung

Die Bedeutung von mobilen Endgeräten und sozialen Netzwerken wächst ständig. So ist für 2013 prognostiziert, dass mehr Zugriffe auf Webseiten von mobilen Endgeräten als von Desktop-Rechnern erfolgen. Allein im Jahr 2011 wurden weltweit 472 Millionen Smartphones verkauft (Gartner 2012). Das soziale Netzwerk Facebook hat innerhalb von ca. 5 Jahren 838 Millionen Teilnehmer für seinen Dienst gewinnen können (Allfacebook.com 2012). Treiber dieser Entwicklungen sind unter anderem sogenannte Apps - kurz für Applications - Programme, die auf mobilen und sozialen Plattformen aufsetzen und diese um vielfältige Funktionen erweitern. Dabei erstreckt sich die Bandbreite der verfügbaren Apps von einfachen Programmen für die Anzeige von Erste-Hilfe-Maßnahmen bis hin zu komplexen Business-Applikationen, die über Backend Prozesse den Zugriff auf Unternehmensdaten beispielsweise in CRM- oder ERP-Systemen ermöglichen. Die Beliebtheit sozialer Netzwerke wie beispielsweise Facebook ist nicht zuletzt durch Spiele-Apps des Herstellers Zynga mit Erfolgs-Apps wie Farmville oder Angry Birds getrieben, die Millionen von Teilnehmern täglich mehrere Stunden in den sozialen Netzwerken verbringen lassen. Jeden Tag werden ca. 20 Millionen Apps auf Facebook installiert (Levy 2012, S. 127). Die aufgezeigten Fakten zeigen eindrucksvoll die Relevanz von Apps im Bereich der Software- Entwicklung.

Die IT-Projektmanagement hat sich parallel dazu in den letzten 10 Jahren stark verändert. Zu den herkömmlich-klassischen Ansätzen (z. B. Wasserfall- oder V-Modell) kamen neue agile Methoden hinzu, die für mehr Flexibilität und Geschwindigkeit stehen und damit den immer dynamischer werdenden globalisierten Märkten und dem damit verbundenen Ruf nach kürzeren Time-to-Markets gerecht werden. Ein beliebtes agiles Projektmanagement- Konzept ist Scrum, das als Framework bezeichnet wird und viele Anhänger gefunden hat.

Das Ziel der vorliegenden Arbeit ist die Untersuchung von Scrum in Hinblick auf den Einsatz in App-Entwicklungsprojekten. Apps, die vornehmlich zur Erweiterung der Funktionen mobiler Endgeräte oder sozialer Netzwerke dienen, sind hoher Marktdynamik unterworfen. Scrum als agiler Ansatz könnte auf Grund der benötigten Flexibilität und EntwicklungsGeschwindkeit ein erfolgversprechendes PM-Konzept für App-Projekte sein.

Nach der Einleitung wird im zweiten Kapitel der herkömmlich-klassische Projektmanagement-Ansatz den agilen Ansätzen gegenübergestellt und anschließend Scrum als konkretes Vorgehenskonzept dargestellt. Im Folgenden dritten Kapitel werden die Besonderheiten bei der Software-Entwicklung von Apps herausgearbeitet und die daraus resultierenden Anforderungen an das Projektmanagement aufgezeigt. Im vierten Kapitel wird erst allgemein und dann anhand eines realitätsnahen Case dargestellt, ob und wie Scrum im Rahmen der App-Entwicklung eingesetzt werden sollte. Im abschließenden fünften Kapitel wird ein Fazit gezogen und der Ertrag der Arbeit für das Forschungsgebiet aufgezeigt. Zudem soll ein Ausblick auf zukünftige Herausforderungen im Bereich der App-Entwicklung gegeben und der weitere Forschungsbedarf aufgezeigt werden.

2. Projektmanagement

2.1 Herkömmlich-klassisch versus agiles Projektmanagement

Unter einem Projekt soll in Anlehnung an das Projektmanagement-Handbuch von Kuster et al. (2011b, S. 5) ein einheitliches, bereichsübergreifendes Vorhaben verstanden werden, welches zeitlich begrenzt, zielgerichtet, interdisziplinär und derart wichtig, kritisch und dringend ist, dass eine eigene Organisation außerhalb der Linie dafür geschaffen werden muss. Projektmanagement umfasst „alle planenden, überwachenden, koordinierenden und steuernden Maßnahmen, die für die Um- oder Neugestaltung von Systemen oder Prozessen bzw. Problemlösungen erforderlich sind“ (Kuster et al. 2011c, S. 8).

Die vorliegende Arbeit fokussiert auf die Projektart IT-Projekte. IT-Projekte haben die Entwicklung von Informations- und Kommunikationssystemen zum Ziel (Wieczorrek und Mertens 2011, S. 11). Projektmanagement wird hier also im Sinne von Management von Software-Entwicklungsprojekten verstanden.

Das „Magische Dreieck“ des Projektmanagements stellt die zentralen Eigenschaften dar, die ein Projekt auszeichnen. Der Termin zu dem das Projektziel erreicht werden muss, die Kosten, die maximal für die Zielerreichung anfallen dürfen und der Inhalt, der für das Erreichen des Projektziels zu erschaffen ist. Die Eigenschaften stehen dabei an den Ecken eines gleichseitigen Dreiecks.

Abb. 1: Das "Magische Dreieck" des Projektmanagements (Bohinc 2010, S. 20)

Abbildung in dieser Leseprobe nicht enthalten

Eine zentrale Aussage dieser Darstellung ist, dass eine Eigenschaft nicht verändert werden kann, ohne dass sich mindestens eine weitere Eigenschaft ebenfalls verändert. Von dem Fertigstellungstermin ist die Anzahl der benötigten Mitarbeiter und somit auch der Umfang des Projekts abhängig. (Bohinc 2010, S. 20). Soll ein Projekt früher fertig gestellt werden, muss sich der Inhalt verändern (reduzieren) oder die Kosten erhöhen (mehr Personal). Die zur Verfügung stehenden Möglichkeiten zur Projektsteuerung definieren Vorgehensmodellen, auf welche nachfolgend eingegangen wird.

Der Projektprozess von IT-Projekten kann in wiederkehrende, gleichförmige Phasen unterteilt werden, die eine gleichförmige Abwicklung ermöglichen. Daher sind einheitliche Verfahren, die sogenannten Vorgehensmodelle zur Entwicklung der Software einzusetzen (Wieczorrek und Mertens 2011, S. 11f). Unter einem Vorgehensmodell versteht man abstrakte, generische Beschreibungen des Systementwicklungsprozesses (Ferstl und Sinz 2008, S. 484). Prozess soll hier nach dem IEEE-Standard 610.12 (1990) als „a sequence of steps performed for a given purpose […]” verstanden werden (IEEE 1990). Vorgehensmodelle schaffen einen Rahmen für das Projekt, wobei sie das Was und nicht das Wie aufzeigen (Grechenig 2010, S. 412).

Kennzeichnend für sequentielle Vorgehensmodelle ist, dass am Ende einer Phase ein prüfbares Phasenprodukt erzeugt wird und jede nachfolgende Phase erst starten kann, wenn die Vorherige abgeschlossen ist. Zudem kann das fertige Produkt gegen die in der Spezifikation festgehaltenen Anforderungen geprüft werden (Ruf und Fittkau 2008, S. 30). Die Abbildung 2 zeigt die aufeinander folgenden Phasen des sequentiellen Vorgehensmodells.

Abb. 2: Sequentielles Vorgehensmodell (Ruf und Fittkau 2008, S. 30)

Abbildung in dieser Leseprobe nicht enthalten

Exemplarisch für sequentielles Vorgehen soll nachfolgend auf das Wasserfallmodell eingegangen und seine Vor- und Nachteile aufgezeigt werden. Laut Grechenig sieht das Wasserfallmodell die Phasen Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb vor (Grechenig 2010, S. 374). Ferstl und Sinz nennen die Phasen Projektplanung, Anforderungsanalyse und -Definition, Softwareentwurf, Realisierung sowie Abnahme und Einführung (Ferstl und Sinz 2008, S. 478). In dieser Arbeit soll der Definition von Ferstl und Sinz gefolgt werden, um den Projektcharakter der Software-Entwicklung stärker hervorzuheben.

In der Phase der Projektplanung wird das Projekt initiiert und der Projektplanungsauftrag erstellt. Zudem werden in einem Lastenheft die fachlichen Anforderungen an das Produkt aus Auftraggeber-Sicht spezifiziert. In der nachfolgenden Phase der Anforderungsanalyse und -Definition wird aus dem Lastenheft das Pflichtenheft erstellt, welches die vollständigen fachlichen Anforderungen aus der Sicht des Auftragnehmers enthält. Nach deren Abnahme beginnt die Phase des Systementwurfs, die aus dem Software-Systementwurf und dem Software-Komponentenentwurf besteht. Wurden die Teilsysteme in Komponenten zerlegt beginnt die Phase der Realisierung mit der Codierung und dem Test der Komponenten. Nach deren Integration in ein Gesamtsystem und dem Testen, wird die Software mit der erstellten Systemdokumentation im Rahmen der Phase der Abnahme und Einführung beim Auftraggeber in Betrieb genommen (Ferstl und Sinz 2008, S. 480). Der sequenzielle Prozess setzt voraus, dass die Anforderungen bereits zu Beginn des Projektes bekannt sind (Tiemeyer 2010, S. 19).

Ein Vorteil des Wasserfallmodells ist das einfache Messen des Projektfortschritts. Durch die sequentielle Vorgehensweise ist jederzeit festzustellen, in welcher Phase man sich gerade befindet (Ferstl und Sinz 2008, S. 485). Das Wasserfall-Modell ist für IT-Projekte vorteilhaft, bei denen kaum bzw. keine Änderungen der Anforderungen während der Realisierung der Software anfallen (Ruf und Fittkau 2008, S. 31).

Ein Nachteil des Wasserfallmodells ist das vollständig sequentielle Vorgehen, was als inhärentes Risiko erachtet wird (Grechenig 2010, S. 375). In der Praxis ist es in größeren Projekten zur Entwicklung von Software kaum möglich, sämtliche fachlichen Anforderungen vollständig vor Beginn von Systementwurf und Realisierung zu spezifizieren (Ferstl und Sinz 2008, S. 485). Das sequenzielle Dilemma bedeutet, das je innovativer eine IT-Lösung ist, desto weniger ist zu Beginn des Projekts über die erforderlichen Eigenschaften bekannt und desto dynamischer eine Branche ist, desto stärker wandeln sich die Anforderungen im Verlauf des Projekts (Nehfort 2011, S. 415). Als Defizit sämtlicher Prozessmodelle, die auf der sequentiellen Durchführung von Phasen beruhen, nennt Grechenig das Fehlen einer

Möglichkeit zur schnellen Reaktion auf Veränderungen der Anforderungen in der Projektdurchführung (Grechenig 2010, S. 373). Muss der Plan geändert werden, ist ein Rückschritt in eine frühere Phase notwendig, der mit hohen Kosten und viel Aufwand einhergeht (Eckkrammer et al. 2010, S. 81).

Ein weiterer Nachteil ist, dass die User nur zu Beginn und am Ende in die Entwicklung involviert werden, wobei die Dauer zwischen Projektidee und Inbetriebnahme lange sein kann (Ruf und Fittkau 2008, S. 31). Sieht der Auftraggeber das Produkt am Ende des Projektes zum ersten Mal, kommt es auf Grund des subjektiven Interpretationsspielraums häufig zu Abweichungen der Software von den Vorstellungen des Auftraggebers. Des Weiteren treten Fehler beim sequentiellen Vorgehen erst sehr spät z. B. in der Testphase auf und sind dann nur mit hohen Kosten zu korrigieren (Eckkrammer et al. 2010, S. 81f).

Nachteilhaft am Wasserfallmodell ist zudem die Einschränkung der Kreativität der Programmierer. Die Lehre des klassischen Projektmanagements sieht einen kooperativen Führungsstil vor. In stark hierarchisch geprägten Organisationen wird häufig ein autoritärer Führungsstil gepflegt, der negative Auswirkungen auf Projekte in Form von nachlassender Motivation und Leistungsbereitschaft der Mitarbeiter hat. Anweisungen werden rein exekutiv von den Mitarbeitern umgesetzt, wobei ihr kreatives Potential ungenutzt bleibt (Wieczorrek und Mertens 2011, S. 104). Ebenfalls nicht förderlich für Kreativität ist, dass dem Projektteam nach Abschluss der umfangreichen Planungsaufgabe lediglich die termingerechte Abarbeitung der einzelnen Aufgaben bleibt (Wieczorrek und Mertens 2011, S. 105).

Vorgehensmodelle bei denen bereits zu Beginn des Projekts alle terminlichen, wirtschaftlichen und organisatorischen Themen definiert werden, werden vom Management präferiert, um inhaltliche und zeitliche Ziele planen zu können, obwohl Projekte ständiger Dynamik ausgesetzt, die die Ziele und Pläne schnell wieder veralten lassen (Wieczorrek und Mertens 2011, S. 104). Die genannten Nachteile und Defizite herkömmlich-klassischer Methoden führten zur Suche und Entwicklung neuer Ansätze.

Agile Projektmanagement-Ansätze sind entstanden, um in möglichst kurzer Zeit eine auf den Bedarf des Kunden oder Anwenders abgestimmte Software zu entwickeln, ohne vorab die exakten Anforderungen im Detail festzulegen (Kuster et al. 2011a, S. 29). Die Leitlinien der agilen Vorgehensmodelle finden sich im Manifesto for Agile Software Development (Beck et al. 2001), das unter der Internetadresse http://agilemanifesto.org/ erreichbar ist. Der Grundgedanke des Manifests ist, dass die Menschen, die die Software erstellen im Mittelpunkt stehen. Sie erschaffen in enger Abstimmung mit dem Auftraggeber lauffähige Software und können schnell und flexibel, daher der Begriff „agil“, auf Änderungen der Anforderungen eingehen (Eckkrammer et al. 2010, S. 73). Dabei soll das Projektteam in weitgehender Autonomie selbstbestimmt den Weg zum Ziel finden, wobei das Projektmanagement die Aufgabe hat, den Akteuren Hindernisse aus dem Weg zu räumen. Der verbalen Kommunikation kommt im agilen Projektmanagement eine große Bedeutung zur Lösung von Problemen zu. Denn durch die enge Zusammenarbeit entsteht kollektives Gruppenwissen, was zur Reduktion der Schnittstellenproblematik und zu einem kohärenten Produkt führt (Eckkrammer et al. 2010, S. 74).

Des Weiteren wird im agilen Manifest lauffähige Software vor umfangreiche Dokumentation gestellt (Beck et al. 2001). Der Projektfortschritt wird ergebnisorientiert anhand lauffähiger Software gemessen und nicht wegorientiert wie in sequentiellen Vorgehensmodellen bspw. als Prozentangabe. Es wird nicht vollständig auf Dokumentation verzichtet, sondern lediglich auf solche, die keinen Mehrwert bringt. Im Gegensatz zum sequentiellen Vorgehen wird zu Beginn des Projekts nicht eine vollständige und detaillierte Spezifikation und Planung vorgenommen, da es in der Regel zu Änderungen der Anforderungen des Kunden im Projektverlauf kommt. Änderungen im Umfeld des Projekts sind im agilen Projektmanagement erwünscht und fließen in die laufende Planung ein (Eckkrammer et al. 2010, S. 75).

Zudem wird im agilen Manifest der Zusammenarbeit mit Auftraggebern einen höheren Stellenwert eingeräumt als Vertragsverhandlungen (Beck et al. 2001). Beim sequentiellen Vorgehen tritt häufig das Problem auf, dass die fertige Software den tatsächlichen Anforderungen nicht entspricht. Agiles Vorgehen integriert den Kunden und dessen Bedürfnisse durch ständigen Austausch in den Entwicklungsprozess. Der Kunde fällt die Entscheidungen und erfährt dabei Beratung durch das Projektteam. Durch die enge Abstimmung und den Austausch können bereits in der nächsten Iteration korrigierende Maßnahmen eingeleitet werden, wenn dem Kunden das Produkt nicht gefällt und nicht erst nach Abschluss der Entwicklung (Eckkrammer et al. 2010, S. 75f).

Des Weiteren wird beim agilen Projektmanagement das Reagieren auf Änderungen höher gewertet als das starre Befolgen eines Plans (Beck et al. 2001). Hinsichtlich Anforderungsmanagement ist ein wesentlicher Unterschied des agilen Vorgehens im Vergleich zum sequentiellen, dass nicht bereits zu Projektbeginn alle Anforderungen bekannt sein müssen (Tiemeyer 2010, S. 19). Die agile Vorgehensweise ermöglicht eine hohe Reaktionsfähigkeit bei Änderungen der Kundenwünsche, indem die Anforderungen erst kurz vor der eigentlichen Umsetzung feinspezifiziert werden. Zu Beginn des Projektes steht dagegen nur eine grobe Planung fest, um die Aufwandsschätzung zu ermöglichen. Die Ziele, die mit der Umsetzung des Projektes zu erreichen sind, werden jedoch schon zu Beginn festgelegt. Erst kurz vor der Umsetzung wird dann die Detail-Planung und Spezifikation vorgenommen. Dies zeigt, dass bei agiler Vorgehensweise auch geplant wird, allerdings kurzfristiger und flexibler. Vorteilhaft ist dabei, dass das Team selbst die Planung vornimmt und somit eine stärkere Bindung an die vereinbarten Ziele aufweist (Eckkrammer et al. 2010, S. 76).

Auch beim agilen Vorgehen erfolgt die Projektsteuerung über das magische Dreieck. Wird im Laufe des Projektes eine Komponente geändert, bspw. der Liefertermin, so muss sich auch dementsprechend eine weitere Komponente bspw. die Kosten ändern, weil beispielsweise mehr Entwickler eingestellt werden müssen, um den früheren Liefertermin zu realisieren, was jedoch dem agilen Gedanken eines starken Teams widerspricht. Am Einfachsten umzusetzen, ist bei agiler Vorgehensweise die Reduktion der Features auf die Conditions of Satisfaction, die im ersten Release ausgeliefert werden. Die Nice-to-have-Features werden dann im darauffolgenden Release geliefert. Um trotzdem zum Projektstart ein Festpreisangebot abgeben zu können und messbare Abnahmekriterien zu schaffen, wird die Kante „Inhalt“ vollständig definiert und in harte Conditions of Satisfaction und Nice-to-have- Anforderungen aufgeteilt (Eckkrammer et al. 2010, S. 110). Im Ergebnis gibt es gegenüber herkömmlich-klassischer Vorgehensweise keinen Nachteil in Bezug auf die Angebotserstellung für den Auftraggeber und den Auftragnehmer.

Nachfolgend sollen die Vorteile von agilen Vorgehensmodellen dargestellt werden. Agiles Vorgehen bringt eine höhere Produktivität, gesteigerte Engagement und höhere Zufriedenheit der Mitarbeiter. Weitere Vorteile sind eine geringere Time-to-Market, gesteigerte Qualität, höhere Zufriedenheit bei den Stakeholdern und die nachlassende Eignung herkömmlicher Methoden (Cohn 2010a, S. 39). Das gesteigertes Engagement der Mitarbeiter ist auf die Förderung von nachhaltigen Arbeitstempo und weniger Überstunden zurückzuführen. Die kurze Time-to-Market begründet sich in der gesteigerten Produktivität und der höheren Wahrscheinlichkeit inkrementeller Releases, d.h. die gelieferte Funktionalität wird von den Stakeholdern als auslieferbar erachtet. Die höhere Qualität ist auf das gleichmäßige Tempo zurückzuführen. Die höhere Zufriedenheit bei den Stakeholdern ist auf den besseren Umgang mit dem Wechsel von Prioritäten bei agilem Vorgehen zurückzuführen (Cohn 2010a, S. 40ff).

Agile Vorgehensmodelle bieten eine höhere Flexibilität als herkömmliche Vorgehensweisen (Kuhrmann 2008). Dem Kunden stehen die pro Iteration entwickelten Software- Komponenten direkt zur Verfügung.

[...]

Ende der Leseprobe aus 33 Seiten

Details

Titel
Scrum als Framework für die Entwicklung von Apps
Untertitel
Using Scrum as a framework for developing apps
Hochschule
Otto-Friedrich-Universität Bamberg
Note
1,0
Autor
Jahr
2012
Seiten
33
Katalognummer
V202962
ISBN (eBook)
9783656295143
ISBN (Buch)
9783656297444
Dateigröße
881 KB
Sprache
Deutsch
Anmerkungen
Projektmanagement
Schlagworte
Projekt Management, Vorgehensmodell, App, Apps, App-Entwicklung, agil, Agiles Projektmanagement, Framework
Arbeit zitieren
Ulrich Theisinger (Autor), 2012, Scrum als Framework für die Entwicklung von Apps, München, GRIN Verlag, https://www.grin.com/document/202962

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Scrum als Framework für die Entwicklung von Apps


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden