Projektmanagement 2 SS2012

Transkript

1 Projektmanagement 2 Ausarbeitung Thema: APM Scrum Anwendbarkeit auf das Projekt Projektname: Laserharfe Hochschule Furtwangen University eingereicht bei Prof. Dr. Gotthard Pietsch am : von : Florian Grübel, Denis Simunec, Tobias Schäuble, Daniel Maier, Daniel Schorr 1

2 Inhaltsverzeichnis: Agiles Projektmanagement Was ist Scrum? Geschichte Rollen Erklärungen Artefakte...11 Scrum im Detail, Elemente...12 Vorteile von Scrum Zusammenfassung Unser Projekt Anwendbarkeit Fazit Quellenverzeichnis, Abbildungsverzeichnis

3 Kurzcharakterisierung: Agiles Projektmanagement Gesamtheit von Führungsaufgaben, -organisation, -techniken und mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten. (DIN-Norm) Projektmanagement ist die Anwendung von Wissen, Können, Werkzeugen und Techniken auf Projektaktivitäten, um Projektanforderungen zu erfüllen. (Project Management Institute PMI) Projektmanagement ist die Planung, Delegierung, Überwachung und Steuerung aller Aspekte eines Projekts. Dazu gehören die Motivation der Beteiligten, die Projektziele zu erreichen, und zwar innerhalb der zu erwarteten Leistungsziele für Zeit, Kosten, Qualität, Umfang, Nutzen und Risiken. (Britisches Office of Gouvernment Commerce OCG) Dies sind nur einige der vielen Definitionen des Projektmanagements. Auch wenn sie sich augenscheinlich unterscheiden mögen, inhaltlich beschreiben sie an sich das Gleiche: Der Begriff Projektmanagement beschreibt den Prozess der Planung, Steuerung und Kontrolle von Projekten. 3

4 Kein größeres und/oder komplexes Projekt kommt ohne das Projektmanagement aus, da man so leicht den Überblick über bestimmte Arbeitsvorgänge verlieren kann oder schlimmstenfalls sein Ziel verfehlt bzw. nicht erfüllen kann. Aus diesem Grund haben sich über die Jahre hinweg verschiedenste Modelle des Projektmanagements ergeben (zum Beispiel: Rational Unified Process oder V-Modell), denn nicht jedes Projekt kann auf demselben Weg angegangen werden. Das agile Projektmanagement (APM) unterstützt agile, also bewegliche Projekte dabei ihre Ziele zu erreichen, basierend auf den Werten des agilen Manifests: o Individuen und Interaktionen haben Vorrang vor den Prozessen und Werkzeugen. o Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation. o Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen. o Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung. APM ist durch ein adaptives Planen gekennzeichnet, was bedeutet, statt am Anfang eines Projekts einen umfangreichen und detaillierten Plan zu erstellen, regelmäßige Planungstreffen abzuhalten. Das heißt allerdings nicht, dass es keinerlei Grundplanung im agilen Projektmanagement gibt: Von Beginn an wird versucht Rahmenbedingungen und möglichst klare Ziele zu definieren, wobei hier aber auf eine starre und bürokratische Vorgehensweise verzichtet werden soll. An diese Stelle tritt hier eine intensive und kontinuierliche Kommunikation zwischen allen Beteiligten, welche in den unten genannten Treffen/Sitzungen am meisten zur Geltung kommt. In diesen Sitzungen, die in möglichst kurzen zeitlichen Abständen stattfinden sollten, können bis dahin entstandene Probleme oder Engpässe sofort angegangen bzw. Kompromisse eingegangen werden oder andere Herangehensweisen besprochen werden. So ist man nie nur starr auf das Ziel gerichtet mit dem was man, sozusagen, einem am Anfang zur Verfügung gestellt wurde, sondern kann stets spontan, dynamisch und agil agieren. Außerdem wird das Prinzip vertreten, das Hauptergebnis / Endziel in mehrere Zwischenergebnisse/ -ziele zu unterteilen. 4

5 Im Zentrum agiler Projektmanagement - Ansätze steht die Annahme, dass komplexe Projekte nie vollständig geplant werden können, da stets neue Erkenntnisse die Herangehensweisen beeinflussen bzw. beeinflussen sollen. Es kommt zu einer schrittweisen Zielannäherung. Grafisch dargestellt eignet sich dafür am besten die Iterations-Wolken-Metapher: Abb 1 - Quelle: APM Agiles Projektmanagement von Bernd Oesterreich und Christian Weiss Die anfangs große Wolke schrumpft zum Projektziel, welches, aufgrund von unvorhergesehenen Erkenntnissen oder Ereignissen, vom einst geplanten Ergebnis abweichen kann. Das agile Projektmanagement ändert zudem die Beziehung zwischen Projektmanagement und dem Team grundsätzlich, da es viele konventionelle Führungsannahmen, wie zum Beispiel, das Command and Motivate ersetzen. Das Team trifft zusammen die Entscheidung, wann welche Ergebnisse geliefert werden können. Also kann man sagen, dass keine einzelne Führungsperson die Organisation Aller und deren Arbeitspakete übernimmt, sondern dass die Entwickler sich selbst und ihre Arbeit organisieren. Der Projektmanager tritt hier nur als eine Art Moderator oder Enabler (frei übersetzt: Ermöglicher ) auf. Der wohl meist verbreitete Ansatz des agilen Projektmanagements nennt sich Scrum, welcher nun als nächstes vorgestellt wird. 5

6 Was ist Scrum? Scrum ist ein Vorgehensmodell für das Verwalten von komplexen Projekten. Es besteht aus wenigen Regeln und Prinzipien. Außerdem gibt es einen groben Rahmen vor, in dem das Projektteam seine eigene Entwicklungsplattform einbetten kann. Abb 2 - Quelle: 6

7 Die Geschichte von Scrum Scrum gibt es seit Beginn der 1990er Jahre. Jedoch wurde nicht schlagartig und auf einmal das Vorgehensmodell bzw. die Softwareentwicklungsmethode Scrum vorgestellt. Sie entwickelte sich Schritt für Schritt. Zunächst wurde in einem Projekt von Jeff Sutherland die Rolle des Projektleiters neu definiert. Er war nun eher Moderator, als Vorgesetzter für die anderen Teammitglieder. Dann veröffentlichte Ken Schwaber, der zusammen mit Jeff Sutherland als Erfinder von Scrum gilt, die These, dass es Scrum akzeptiere, dass in einem Projekt die Prozesse nicht vorherzusehen sind. Wenn man Scrum nutze, sei man des Weiteren auf dem besten Weg, das bestmögliche Endprodukt, in bestmöglicher Qualität, Funktionalität und Zeit, zu möglichst geringen Kosten zu erhalten. Anfang des 21. Jahrhunderts erschienen dann die ersten Bücher über Scrum. Im Jahre 2003 wurden auch die ersten Scrum Master von Ken Schwaber ausgebildet. Mittlerweile sind weitere Bücher über Scrum erschienen und es werden etliche Kurse angeboten in denen man Scrum Master werden kann. Die Rollen bei Scrum Product Owner Der Product Owner ist für den wirtschaftlichen Erfolg des Projektes verantwortlich. Dieser eröffnet das Projekt mit einer klaren Vision des Produkts. Passend zu dieser Vison erstellt der Product Owner die Anforderungen im Product Backlog und priorisiert diese. Selbstverständlich bindet er alle im Projekt relevanten Parteien früh in die Definition der Produktvision und des Product Backlogs ein. Der Product Owner bleibt aber immer Herr über das Produkt und das Product Backlog. Außerdem stellt der Product Owner die Interessen des Kunden dar, gibt diese weiter an das gesamte Team und steht stets in Kontakt zum Kunden. 7

8 Scrum Master Der Scrum Master sorgt dafür, dass Scrum im Team reibungslos funktioniert. Er sorgt dafür, dass die Werte und Prinzipien von allen Teammitgliedern vollzogen werden. Er kümmert sich darum, dass der Scrumprozess eingehalten wird. Ebenso hilft er bei der Beseitigung von Hindernissen und schützt das Team gegen Störungen von außen. Er hilft dem Team bei der Selbstorganisation, löst dabei aber nicht direkt die Probleme des Teams, sondern hilft dem Team Probleme selbstständig zu lösen. Der Scrum Master ist eine Führungskraft in einem modernen Verständnis. Er ist gegenüber dem Team nicht weisungsbefugt und folgt dem Grundsatz führen durch dienen. Eine der ersten Aufgaben des Scrum Masters ist die Bestimmung eines Product Owners. Entwicklungsteam Das selbst organisierte Team arbeitet während des Sprints(siehe Begriffserklärung) störungsfrei an der Abarbeitung des Sprint Backlogs. Das bedeutet auch, dass während des Sprints keine neuen oder geänderten Anforderungen an das Team gestellt werden. Dies ist erst nach Ende des Sprints, also im Sprint Planning des folgenden Sprints, möglich. 8

9 Scrum Begriffserklärungen Sprint Planning Zu Beginn jedes Entwicklungszyklus, hier Sprint genannt, findet das sogenannte Sprint Planning statt. Beim Sprint Planning vereinbaren Product Owner und das Entwicklungsteam welche Anforderungen aus dem Product Backlog als nächstes erledigt werden sollen. Diese Anforderungen werden in das Sprint Backlog übertragen. Wichtig ist, dass sich der Product Owner und das Entwicklungsteam auf das Sprint Backlog committen. Das bedeutet, dass das Entwicklungsteam selbst abschätzt, wie viel es im nächsten Sprint erledigen kann. Sprint Ein Sprint hat eine feste und immer gleiche Länge. Die Entwicklung erfolgt in direkt aufeinander folgenden Sprints. Die immer gleiche Länge führt zu einer guten Vergleichbarkeit der Sprints, womit es leichter fällt die Dauer zukünftiger Sprints zu bestimmen. Viele Teams arbeiten mit einer Sprintlänge von zwei oder drei Wochen, wobei eine Dauer von nur einer oder gar vier Wochen auch nicht unüblich ist. Daily Scrum Das Daily Scrum sorgt für den täglichen Statusabgleich und die Einsatzplanung für den Tag. Das Daily Scrum findet jeden Werktag zur selben Uhrzeit statt und dauert maximal 15 Minuten. Reihum beantwortet jedes Teammitglied 3 Fragen: 1. Was habe ich seit dem letzten Daily Scrum geschafft? 2. Was behindert mich bei meiner Arbeit? 3. Was werde ich bis zum nächsten Daily Scrum erledigt haben? Das Daily Scrum beinhaltet keine Diskussionen. Diese können, falls notwendig im Anschluss stattfinden. 9

10 Sprint Review Am Ende jedes Sprints, findet das Sprint Review statt. Hier präsentiert das Team dem Product Owner, was es im letzten Sprint geschafft hat. Dafür ist es wichtig, dass die Anforderungen im Sprint Planning so heruntergebrochen werden, dass es nach jedem kurzen Sprint etwas vorzuführen und zu sehen gibt. Häufig fallen den Projektbeteiligten im Sprint Review neue Anforderungen ein, die der Product Owner dann direkt ins Product Backlog einstellt. Sprint Retrospective Während es im Sprint Review um das Betrachten des Ergebnisses geht, betrachten Scrum - Teams in der Sprint Retrospective ihren Prozess. Sie fragen sich, was besonders gut gelaufen ist und wie diese Eigenschaften konserviert werden können. Außerdem fragen sie sich, was weniger gut gelaufen ist und wie diese Aspekte verbessert werden können. Dies ist ein in agile Softwareentwicklungsprozesse eingebauter kontinuierlicher Verbesserungsprozess, der darauf basiert, dass wir ständig weiterlernen. Danach kann der nächste Sprint beginnen. 10

11 Artefakte Mit Artefakten werden bei Scrum die (Zwischen-) Ergebnisse bezeichnet, die während den einzelnen Phasen oder zu Beginn des Projektes entwickelt werden. Product Backlog: Das Product Backlog ist eine Liste der Kundenanforderungen, die nach Wichtigkeit geordnet sind. Das Product Backlog ist ein lebendes Dokument, da es dauernd aktualisiert wird. Sprint Backlog: Das Sprint Backlog enthält die Aktivitäten, die durchgeführt werden müssen um die wichtigsten Kundenanforderungen aus dem Product Backlog innerhalb eines Sprints umzusetzen. Burndown Chart: Das Burndown Chart ist eine täglich aktualisierte Darstellung des noch zu erbringenden Restaufwandes für den aktuellen Sprint. 11

12 Scrum im Detail Im Zentrum von Scrum steht das sich selbstorganisierende Entwicklerteam, welches ohne den üblichen Projektleiter auskommt. Ein Scrum Master sorgt dafür, dass das Team störungsfrei arbeiten kann und der Entwicklungsprozess nicht ins Stocken gerät. Der Scrum Master ist auch das Bindeglied zwischen Entwicklerteam und dem Produktverantwortlichen, dem sogenannten Product Owner. Der Product Owner hat die Aufgabe, Anforderungen zu definieren, zu priorisieren und diese gegebenenfalls zu tauschen. Allerdings ist in Scrum klar geregelt, wann der Produktverantwortliche neue oder geänderte Anforderungen beauftragen darf. So gibt es Entwicklungszyklen von ca. ein bis vier Wochen - die sogenannten Sprints - in denen dem Product Owner untersagt ist, das Entwicklerteam zu "stören". Während eines Sprints wird deshalb der Product Owner seine Vorstellungen von der weiteren Entwicklung in ein sogenanntes Product Backlog eintragen und seine Vorstellungen in zukünftigen Sprints vortragen und damit weiterplanen. Welche Elemente bietet Scrum? Scrum definiert einen Rahmen, aber nicht wie dieser ausgefüllt werden soll. Somit hat das Projektteam viele Freiheiten bei der Umsetzung von Scrum. Diese Eigenschaften lassen sich wie folgt zusammenfassen: Scrum beinhaltet... einfache Regeln wenige Rollen mehrere Arten von Meetings mit bestimmten Zwecken einige Schlüssel-Artefakte, die maximale Transparenz auf einfache Weise bieten Selbstorganisation und Eigenverantwortung in interdisziplinären Teams Änderungen der Kundenanforderungen während des Projekts gelten als normal, nicht als Störfaktor speziell geeignet für hochkomplexe Projekte mit unklaren Anforderungen 12

13 Welche Vorteile hat Scrum? Scrum ist einfach: Scrum ist einfach zu lernen und ist für den Laien relativ schnell zu verstehen. Eine lange Einarbeitungszeit in die Vorgehensweise ist damit überflüssig und man kann direkt starten. Scrum ist flexibel: Scrum lässt sich sehr schnell und flexibel einsetzen. Somit kann es häufig den ersten Schritt darstellen, um Entwicklungsprojekte dynamisch zu gestalten. Jedoch kann man jeder Zeit Änderungen am Projekt vornehmen, ohne dass diese sich negativ auf die zu Beginn des Projektes erstellten Planungen auswirken. Scrum ist klar definiert: Des Weiteren definiert Scrum klare Rollen: Entwicklerteam, Product Owner und Scrum Master. Außerdem einen gut strukturierten, aber dennoch flexiblen Entwicklungsprozess. Bei aller Klarheit bleibt stets die Möglichkeit erhalten, Besonderheiten und Erfahrungen des eigenen Projekts zu berücksichtigen und sich so seinen individuellen Scrum-Prozess zu erarbeiten. Scrum deckt Probleme relativ schnell auf: Scrum löst keine Probleme, sorgt aber dafür, dass diese schnellstmöglich lokalisiert und aufgedeckt werden. So sorgt Scrum dafür, dass man nicht, wie bei normalen Projekten, irgendwann auf ein großes Problem stößt, welches dafür sorgen könnte, dass man das Projektziel nicht erreicht. Das Projekt würde dann normalerweise ins Stocken geraten und man würde versuchen erst die anderen Thematiken umzusetzen. Erst am Schluss wird man wieder auf das große Problem zu sprechen kommen. Dies ist bei Scrum anders: Hier wird sofort die Problematik lokalisiert, aufgedeckt und für alle sichtbar gemacht. Die Gründe liegen dann direkt auf der Hand und man kann relativ zügig mit dem Lösen des Problemes beginnen. 13

14 Scrum stärkt den Teamgeist: Bei Scrumprojekten gibt es eine viel engere Verzahnung der Teammitglieder als bei normalen Projekten. Es gibt keinen Projektregenten der alles bestimmt, überwacht und selbst kaum etwas für das Gelingen des Projektes beiträgt. Durch die täglichen Meetings und das schnelle Aufdecken von Problemen wird die Stimmung im Team auf einem konstant guten Level gehalten. Das Team bestimmt in Scrumprojekten die Vorgehensweise zur Umsetzung der Anforderungen selbst. Zudem organisiert sich das Team durch gegenseitige Verpflichtung und enger Kommunikation. Die Eigenständigkeit und Selbstbestimmung des Teams verbessert die Zufriedenheit des einzelnen Teammitglieds, was einen positiven Effekt auf das gesamte Team hat. Scrum ist näher am Kunden: Dadurch, dass der Kunde nach jedem Sprint, also alle 1-4 Wochen, etwas Fertiges zu Gesicht bekommt, ist er immer auf dem aktuellsten Stand des Projektes. Er kann direkt eingreifen wenn ihm etwas nicht gefällt und bekommt nicht erst nach einigen Monaten oder gar Jahren ein fertiges Produkt vorgesetzt das ihm eventuell gar nicht gefällt. Er kann seine Meinung und Wünsche also nach jedem Sprint äußern. Der Vorteil für das Projektteam liegt hierbei klar auf der Hand: Falls es nun zu Änderungswünschen seitens des Kunden kommen sollte besteht nicht die Gefahr, dass alles verloren ist und man sich wieder am Anfang des Projektes befindet. Die Änderungswünsche können direkt im nächsten Sprint umgesetzt werden. Somit ist der Kunde, wie auch das Team deutlich zufriedener mit dem Fortschritt des Projektes und es geht dadurch weniger Zeit verloren. Scrum ist zielführend und effektiv: Scrum sorgt dafür, dass die wichtigsten Anforderungen auch die höchste Priorität genießen und schnellstmöglich umgesetzt werden. Des Weiteren kann effektiver mit zu erwartenden Anforderungsänderungen umgegangen werden. Die Chance, dass der Kunde genau die Software erhält, die er braucht, ist um ein Vielfaches höher als bei der herkömmlichen Vorgehensweise. 14

15 Scrum beschleunigt das Projekt: In vielen Projekten wird die Entwicklung durch offene Fragen und Probleme stark verlangsamt. Mit Scrum werden diese bei den sogenannten Daily Scrums identifiziert, priorisiert und systematisch gelöst. So ist das Team schnellstmöglich wieder operativ und produktiv. Zusammenfassung: Alle Projektbeteiligten schreiben zu beliebigen Zeiten Anforderungen in das Product Backlog. Noch nicht realisierte eigene Anforderungen können auch wieder entnommen oder verändert werden. Der Product Manager wählt die Anforderungen aus dem Product Backlog aus und priorisiert sie im Sprint Backlog. Das Sprint Backlog definiert die Arbeitsaufträge an das Entwicklungsteam für einen Sprint. Das Entwicklungsteam realisiert die Anforderungen, so dass verwendbare Software entsteht. Nach dem Sprint ist vor dem Sprint. Wenn ein Sprint erledigt ist, stellt der Product Manager das nächste Sprint Backlog zusammen und der nächste Sprint beginnt. Ein Sprint dauert ca. eine Woche 30 Tage. In einem Projekt sind die Sprints aber immer gleich lang. Während des Sprints finden die sogenannten Daily Scrums statt, die maximal 15 Minuten dauern. Der ScrumMaster nimmt an den Meetings teil. Seine Aufgabe besteht darin, das Team bei seiner Selbstorganisation zu unterstützen. Die in einem Sprint entwickelte Funktionalität wird in einem Sprint Review den Projektbeteiligten vorgestellt. Diese geben Feedback und schreiben, bei Bedarf, neue Anforderungen an das Product Backlog oder ändern existierende Anforderungen. 15

16 Unser Projekt In unserem Projekt Laserharfe geht es darum eine voll funktionstüchtige Laserharfe zu bauen. Sie soll wie eine richtige Harfe funktionieren, sprich man soll mehrere Töne anspielen können. Statt Harfensaiten soll sie acht Laserstrahlen projezieren. Diese werden mithilfe eines Laserstrahles, welcher im Baugerät zu acht einzelenen Strahlen gebrochen wird, vom Boden nach oben geworfen. Hält man seine Hand in einen der Laserstrahlen und unterbricht diesen, so wird der entsprechende Ton angespielt. Ein Sensor, der auch im Baugerät angebracht ist, erkennt nämlich, ob ein Gegenstand bzw. eine Hand den Laserstrahl unterbricht. Die Tonhöhe bzw. die Lautstärke soll man ebenfalls über den Sensor regeln können. Damit das Ganze besser vorzuführen ist, wird zusätzlich eine Nebelmaschine benötigt. Diese wird einen Nebel erzeugen, welcher die Laserstrahlen besonders zum Vorschein bringen wird. Unsere konkrete Aufgabe besteht zunächst darin, die Funktionsweise einer Laserharfe zu verstehen, die benötigten Bauteile zu beschaffen, sie nach unserem eigenen Design zu gestalten und zu bauen und die entsprechende Software zu entwickeln. Der gesamte Vorgang wird zusätzlich noch filmisch, sowie mit Text dokumentiert. Die Laserharfe soll am Tag der Medien im Wintersemester 2012/2013 vorgeführt werden. Sowohl an einem eigenen Stand, aber eventuell auch auf der Medianight. Hierzu werden Studenten der Musikhochschule Trossingen geladen, welche die Laserharfe spielen werden. 16

17 Abb 3 Quelle

18 Könnte man Scrum auf unser Projekt anwenden? Um diese Frage beantworten zu können, müsste man zwei Ansätze betrachten: o Theoretischer Ansatz o Realistischer Ansatz Theoretischer Ansatz An sich könnte man das Scrum-Modell vollständig auf das Projekt anwenden, denn dafür wären alle Voraussetzungen gegeben: Um die nötigen Rollen des Scrum-Modells zu verteilen hätten wir genügend Projektmitglieder. Unser Team besteht aus fünf Studenten und einem leitenden Professor, welcher zusätzlich zu seiner betreuenden Führungsposition die Rolle des Kunden übernommen hat. Also ist es möglich einen Scrum Master, den Product Owner und das Entwicklungsteam hieraus zu bestimmen. In unserem Projekt übernimmt Prof. Dr. Bruno Friedmann die Rolle des Kunden. Er erteilte, sozusagen, den Auftrag an das Projektteam eine Laserharfe zu bauen. Dies soll bis zum Tag der Medien 2013 geschehen. Außerdem bespricht er seine Wünsche, Erwartungen und Anregungen mit dem Team. Natürlich gibt es auch ein Entwicklerteam, welches aus drei Studenten bestehen müsste, da Scrum Master und Product Owner wegfallen würden. Das hieße, dass die Aufgabenfelder Bau, Programmierung und Dokumentation auf jeweils einen Studenten verteilt werden würde. Die beiden verbliebenen Studenten würden dann die Rollen des Scrum Masters, also des Projekt Moderators und des Product Owners übernehmen. Eine weitere wichtige Voraussetzung wäre damit erfüllt, dass ein klares Ziel bestimmt ist und dazu die Rahmenbedingungen. Allerdings, wie bei Scrumprojekten vorgesehen, kommen stets neue Erkenntnisse, die den Projektverlauf beeinflussen, hinzu. Das Ziel ist hier der Bau einer funktionstüchtigen Laserharfe, wobei aber nicht 18

19 festgelegt wurde, wie diese aussehen soll oder über welche sonstigen Funktionen sie verfügen muss. Die groben Rahmenbedingungen, wie Zeit und Funktionsfähigkeit sind die Einzigen, die bestehen. Der Rest wird frei vom Team entschieden, also Design, Programmierung und sonstige Funktionen. Daily Scrums, also tägliche Team Meetings, könnten abgehalten werden, da alle Beteiligten an derselben Hochschule studieren und somit örtlich gebunden sind. Außerdem wäre hier auch der nötige Platz für den Bau vorhanden, sowie technische Hilfsgeräte, wie Lötkolben, Laserlabor, Besprechungsräume, usw. Realistischer Ansatz Wenn man nun allerdings alle anderen Einflüsse, die direkt oder indirekt das Projekt beeinflussen, berücksichtigt, dann kommt man zu einem anderen Schluss. Dies soll der realistische Ansatz aufzeigen. Da das Projektteam nun schon einige Wochen zusammenarbeitet und man so schon herausfiltern konnte, welche Einflüsse den Projektverlauf bis hierhin begleiteten, kann man sagen, dass eine vollständige Übertragung des Scrum-Modells nicht möglich ist. Es besteht nicht die Möglichkeit einer gesamten Rollenverteilung, wie es in Scrum vorgesehen ist. Das Projekt Laserharfe ist ein Hochschul-internes Projekt, was bedeutet, dass Prof. Dr. Bruno Friedmann uns den Auftrag gab, dieses Projekt zu realisieren. Damit stellt er eigentlich unseren Kunden dar. Die Rolle des Kunden wäre damit also gegeben. Allerdings hat bzw. benötigt unser Projektteam keinen Product Owner oder anders gesagt, das gesamte Team ist der Product Owner. Da jedes Mitglied in Kontakt mit dem Kunden, Prof. Dr. Bruno Friedmann, steht, fällt somit die Rolle eines Vermittlers zwischen Team und Kunde weg. Außerdem übernahmen wir alle die Aufgabe der Recherche und der Erstellung eines individuellen Baukonzeptes für eine Laserharfe. Damit fällt auch die zweite wichtige Funktion des Product Owners weg, nämlich die der Produktvision. Auch Prof. Dr. Bruno Friedmann übergab allen Mitgliedern freie Entscheidungs- und Entfaltungsgewalt über das Produkt. 19

20 Die Rolle des Scrum Masters wird nur teils von einem Teammitglied ausgefüllt. Dieser ist der Projektleiter, der, ähnlich wie der Scrum Master, ein Auge darauf hat, dass das Projekt vorangetrieben wird bzw. nicht vernachlässigt wird. Außer dieser Tätigkeit hat der Projektleiter keine Parallelen zu denen des Scrum Masters. Der Projektleiter ist nämlich ein vollwertiges Mitglied des Entwicklerteams, übernimmt also auch andere Aufgaben, wie beispielsweise Bau, Programmierung und Dokumentation des Projekts. Realistisch betrachtet, würde es zu großen Schwierigkeiten im Projektverlauf kommen, wenn tatsächlich zwei der fünf Studenten für andere Rollen wie das Entwicklerteam wegfallen würden. Das Projekt besteht aus drei großen Arbeitsteilbereichen: Bau, Programmierung und Dokumentation. Es wäre einem einzelnen Studenten kaum bzw. nicht möglich einen gesamten Teilbereich alleine zu übernehmen, da dies sehr viel Zeit und sonstigen Aufwand in Anspruch nehmen würde. Zudem gibt es noch sehr viele andere Faktoren, die den Mitgliedern des Projektteams Zeit und Aufwand kosten. Zum einen, natürlich, da es noch andere wichtige Hochschulveranstaltungen gibt, die teilweise verpflichtend sind. Diese nehmen eine Menge Zeit und Kraft in Anspruch, besonders gegen Ende eines Semesters, da meist Klausuren zu schreiben bzw. wichtige Abgaben zu erledigen sind. Zum Zweiten ist ein Großteil unseres Projektteams, aufgrund von Arbeit in einem Unternehmen, Heimatbesuch oder dergleichen, des Öfteren verhindert. Glücklicherweise kann einige Arbeit auch mobil, also beispielsweise unterwegs, oder von zuhause aus erledigt werden. Besonders aus letzterem Grund ist es uns also nicht gegeben Daily Scrums abzuhalten. Zudem wäre es kaum möglich tägliche Ergebnisse zu liefern, da wir, als Studenten, noch jede Menge andere Aufgaben zu erledigen haben. Aber nicht nur da liegt ein Zeitproblem, sondern auch bei Prof. Dr. Bruno Friedmann. Da er lehrender Professor an der Hochschule ist, ist er auch zeitlich äußerst beschränkt und könnte so nicht täglich an einem Treffen teilnehmen, was aber dazu nötig wäre. 20

21 Ein weiterer Grund, warum Scrum bei uns keine Anwendung findet ist die Methode der Sprints. Wie geschrieben sollten die Sprints eine etwa gleiche Dauer aufweisen. Dies war bei uns von Anfang an nicht möglich, da wir verschiedene Phasen durchlaufen mussten. Zu Beginn sollten wir Recherche betreiben, da wir alle noch keinerlei Erfahrung mit der Materie und dem Inhalt des Projektes hatten. Dies nahm sehr viel Zeit in Anspruch, anders als andere, darauf folgende Aufgaben. So war es natürlich auch nicht möglich täglich vorweisbare Ergebnisse zu liefern. Ein weiterer Faktor, der den Projektverlauf sehr beeinflusst, ist die Abhängigkeit von den Online- Shops, bei denen die benötigten Bauteile bestellt wurden. Teilweise mussten die Komponenten aus dem Ausland bestellt werden, was eine lange Lieferdauer zur Folge hatte. In dieser Zeit konnten wir kaum etwas für das Projekt tun, da die meisten theoretischen Arbeiten bereits abgeschlossen waren. Fazit: Wie man aus den beiden Ansätzen herauslesen kann, wäre es durchaus möglich das Scrum Modell auf unser Projekt anzuwenden. Das hieße aber, dass sich alle Beteiligten über den Zeitraum bis zum Erreichen des Projektziels ausschließlich mit dem Projekt beschäftigen müssten. Da jedoch einige Faktoren eben dies nicht zulassen, ist eine vollständige Übertragung auf unser Projekt nicht erreichbar. Wir verwenden also kaum Bausteine des Scrum Modells. Bis auf eine äußerst reduzierte Form des Scrum Masters, bei uns Projektleiter, ergeben sich keine Ähnlichkeiten zum Scrum Modell. 21

22 Quellenverzeichnis: - Abbildungsverzeichnis: Abb. 1 - Quelle: APM Agiles Projektmanagement von Bernd Oesterreich und Christian Weiss Abb. 2 - Quelle: Abb. 3 Quelle: 22