Diese Hausarbeit widmet sich der Analyse und Umsetzung von IT-Management-Steuerungsansätzen durch verschiedene Vorgehensmodelle, insbesondere dem Wasserfallmodell und der agilen Methode Scrum. Die Arbeit beleuchtet die Grundlagen dieser Modelle sowie deren praktische Anwendung in einem konkreten KI-Projekt. Dabei werden Schritte wie die Entwicklung einer Produktvision, die Priorisierung von Aufgaben im Backlog-Prozess, die Planung und Durchführung von Sprints sowie das Feedback- und Verbesserungsmanagement im Scrum-Team detailliert betrachtet. Diskussionen zu den Vor- und Nachteilen des Scrum-Frameworks im Kontext des KI-Projekts sowie ein abschließendes Fazit und Ausblick runden die Arbeit ab. Diese Hausarbeit liefert einen fundierten Einblick in die praktische Anwendung agiler Methoden im IT-Management und richtet sich an Fachleute und Studierende im Bereich der Informationstechnologie und des Projektmanagements.

Extracto

1.1 Problemstellung.............................................................................. 2

1.2 Zielsetzung..................................................................................... 4

1.3 Art des Vorgehens........................................................................... 4

2.1 Grundlagen der IT-Management-Steuerung durch Vorgehensmodelle.... 5

2.2 Phasen orientiertes Wasserfallmodell................................................ 7

2.3 Agiles Vorgehensmodell Scrum......................................................... 9

2.4 Zusammenfassung der wesentlichen Unterschiede des Wasserfallmodells und der agilen Scrum-Methode................................. 13

3.1 Voraussetzungen zur Adaption des Scrum Frameworks und Entwicklung einer Produktvision für das KI-Projekt.................................................... 14

3.2 Ableitung der Produktvision und Präzisierung mittels Story-Cards....... 15

3.3 Effiziente Priorisierung und Ableitung der Story-Cards in den Backlog-Prozess............................................................................................. 15

3.4 Praktisches Beispiel des Product-Backlog des KI-Modells und Erarbeitung der Meilensteine................................................................ 17

3.5 Sprint-Planning und transparente Aufgabenverteilung im agilen Scrum-Prozess............................................................................................. 19

3.6 Bessere Visualisierung der Sprints durch die Adaption eines Sprint-Boards und Kanban............................................................................. 19

3.7 Daily-Scrum als Hilfsmittel zur Fokussierung des Fortschrittes in Richtung des Sprint-Ziels..................................................................... 21

3.8 Burndown-Chart als Hilfsmittel zur holistischen Abbildung des Projektfortschrittes............................................................................. 22

3.9 Feedback, Abnahme und Neuplanung im agilen Scrum-Prozess durch das Sprint-Review-Meeting.................................................................. 22

3.10 Kalkulation der Velocity zur Bestimmung der durchschnittlichen Arbeitsleistung des Scrum-Teams......................................................... 23

3.11 Sprint-Retrospektive zur kontinuierlichen Verbesserung und Lösungsfindung im agilen Scrum-Team................................................. 24

4.1 Diskussionen zur Ableitung der bestehenden Vorteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes............................ 26

4.2 Diskussionen zur Ableitung der bestehenden Nachteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes............................ 27

5.1 Fazit............................................................................................. 28

5.2 Ausblick....................................................................................... 29

Literaturverzeichnis............................................................................ 30

Abkürzungsverzeichnis

bspw. beispielsweise

bzw. beziehungsweise

etc. et cetera

gem. gemäß

ggf. gegebenen Falls

i.d.R. in der Regel

insg. insgesamt

KI Künstliche Intelligenz

resp. respektive

sog. sogenannte

u. a. unter anderem

usw. und so weiter

u. u. unter Umständen

z. B. zum Beispiel

z. T. zum Teil

1.1 Problemstellung

Im Laufe eines IT-Projektes gilt es, Hunderte von Entscheidungen zu treffen. Einige dieser IT-Entscheidungen sind für Unternehmen mitunter von fundamentaler Bedeutung und reichen vom drohenden Stillstand des Betriebs, bis hin zum Schutz von Leib und Leben. Ist letzteres der Fall, sind IT-Entscheidungen nicht mehr nur als Gegenstand der IT-Strategie, sondern als Bestandteil der Unternehmensstrategie zu konnotieren. [1] Eine der ersten zu treffenden Entscheidungen, besteht mitunter in der Auswahl einer Projektmanagementmethode, welche den speziellen Anforderungen des Projektes entspricht. Diese als Vorgehensmodelle beschriebene Frameworks ermöglichen es, einen sicheren Rahmen für das Vorgehen des Projektes sicherzustellen. [2] Ein angemessenes Modell um die Relevanz von Vorgehensmodellen, besonders von jenen, welche im IT-Projektmanagement Verwendung finden, offeriert uns der Teufelskreis der Software-Entwicklung nach Versteegen. Sehe 1. Abb.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

1. Abb. Der Teufelskreis der Software-Entwicklung. Quelle: Mast, S. (2015), S. 6

Mitunter nimmt die Entwicklung von Software i.d.R. weniger Zeit in Anspruch als die Nutzung dieser. Hierdurch entsteht ein höherer Wartungsaufwand, welcher sich direkt auf eine mangelhafte Entwicklung zurückführen lässt. Je mehr Fehler in der Entwicklung geschehen resp. je mehr Details bei der Entwicklung vergessen werden, desto höher wird der spätere Wartungsaufwand des Projektes ausfallen. Daher muss das Projekt von Beginn an genau geplant, geordnet sowie strukturiert werden. Der Anteil der Kostenverteilung einer Software in Bezug auf die komplette Nutzungsdauer zeigt, dass die bestehenden Wartungskosten mitunter 67 % der Gesamtkosten eines Projektes einnehmen, tendenziell steigend. Gelingt es den Entwicklern bereits in der Entwicklungsphasen potenziellen Risiken und Schwachstellen präventiv zu begegnen, senkt dies nicht nur die Gesamtkosten, sondern erhöht auch die Qualität der Ergebnisse. [3] Eine in Praxis weitverbreitete Methodik zur Prävention von Risiken besteht in der Adaption eines geeigneten Vorgehensmodells. Diese Modelle verbinden die Aufgaben zwischen den Aufgaben der Projektorganisation und des Managements, sowie den methodischen und technischen Aufgaben der Software- und Systementwicklung. Hierbei strukturieren diese das Vorgehen und die Zuständigkeit für die spezifischen Aufgaben, und helfen dabei, die Struktur von Projekten greifbar, vergleichbar und bewertbar zu machen, womit sie wesentlich zum Erfolg eines Projektes beitragen. [4] Wichtig zu verstehen ist, dass der Entwicklung von Computersoftware und Prozesssystemen schon immer verschiedene Methoden zugrunde lagen. Diese Methoden verwenden unterschiedliche Frameworks, um den Entwicklungsprozess zu entwerfen, zu verwalten und zu steuern. Im Zentrum der Betrachtung steht der Softwareentwicklungslebenszyklus, welcher differenzierte Phasen umfasst und eine gut geplante Strategie zur Änderung oder Erstellung eines neuen Produkts umfasst. In der Praxis bestehen viele verschiedene Ansätze zur Entwicklung von Software, zu den weit verbreitetsten gehören das Wasserfallmodell und das agile Vorgehen, auch als (Scrum) bekannt. [5] Gerade für Menschen, die sich nicht eingehend mit Projektmanagementmethoden beschäftigen, kann es mitunter schwierig sein, den Unterschied zwischen einem Kanban-Board von einem Scrum-Board zu erkennen, oder zu verstehen, aus welchen Gründen die Unterschiede zwischen agilen und Wasserfall-Methoden wichtig sind. In der Literatur bestehen unzählige Begriffe, welche z.T. nicht ganz verstanden werden. Dies führt leider oft dazu, dass sich Projektverantwortlichen, die mit den jeweiligen Methoden verbundenen besonderen Vorteile entgehen lassen, was sich in manchen Fällten defizitär auf den gesamten Projektverlauf auswirkt. [6] Da der Differenzierung und der Adaption eines geeigneten methodischen Frameworks im Rahmen eines IT-Projektes somit eine wesentliche Relevanz zu konnotieren ist, fokussiert sich diese Ausarbeitung auf die jeweiligen Vor- und Nachteile dieser und veranschaulicht diese anhand von praktischen Implikationen für ein KI-Projekt.

1.2 Zielsetzung

Das Primärziel dieser Ausarbeitung besteht in der Beschreibung der im IT-Management verwendeten Steuerungsformen des Wasserfallmodells resp. der Agilen-Methode (Scrum). Hierbei werden beide Steuerungsformen ausgiebig erörtert sowie die den Modellen zugrunde liegenden Steuerungsformen anhand der bestehenden Charakteristiken unterschieden. Weiterhin wird sich auf die Agile-Methode (Scrum) anhand eines selbst gewählten Beispiels, der Entwicklung einer Künstlichen Intelligenz (KI) fokussiert, um den praktischen Ablauf des agilen Frameworks abzubilden. Zuletzt werden anhand des praktischen Beispiels die jeweiligen Vor- und Nachteile der gewählten Steuerungsform beschrieben.

1.3 Art des Vorgehens

Der theoretische Teil fokussiert sich zunächst auf die definitorische Bestimmung und Beschreibung der grundlegenden IT-Management-Steuerungsformen, fokussiert sich dann auch das Wasserfallmodell und die Agilen-Methode (Scrum). Der Fokus liegt hierbei vor allem auf den grundlegenden Aspekten, um die Unterschiede der beiden Steuerungsformen besser herauszuarbeiten. Im praktischen Teil dieser Ausarbeitung wird dann anhand eines selbst gewählten IT-Projektes (Entwicklung einer Künstlichen-Intelligenz zur Threat Detection) der Softwareentwicklungsprozess auf Basis des agilen Vorgehens (Scrum) beschrieben und erläutert. In diesem Kontext wird auf Grundlage der bestehenden wissenschaftlichen Natur dargestellt, welche jeweiligen Vor- und Nachteile durch die gewählte Steuerungsform bezogen auf das gewählte Beispielprojekt bestehen. Im Diskussionsteil werden die jeweiligen Vor- und Nachteile dann vertieft. Die Ausarbeitung endet mit einem Fazit zu den markantesten Merkmalen und dem Ausblick.

2.1 Grundlagen der IT-Management-Steuerung durch Vorgehensmodelle

„Ein Vorgehensmodell definiert einen allgemeinen Rahmen für den organisatorischen Prozess der Softwareerstellung“. [7] Grundsätzlich beschreibt ein Vorgehensmodell systematische, organisatorische, ingenieurmäßige und quantifizierbare Vorgehensweisen, um Aufgaben einer bestimmten Klasse wiederholbar zu lösen. Wie oben bereits angeführt beschreiben diese auch die Schnittstellen des Projekts zur Organisation, in denen das Projekt eingebettet ist und stellt gleichzeitig ein Instrument zur Integration von Methoden und Praktiken dar, welches für die Lösung eng umgrenzter Teilaufgaben verwendet wird. Somit strukturieren diese und die mit ihnen kombinierten Methoden resp. Praktiken in ihrem Kern das Projekt, wobei sich diese vor allem auf die Aufbau und Ablauf organisatorischen Aspekte beziehen. [8] Aufbau organisatorisch beschreibt ein Vorgehensmodell, den Aufbau des Projektteams, sowie die dazugehörigen Aufgabenprofile über Rollen. Weiterhin werden Artefakt Modelle festgelegt, welche die Ordnungsstruktur für Arbeitsergebnisse und ihre Abhängigkeiten zueinander beschreiben. Im Sinne der Ablauforganisation beschreiben Vorgehensmodelle vor allem den grundsätzlichen Arbeitsprozess, seine groben Aufgabenfelder, sowie die jeweiligen Entwicklungsschritte, in den jeweils bestehenden Detaillierungsgraden. Gemeint ist hiermit vor allem der technische Entwicklungsprozess des Aufbaus der Entwicklung des Systems unter Berücksichtigung der relevanten Kernaufgaben. [9] Eine grobe Differenzierung dieser Modelle, kann in die herkömmliche phasenspezifischen Vorgehensmodelle z.B. (Wasserfallmodell, Rational Unified Process, V-Modell XT) und die Agilen inkrementelle, resp. iterative Vorgehensmodelle z.B. (Scrum, Crystal, Extreme Programming, Microsoft Solutions Framework) geschehen. Nicht selten verfügen Unternehmen über eigens entwickelte, oder einer Mischung an Modellen. Bspw. ITPM (BMW), SEP (AUDI/VW). [10] Der nachfolgenden 2. Abb. ist eine Einteilung von populären Vorgehensmodellen in drei Familien zu entnehmen. Während die Einteilung und der Einsatz anhand von zwei Dimensionen erfolgt, welche durch die Kategorie Anforderungen bestimmt wird, beschreibt die horizontale Achse die Stabilität der Marktanforderungen. Die vertikale Achse hingegen bezieht sich auf die Anforderungen an den Projektcharakter. [11]

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

2. Abb. Charakterisierung der Vorgehensmodelle nach Ebert. Quelle: Scharch, M. (2016), S. 14

Die oben angeführten Differenzierungsmöglichkeiten dependieren mitunter daran, da es eine Vielzahl an unterschiedlichen Vorgehensmodellen gibt, welche jeweils spezifisch auf unterschiedliche Aufgaben oder Anwendungsdomänen ausgerichtet, auf die spezifischen Anforderungen eines Unternehmens oder Projekttypen zugeschnitten, oder als generischer Standard formuliert sind. [12] Die Adaption eines Vorgehensmodells, stellt sich wie angeführt als kritisch für den Projektverlauf dar, grundlegend sind folgende Vorteile mit dem Nutzen eines geeigneten Modells verbunden. 1.) Die Erhöhung der Übersichtlichkeit der Projektdurchführung. 2.) Die Steigerung der Beherrschbarkeit des Projektes. 3.) Die Steigerung der Planbarkeit eines Projektes. 3.) Verbesserte Kontrolle und (weitgehend) einheitliche Durchführung des Projektes. 4.) Die Verbesserung der Projektkommunikation. 5.) Senkung der Aufwände. 6.) Die frühzeitige Erkennung von Fehlern. 7.) Verbesserte Dokumentation im Projekt. 8.) Erzielung von qualitativ höherwertigen Projektergebnissen. 9.) Die Minimierung von Projektrisiken. 10.) Die Möglichkeit, Erfahrungen zum Vorgehen zu sammeln und kontinuierlich zu verbessern. All dies trägt insg. zu einer höheren Wahrscheinlichkeit bei, dass sich das Projekt innerhalb der festgelegten Qualität, des verfügbaren Budgets und anhand des determinierten Zeitraumes erfolgreich realisieren lässt. [13] Auch wenn sich die einzelnen Vorgehensmodelle in einigen Aspekten unterscheiden, liegt diesen jedoch alle zugrunde, dass diese Anforderungen vor ihrer jeweiligen Umsetzungen ermitteln und analysieren. Dies geschieht jedoch mit einem unterschiedlichen Tiefgang, hierbei können sich in jedem Vorgehensmodell die Anforderungen während des gesamten Entwicklungsprojekts ändern, was den Fokus auf eine kontinuierliche Verfolgung der Anforderungen richtet. Einige Charakteristiken, welche bei der Wahl eines geeigneten Vorgehensmodells, Prozesses, Methodik und Dokumentation für die Projektbetreuung als relevant zu konnotieren sind, bestehen mitunter in Fragen danach, wie lange ein Produkt gepflegt werden soll, wie viele Kunden durch das Projekt betroffen sind, wie lange der Lebenszyklus des Projektes ist, und vor allem, welche Risiken, Unsicherheiten und Randbedingungen mit dem Projekt in Verbindung stehen. [14]

2.2 Phasen orientiertes Wasserfallmodell

Ursprünglich fand das Wasserfallmodell im Bau- und Produktionsprozess Anwendung, in welchem späte Änderungen zu kostenintensiv oder nahezu unmöglich erscheinen. Da zum damaligen Zeitpunkt kein formaler Softwareentwicklungsprozess existierte, wurde das Vorgehensmodell notgedrungen auf den Softwareentwicklungsprozess angewandt. [15] Nicht selten wird das Phasenmodell auch als der klassische Ansatz zur Software- und Systementwicklung angesehen. Hierbei stellt das Wasserfallmodell den bekanntesten Vertreter dieser Rubrik dar, welches einer streng sequenziellen Vorgehensweise mit klar abgegrenzten Phasen entspricht. [16] Diese einzelnen Stufen werden hierbei im Rahmen des Softwareentwicklungsprozesses strikt einzeln resp. sequenziell durchlaufen, was dem Modell einen linearen und nicht iterativen Charakter verschafft. Hierbei werden die Phasenergebnisse, ähnlich einem Wasserfall, immer als bindende Vorgaben für die nächsttiefere Phase adaptiert. Dies hat zur Folge, dass Rückkopplungen auf andere Phasen des Prozesses, jeweils nur auf die unmittelbar davor liegende Phasen bestehen dürfen, hierfür gilt es jedoch eine erweiterte Version des Wasserfallmodells zu adaptieren, welches iterative Elemente implementiert. [17] Jede der einzelnen Phasen sieht hierbei eine umfassende Dokumentation vor und unterliegen der Definition eines Start- und Endpunktes. [18] Charakteristisch für das Wasserfallmodell ist, dass sich Sowohl in der Einteilung der Phasen als auch in der Rückkopplungsstrategie viele Unterschiede befinden. In der Fachliteratur ist nur selten auf zwei identische Modellbeschreibungen zu treffen. [19] Da der Abschluss einer Phase in einem Dokument festgehalten wird, ist das Wasserfallmodell ein Dokument getriebenes Modell. Die einfach gehaltene Struktur des Modells verringert den Koordinationsaufwand und erhöht die Verständlichkeit. [20] Dies reduziert den verbundenen Managementaufwand, weiterhin hat sich das Modell in der Vergangenheit als eines der ersten Prozessmodelle seiner Art wesentlich zu einem disziplinierten, sichtbaren und kontrollierbaren Prozessablauf beigetragen. [21] Auch wenn das Modell in der Praxis wie bereits angeführt verschiedenste Modifikationen erfährt, gehen wir im Folgenden von vier Inkrementellen Phasen aus. Zu Beginn steht die Analysephase, diese fokussiert sich auf das zu lösende Problem, welches Anstoß für das Projekt gibt. Die Entwurfsphase zielt darauf ab, sich mit den Anforderungen an die zu entwickelnde Software zu befassen. Die Realisierungsphase zielt darauf ab, die Vorgehensweise, wie die Anforderungen erfolgreich umzusetzen sind, zu gestalten. Die Integrations- und Systemtestphase dient dazu, die Software zu programmieren und zu testen, auf welche die Einführung der Software in den Markt folgt. [22] Der Ablauf des Wasserfallmodells ist der 3. Abb. zu entnehmen.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

3. Abb. Klassisches Wasserfallmodell. Quelle: Mast, S. (2015), S. 7; 6. Kap. 2. Abs.

Hervorragend eignet sich das Wasserfallmodell vor allem für Projekte, bei denen bereits zu einem frühen Zeitpunkt alle Anforderungen, Leistungen und Abläufe bekannt sind und festgelegt werden können. Wesentliche Vorteile des Modells bestehen u. a. in der klaren Abgrenzung der einzelnen Phasen, der Einfachheit des Modells und darin, dass die Projektkosten bereits zu Beginn des Projektes abgeschätzt werden können. Zu den Nachteilen zählen vor allem, dass es nicht realistisch erscheint, alle Anforderungen eines Projektes bereits zu Beginn festzulegen und die Inflexibilität des Modells gegenüber Veränderungen in den Anforderungen mitunter zu Problemen führen. Weiterhin werden Fehler u. u. erst sehr spät erkannt, was mit einem hohen Aufwand zur Behebung verbunden ist. [23] Die jeweiligen Vor- und Nachteile des Modells, sind der 1. Tab. zu entnehmen.

[Diese Tabelle ist nicht in der Leseprobe enthalten.]

1. Tab. Vor- und Nachteile des Wasserfallmodells. Quelle: Eigene Darstellung in Anlehnung an Gaida, V. J. (2023), 3. Kap. 1. Abs. bis 2. Abs.; Windpohl, A. (2021), 7. Kap. 1. Abs. bis. 8. Kap. 1. Abs.

2.3 Agiles Vorgehensmodell Scrum

Heutzutage ist Scrum als der De-Facto-Standard in der agilen Softwareentwicklung zu bezeichnen. [24] Der Name Scrum steht im Rugby für Gedränge. Im Kontext der Softwareentwicklung bietet Scrum ein Framework, welches Developer-Teams dabei unterstützt, ihre Arbeit mithilfe einiger Werte, Prinzipien und Praktiken zu strukturieren und zu verwalten. Genau wie beim Rugby-Team, welches für das große Spiel trainiert, sind Scrum Teams dazu in der Lage, sich durch die gemachten Erfahrungen bei der Problembehebung selbst zu organisieren und einen Reflexionsprozess zu starten, welcher zur kontinuierlichen Verbesserung beiträgt. [25] Üblicherweise wird unter einem Scrum Team, ein kleines interdisziplinäres Team von zehn oder weniger Personen verstanden, welches eine differenzierte Rollenverteilung aufweist. Innerhalb dieses Teams bestehen keine Teilteams oder Hierarchien. Vielmehr handelt es sich um eine geschlossene Einheit von Fachleuten, die sich auf das Hauptziel konzentrieren, das Produktziel mittels Increments voranzutreiben. [26] Diese Teams sind mitunter hocheffektiv, da sie nach dem klassischen Modell der self-directed -work-Teams, den autonomen Arbeitsgruppen gebildet sind, was ihnen ermöglicht mehrere Arbeiten entlang des Arbeitsprozesses durchzuführen. Das Team organisiert die Aufgaben vollständig selbst, wobei der Scrum Master nicht Teil des Entwicklungsteams ist, sondern lediglich die Rahmenbedingungen um das Scrum-Team herum organisiert. Der Product Owner entscheidet hingegen aus fachlicher Perspektive heraus, welche Maßnahmen umgesetzt werden sollen. [27] Der 2. Tab sind die jeweiligen Rollen und deren Team internen Funktionen zu entnehmen.

[Diese Tabelle ist nicht in der Leseprobe enthalten.]

2. Tab. Rollenverteilung innerhalb eines Scrum-Teams. Quelle: Bundesministerium des Innern und für Heimat [BMI]. (2023), 4. Kap. 14.2. Abs.; Schwaber, K. Sutherland, J. (2020), S. 5; Hundermark, P. (2009), S. 6; Radon, B. (2015), S. 1

Hierbei basiert das Modell auf Empirie und Lean-Thinking. Empirie bedeutet in diesem Kontext, dass Wissen aus Erfahrungen gewonnen wird und Entscheidungen auf der Grundlage von Beobachten getroffen werden. Lean-Thinking reduziert Verschwendungen und hilft dabei, sich auf das Wesentliche zu konzentrieren. [28] Scrum gehört zu den aktuell wohl bekanntesten agilen Projektmethoden. Dabei ist diese nicht nur der Softwareentwicklung vorbehalten, sondern kann auch für das agile Projektmanagement adaptiert werden. [29] Zumeist stellt es jedoch ein iteratives und kundenorientiertes Vorgehensmodell für die Softwareentwicklung dar, welches die Prinzipien der agilen Softwareentwicklung praxisgerecht einsetzt. Hierbei setzt sich der Prozess aus mehreren Rückkopplungsschleifen zusammen, welche ineinander verschachtelt sind. Die einzelnen Phasen beginnen mit der Planung, über die Durchführung, bis hin zur Überprüfung und Anpassung. [30] Hierbei ist zu beachten, dass agil und Scrum nicht dasselbe sind. Während es sich bei Scrum um ein Framework zur Bewältigung von Aufgaben handelt, beschreibt Agile ähnlich dem Hacker Manifesto des Mentors eine Philosophie, welche dem agilen Manifest zu entnehmen ist und teilweise in die Scrum Methodologie einfließt. [31] Die agile Philosophie beschreibt sich wie folgt: „Individuals and interactions over processes and tools. Working software over comprehensive Documentation. Customer collarboration over Contract negotiation. Responting to change over following a plan“. [32] Eine Charakteristik der agilen Vorgehensmodelle besteht darin, dass diese aus kleinen inkrementellen Phasen bestehen, welche als Ergebnis kleinere Softwarekomponenten unter Nutzung bestimmter Architekturansätze wie bspw. dem Microservice-Ansatz bereitstellen. Weiterhin beziehen agile Vorgehensweisen wie Scrum, Extreme Programming (XP), Rational Unified Process (RUP), Crystal, Feature Driven Development (FDD), etc. Kunden resp. Stakeholder in den Entwicklungsprozess mit ein. [33] Das Projekt wird hierbei in einzelne sog. Sprints aufgeteilt, welche einen Artefakt-Charakter aufweisen und dem Scrum-Team eine Übersicht über alle Tasks, Anforderungen und fertiggestellte Teilprodukte liefern. Scrum fordert hierbei vier Artefakte, diese sind der Product-Backlock, der Sprint-Backlock, der Burndown-Chart und das Impediement-Backlock. [34] Unter dem Product-Backlock ist eine einfache Liste von Arbeitsgegenständen resp. Anforderungen an das Produkt zu verstehen, welche über die Zeit erledigt zu werden haben. Während die Einträge im Backlog von jedem hinzugefügt werden können. [35] Weiterhin stellt dieser, das Bindeglied zwischen dem Product-Owner und dem Scrum-Team dar. In diesem legt der Product-Owner Kriterien dar, welche bspw. nach wirtschaftlichem Nutzen, Aufwand, Risiko und Notwendigkeit an das zu entwickelnde Produkt in der Form einer Liste priorisiert werden. Diese To-do-Liste ist als Ergebnis des Release Planning zu verstehen (Produkt-Vision) und wird entlang des Projektverlaufes immer weiter verfeinert. Somit ist der Product-Backlog, also kein endgültiger Prozess, welcher zu Projektstart beginnt, sondern kann jederzeit um neue Anforderungen erweitert werden. [36] Der Sprint-Backlock, stellt zumeist die physische Repräsentation einer Liste der Arbeit dar, welche für den jeweiligen Sprint erforderlich ist und einem Kanban Bord ähnelt. Hieraus können alle am Prozess Beteiligten einsehen, welche Arbeit für den Sprint geplant wurde, und in welchem Status sich die Arbeit befindet. [37] Das Sprint-Burndown Chart hilft dem Team bei der Überwachung seines Fortschrittes, sowie bei der Frage, ob es sein Lieferversprechen am Ende des Sprints einhalten kann. Normalerweise erfasst das Team seine Arbeit in Stunden und trägt die gesamte restliche Arbeitszeit für alle unvollendeten auf täglicher Basis in ein Diagramm ein. [38] Das Product- oder Release-Burndown-Chart ist dazu da, um die Rate der Lieferungen eines Stroms von lauffähigen, getesteten Features über einen determinierten Zeitraum zu messen, dieses Maas ist auch als die Velocity des Teams bekannt. Aufgrund der variierenden Komplexität und den sich hierdurch verändernden Variablen des Aufwands resp. der Laufzeit, wird eine Skala adaptiert, um die bestehenden Größen zu messen. Die weit verbreitetste Skala zur Messung ist als Story-Points bekannt. I.d.R. pendelt sich die Velocity in einem definierbaren Bereich ein, sobald ein Team eine Reihe von Sprints zusammen abgearbeitet hat. Diese Velocity kann vom Product Owner dazu herangezogen werden, um die zukünftige Lieferrate des Teams zu bestimmen. [39] „Ein Projekt ohne ein einziges Problem ist in etwa so wahrscheinlich wie ein Sechser im Lotto. Manche Projektmanager halten das sogar für völlig unmöglich.“ [40] Unter dem Impedient-Backlock ist eine Liste der aktuellen Dinge (Impediments) zu verstehen, welche das Team daran behindert, Fortschritte zu erzielen, oder sich zu verbessern. Mitunter handelt es sich bei diesen Hindernissen, um eben jene, welche der Scrum-Master aus dem Weg zu schaffen hat, um seiner niemals endenden Mission, das Team so gut wie möglich zu unterstützten, zu entsprechen. [41] Somit handelt es sich also um Impediments, welche vom Entwicklungsteam nicht im Sinne der Selbstorganisation zu bewältigen sind. Zu diesen gehören bspw. logistische, infrastrukturelle Probleme und Hindernisse, welche nicht selten bis in den Bereich der Kommunikation hineinfallen. Die aktuellen Impediments werden im Rahmen der täglichen Scrum-Meetings (Daily-Scrum) vom Team mitgeteilt und durch den Scrum-Master im Impediment-Backlock dokumentiert. [42] Die Sprints umfassen einen festgelegten Zeitraum, bspw. vier Wochen. [43] Jeder Sprint beginnt damit, die Anforderungen aus dem Product-Backlog, einer Sammlung aller noch zu erledigenden Anforderungen, in den Sprint Backlock, einer Sammlung, welche die in diesem Sprint noch fertigzustellende Anforderungen enthalten sind, zu übernehmen. Zu Ende des Sprints werden dann die im sog. Sprint-Review, die erfolgreich abgeschlossenen Anforderungen vom Product-Owner abgenommen. Zuletzt werden die Sprints in der Retrospektive analysiert, um ggf. Änderungen und Verbesserungen in den Ablauf zu integrieren. Hierbei bietet Scrum umfassende Möglichkeiten, den sich dynamisch verändernden Bedingungen der extern auf das Projekt wirkenden Anforderungen während vorlaufender Entwicklung gerecht zu werden. Grundsätzlich besteht ein Sprint aus den folgenden fünf Aktivitäten. 1.) Zu Beginn steht das Sprint-Planning, hierbei wird der Sprint geplant. 2.) Unter dem Daily-Scrum, ist das tägliche Treffen des Entwicklerteams zu verstehen. 3.) Kommt es zur Umsetzung der Backlog-Items für das Inkrement. 4.) Hier kommt es zur Sprint-Review, was der Repräsentation des erstellten Inkrements entspricht. 5.) Die Sprint-Retrospektive, bezieht sich auf die Analyse und Bewertung des methodischen Vorgehens während des Sprints und bezieht auch die Planung von Verbesserungsmaßnahmen mit ein. [44] Eine Übersicht über den Scrum-Entwicklungsprozess ist der 4. Abb. zu entnehmen. [45]

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

4. Abb. Der Scrum Entwicklungsprozess. Quelle: Faßrainer, S. (2016), S. 7

Der Erfolg von Scrum als Methode des agilen Projektmanagements dependiert maßgebend an dem Vertrauen, welches das Management in die Fähigkeit des Projektmanagements aufweist, da diesem durch in seiner erweiterter Rolle als langer Arm der Unternehmensführung einiges an Spielraum geboten wird. Im Gegensatz zum klassischen Top-down-Ansatz erfordert dies ein grundlegendes Umdenken, da Scrum-Master, Product-Owner und Entwicklungsteam mit autarken Managementfunktionen ausgestattet werden. [46] Der nachfolgenden 3. Tab. sind die jeweiligen Vor- und Nachteile der Scrum-Methode zu entnehmen.

[Diese Tabelle ist nicht in der Leseprobe enthalten.]

3. Tab. Potenziale und Restriktionen von Scrum. Quelle: Clevis Consult (2023), 3. Kap. 1. Abs. bis. 9. Kap. 1. Abs.; Agiles-Projektmanagement.org (2023), 15. Kap. 2. Abs. bis 3. Abs.; International Association of Project Managers [iapm]. (2023), 4. Kap. 2. Abs. bis 3. Abs.

2.4 Zusammenfassung der wesentlichen Unterschiede des Wasserfallmodells und der agilen Scrum-Methode

Anders als bei der Wasserfallmethode verzichtet Scrum auf eine vollständige Planungsdokumentation, was jedoch nicht bedeutet, dass diese in der Scrum-Methode nicht für gewisse Sprints adaptiert wird. Somit besteht beim Scrum-Ansatz keine Strategie, welche es vom Beginn des Projekts, bis zum Projektende einheitlich zu verfolgen gilt. Während bei Scrum in Sprints gedacht wird, wird das Projekt beim Wasserfallmodell in mehrere Phasen aufgeteilt, welche wie bereits angeführt linear aufeinander aufbauen, die am Ende jeder Phase hinsichtlich vorher festgelegten Arbeitsschritten abgenommen zu werden haben, um eine neue sequenzielle Phase zu beginnen. Gerade bei ungeplanten Änderungen im Projektablauf führt dies zu exponentiell steigenden Kosten. [47] Beziehen wir den Vergleich der beiden Vorgehensmodellen auf die Projektpraxis eignet sich das Wasserfallmodell vor allem für Projekte, welche den folgenden Charakteristiken entsprechen. 1.) Projekte, bei denen mehrere Organisationen oder externe Mitarbeiter zusammenarbeiten. 2.) Projekte, welche einen festen Umfang, Zeit und Budget aufweisen. 3.) Weiterhin sollten diese Projekte klein, mit definierten Zielen und einfach sein. 4.) Projekte, bei welchen der Kunde nicht anwesend ist. Beim agilen Vorgehen sollten die Projekte folgende Charakteristiken aufweisen. 1.) Organisation ist für den gesamten Prozess verantwortlich. 2.) Die Projekte sollten genug Spielraum für sich ändernde Anforderungen aufweisen. 3.) Die Projekte sind zumeist groß, undefiniert und komplex. 4.) Der Kunde wird direkt in das Projekt integriert. [48] Da die beiden Vorgehensmodelle als jeweils geeigneter Vertreter von klassischen und geeigneten Projekten gelten, erscheinen die von Paul angebrachten Merkmale und Differenzierung als angebracht. Sehe 4. Tab.

[Diese Tabelle ist nicht in der Leseprobe enthalten.]

4. Tab. Voraussetzungen des klassischen Projektmanagements vs. agilen Projektmanagements. Quelle: Paul, J. (2017), S. 37

3.1 Voraussetzungen zur Adaption des Scrum Frameworks und Entwicklung einer Produktvision für das KI-Projekt

Bevor wir uns mit der Umsetzung des Softwareentwicklungsprozesses mittels Scrum zuwenden, gilt es zunächst die für ein solches Projekt geltenden Voraussetzungen anzuführen. Wie oben bereits angeführt, sind diese überwiegend in der Unternehmenskultur verankert. So gilt es vor allem eine positive Fehlerkultur, Vertrauen in die Mitarbeiter sowie Freiheit, die Eigenverantwortlichkeit und Selbstorganisation des Teams zu kultivieren. [49] Die nachfolgende 5. Abb. visualisiert den Scrum Prozess, welcher uns als Leitfaden zur praktischen Umsetzung des Scrum-Projektes dient.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

5. Abb. Scrum Prozess. Quelle: Adam, J. Böllhoff, P. (2023), 5. Kap. 5. Abs.

Jedes Scrum-Projekt beginnt mit einer Produkt-Vision. Hierunter ist eine grobe Vorstellung vom Produkt oder dem Projektergebnis zu verstehen, welches durch die Geschäftsleitung oder den Product-Owner in Auftrag gegeben wurde. [50] Für das Beispielprojekt könnte eine solche Vision z.B. die Entwicklung einer künstlichen Intelligenz zur Bestimmung der Cyberbedrohungslage für Unternehmen darstellen, indem die KI zur Erkennung von Abweichungen vom Normalverhalten, bspw. der Erkennung von Störeinflüssen resp. der Detektion von Anomalien im Firmeninternen Datenverkehr verwendet wird. [51] Der konkrete Anlass oder Auslöser besteht dabei z.B. in der zunehmenden Adaption von künstlicher Intelligenz bei Cyberangriffen. [52] In der Phase der Visionsfindung sind seitens des Project- Owner, sowie der Sponsoren vor allem über das Warum, das Projektziel und die zu erwartenden Outcomes und Messgrößen zur Erfolgsbewertung festzulegen. Da dieses Framing als Ausgangspunkt dient und dabei hilft, die Vision des Projektteams, sowie dessen Handeln zu fokussieren. Auch wenn die Scrum Methode für ihre geringen Dokumentationsverfahren bekannt ist, sollten die angeführten Aspekte verschriftlicht werden. [53]

3.2 Ableitung der Produktvision und Präzisierung mittels Story-Cards

Aus der verfassten Definition des Projektes resp. Produktes lassen sich im Weiteren nun einzelne Funktionen und Merkmale, welches dieses aufzuweisen hat, sowie konkrete Lösungen ableiten, welche im Projekt zu entwickeln sind. Hierzu beschreiben die Kunden und Nutzer ihre Anforderungen und Erwartungen aus der Anwenderperspektive, welche auf einer Story-Card formuliert werden. Hierbei fungiert die Story-Card als Medium, auf welchem die User-Story möglichst exakt erfasst und dargestellt wird. Nicht selten werden zur Entwicklung besagter, eigene Workshops abgehalten, an welchen auch der Product-Owner teilnimmt. Sinn dieses Unterfangens besteht darin, die Anforderungen des Projektes möglichst genau zu erfassen, um den Ressourcenaufwand des Projektes zu bestimmen. Neben den geforderten monetären Ressourcen hilft dies vor allem dabei, die Art der benötigten Qualifikationen, das Know-hows des Projektteams, sowie eine grobe Schätzung des Aufwands für die Entwicklung zu bestimmen. [54] Für die Erstellung eines KI-Modells können hierfür Modelle zur Konzeption Reihenfolge als Ausgangspunkt dienen, sehe 6. Abb.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

6. Abb. Mögliches Vorgehensmodell im Rahmen von KI-Projekten. Quelle: Gotscharek&Company Managing Success (2023), 5. Kap. 1. Abs.

3.3 Effiziente Priorisierung und Ableitung der Story-Cards in den Backlog-Prozess

Nach der Erstellung und Kategorisierung ausreichender User-Storys, haben diese im Backlog priorisiert zu werden. Da Agilität kontinuierliches Lernen und Anpassen umfasst, werden, solange die Arbeit am Projekt fortgesetzt wird, weitere User-Storys erstellt. [55] Alle relevanten Informationen, bezüglich den Anforderungen des Product-Owner und der Nutzer, welche aus den gesammelten User-Storys extrahiert werden, fließen mit in den Product-Backlog ein. Wie bereits angeführt, handelt es sich hierbei um eine Sammlung sämtlicher Funktionen und Merkmale, welche ein Produkt oder die Lösung für ein Projekt aufzuweisen hat. Im Product-Backlog können neben den Merkmalen und Funktionen auch Aufgaben oder Arbeitspakete für das Scrum-Projekt zusammengestellt sein. Unter einem Backlog-Item ist eine einzelne Aufgabe, Funktion oder Merkmal zu verstehen. Da am Anfang eines Projektes innerhalb eines Projektteams die Teilaufgaben noch nicht mit einer Lösung verknüpft, oder welche Eigenschaften die Funktionen im Detail aufzuweisen haben, sind die Backlog-Items in dieser Phase meistens sehr grob beschrieben. Dies ändert sich jedoch, wenn das jeweilige Backlog-Item entwickelt oder ausgearbeitet wird. Für diesen Prozess sind weitere Gespräche mit den Rezipienten notwendig, um während des Projektverlaufes immer detailliertere Informationen zu beschaffen. [56] Zur Bestimmung, wann ein Backlog-Item als abgearbeitet gilt, wird im Scrum-Backlog die (Definition of Done) praktiziert. Hierunter sind genaue Definitionen zu verstehen, welche messbare Kriterien (erledigt, oder nicht erledigt) enthält als Maß herangezogen werden, um zu bestimmen, ob ein Backlog-Item als erfüllt erachtet werden kann. Erst wenn alle Kriterien abgearbeitet wurden und als erledigt konnotiert werden, gilt das Backlog Item als erledigt. [57] Da die Komplexität meistens ein guter Indikator für den (zeitlichen) Aufwand zur Realisierung eines Backlock-Items darstellt, werden sog. Story-Points erstellt. [58] „Story Points werden auch Agile Points oder Scrum Points genannt und kommen zum Einsatz, um eine Aufwandsschätzung in Zahlen (bspw. 5, 13 oder 55) durchzuführen. Im Fokus steht die Schätzung der Komplexität einer Aufgabe, nicht der Aufwand in Personentagen. Den Komplexitätsgrad definiert das Team gemeinsam.“ [59] Die Kalkulation, wie viele Stunden Entwicklungsaufwand mit einem Story-Point verbunden sind, geschieht aus bereits gesammelten Erfahrungswerten oder dem Projektverlauf. Die Verknüpfung eines Story-Points mit einem Zeit- oder Geldfaktor, hilft bei der Bestimmung einer Zeit- resp. Kostenkalkulation. Wird ein Backlog-Item bspw. mit 10 Story-Points bewertet, ist dieses als doppelt so komplex und aufwendig zu konnotieren, als ein Backlog-Item, welches lediglich mit 5 Punkten bewertet wird. [60] Grundsätzlich profitiert das gesamte Team durch die Vergabe von Story-Points, da diese eine schnellere Planungszeit ermöglichen, indem sie auf das gesammelte Wissen des Teams zurückgreifen. [61] Normalerweise geht die Story-Point-Schätzung dem Sprint-Planungsmeeting voraus, damit beim Meeting selbst, dann alle nötigen Informationen bereitstehen. Um zu evaluieren, wie viel Arbeit in den nächsten Sprint gepackt werden kann. [62] Bei der Entwicklung eines KI-Modells, ist somit davon auszugehen, dass der Sondierung des Anwendungsfelds ein geringerer Story-Point Wert zugesprochen wird als z. B. der Auswahl und Klärung des Umfeldes. Beziehen wir die oben angeführten Faktoren Zeit und Kosten mit ein, ist davon auszugehen, dass der Modellierung der Daten und dem Aufbau des Modells und den mit diesen Hauptkategorien verbundenen Prozessschritte, der höchste Wert an Story-Points zuzuschreiben ist. Gerade die Beschaffung der Daten unter den gültigen DSGVO-Bestimmungen, deren Bereinigung, die benötigte Expertise zur Entwicklung und Wartung, stellen zeitlich und kosten ineffiziente Faktoren dar. Unternehmen, welche diese Kosten zu senken vermögen, starten i.d.R. mit einem starken Data-Science-Kompetenzzentrum. [63] Für die Priorisierung der im Produkt-Backlog enthaltenen Items ist wie bereits angeführt alleine der Product-Owner verantwortlich, welcher diese auf der Grundlage der Wünsche und Ambitionen der Stakeholder erstellt. [64] Items erhalten eine hohe Priorität, indem die Aufgaben, Merkmale und Funktionen, welche diesen zugrunde liegen, sich als besonders wichtig für die Anwenderzufriedenheit herausstellen. Weiterhin haben sich diese auch als wesentlich für das Produkt- und Projektergebnis zu erweisen. Eine geringe Priorität wird solchen Aufgaben, Merkmalen und Funktionen zugesprochen, welche für den Endnutzer als nicht wichtig klassifiziert werden. Diese Items mit geringer Priorität werden verschoben, zurückgestellt, oder gar nicht entwickelt, weil dies nicht mit dem gesetzten Zeitrahmen oder dem vorhandenen monetären Mitteln übereinstimmen. Nicht selten werden diese erst bei der Überarbeitung oder der Erweiterung des Produktes im Rahmen eines Release-Wechsels in Betracht gezogen. [65] Die oberen Items am Anfang der Liste hingegen weisen einen wesentlich höheren Detaillierungsgrad auf, sodass diese sprintfähig sind und von den Entwicklern angegangen werden können. [66]

3.4 Praktisches Beispiel des Product-Backlog des KI-Modells und Erarbeitung der Meilensteine

Als praktisches Beispiel für die Erstellung des KI-Projekts dienen uns aus der 6. Abb. bezogenen Prozessschritte, welche in der folgenden 5. Tab. um die Story-Points und Backlog Priorisierung erweitert. Im Folgenden wird davon ausgegangen, dass sich der Entwicklungsprozess bereits jenseits der Phase 6, als des Modelltests befindet und somit Endkonsumenten über Zugang zum Testsystem verfügen. Anzumerken bleibt, dass nachfolgend nur einige Beispiele an Items angeführt werden, die Praxis erweist sich als westlich komplexer.

[Diese Tabelle ist nicht in der Leseprobe enthalten.]

5. Tab. Beispielhafte Items in einem Product-Backlog mit Story Points und Priorität. Quelle: Eigene Darstellung.

Nach einer ersten Priorisierung der Items im Sprint-Backlog trifft sich das Projektteam unter der Führung des Scrum-Masters zu einer ersten Besprechung, bei welcher die Rahmenbedingungen des Projektablaufes abgesteckt werden und ein gemeinsames Verständnis vom Produkt, den wichtigsten Aufgaben, sowie des zeitlichen Ablaufes entwickelt wird. Da sich bei Scrum-Projekten im Projektverlauf ohnehin viel ändert, kann es als Vorteil erachtet werden, dass die Ablaufplanung nur grob ist und keinen großen Aufwand verlangt. Viel wichtiger ist es, die K.-o.-Kriterien, Ziele und Meilensteine herauszuarbeiten. Bei diesem Meeting gilt es vor allem folgende Fragen zu beantworten: [67] „Wie soll der allgemeine Aufbau des Produkts oder der Lösung aussehen? Was sind die Meilensteine? Welche Funktionen und Aufgaben müssen bis zu welchem Zeitpunkt in jedem Fall erledigt sein? Was sind die Teilziele für eine einzelne Funktion oder Aufgabe? In welche Teilschritte, Sprints, lässt sich das Projekt untergliedern? Auf welche Details oder Besonderheiten ist zu achten? Welche Konventionen und Schnittstellen sind einzuhalten? Wo und wann kann sich das Team regelmäßig für den Daily Scrum (täglich!) treffen“. [68] Die nachfolgende 7. Abb. zeigt uns anhand eines Pfeildiagramms, wie ein solcher KI-Entwicklungsprozess grundlegend aussehen kann (ohne detaillierte Items).

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

7. Abb. Von der Idee zum Produkt mit Scrum. Quelle: Gotscharek&Company Managing Success (2023), 7. Kap. 1. Abs.

3.5 Sprint-Planning und transparente Aufgabenverteilung im agilen Scrum-Prozess

Nach der Bestimmung der projektbedingten Parameter, kommt es zum Sprint-Planning, welches als gemeinschaftliches Event zu erachten ist, an welchem das gesamte Scrum-Team partizipiert. Im Normalfall wird diese Diskussion vom Product-Owner geführt, bei welcher die Items im Product-Backlog und deren Beitrag zum Produktziel priorisiert werden. Hierbei gilt als normal, Stakeholder in die Diskussion einzuladen, welche nicht direkt Bestandteil des Scrum-Teams sind, dies wirkt befriedigend auf die Interessenvielfalt der verschiedenen Interessengruppen. [69] Zur Festlegung der Time-Box, welche dem Sprint zugewiesenen Zeitrahmen entspricht, dependiert maßgeblich an der für den jeweiligen Sprint ermittelten Umfang und Komplexität, sowie der jeweils zu bearbeitenden Aufgabe. [70] Fragen, die es während des Sprint-Planning zu beantworten gilt, lauten wie folgt: „Warum ist dieser Sprint sinnvoll? Welche Elemente des Product Backlogs können in diesem Sprint abgeschlossen werden? Wie wird die Arbeit ausgeführt?“ [71] Aus dem Sprint Planning werden anschließend sog. Sprint-Tasks oder Tickets abgeleitet. Diese Teilaufgaben werden im Sprint-Backlog, also dem Maßnahmenplan angeführt und z.B. am Sprint-Taskboard visualisiert. Unter dem Sprint-Backlog und dem Taskboard ist gewissermaßen eine Art Maßnahmenplan zu verstehen, welcher den Arbeitsvorrat für das Entwicklerteam für den nächsten Sprint anzeigt. Die Aufnahme einer Teilaufgabe aus dem Arbeitsvorrat, leitet die eigenverantwortliche Arbeit des Entwicklers ein, womit sich dieser zur Lösungsfindung resp. zur Entwicklung einer Lösung verpflichtet. [72] Die 8. Abb. visualisiert den Prozess des Sprint Planning im Rahmen des Scrum-Prozesses.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

8. Abb. Scrum-Prozess und Sprint im Überblick. Quelle: Fleig, J. (2023), 8. Kap. 2. Abs.

3.6 Bessere Visualisierung der Sprints durch die Adaption eines Sprint-Boards und Kanban

Oben fiel bereits der Begriff des Sprint-Boards, dieses wird in der Literatur oft auch als Scrum-Board, oder Scrum-Taskboard bezeichnet. Dieses Taskboard offeriert den Scrum-Teammitgliedern eine holistische Übersicht über die einzelnen Tasks, welche zu erledigen sind. Grundsätzlich ist hierunter ein physisches, resp. virtuelles Whiteboard zu imaginieren, auf welchem der Fortschritt des Sprints von der Entstehung, bis hin zum Abschluss abgebildet wird. Gerade im Bereich der Softwareentwicklung, Marketing Business, HR usw. hilft dieses dabei, die Komplexität der Projekte besser zu überschauen. Dies geschieht u. a. dadurch, dass die verschiedene Aufgaben der Arbeitsgruppen isoliert, organisiert, sowie jede Aufgabe durch ihren Lebenszyklus genauestens überwacht wird. [73] Nicht selten wird das Sprint-Taskboard durch die Adaption eines Kanban-Boards stärker untergliedert und verbessert. Durch Kanban können die Sprints z. B. durch eine phasenspezifische Betrachtungsweise erweitert werden. Dies ermöglicht jedem Scrum-Teammitglied zu jeder Zeit die Items resp. Tickets im Sprint zu verfolgen. Bei der Planung der Sprints ist zu berücksichtigen, dass insg. nur so viele Tickets zur Bearbeitung freigegeben werden können, wie vom Projektteam im Rahmen der bestehenden Kapazitäten auch bearbeitet werden können. Ein anderer Vorteil des Sprint-Taskboards besteht im visuellen Hervortreten von potenziellen Engpässen, welche mitunter deshalb hervortreten, da sich die unbearbeitete Tickets auf dem Sprint-Taskboard unverkennbar anstauen. Eilige Tickets, oder solche, welche über eine hohe Priorität verfügen, können mit Signalfarben zur Bearbeitung hervorgehoben werden. [74] Kategorien, durch welche die typischen Spalten eines Scrum Boards unterteilt werden sind bspw. 1.) User Storys, Backlog. Hier werden die oben angeführten User Storys und Backlog-Items gelistet. 2.) To do, hier werden die noch nicht gestarteten Aufgaben angezeigt. 3.) Work in Progress (WIP). Enthält die Tasks, welche gerade ausgeführt, resp. bearbeitet werden. 4.) Done stellt zumeist die letzte Spalte dar und enthält alle erledigten Aufgaben. Wie die nachfolgende 9. Abb. zeigt, kann ein Sprint-Taskboard, welches Kanban adaptiert, jedoch auch um individuelle Kategorien individualisiert werden. Unabhängig, der spalten spezifischen Möglichkeiten zur Individualisierung erscheint es in jedem Fall notwendig, eine Spalte dem (Done) zu widmen, da hierdurch der Abschluss jedes Ziels angezeigt wird, dies ist erforderlich, um den Übergang zum nächsten Sprint zu ermöglichen. [75] Wie oben angeführt wurden einige der Tickets mit der Signalfarbe rot markiert, um dem Entwicklertram deren Relevanz zu signalisieren.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

9. Abb. Kanban-Board als detailliertes Sprint-Taskboard. Quelle: Fleig, J. (2023), 9. Kap. 4. Abs.

Um im vereinbarten Zeit- und Kostenrahmen zu bleiben, liegt der Fokus der Teammitglieder auf dem determinierten Zeitplan, dem Aufwand und den vereinbarten Meilensteinen. Deshalb orientieren sich die Teammitglieder während der Abarbeitung ihrer Aufgaben (Sprint-Tasks) vor allem an den Story-Cards, mit deren Hilfe diese prüfen und testen, ob die von ihnen erbrachte Lösung innerhalb der gegebenen Time-Box, als ausreichend zu konnotieren ist. [76]

3.7 Daily-Scrum als Hilfsmittel zur Fokussierung des Fortschrittes in Richtung des Sprint-Ziels

Das Daily-Scrum stellt mitunter wegen seiner Regelmäßigkeit das bekannteste Ereignis des Scrum-Prozesses dar. Wie bereits angeführt wird hierunter ein routinemäßig und zeitlich auf 15 Minuten begrenzte Besprechung verstanden, welche unbedingt an jedem Arbeitstag, zur selben Zeit und möglichst am selben Ort stattfinden sollte und hinsichtlich der Konsistenz und Effektivität in den Aufgabenbereich des Scrum-Masters fällt. Die Konzeption dieses Events zielt darauf ab, den Fokus auf den Fortschritt in Richtung des Sprint-Ziels zu legen, wobei die Weise, wie das Daily Scrum zu organisieren ist, auf die Förderung der Selbstorganisation und der Übernahme der Verantwortlichkeit der einzelnen Entwickler untereinander und gegenüber dem Entwicklungsteam als Ganzes abzielt und kein klassisches Meeting im Sinne eines Updates an den Projektmanager darstellt. Grundlegende Aktivitäten bestehen in der Aufzeichnung des Fortschrittes im Hinblick auf das Scrum Sprint-Ziel, synchronisieren die Aktivitäten und erstellen einen Plan für die nächsten 24 Stunden. Die einzige feste Regel innerhalb des Daily-Scrum besteht darin, sich auf in die Richtung des Sprint-Ziels zu fokussieren und einen umsetzbaren Plan für die Arbeit des kommenden Tages zu definieren. [77] Die Hauptfragen des Daily-Scrum können wie folgt umschrieben werden, „Was wurde seit dem letzten Scrum gemacht? Was ist bis zum nächsten Scrum zu tun? Was behindert bei der Arbeit oder was verhindert die weitere Bearbeitung?“ [78] Probleme, welche im Daily-Scrum auftreten, werden im Impediment-Backlog festgehalten. [79]

3.8 Burndown-Chart als Hilfsmittel zur holistischen Abbildung des Projektfortschrittes

Neben dem Daily-Scrum hilft vor allem das Burndown-Chart dabei unter der Zuhilfenahme visueller Informationen das tägliche Management des Projekts resp. der Scrum-Sprints zu planen, in dem es den Projektfortschritt abbildet. Die Informationen, welche aus dem Burndown-Chart extrahier werden, helfen während des Daily-Scrum mitunter dabei, die verbleibende Arbeitslast des Gesamtprojekts oder des aktuellen Sprints zu verdeutlichen. [80] Um dies zu gewährleisten, hält das Sprint-Burndown-Chart fest, welche Ressourcen oder Arbeitszeiten des Gesamtprojekts bereits aufgebraucht wurden. Der kalkulierte Ist-Aufwand wird hierbei mit dem Plan-Aufwand verglichen und in einem Diagramm einfach zu verstehen abgebildet, um sicherzustellen, dass sich das Projekt im vereinbarten Zeit- und Kostenrahmen befindet. [81] Sehe 10. Abb.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

10. Abb. Burn-Down-Chart für das Controlling im Scrum-Sprint. Quelle: Fleig, J. (2023), 12. Kap. 3. Abs.; Lang, M. (b). (2023), 3. Kap. 2. Abs.

3.9 Feedback, Abnahme und Neuplanung im agilen Scrum-Prozess durch das Sprint-Review-Meeting

Zur Ende eines jedes Sprints steht das sog. Sprint-Review-Meeting an, dieses ist der offizielle Moment nach jedem Sprint, bei welchem den Stakeholdern das Fertige (Teil-Produkt) durch das Scrum-Team vorgestellt wird. Für die Stakeholder ist dieser Moment mitunter deshalb von fundamentaler Bedeutung, da diese in diesem ihr Feedback zu den vorgestellten Ergebnissen einbringen. Letztlich haben die Lösungen von den Stakeholdern akzeptieren und abgenommen zu werden. Hierbei handelt es sich nicht um eine PowerPoint-Präsentation, sondern zumeist um die Vorführung der praktischen Eigenschaften, welches das Produkt in Relation zu den im Product-Backlog geforderten Funktionen der Definition of Done aus dem Sprint (Product Increment) entspricht. [82] Erst, wenn das Teilprodukt, welches im Sprint erstellt wurde, als in Ordnung und vom Product-Owner und den Stakeholdern resp. Anwendern abgenommen wurde, wird mit der Bearbeitung der Nächsten Aufgabe aus dem Product-Backlog begonnen. Hierbei startet der Prozess des Sprint-Planning mit der Überprüfung der groben Beschreibung der Items im Produkt-Backlog von Neuem und führt zu einem weiteren detaillierten Sprint. Dieser Prozess nennt sich Product-Backlog-Refinement und kann u. a. zur Verschiebung der bisher geplanten Backlog-Items führen. [83]

3.10 Kalkulation der Velocity zur Bestimmung der durchschnittlichen Arbeitsleistung des Scrum-Teams

Für die Kalkulation der Arbeitsmenge, welche ein Scrum-Team im Laufe eines Sprints bewältigen kann, gilt es die Velocity zu berechnen. Die Velocity stellt somit eine Maßeinheit für die Schnelligkeit des Scrum-Teams dar und ist als Schlüsselkennzahl innerhalb des Scrum-Frameworks zu erachten. Verfügt ein Scrum-Team über genaue Kenntnis der Velocity, kann dieses fast punktgenau vorhersagen, wie viele User-Story-Points es im nächsten Sprint bearbeiten kann. [84] Hierbei gibt die Velocity die Menge an neu gelieferter Software in Story-Points pro Iteration (Sprints) an. Arbeitet ein Scrum-Team bspw. die in der 5. Tab. angeführten User-Storys in einem einzigen Sprint gem. der gesetzten Definition of Done ab, dann beträgt die Velocity für diesen Sprint 35 Story-Points pro Sprint. Einige Sprints weisen eine höhere, andere eine niedrigere Velocity rate auf, dies ist normal. Die Velocity ist mitunter deshalb von Bedeutung, da eingespielte Scrum-Teams mit der Zeit einen relativ konstanten Mittelwert erreichen, welcher als festes Kalkulationskriterium für die Geschwindigkeit des Scrum-Teams in der Projektplanung verwendet werden kann. Für neu gebildete Scrum-Teams bedeutet dies jedoch auch, dass zunächst einige Sprints gemeinsam durchlaufen werden müssen, bevor das Maß als valides Kalkulationskriterium Anwendung findet. [85] Um die bestehende Geschwindigkeit des Scrum-Teams zu ermitteln, wird ein sog. Velocity-Chart erstellt, welches nach jedem Sprint aus den folgenden zwei Gründen aktualisiert wird. 1.) Lernt das Scrum-Team hierdurch, ob die getroffenen Einschätzungen zu Aufwand und zum Zeitablauf realistisch waren, oder ob ggf. Änderungen im Arbeitsablauf benötigt werden, dies hilft vor allem dem Sprint-Planning. 2.) Kann der Product-Owner aus dem Velocity-Chart erkennen, bis wann er mit dem Projektabschluss resp. dem fertigen Produkt rechnen kann. [86] Praktische Tipps zur Berechnung der Velocity sind u. a. 1.) Die Messung der Velocity bereits während des Sprints. 2.) Die Punkte erledigter User-Storys werden im Sprint-Burndown-Chart eingetragen. 3.) Das Burndown-Chart wird zu jeder Zeit für alle Mitglieder des Scrum-Teams sichtbar gemacht. [87] Faktoren, welche die Velocity defizitär beeinflussen, sind multifaktoriell und können in die Hauptkategorien Technisch, Verfügbarkeit, unklare Anforderungen, Grad an Automatisierung des Softwareentwicklungs- bzw. Deployment-Prozesses und der Abhängigkeit zu anderen Teams differenziert werden. [88] Um abschließend kurz auf das Velocity Chart einzugehen ist anzumerken, dass in diesem die Aufgaben aus dem Product Backlog, den Anforderungen, welche der Definition of Done entsprechen, dem Sprint zugeordnet werden, in welchem diese erledigt wurden. Im Folgenden kommt es dann zur Addition und Kumulation der zu diesen dazugehörigen Story-Points. Das aus dieser Rechenmethode resultierende Ergebnis, ergibt ein ähnliches visuelles Bild, wie jenes, des Burndown-Chart. [89] Der 11. Abb. ist ein solches Velocity-Chart für unser KI-Projekt zu entnehmen.

[Diese Abbildung ist nicht in der Leseprobe enthalten.]

11. Abb. Velocity-Chart für ein KI-Scrum Projekt. Quelle: Haslinger, D. (2023), 2. Kap. 2. Abs.

3.11 Sprint-Retrospektive zur kontinuierlichen Verbesserung und Lösungsfindung im agilen Scrum-Team

Da das Wissen zur Berechnung der Velocity und den gängigsten Hindernissen zur Optimierung der Sprints zwar den Anfang zur kontinuierlichen Optimierung bildet, für sich genommen, jedoch keine praktischen Implikationen zur kontinuierlichen Verbesserung für das Scrum-Team aufweist, gibt es die Sprint-Retrospektive. Hierbei handelt es sich um ein spezielles Meeting im Rahmen des Agile-Frameworks, welches dem Scrum-Team ermöglicht ex-post zu beurteilen, was gut gelaufen ist und was es für die nächsten Sprints noch zu verbessern gilt. [90] Im Fokus dieses Rückblickes stehen vor allem Fragen zu: „Prozesse und Abläufe, Werkzeuge, Fähigkeiten, Beziehungen, die Zusammenarbeit im Team, generelle und spezielle Herausforderungen sowie Erfahrungen.“ [91] Erklärtes Ziel der Sprint Retrospektive besteht 1.) im Rückblick auf den gesamten Verlauf des vorherigen Sprints in Bezug auf die Mitarbeiter, sowie der Offenlegung der zwischen den Teammitgliedern und dem Prozess bestehenden Verhältnisse. 2.) Dem Aufzeigen von möglichen Verbesserungen. 3.) Der Entwicklung eines Plans für die Umsetzung der im Meeting erarbeiteten Verbesserungspunkte. [92] Anlässe für eine Sprint-Retrospektive ergeben sich vor allem dann, wenn zwischen den Scrum-Teammitgliedern resp. zwischen dem Team und dem Product-Owner ein Konfliktpotenzial entstanden ist, oder das Projekt aus anderen Gründen nicht weiter vorankommt. Im Zentrum steht die gemeinsame und teambezogene Suche nach einer Lösung, wobei sich auf die zu erbringende Schritte konzentriert wird, welche dazu notwendig sind, um die bestehenden Hindernisse zu beseitigen. [93] Der Ablaufplan einer Sprint-Retrospektive ist simpel und kann durch wenige Schritte beschrieben werden. 1.) Ziel des Meetings festlegen. 2.) Feedback des Scrum-Teams einsammeln. 3.) Erkenntnisse gewinnen. 4.) Aktionspunkte aus den gewonnenen Erkenntnissen ableiten. 5.) Das Meeting mit der Rekapitulation der erarbeiteten Erkenntnisse und Aktionspunkte abschließen. [94] Es bleibt darauf zu verweisen, dass, auch wenn die Idee der Retrospektive gut und simpel erscheint, diese in der Praxis jedoch anders abläuft. Zumeist arbeitet das Scrum-Team unter der Führung des Scrum-Masters festgelegte Standardfragen ab, woraufhin der wichtigste Verbesserungspunkt ausgewählt wird. Fragen diesbezüglich lauten bspw. wie folgt. [95] „Was kannst Du von mir erwarten? Was erwarte ich vom Team / von Dir? Was wünsche ich mir vom Team / von Dir? Was möchte ich ab sofort anders / besser tun? Was schätze ich an Dir und an Deiner Arbeit? Was wünsche ich Dir, dass Dir besser gelingt.“ [96] Fallstricke, die es hierbei zu berücksichtigen gilt, bestehen u. a. in den Faktoren Zeit und zu geringe Beteiligung. Beim Faktor Zeit hilft es im Voraus eine Tagesplanung zu erstellen, welche mit den Beteiligten geteilt wird, sowie genaue Überlegungen zur Dauer des Meetings. Zu geringe Beteiligung, kann durch das vorab Versenden von Denkanstößen, Maßnahmen zum Brechen des Eises und dem Zeigen von Dankbarkeit begegnet werden. [97] Nach dem erfolgreichen Durchlauf aller im Scrum-Projekt hinterlegten Sprints, wird das fertige Produkt an den Product-Owner geliefert, was mit dem Abschluss des Projektes gleichzusetzen ist. Vor dem Hintergrund der Nutzer und kundenspezifischen Anforderungen in den Story-Cards, prüft der Product-Owner das Produkt sowie das Projektergebnis. Der Prüfung ist zu entnehmen, welche Anforderungen, Merkmale und Funktionen des Produktes in diesem Projekt noch nicht bearbeitet wurden und aus welchen Gründen dies so ist. Ggf. werden diese in einem anschließenden Projekt berücksichtigt. Zuletzt kommt es dann zum Projet-Review, bei diesem werden alle Aspekte angeführt, welche die Zusammenarbeit erschwert oder den Prozess behindert haben, woraus sich meistens Möglichkeiten ergeben, das nächste Scrum Projekt besser zu gestalten. [98]

4.1 Diskussionen zur Ableitung der bestehenden Vorteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes

Die Ableitung der Vor- und Nachteile des KI-Projekts geschieht auf Grundlage der in der 3. Tab. angeführten Faktoren. Einer der wichtigsten Vorteile des Scrum-Frameworks in Bezug zu dem KI-Projekt besteht in der Reduzierung von potenziellen Fehlentwicklungen, welche durch die schrittweise Entwicklung des Projekts mit zahlreichen Feedbackschleifen beruht. Das in der 6. Abb. angeführte KI-Vorgehensmodell, kann so durch das Scrum-Framework in effiziente Sprints zerlegt werden, welche von den angeführten Meetings initiiert, begleitet und abgenommen werden. [99] Das Projekt profitiert vor allem dadurch, dass dem Framework wenige Regeln zugrunde liegen und dieses grundsätzlich als leicht verständlich und schnell einführbar gilt, zudem sind die meisten im IT-Bereich arbeitenden Individuen bereits darin geschult, oder hatten bereits Kontaktpunkte mit dem Framework, was die grundlegende Basis der zur Verfügung stehenden Arbeitskraft erhöht und somit die Projektkosten reduziert. [100] Weiterhin sorgt die hohe Flexibilität durch die kurzen Sprints für eine zeitnahe Umsetzung der Produkteigenschaften resp. des Projekts und fördert die Reaktionsfähigkeit bei auftretenden Problemen. Beispielsweise können die Datenwissenschaftler zügige Änderungen in den zum Training des Modells adaptierten Daten durchführen, oder nach Rücksprache mit dem Product-Owner neue Trainingsdaten für das Training adaptieren. [101] In Anlehnung zur Rücksprache mit den Stake und Shareholdern des Projektes, hilft die hohe Transparenz und deren Einbezug dabei dem Projekt entgegengebrachten goodwill zu erhöhen, was sich auch auf die Bereitschaft zur weiter Finanzierung auswirkt. Transparenz bezieht sich jedoch nicht nur auf die positiven Aspekte, sondern hilft den Beteiligten auch bei auftretenden Problemen, diese systematisch anzugehen und auf mehr Verständnis zu treffen. So kann z. B. nach bereits getätigten Investitionen, nach einer fehlgeschlagenen Produktvorführung darauf gehofft werden, ein weiteres Zeitfenster für die Problembehebung zu bekommen. [102] Bei der Problemfindung helfen vor allem die kurzen Kommunikationswege, die hohe Effektivität durch Selbstorganisation und die kontinuierliche Verbesserungsmentalität dabei, die Integrität des Scrum-Teams zu schützen. [103] Einer der größten Vorteile des Scrum-Frameworks findet sich in der hohen Individualisierung der produktspezifischen Eigenschaften, was die Usability des Endprodukts auf die spezifischen Anforderungen der User garantiert und sich hierdurch positiv auf die wahrgenommene Produktqualität auswirkt. Bsp. hierzu sind der 5. Tab. zu entnehmen, welche die User Storys, die Story Points, sowie Prioritäten im Product-Backlog vereinbaren. Der 5. Tab. folgend, würde es sich anbieten, das Feedback des User 177 zeitnahe umzusetzen, da die Story-Points einen mäßigen Zeitaufwand, bei einer gleichzeitig hohen Priorität signalisieren. [104] Weiterhin wird die Markteinführungsdauer des entwickelten Produktes durch die schlanken Prozesse reduziert. Für unser Projekt bedeutet dies, dass sich die Developer auf das wesentliche konzentrieren können, was sich u. a. in dem geringen Administrations- und Dokumentationsaufwand widerspiegelt. [105] Zuletzt ist auf den Motivationsschub einzugehen, welcher durch die übersehbaren Sprints mit direkt messbaren Ergebnisse verbunden ist. Bspw. wird in der Sprint-Retrospektive konstruktiv auf die geleistete Arbeit eingegangen, wobei die Formulierung der Fragen einen generell positivistischen Charakter aufweisen und die Developer dazu ermuntern, ihr Vorgehen systematisch zu verbessern und das Projekt als Lernprozess zu erachten. [106]

4.2 Diskussionen zur Ableitung der bestehenden Nachteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes

In Relation zu den Nachteilen der Adaption des Scrum-Frameworks wird zumeist jener des fehlenden Gesamtüberblicks der Projektstrecke angeführt. Diese fehlende Plangenauigkeit wirkt sich für das KI-Projekt auf mehreren Dimensionen aus. So könnten potenzielle Investoren von Beginn an Zweifel an der Durchführbarkeit der eigenständigen Entwicklung einer KI, haben, da ihnen detaillierte Informationen zum Ablauf fehlen. Diese Unsicherheit wirkt sich im Weiteren auch auf die Planung des zeitlichen und monetären Aufwands des Endproduktes aus. Die Projektleitung könnte Probleme damit bekommen, die Kosten des Endproduktes zu rechtfertigen, da nicht jeder Schritt dokumentarisch erfasst wird. [107] Somit ist das oben unter Vorteile erfasste Kriterium des geringen Dokumentationsaufwands nicht nur ausschließlich positiv zu bewerten, weiterhin substituier sich ebendieser Vorteil dadurch, dass die zahlreichen Meetings und interne Abstimmungen, welche im Rahmen des Scrum-Frameworks in dieser Ausarbeitung als notwendig erläutert wurden, in einem hohen Kommunikationsaufwand resultieren, welcher nicht unmittelbar als wertschöpfende Tätigkeit im klassischen Sinne, wie dies bei der klassischen Produktionsarbeit der Fall ist, deklariert werden kann. [108] Weiterhin verfügen die einzelnen Sprints über das Potenzial dafür zu sorgen, dass das große Ganze aus den Augen verloren wird, da sich die Entwickler zu sehr auf einzelne Aufgaben konzentrieren. Selbstorganisation hört sich zwar gut an, diese Fähigkeit hat jedoch zuerst kultiviert zu werden. [109] Wenn es sich um ein neu zusammengestelltes Scrum-Team handelt, könnten für das KI-Projekt zu Beginn mehr Kosten anfallen, bis sich dieses den grundlegenden methodologischen Prinzipien angeeignet hat. [110] Gerade in hierarchisch geprägten top-down Organisationsformen erscheinen die unklaren Regelungen der Zuständigkeiten für linear denkendes Personal sehr fordern. Dies könnte mitunter eines der größten Probleme für das KI-Projekt darstellen, da die Änderung der Unternehmenskultur im Bereich Change-Management, als eine der herausforderndsten und langwierigsten Unterfangen gelten, bei denen große Veränderungen teils nur durch die Rekrutierung ausgewählter Generationen mit einem präferierten Gedankengut möglich erscheinen. Oder um es mit den Worten von Drucker zu beschreiben, „Kultur isst Strategie zum Frühstück“. [111] Dies schmälert die Vertretbarkeit des KI-Projektes enorm, solange nicht die unter 3.1 angeführten Voraussetzungen in organisationale Rahmenbedingungen geschaffen sind. [112]

5.1 Fazit

Wie herausgearbeitet, verfügen beide Vorgehensmodelle, welche im Rahmen dieser Ausarbeitung angeführt wurden, über spezifische Vorteile. Während das Wasserfallmodell eher als klassischer Ansatz zu verstehen ist und sich somit für hierarchisch organisierte Organisationen eignet, welche die Mühe und Aufwand betreiben ihre Projekte in einer holistischen Art zu erfassen, offeriert das Scrum-Framework eine agile Methodologie, welche sich gut in unser KI-Projekt implementieren lässt. Das Projekt profitiert wie bereits angeführt vor allem von der visionsgetriebenen Herangehensweise, welche es dem Scrum-Team ermöglicht, in den Sprint z. T. neue Praktiken zu adaptieren, um auch im späteren flexibel auf problematische Situationen reagieren zu können, indem es seine Arbeit systematisch reflektiert. Weiterhin überzeugt die hohe Nutzerzentriertheit, welche durch die Wahl des Scrum-Frameworks im Sinne der Verwendung von Story-Cards und deren Implementierung in den Backlog resultieren. Durch die Priorisierung der Aufgaben und deren Abbildung in der Timeline sehen nicht nur die Entwickler, sondern auch Projektleitung, was die Wünsche der Endbenutzer sind, und können schnell und flexibel Interventionen veranlassen, welche dem Team auf täglicher Basis, im Sinne des Daily-Scrum, oder anderen angeführten Meetings mitgeteilt wird. Bei der richtigen Anwendung des Scrum-Frameworks unter Berücksichtigung eines eingeübten und motivierten, resp. routinierten Scrum-Teams kann sich die Entwicklungsdauer des Frameworks deutlich von jener des Wasserfallmodells unterscheiden, was die Attraktivität für potenzielle Investoren erhöht.

5.2 Ausblick

Wie herausgearbeitet erweist sich das Scrum-Framework als verlässlich vor allem bei Softwareprojekte in Organisations- und Projektkulturen mit flacher Hierarchie unter Berücksichtigung der oben angeführten Voraussetzungen als State of the Art Framework. Dennoch geht es zu weit, das Scrum-Framework als Alleskönner zu bezeichnen, im Gegenteil. Gerade bei Investitions- und Organisationsprojekten mit fest determinierten Zielen, und zu Beginn festgelegten Rahmenbedingungen und unter der Beteiligung von Führungspersönlichkeiten im klassischen Sinne (Top-Down) Sinne und festen vertraglichen Verbindlichkeiten, scheint es weiterhin durchaus angebracht auf das Wasserfall-Vorgehensmodell zur Projektplanung zu setzen. Das Wasserfallmodell stellt also zumindest in der näheren Zukunft noch kein Auslaufmodell dar, sondern verfügt lediglich über andere Parameter, in welchem dieses optimal adaptiert werden kann. Für das angeführte KI-Modell eignet sich jedoch abschließend betrachtet das Scrum-Framework besser, da es sich eben um ein solches Softwareprojekt handelt, welches sich entlang des gesamten Prozesses kontinuierlich verändert. Diese Veränderungen sind hierbei nicht als Rückschritt zu erachten, wie diese im Falle des Wasserfallmodells zu konnotieren wären, sondern als ein Schritt in die Richtung der User-Freundlichkeit. Das Ziel besteht nicht darin, einen großen Vertrag an Land zu ziehen und diesen durch die vorab definierten Parameter, die sich zum Teil im Prozess verändern, so schnell wie möglich abzuliefern, sondern den Rezipienten, soweit dies möglich ist, mit in die Entwicklung einzubeziehen und dessen Wünsche so gut wie möglich zu erfüllen. Durch diesen Prozess wird dem Scrum-Team des KI-Projekts eine andere Art von Incentives ermöglicht. Ein Auftrag führt nicht selten zu einem Folgeauftrag. Scrum stellt somit auch eine andere Art der Kundeninteraktion dar. Wenn sich Kunden wahrgenommen und verstanden fühlen und darüber hinaus das Endprodukt den Definitionen of Done entspricht, gewinnt jeder.

Literaturverzeichnis

Agiles-Projektmanagement.org (2023), Scrum verstehen und erfolgreich anwenden. Verfügbar unter http://agiles-projektmanagement.org , abgerufen am 7.7.2023

Angermeier, G. (2019), Sprint (Scrum), Verfügbar unter https://www.projektmagazin.de/glossarterm/sprint-scrum , abgerufen am 7.7.2023

Beck, K. & Beedle, M. & Van Bennekum, A. & Cockburn, A. & Cunningham, W. & Fowler, M. & Grenning, J. & Highsmith, J. & Hunt, A. & Jeffries, R. & Kern, J. & Marick, B. & Martin, C. R. & Mellor, S. & Sutherland, J. & Thomas, D. (2001), verfügbar unter https://agilemanifesto.org , abgerufen am 6.7.2023

Broy, M. & Kuhrmann, M. (2021), Vorgehensmodelle in der Softwareentwicklung. Enthalten in Einführung in die Softwaretechnik. Berlin, Heidelberg: Springer Vieweg. ISBN 978-3-662-50262-4 https://doi.org/10.1007/978-3-662-50263-1_3

Bundesministerium des Innern und für Heimat [BMI]. (2023), Scrum. Verfügbar unter https://www.orghandbuch.de/OHB/DE/OrganisationshandbuchNEU/4_MethodenUndTechniken/Methoden_A_bis_Z/Scrum/Scrum_inhalt.html , abgerufen am 6.7.2023

Chaudhary, L. & Thakur, M. (2023), Scrum vs Waterfall. Verfügbar unter https://www.educba.com/scrum-vs-waterfall/ , abgerufen am 4.7.2023

Clevis Consult (2023), Scrum: Definition, Methode & Prozesse. Verfügbar unter https://www.clevis.de/ratgeber/scrum/ , abgerufen am 7.7.2023

Diehl, A. (2018), Scrum einführen- Wie du deine ersten Projekte mit Scrum umsetzt. Verfügbar unter https://digitaleneuordnung.de/blog/scrum-einfuehren/ , abgerufen am 8.7.2023

Drumond, C. (2023), Informationen zu Scrum und Tipps für den Einstieg. Ein Leitfaden zu Scrum: Was ist es, wie es funktioniert und die ersten Schritte. Verfügbar unter https://www.atlassian.com/de/agile/scrum , abgerufen am 6.7.2023

Eby, K. (2017), Worin liegt der Unterschied? Agile vs. Scrum vs. Waterfall vs. Kanban. Verfügbar unter https://de.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban , abgerufen am 4.7.2023

Fabris, V. (2021), Scrum Board: Überwachen Sie ihren Projektfortschritt. Verfügbar unter https://www.appvizer.de/magazin/organisation-planung/projektmanagement/scrum-board , abgerufen am 10.7.2023

Fandl, A. (2005), Einsatz von Vorgehendmodellen. Verfügbar unter https://www.infrasoft.at/images/downloads/Vorgehensmodelle_in_der_Softwareentwicklung.pdf , abgerufen am 5.7.2023

Faßrainer, S. (2016), Auswahl einer geeigneten Projektmethode. Verfügbar unter https://www.pst.ifi.lmu.de/Lehre/wise-15-16/jur-pm/fassrainer-ausarbeitung.pdf , abgerufen am 6.7.2023

Fähnrich, K. P. (2010), Vorlesung Softwaretechnik- Vorgehensmodelle, V-Modell XT. Verfügbar unter http://bis.informatik.uni-leipzig.de/de/Lehre/0910/WS/LV/SWT/files?get=2009w_swt_v_03.pdf , abgerufen am 6.7.2023

Fleig, J. (2023), So läuft ein Projekt mit Scrum ab. Verfügbar unter https://www.business-wissen.de/hb/scrum-projekt-der-ablauf-schritt-fuer-schritt-mit-beispielen/ , abgerufen am 8.7.2023

Fournier, A. (2020), Die Wirtschaftlichkeit Künstlicher Intelligenz- Wie Datenprojekte vom Kostenblock zum Umsatzgenerator werden. Verfügbar unter https://digitaleweltmagazin.de/fachbeitrag/die-wirtschaftlichkeit-kuenstlicher-intelligenz-wie-datenprojekte-vom-kostenblock-zum-umsatzgenerator-werden/ , abgerufen am 9.7.2023

Gaida, V. J. (2023), Wasserfallmodell- klassisches Projektmanagement. Verfügbar unter https://www.factro.de/blog/wasserfallmodell/ , abgerufen am 6.7.2023

Gloger, B. (2010), Scrum. Der Paradigmenwechsel im Projekt- und Produktmanagement- Eine Einführung. Verfügbar unter https://link.springer.com/article/10.1007/s00287-010-0426-6 , abgerufen am 7.7.2023

Gotscharek&Company Managing Success. Verfügbar unter https://www.gotscharek-company.com/blog-1/115-ki-kuenstliche-intelligenz-projekte-richtig-aufsetzen , abgerufen am 8.7.2023

Grande, M. (2014), 100 Minuten für Anforderungsmanagement. Kompaktes Wissen nicht nur für Projektleiter und Entwickler. Wiesbaden: Springer Vieweg. ISBN 978-3-658-06434-1 https://doi.org/10.1007/978-3-658-06435-8

Haslinger, D. (2023), Die Velocity ist eine der weitverbreitetsten Metriken der agilen Softwareentwicklung. Was ist eigentlich ihr Nutzen und wie berechnet man sie? Verfügbar unter https://www.objectbay.com/blog/agile-metriken-velocity , abgerufen am 11.7.2023

Haworth, S. (2023), Agile vs. Wasserfall. Was solltest du für dein Projekt verwenden. Verfügbar unter https://thedigitalprojectmanager.com/de/methoden-projektmanagement/agile-vs-wasserfall-was-solltest-du-fur-dein-projekt-verwenden/ , abgerufen am 8.7.2023

Höhn, R. & Höppner, S. (2008), Das V-Modell XT. Verfügbar unter https://bilder.buecher.de/zusatz/20/20754/20754505_lese_1.pdf , abgerufen am 5.7.2023

Hundermark, P. (2009), Scrum besser machen. Verfügbar unter https://www.agile42.com/wp-content/media/documents/ScrumBesserMachen-v2.1.1.pdf , abgerufen am 7.6.2023

International Association of Project Managers [iapm]. (2023), Scrum Vs. Wasserfall: Was ist das richtige für ihr Projekt. Verfügbar unter https://www.iapm.net/de/blog/scrum-vs-wasserfall/ , abgerufen am 7.7.2023

Lang, M. (a). (2023), Prioritätensetzung in Scrum-Projekten (Priorisierung des Backlogs), Verfügbar unter https://agilescrumgroup.de/prioritaetensetzung-scrum-agile-product-backlog/ , abgerufen am 9.7.2023

Lang, M. (b). (2023), Burndown Chart: Was ist das und was kann ich damit machen?. Verfügbar unter https://agilescrumgroup.de/burndown-chart/ , abgerufen am 10.7.2023

Lang, M. (c). (2023), Sprint Review: Wofür ist dieses Meeting gut? (inkl. Fallstricke) Verfügbar unter https://agilescrumgroup.de/sprint-review/#:~:text=Die%20Sprint%20Review%20ist%20ein,Feedback%20von%20den%20Stakeholdern%20einzuholen ., abgerufen am 10.7.2023

Leichsenring, H. J. (2022), Peter Drucker über Unternehmenskultur und Strategie. Verfügbar unter https://www.der-bank-blog.de/peter-drucker-ueber-unternehmenskultur-und-strategie/zitate/13830/ , abgerufen am 14.7.2023

LeSS (2023), Definition of Done. Verfügbar unter https://less.works/less/framework/definition-of-done#:~:text=The%20Definition%20of%20Done%20is,completed%2C%20the%20item%20is%20done ., abgerufen am 8.7.2023

Lucid Content Team (2023), Agile vs. Waterfall vs. Kanban vs. Scrum: What´s the Difference? Verfügbar unter https://www.lucidchart.com/blog/agile-vs-waterfall-vs-kanban-vs-scrum , abgerufen am 4.7.2023

MacNeil, C. (2022), so führen Sie eine effektive Sprint-Retrospektive durch. Verfügbar unter https://asana.com/de/resources/sprint-retrospective , abgerufen am 11.7.2023

Mast, S. (2015), Das Vorgehensmodell als Erfolgsfaktor für ein IT-Projekt. Verfügbar unter https://opus.ostfalia.de/frontdoor/deliver/index/docId/548/file/Mast_2015_Vorgehensmodell_Erfolgsfaktor_IT_App.pdf , abgerufen am 5.7.2023

Maynard, C. (2023), Scrum-Projekt in Jira Software. Detaillierte Anleitung zur Umsetzung eines Scrum-Projekts. Verfügbar unter https://www.atlassian.com/de/agile/tutorials/how-to-do-scrum-with-jira-software , abgerufen am 8.7.2023

Paul, J. Hybrides Projektmanagement in Abgrenzung zum klassischen und agilen Projektmanagement. Verfügbar unter https://core.ac.uk/download/pdf/196251054.pdf , abgerufen am 8.7.2023

Pilorget, L. & Schell, T. (2022), IT-Management. Die Kunst des IT-Managements auf der Grundlage eines soliden Rahmens, der das politische Ökosystem des Unternehmens wirksam unterstützt. Wiesbaden: Springer Fachmedien. ISBN 978-3-658-39714-2 https://doi.org/10.1007/978-3-658-39715-9

Radon, B. (2015), Projekt erfolgreich umsetzen. Projekt-Entwicklung mit Scrum. Verfügbar unter https://www.computerwoche.de/a/projekt-entwicklung-mit-scrum,3070730,2 , abgerufen am 8.7.2023

Salimi, S. (2023), Was bedeutet Velocity für dein Team?- Definition und wie du sie berechnen kannst!

Sarre, F. (2016), Vorgehensmodelle. Verfügbar unter https://www.pst.ifi.lmu.de/Lehre/wise-15-16/jur-pm/vorgehensmodelle-1.pdf , abgerufen am 5.7.2023

Scharch, M. (2016), Vorgehensmodelle in der Software-Entwicklung. Verfügbar unter https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwi3_rKLlPb_AhVwcvEDHQ_WBbwQFnoECAcQAQ&url=https%3A%2F%2Filias.uni-giessen.de%2Filias%2Fgoto.php%3Ftarget%3Dfile_183936_download%26client_id%3DJLUG&usg=AOvVaw2GiEoCPK-VSlJeBTH6C8e9&opi=89978449 , abgerufen am 5.7.2023

Schenner, M. (2023), KI-basierte Cyberangriffe häufen sich. Verfügbar unter https://www.swisscybersecurity.net/cybersecurity/2023-05-16/ki-basierte-cyberangriffe-haeufen-sich , abgerufen am 8.7.2023

Schütte, R. & Seufert, S. & Wulfert, T. (2022), IT-Systeme wirtschaftlich verstehen und gestalten. Methoden-Paradoxien-Grundsätze. Wiesbaden: Springer Fachmedien. ISBN 978-3-658-34615-7 https://doi.org/10.1007/978-3-658-34616-4

Schwaber, K. & Sutherland, J. (2020), Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf , abgerufen am 6.7.2023

The Mentor (1986), Hacker’s Manifesto. Verfügbar unter http://phrack.org/issues/7/3.html , abgerufen am 6.7.2023

T2informatik (2023), Scrum Retrospektive. Verfügbar unter https://t2informatik.de/wissen-kompakt/scrum-retrospektive/ , abgerufen am 11.7.2023

Van der Wardt, R. (2023), Sprint Retrospektive. Verfügbar unter https://scrumguide.de/sprint-retrospective/ , abgerufen am 11.7.2023

Vige, W. (2023), Story Points: Der 6 Schritte-Leitfaden im Überblick!. Verfügbar unter https://asana.com/de/resources/story-points , abgerufen am 9.7.2023

Wergen, S. (2023), Story Points: So funktioniert die Aufwandsschätzung in Agile. Verfügbar unter https://blog.hubspot.de/marketing/story-points , abgerufen am 7.8.2023

Windpohl, A. (2021), Das Wasserfallmodell. Definition, Aufbau, Vor- und Nachteile. Verfügbar unter https://projekte-leicht-gemacht.de/blog/projektmanagement/klassisch/wasserfallmodell/ , abgerufen am 6.7.2023

[1] Vgl. Höhn, R. Höppner, S. (2007), S. 36

[2] Vgl. Eby, K. (2017), 1. Kap. 1. Abs. ; Broy, M. Kuhrmann, M. (2021), S. 83

[3] Vgl. Mast, S. (2015), S. 6

[4] Vgl. Broy, M. Kuhrmann, M. (2021), S. 84

[5] Vgl. Chaudhary, L. Thakur, M. (2023), 1. Kap. 1. Abs.

[6] Vgl. Lucis Content Team (2023), 1. Kap. 1. Abs. bis 1. Kap. 2. Abs.

[7] Fähnrich, K. P. (2010), S. 3

[8] Broy, M. Kuhrmann, M. (2021), S. 84

[9] Vgl. Ebd. (2021), S. 84

[10] Vgl. Sarre, F. (2016), S. 83-84; Broy, M. Kuhrmann, M. (2021), S. 86-89; Fähnrich, K. P. (2022), S. 3

[11] Vgl. Scharch, M. (2016), S. 14

[12] Vgl. Broy, M. Kuhrmann, M. (2021), S. 85

[13] Vgl. Sarre, F. (2016), S. 81; Fähnrich, K. P. (2010), S. 4

[14] Vgl. Scharch, M. (2016), S. 13

[15] Vgl. Faßrainer, S. (2016), S. 3

[16] Vgl. Broy, M. Kuhrmann, M. (2021), S. 86; Pilorget, L. Schell, T. (2022), 5. Kap. 3.3.1. Abs.

[17] Vgl. Grande, M. (2014), S. 114

[18] Vgl. Faßrainer, S. (2016), S. 3

[19] Vgl. Fandl. A (2005), S. 3; Schütte, R. et al. (2022), 6. Kap. 2. Abs.

[20] Vgl. Mast, S. (2015), S. 8

[21] Fandl. A (2005), S. 4

[22] Vgl. Mast, S. (2015), S. 8; Pilorget, L. Schell, T. (2022), 5. Kap. 3.3.1. Abs.; Schütte, R. et al. (2022), 6. Kap. 2. Abs.; Windpohl, A. (2021), 5. Kap. 1. Abs. bis 2. Abs.

[23] Vgl. Faßrainer, S. (2016), S. 3

[24] Vgl. Gloger, B. (2010), S. 195

[25] Vgl. Drumond, C. (2023), 1. Kap. 1. Abs.

[26] Vgl. Schwaber, K. Sutherland, J. (2020), S. 5

[27] Vgl. Gloger, B. (2010), S. 196

[28] Vgl. Schwaber, K. Sutherland, J. (2020), S. 3;

[29] Vgl. Faßrainer, S. (2016), S. 3

[30] Vgl. Grande, M. (2014), S. 113; Schwaber, K. Sutherland, J. (2020), S. 3

[31] Vgl. Drumond, C. (2023), 2. Kap. 1. Abs.; The Mentor (1986) S. 1

[32] Vgl. Beck, K. (2001), 1. Kap. 2. Abs.

[33] Vgl. Schütte, R. et al. (2022), 6. Kap. 2. Abs.

[34] Vgl. Bundesministerium des Innern und für Heimat [BMI]. (2023), 4. Kap. 14.3. Abs.; Hundermark, P. (2009), S. 12, Angermeier, G. (2019), 5. Kap. 1. Abs.

[35] Vgl. Hundermark, P. (2009), S. 12

[36] Vgl. Agiles-Projektmanagement.org (2023), 8. Kap. 1. Abs. bis 2. Abs.

[37] Vgl. Hundermark, P. (2009), S. 13

[38] Vgl. Ebd. (2009), S. 14

[39] Vgl. Hundermark, P. (2009), S. 15

[40] Agiles-Projektmanagement.org (2023), 9. Kap. 2. Abs.

[41] Vgl. Hundermark, P. (2009), S. 15; Gloger, B. (2010), S. 197

[42] Vgl. Agiles-Projektmanagement.org (2023), 9. Kap. 2. Abs.

[43] Vgl. Agiles-Projektmanagement.org (2023), 6. Kap. 1. Abs.

[44] Vgl. Angermeier, G. (2019), 2. Kap. 1. Abs.

[45] Vgl. Faßrainer, S. (2016), S. 7

[46] Vgl. Agiles-Projektmanagement.org (2023), 14. Kap. 1. Abs. und 10. Kap. 1. Abs.

[47] Vgl. International Association of Project Managers [iapm]. (2023), 1. Kap. 1. Abs.

[48] Vgl. Haworth, S. (2023), 2. Kap. 2. Abs. bis 3. Abs.

[49] Vgl. Radon, B. (2015), S. 2

[50] Vgl. Fleig, J. (2023), 1. Kap. 1. Abs.

[51] Vgl. Gotscharek&Company Managing Success (2023), 3. Kap. 5. Abs.

[52] Vgl. Schenner, M. (2023), 1. Kap. 1. Abs.

[53] Vgl. Diehl, A. (2018), 2. Kap. 2. Abs.

[54] Vgl. Fleig, J. (2023), 2. Kap. 1. Abs. bis 3. Abs.; Maynard, C. (2023), 3. Kap. 1. Abs.

[55] Vgl. Maynard, C. (2023), 3. Kap. 2. Abs. bis 4. Abs.

[56] Vgl. Fleig, J. (2023), 3. Kap. 1. Abs. bis 4. Abs.

[57] Vgl. Less (2023), 1. Kap. 1. Abs. bis 3. Abs.

[58] Vgl. Fleig, J. (2023), 5. Kap. 1. Abs.

[59] Vgl. Wergen, S. (2023), 1. Kap. 1. Abs.

[60] Vgl. Fleig, J. (2023), 5. Kap. 1. Abs. bis 2. Abs.

[61] Vgl. Wergen, S. (2023), 3. Kap. 1. Abs.; Vige, W. (2023), 1. Kap. 1. Abs.

[62] Vgl. Vige, W. (2023), 2. Kap. 1. Abs.

[63] Vgl. Fournier, A. (2020), 3. Kap. 1. Abs.

[64] Vgl. Lang, M. (a). (2023), 2. Kap. 2. Abs.; Gotscharek&Company Managing Success (2023), 6. Kap. 2. Abs.

[65] Vgl. Fleig, J. (2023), 6. Kap. 1. Abs. bis 3. Abs.

[66] Vgl. Lang, M. (a). (2023), 2. Kap. 2. Abs.

[67] Vgl. Fleig, J. (2023), 7. Kap. 1. Abs. bis 2. Abs.

[68] Ebd. (2023), 7. Kap. 1. Abs.

[69] Vgl. Adam, J. Böllhoff, P. (2022), 6. Kap. 1. Abs.

[70] Vgl. Fleig, J. (2023), 8. Kap. 2. Abs.

[71] Adam, J. Böllhoff, P. (2022), 6. Kap. 1. Abs.

[72] Vgl. Fleig, J. (2023), 8. Kap. 3. Abs.

[73] Vgl. Fabris, V. (2021), 3. Kap. 1. Abs. bis 2. Abs.

[74] Vgl. Fleig, J. (2023), 9. Kap. 1. Abs. bis 2. Abs.

[75] Vgl. Fabris, V. (2021), 5. Kap. 1. Abs. bis 3. Abs.

[76] Vgl. Fleig, J. (2023), 10. Kap. 1. Abs. bis 2. Abs.

[77] Vgl. Fabris, V. (2021), 7. Kap. 1. Abs. bis 5. Abs

[78] Fleig, J. (2023), 11. Kap. 1. Abs.

[79] Vgl. Ebd. (2023), 11. Kap. 2. Abs.

[80] Vgl. Lang, M. (b). (2023), 1. Kap. 1. Abs.

[81] Vgl. Fleig, J. (2023), 12. Kap. 1. Abs. bis 2. Abs.

[82] Vgl. Lang, M. (c). (2023), 2. Kap. 1. Abs. bis 3. Abs.

[83] Vgl. Fleig, J. (2023), 13. Kap. 1. Abs. bis 3. Abs.

[84] Vgl. Salimi, S. (2023), 1. Kap. 1. Abs. bis 1. Kap. 2. Abs.

[85] Vgl. Haslinger, D. (2023), 2. Kap. 1. Abs. bis 3. Kap. 2. Abs.

[86] Vgl. Fleig, J. (2023), 14. Kap. 1. Abs. bis 2. Abs.

[87] Vgl. Salimi, S. (2023), 5. Kap. 1. Abs.

[88] Vgl. 4. Kap. 1. Abs. bis 7. Abs.

[89] Vgl. Fleig, J. (2023), 14. Kap. 3. Abs.

[90] Vgl. MacNeil, C. (2022), 1. Kap. 1. Abs.

[91] t2informatik (2023), 1. Kap. 1. Abs.

[92] Vgl. Van der Wardt, R. (2023), 1. Kap. 2. Abs.

[93] Vgl. Fleig, J. (2023), 15. Kap. 3. Abs.

[94] Vgl. MacNeil, C. (2022), 7. Kap. 2. Abs. bis 5. Abs.

[95] Vgl. Van der Wardt, R. (2023), 3. Kap. 1. Abs.

[96] Vgl. t2informatik (2023), 6. Kap. 1. Abs.

[97] Vgl. MacNeil, C. (2022), 8. Kap. 1. Abs. bis 2. Abs.

[98] Vgl. Fleig, J. (2023), 16. Kap. 1. Abs. bis 4. Abs.

[99] Vgl. Clevis Consult (2023), 3. Kap. 1. Abs.

[100] Vgl. Agiles-Projektmanagement.org (2023), 15. Kap. 2. Abs.

[101] Vgl. iapm (2023), 4. Kap. 2. Abs.

[102] Vgl. Clevis Consult (2023), 3. Kap. 1. Abs.

[103] Vgl. Agiles-Projektmanagement.org (2023), 15. Kap. 2. Abs.

[104] Vgl. Clevis Consult (2023), 3. Kap. 1. Abs.

[105] Vgl. Agiles-Projektmanagement.org (2023), 15. Kap. 2. Abs.

[106] Vgl. Clevis Consult (2023), 3. Kap. 1. Abs.

[107] Vgl. iapm (2023), 4. Kap. 4. Abs.

[108] Vgl. Agiles-Projektmanagement.org (2023), 15. Kap. 3. Abs.

[109] Vgl. iapm (2023), 4. Kap. 4. Abs.

[110] Vgl. Clevis Consult (2023), 9. Kap. 1. Abs.

[111] Vgl. Leichsenring, H. J. (2022), 4. Kap. 1. Abs.

[112] Vgl. Agiles-Projektmanagement.org (2023), 15. Kap. 3. Abs.

Final del extracto de 46 páginas - subir

Detalles

Título: Agiles Projektmanagement im Kontext Künstlicher Intelligenz
Subtítulo: Anwendung des Scrum-Frameworks zur effizienten Steuerung von IT-Projekten
Universidad: SRH - Mobile University
Calificación: 1,3
Autor: Eloy Veit (Autor)
Año de publicación: 2023
Páginas: 46
No. de catálogo: V1464400
ISBN (PDF): 9783389012352
ISBN (Libro): 9783389012369
Idioma: Alemán
Etiqueta: IT-Management Wasserfallmodell Agile Methoden Scrum

Citar trabajo: Eloy Veit (Autor), 2023, Agiles Projektmanagement im Kontext Künstlicher Intelligenz, Múnich, GRIN Verlag, https://www.grin.com/document/1464400

Agiles Projektmanagement im Kontext Künstlicher Intelligenz

Anwendung des Scrum-Frameworks zur effizienten Steuerung von IT-Projekten

Extracto

1.1 Problemstellung

1.2 Zielsetzung

1.3 Art des Vorgehens

2.1 Grundlagen der IT-Management-Steuerung durch Vorgehensmodelle

2.2 Phasen orientiertes Wasserfallmodell

2.3 Agiles Vorgehensmodell Scrum

2.4 Zusammenfassung der wesentlichen Unterschiede des Wasserfallmodells und der agilen Scrum-Methode

3.1 Voraussetzungen zur Adaption des Scrum Frameworks und Entwicklung einer Produktvision für das KI-Projekt

3.2 Ableitung der Produktvision und Präzisierung mittels Story-Cards

3.3 Effiziente Priorisierung und Ableitung der Story-Cards in den Backlog-Prozess

3.4 Praktisches Beispiel des Product-Backlog des KI-Modells und Erarbeitung der Meilensteine

3.5 Sprint-Planning und transparente Aufgabenverteilung im agilen Scrum-Prozess

3.6 Bessere Visualisierung der Sprints durch die Adaption eines Sprint-Boards und Kanban

3.7 Daily-Scrum als Hilfsmittel zur Fokussierung des Fortschrittes in Richtung des Sprint-Ziels

3.8 Burndown-Chart als Hilfsmittel zur holistischen Abbildung des Projektfortschrittes

3.9 Feedback, Abnahme und Neuplanung im agilen Scrum-Prozess durch das Sprint-Review-Meeting

3.10 Kalkulation der Velocity zur Bestimmung der durchschnittlichen Arbeitsleistung des Scrum-Teams

3.11 Sprint-Retrospektive zur kontinuierlichen Verbesserung und Lösungsfindung im agilen Scrum-Team

4.1 Diskussionen zur Ableitung der bestehenden Vorteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes

4.2 Diskussionen zur Ableitung der bestehenden Nachteile des Scrum-Frameworks im Rahmen des angeführten KI-Projektes

5.1 Fazit

5.2 Ausblick

Literaturverzeichnis

Detalles