Grundlagen für die Mini-Team-Projekte

1. Überblick

Als Abschluss der erste 2 Jahre Programmier-Ausbildung soll in Mini-Teams (2 bis max. 4 Mitglieder) eine JavaFX-App entwickelt werden, die Gelegenheit gibt, das Gelernte für eine interessante Thematik "Auf die Straße" zu bringen - es sollte ein funktionsfähiges Produkt entstehen (nicht marktreif, aber für die "Väter" schon nutzbar und präsentierbar). Das noch zu ergänzende Wissen wird dabei eher aus Eigenmotivation beschafft - auch (aber nicht hauptsächlich) über den Lehrer. Damit wird das Lernen von Prüfungsorientierung auf Umsetzungsorientierung verschoben, was dem Lernen im "echten Leben" (Beruf, Hobbies, etc.) recht nahe kommen sollte. Neben den technischen Aspekten sollten auch Team-Arbeit, Infrastruktur, Dokumentation und verschiedener andere Aspekte bewältigt, erlebt und bewusst gemacht werden. Auch die diesbezüglichen Hindernisse und Pannen sollen wahrgenommen werden. Das Projekt wird mit einer Präsentation abgeschlossen. Diese sollte im Wesentlichen folgende Bereiche umfassen:

  • Team-Mitglieder und Arbeitsaufteilung

  • Ursprüngliche Projekt-Idee

  • kurzer Überblick zum Themenfeld, um den Zweck und Einsatzbereich klarzumachen

  • Tatsächlich umgesetzte Applikation, Hinweise zu den Abweichungen/Änderungen

  • Oranisatorische Erfahrungen (auch die Schwierigkeiten, was ist woran gescheitert, etc.)

  • Technische Erfahrungen (Java, JavaFX, Tools, genutzte Open-Source-Libraries, etc.)

  • Vorführung der App

  • Eventuelle Pläne zur privaten Weiterarbeit daran u.ä.

2. Projekt-Idee formulieren

Bei Projekten in größeren Strukturen sind mehrere Schritte zu durchlaufen: Projektidee, Projekt-Entwurf, Proposal/Projektvorschlag, …​) Der Zweck eines Proposals ist üblicherweise der, einen potentiellen Abnehmer/Financier zu informieren und zu gewinnen. Bei uns geht es eher um die Ideenfindung und Einigung im Team sowie Abstimmung mit den Lehrern - also mindestens eine Stufe davor - Zusammenstellung der Projektidee. Das zu erstellende Dokument sollte einen Umfang ca. 1-3 Seiten mit Skizze(n) haben folgende Bereiche enthalten:

  • Team-Mitglieder

  • Erste Überlegung Aufgabenteilung

  • Themenfeld, in dem die App "angesiedelt" ist

  • Funktionalität für das Themenfeld/Themengebiet - Überblick

  • Detailliertere Funktionalität, sodass die Komplexität ein bisschen abschätzbar wird

  • Skizze UI mit Hinweisen zur Interaktion

  • Erster Zeitplan (SEHR wichtig, wir haben durch den Schuljahres-Verlauf ca. 6 Wochen Zeit)

  • Risken - was kann schiefgehen: technische, organisatorische, aufwandsmäßige, sonstige Hürden (normalerweise müsste hier auch der Markt, Mitbewerb, etc behandelt werden)

Hinweis: Layout ist nicht wichtig, sollte aber vernünftig lesbar und verstehbar sein. Siehe auch "Tools" (nachstrehend)

3. Tools

Damit durch die betreuenden Lehrer Support halbwegs effizient möglich wird, müssen wir einige Standards definieren. Hier ein erster Entwurf (müssen wir je nach Bedarf und Möglichkeiten vielleicht anpassen):

Bitte nur (OpenSource)-Tools verwenden, die auf Windows, Linux und Mac lauffähig sind - zumindest die Dokumente müssen auf diesen Plattformen mit OpenSource Tools voll bearbeitbar sein.

  • Office-Dokumente müssen auch unter LibreOffice verwend+bearbeitbar sein

  • Alternativ kann verwendet werden: HTML, Markdown (wie in GitLab, GitHub etc. verwendet), AsciiDoc (für komplexere technische Dokumentation geeignet - wird für Mini-Anleitung verwendet)

  • Graphiken, Diagramme, Skizzen sollten wenn möglich entweder als Vektorgrafik (z.B. SVG) oder per textueller Definition vorliegen (z.B. PlantUML - einfaches Diagramm-Erstellung aus Text — https://plantuml.com/de/ und dort referenzierte weitere). Damit bleiben sie weiterhin leicht adaptierbar. Verwendbar sind z.B. Inkscape — https://inkscape.org/de/ oder die spezialisierte GUI-Prototyping App (Pencil Home - Pencil Project — http://pencil.evolus.vn/)

  • Jedes Team muss alle Dokumente in GIT/GitLab verwalten - wir werden für jedes Projekt ein extra Repository anlegen, in dem alle jeweiligen Team-Mitglieder und die betreuenden Lehrer Zugriff haben - damit wird die Home-Office-Arbeitsweise und die Unterstützung durch die betreuenden Lehrer vernünftig funktionsfähig.

  • Als IDE können Eclipse, IntelliJ und VS-Code verwendet werden.

4. Projekt-Ablauf

4.1. Wichtig:

  • Team sollte vom Wissens- und Motivationsstand halbwegs harmonieren. Es ist unbedingt GIT/GitLab zu verwenden, häufig Commits zu machen (vom jeweiligen Autor, um Nachvollziehbarkeit zu ermöglichen)

  • Alles, was ausgemacht wird, muss schriftlich festgehalten werden (im Repository!), um für jeden klar zu sein und um Nachsehen zu können, nichts zu vergessen etc.

4.2. Ablauf und Hinweise:

  • Team-Findung und Projektidee definieren (Reihenfolge unterschiedlich)

  • Anlegen eines Projekt-Repositories durch Lehrer (oder abgestimmte Vorgehensweise) und committen der Projektidee-Dokumente

  • Abstimmung mit Lehrer (Projektidee-Dokument, Besprechung, u.U. Überarbeitung)

  • Technisches Design (Funktionalitäten, Packages, wichtige Klassen, etc.)

  • Gliederung des Projekts in kleinere Arbeitseinheiten und Überlegung/Klärung, wie diese zusammenhängigen (was wird von anderen Arbeitseinheiten wann benötigt, was dauert wie lange, etc.)

  • Aufteilung der zeitlich ersten Abeitsschritte (wichtig)

  • Vereinbarung, wann - was - wer erledigt haben sollte (besonders wichtig für Dinge, von denen andere Arbeiten stark abhängen)

  • Vereinbarung der Kommunikation - Medien, Meetings, Dokumente

  • Rascher Start der technischen Umsetzung

  • Häufige Fortschritts-Abstimmung mit Dokumentation von Erledigtem und nächsten ToDos samt Dringlichkeit

  • Nach ersten Erfahrungen u.U. Anpassung der Projektidee (Abstimmung mit Lehrer) oder Umsetzung, Festlegung der weiteren Aufteilung und Terminisierung

  • Auch informelle Kooperation zwischen Team-Mitgliedern (Wichtiges für alle dokumentieren)

  • Team-Mitglieder, Lehrer, Internet-Foren, etc. bei Problemen fragen

  • Präsentation und Präsentierbarkeit planen

  • Häufiges Refactoring zur Verbesserung der Strukturen, Benennungen, etc. - aber ABGESTIMMT, da es mehrere Team-Mitglieder betreffen könnte

  • Häufige Commits mit sinnvollen Messages

  • Nutzung des Issues-Systems und des Wikis in GitLab für Kooperation

4.3. Rollen im Projekt

Hier als Nachdenk-Hilfe eine Aufstellung, welche Rollen während einzunehmen sind. Manche werden fix einer Person zuteilbar sein, andere müssen von mehreren Team-Mitgliedern immer wieder eingenommen werden. Es geht darum, dass man diese Rollen (und möglicherweise weitere) im Team als existent wahrnimmt und in den Aufwandsüberlegungen berücksichtigt.

  • Funktionalitäts-Designer (Was soll die App "können" - grobe Formulierung, Kontrolle, ob Richtung beibehalten wird, ggf. koordinierte Richtungs-Korrektur)

  • Koordinator - zuständig für Termine, Milestones, Abhängigkeiten, kritische Pfade, Aufwands/Kosten-Logging, Termin-Prognosen

  • Kommunikator Extern - zuständig für die Präsentation nach außen - ggü. Lehrer, Mitschülern, etc.

  • Dokumentator - Zuständig für team-interne (und auch externe) Dokumentation - welche Schnittstellen, Aktualität von Versionen, etc.

  • Wissens-Manager Themengebiet - zuständig für Themengebiets-Details (z.B. was ist "Body Mass Index", Definition, Darstellung, etc.)

  • Wissens-Manager Technik - zuständig für KnowHow GIT, Eclipse, Java, JavaFX, in Koop mit Dokumentator: Linksammlung mit Kommentaren in GitLab-Projekt-Wiki, etc.

  • Sysadmin (Infrastruktur-Pflege, Ansprechstelle bei Software-Problemen, GIT/GitLab, Eclipse, sonstige Tools, …​)

  • GUI Layout- und Interaktions-Designer

  • Software-Designer (Packages, Klassen, Interfaces f. Engine ind GUI)

  • Test-Verantwortlicher (Überblick Testen als Konzept, Sicherstellung, dass v.a. für Engine Tests verfügbar und dass sie regelmäßig laufen)

  • Styling-Developer

  • GUI-Developer

  • GUI/Engine Interface Developer

  • Engine-Developer

  • Storage-Developer (Dateiformate, DB-Struktur, Low-Level Zugriff auf Storage, etc.) Wichtig, all diese Blickwinkel periodisch einnehmen und Abstimmung über Projekt-Zustand machen, um Probleme, nötige Anpassungen etc. frühzeitig anzugehen (VIEL effizienter als spät)

5. Zeitplan und Beurteilung

Das Mini-Projekt wird neben den Abgaben ein wesentliches "Standbein" der Benotung bilden. Deswegen ist es nötig, dass Zuständigkeiten und faktische Arbeit der einzelnen Team-Mitglieder nachvollziehbar ist. Wir müssen aus jetziger Einschätzung (Corona …​) ca. Mitte Juni ein brauchbares Ergebnis haben und es muss eine halbwegs kontinuierliche Arbeit während dieser Zeit erfolgen - am "zu-lange-Aufschieben" und mangelnder Organsisation scheitern VIELE Schüler-Projekte (und an ähnlichen Problemen auch "echte")