DIY - Individual prototyping and systems engineering (V+Ü+Projekt) - Exam

Aufgabe 1)

Du bist beauftragt, einen Prototypen für eine neue mobile App zu erstellen, die Schülern hilft, ihre Hausaufgaben zu organisieren und zu verfolgen. Dabei sollst Du den iterativen Prototyping-Prozess anwenden, um Risiken zu minimieren und Nutzer-Feedback frühzeitig einzuarbeiten.

a)

Beschreibe die Schritte, die Du in einem iterativen Prototyping-Prozess durchlaufen würdest, um den Prototypen zu entwickeln. Stelle sicher, dass Du mindestens drei Iterationen beschreibst und erklären, welche Art von Prototyp Du in jeder Iteration verwenden würdest (Low-Fidelity, High-Fidelity, etc.).

Lösung:

Iterativer Prototyping-Prozess zur Entwicklung der Hausaufgaben-Organisations-AppHier ist ein detaillierter iterativer Prototyping-Prozess, der mindestens drei Iterationen umfasst, um einen Prototypen für eine mobile App zur Hausaufgaben-Organisation zu entwickeln:

• Iteration 1: Erstellung eines Low-Fidelity-PrototypsIn der ersten Iteration wird ein Low-Fidelity-Prototyp entwickelt. Dieser besteht meist aus einfachen Skizzen oder Wireframes, die auf Papier oder mit einem digitalen Wireframe-Tool erstellt werden.
  • Schritt 1: Anforderungsanalyse: Sammeln von Informationen über die Bedürfnisse der Nutzer, z.B. durch Interviews oder Umfragen mit Schülern.
  • Schritt 2: Erstellung von Wireframes: Skizzieren der grundlegenden Benutzeroberfläche und der Benutzerflüsse auf Papier oder mit einem Tool wie Balsamiq.
  • Schritt 3: Feedback einholen: Präsentation der Wireframes an eine kleine Gruppe von Nutzern (z.B. einige Schüler und Lehrer) und Sammeln von Feedback zur Benutzeroberfläche und zu den Funktionen.
• Iteration 2: Entwicklung eines Mid-Fidelity-PrototypsBasierend auf dem Feedback der ersten Iteration wird nun ein detaillierterer Prototyp entwickelt, der mehr visuelle Details und Interaktionsmöglichkeiten bietet.
  • Schritt 1: Überarbeitung der Wireframes: Integration des erhaltenen Feedbacks bei der Erstellung detaillierterer Wireframes oder Mockups mit einem Tool wie Figma oder Adobe XD.
  • Schritt 2: Hinzufügen von Interaktivität: Verwendung eines Prototyping-Tools, um klickbare Prototypen zu erstellen, die es den Nutzern ermöglichen, durch die App zu navigieren.
  • Schritt 3: Feedback einholen: Durchführung von Usability-Tests mit einer größeren Gruppe von Nutzern und Sammeln von detailliertem Feedback zur Benutzerfreundlichkeit und zu weiteren Verbesserungsvorschlägen.
• Iteration 3: Erstellung eines High-Fidelity-PrototypsIn dieser Iteration wird ein nahezu fertiger Prototyp erstellt, der dem Endprodukt sehr nahe kommt und die endgültige Benutzeroberfläche sowie nahezu alle Funktionen umfasst.
  • Schritt 1: Design-Feinschliff: Verfeinerung des Designs und Integration aller visuell ansprechenden Elemente sowie detaillierter Interaktionen basierend auf dem Feedback aus der zweiten Iteration.
  • Schritt 2: Implementierung der meisten Funktionen: Programmieren der wichtigsten Funktionen und Verknüpfungen der App, sodass ein realistischer, funktionsfähiger Prototyp entsteht, der auf mobilen Geräten getestet werden kann.
  • Schritt 3: Benutzer-Tests und letzte Anpassungen: Durchführung umfassender Usability-Tests mit der Zielgruppe und Feinabstimmung der App basierend auf dem Feedback, um sicherzustellen, dass alle Anforderungen erfüllt sind und die Benutzererfahrung optimal ist.

b)

Mathematische Modelle können verwendet werden, um Zeit- und Ressourcenplanung im Prototyping-Prozess zu unterstützen. Angenommen, Du hast folgende Schätzungen für die Dauer jeder Iteration: Erste Iteration (Low-Fidelity) dauert 3 Tage, zweite Iteration (Medium-Fidelity) dauert 5 Tage und dritte Iteration (High-Fidelity) dauert 7 Tage. Berechne die gesamte Entwicklungszeit für den Prototypen. Falls jede Iteration eine Feedback-Zykluszeit von 2 Tagen hat, wie ändern sich die Gesamtentwicklungszeiten?

Lösung:

Berechnung der gesamten Entwicklungszeit für den Prototypen:

• Erste Iteration (Low-Fidelity): 3 Tage
• Zweite Iteration (Medium-Fidelity): 5 Tage
• Dritte Iteration (High-Fidelity): 7 Tage

Die Gesamtdauer ohne Feedback-Zyklen beträgt:

• 3 Tage (erste Iteration) + 5 Tage (zweite Iteration) + 7 Tage (dritte Iteration) = 15 Tage

Berücksichtigung der Feedback-Zykluszeiten:Wenn jede Iteration einen Feedback-Zyklus von 2 Tagen hat, müssen wir diese Zeiten zur Grunddauer addieren.

• Erste Iteration: 3 Tage + 2 Tage Feedback = 5 Tage
• Zweite Iteration: 5 Tage + 2 Tage Feedback = 7 Tage
• Dritte Iteration: 7 Tage + 2 Tage Feedback = 9 Tage

Die Gesamtdauer mit Feedback-Zyklen beträgt:

• 5 Tage (erste Iteration) + 7 Tage (zweite Iteration) + 9 Tage (dritte Iteration) = 21 Tage

Zusammenfassung:

• Ohne Feedback-Zyklen: Die gesamte Entwicklungszeit beträgt 15 Tage
• Mit Feedback-Zyklen: Die gesamte Entwicklungszeit beträgt 21 Tage

c)

Was sind die Vorteile und möglichen Nachteile des Einholens von Nutzer-Feedback in jeder Iteration? Gib konkrete Beispiele, wie das Feedback den Entwicklungsprozess und das Endprodukt beeinflussen könnte. Vor allem, wie würdest Du mit widersprüchlichem Feedback umgehen?

Lösung:

Vorteile und mögliche Nachteile des Einholens von Nutzer-Feedback in jeder Iteration:

• Vorteile:
• Frühe Erkennung von Problemen: Durch frühes Feedback können potenzielle Probleme oder Missverständnisse bezüglich der Benutzeranforderungen schnell identifiziert und behoben werden.
• Verbesserte Benutzerfreundlichkeit: Nutzer-Feedback hilft, die Benutzererfahrung schrittweise zu optimieren, indem die App benutzerfreundlicher und intuitiver gestaltet wird.
• Erhöhte Benutzerzufriedenheit: Indem Du auf das Feedback der Benutzer eingehst, fühlen sich die Nutzer wertgeschätzt und ernst genommen, was letztendlich die Benutzerzufriedenheit erhöht.
• Kosteneffizienz: Änderungen und Verbesserungen können in frühen Entwicklungsphasen kostengünstiger und zeitlich effizienter umgesetzt werden, als wenn sie später im Entwicklungsprozess vorgenommen werden müssten.
• Nachteile:
• Erhöhter Zeitaufwand: Das regelmäßige Einholen und Umsetzen von Feedback kann den Entwicklungsprozess verlängern.
• Potenzielle Unklarheiten: Widersprüchliches Feedback kann zu Verwirrung und Unklarheiten im Team führen, was die Entscheidungsfindung und den Entwicklungsprozess verkomplizieren kann.
• Ressourcenaufwand: Das Einholen, Auswerten und Implementieren von Feedback erfordert zusätzliche Ressourcen, sowohl in Bezug auf die Zeit als auch auf die Arbeitskraft.
Konkrete Beispiele, wie Feedback den Entwicklungsprozess und das Endprodukt beeinflussen könnte:
• Beispiel 1: In der ersten Iteration stellt sich heraus, dass die Nutzer Schwierigkeiten haben, ihre Aufgaben in der App zu finden. Durch das Feedback wird die Navigationsstruktur überarbeitet und vereinfacht, was die Benutzerfreundlichkeit erhöht und die Nutzung der App angenehmer macht.
• Beispiel 2: Während der zweiten Iteration schlägt ein Großteil der Nutzer vor, dass eine Kalenderansicht hinzugefügt werden sollte, um die Aufgaben besser im Überblick zu behalten. Dieses Feedback wird in der nächsten Iteration implementiert, was die Funktionalität der App erheblich verbessert.
• Beispiel 3: Nach der dritten Iteration geben einige Nutzer an, dass sie eine Reminder-Funktion vermissen. Diese Anforderung wird in die Endphase der Prototypenentwicklung aufgenommen, um sicherzustellen, dass die App die Bedürfnisse der Zielgruppe vollständig erfüllt.
Umgang mit widersprüchlichem Feedback:
• Priorisieren von Feedback: Zunächst überlegst Du, welche Feedbackpunkte am häufigsten genannt wurden und welche für die Zielgruppe am wichtigsten sind. Feedback, das von einer Mehrheit der Nutzer kommt, sollte bevorzugt behandelt werden.
• Kategorisieren und Evaluieren: Teile das Feedback in verschiedene Kategorien ein (z.B. Benutzerfreundlichkeit, Funktionen, Design) und bewerte dessen Einfluss auf das Endprodukt. Widersprüchliches Feedback sollte gründlich analysiert werden, um herauszufinden, welches die größte Verbesserung für die Mehrheit der Nutzer bringt.
• Prototyping und A/B-Tests: Erstelle alternative Prototypen oder setze A/B-Tests ein, um verschiedene Ansätze zu testen. Nutzer können dann direkt miteinander vergleichen, was ihnen besser gefällt und was für sie besser funktioniert.
• Klare Kommunikation: Halte regelmäßige Meetings mit dem Entwicklungsteam und gegebenenfalls mit den Nutzern ab, um das Feedback zu diskutieren und eine gemeinsame Entscheidung über die Umsetzung zu treffen.
• Fokusgruppen und tiefere Einblicke: Führe detaillierte Interviews oder Fokusgruppen durch, um die Gründe hinter dem widersprüchlichen Feedback zu verstehen und eine fundierte Entscheidung zu treffen.

Aufgabe 2)

Im Laufe des Semesters hast Du verschiedene Arten von Prototypen kennengelernt, darunter Throwaway-Prototypen und evolutionäre Prototypen. Beide Prototyparten haben unterschiedliche Anwendungen und Ziele in der Softwareentwicklung. Throwaway-Prototypen werden schnell erstellt, um Anforderungen zu validieren, und anschließend verworfen. Im Gegensatz dazu werden evolutionäre Prototypen kontinuierlich weiterentwickelt, bis sie zum Endprodukt gereift sind.

a)

1. Beschreibe einen möglichen Use-Case für einen Throwaway-Prototyp und erläutere, warum diese Art von Prototyp für diesen spezifischen Use-Case geeignet ist.

Lösung:

Use-Case für einen Throwaway-Prototyp

• Kurze Beschreibung: Ein Softwareunternehmen erhält eine Anfrage von einem Kunden, der eine spezielle Anwendung zur Verwaltung von Veranstaltungen benötigt. Der Kunde ist sich noch nicht sicher, welche Funktionen die Anwendung genau haben soll und benötigt eine visuelle und funktionale Präsentation, um seine Anforderungen besser zu verstehen und zu definieren.
• Warum geeigneter Prototyp:
• Schnelle Umsetzung: Ein Throwaway-Prototyp kann sehr schnell entwickelt werden. Dies ist wichtig, um dem Kunden innerhalb kürzester Zeit eine erste Version der Anwendung zu zeigen und ihm zu helfen, seine Anforderungen klarer zu formulieren.
• Flexibilität: Da der Prototyp nur dazu dient, Anforderungen zu validieren und nicht weiterentwickelt wird, kann das Entwicklungsteam ohne große Rücksicht auf zukünftige Erweiterungen arbeiten. Dies erlaubt es, Änderungen und Anpassungen kurzfristig vorzunehmen.
• Kosteneffizienz: Durch die schnelle Erstellung und das Wegwerfen des Prototyps nach der Anforderungsvalidierung sparen die Entwickler Zeit und Ressourcen, die ansonsten für die Weiterentwicklung benötigt würden.
• Risikominderung: Der Kunde kann seine Erwartungen überprüfen, bevor größere Ressourcen in die finale Entwicklung investiert werden. Dies minimiert das Risiko, dass die finale Anwendung nicht den tatsächlichen Bedürfnissen des Kunden entspricht.

b)

2. Angenommen, Du entwickelst ein komplexes Softwaresystem mit vielen Unsicherheiten in den Anforderungen. Diskutiere die Vor- und Nachteile der Verwendung eines evolutionären Prototyps im Vergleich zu einem Throwaway-Prototyp in diesem Szenario.

Lösung:

Verwendung eines evolutionären Prototyps vs. eines Throwaway-Prototyps in einem komplexen Softwaresystem

• Evolutionärer Prototyp:
• Vorteile:
• Kontinuierliche Verbesserung: Der Prototyp wird kontinuierlich weiterentwickelt und verbessert, was zu einem reiferen und stabileren Endprodukt führt.
• Nutzerfeedback: Durch wiederholte Rückmeldungen der Nutzer kann der Prototyp an sich ändernde Anforderungen angepasst werden, wodurch das Endprodukt besser den tatsächlichen Bedürfnissen entspricht.
• Schrittweise Entwicklung: Unsicherheiten in den Anforderungen können leichter bewältigt werden, da das System schrittweise entwickelt und getestet wird. Probleme und neue Anforderungen können im laufenden Prozess entdeckt und adressiert werden.
• Nachteile:
• Höhere Kosten: Die kontinuierliche Weiterentwicklung und Überarbeitung des Prototyps erfordert mehr Zeit und Ressourcen, was die Kosten erhöhen kann.
• Komplexität des Managements: Die Pflege und Koordination eines evolutionären Prototyps kann komplex und ressourcenintensiv sein, insbesondere wenn viele Änderungen und Verbesserungen erforderlich sind.
• Throwaway-Prototyp:
• Vorteile:
• Schnellere Umsetzung: Ein Throwaway-Prototyp kann schnell entwickelt werden, um einen ersten Einblick in das System zu geben und Anforderungen zu validieren.
• Kosteneffizienz: Da der Prototyp nach der Validierung verworfen wird, wird weniger Zeit und Geld in die Entwicklung des Prototyps selbst investiert, wodurch die Kosten relativ gering bleiben.
• Fokus auf Anforderungserfassung: Der Hauptzweck besteht darin, die Anforderungen zu klären, ohne sich um die langfristige Wartbarkeit und Erweiterbarkeit des Prototyps zu kümmern.
• Nachteile:
• Fehlende Entwicklungskontinuität: Da der Prototyp verworfen wird, müssen bekannte Probleme und Verbesserungen von Grund auf neu entwickelt werden, was zu doppeltem Aufwand führen kann.
• Begrenzte Funktionalität: Der Prototyp enthält möglicherweise nicht alle Funktionalitäten des Endprodukts, was zu unvollständigen oder fehlerhaften Anforderungsdefinitionen führen kann.
• Risiko der Fehlausrichtung: Der endgültige Entwurf kann sich stark vom Prototyp unterscheiden, was zu Missverständnissen und Fehlausrichtungen bezüglich der tatsächlichen Anforderungen führen kann.
Fazit: In einem komplexen Softwaresystem mit vielen Unsicherheiten in den Anforderungen ist der Einsatz eines evolutionären Prototyps oft vorteilhafter, da er kontinuierlich verbessert und an veränderte Anforderungen angepasst werden kann. Dies minimiert das Risiko, dass das Endprodukt von den Bedürfnissen der Nutzer abweicht. Allerdings sollten die höheren Kosten und die komplexe Verwaltung berücksichtigt werden. Ein Throwaway-Prototyp kann eine gute Wahl sein, um schnell erste Anforderungen zu validieren, eignet sich jedoch weniger für die kontinuierliche Weiterentwicklung in einem komplexen Umfeld.

c)

3. Ein Unternehmen plant, ein neues interaktives System zu entwickeln. Du hast Dich für die Nutzung eines evolutionären Prototyps entschieden. Beschreibe den Prozess der kontinuierlichen Weiterentwicklung dieses Prototyps von der Konzeptionsphase bis zur Fertigstellung und zeige auf, welche Metriken und Methoden Du zur Bewertung der Prototyp-Iterationen verwenden würdest.

Lösung:

Prozess der kontinuierlichen Weiterentwicklung eines evolutionären Prototyps

• 1. Konzeptionsphase:
• Zielsetzung: Definiere die Ziele des interaktiven Systems und identifiziere die Hauptanforderungen und Funktionen.
• Stakeholder-Engagement: Arbeite eng mit den Interessengruppen zusammen, um deren Erwartungen und Bedürfnisse vollständig zu verstehen.
• Erste Skizzen und Mockups: Entwickle erste visuelle Skizzen oder Mockups, um die grundlegende Struktur und Design-Ideen zu präsentieren.
• 2. Erste Prototyp-Entwicklung:
• Schnelle Implementierung: Implementiere einen ersten funktionalen Prototyp, der grundlegende Funktionen und das User Interface beinhaltet.
• Feedbackrunde: Stelle den Prototyp den Stakeholdern und Benutzern vor, um erste Rückmeldungen zu sammeln.
• 3. Iterative Weiterentwicklung:
• Analyse des Feedbacks: Analysiere die Rückmeldungen und identifiziere Verbesserungspotenziale sowie neue Anforderungen.
• Planung der nächsten Iteration: Plane die Weiterentwicklungen und Priorisiere die anstehenden Aufgaben basierend auf dem Feedback und den identifizierten Anforderungen.
• Implementierung: Implementiere die geplanten Änderungen und neuen Funktionen.
• Testen und Validieren: Führe ausführliche Tests durch, um sicherzustellen, dass die Änderungen korrekt funktionieren und die Nutzeranforderungen erfüllen.
• Feedbackaufnahme: Wiederhole den Prozess der Rückmeldungen von Stakeholdern und Benutzern.
• 4. Finalisierung:
• Abschlussvalidierung: Führe umfassende Tests und Validierungen durch, um sicherzustellen, dass alle Anforderungen erfüllt sind und das System stabil ist.
• Dokumentation: Erstelle eine vollständige Dokumentation des Systems sowie der durchgeführten Änderungen und Verbesserungen während der Entwicklungsphasen.
• Freigabe und Deployment: Bereite das System für den endgültigen Einsatz vor und starte den Deployment-Prozess.

Metriken und Methoden zur Bewertung der Prototyp-Iterationen

• Metriken:
• Nutzerzufriedenheit: Erfasse die Zufriedenheit der Nutzer durch Umfragen und Feedback-Sitzungen.
• Anforderungsabdeckung: Überprüfe, wie viele der identifizierten Anforderungen bereits erfüllt wurden.
• Fehleranzahl und -frequenz: Zähle die Anzahl der entdeckten Fehler und wie häufig sie auftreten.
• Performance-Metriken: Messe die Systemleistung durch Ladezeiten, Antwortzeiten und Ressourcennutzung.
• Benutzungsstatistiken: Analysiere das Benutzerverhalten, z.B. welche Funktionen am häufigsten genutzt werden und Verweildauer auf verschiedenen Seiten.
• Methoden:
• Usability-Tests: Führe regelmäßige Usability-Tests mit einer repräsentativen Gruppe von Benutzern durch, um die Benutzerfreundlichkeit zu bewerten.
• Prototyp-Feedback-Sitzungen: Organisiere Feedback-Sitzungen nach jeder Iteration, um direktes Feedback von Stakeholdern und Benutzern zu bekommen.
• Monitoring und Logging: Implementiere Monitoring- und Logging-Tools, um die Systemleistung und das Benutzerverhalten kontinuierlich zu überwachen.
• A/B-Tests: Verwende A/B-Tests, um verschiedene Versionen des Prototyps zu vergleichen und herauszufinden, welche Iterationen die besten Ergebnisse liefern.

Aufgabe 3)

Du arbeitest in einem Softwareentwicklungsteam, das ein neues Projekt mit agilen Methoden angeht. Für dieses Projekt soll eine Wahl zwischen Scrum und Kanban getroffen sowie die spezifische Implementierung geplant werden. Berücksichtige die Anforderungen und Ziele des Projekts, um eine fundierte Entscheidung zu treffen.

a)

Erkläre die Hauptunterschiede zwischen Scrum und Kanban. Diskutiere, welcher Ansatz für ein Projekt geeignet sein könnte, das unter strengen Terminbeschränkungen steht und eine hohe Flexibilität sowie schnelle Anpassungen an Anforderungen erfordert.

Lösung:

Hauptunterschiede zwischen Scrum und Kanban:

• Struktur: Scrum ist ein Framework, das auf festen Iterationen (Sprints) basiert, die in der Regel 2-4 Wochen dauern. Jeder Sprint endet mit einem potenziell auslieferbaren Produktinkrement. Kanban hingegen hat keine vorgeschriebenen Iterationen. Die Arbeit fließt kontinuierlich, wobei der Fokus auf dem Management des Arbeitsflusses liegt.
• Rollen: Scrum definiert spezifische Rollen innerhalb des Teams, wie den Product Owner, den Scrum Master und das Entwicklungsteam. Kanban hat keine vorgeschriebenen Rollen, ist jedoch flexibel genug, um bestehende Rollen und Verantwortlichkeiten zu berücksichtigen.
• Meetings: Scrum sieht regelmäßige Zeremonien vor, wie tägliche Stand-up Meetings (Daily Scrums), Sprint-Planungen, Sprint-Reviews und Retrospektiven. Kanban hat keine festgelegten Meetings. Es obliegt dem Team, Meetings nach Bedarf abzuhalten.
• Board: In Scrum repräsentiert das Board den Sprint-Backlog und wird am Ende eines jeden Sprints aktualisiert. In Kanban wird das Board kontinuierlich aktualisiert und zeigt den Arbeitsfluss durch verschiedene Phasen.
• WIP Limit (Work in Progress Limit): Kanban hat ein klares Konzept der Begrenzung von laufenden Arbeiten (WIP), um Überlastung zu vermeiden und den Fluss zu verbessern. Scrum hat keine expliziten WIP-Limits, sondern festgelegt, wie viel Arbeit innerhalb eines Sprints abgeschlossen werden kann.

Welcher Ansatz könnte für das Projekt unter strengen Terminbeschränkungen geeignet sein?

Für ein Projekt, das unter strengen Terminbeschränkungen steht und eine hohe Flexibilität sowie schnelle Anpassungen an Anforderungen erfordert, könnte Kanban die geeignetere Wahl sein. Hier sind die Gründe:

• Kontinuierlicher Fluss: Kanban erlaubt eine kontinuierliche Auslieferung von Aufgaben und passt sich gut an laufende Änderungen an. Dies ist besonders wichtig, wenn sich die Anforderungen schnell ändern können.
• Flexibilität: Da es keine festgelegten Iterationen gibt, können Aufgaben jederzeit hinzugefügt oder angepasst werden, was eine schnelle Reaktion auf neue Anforderungen ermöglicht.
• Visualisierung und WIP Limits: Das Kanban-Board ermöglicht eine klare Visualisierung des Arbeitsflusses und hilft, Engpässe zu identifizieren und zu beseitigen. Die WIP-Limits tragen dazu bei, Überlastung zu vermeiden und fokussiertes Arbeiten zu fördern.

Während Scrum auch Vorteile bieten kann, wie eine klare Struktur und regelmäßige Feedbackschleifen, könnte die starre Sprintstruktur weniger flexibel sein, wenn schnelle Anpassungen erforderlich sind. Daher bietet Kanban in diesem spezifischen Kontext wahrscheinlich die notwendige Flexibilität und Anpassungsfähigkeit.

b)

Das ausgewählte Projekt verwendet Scrum als seine agile Methodik. Skizziere einen beispielhaften Sprintplan für ein 4-wöchiges Sprint. Beschreibe die verschiedenen Rollen (Product Owner, Scrum Master, Entwicklungsteam) und deren Verantwortlichkeiten während dieses Sprints. Füge einen Zeitplan für tägliche Stand-Ups, Sprint Review und Sprint Retrospektive hinzu.

Lösung:

Beispielhafter Sprintplan für ein 4-wöchiges Sprint (Scrum):

Ein Sprint in Scrum umfasst verschiedene Phasen und Meetings. Hier ist ein Beispiel für einen 4-wöchigen Sprint:

Woche 1:

• Tag 1: Sprint Planung (Teil 1 & 2): - Dauer: 3-4 Stunden - Teilnehmer: Produkt Owner, Scrum Master, Entwicklungsteam - Ziel: Festlegung der Sprint-Ziele, Erstellung des Sprint Backlogs basierend auf der Priorisierung durch den Product Owner.
• Tag 2-5: - Tägliches Stand-Up Meeting: - Dauer: 15 Minuten - Teilnehmer: Entwicklungsteam - Ziel: Besprechung des Fortschritts und der Hindernisse.

Woche 2-3:

• Tag 6-15: - Tägliches Stand-Up Meeting: - Dauer: 15 Minuten - Teilnehmer: Entwicklungsteam - Ziel: Besprechung des Fortschritts und der Hindernisse.
• Tag 16: Backlog Refinement: - Dauer: 1-2 Stunden - Teilnehmer: Produkt Owner, Entwicklungsteam, Scrum Master - Ziel: Überarbeitung und Priorisierung des Backlogs für zukünftige Sprints.
• Tag 17-20: - Tägliches Stand-Up Meeting: - Dauer: 15 Minuten - Teilnehmer: Entwicklungsteam - Ziel: Besprechung des Fortschritts und der Hindernisse.

Woche 4:

• Tag 21-24: - Tägliches Stand-Up Meeting: - Dauer: 15 Minuten - Teilnehmer: Entwicklungsteam - Ziel: Besprechung des Fortschritts und der Hindernisse.
• Tag 25: Sprint Review: - Dauer: 1-2 Stunden - Teilnehmer: Produkt Owner, Scrum Master, Entwicklungsteam, Stakeholder - Ziel: Präsentation der im Sprint erreichten Arbeit, Feedback von Stakeholdern.
• Tag 26: Sprint Retrospektive: - Dauer: 1-2 Stunden - Teilnehmer: Produkt Owner, Scrum Master, Entwicklungsteam - Ziel: Reflexion des Sprints, Besprechung dessen, was gut lief und was verbessert werden kann, Planung von Maßnahmen zur Optimierung zukünftiger Sprints.

Die Rollen und ihre Verantwortlichkeiten während dieses Sprints:

• Product Owner: - Verantwortlich für die Erstellung und Priorisierung des Product Backlogs. - Setzt klare Ziele und Anforderungen für den Sprint. - Nimmt an allen wichtigen Meetings teil, insbesondere der Sprint Planung, dem Sprint Review und der Retrospektive. - Fungiert als Bindeglied zwischen dem Entwicklungsteam und den Stakeholdern.
• Scrum Master: - Unterstützt das Team bei der Einhaltung der Scrum-Prinzipien und -Praktiken. - Moderiert Meetings und sorgt für eine effiziente Kommunikation. - Beseitigt Hindernisse, die das Entwicklungsteam beeinträchtigen. - Fördert eine Kultur der kontinuierlichen Verbesserung.
• Entwicklungsteam: - Führt die im Sprint Backlog geplanten Aufgaben aus und sorgt für die Erstellung des Produktinkrements. - Nimmt an täglichen Stand-Up Meetings teil, um den Fortschritt zu besprechen. - Arbeitet eng mit dem Product Owner und dem Scrum Master zusammen, um die Ziele des Sprints zu erreichen. - Nimmt aktiv an der Sprint Planung, dem Sprint Review und der Sprint Retrospektive teil.

c)

Im Laufe des Projekts stellt das Team fest, dass die Arbeitseffizienz aufgrund zu vieler paralleler Aufgaben leidet. Analysiere, wie Kanban in dieser Situation angewendet werden könnte, um den Workflow zu verbessern. Erläutere, wie WIP (Work in Progress) Limits gesetzt werden können und welche Vorteile sie für das Team haben könnten.

Lösung:

Anwendung von Kanban zur Verbesserung des Workflows:

Wenn das Team feststellt, dass die Arbeitseffizienz aufgrund zu vieler paralleler Aufgaben leidet, kann die Einführung von Kanban und der Einsatz von WIP (Work in Progress) Limits eine effektive Lösung sein.

Wie Kanban angewendet werden kann:

• Visualisierung des Workflows: Erstelle ein Kanban-Board, das die verschiedenen Phasen der Arbeit darstellt, z. B. 'Zu erledigen', 'In Arbeit', 'In Prüfung', 'Fertig'. Jedes Arbeitselement wird als Karte auf dem Board dargestellt.
• Analyse des aktuellen Workflows: Überwache den aktuellen Arbeitsfluss, um Engpässe und ineffiziente Bereiche zu identifizieren. Die Visualisierung hilft dem Team, ein gemeinsames Verständnis des Workflows zu entwickeln und Probleme sofort zu erkennen.
• Einführung von WIP (Work in Progress) Limits: Begrenze die Anzahl der Aufgaben, die gleichzeitig in jeder Phase bearbeitet werden.

Setzen von WIP (Work in Progress) Limits:

• Bestimmen der WIP Limits: Bestimme, wie viele Aufgaben das Team gleichzeitig in jeder Phase bearbeiten kann, ohne überlastet zu sein. Ein guter Ausgangspunkt kann die Analyse der bisherigen Durchschnittswerte sein. Für ein kleines Team könnte es sinnvoll sein, mit einem WIP Limit von 2-3 Aufgaben pro Phase zu beginnen und dieses bei Bedarf anzupassen.
• Kommunikation und gemeinsames Verständnis: Sorgen dafür, dass alle Teammitglieder die Bedeutung und den Zweck der WIP Limits verstehen und einverstanden sind. Eine klare Kommunikation ist entscheidend für die Akzeptanz und Einhaltung der Limits.
• Kontinuierliche Überprüfung und Anpassung: Überwache die Effektivität der WIP Limits regelmäßig. Das Team sollte bereit sein, die Limits anzupassen, falls erforderlich, um eine optimale Arbeitsumgebung zu gewährleisten.

Vorteile von WIP Limits für das Team:

• Verbesserte Fokussierung: Weniger parallele Aufgaben ermöglichen es dem Team, sich besser auf die jeweils aktuelle Arbeit zu konzentrieren, was die Qualität und Effizienz erhöht.
• Reduzierung von Engpässen: Durch das Begrenzen der gleichzeitigen Arbeiten in jeder Phase können Engpässe schneller identifiziert und behoben werden.
• Schnelleres Feedback: Ein schnellerer Fluss von Aufgaben durch die Phasen ermöglicht ein schnelleres Feedback und kürzere Reaktionszeiten auf Probleme.
• Erhöhte Transparenz: Das Kanban-Board und die WIP Limits bieten dem Team und den Stakeholdern eine klare Sicht auf den aktuellen Stand der Arbeit und die Auslastung des Teams.
• Kontinuierliche Verbesserung: Regelmäßige Überprüfung und Anpassung der WIP Limits fördern eine Kultur der kontinuierlichen Verbesserung und helfen dem Team, effizienter zu arbeiten.

Durch die Anwendung von Kanban und die Einführung von WIP Limits kann das Team seine Arbeit besser organisieren, die Effizienz steigern und den Workflow insgesamt verbessern.

Aufgabe 4)

In dieser Aufgabe geht es um den Vergleich und die Handhabung von Versionskontrollsystemen, insbesondere Git und SVN. Git ist ein verteiltes Versionskontrollsystem, bei dem jeder Entwickler eine vollständige Kopie des Repositories hat. SVN (Subversion) ist hingegen ein zentrales System, in dem das Repository auf einem Server gespeichert ist, und die Entwickler führen Checkouts auf ihre lokalen Maschinen durch. Du sollst das Wissen über die Unterschiede, die wichtigsten Befehle und einige spezifische Eigenschaften von Git und SVN anwenden.

a)

Erkläre den grundlegenden Unterschied zwischen einem verteilten Versionskontrollsystem (wie Git) und einem zentralisierten Versionskontrollsystem (wie SVN). Diskutiere dabei die Vor- und Nachteile der beiden Ansätze für die Teamarbeit.

Lösung:

• Verteiltes Versionskontrollsystem (DVCS) - Beispiel Git:
• Jeder Entwickler besitzt eine vollständige Kopie des gesamten Repositorys inklusive der kompletten Historie.
• Änderungen werden lokal durchgeführt und können später in ein zentrales Repository gepusht werden.
• Vorteile:
• Schnellere Operationen: Da die meisten Operationen (z.B. Commits, Branching, Merging) lokal durchgeführt werden, sind sie schneller.
• Unabhängiges Arbeiten: Entwickler können unabhängig voneinander arbeiten und ihre Änderungen später zusammenführen.
• Verbesserte Verfügbarkeit: Da jeder Entwickler eine vollständige Kopie des Repositorys hat, kann im Falle eines Serverausfalls weiterhin gearbeitet werden.
• Besseres Verzweigen und Zusammenführen (Branching und Merging): Diese Operationen sind in verteilten Systemen tendenziell einfacher und flexibler.
• Nachteile:
• Größerer Speicherbedarf: Da jeder Entwickler eine vollständige Kopie des Repositorys hat, wird mehr Speicherplatz benötigt.
• Komplexität: Der Umgang mit mehreren Repositories kann komplizierter sein, insbesondere für Anfänger.
• Zentralisiertes Versionskontrollsystem (CVCS) - Beispiel SVN:
• Das Repository befindet sich auf einem zentralen Server, und Entwickler führen Checkouts auf ihre lokalen Maschinen durch.
• Änderungen werden direkt am Server vorgenommen.
• Vorteile:
• Einfachheit: Für neue Benutzer ist das Konzept und der Arbeitsablauf oft einfacher zu verstehen.
• Wenig Speicherbedarf: Die lokalen Maschinen speichern nur die aktuell ausgecheckten Dateien und eventuell anstehende Änderungen, nicht die gesamte Historie.
• Zentrale Verwaltung: Da alle Änderungen auf einem zentralen Server durchgeführt werden, ist die Verwaltung oft einfacher.
• Nachteile:
• Einzelpunkt des Scheiterns: Wenn der zentrale Server ausfällt, können keine Änderungen durchgeführt werden.
• Langsamere Operationen: Da viele Operationen eine Kommunikation mit dem Server erfordern, können sie langsamer sein.
• Abhängigkeit vom Netzwerk: Ohne Netzwerkverbindung kann oft nicht gearbeitet werden.
• Eingeschränktes paralleles Arbeiten: Im Vergleich zu verteilten Systemen kann das parallele Arbeiten und das Zusammenführen von Änderungen komplizierter sein.

b)

Ein Entwicklerteam benutzt Git für die gemeinsame Entwicklung eines Projekts. Beschreibe den Workflow, der um die Befehle

git init

,

git clone

,

git add

,

git commit

,

git push

,

git pull

herum aufgebaut ist. Erkläre, wie Änderungen im Quellcode zwischen verschiedenen Entwicklern synchronisiert werden.

Lösung:

• Workflow und Verwendung der Git-Befehle:

• git init

• Dieser Befehl wird verwendet, um ein neues Git-Repository in einem bestehenden Verzeichnis zu initialisieren. Ein Entwickler verwendet

  git init

  , um den Quellcode in ein neues Git-Repository zu verwandeln. Es erstellt ein verstecktes .git-Verzeichnis, das alle Informationen zum Versionsverlauf des Projekts enthält.

• git clone

• Mit diesem Befehl wird ein bereits bestehendes Repository geklont, also kopiert. Ein Entwickler, der dem Projekt beitreten möchte, verwendet

  git clone

  , um das Remote-Repository (üblicherweise auf einem Online-Dienst wie GitHub oder GitLab) auf seinen lokalen Rechner zu kopieren. Dadurch erhält er eine vollständige Kopie des gesamten Repositorys inklusive der gesamten Historie.

• git add

• Mit

  git add

  werden Änderungen in der Arbeitskopie (neue oder geänderte Dateien) zur Aufnahme in den nächsten Commit markiert. Es informiert Git darüber, dass diese Dateien in den Versionsverlauf aufgenommen werden sollen. Zum Beispiel,

  git add datei.txt

  fügt die Datei datei.txt hinzu.

• git commit

• Mit

  git commit

  werden alle Änderungen, die mit

  git add

  markiert wurden, in die lokale Historie übernommen. Jede Übernahme erhält eine eindeutige ID und wird mit einer Beschreibung (Commit-Message) versehen. Der Befehl

  git commit -m 'Nachricht'

  erstellt z.B. einen neuen Commit mit der Nachricht Nachricht.

• git push

• Dieser Befehl wird verwendet, um die lokalen Änderungen in das Remote-Repository zu übertragen. Mit

  git push

  werden die neuesten Commits und Änderungen von der lokalen Kopie auf den Server übertragen. Dadurch werden die Änderungen anderen Mitgliedern des Teams zur Verfügung gestellt.

• git pull

• Dieser Befehl holt und integriert Änderungen vom Remote-Repository in die lokale Kopie. Mit

  git pull

  lädt ein Entwickler die neuesten Änderungen, die von anderen Teammitgliedern gepusht wurden, und kombiniert sie mit seiner eigenen Arbeitskopie. Es führt einen

  git fetch

  und einen

  git merge

  in einem Schritt aus.
• Synchronisation von Änderungen:
• Initiales Setup: Ein Entwickler startet das Projekt mit

  git init

  , erstellt die initialen Dateien, führt

  git add

  und

  git commit

  aus und pusht dann das erste Commit mit

  git push

  zu einem Remote-Repository.
• Beitritt zum Projekt: Andere Entwickler klonen das Repository mit

  git clone

  , um eine lokale Kopie des Projekts zu erhalten.
• Lokal arbeiten: Jeder Entwickler erstellt neue Dateien oder bearbeitet bestehende Dateien und verwendet

  git add

  , um Änderungen für den nächsten Commit vorzubereiten. Die Änderungen werden mit

  git commit

  in die lokale Historie aufgenommen.
• Änderungen teilen: Nach dem Commit kann ein Entwickler seine Änderungen mit

  git push

  zum zentralen Repository hochladen, wo die anderen Teammitglieder die Änderungen sehen können.
• Aktuelle Version holen: Entwickler ziehen regelmäßig neue Änderungen mit

  git pull

  vom Remote-Repository, um ihre lokale Kopie auf dem neuesten Stand zu halten und Konflikte zu vermeiden.
• Konfliktlösung: Sollten während eines

  git pull

  Konflikte auftreten, müssen diese manuell gelöst werden. Git unterstützt hier mit Meldungen und Werkzeugen zur Konfliktlösung.

c)

In einem weiteren Beispiel benutzt ein anderes Team SVN. Die Teammitglieder haben Änderungen an denselben Dateien vorgenommen und möchten nun diese Änderungen in das zentrale Repository einpflegen. Beschreibe den Workflow für diesen Vorgang unter Berücksichtigung der Befehle

svn checkout

,

svn update

und

svn commit

. Erläutere, wie Konflikte im Quellcode gelöst werden können, wenn zum Beispiel mehrere Entwickler parallel an derselben Datei gearbeitet haben.

Lösung:

• Workflow und Verwendung der SVN-Befehle:

• svn checkout

• Mit diesem Befehl wird eine Arbeitskopie (Working Copy) des Projekts vom zentralen Repository auf die lokale Maschine des Entwicklers erstellt. Dies entspricht dem Klonen eines Repositories in Git. Beispielsweise wird mit

  svn checkout https://svn.example.com/repo/project

  eine lokale Kopie des Projekts erstellt.

• svn update

• Mit

  svn update

  werden alle neuesten Änderungen vom zentralen Repository zur lokalen Arbeitskopie heruntergeladen und integriert. Entwickler verwenden diesen Befehl regelmäßig, um sicherzustellen, dass sie auf dem neuesten Stand sind und mögliche Konflikte frühzeitig erkennen. Beispielsweise wird mit

  svn update

  die lokale Arbeitskopie mit den neuesten Änderungen synchronisiert.

• svn commit

• Mit

  svn commit

  werden die Änderungen der lokalen Arbeitskopie in das zentrale Repository hochgeladen. Es erstellt einen neuen Revisionseintrag im zentralen Repository und überträgt die Änderungen. Der Befehl

  svn commit -m 'Nachricht'

  fügt die Änderung mit einem Kommentar Nachricht hinzu.
• Änderungen einpflegen und Konfliktlösung:
• Initiales Setup: Ein Entwickler verwendet

  svn checkout

  , um eine Arbeitskopie des zentralen Repositorys zu erhalten.
• Regelmäßige Updates: Entwickler führen regelmäßig

  svn update

  aus, um sicherzustellen, dass ihre lokale Arbeitskopie die neuesten Änderungen von anderen Entwicklern enthält.
• Anpassungen und Commits: Nachdem ein Entwickler Änderungen vorgenommen hat, verwendet er

  svn commit

  , um die Änderungen zum zentralen Repository zu übertragen.
• Konfliktentstehung: Wenn zwei oder mehr Entwickler Änderungen an denselben Dateien vorgenommen haben, kann es beim nächsten

  svn update

  oder

  svn commit

  zu Konflikten kommen. SVN merkt dies und informiert den Entwickler über die Konflikte.
• Konfliktlösung: Entwickler müssen die Konflikte manuell lösen:
• Während eines

  svn update

  markiert SVN die konfliktbehafteten Dateien und erstellt temporäre Dateien (z.B. .mine, .r1, .r2) zur Unterstützung bei der Konfliktlösung.
• Der Entwickler öffnet die betroffenen Dateien und prüft die Änderungen. Er verwendet ein Merge-Tool oder löst die Konflikte manuell, indem er die korrekte Version der Zeilen auswählt und die anderen Versionen verwirft.
• Nach der Behebung der Konflikte wird die Datei mit

  svn resolve --accept working 

  als Korrektur markiert, was bedeutet, dass der Konflikt gelöst wurde.
• Anschließend wird

  svn commit

  verwendet, um die bereinigten Änderungen ins zentrale Repository hochzuladen.
• Kommunikation: Ein wichtiger Aspekt der Konfliktlösung in SVN ist die Kommunikation zwischen den Teammitgliedern. Entwickler sollten regelmäßig miteinander kommunizieren, um das Entstehen von Konflikten zu minimieren und um sicherzustellen, dass alle Mitglieder auf dem Laufenden sind.