YouTrack - Tags & Zeiterfassung

Dieser Leitfaden definiert standardisierte Zeiterfassung mit Arbeitstypen um einheitliche Schreibweisen und Prozesse für eine bessere Übersicht in Tickets zu gewährleisten.

ZEITERFASSUNG - Übersicht

Arbeitstypen für YouTrack

Name	Beschreibung
Entwicklung	Code-Entwicklung, Bug-Fixes, Refactoring
Testen	Unit- und Integrationstests, Manuelles Testen von Funktionen
Dokumentation	Code-Dokumentation, API-Docs, Benutzer-Handbücher
Analyse	Fehler- und Performance-Analyse, Code-Review, Debugging
Recherche	Technologie-Evaluierung, Library/Framework-Vergleiche, Best-Practice-Recherche
Projektmanagement	Projekt-Controlling, Projekt-Planung, Projekt-Kostenplan

YouTrack wird bei ITeas zur Arbeitszeiterfassung verwendet. Alle Zeiteinträge werden automatisch mit Autotask synchronisiert, daher ist eine korrekte und konsistente Erfassung wichtig.

---

QUICK REFERENCE - Schnelle Übersichten

Schnell-Referenz: Arbeitstypen wählen

Wenn du...	Dann nutze...
Code schreibst/änderst	Entwicklung
Tests erstellst/ausführst	Testen
Dokumentation schreibst	Dokumentation
Fehler suchst/analysierst	Analyse
Infos recherchierst	Recherche

Flussdiagramm: Arbeitstyp-Auswahl

Habe ich Code geschrieben/geändert?
├─ JA → Entwicklung
└─ NEIN
    └─ Habe ich Tests erstellt/durchgeführt?
        ├─ JA → Testen
        └─ NEIN
            └─ Habe ich Dokumentation geschrieben?
                ├─ JA → Dokumentation
                └─ NEIN
                    └─ War ich auf der Suche nach Informationen OHNE spezifisches Problem?
                        ├─ JA → Recherche
                        └─ NEIN → Analyse

Checkliste: Zeiteintrag erfassen

☐ Ticket geöffnet/ausgewählt
☐ "Add Work Item" / Zeiteintrag hinzufügen
☐ Zeit korrekt angegeben (in Stunden, z.B. 1.5h)
☐ Arbeitstyp passend ausgewählt (siehe Schnell-Referenz oben)
☐ Beschreibung aussagekräftig (Was + Wo)
☐ Speichern

Best Practices für Zeiterfassung

1. Zeitnah erfassen

✅ Gut: Zeiteinträge direkt während oder unmittelbar nach der Arbeit erfassen ❌ Schlecht: Am Ende der Woche alle Zeiten rekonstruieren

Warum: Genauere Erfassung, bessere Beschreibungen, keine vergessenen Einträge

2. Aussagekräftige Beschreibungen

✅ Gut:

2h | Entwicklung | REST-API für Mailgun-Domain-Import implementiert (POST /mailManager/domains/import)

❌ Schlecht:

2h | Entwicklung | Gearbeitet

Mindestangaben in Beschreibung:

• Was wurde gemacht
• Wo (Modul/Komponente)
• Optional: Ergebnis oder erreichte Teilschritte

3. Realistische Granularität

Empfohlene Zeiteinheiten:

• Minimum: 15 Minuten (0.25h)
• Typisch: 30 Minuten bis 2 Stunden
• Maximum pro Eintrag: 4 Stunden

Warum:

• Zu kleine Einträge (< 15min) → Overhead bei Verwaltung
• Zu große Einträge (> 4h) → Schwierig nachzuvollziehen, vermutlich mehrere Aktivitäten

Bei längerer Arbeit an einem Thema: Teilen Sie in logische Abschnitte:

Statt:
❌ 6h | Entwicklung | Feature XY

Besser:
✅ 2h | Analyse | Feature XY - Bestehenden Code analysiert und Konzept erstellt
✅ 3h | Entwicklung | Feature XY - Backend-Logik implementiert
✅ 1h | Testen | Feature XY - Unit-Tests geschrieben und manuell getestet

4. Pausen nicht erfassen

• Mittagspause: Nicht erfassen
• Kaffeepausen: Nicht separat erfassen (in Arbeitszeit eingerechnet)
• Längere Unterbrechungen (> 30min): Zeit unterbrechen

5. Meetings und Kommunikation

Projekt-bezogene Meetings:

• Erfassen Sie diese im relevanten Ticket als "Analyse" oder eigener Arbeitstyp (falls vorhanden)
• Beispiel: 1h | Analyse | Kick-off Meeting für Feature XY - Requirements besprochen

Allgemeine Meetings:

• Team-Meetings, Standups, Retrospektiven: Nicht in Projekt-Tickets erfassen
• Falls Erfassung gewünscht: Separates "Team"-Projekt oder Ticket verwenden

---

ARBEITSTYPEN IM DETAIL

1. Entwicklung

Verwendung:

• Schreiben von neuem Code
• Implementierung von Features
• Bug-Fixes implementieren
• Code-Refactoring
• Integration von APIs oder Services
• Erstellen von Migrations

Beispiele:

• "REST-API-Endpunkt für Domain-Import implementiert"
• "Bug im MailManager behoben - Domains werden jetzt korrekt validiert"
• "Autotask-Client um neue Methode erweitert"

Nicht für:

• Fehlersuche ohne Code-Änderung → Analyse
• Tests schreiben → Testen
• Code dokumentieren → Dokumentation

---

2. Testen

Verwendung:

• Manuelle Tests durchführen
• Unit-Tests schreiben
• Integrationstests erstellen
• Testfälle definieren
• Bug-Reproduktion und Verifikation
• QA-Aktivitäten
• End-to-End-Testing

Beispiele:

• "Unit-Tests für Domain-Validierung geschrieben"
• "Feature XY manuell getestet - 3 Bugs gefunden"
• "Bug-Fix verifiziert in Staging-Umgebung"
• "Integrationstests für YouTrack-Sync erweitert"

Nicht für:

• Test-Setup/Umgebung konfigurieren → Entwicklung oder Analyse
• Performance-Analyse → Analyse

---

3. Dokumentation

Verwendung:

• Code-Dokumentation schreiben
• API-Dokumentation erstellen/aktualisieren
• README oder CLAUDE.md aktualisieren
• VitePress-Dokumentation schreiben
• Kommentare in Code einfügen
• Benutzer-Handbücher erstellen
• Technische Spezifikationen dokumentieren

Beispiele:

• "API-Endpunkte in VitePress dokumentiert"
• "CLAUDE.md um neue Workflows-Sektion erweitert"
• "Inline-Dokumentation für MailManager-Klassen hinzugefügt"
• "Deployment-Prozess dokumentiert"

Nicht für:

• Code-Review-Kommentare → Entwicklung
• Ticket-Beschreibungen → Teil der Ticket-Erstellung, nicht separat erfassen

---

4. Analyse

Verwendung:

• Fehlersuche und Debugging
• Log-Analyse
• Performance-Analyse
• Requirements-Analyse
• Technische Konzepte erarbeiten
• Systemarchitektur-Planung
• Impact-Analysen
• Code-Review durchführen
• Bestehenden Code verstehen

Beispiele:

• "Fehlerursache für timeout-Problem identifiziert"
• "Performance-Bottleneck in Database-Queries analysiert"
• "Bestehende Autotask-Integration analysiert für Feature-Erweiterung"
• "Code-Review für Pull Request #123 durchgeführt"

Nicht für:

• Einfache Google-Suchen → Recherche
• Debugging mit direkter Code-Änderung → Entwicklung

---

5. Recherche

Verwendung:

• Technologie-Evaluierung
• Library/Framework-Vergleiche
• Best-Practice-Recherche
• Lösungsansätze recherchieren
• Dokumentation studieren
• Tutorials durcharbeiten
• PoC (Proof of Concept) Vorbereitung
• Externe Ressourcen studieren

Beispiele:

• "Verschiedene CSV-Parser-Libraries verglichen"
• "OAuth2-Flow in Microsoft Graph API recherchiert"
• "Docker-Best-Practices für PHP-Apps recherchiert"
• "Yii2-Framework-Features für neues Modul evaluiert"

Nicht für:

• Recherche MIT Implementierung → Entwicklung
• Recherche MIT direkter Anwendung im Projekt → je nach Kontext Analyse oder Entwicklung

---

6. Projektmanagement

Verwendung:

• Projekt-Planung und Scheduling
• Projekt-Controlling und Reporting
• Ressourcen-Management
• Risiko-Analyse
• Milestone-Planung
• Projekt-Dokumentation und Archivierung
• Stakeholder-Kommunikation (projektbezogen)

Beispiele:

• "Projekt-Kickoff und Timeline-Planung durchgeführt"
• "Wöchentliches Projekt-Status-Meeting geleitet"
• "Kostenkalkulation und ROI-Analyse erstellt"

Nicht für:

• Entwicklungs-Task-Planung → Entwicklung oder Analyse
• Team-Management-Overhead → nicht erfassen

---

Grenzfälle und Kombinationen

Was wenn mehrere Typen zutreffen?

Grundsatz: Wählen Sie den Hauptaspekt der Tätigkeit.

Beispiel 1: "Feature implementiert UND getestet"

• Lösung: Zwei separate Zeiteinträge
  • 2h "Entwicklung" - Feature XY implementiert
  • 0.5h "Testen" - Feature XY manuell getestet

Beispiel 2: "Bug analysiert UND direkt behoben"

• Lösung: Je nach Zeitverteilung
  • Wenn Analyse kurz (< 20%): Nur "Entwicklung"
  • Wenn Analyse länger: Zwei Einträge splitten
    • 1h "Analyse" - Fehlerursache identifiziert
    • 0.5h "Entwicklung" - Bug behoben

Faustregel: Bei < 15 Minuten für Nebenaktivität → in Hauptaktivität einrechnen. Bei > 15 Minuten → separater Eintrag.

---

HÄUFIG GESTELLTE FRAGEN (FAQ)

Warum ist korrekte Zeiterfassung wichtig?

Korrekt kategorisierte Zeiteinträge:

• Ermöglichen genaues Projekt-Controlling
• Erlauben Analyse des Zeit-Aufwands nach Aktivität
• Verbessern Schätzungen für zukünftige Projekte
• Sind Grundlage für Fakturierung (via Autotask-Sync)
• Zeigen Engpässe und Optimierungspotenzial auf

---

INTEGRATION MIT AUTOTASK

Automatische Synchronisation

• Zeiteinträge aus YouTrack werden automatisch zu Autotask synchronisiert
• Synchronisation erfolgt über ytSync-Modul
• Voraussetzung: YouTrack-Ticket muss mit Autotask-Ticket verknüpft sein

Mapping: YouTrack → Autotask (NOCH NICHT IMPLEMENTIERT)

YouTrack Arbeitstyp	Autotask Work Type
Entwicklung	Development
Testen	Testing
Dokumentation	Documentation
Analyse	Analysis
Recherche	Research
Projektmanagement	Project Management

Wichtig: Falsche Arbeitstypen führen zu falschen Abrechnungen in Autotask!

Zeiteintrag-Beschreibung

Die Beschreibung aus YouTrack wird 1:1 zu Autotask übertragen:

• Maximum: 500 Zeichen (größere werden gekürzt)
• Formatierung: Markdown wird zu Plain-Text konvertiert
• Sprache: Deutsch oder Englisch - je nach Kundenpräferenz

Tipp: Halten Sie Beschreibungen prägnant aber aussagekräftig für Kunden-Transparenz.

---

SIEHE AUCH

• Ticket-Erstellungsrichtlinien
• Ticket-Vorlagen
• YouTrack Documentation
• YouTrack Tags