Update 2024 10 30
@@ -18,33 +18,113 @@ title: '2024-10-30'
|
|||||||
| SM | Kelvi Awuklu, Jesko Dalmu |
|
| SM | Kelvi Awuklu, Jesko Dalmu |
|
||||||
|
|
||||||
## Ordnungspunkte
|
## Ordnungspunkte
|
||||||
|
1. Ankündigungen und Anmerkungen
|
||||||
|
2. Bericht des PO
|
||||||
|
3. Rückfragen und Aufgaben zum nächsten Termin
|
||||||
|
|
||||||
### 1. Ankündigungen
|
### 1. Ankündigungen und Anmerkungen
|
||||||
|
|
||||||
-
|
- Zukünftig in den Protokollen nur die für das eigene Team zugehörigen Informationen dokumentieren und festhalten.
|
||||||
|
- Hierzu zählen ebenfalls Punkte, die auf alle zutreffen, z.B. Organisatorisches, wichtige Regelungen, Feedback oder allgemeine Ankündigungen.
|
||||||
|
- Alle Anhänge in den Protokollen wie PO-Berichte etc. als PDF-Dateien einbinden, da dies einheitlich ist und außerdem so die Möglichkeit der nachträglichen Manipulation erschwert wird.
|
||||||
|
- Ordnungspunkte (Grundstruktur) gliedern sich nahezu immer in die drei Abschnitte: 1) Ankündigungen/Anmerkungen (mit Anwesenheitskontrolle), 2) PO-Bericht mit anschließendem Feedback sowie 3) Rückfragen und Aufgaben-/Schwerpunktbesprechung zu nächster Woche.
|
||||||
|
- Ergebnisübersicht mit Action List dagegen entsprechend dem Inhalt der Sitzung festhalten.
|
||||||
|
- Inhaltspunkte der PO Präsentation nicht in die Protokolle aufnehmen (identischer Aufbau), sondern sich auf Feedback und Anmerkungen zum weiteren Vorgehen konzentrieren.
|
||||||
|
|
||||||
### 2. Bericht des PO
|
### 2. Bericht des PO
|
||||||
|
|
||||||
-
|
- In der Requirement-Engineering-Phase nicht zu viel Entwickeln, sondern erst Anforderungen festlegen und diese genau ausarbeiten und dokumentieren; Reihenfolge beachten.
|
||||||
|
- Zunächst Backlog und Anforderungen aufstellen und konkrete Ziele und Requirements festlegen.
|
||||||
|
- Diese dann detailliert ausarbeiten (Funktionalitäten, Features etc.) und auf diese Weise User Stories in korrekter Form darstellen; dabei alle notwendigen Requirements abdecken und definieren.
|
||||||
|
- Dann erst Punkte nach zuvor klar festgelegten und aufgeteilten Anforderungsfällen abarbeiten (Implementierung).
|
||||||
|
- Ist hier jedoch ein fließender Übergang und nicht vollkommen strikt in diese zwei verschiedenen, aufeinanderfolgenden Phasen aufgeteilt.
|
||||||
|
- Es ist trotzdem sehr wichtig und langfristig notwendig und sinnvoll, sich an diese Reihenfolge zu halten und viel Zeit/Mühe in die Anforderungsanalyse und deren Umsetzungsweise zu investieren.
|
||||||
|
- Danach erst Entwicklung starten (kleinere Ausnahmen im angemessenen Rahmen gestattet).
|
||||||
|
- User Stories: Fokus auf Anwender legen, deren Probleme/Ziele erkennen, diese herausarbeiten und in entsprechenden Features und Funktionalitäten definieren und umsetzen; Akzeptanzkriterien sind wichtig.
|
||||||
|
- Ergebnisse weiter ausbauen, strukturieren und in GitLab tracken.
|
||||||
|
|
||||||
### 3. Rückfragen und Aufgaben zum nächsten Termin
|
### 3. Rückfragen und Aufgaben zum nächsten Termin
|
||||||
|
|
||||||
-
|
- Stunden/Zeitmanagement der Arbeitspakete einschätzen und tracken.
|
||||||
|
- Kein Material steht zur Verfügung: Dummyfiles und eigene Texte notwendig; konkrete Umsetzung und Formatierung der Erklärungstexte ist freigestellt, solange es die Anforderungen erfüllt.
|
||||||
|
- Das Gleiche gilt für die Verwendung richtiger Bilder, oder nur Schablonen für Bilder.
|
||||||
|
- Produkt aus dem Angebot der Pitchvorstellung muss bis zum Novembertermin abgegeben werden. Dafür zählen die festgelegten Requirements (aus Anschreiben sowie den weiteren Gesprächen).
|
||||||
|
- Danach startet der agile Teil mit ggf. neuen, spontanen Kundenwünschen.
|
||||||
|
- Nutzen von KI erlaubt (z.B. Textgenerierung Projektumsetzung)? Gestattet, Fokus liegt auf dem Prozess der Planung, Organisation und der Strukturierung des Projekts und untereinander: Requirements detailliert aufbauen und richtig umsetzten.
|
||||||
|
- Natürlich wird eine gewisse Eigenleistung bei der Implementierung erwartet, sowie das Erarbeiten von entsprechend benötigten Kenntnissen.
|
||||||
|
- Auslieferung des Projekts: Es wird nur erwartet, die Software zur Verfügung zu stellen, Webserver o.Ä. ist nicht notwendig, jedoch erste Anleitung für die Installation/Aufsetzten und den Start für die Inbetriebnahme erwünscht.
|
||||||
|
- Es müssen nicht zu viele Fachthemen abgedeckt werden (Schulfächer).
|
||||||
|
- Keine externen Quellen (z.B. YouTube Links) in die Erklärtexte einbetten.
|
||||||
|
- Projekt besser kompakter halten und dafür genau Anforderungen umsetzten, ordentlich mit Dokumentation/Wiki arbeiten.
|
||||||
|
- Wichtig ist vor allem, die Umsetzungen der Anforderungen aus dem Anschreiben und Pitch.
|
||||||
|
|
||||||
|
- **Für nächste Woche:** Aufgabenpakete erstellen und planen wie sie verteilt werden (bis Mitte/Ende November).
|
||||||
|
- Diese in GitLab tracken und dokumentieren. User Story zu Funktionalitäten aus Anleitung erstellen, Struktur schaffen.
|
||||||
|
- Dahingehend Zeitmanagement betreiben: Den benötigten Umfang der Arbeitspakete einschätzen und tracken.
|
||||||
|
- Herr Erbach als Maintainer: Projektdetails vorstellen, Zeit- und Aufgabenbereiche angeben; ggf. Diagramme und Unterstützung durch MS Project/ Jira/ GitLab -\> Wie viele Stunden pro Arbeitsabschnitt.
|
||||||
|
|
||||||
## Ergebnisse der Sitzung
|
## Ergebnisse der Sitzung
|
||||||
|
|
||||||
-
|
- Weitere Verbesserungen über die Dokumentationsstruktur und Inhaltsvorgaben für das Protokoll besprochen; zukünftig werden nur noch für die eigene Gruppe relevante Informationen protokolliert.
|
||||||
|
- Klärung der Anforderungen für die Projektphase "Requirements Engineering": keine Vorwegnahme der Entwicklung; zunächst klare und vollständige Festlegung der Anforderungen und User Stories.
|
||||||
|
- Detaillierte Anforderungen für das Produkt festlegen, einschließlich Einschränkungen und Rahmenbedingungen.
|
||||||
|
- Erörterung des Zeitmanagements für die Arbeitspakete sowie Strukturierung des Backlogs, um die Ziele bis zum Novembertermin zu erreichen.
|
||||||
|
|
||||||
## Action List
|
## Action List
|
||||||
|
|
||||||
| Was? | Wer? | Wann? |
|
<table>
|
||||||
|------|------|-------|
|
<tr>
|
||||||
| | | |
|
<th>Was?</th>
|
||||||
| | | |
|
<th>Wer?</th>
|
||||||
| | | |
|
<th>Wann?</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>Requirements konkret ausarbeiten und im Backlog festhalten</td>
|
||||||
|
<td>Alle</td>
|
||||||
|
<td>
|
||||||
|
|
||||||
|
30.10. -
|
||||||
|
|
||||||
|
6.11.
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>User Stories detailliert zu den identifizierten Anforderungen formulieren</td>
|
||||||
|
<td>
|
||||||
|
|
||||||
|
Eric, Jesko,
|
||||||
|
|
||||||
|
Alle
|
||||||
|
</td>
|
||||||
|
<td>
|
||||||
|
|
||||||
|
30.10. -
|
||||||
|
|
||||||
|
6.11
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>Strukturierung Aufgabenpakete und Zeitmanagement in GitLab ausbauen</td>
|
||||||
|
<td>Nathan</td>
|
||||||
|
<td>
|
||||||
|
|
||||||
|
30.10. -
|
||||||
|
|
||||||
|
6.11
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>Neue Issues erstellen und später dazu Zeitmanagement/Aufteilung der Arbeitsschritte einschätzen</td>
|
||||||
|
<td>Matthias, Alle</td>
|
||||||
|
<td>30.10. - 6.11</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>Gedanken zur Umsetzung erster Entwicklungsschritte bei einzelnen universellen Teilen</td>
|
||||||
|
<td>Jesko, Şafak, Kelvi</td>
|
||||||
|
<td>30.10. - 6.11</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
## Anlagen
|
## Anlagen
|
||||||
|
|
||||||
- PO-Bericht: "PO-2024-10-30.pdf"
|
- PO-Bericht: "PO-2024-10-30.pdf"
|
||||||
|
|
||||||
_Bitte beachten Sie, dass dem Protokoll immer auch die vorgestellten unkorrigierten Foliensätze angefügt werden müssen. Fehlende Folien führen zu einem nicht genehmigten Protokoll!_
|
|
||||||
Reference in New Issue
Block a user