055.1 Lektion 1

Zertifikat:

Open Source Essentials

Version:

1.0

Thema:

055 Projektmanagement

Lernziel:

055.1 Modelle der Softwareentwicklung

Lektion:

1 von 1

Einführung

Das Leben ist voller Projekte: die Planung eines Kinoabends, eines Ausflugs oder einer Familienveranstaltung, der Wochenplan der Kinder oder das Training für den Sport — Pläne sind zu machen und Aufgaben zu erledigen. Oft entwerfen wir mehrere Szenarien, mit Plan B, Plan C usw. Das ist in der Welt der Softwareentwicklung nicht anders.

Rollen in der Softwareentwicklung

Da erfolgreiches Projektmanagement eine Vielzahl von Fähigkeiten erfordert, ist es sinnvoll, verschiedene Personen für klar definierte Rollen vorzusehen. In den folgenden Abschnitten werden einige der Rollen beschrieben, die bei Softwareprojekten häufig anzutreffen sind.

Projektmanager

Die Leitung eines Projekts ist eine komplexe Aufgabe. Manche Situationen sehen auf den ersten Blick einfach aus, erfordern aber viel Sorgfalt und Erfahrung. Dies ist die Zuständigkeit des Projektmanagers.

Zu den Aufgaben des Projektmanagers gehört es, dafür zu sorgen, dass das Projekt rechtzeitig, im Rahmen des Budgets und in akzeptabler Qualität fertiggestellt wird. Auch wenn er keine einzige Zeile Code schreibt, ist der Projektmanager für die Ergebnisse des Teams verantwortlich. Er muss mit Kunden die Fristen abstimmen und mit Mitarbeitern in anderen Rollen sprechen, um sicherzustellen, dass alles planmäßig vorangeht.

Business Analyst und Requirement Engineer

Es gibt keinen Platz für Mikromanagement — zumindest nicht an einem angenehmen Arbeitsplatz. Business Analysten (BA) und Requirement Engineers (RE), im Deutschen auch Anforderungsmanager genannt, unterstützen den Projektmanager intern oder extern im Projektteam. Sie sind verantwortlich für eine umfassende und klare Dokumentation der Anforderungen. Sie sind zugleich das Bindeglied zwischen Kunden und Entwicklern. Kunden kommunizieren in einfacher Sprache, was BA/RE in eine eindeutige Dokumentation überführen, damit Entwickler ihre Arbeit effektiv erledigen können.

Stellen Sie sich vor, Sie werden gebeten, eine “große Torte” zu einer Party mitzubringen. Was bedeutet “groß”? Zehn Stücke oder zwanzig? Vielleicht ist es aber auch eine Hochzeitstorte mit hundert Stücken. Der BA/RE muss Anforderungen wie Mengen genau spezifizieren, damit die Entwickler wissen, dass eine Anwendung beispielsweise für eine bestimmte Anzahl von Benutzern konzipiert ist.

Schon zu Beginn der Anforderungsdefinition wird deutlich, wie wichtig klare Kommunikation ist. Zwar ist sie für jede Zusammenarbet unerlässlich, aber in einem Open-Source-Projekt ist sie vielleicht noch wichtiger, da Menschen mit sehr unterschiedlichem Hintergrund an den verschiedenen Teilen des Projekts arbeiten: Studierende, Rentner, Berufstätige mit zwei Jobs usw. Dennoch muss der Projektfortschritt auch in dieser Umgebung reibungslos sein — und Kommunikation darf diesen Fortschritt nicht behindern.

Entwickler, Architekten und Tester

Um die Anforderungen umzusetzen, braucht ein Softwareprojekt Entwickler, die das Produkt auf der Grundlage der Dokumentationen und Designentscheidungen erstellen. Ihre Arbeit wird vom Architekten beurteilt, der in der Regel über die umfangreichsten technischen und fachlichen Kenntnisse aller Projektbeteiligten verfügt. Jeder Entwickler, insbesondere die Senior Developer, ist für seinen eigenen Code verantwortlich, aber umfassende Entscheidungen werden vom Architekten getroffen oder genehmigt.

Manchmal werden auch Tester benannt, die für alle Arten von Tests, die Dokumentation der Ergebnisse und die Erstellung von Tickets verantwortlich sind.

Planung und Terminierung

Nach den grundlegenden Rollen in einem Softwareprojekt betrachten wir nun dessen wichtigste Phasen: Planung, Terminierung, Implementierung, Wartung/Test und Übergabe. Einige Phasen unterscheiden sich in verschiedenen Softwareentwicklungsmodellen, aber Planung und Terminierung sind allgemeine Themen, die wir besprechen, bevor wir tiefer in verschiedene Modelle eintauchen.

Die Planung erfolgt, nachdem die BAs/REs die Anforderungsliste vorgelegt haben. Die Planung besteht aus einem oder mehreren Meetings, in denen geklärt wird, was das Team erreichen will, wie es das erreichen will und wie lange das dauern würde. Normalerweise erfolgt in diesen Meetings auch eine Risikoanalyse.

Die Planer müssen dann die Arbeit terminieren und Meilensteine (Milestones) definieren. Jeder Milestone zeigt dem Team, dass ein großer und wichtiger Teil abgeschlossen ist. Manche Komponenten oder Funktionen können Monate der Entwicklung erfordern, so dass die Planer Urlaube, Feiertage und — vor allem in der kalten Jahreszeit — krankheitsbedingte Ausfälle einkalkulieren müssen, um einen genauen Liefertermin zu gewährleisten und Hektik vor der Abgabe zu vermeiden. Bei einem soliden Zeitplan fühlen sich die Entwickler entspannter und können qualitativ hochwertige Lösungen pünktlich und ohne Pannen liefern.

Tools

Zwei Werkzeuge, die für alle Entwicklungsmodelle und das Projektmanagement im Allgemeinen von Vorteil sind, sind ein Versionskontrollsystem (VCS) und eine Plattform für das Application Lifecycle Management (ALM), also die Verwaltung des Lebenszyklus eines Projekts oder Produkts. Die Versionskontrolle wird in einer anderen Lektion ausführlich behandelt — hier also einige Bemerkungen zum ALM.

ALM ist ein umfassendes Framework, das den Lebenszyklus einer Softwareanwendung von der Entwicklung über die Wartung bis hin zur Ausmusterung verwaltet. ALM integriert Menschen, Prozesse und Tools, um Zusammenarbeit und Effizienz zu verbessern und sicherzustellen, dass alle Phasen des Lebenszyklus einer Software koordiniert und auf die Unternehmensziele abgestimmt sind. Dieser Ansatz hilft, Qualität, Leistung und Zuverlässigkeit von Anwendungen während ihrer gesamten Lebensdauer zu erhalten.

Nach einem groben Überblick über Rollen und die Phasen des Lebenszyklus geht es im Folgenden um Modelle der Softwareentwicklung.

Wasserfallmodell

Das Wasserfallmodell ist eine der frühesten und einfachsten Methoden der Softwareentwicklung. Man kann sie sich wie eine Treppe vorstellen, bei der jede Stufe abgeschlossen sein muss, bevor es weitergeht. Das Modell kennt jedoch nur eine Richtung, so dass es sich nur für Projekte mit klaren Anforderungen und minimalen oder keinen zu erwartenden Änderungen eignet.

Zwar kann die Einfachheit dieses Modells ein Vorteil sein, allerdings gerät sie rasch zum Nachteil, wenn Flexibilität und Anpassungsfähigkeit gefragt sind — und heutzutage ändert sich meist alles während der Arbeit an einem Projekt.

Wie in den vorangegangenen Abschnitten erläutert, benötigt ein Projekt zu Beginn der Entwicklung die Anforderungen, ein abgeschlossenes Konzept und einen endgültigen Zeitplan für die Arbeit mit Meilensteinen. Im Wasserfallmodell sind dies die Ergebnisse des Anforderungsmanagements (Requirement Engineering) und der Geschäftsanalyse (Business Analysis).

Anforderungsmanagement

In dieser ersten Phase werden alle Projektanforderungen gesammelt und dokumentiert. Dazu gehören ausführliche Gespräche zwischen dem Projektleiter und den Auftraggebern, um deren Bedürfnisse und Erwartungen zu verstehen. Das Ergebnis ist eine umfassende Requirements Specification, also ein Dokument, das die Anforderungen an das System beschreibt.

Geschäftsanalyse

Business Analysts (BAs) untersuchen die Anforderungen aus der Unternehmensperspektive, um sicherzustellen, dass sie mit den Unternehmenszielen übereinstimmen. BAs führen Machbarkeitsstudien, Risikobewertungen und Kosten-Nutzen-Analysen durch, um Durchführbarkeit und Nutzen des Projekts zu bewerten. Die gewonnenen Erkenntnisse dienen der Präzisierung des Projektumfangs und der Projektziele.

Softwaredesign

Softwaredesign ist der Schritt, in dem der Architekt einen detaillierten Entwurf erstellt, an dem sich die Entwickler orientieren. Mit dieser Spezifikation kann das Team mit der Umsetzung der Anforderungen beginnen, also mit der eigentlichen Entwicklungsphase.

Entwicklung

In der Entwicklungsphase findet die eigentliche Magie statt — der Code wird geschrieben. Die Entwickler folgen gewissenhaft der Dokumentation und den Designentscheidungen und schreiben ihre Teile. Nachdem die Entwickler ihren Code mit anderen Entwicklern oder dem Architekten überprüft haben, kann diese Phase als abgeschlossen betrachtet werden.

Testing

Auf die Entwicklung folgt eine Testphase, die von den Testern geleitet wird. Es gibt verschiedene Arten von Tests, die in einer anderen Lektion beschrieben werden, beispielsweise Unit Tests, Integrationstests, Systemtests und Abnahmetests.

Ziel dieser Tests ist es, Probleme vor der Veröffentlichung aufzudecken und den Entwicklern die Möglichkeit zu geben, sie rechtzeitig zu beheben — und nicht erst, nachdem das Projekt bereitgestellt und veröffentlicht wurde und die Benutzer durch Fehler verärgert und frustriert werden.

Betrieb

Nachdem die Tests bestanden und Fehler behoben wurden, kann das Projekt freigegeben, also in der Produktionsumgebung bereitgestellt werden. Diese Phase kann die Installation, die Konfiguration und manchmal auch die Schulung der Benutzer umfassen. Ist das Projekt einsatzbereit, befindet es sich in einer Wartungsphase, in der das Team Probleme der Benutzer beheben und gegebenenfalls Aktualisierungen bereitstellen kann.

Beurteilung des Wasserfallmodells

Fassen wir Vor- und Nachteile des Wasserfallmodells kurz zusammen.

Das Wasserfallmodell hat folgende Vorteile:

Klare Struktur: Der lineare Prozess ist einfach zu verwalten, zu verstehen und nachzuverfolgen.
Ausführliche Dokumentation: Eine detaillierte Dokumentation jeder Phase hilft dem Team zu verstehen, was während der Entwicklung und der zukünftigen Wartung benötigt wird.
Vorhersehbarkeit: Klar definierte Meilensteine sorgen für einen vorhersehbaren Zeitplan und ein planbares Budget.
Vereinfachtes Projektmanagement: Dank seines linearen und unkomplizierten Ablaufs ist das Modell einfach zu verwalten.

Das Wasserfallmodell hat folgende Nachteile:

Mangelnde Flexibilität: Die lineare Starrheit des Modells erschwert die Umsetzung von Änderungen nach Abschluss der Anforderungsphase.
Spätes Testing: Während der Entwicklungsphase werden Tests nur unregelmäßig oder gar nicht durchgeführt, was dazu führen kann, dass gravierende Probleme zu spät erkannt werden.
Annahme perfekter Anforderungen: Das Modell setzt voraus, dass alle Anforderungen korrekt und eindeutig sind, was unrealistisch sein kann. Das Modell bietet keinen Raum für Überprüfungen während der Entwicklung, die sicherstellen würden, dass die Anforderungen korrekt sind und von den Entwicklern verstanden werden.
Fehlendes Feedback: Erst in der letzten Phase kann ein Kunde etwas über das Produkt sagen. Wenn also etwas (oder vieles) nicht seinen Erwartungen entspricht, taucht das Problem erst ganz am Schluss auf.

Agile Softwareentwicklung, Scrum und Kanban

Um diese Reihe modernerer Softwareentwicklungsmodelle zu erkunden, geht es zunächst um den Begriff agil: Agilität drückt die Fähigkeit aus, schnell zu reagieren und sich zu bewegen, sowohl physisch als auch gedanklich; und dies ist auch das Ziel in der Softwareentwicklung.

Agile Softwareentwicklung ist eine Methodik, die auf iterativer Entwicklung, Flexibilität und Zusammenarbeit aufbaut. Sie konzentriert sich darauf, kleine Verbesserungen zu liefern und dabei stets Feedback einzuholen und während der Entwicklung umzusetzen. Dieser Ansatz ermöglicht schnelle Reaktionen, Anpassungen und Antworten, was Zeit spart und sicherstellt, dass das Projekt die Erwartungen der Benutzer und Kunden erfüllt.

Die agile Bewegung startete 2001 mit einem Online-Manifest für agile Softwareentwicklung, in dem die folgenden Grundsätze benannt sind:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

— Manifest für Agile Softwareentwicklung

Scrum

Scrum ist eines der populärsten Frameworks — vielleicht sogar das populärste — in der agilen Softwareentwicklung. Scrum basiert auf den folgenden Bausteinen:

Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein Umfeld fördert, in dem

ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;

das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;

das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen;

diese Schritte wiederholt werden.

— The 2020 Scrum Guide

Aber wer sind Scrum Master und Product Owner? Was sind Product Backlog und Sprint? Sehen wir uns die Rollen und Prozesse genauer an.

Sprints und Sprint-Planung

Ein Sprint ist eine typischerweise zwei- bis vierwöchige Entwicklungsphase, in der zuvor definierte Aufgaben und/oder Features fertiggestellt werden. Einigkeit über die Aufgaben wird in der vorangehenden Sprint-Planung erzielt. In diesem Prozess trifft das Team Entscheidungen darüber, welche Aufgaben im kommenden Sprint fertiggestellt werden können.

Diese Entscheidungen beruhen auf den vom Product Owners (PO) bestimmten Prioritäten, der das Projekt steuert und oft auch die Mittel dafür bereitstellt.

Product Backlog und Sprint Backlog

Der PO verwaltet also die Prioritätenliste, die alle gewünschten Arbeiten am Projekt enthält. In Scrum wird diese Liste Product Backlog genannt. Jedes Sprint Backlog enthält die ausgewählten Aufgaben für den aktuellen Sprint aus dem Product Backlog. Das Sprint Backlog führt die vom Team während der Sprint-Planung ausgewählten Elemente auf.

Daily Scrum oder Stand-up

Das Daily Scrum oder Stand-up ist ein kurzes, effizientes Treffen, bei dem die Teams ihre Fortschritte besprechen, Probleme und Blocker benennen und ihre Pläne für den Tag mitteilen. Ein Scrum findet in der Regel zu Beginn des Arbeitstages statt.

Inkrement

Ein Inkrement ist ein Ziel, das während eines Sprints erreicht wird. Jeder Sprint sollte zu einem oder mehreren Inkrementen führen. Die Korrektheit der durch das Inkrement erreichten Aufgabe oder Features sollte durch Testen überprüft werden.

Sprint Review

Der Sprint Review ist ein Meeting zur Überprüfung des Sprint-Ergebnisses. Diese Meetings sind in der Regel mehr als Demos; Ziel ist Feedback zu den Ergebnissen des Scrum-Teams. Um das Produktziel zu erreichen, geben die Beteiligten Kommentare und Vorschläge für weitere Anpassungen ab. Ergebnisse dieser Meetings können Änderungen oder Ergänzungen des Product Backlogs sein.

Sprint-Retrospektive

Ziel der Sprint-Retrospektive ist die Verbesserung von Qualität und Effektivität — und das nicht nur für das aktuelle Produkt. Die Retrospektive soll versteckte Spannungen innerhalb des Teams aufdecken, fehlende Informationen, die Prozesse verlangsamen, Abhängigkeiten von außen, die gelockert werden sollten, um das Team zu entlasten, usw. Das Team bespricht, was gut gelaufen ist, welche Probleme es gab und welche Lösungen für diese Probleme gefunden wurden (oder auch nicht).

Das Ergebnis ist eine Liste von Problemen mit möglichen Lösungen, die der zuständigen Person zugewiesen werden.

Scrum Master

All diese Meetings leitet der Scrum Master, den jedes Scrum Team braucht. Er ist dafür verantwortlich, die Scrum-Prozesse zu moderieren und dem Team zu helfen, das Produktziel zu erreichen, auch wenn während der Sprints Probleme auftreten. Der Scrum Master leitet nicht nur die Prozesse, sondern fungiert auch als Coach, um eine effektive Kommunikation innerhalb des Teams sicherzustellen.

Product Owner

Der Product Owner ist für die Wertmaximierung des vom Scrum Team geschaffenen Produkts verantwortlich. Diese Rolle kann in verschiedenen Organisationen und Teams unterschiedlich sein, aber selbst wenn er Aufgaben delegiert, bleibt der Product Owner für die Ergebnisse verantwortlich.

Erfolg setzt voraus, dass die Organisation die Entscheidungen des Product Owners, die sich im Product Backlog und im Inkrement des Sprint Reviews widerspiegeln, respektiert. Der Product Owner ist eine einzige Person, die die Bedürfnisse der verschiedenen Beteiligten und Interessen im Product Backlog repräsentiert. Wer das Backlog ändern möchte, muss den Product Owner davon überzeugen. Der Product Owner definiert und priorisiert die Produktvision und das Backlog und sorgt für Transparenz, Sichtbarkeit und Verständlichkeit des Product Backlogs.

Scrum Master und Product Owner arbeiten zusammen, um den Projekterfolg voranzutreiben. Ihre Partnerschaft hilft dem Entwicklungsteam, hochwertige Funktionen effizient und wirkungsvoll zu liefern.

Entwickler

Die Entwickler setzen die Anforderungen entsprechend dem vereinbarten Sprint Backlog um. Sie können unabhängig voneinander arbeiten, aber es gibt verschiedene Gelegenheiten, bei denen sie zusammenarbeiten können, beispielsweise beim Pair Programming oder bei der Überprüfung des Codes eines anderen Entwicklers.

Beurteilung des Scrum-Modells

Scrum hat sich bei Softwareteams durchgesetzt, aber auch hier gibt es Vor- und Nachteile.

Das Scrum-Modell hat folgende Vorteile:

Flexibilität: Die Prozesse sind flexibel und iterativ, so dass Änderungen auf der Grundlage von Feedback möglich sind.
Einbeziehung der Kunden: Regelmäßiges Feedback gewährleistet die Anpassung an die Kundenbedürfnisse.
Verbesserte Qualität: Häufige Tests und Reviews verbessern die Produktqualität.
Zusammenarbeit im Team: Das Modell legt Wert auf Teamarbeit und Kommunikation durch tägliche Stand-ups und regelmäßige Treffen.

Das Scrum-Modell hat folgende Nachteile:

Notwendige Disziplin: Scrum erfordert die strikte Einhaltung der Abläufe, was eine Herausforderung sein kann.
Ausufernde Anforderungen: Es besteht die Gefahr, dass immer mehr Kundenwünsche hinzukommen und die Veröffentlichung verzögern, wenn der Product Backlog nicht gut verwaltet wird.
Rollenverteilung: Standardrollen wie Scrum Master und Product Owner können missverstanden oder schlecht umgesetzt werden.
Ressourcenintensiv: Tägliche Sitzungen und häufige Reviews können zeitaufwändig sein.

Kanban

Kanban ist ein weiteres beliebtes agiles Framework, das den Schwerpunkt auf Arbeitsvisualisierung, Flussmanagement und Prozessverbesserungen legt. Einer der großen Unterschiede zwischen Scrum und Kanban ist, dass Kanban keine Iterationen mit fester Länge erfordert. Dadurch wird die kontinuierliche Lieferung flexibler und kann unterschiedliche Prioritäten ausgleichen.

In den folgenden Abschnitten sehen wir uns an, was Teams für ein Kanban-Projekt benötigen.

Kanban Boards

Ein Kanban Board ist ein visuelles Hilfsmittel, das den Arbeitsfluss in verschiedenen Phasen abbildet. Die wichtigsten Spalten sind “To Do”, “In Progress” und “Done”. Weitere Spalten können hinzugefügt werden, aber diese drei müssen auf dem Board vorhanden sein. Die Visualisierung hilft Teams, Engpässe zu erkennen und den Status von Aufgaben schnell zu erfassen.

Work in Progress Limit

Ein Work in Progress Limit hilft, Multitasking zu vermeiden, und erhöht die Konzentration. Mit diesem Limit gibt es einen Punkt, an dem keine weiteren Aufgaben mehr in der Spalte “In Progress” hinzugefügt werden, so dass die Entwickler nicht mit Aufgaben überlastet werden und sich auf die Aufgaben konzentrieren, an denen sie gerade arbeiten.

Teammitglieder

Die Teammitglieder sind für die Erledigung der Aufgaben und den reibungslosen Ablauf im Kanban-System verantwortlich. Sie arbeiten zusammen, um die Arbeit zu priorisieren und alle auftretenden Probleme zu erkennen und zu lösen.

Kanban Manager

Der Kanban Manager beaufsichtigt den Kanban-Prozess und stellt sicher, dass das Team die Kanban-Prinzipien und -Praktiken befolgt. Er moderiert Besprechungen, überwacht die Arbeitsabläufe und hilft bei der Lösung von Problemen.

Beurteilung des Kanban-Modells

Der Kern dieses Modells ist einfach; betrachten wir die Vor- und Nachteile: Das Kanban-Modell hat folgende Vorteile:

Visueller Arbeitsablauf: Kanban Boards machen Arbeitsstatus und -fortschritt klar erkennbar.
Flexibilität: Da es keine festen Iterationen gibt, unterstützt das Modell die kontinuierliche Bereitstellung (Continuous Delivery) mit hoher Anpassungsfähigkeit.
Begrenzung der Aufgaben: Das Work in Progress Limit trägt dazu bei, dass Teammitglieder nicht überlastet werden, und steigert somit Fokussierung und Effizienz.
Kontinuierliche Verbesserung: Das Modell fördert die regelmäßige Bewertung und Verbesserung der Prozesse.

Das Kanban-Modell hat folgende Nachteile:

Fehlender Zeitrahmen: Ohne feste Fristen ist das Zeitmanagement schwierig.
Weniger Struktur: Dem Modell kann es an Struktur fehlen, die manche Teams brauchen, um organisiert zu bleiben.
Notwendige Disziplin: Wirksame Work in Progress Limits und das Board Management müssen sorgfältig überwacht werden.
Mögliche Vereinfachung: Die Aufgabenbeschreibungen könnten komplexe Projekte zu stark vereinfachen, wenn sie nicht mit Bedacht umgesetzt werden.

DevOps

DevOps ist ein Softwareentwicklungsansatz, der die Teams aus Entwicklung (Development) und Betrieb (Operations) integriert, um Zusammenarbeit, Effizienz und Geschwindigkeit der Bereitstellung zu verbessern. Das Hauptziel von DevOps ist die Verkürzung des Softwareentwicklungszyklus und die kontinuierliche Bereitstellung bei hoher Softwarequalität. DevOps legt den Schwerpunkt auf Automatisierung, kontinuierliche Integration und kontinuierliche Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD) sowie auf eine enge Zusammenarbeit zwischen traditionell getrennten Teams.

Die Automatisierung von Aufgaben wie Code-Integration, Testen, Bereitstellung und Infrastrukturmanagement ist für DevOps von entscheidender Bedeutung. Die Automatisierung sich wiederholender Aufgaben reduziert Fehler, beschleunigt Prozesse und ermöglicht es Teams, sich auf eher strategische Aufgaben zu konzentrieren.

Zu den DevOps-Praktiken gehört die Einrichtung umfassender Überwachungs- und Protokollierungssysteme, um Probleme zu erkennen, Trends zu analysieren und die Systemzuverlässigkeit zu verbessern.

Beurteilung des DevOps-Modells

Obwohl sich DevOps für viele moderne Softwareprojekte empfiehlt, sind auch hier Vor- und Nachteile zu berücksichtigen.

Das DevOps-Modell hat folgende Vorteile:

Schnelligkeit und Effizienz: Das Modell beschleunigt die Entwicklungs- und Bereitstellungszyklen durch Automatisierung.

Verbesserte Zusammenarbeit: Das Modell überbrückt die Kluft zwischen Entwicklungs- und Betriebsteams.

Kontinuierliche Bereitstellung: Das Modell stellt sicher, dass die Software immer in einem einsatzbereiten Zustand ist, was zu häufigeren Releases führt.

Hohe Zuverlässigkeit: Automatisierte Tests und Überwachung erhöhen die Zuverlässigkeit und reduzieren Fehler.

Das DevOps-Modell hat folgende Nachteile:

Wandel der Arbeitskultur: Das Modell erfordert einen bedeutenden Wandel in Arbeitsabläufen und die Akzeptanz in der gesamten Organisation.
Komplexität: Die Verwaltung von CI/CD-Pipelines und automatisierter Infrastruktur kann komplex sein.
Sicherheitsrisiken: Die kontinuierliche Bereitstellung kann bei unvorsichtiger Handhabung zu Sicherheitslücken führen.
Viele Tools: Die Vielzahl der eingesetzten Tools und Technologien kann erdrückend sein.

Geführte Übungen

Was bedeutet Agilität?
Wie lautet die Scrum-Definition gemäß dem Scrum Guide?
Warum kann Scrum in Bezug auf Kundenfeedback besser sein als das Wasserfallmodell?
Was sind die positiven Aspekte von DevOps?

Offene Übungen

Warum ist das Wasserfallmodell in einem sich schnell verändernden Umfeld nicht die beste Lösung?
Was kann passieren, wenn die Rolle des Scrum Masters schlecht umgesetzt wird?

Zusammenfassung

Die Bedeutung des Projektmanagements bei der Softwareentwicklung, insbesondere bei Open-Source-Projekten, liegt in seiner Fähigkeit, für Struktur zu sorgen, Kommunikation zu verbessern, Rollen zu definieren, Risiken zu managen und Qualität zu gewährleisten. Diese Elemente sind entscheidend für den erfolgreichen Abschluss von Projekten und für die Förderung einer kooperativen und produktiven Entwicklungsumgebung.

In dieser Lektion ging es um das Wasserfallmodell, agile Methoden und DevOps. Die Kenntnis dieser Modelle ist für das Verständnis des Projektmanagements in der Softwareentwicklung unerlässlich. Es gibt keinen goldenen Weg — jedes Projekt ist anders. Besprochen wurden Rollen, Prozesse sowie die Vor- und Nachteile der verschiedenen Ansätze, was dabei helfen kann, das passende Modell für ein Projekt auszuwählen.

Antworten zu den geführten Übungen

Was bedeutet Agilität?

Agilität ist die Fähigkeit, schnell zu reagieren und sich zu bewegen, sowohl physisch als auch mental.
Wie lautet die Scrum-Definition gemäß dem Scrum Guide?
- Ein Product Owner sortiert die Arbeit für ein komplexes Problem in einem Product Backlog.
- Das Scrum Team setzt einen Teil der Arbeit im Rahmen eines Sprints in ein Inkrement, einen Zwischenschritt mit höherem Wert, um.
- Das Scrum Team und seine Beteiligten prüfen die Ergebnisse und passen sie für den nächsten Sprint an.
- Wiederholung
Warum kann Scrum in Bezug auf Kundenfeedback besser sein als das Wasserfallmodell?

Da Feedback bereits während der Entwicklung gesammelt wird, kann das Endprodukt die Erwartungen der Kunden besser erfüllen.
Was sind die positiven Aspekte von DevOps?

Geschwindigkeit und Effizienz — Verbesserte Zusammenarbeit — Kontinuierliche Bereitstellung — Hohe Zuverlässigkeit.

Antworten zu den offenen Übungen

Warum ist das Wasserfallmodell in einem sich schnell verändernden Umfeld nicht die beste Lösung?

Beim Wasserfallmodell wird Feedback erst am Ende der Entwicklung gesammelt. Daher muss jede Anforderung, die von den Entwicklern missverstanden wurde, ganz am Ende korrigiert werden. Wenn sich die Umgebung sehr schnell ändert, sollte dieses Modell nicht verwendet werden, da während des Entwicklungszyklus kein Feedback vorgesehen ist.
Was kann passieren, wenn die Rolle des Scrum Masters schlecht umgesetzt wird?

Eine schlecht umgesetzte Rolle als Scrum Master kann das Team daran hindern, effizient hochwertige Produkte zu liefern, und damit die eigentlichen Vorteile von Scrum untergraben. Dem Team fehlt möglicherweise eine angemessene Anleitung zu den Scrum-Praktiken und -Prinzipien, was zu einer inkonsistenten oder falschen Anwendung des Frameworks führt.

Ohne einen geeigneten Scrum Master, der Hindernisse aus dem Weg räumt, können Fortschritte verlangsamt und die Produktivität des Teams verringert werden. Die Kommunikation zwischen Teammitgliedern und anderen Beteiligten kann leiden, was zu Missverständnissen und nicht abgestimmten Erwartungen führt. Das Team kann aufgrund ungelöster Probleme, mangelnder Unterstützung und ineffektiver Moderation von Scrum Events seine Motivation verlieren. Unzulänglichkeiten können durch schlecht geführte Meetings, mangelnden Fokus und ineffiziente Sprint-Planung und -Reviews entstehen.