Vorlesung 9: Agile Entwicklung WS 2024/25 PDF

BSc. WIN / MSc. DLM Management von IT-Projekten Vorlesung 9: Agile Entwicklung WS 2024/25 Prof. Dr. Michael Fellmann Professur für Wirtschaftsi...

BSc. WIN / MSc. DLM Management von IT-Projekten Vorlesung 9: Agile Entwicklung WS 2024/25 Prof. Dr. Michael Fellmann Professur für Wirtschaftsinformatik, insbes. Betriebliche Informationssysteme WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik  IT-Management: Themen WS 24/25 ITM PM Information als Ressource Organisation Organisation Führungsaufgaben Strategische, taktische, operative Ebene Vorgehensmodelle Qualitätsmanagement Termin- und Ressourcenplanung Risikomanagement Datenschutz vs. Datensicherheit Projektcontrolling Informationslogistik Qualitätsmanagement IT Sourcing Risikomanagement IT Portfoliomanagement Teambuilding Best Practises Agile Entwicklung WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 2 Fragen der letzten Vorlesung Welche Schritte umfasst grundsätzlich das Projektcontrolling? Was wird im Rahmen des Projektcontrollings überwacht? Welche Analysemethoden gibt es für das Projektcontrolling? Was ist der Grundgedanke beim Prozessorientierten Qualitätsmanagement? Welche Reifestufen für Prozesse werden grundsätzlich unterschieden? Wozu dienen diese Reifestufen? WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 3 Fragen der heutigen Vorlesung Welche Vorteile verspricht man sich von agilen Softwareentwicklungsmethoden? Was für Prinzipien stehen hinter der agilen Softwareentwicklung? Was sind typische Methoden der agilen Softwareentwicklung? Welche Grenzen/Nachteile gibt es bei der agilen Softwareentwicklung? Wie werden bei Scrum die klassischen Aufgaben des Projektmanagements umgesetzt? WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 4  Einleitung Agile Softwareentwicklung: Schnelle und flexible Entwicklung von Software (im Gegensatz zum klassischen Wasserfallmodell) Prinzipien: Wiederverwendung: Vorhandenen Programmcode mehrfach verwenden KISS-Prinzip (Keep it simple and smart) Kundennah (in enger Zusammenarbeit mit den Auftraggebern) Agile Methoden Gemeinsamer Code-Besitz (Collective Code Ownership) Extreme Programming (XP) Programmierpraxis auf Basis Agiler Techniken Scrum: Methode für die Entwicklung von Softwareprojekten auf Basis Agiler Techniken Beschreibt den Prozess der Identifikation und Beschreibung von zu erledigenden Aufgaben, Priorisierung der Aufgaben zusammen mit dem Auftraggeber und Implementierung mit iterativen Verfahren WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 5 Warum scheitern Projekte? How/Ergebnisse_Erfolg_und_Scheitern-Studie_2008.pdf http://www.gpm-ipma.de/fileadmin/user_upload/Know- 2008, n=79 WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 6 Warum scheitern Projekte? ipma.de/know_how/studienergebnisse/anforderungsanalyseanforderungsmanagement_in_ komplexen_projekten.html http://www.gpm- 2012, n=74 (Schwerpunkt Logistik) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 7  nach schneller Entwicklungsprozess Forderung nach mehr Dynamik Brooks (1975): “Grow, not build, Software” Marissa Mayer (2010): The Internet will fundamentally change the way software is developed, and in many ways, it already has. Release cycles have accelerated, and new features are being developed all the time, which is a very different case than with shrink-wrapped software. When we look at our best products, including Youtube […] they are on weekly - if not daily - release cycles. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 8 Das agile Manifest Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge Funktionierende Software statt umfassender Dokumentation Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen http://agilemanifesto.org/iso/de/principles.html Auf Veränderungen reagieren, anstatt einem Plan zu folgen WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 9 Das agile Manifest Prinzipien hinter dem Agilen Manifest Wir folgen diesen Prinzipien: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. akzeptieren Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder http://agilemanifesto.org/iso/de/principles.html Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 10 Das agile Manifest Prinzipien hinter dem Agilen Manifest (Teil 2) Wir folgen diesen Prinzipien: die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Kontinuierliche Reflexion des Teams, um die Effektivität zu steigern. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 11 Motivation für agile Softwareentwicklung Änderungskosten im Änderungskosten in der klassischen Wasserfallmodell agilen Softwareentwicklung WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 12 Agile Vorgehensmodelle Ursprünglich auch leichtgewichtig genannt Projekt in sehr enger und direkter Zusammenarbeit mit dem Auftraggeber durchgeführt (anstelle der festen Abfolge »Spezifikation, Konstruktion und Umsetzung«) Enge Zusammenarbeit mit dem Auftraggeber Der Kunde bekommt, was er braucht, nicht was er spezifiziert hat. Die Spezifikation erfolgt sukzessive während der Umsetzung wichtiger Vorteil bei Projekten: Mit unklaren Anforderungen zum Projektstart oder starken Veränderung durch externe Einflüsse Abbau bürokratischer Strukturen weniger Dokumente Wenig explizite Regeln Entwicklungsprozess dadurch flexibler und schlanker Fokus liegt auf den zu erreichenden Zielen liegen Regeln entstehen erst durch die Teamarbeit der Entwicklergruppe (dadurch nur tatsächlich nötige und ergebnisförderliche Regeln) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 13  http://www.gpm-ipma.de/fileadmin/user_upload/Know-How/studien/Studie_Agiles-PM_web.pdf Verbreitung von Methoden der agilen Softwareentwicklung Studie des BPM- Labor der HS Koblenz in Kooper- ation mit der Deutschen Gesell- schaft für Projekt- management e. V. 2015, n > 600 WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 14  Wie strikt wird Agilität angewendet? Die meisten Anwender betreiben Agilität nicht in Reinform Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 15  Welche Themen werden agil bearbeitet? Softwareentwicklung ist führend Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 16  Erfolg agiler Methoden (vereinfacht) Frage: „Sind Verbesserungen bei Ergebnis und Effizienz erreicht worden?“ Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 17  Wie hoch ist die Erfolgsquote agiler Methoden? Einschätzung der Erfolgsquote agil durchgeführter Projekte/Prozesse Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 18  … und zum Vergleich: Mit klassischen Methoden? Einschätzung der Erfolgsquote „klassisch“ durchgeführter Projekte/Prozesse Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 19  Ein weiterer Vergleich Chaos-Report der Standish Group von 2011 Quelle: http://random-signals.de/?s=studie 20 Ausweitung: Agile Methoden im Projektmanagement? Frage: „Gibt es Überlegungen hierzu?“ Quelle: Studie „Status Quo Agile (2016/2017)“ der HS Koblenz. 21 Extreme Programming /1 MEthode Werte von XP Einfachheit (Simplicity): – Einfache Lösungen sind kostengünstiger und schneller zu realisieren als komplexe Lösungen – Deshalb immer der Versuch, die einfacheren Lösungen zu finden Kommunikation (Communication): – Alle Projektmitglieder sollen intensiv miteinander kommunizieren – Durch persönliche Gespräche lassen sich Missverständnisse sehr schnell ausräumen; – Fragen können ebenso schnell geklärt werden. – Dadurch kann auf Dokumentation an einigen Stellen verzichtet werden WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 22 Extreme Programming /2 Werte von XP Feedback: – Um eine hohe Qualität zu erzielen, nämlich das zu erreichen, was der Kunde benötigt, werden sehr kurze Feedback-Schleifen verwendet, um dem Kunden kontinuierlich die Entwicklung zu zeigen – Hierdurch werden durch den Kunden Fehlentwicklungen sehr schnell gestoppt – Feedback wird erreicht: durch den Kunden durch Tests der erstellten Software Mut (Courage): – Diese Werte einzusetzen und dabei offen zu kommunizieren erfordert sehr viel Mut, besonders für die Projektmitglieder, die das Handeln nach diesen Werten nicht gewohnt sind – Anforderungen des Kunden auf das Wichtigste zu reduzieren, kontinuierliches Feedback und Offenheit, sowie direkte Kommunikation mit dem Kunden und anderen Projektmitgliedern erfordert Mut WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 23 Iterative Entwicklung aus: Head First: Software Development WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 24 Programmier-Techniken Testen (Testing): – Alle Entwicklungen müssen getestet werden. – Vor der Entwicklung werden die Testfälle beschrieben Einfaches Design (Simple Design): Das System sollte möglichst einfach gestaltet sein – (keep it simple..) – einfacher zu verstehen, zu ändern und zu testen Inkrementelle Veränderung (Incremental Change): – Kontinuierlich kleine Veränderungen vorantreiben (nicht anstauen)– – große Änderungen haben meist viele Abhängigkeiten Refactoring (Refactoring): – Sobald erforderlich wird, die Struktur des Systems zu verändern, soll dies durchgeführt werden Programmieren in Paaren (Pair Programming): – immer zwei Entwickler sitzen vor einem Computer, um die Qualität der Software zu erhöhen – Rollenteilung meist: einer programmiert, einer kommentiert (abwechselnd) WS 24/25 2016 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 25 Fehler vermeiden: Pair Programming Beliebt im akademischen Umfeld, aber nicht nur: Extreme Programming in Startups Hackathon Umgebungen WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 26 Anforderungen in XP werden in Form von User Storys auf Story Cards festgehalten Der Kunde formuliert seine Anforderung auf einer Karteikarte in Form einer Story  Story wird vom Team grob geschätzt  vom Kunden mit Akzeptanzkriterien versehen  Reihenfolge der Umsetzung wird in Planning Meetings (Planungstreffen) festgelegt  Story beschreibt keine Technik, muss aber so vollständig sein, dass Risiken analysiert und grobe Aufwände dazu geschätzt werden können  Details zu diesen User Storys werden während des Projektes vom Entwickler mit dem Kunden besprochen  Ist die Story realisiert, wird die Karte entfernt.  Dokumentation von Anforderungen sind dann die geschriebenen Tests des Projektteams WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 27 Abschätzungen sollen unabhängig voneinander geschiehen werden und dann miteinander verglichen werden WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 28 Planning Poker WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 29 Fazit zum Einsatz von XP Vorteile: wenn Anforderungen zu Beginn eines Projektes nicht vollständig vorliegen – was sehr häufig der Fall ist. Anforderungen können sich bei XP während des Projektes verändern und auch konkretisiert werden. Ebenfalls können durch falsch verstandene Anforderungen Fehler des Entwicklungsteams auf einfachem Weg behoben werden. Es wird bei XP darauf geachtet, dass die Teile eines Projektes zuerst realisiert werden, die den größten Nutzen versprechen. Somit erhalten die Auftraggeber sehr schnell die wichtigsten Funktionen (positive Ergebnisse im Programm von Anfang an) Grenzen/Nachteile: XP hat einen hohen Anteil an Selbstorganisation Dies setzt gewisse Mindesterfahrungen der Teammitglieder voraus. Ebenfalls setzt XP bei den Teammitgliedern auf Mut, speziell im Bereich Kommunikation Ist dies mit den Teammitgliedern nicht möglich, ist der Einsatz von XP nicht unbedingt vorteilhaft. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 30 Darauf basierendes Projektentwicklungsverfahren: Scrum Foto ist aus dem Wiki von: Scrum bei T-Online International (TOI) (Christian Mann)  Agile Softwareentwicklungsmethode  „mehr Dynamik“ im Softwareentwickungsprozess WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 31 Der Scrum-Prozess Adaption gemäß Agile Software Development with Scrum von Ken Schwaber & Mike Beedle WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 32 Scrum-Prozess Vorplanung 1. Projektplanung und 2. Design der Grobarchitektur Dabei werden die Vorgaben für das Projekt definiert Auswahl der Mitarbeiter Festlegung der Entwicklungswerkzeuge Weitere Konventionen festlegen 3. Erste Version des Product Backlogs (Sammlung der Anforderungen) vom Scrum Team im Rahmen eines ersten Sprints gemeinsam erarbeitet WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 33 Rollen Direkt am Projekt beteiligte Personen, die auch eine Last bzw. ein Risiko im Projekt tragen: Product Owner ScrumMaster Team sonstige Stakeholder Arbeiten in durch die Scrum-Regeln definierter Weise zusammen Treffen sich regelmäßig zu kurzen, effizienten Meetings Halten ihre jeweiligen Scrum-Artefakte auf dem neuesten Stand, damit alle - auch die Chickens - sich selbständig über den Fortschritt informieren können. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 34 Rollen in Scrum Product Owner verwaltet die Anforderungen an die Entwicklung - Repräsentant des Kunden Entscheidet letztendlich, welche Funktionalitäten entwickelt werden sollte während der gesamten Entwicklung verfügbar sein Entwicklungsteam besteht im Idealfall aus sechs plus oder minus drei Personen organisiert sich selbst und entwickelt eigenverantwortlich die Software in sogenannten Sprints – der Begriff für Iterationen in Scrum Bei mehr als neun Personen sieht Scrum keine Vergrößerung des Teams vor, (Kommunikationsfähigkeit gefährdet) Stattdessen »Scrum of Scrums«, mehrere Scrum-Teams bilden 1-2 Personen aus jedem Teams bilden ein hierarchisch höher angesiedeltes Team, das ebenso den Scrum-Prozess durchläuft Also: Baumstruktur von Teams Scrum Master Werte und Regeln während des Projektes zu wahren und Hindernisse zu beseitigen ist auch die Schnittstelle des Teams zur Außenwelt zuständig für die Kommunikation mit Nichtteammitgliedern, (zentrale Anlaufstelle) Der Scrum Master ist prinzipiell nicht höher gestellt als das Team WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 35 Bedeutung des Teams Entwicklung steht und fällt mit dem Team Gegen das Team lässt sich keine Zeitplanung durchführen nicht motiviertes oder nicht fähiges Team kann auch durch einwandfreies Projektmanagement keine Höchstleistungen erzielen Daher: agiler Ansatz: Gewährt dem Entwicklungsteam viele Freiheiten Kaum äußere Regeln Setzt auf Offenheit und das Selbstmanagement des Teams Sicherstellung der langfristigen Motivation des Teams (nicht nur äußere Umstände können zum das Entstehen von »Blockern« führen, auch die Projektarbeit selbst, kann das Team ändern) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 36 „Dokumente“ in Scrum Halten ihre jeweiligen Scrum-Artefakte auf dem neuesten Stand, damit alle - auch die Chickens (Einsteiger) - sich selbständig über den Fortschritt informieren können: Product Backlog was solte implementiert werden enthält teile die im sprint entwickelt werden Sprint Backlog Burndown Chart Wie weit man schon im Sprint gekommen ist Impediment/Blocks List Hindernisse Liste, mehr auf seite 45 WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 37 User Stories und Iterationen WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 37 User Stories und Tasks  Tasks (Aufgaben aus den User Stories ableiten) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 39 Product Backlog Priorisierte Liste mit den umzusetzenden Aufgaben , die werden Beschrieben über User Stories Nie vollständig, kann vom Product Owner ergänzt werden Sprint Planning Meeting Teil 1: mit dem Product Owner – Aus den User Stories (auf Karteikarten) und – Erklärungen zu den User Stories (vom Product Owner) Der Product Owner erläutert die am höchsten priorisierten Einträge (»Items«) des Product Backlogs und erklärt deren fachlichen Nutzen. Das Team schätzt den Aufwand der »Items« ab. Teil 2: Team – Genauere Planung, wie die Umsetzung erfolgen soll Weitere Festlegung zu der zu entwickelnden Software Festlegung, welche User Stories im nächsten Sprint umgesetzt werden sollen Erstellen des Product Backlogs Dauer 1 Stunde pro 1 Woche Entwicklungszeit jeweils für Teil 1+2 WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 40 Sprint Backlog Übersicht über die Aufgaben, die im Sprint umzusetzen sind Oft werden folgende Spalten verwendet: 1. User Stories, priorisiert spalte 2. Aufgaben zu den User Stories 3. Bearbeitungsstand: „Tasks to Do“, „Work in Progress“, „Done“ Im Daily Scrum werden die sich ergebenden Änderungen besprochen, nicht erledigte Tasks mit einem roten Punkt markiert WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 41 Zu pflegende „Dokumente“ Foto aus dem Wiki von: Scrum bei T-Online International (TOI) (Christian Mann) User Stories, Zu erledigende Aufgaben, Aufwände WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 42 Scrum-Meeting Täglich Foto aus dem Wiki von: Scrum bei T-Online International (TOI) (Christian Mann) Festgelegte Zeit Kurz (10-15 Minuten) Kurze Vorstellung, wer macht welche Aufgaben (an diesem Tag, was war Besonderes, welche Änderungen traten auf WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 43 Regeln gibt es doch ☺ Foto aus dem Wiki von: Scrum bei T-Online International (TOI) (Christian Mann) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 44 Hindernisse festhalten Im Sprint können sich Hindernisse zeigen Nicht realisierte Tasks Rahmenbedingungen Können von jedem Teammitglied identifiziert und angegeben werden Festhalten in einer Liste (Impediment List) wird im Daily Scrum Meeting an die anderen Team Mitglieder kommuniziert und in der Impediment List festgehalten Muss vom Scrum-Master gelöst werden WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 45 Regeln zum Daily Scrum Täglich Max. 15 Minuten oft im Stehen abgehalten Jedes Teammitglied beantwortet folgende Fragen: Was habe ich seit dem letzten Daily Scrum Meeting erreicht? Was werde ich bis zum nächsten Daily Scrum Meeting erreichen? Was hindert mich an meiner Arbeit (Blocker/Hindernisse)? keine Diskussion, sondern eine rein mündliche Informationsverteilung an das Team Hauptaufgabe des ScrumMasters: auftretende Blocker zu beseitigen (nicht die Steuerung des Teams, dieses organisiert sich selbst) Richtlinien für das »Daily Scrum«: Das Treffen startet immer pünktlich. Das Treffen sollte immer am gleichen Ort und zur gleichen Zeit stattfinden. jeder darf teilnehmen, aber die eigentlichen Rollen haben Sprachrecht. WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 46 Fortschrittskontrolle während eines Projektes Sogenannte Burn-down-Rate: aufgabe von scrum master, der diese ausführt – Ständiger Vergleich mit Planung Jedes Teammitglied schätzt täglich den Restaufwand seiner Tasks Es ergibt sich eine von Tag zu Tag verbesserte Genauigkeit (auch da die Anzahl der offenen APs abnimmt) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 47 Planungsfehler zeigen sich im Burn-down-Diagramm WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 48 Das Sprint Review Meeting / Retrospektive Am Ende jeden Sprints »Review Meeting«, Aufgabe 1: Team stellt die Ergebnisse dem Product Owner vor Aufgabe 2: eine rückwirkende Betrachtung, die Retrospektive, auf den Sprint. ganzes Scrum Team nimmt teil Es wird darüber diskutiert, was zukünftig verbessert werden soll (Selbstorganisation) WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 49 Zusammenfassung Immer häufiger eingesetzte Form der Projektorganisation Besonders in kleinen, schlanken Firmen Startups, etc. Scrum regelt den gesamten Entwicklungsprozess Setzt auf Eigenverantwortung und -organisation des Teams WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 50 Abschließend: Wie gut „funktioniert“ SCRUM in der Praxis? www.gpm-ipma.de/fileadmin/user_upload/Know-How/studien/Studie_Agiles-PM_web.pdf WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 51 … und wie gut dagegen XP? www.gpm-ipma.de/fileadmin/user_upload/Know-How/studien/Studie_Agiles-PM_web.pdf WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 52 Literatur Wirtschaftsinformatik & Management 4/2019: Schwerpunktthema “Agile, nur ein Buzzword?” Online: https://www.springerprofessional.de/agile-nur-ein-buzzword/16967266/ Dan Pilone, Russ Miles. Head First: Software Development, O'Reilly Verlag (2009) Sam Lightstone. Making it Big in Software, Prentice Hall (2010) Frederick P. Brooks. Mythical Man Month, Addison Wesley (1995) Stefanie Scherzinger. Agil und spielerisch: Neue Methoden der Software- Entwicklung in der Praxis und ihr Potential für den Schulunterricht. INFOS 2011: 23-24 (2011) Und ein paar Webressourcen https://www.scrumguides.org/ http://scrum-master.de/ https://www.scrum.org/ WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 53  Thematisierung von Agilität in der Zeitschrift WuM Schwerpunktheft 4/19: „Agile – nur ein Buzzword?“, sowie weitere Artikel Themen u.a. Agile digitale Transformation Agile Projektbewertung mit dem „fail fast indicator“ Agile Planung – nur so viel planen wie nötig Agilität in Organisationen Probleme: Havarierte Projekte, Saboteure der agilen Methoden Mischung: Agil und klassisch 54 Fragen der heutigen Vorlesung Welche Vorteile verspricht man sich von agilen Softwareentwicklungsmethoden? Was für Prinzipien stehen hinter der agilen Softwareentwicklung? Was sind typische Methoden der agilen Softwareentwicklung? Welche Grenzen/Nachteile gibt es bei der agilen Softwareentwicklung? Wie werden bei Scrum die klassischen Aufgaben des Projektmanagements umgesetzt? WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 55  BSc. WIN / MSc. DLM Management von IT-Projekten Vorlesung 9: Agile Entwicklung WS 2024/25 Prof. Dr. Michael Fellmann Professur für Wirtschaftsinformatik, insbes. Betriebliche Informationssysteme WS 24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik