Entwicklungsprojekt

Die Studierenden sollen vertiefende Kenntnisse in die Methoden und Techniken aus einem ausgewählten Modul aus den ersten vier Fachsemestern des Studiums erlangen und diese in der Konzeption und prototypischen Realisierung eines interaktiven Systems oder Mediums anwenden. Dadurch sollen sie eigene Erfahrungen in der Projektabwicklung mit Medieninformatik-spezifischen Fragestellungen und in der Teamarbeit sammeln und eine reflektierend-kritische Haltung zu methodischen Ansätzen und Entwicklungsmodellen entwickeln. Ziel ist es eine, mit eigenen praktischen Erfahrungen fundierte Methodenkompetenz zu erlangen.

Ablauf

Step 1: Perspektive und Thema finden/auswählen

Viele Studierende setzen im Entwicklungsprojekt die Perspektive ihres Vertiefungsmoduls (Social Computing, Visual Computing, Web-Development) fort. Das ist völlig in Ordnung und sinnvoll. Es können aber auch andere Perspektiven gewählt werden. Mensch-Computer-Interaktion ist ein zentraler Bestandteil der Medieninformatik, jedoch bieten wir dazu kein Vertiefungsmodul an. Die MCI-Perspektive ist im Entwicklungsprojekt absolut erwünscht. Aktuell haben wir für folgende Perspektiven Betreuungsteams: Mensch-Computer-Interaktion, Social Computing, Visual Computing und Web-Development.

Die Spielregeln in den einzelenen Perpektiven und Betreuungsteams sind ähnlich, aber nicht gleich. Informieren Sie sich daher bei den Betreuungsteams.

In der Perspektive Web-Development können Sie ein eigenes Thema vorschlagen oder das vorgeschlagene Szenario als Ausgangspunkt nehmen. In beiden Fällen muss das Thema ausgearbeitet und sorgfältig projektiert werden. Verfassen Sie für ihr Projekt ein Exposé. Dazu finden Sie ausführliche Informationen im Modulwiki innerhalb des ILU Kurses zum Modul. Stimmen Sie ihr Exposé unbedingt in den Open Spaces mit ihrem Betreuer Team ab.

Audit 1 – Problemraum begreifen

Im ersten Audit möchte wir weder Code noch Designs sehen und besprechen. Stattdessen wollen wir sehen, wie gut und sorgfältig Sie die Domäne durchdrungen, das Problem verstanden, mögliche Risiken erkannt, im Markt recherchiert und mögliche Lösungsstrategien entwickelt haben.

Anders als im ILU beschrieben, möchte ich bis spätestens Freitag, 08:30 Uhr, vor dem jeweiligen Audit einen maximal 10-minütigen Film mit dem aktuellen Stand Ihrer Arbeit erhalten. Den Upload-Link finden Sie im ILU. Außerdem möchte ich keine kommentierte Präsentation, sondern eine Markdown-Datei in Ihrem Repository. Verlinken Sie die Datei in Ihrer README.

Audit 2 - Risiken ausschließen, erste Teillösungen entwicklen

Im zweiten Audit möchten wir erste Teillösungen auf Code- und Designebene sehen. Wir wollen erkennen, wie gut die Projektrisiken weiterentwickelt, konkretisiert und mit Proof-of-Concepts abgesichert wurden. Wir möchten Einblicke in Ihre Architektur und Ihr Design- und Interaktionskonzept erhalten. Zeigen Sie im Film zum Audit, was und warum Sie modelliert haben (z.B. Daten, Domäne, Interaktion, Design) haben.

Audit 3 – Prototyp

Im dritten Audit wollen wir die erste Version ihres Prototyps besprechen. Zeigen Sie im Film zum Audit, wie und warum Sie die verschiedenen Modelle (z.B. Daten, Domäne, Interaktion, Design) weiterentwickelt und angepasst haben. Stellen Sie ihre Anwendungslogik vor und begründen Sie diese.

Audit 4 – Projektabschluss

Das letzte Audit besteht aus zwei Teilen. Teil 1 ist die Vorstellung des Projekts im Plenum anhand des Posters. Teil 2 umfasst die Präsentation des Prototyps und die Besprechung des zugehörigen Codes in der Perspektivgruppe. Demonstrieren Sie Ihren funktionalen Prototypen und erläutern Sie die Implementierung der wichtigsten Konzepte. Es folgt eine kurze Codeinspektion des Prototyps über das Repository. Abschließend ziehen Sie ein Fazit und reflektieren Sie kritisch den gesamten Projektprozess im Vergleich zur ursprünglichen Zielsetzung. Zeigen Sie im Audit-Video, wie der Prototyp auf die User Stories einzahlt.

Wissenswertes

Audits

Die Audits «meiner» Teams finden immer vor Ort und immer in der gesamten Perspektivgruppe statt. Allozieren Sie daher bitte ausreichend Zeit und Geduld für diese Termine.

Architecture Decision Records

Nutzen Sie für ihre (technischen) Entscheidungen Architecture Decision Records. ADRs (Architecture Decision Records) sind dokumentierte Architekturentscheidungen, die während der Entwicklung eines Softwareprojekts getroffen werden. Sie bieten eine strukturierte Möglichkeit, Entscheidungen festzuhalten, die sich auf die Architektur und das Design eines Systems auswirken.

Ein ADR beschreibt, welche Entscheidung getroffen wurde, warum sie getroffen wurde und welche Alternativen in Betracht gezogen wurden. Das Ziel ist, nachvollziehbar zu machen, wie und warum bestimmte (technische) Entscheidungen zu einem bestimmten Zeitpunkt sinnvoll waren. Dies hilft nicht nur aktuellen Teammitgliedern, sondern auch zukünftigen Entwicklern, die Entscheidungen zu verstehen und gegebenenfalls zu überdenken.

Typische Elemente eines ADR:

• Titel der Entscheidung
• Kontext (Problemstellung)
• Entscheidung (Was wurde entschieden?)
• Alternativen (Welche Optionen wurden geprüft?)
• Begründung (Warum wurde diese Entscheidung getroffen?)
• Konsequenzen (Welche Auswirkungen hat die Entscheidung?)

Ein Template für ADRs finden Sie hier: ADR Template

Das ist eine gute Grundlage, um eine konsistente und vollständige Dokumentation von Architekturentscheidungen sicherzustellen.

Hier ein paar Beispiele auf dem Master Beiboot Projkt:

• Video Procssing
• SvelteKit als Static Site Generator
• Deployment und Hosting
• Frontend Tooling - Vite

Backlogs

Nutzen Sie Backlogs für Ihre Tasks, User Stories und Issues. Ein Backlog ist eine priorisierte Liste von Aufgaben, Anforderungen oder Features, die in einem Projekt erledigt werden müssen. In agilen Projekten dient das Backlog als zentrale Sammelstelle für alle gewünschten Änderungen und neuen Funktionen. Es gibt zwei Hauptarten von Backlogs:

• Product Backlog: Enthält alle User Stories, Features und Anforderungen für das gesamte Produkt.
• Sprint Backlog: Umfasst die spezifischen Aufgaben und User Stories, die in einem bestimmten Sprint (Zeitfenster für die Entwicklung) bearbeitet werden.

Das Backlog wird kontinuierlich gepflegt und priorisiert, um sicherzustellen, dass das Team an den wichtigsten und wertvollsten Aufgaben arbeitet. Es wird in der Regel vom Product Owner verwaltet und dient als Leitfaden für die Entwicklungsarbeit.

Ein Infovideo zum Erstellen von einem Backlog finden Sie hier: Building your backlog with Projects

Sprintplanung

Sprintplanung ist ein zentrales Meeting im agilen Projektmanagement, das zu Beginn eines jeden Sprints (kurzer, zeitlich begrenzter Entwicklungszyklus) stattfindet. Ziel der Sprintplanung ist es, festzulegen, welche Aufgaben und User Stories im kommenden Sprint umgesetzt werden sollen. Das Team bewertet die Komplexität und den Arbeitsaufwand der Aufgaben und entscheidet gemeinsam, was realistisch in der festgelegten Sprintdauer (oft 1-4 Wochen) abgeschlossen werden kann.

Wichtige Schritte der Sprintplanung:

1. Ziele des Sprints festlegen: Welche funktionalen Ziele sollen erreicht werden?
2. Auswahl von Aufgaben/User Stories: Der Product Owner priorisiert Aufgaben aus dem Backlog, das Team wählt Aufgaben basierend auf der eigenen Kapazität.
3. Schätzung des Arbeitsaufwands: Aufgaben werden in ihrer Komplexität geschätzt (z.B. durch Story Points oder Schätzung in Stunden).
4. Verteilung der Aufgaben: Teammitglieder übernehmen konkrete Aufgaben zur Umsetzung.

Die Sprintplanung sorgt dafür, dass das Team fokussiert und effizient an den wichtigsten Features arbeitet.

Ein hilfreicher Link zur Sprintplanung: Atlassian Sprint Planning Guide

Dieser Guide bietet praktische Anleitungen zur effektiven Durchführung der Sprintplanung.

User Stories

Verfassen Sie User Stories für ihr Projekt. User Stories sind kurze, einfache Beschreibungen einer Funktion oder eines Features aus der Perspektive des Endbenutzers. Sie werden in agilen Projekten verwendet, um die Anforderungen eines Systems zu definieren. Eine User Story ist in der Regel in einer bestimmten Struktur formuliert:

Als [Nutzerrolle] möchte ich [Ziel], um [Nutzen] zu erreichen.

User Stories sind hilfreich, um die Bedürfnisse der Benutzer zu verstehen und den Fokus auf die Wertschöpfung zu legen. Sie sind oft bewusst kurz gehalten, um Raum für Diskussionen und Details während der Entwicklung zu lassen.

Beispiel:

Als Benutzer möchte ich mich mit meinem Google-Account anmelden, um schnell auf mein Konto zugreifen zu können.

Typische Elemente einer User Story:

• Nutzerrolle (Wer nutzt die Funktion?)
• Ziel (Was soll erreicht werden?)
• Nutzen (Warum ist das wichtig?)

Ein Template für User Stories finden Sie hier: User Story Template

Das Template hilft, strukturierte und zielgerichtete User Stories zu erstellen.

Open Spaces

Ich erwarte Anwesenheit in den Open Spaces. Diese finden hybrid statt und starten immer um 13:00 Uhr.

Open Spaces sind offene, informelle Meetings, bei denen die Teilnehmer die Themen, Diskussionen und Aktivitäten selbst festlegen. In Projekten bieten sie eine Plattform, um spezifische Themen zu besprechen, neue Ideen zu entwickeln oder Herausforderungen zu diskutieren. Open Spaces sind besonders flexibel, weil sie es den Teilnehmern ermöglichen, sich aktiv an den Themen zu beteiligen, die für sie am relevantesten sind.

In einem Projektkontext, insbesondere in agilen Entwicklungsprozessen, sind Open Spaces besonders wertvoll, weil sie Raum für spontanen Austausch und Feedback bieten. Hier können die Teams ihre Arbeit, Probleme oder Fragen direkt mit den Betreuern und anderen Beteiligten besprechen. Das Feedback der Betreuer ist entscheidend, um frühzeitig Verbesserungspotenziale zu identifizieren und sicherzustellen, dass das Projekt den Erwartungen entspricht. Die Offenheit des Formats fördert zudem den Wissensaustausch und ermöglicht es den Teams, Lösungen zu finden oder neue Ansätze zu diskutieren.

Für das Projekt sind Open Spaces daher besonders wichtig, da die Möglichkeit besteht, zeitnah konstruktives Feedback von den Betreuern einzuholen, was wiederum hilft, das Projekt besser zu steuern und mögliche Fehler frühzeitig zu erkennen und zu beheben.

Projektplan

Der Projektplan ist ein wichtiger Bestandteil eines Entwicklungsprojekts, der die gesamte Planung und Strukturierung der Arbeit beschreibt. Er dient dazu, die wichtigsten Phasen, Aufgaben und Meilensteine des Projekts zu definieren und zu koordinieren. Der Plan umfasst in der Regel:

1. Ziele: Klare Definition dessen, was das Projekt erreichen soll.
2. Meilensteine: Wichtige Etappenziele, die während des Projekts erreicht werden müssen.
3. Zeitplan: Eine zeitliche Übersicht, wann welche Aufgaben erledigt werden sollen.
4. Ressourcen: Verteilung von Personal, technischen Mitteln oder anderen notwendigen Ressourcen.
5. Rollen und Verantwortlichkeiten: Wer ist für welche Aufgaben verantwortlich?
6. Risikomanagement: Mögliche Projektrisiken und Strategien, um diese zu minimieren.

Der Projektplan in GitHub kann durch verschiedene Tools und Funktionen unterstützt und abgebildet werden, wie:

• Issues: Dienen zur Erfassung einzelner Aufgaben oder User Stories. Diese können priorisiert und mit Fristen versehen werden.
• Milestones: Mit GitHub-Milestones können große, zentrale Projektetappen abgebildet werden. Sie geben einen Überblick darüber, welche Issues erledigt werden müssen, um einen bestimmten Meilenstein zu erreichen.
• Project Boards: GitHub bietet Kanban-Boards, die es ermöglichen, den Projektverlauf visuell darzustellen. Hier können Aufgaben in verschiedene Phasen unterteilt werden (z.B. „To Do“, „In Progress“, „Done“).
• Pull Requests: Diese helfen, den Fortschritt einzelner Aufgaben in Bezug auf den Code zu verfolgen und sicherzustellen, dass die Implementierung den Projektanforderungen entspricht.

Durch die Abbildung des Projektplans in GitHub wird der Fortschritt für alle Teammitglieder transparent. Es erleichtert die Zusammenarbeit, das Tracking des Projektfortschritts und die Anpassung von Prioritäten bei Bedarf.

Perspektiv Gruppe

Die Perspektivgruppe umfasst alle Teams der Perspektive «Web Development». Die Bedeutung der Perspektivgruppe liegt in der fachlichen Vertiefung und dem Feedback: Innerhalb dieser Gruppe findet der fachspezifische Austausch statt, wo die Projektteams ihre Entwürfe, Prototypen und Konzepte besprechen und das Feedback der Gruppe sowie der Betreuer erhalten. Dies ermöglicht es, fokusiert Feedback zu spezifischen Themenbereichen einzuholen und sicherzustellen, dass die entwickelten Lösungen die relevanten Anforderungen der jeweiligen Disziplin erfüllen.