From 2bb559e59d603f3985902448a4e43bd1ce17d135 Mon Sep 17 00:00:00 2001 From: ValueOn AG Date: Wed, 19 Nov 2025 10:39:42 +0100 Subject: [PATCH] Trainingsplan 2025-Q4 --- training/README.md | 135 ----------- training/handover_agenda_sync.md | 246 ++++++++------------ training/handover_einarbeitungsplan.md | 310 +++++++++++-------------- training/handover_naming_convention.md | 2 +- 4 files changed, 231 insertions(+), 462 deletions(-) delete mode 100644 training/README.md diff --git a/training/README.md b/training/README.md deleted file mode 100644 index 16f0bb7..0000000 --- a/training/README.md +++ /dev/null @@ -1,135 +0,0 @@ -# Training & Handover Dokumentation - -Dieses Verzeichnis enthält alle Dokumente für den Handover und die Einarbeitung von Ida & Stephan. - ---- - -## Dokumente - -### 1. Handover-Agenda für Sync-Meeting -**Datei:** `handover_agenda_sync.md` - -Agenda für das erste Sync-Meeting mit Ida & Stephan. Enthält: -- Projektkontext & Überblick -- System-Architektur -- Aktueller Stand & kritische Gaps -- Wichtige Anforderungen -- Rollenverteilung -- Einarbeitungsplan-Übersicht -- Naming Convention -- Offene Fragen & Diskussion - -**Verwendung:** Als Agenda für das erste Handover-Meeting verwenden. - ---- - -### 2. Einarbeitungsplan bis Weihnachten -**Datei:** `handover_einarbeitungsplan.md` - -Detaillierter Einarbeitungsplan mit 4 Phasen: -- **Phase 1**: Grundlagen (Woche 1-2) -- **Phase 2**: Praktische Einarbeitung (Woche 3-4) -- **Phase 3**: Selbstständige Entwicklung (Woche 5-6) -- **Phase 4**: Konsolidierung (bis Weihnachten) - -Enthält: -- Konkrete Aufgaben für Ida & Stephan -- Checkpoints mit Erfolgskriterien -- Metriken & Tracking -- Risiken & Mitigation - -**Verwendung:** Als Roadmap für die Einarbeitung verwenden. - ---- - -### 3. Naming Convention für Wiki-Dokumentation -**Datei:** `handover_naming_convention.md` - -Vollständige Naming Convention für alle Dokumente im Wiki. Enthält: -- Präfix-System (`doc_*`, `implementation_*`, `handover_*`, etc.) -- Verzeichnisstruktur -- Dateiformate -- Best Practices -- Migration bestehender Dokumente - -**Verwendung:** Als Referenz für alle neuen Dokumente verwenden. - ---- - -## Verwendung - -### Für das erste Sync-Meeting -1. `handover_agenda_sync.md` durchgehen -2. Alle Punkte besprechen -3. Offene Fragen klären -4. Nächste Schritte vereinbaren - -### Für die Einarbeitung -1. `handover_einarbeitungsplan.md` als Roadmap verwenden -2. Wöchentliche Checkpoints durchführen -3. Fortschritt dokumentieren -4. Anpassungen vornehmen falls nötig - -### Für neue Dokumentation -1. `handover_naming_convention.md` als Referenz verwenden -2. Konsistente Namensgebung anwenden -3. Richtiges Verzeichnis wählen -4. Dokumentation pflegen - ---- - -## Checkpoints - -### Checkpoint 1 (Ende Woche 2) -- Architektur verstanden -- Entwicklungsumgebung funktionsfähig -- Erste Änderungen erfolgreich -- Dokumentationsstruktur klar - -### Checkpoint 2 (Ende Woche 4) -- Kritische Bug-Fixes implementiert -- Feature-Integrations-Anleitung vorhanden -- Dokumentation aktualisiert -- Komponentenmodell vervollständigt - -### Checkpoint 3 (Ende Woche 6) -- Kritische Gaps behoben -- Neue Features integriert -- Dokumentation konsolidiert -- Sprint-Prozess etabliert - -### Final Checkpoint (Weihnachten) -- Alle kritischen Gaps geschlossen -- Dokumentation vollständig strukturiert -- Feature-Integrations-Anleitung fertig -- Komponentenmodell komplett -- Selbstständige Entwicklung möglich - ---- - -## Wichtige Links - -### Dokumentation -- Architektur: `../appdoc/doc_gateway_architecture_overview.md` -- Development Framework: `../appdoc/doc_gateway_development_framework.md` -- Workflow System: `../appdoc/doc_dev_workflow.md` -- Implementation Gaps: `../../gateway/WORKFLOW_IMPLEMENTATION_GAPS.md` - -### Code -- Gateway: `../../gateway/` -- Frontend: `../../frontend_agents/` -- Tests: `../../gateway/tests/` - ---- - -## Kontakt & Fragen - -Bei Fragen zur Einarbeitung oder Dokumentation: -- **Ida**: Code-Entwicklung, Architektur -- **Stephan**: Dokumentation, Strukturierung, Sprint-Planung -- **[Name]**: Checkpoints, Validierung, Finale Entscheidungen - ---- - -**Viel Erfolg bei der Einarbeitung! 🚀** - diff --git a/training/handover_agenda_sync.md b/training/handover_agenda_sync.md index 4c5908e..ce08a1e 100644 --- a/training/handover_agenda_sync.md +++ b/training/handover_agenda_sync.md @@ -1,30 +1,31 @@ # Handover-Agenda: Sync mit Ida & Stephan -**Datum:** [Heute] -**Teilnehmer:** [Name], Ida (Coding Expertin, Architekt), Stephan (Sprintführung, Struktur, Dokumentation) -**Dauer:** 90-120 Minuten +**Datum:** 19.11.2025 + +**Teilnehmer:** +| Name | Rolle | +|------|------| +| Ida | Coding Expertin, Architekt | +| Stephan | Sprintführung, Struktur, Dokumentation | +| Patrick | Product Owner, Applikations-Architekt | +| Dominic | Business Owner | + +**Dauer:** 20 Minuten --- -## 1. Einführung & Überblick (15 Min) +## 1. Projektkontext & Zugriff (3 Min) -### 1.1 Projektkontext -- **PowerOn Gateway**: Backend-System für intelligente Workflow-Automatisierung -- **Frontend Agents**: React-basierte UI-Playground mit allen Implementierungen -- **Architektur**: Multi-Layer-System (Connectors → Interfaces → Services → Workflows) -- **Ziel**: Weiterentwicklung und Wartung des Systems übernehmen - -### 1.2 Zugriff & Ressourcen -- ✅ GitHub Repository: Vollzugriff auf alle Daten -- ✅ Dokumentation: `wiki/appdoc/`, `wiki/implementation/`, `wiki/deployment/` -- ✅ Code: `gateway/` (Backend), `frontend_agents/` (UI-Playground) -- ✅ Aktuelle Gaps: `gateway/WORKFLOW_IMPLEMENTATION_GAPS.md` +- **PowerOn Gateway**: Backend für intelligente Workflow-Automatisierung +- **Architektur**: Multi-Layer (Connectors → Interfaces → Services → Workflows) +- **Zugriff**: GitHub Repository, Dokumentation (`wiki/appdoc/`, `wiki/implementation/`), Code (`gateway/`, `frontend_agents/`) +- **Ziel**: Weiterentwicklung und Wartung übernehmen --- -## 2. System-Architektur Überblick (20 Min) +## 2. System-Architektur (5 Min) -### 2.1 Layer-Struktur +**Layer-Struktur:** ``` Routes → Services → Interfaces → Connectors ↓ @@ -33,181 +34,118 @@ Routes → Services → Interfaces → Connectors Datamodels & AI Core ``` -**Wichtige Verzeichnisse:** +**Wichtigste Verzeichnisse:** - `gateway/modules/routes/` - HTTP Endpoints - `gateway/modules/services/` - Business Logic - `gateway/modules/interfaces/` - Standardisierte APIs - `gateway/modules/connectors/` - Externe System-Integration - `gateway/modules/workflows/` - Workflow-Orchestrierung -- `gateway/modules/datamodels/` - Datenmodelle -### 2.2 Dokumentationsstruktur -- **`wiki/appdoc/`**: Architektur-Dokumentation, System-Übersichten, User-Docs -- **`wiki/implementation/`**: Implementierungsdetails, Refactoring-Dokumentation -- **`wiki/deployment/`**: Deployment-Informationen, Instanzenübersicht -- **`wiki/training/`**: Handover-Dokumente, Einarbeitungspläne - -### 2.3 Key Components -- **Workflow System**: Multi-Mode-System (React Mode, Actionplan Mode) -- **AI Core**: Zentrale AI-Orchestrierung mit verschiedenen Providern -- **Service Center**: Registry für Service-Discovery und -Konfiguration -- **Security Layer**: JWT, RBAC, Key Management, Verschlüsselung +**Dokumentation:** `wiki/appdoc/` (Architektur), `wiki/implementation/` (Details) --- -## 3. Aktueller Stand & Wichtige Punkte (25 Min) +## 3. Wichtige Anforderungen & Aufgaben (5 Min) -### 3.1 Kritische Gaps (aus `WORKFLOW_IMPLEMENTATION_GAPS.md`) -1. **Fast Path fehlt**: Keine Komplexitätserkennung für einfache Requests -2. **Task-Nummerierung**: Zeigt immer "Task 0" statt korrekter Nummerierung -3. **User-Language Messages**: Technische Texte statt benutzerfreundlicher Nachrichten -4. **Workflow-Level Models**: RequestContext, UnderstandingResult fehlen +### Basis-Anforderungen: +1. **Komplettes Komponentenmodell** - Vervollständigen (`doc_diagram_components.md`) +2. **Klare Dokumentation** - Strukturieren, Naming Convention etablieren +3. **Feature-Integrations-Anleitung** - Praktische Schritt-für-Schritt-Anleitung erstellen -### 3.2 Code-Qualität & Standards -- **Naming**: camelStyle für Variablen/Funktionen, `_` Prefix für interne Funktionen -- **Code-Stil**: Einfach, smart, lesbar - keine Overcomplications -- **Fehlerbehandlung**: Root Cause identifizieren, keine Workarounds -- **Logging**: Keine Emojis in Log-Einträgen +### Zusätzliche Aufgaben: -### 3.3 Frontend als Referenz -- `frontend_agents/` enthält alle UI-Implementierungen -- Kann als Referenz für Backend-Integration verwendet werden -- React-basiert, zeigt alle Features in Aktion +**Mehrsprachigkeits-Konzept** (Ida & Stephan): +- Konzept für einfache UI-Mehrsprachigkeit entwickeln +- Anforderungen: + - Einfaches Ergänzen neuer Sprachen jederzeit möglich + - Angepasste Elemente nachführbar + - Abdeckung: Statische Texte, Log-Texte, Navigationstexte, Seitentexte + - Backend: Bereits über Pydantic-Models mit Sprachen versorgt (automatisiert erweiterbar) + - Frontend: Rendering-Themen, die Backend nicht interessieren + - Klare Trennung: Was kommt aus Backend/Logik vs. Frontend + +**React UI Objektbaum** (Ida): +- Objektbaum aller React UI-Elemente erstellen +- Klarheit über UI-Struktur und Komponenten-Hierarchie +- Dokumentation der React-Komponenten-Struktur + +**Althaus Chat Integration** (Ida): +- Bestehende Implementierung analysieren +- Vorschlag für Integration in Gesamtarchitektur erstellen + +**Nyla UI-Gestaltung** (Ida): +- Vorschlag für flexible Customer Journeys entwickeln +- UI-Architektur für bekannte Customer Journeys konzipieren + +**Graphische Workflow-Modellierung** (Ida): +- Vertiefung in graphische Workflow-Modellierung +- Möglichkeiten und Anforderungen identifizieren + +**Wiki vs. Notion Struktur** (Stephan): +- Klare Regeln definieren: Was gehört wohin? +- Sprint-Planung, Notion-Doku und Wiki abstimmen +- Intuitive Struktur schaffen + +### Info - Parallele Refactors: +**RBAC Refactoring** (Patrick macht parallel): +- RBAC in DB überführen mit klaren Rollenmodellen +- Berechtigungen auch für UI-Komponenten definieren +- Klare Trennung Backend/Frontend Berechtigungen --- -## 4. Wichtige Anforderungen (15 Min) +## 4. Rollenverteilung (3 Min) -### 4.1 Komplettes Komponentenmodell -- **Ziel**: Vollständige Übersicht aller Komponenten und deren Beziehungen -- **Status**: Teilweise vorhanden in `doc_diagram_components.md` -- **Action**: Aktualisieren und vervollständigen +**Ida:** +- Code-Entwicklung, Architektur-Entscheidungen, Python/React +- Feature-Implementierung, Code-Review, Bug-Fixes -### 4.2 Klare Dokumentation -- **Ziel**: Strukturierte, gepflegte Dokumentation für alle Stakeholder -- **Status**: Dokumentation vorhanden, aber nicht vollständig strukturiert -- **Action**: Naming Convention etablieren, Dokumentation kategorisieren +**Stephan:** +- Sprint-Planung, Dokumentations-Pflege, Prozess-Optimierung -### 4.3 Feature-Integrations-Anleitung -- **Ziel**: Schritt-für-Schritt-Anleitung, wie neue Features integriert werden -- **Status**: Framework vorhanden (`doc_gateway_development_framework.md`), aber keine konkrete Anleitung -- **Action**: Praktische Anleitung mit Beispielen erstellen +**Zusammenarbeit:** Wöchentliche Syncs, Code-Reviews, Checkpoints mit Ida & Stephan --- -## 5. Rollenverteilung & Verantwortlichkeiten (10 Min) +## 5. Einarbeitungsplan & Trainingsziel (4 Min) -### 5.1 Ida (Coding Expertin, Architekt) -- **Fokus**: Code-Entwicklung, Architektur-Entscheidungen, Python/React -- **Verantwortung**: - - Feature-Implementierung - - Code-Review und Qualitätssicherung - - Architektur-Verbesserungen - - Bug-Fixes und Refactoring +**Trainingsziel bis Weihnachten:** Verstehen & Starten -### 5.2 Stephan (Sprintführung, Struktur, Dokumentation) -- **Fokus**: Projektmanagement, Dokumentation, Strukturierung -- **Verantwortung**: - - Sprint-Planung und -Tracking - - Dokumentations-Pflege und -Strukturierung - - Prozess-Optimierung - - Stakeholder-Kommunikation +**4 Phasen bis Weihnachten:** +- **Phase 1** (Woche 1-2): Grundlagen - Dokumentationen nachführen, Althaus Chat Integration, Nyla UI-Konzept, Wiki/Notion-Struktur klären +- **Phase 2** (Woche 3-4): Praktische Einarbeitung - Bug-Fixes, Feature-Integrations-Anleitung, React UI Objektbaum, Mehrsprachigkeits-Konzept +- **Phase 3** (Woche 5-6): Selbstständige Entwicklung - Kritische Gaps beheben, Features entwickeln, Mehrsprachigkeits-Konzept finalisieren +- **Phase 4** (bis Weihnachten): Konsolidierung - Verstehen & Starten abgeschlossen -### 5.3 Zusammenarbeit -- Regelmäßige Syncs (wöchentlich) -- Code-Reviews vor Merge -- Dokumentation parallel zur Entwicklung -- Checkpoints für [Name] zur Validierung +**Checkpoints:** Ende Woche 2, 4, 6 und Weihnachten + +**Details:** Siehe `handover_einarbeitungsplan.md` --- -## 6. Einarbeitungsplan bis Weihnachten (15 Min) +## 6. Naming Convention (1 Min) -### 6.1 Phase 1: Grundlagen (Woche 1-2) -- [ ] System-Architektur verstehen -- [ ] Codebase explorieren -- [ ] Lokale Entwicklungsumgebung aufsetzen -- [ ] Erste kleine Änderungen testen - -**Checkpoint 1**: [Name] prüft Verständnis der Architektur - -### 6.2 Phase 2: Praktische Einarbeitung (Woche 3-4) -- [ ] Erste Bug-Fixes implementieren -- [ ] Dokumentation aktualisieren -- [ ] Feature-Integrations-Anleitung erstellen -- [ ] Komponentenmodell vervollständigen - -**Checkpoint 2**: [Name] prüft Qualität der ersten Änderungen - -### 6.3 Phase 3: Selbstständige Entwicklung (Woche 5-6) -- [ ] Kritische Gaps beheben (siehe 3.1) -- [ ] Neue Features entwickeln -- [ ] Dokumentation strukturieren und pflegen -- [ ] Best Practices etablieren - -**Checkpoint 3**: [Name] prüft Fortschritt und Qualität - -### 6.4 Phase 4: Konsolidierung (bis Weihnachten) -- [ ] Alle kritischen Gaps geschlossen -- [ ] Dokumentation vollständig strukturiert -- [ ] Feature-Integrations-Anleitung fertig -- [ ] Komponentenmodell komplett - -**Final Checkpoint**: [Name] prüft Gesamtergebnis - -**Detaillierter Plan**: Siehe `handover_einarbeitungsplan.md` - ---- - -## 7. Naming Convention & Dokumentationsstruktur (10 Min) - -### 7.1 Dokument-Naming Convention -Siehe `handover_naming_convention.md` für Details. - -**Kurzfassung:** +**Präfix-System:** - `doc_*` - Architektur- und System-Dokumentation - `implementation_*` - Implementierungsdetails - `handover_*` - Handover-Dokumente - `spec_*` - Spezifikationen - `user_*` - User-Dokumentation -### 7.2 Dokumentationsstruktur -- **`wiki/appdoc/`**: Architektur, System-Übersichten, User-Docs -- **`wiki/implementation/`**: Implementierungsdetails -- **`wiki/deployment/`**: Deployment-Informationen -- **`wiki/training/`**: Handover, Einarbeitung -- **`wiki/reviews/`**: Code-Reviews, Analysen -- **`wiki/strategy/`**: Strategische Dokumente +**Verzeichnisse:** `wiki/appdoc/`, `wiki/implementation/`, `wiki/training/` + +**Details:** Siehe `handover_naming_convention.md` --- -## 8. Offene Fragen & Diskussion (10 Min) +## 7. Nächste Schritte & Fragen (3 Min) -### 8.1 Fragen von Ida & Stephan -- Technische Fragen zur Architektur -- Prozess-Fragen zur Entwicklung -- Dokumentations-Fragen - -### 8.2 Nächste Schritte -- [ ] GitHub-Zugriff bestätigen -- [ ] Lokale Entwicklungsumgebung aufsetzen -- [ ] Erste Dokumentation lesen +### Action Items: +- [ ] (Siehe Einarbeitungsplan) - [ ] Nächster Sync-Termin vereinbaren ---- - -## 9. Action Items - -### Für Ida & Stephan: -- [ ] GitHub Repository klonen und explorieren -- [ ] Lokale Entwicklungsumgebung aufsetzen -- [ ] Dokumentation in `wiki/appdoc/` durcharbeiten -- [ ] Erste Fragen sammeln für nächsten Sync - -### Für [Name]: -- [ ] Zugriff auf alle Ressourcen bestätigen -- [ ] Nächsten Sync-Termin festlegen -- [ ] Checkpoint-Termine für Einarbeitungsplan vereinbaren +### Offene Fragen: +- Zum Plan, Vorgehen, andere? --- @@ -215,7 +153,5 @@ Siehe `handover_naming_convention.md` für Details. - **Einarbeitungsplan**: `handover_einarbeitungsplan.md` - **Naming Convention**: `handover_naming_convention.md` -- **Architektur-Übersicht**: `../appdoc/doc_gateway_architecture_overview.md` -- **Development Framework**: `../appdoc/doc_gateway_development_framework.md` -- **Workflow Gaps**: `../../gateway/WORKFLOW_IMPLEMENTATION_GAPS.md` +- **Architektur**: `../appdoc/doc_architecture_gateway.drawio` diff --git a/training/handover_einarbeitungsplan.md b/training/handover_einarbeitungsplan.md index aaf4800..e95c50e 100644 --- a/training/handover_einarbeitungsplan.md +++ b/training/handover_einarbeitungsplan.md @@ -1,6 +1,7 @@ # Einarbeitungsplan: Ida & Stephan bis Weihnachten -**Zeitraum:** [Startdatum] bis Weihnachten +**Zeitraum:** 19.11.2025 bis Weihnachten +**Trainingsziel:** Verstehen & Starten **Ziel:** Vollständige Übernahme der Code-Entwicklung und Dokumentation --- @@ -17,95 +18,100 @@ Phase 3: Selbstständige Entwicklung (Woche 5-6) Phase 4: Konsolidierung (bis Weihnachten) ``` +**Info - Parallele Refactors:** +Patrick macht parallel: +- **RBAC Refactoring**: RBAC in DB überführen mit klaren Rollenmodellen und Berechtigungen für UI-Komponenten +- **Finalisierung Separation der Gateway Funktionsblöcke**: Core, Messaging, Workflow, AI & Chat --- ## Phase 1: Grundlagen (Woche 1-2) ### Ziel -System-Architektur verstehen, Codebase explorieren, Entwicklungsumgebung aufsetzen +Dokumentationen geradeziehen und nachführen, Struktur der Dokumentation klären, Integrationen planen ### Aufgaben für Ida -#### Woche 1: Architektur & Codebase -- [ ] **Tag 1-2**: Architektur-Dokumentation lesen - - `doc_gateway_architecture_overview.md` - - `doc_gateway_development_framework.md` - - `doc_diagram_components.md` - - `doc_dev_workflow.md` -- [ ] **Tag 3-4**: Codebase explorieren - - `gateway/modules/` Struktur verstehen - - Wichtige Dateien identifizieren: - - `app.py` (Entry Point) - - `workflowManager.py` (Workflow-Orchestrierung) - - `modules/services/__init__.py` (Service Center) - - `modules/workflows/` (Workflow-System) -- [ ] **Tag 5**: Lokale Entwicklungsumgebung aufsetzen - - Python-Umgebung konfigurieren - - Dependencies installieren (`requirements.txt`) - - Environment-Variablen konfigurieren - - App lokal starten und testen +**Hinweis:** Ida kennt die App bereits und entwickelt darauf. -#### Woche 2: Praktisches Verständnis -- [ ] **Tag 1-2**: Workflow-System verstehen - - `workflowManager.py` durcharbeiten - - `workflowProcessor.py` analysieren - - React Mode vs. Actionplan Mode verstehen - - `modeDynamic.py` studieren -- [ ] **Tag 3-4**: Service-Layer verstehen - - Service Center (`modules/services/__init__.py`) - - Beispiel-Services analysieren (`serviceAi`, `serviceExtraction`) - - Interface-Pattern verstehen - - Connector-Pattern verstehen -- [ ] **Tag 5**: Erste kleine Änderung testen - - Kleiner Bug-Fix oder Code-Formatierung - - Pull Request erstellen - - Review-Prozess durchlaufen +#### Woche 1: Dokumentationen geradeziehen & nachführen +- [ ] **Tag 1-2**: Bestehende Dokumentationen analysieren und aktualisieren + - `doc_gateway_architecture_overview.md` auf Aktualität prüfen + - `doc_gateway_development_framework.md` mit aktueller Codebase abgleichen + - `doc_diagram_components.md` vervollständigen + - `doc_dev_workflow.md` aktualisieren + - Dokumentationen nachführen, wo Code weiterentwickelt wurde +- [ ] **Tag 3-4**: Althaus Chat Integration analysieren + - Bestehende Althaus Chat-Implementierung analysieren (`features/chatAlthaus/`) + - Architektur verstehen und dokumentieren + - **Vorschlag erstellen**: Wie Althaus Chat in die Gesamtarchitektur integrieren? + - Integration-Pattern identifizieren +- [ ] **Tag 5**: Graphische Workflow-Modellierung vertiefen + - Bestehende Workflow-Modellierung analysieren + - Graphische Darstellung verstehen + - Vertiefung in das Thema der graphischen Workflow-Modellierung + - Möglichkeiten und Anforderungen identifizieren + +#### Woche 2: Nyla UI & Customer Journeys +- [ ] **Tag 1-2**: Nyla UI analysieren und Customer Journeys verstehen + - Bestehende UI-Struktur analysieren (`frontend_agents/`) + - Bekannte Customer Journeys identifizieren und dokumentieren + - UI-Komponenten für Customer Journeys analysieren +- [ ] **Tag 3-4**: Nyla UI-Gestaltungskonzept entwickeln + - **Vorschlag erstellen**: Wie Nyla UI gestalten, damit bekannte Customer Journeys flexibel gefahren werden können? + - UI-Architektur für flexible Customer Journeys konzipieren + - Komponenten-Struktur für Customer Journeys planen +- [ ] **Tag 5**: Dokumentationen finalisieren + - Alle aktualisierten Dokumentationen reviewen + - Integration-Vorschläge dokumentieren + - Nyla UI-Konzept dokumentieren ### Aufgaben für Stephan -#### Woche 1: Dokumentationsstruktur -- [ ] **Tag 1-2**: Dokumentationsstruktur analysieren +#### Woche 1: Dokumentationsstruktur klären +- [ ] **Tag 1-2**: Bestehende Dokumentationsstruktur analysieren - Alle `wiki/` Unterordner durchgehen + - Notion-Struktur analysieren (falls vorhanden) - Dokumentations-Typen identifizieren - - Lücken in der Dokumentation finden -- [ ] **Tag 3-4**: Naming Convention etablieren - - `handover_naming_convention.md` durcharbeiten - - Bestehende Dokumente kategorisieren - - Vorschläge für Verbesserungen sammeln + - Aktuelle Verteilung Wiki vs. Notion verstehen +- [ ] **Tag 3-4**: Klare Regeln und Strukturen definieren + - **Klären**: Was gehört ins Wiki? Was gehört ins Notion? + - Klare Regeln für Dokumentations-Orte definieren + - Struktur für beide Systeme festlegen + - Naming Convention etablieren (`handover_naming_convention.md` durcharbeiten) - [ ] **Tag 5**: Dokumentations-Index erstellen - - Übersicht aller Dokumente - - Kategorisierung nach Typ + - Übersicht aller Dokumente (Wiki + Notion) + - Kategorisierung nach Typ und Ort - Verlinkungen zwischen Dokumenten + - Klare Zuordnung: Was gehört wohin? -#### Woche 2: Prozess-Verständnis -- [ ] **Tag 1-2**: Development-Workflow verstehen - - `doc_dev_workflow.md` durcharbeiten - - Git-Workflow verstehen - - Review-Prozess verstehen -- [ ] **Tag 3-4**: Sprint-Struktur planen +#### Woche 2: Sprint-Planung & Dokumentations-Integration +- [ ] **Tag 1-2**: Sprint-Planung strukturieren - Sprint-Länge festlegen (z.B. 2 Wochen) - Backlog-Struktur definieren - - Tracking-Tool einrichten (falls nötig) -- [ ] **Tag 5**: Erste Dokumentation aktualisieren - - Ein Dokument aktualisieren/verbessern - - Naming Convention anwenden - - Feedback einholen + - Sprint-Planung in Notion strukturieren +- [ ] **Tag 3-4**: Integration sicherstellen + - **Sicherstellen**: Sprint-Planung, Notion-Doku und Wiki sind integral aufeinander abgestimmt + - Workflow definieren: Wie fließen Informationen zwischen den Systemen? + - Klare Zuordnungen: Was gehört in Sprint-Planung, was in Notion, was ins Wiki? + - Intuitive Struktur schaffen: Auf einfache Weise klar, was wohin gehört +- [ ] **Tag 5**: Dokumentations-Struktur finalisieren + - Regeln dokumentieren + - Struktur visualisieren + - Team informieren und Feedback einholen ### Checkpoint 1 (Ende Woche 2) -**Prüfung durch [Name]:** -- [ ] Ida kann die Architektur erklären -- [ ] Ida hat lokale Entwicklungsumgebung funktionsfähig -- [ ] Ida hat erste kleine Änderung erfolgreich gemacht -- [ ] Stephan hat Dokumentationsstruktur verstanden -- [ ] Stephan hat Naming Convention angewendet -- [ ] Beide können Fragen zur Architektur beantworten - -**Erfolgskriterien:** -- ✅ Lokale Entwicklungsumgebung läuft -- ✅ Erste Code-Änderung erfolgreich -- ✅ Dokumentationsstruktur klar -- ✅ Naming Convention etabliert +**Prüfung durch Patrick:** +| Kriterium | Name | Status | +| ---------- | ---- | ------ | +| Dokumentationen aktualisiert und nachgeführt | Ida | (offen) | +| Vorschlag für Althaus Chat-Integration erstellt | Ida | (offen) | +| Selbstständig in graphische Workflow-Modellierung vertieft | Ida | (offen) | +| Vorschlag für Nyla UI-Gestaltung erstellt | Ida | (offen) | +| Klare Regeln für Wiki vs. Notion definiert | Stephan | (offen) | +| Dokumentationsstruktur etabliert | Stephan | (offen) | +| Sprint-Planung, Notion-Doku und Wiki abgestimmt | Stephan | (offen) | +| Intuitiv klar, was wohin gehört | Ida & Stephan | (offen) | --- @@ -131,15 +137,19 @@ Erste Bug-Fixes implementieren, Dokumentation aktualisieren, Feature-Integration - Review-Prozess durchlaufen - Feedback einarbeiten -#### Woche 4: Feature-Integrations-Anleitung +#### Woche 4: Feature-Integrations-Anleitung + React UI Objektbaum - [ ] **Tag 1-2**: Bestehende Features analysieren - Wie wurden Features bisher integriert? - Patterns identifizieren - Beispiele sammeln -- [ ] **Tag 3-4**: Feature-Integrations-Anleitung erstellen +- [ ] **Tag 3-4**: Feature-Integrations-Anleitung erstellen + React UI Objektbaum - Schritt-für-Schritt-Anleitung - Beispiele für verschiedene Feature-Typen - Checkliste für neue Features + - **React UI Objektbaum erstellen** + - Alle React-Komponenten analysieren + - Komponenten-Hierarchie dokumentieren + - Objektbaum visualisieren - [ ] **Tag 5**: Anleitung testen - Kleines Feature als Beispiel integrieren - Anleitung dabei verwenden @@ -161,34 +171,38 @@ Erste Bug-Fixes implementieren, Dokumentation aktualisieren, Feature-Integration - Qualitätskriterien definieren - Erste Dokumente reviewen -#### Woche 4: Komponentenmodell +#### Woche 4: Komponentenmodell + Mehrsprachigkeits-Konzept - [ ] **Tag 1-2**: Bestehendes Komponentenmodell analysieren - `doc_diagram_components.md` durcharbeiten - Lücken identifizieren - Aktualitätsprüfung -- [ ] **Tag 3-4**: Komponentenmodell vervollständigen +- [ ] **Tag 3-4**: Komponentenmodell vervollständigen + Mehrsprachigkeits-Konzept starten - Alle Komponenten dokumentieren - Beziehungen zwischen Komponenten - Diagramme aktualisieren/erstellen -- [ ] **Tag 5**: Komponentenmodell validieren + - **Mehrsprachigkeits-Konzept entwickeln** (mit Ida) + - Backend-Analyse: Pydantic-Models mit Sprachen + - Frontend-Analyse: React UI-Komponenten + - Trennung: Backend/Logik vs. Frontend/Rendering +- [ ] **Tag 5**: Komponentenmodell validieren + Mehrsprachigkeits-Konzept - Mit Codebase abgleichen - Feedback von Ida einholen - Verbesserungen einarbeiten + - **Mehrsprachigkeits-Konzept dokumentieren** ### Checkpoint 2 (Ende Woche 4) -**Prüfung durch [Name]:** -- [ ] Ida hat kritische Bug-Fixes implementiert -- [ ] Code-Qualität hat sich verbessert -- [ ] Feature-Integrations-Anleitung ist praktisch nutzbar -- [ ] Dokumentation ist aktualisiert und strukturiert -- [ ] Komponentenmodell ist vervollständigt - -**Erfolgskriterien:** -- ✅ Task-Nummerierung funktioniert korrekt -- ✅ Feature-Integrations-Anleitung vorhanden -- ✅ Dokumentation strukturiert und gepflegt -- ✅ Komponentenmodell vollständig +**Prüfung durch Patrick:** +| Kriterium | Name | Status | +| ---------- | ---- | ------ | +| Task-Nummerierung Fix implementiert | Ida | (offen) | +| Code-Qualität verbessert | Ida | (offen) | +| Feature-Integrations-Anleitung erstellt | Ida | (offen) | +| React UI Objektbaum erstellt | Ida | (offen) | +| Dokumentations-Lücken geschlossen | Stephan | (offen) | +| Dokumentations-Struktur verbessert | Stephan | (offen) | +| Komponentenmodell vervollständigt | Stephan | (offen) | +| Mehrsprachigkeits-Konzept gestartet (mit Ida) | Ida & Stephan | (offen) | --- @@ -230,15 +244,21 @@ Kritische Gaps beheben, neue Features entwickeln, Best Practices etablieren ### Aufgaben für Stephan -#### Woche 5: Dokumentations-Konsolidierung +#### Woche 5: Dokumentations-Konsolidierung + Mehrsprachigkeits-Konzept finalisieren - [ ] **Tag 1-2**: Alle Dokumentationen durchgehen - Aktualitätsprüfung - Konsistenz prüfen - Verbesserungen identifizieren -- [ ] **Tag 3-4**: Dokumentations-Workflow etablieren +- [ ] **Tag 3-4**: Dokumentations-Workflow etablieren + Mehrsprachigkeits-Konzept - Prozess für Dokumentations-Updates - Review-Prozess für Dokumentation - Qualitätskriterien durchsetzen + - **Mehrsprachigkeits-Konzept finalisieren** (mit Ida) + - Konzept für einfache UI-Mehrsprachigkeit + - Abdeckung: Statische Texte, Log-Texte, Navigationstexte, Seitentexte + - Backend: Pydantic-Models automatisiert erweiterbar + - Frontend: Rendering-Themen + - Klare Trennung Backend/Logik vs. Frontend - [ ] **Tag 5**: Dokumentations-Templates erstellen - Template für neue Features - Template für Architektur-Dokumente @@ -260,25 +280,25 @@ Kritische Gaps beheben, neue Features entwickeln, Best Practices etablieren ### Checkpoint 3 (Ende Woche 6) -**Prüfung durch [Name]:** -- [ ] Kritische Gaps sind behoben -- [ ] Neue Features wurden erfolgreich integriert -- [ ] Dokumentation ist konsolidiert -- [ ] Sprint-Planung funktioniert -- [ ] Code-Qualität ist hoch - -**Erfolgskriterien:** -- ✅ Fast Path funktioniert -- ✅ User-Language Messages implementiert -- ✅ Dokumentation vollständig strukturiert -- ✅ Sprint-Prozess etabliert +**Prüfung durch Patrick:** +| Kriterium | Name | Status | +| ---------- | ---- | ------ | +| Fast Path implementiert | Ida | (offen) | +| User-Language Messages implementiert | Ida | (offen) | +| Neue Features erfolgreich integriert | Ida | (offen) | +| Architektur-Verbesserungen umgesetzt | Ida | (offen) | +| Dokumentations-Konsolidierung abgeschlossen | Stephan | (offen) | +| Mehrsprachigkeits-Konzept finalisiert (mit Ida) | Ida & Stephan | (offen) | +| Dokumentations-Templates erstellt | Stephan | (offen) | +| Sprint-Planung strukturiert | Stephan | (offen) | +| Code-Qualität ist hoch | Ida & Stephan | (offen) | --- ## Phase 4: Konsolidierung (bis Weihnachten) ### Ziel -Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Feature-Integrations-Anleitung fertig, Komponentenmodell komplett +**Verstehen & Starten**: Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Feature-Integrations-Anleitung fertig, Komponentenmodell komplett, Mehrsprachigkeits-Konzept fertig, React UI Objektbaum dokumentiert ### Aufgaben für Ida @@ -310,19 +330,25 @@ Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Featu ### Final Checkpoint (Weihnachten) -**Prüfung durch [Name]:** -- [ ] Alle kritischen Gaps geschlossen -- [ ] Dokumentation vollständig strukturiert und gepflegt -- [ ] Feature-Integrations-Anleitung fertig und getestet -- [ ] Komponentenmodell komplett -- [ ] Ida & Stephan können selbstständig entwickeln -- [ ] Qualität ist hoch und konsistent +**Prüfung durch Patrick:** +| Kriterium | Name | Status | +| ---------- | ---- | ------ | +| Alle kritischen Gaps geschlossen | Ida | (offen) | +| Code-Qualität auf hohem Niveau gehalten | Ida | (offen) | +| Performance-Optimierungen umgesetzt | Ida | (offen) | +| Umfassende Tests geschrieben | Ida | (offen) | +| Neue Features erfolgreich entwickelt | Ida | (offen) | +| Best Practices etabliert | Ida | (offen) | +| Alle Dokumentationen aktualisiert | Stephan | (offen) | +| Komponentenmodell finalisiert | Stephan | (offen) | +| Feature-Integrations-Anleitung finalisiert | Stephan | (offen) | +| Dokumentations-Index vollständig | Stephan | (offen) | +| Sprint-Prozess optimiert | Stephan | (offen) | +| Metriken & Reporting etabliert | Stephan | (offen) | +| Selbstständig entwickeln | Ida & Stephan | (offen) | +| Qualität ist hoch und konsistent | Ida & Stephan | (offen) | +| Verstehen & Starten abgeschlossen | Ida & Stephan | (offen) | -**Erfolgskriterien:** -- ✅ System ist produktionsreif -- ✅ Dokumentation ist vollständig -- ✅ Prozesse sind etabliert -- ✅ Wissenstransfer abgeschlossen --- @@ -330,7 +356,7 @@ Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Featu ### Format - **Dauer**: 30-60 Minuten -- **Teilnehmer**: [Name], Ida, Stephan +- **Teilnehmer**: Patrick, Ida, Stephan - **Agenda**: 1. Fortschritt der letzten Woche 2. Herausforderungen & Blockaden @@ -345,42 +371,6 @@ Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Featu --- -## Metriken & Tracking - -### Code-Metriken -- Anzahl implementierter Features -- Anzahl behobener Bugs -- Code-Coverage (Tests) -- Code-Qualität (Linter-Scores) - -### Dokumentations-Metriken -- Anzahl aktualisierter Dokumente -- Vollständigkeit des Komponentenmodells -- Qualität der Dokumentation (Review-Scores) - -### Prozess-Metriken -- Sprint-Velocity -- Time-to-Market für Features -- Review-Zyklus-Zeit - ---- - -## Risiken & Mitigation - -### Risiko 1: Zu komplexe Architektur -- **Mitigation**: Schrittweise Einarbeitung, Fragen stellen, Pair Programming - -### Risiko 2: Unvollständige Dokumentation -- **Mitigation**: Dokumentation parallel zur Entwicklung, regelmäßige Reviews - -### Risiko 3: Zeitdruck -- **Mitigation**: Realistische Planung, Priorisierung, Fokus auf kritische Punkte - -### Risiko 4: Wissenslücken -- **Mitigation**: Regelmäßige Syncs, Code-Reviews, Dokumentation lesen - ---- - ## Ressourcen & Links ### Dokumentation @@ -389,28 +379,6 @@ Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Featu - Workflow System: `wiki/appdoc/doc_dev_workflow.md` - Implementation Gaps: `gateway/WORKFLOW_IMPLEMENTATION_GAPS.md` -### Code -- Gateway: `gateway/` -- Frontend: `frontend_agents/` -- Tests: `gateway/tests/` - -### Tools -- GitHub: Repository -- Development Environment: Lokal -- Testing: pytest -- Code Quality: Linter, Type Checking - ---- - -## Erfolgsfaktoren - -1. **Regelmäßige Kommunikation**: Wöchentliche Syncs, offene Fragen -2. **Schrittweise Einarbeitung**: Nicht alles auf einmal, sondern strukturiert -3. **Praktische Übung**: Learning by doing, kleine Aufgaben zuerst -4. **Dokumentation parallel**: Wissen sofort dokumentieren -5. **Feedback-Loops**: Regelmäßige Checkpoints, Anpassungen - ---- **Viel Erfolg bei der Einarbeitung! 🚀** diff --git a/training/handover_naming_convention.md b/training/handover_naming_convention.md index 7064533..de1b540 100644 --- a/training/handover_naming_convention.md +++ b/training/handover_naming_convention.md @@ -1,4 +1,4 @@ -# Naming Convention für Wiki-Dokumentation +# Naming Convention für Wiki-Dokumentation (ALS IDEE FÜR STEPHAN - NICHT ANGEWENDET - SO KURZ WIE MÖGLICH) **Zweck:** Klare Strukturierung und Auffindbarkeit aller Dokumente im Wiki