Kernkompetenz: praktische Full-Stack-Projekte
Beherrschen Sie den gesamten Prozess von den Anforderungen bis zur Lieferung, verstehen Sie die Methodik der Spec-getriebenen Entwicklung, lernen Sie die WBS-Zerlegung und die DoD-Definition und erwerben Sie Fähigkeiten in Projektmanagement und Qualitätskontrolle auf Enterprise-Niveau.
Methodik zur Klärung der Anforderungen
Die Klärung der Anforderungen ist die Grundlage für den Projekterfolg. Mit einer systematischen Methode stellen Sie sicher, dass die tatsächlichen Bedürfnisse verstanden werden und Nacharbeit sowie Missverständnisse vermieden werden.
Reverse-Interview-Technik
Reverse Interview ist eine proaktive Fragetechnik, die durch die Frage „warum“ die tatsächlichen Bedürfnisse aufdeckt:
Fragen Sie „warum“ statt „was“
Falsche Fragestellung：„Welche Funktionen benötigen Sie?“
Die richtige Frage stellen: „Warum brauchen Sie diese Funktion? Welches Problem löst sie?“
Indem man „warum“ fragt, versteht man die wahren Motive und Geschäftsziele hinter dem Bedarf.
Fragen Sie nach „wann“ und „wer“
- • Anwendungsszenarien：„Wann wird diese Funktion verwendet? Wie häufig wird sie verwendet?“
- • Zielgruppen: „Wer wird diese Funktion nutzen? Wie hoch ist ihr technisches Niveau?“
- • Nutzungsumgebung："In welcher Umgebung wird es verwendet? Welche Einschränkungen gibt es?"
„Was wäre, wenn …?“ fragen
- • Randfälle：„Was würde passieren, wenn es diese Funktion nicht gäbe?“
- • Fehlerbehandlung："Was passiert, wenn die Daten ungewöhnlich sind?"
- • Skalierbarkeit：„Was passiert, wenn sich die Anforderungen ändern?“
Erstellung von User Stories
Eine User Story ist die kleinste Einheit einer Anforderung und umfasst drei Elemente: Rolle, Ziel und Wert:
Benutzerstory-Vorlage:
Ich möchte [Ziel],
Damit [Wert/Grund].
Merkmale einer guten User Story
- • Unabhängigkeit：kann unabhängig entwickelt und getestet werden
- • Verhandelbar: Kann besprochen und angepasst werden
- • Wertvoll: Bietet den Nutzern einen echten Mehrwert
- • Abschätzbar: Kann die Entwicklungszeit abschätzen
- • Klein: kann in einer Iteration abgeschlossen werden
- • Testbar: Es gibt klare Abnahmekriterien
Akzeptanzkriterien
Jede User Story sollte klare Akzeptanzkriterien haben und das Given-When-Then-Format verwenden:
When: wenn der Nutzer auf die Schaltfläche „Aufgabe erstellen“ klickt
Then: Das Formular zur Aufgabenerstellung anzeigen
And: Der Benutzer kann einen Aufgabentitel und eine Aufgabenbeschreibung eingeben
And: Benutzer können Aufgaben speichern
Priorisierung von Anforderungen
MoSCoW-Methode
- • Must have：Muss vorhanden sein, eine Schlüsselfunktion für den Projekterfolg
- • Should have: Sollte vorhanden sein; wichtig, aber nicht entscheidend
- • Could have: Kann vorhanden sein; umsetzen, wenn die Zeit es erlaubt
- • Won't have: Wenn wir es dieses Mal nicht tun, machen wir es vielleicht später
Wert-Komplexitäts-Matrix
Basierend auf dem Wert und der Komplexität der Funktionen sollten Funktionen mit hohem Nutzen und geringer Komplexität priorisiert werden.
Praxisfall: Anforderungsklärung für eine E-Commerce-Plattform
Anfangsanforderung
„Wir brauchen eine Warenkorb-Funktion“
Reverse-Interview-Prozess
- F: "Warum wird ein Warenkorb benötigt?" A: "Benutzer müssen mehrere Produkte gleichzeitig auswählen können"
- F: "Wann verwenden?" A: "Beim Stöbern nach Produkten die, die Ihnen gefallen, in den Warenkorb legen"
- F: "Wer wird es nutzen?" A: "Alle registrierten Nutzer"
- F: "Was passiert, wenn der Benutzer nicht angemeldet ist?" A: "Man kann Artikel zum Warenkorb hinzufügen, muss sich aber beim Bezahlen anmelden"
Klar definierte Anforderungen
- • Benutzer können Produkte zum Warenkorb hinzufügen (angemeldet/nicht angemeldet)
- • Benutzer können die Artikel im Warenkorb anzeigen
- • Benutzer können die Produktmenge ändern
- • Benutzer können Produkte löschen
- • Der Warenkorb nicht angemeldeter Nutzer wird im lokalen Speicher gespeichert
- • Den lokalen Warenkorb und den Server-Warenkorb nach der Anmeldung zusammenführen
Spezifikationsgetriebene Entwicklung
Spec-gesteuerte Entwicklung wandelt Anforderungen in ausführbare Spezifikationen um, und KI kann direkt auf Basis der Spec Code generieren, wodurch die Entwicklungseffizienz und die Codequalität verbessert werden.
PRD-Erstellung
PRD-Struktur
- • Produktübersicht: Produktpositionierung, Zielnutzer, Kernwert
- • Funktionale Anforderungen：Detaillierte Funktionsbeschreibungen und User Stories
- • Nicht-funktionale Anforderungen: Leistung, Verfügbarkeit, Sicherheit, Skalierbarkeit
- • Benutzeroberfläche: Oberflächendesign und Interaktionsabläufe
- • Datenmodell: Datenstrukturen und Beziehungen
- • Akzeptanzkriterien：Funktionsabnahme, Leistungsabnahme, Sicherheitsabnahme
Prinzipien für das Verfassen von PRDs
- • Klar und eindeutig: Verwenden Sie eine klare Sprache und vermeiden Sie Mehrdeutigkeiten
- • Ausführbar：KI kann Code direkt auf Grundlage des PRD generieren
- • Testbar: Jede Anforderung hat klare Akzeptanzkriterien
- • Nachverfolgbar: Anforderungen lassen sich auf Geschäftsziele zurückverfolgen
API-Spezifikation (OpenAPI-Spezifikation)
Vorteile der OpenAPI-Spezifikation
- • Standardisierung: Industriestandard mit umfassender Werkzeugunterstützung
- • Ausführbar：KI kann Code direkt auf Grundlage von OpenAPI generieren
- • Testbar: Kann API-Testfälle automatisch generieren
- • Dokumentierbar：Automatische Generierung von API-Dokumentation
Beispiel für API Spec
openapi: 3.0.0
info:
title: Task Management API
version: 1.0.0
paths:
/api/tasks:
get:
summary: Aufgabenliste abrufen
parameters:
- name: status
in: query
schema:
type: string
enum: [pending, in-progress, completed]
responses:
'200':
description: Erfolgreich
content:
application/json:
schema:
type: object
properties:
tasks:
type: array
items:
$ref: '#/components/schemas/Task'
post:
summary: Aufgabe erstellen
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateTaskRequest'
responses:
'201':
description: Erfolgreich erstellt
components:
schemas:
Task:
type: object
properties:
id:
type: string
title:
type: string
status:
type: string
enum: [pending, in-progress, completed]UI Spec
UI-Spec-Inhalt
- • Seitenlayout: Seitenstruktur, Position der Komponenten
- • Komponentendesign: Komponententypen, Stile, Interaktionen
- • Interaktionsablauf: Benutzerablauf, Zustandsänderungen
- • Responsives Design：Anpassung an unterschiedliche Bildschirmgrößen
Tipps zum Verfassen von UI-Spezifikationen
- • Figma oder ähnliche Tools verwenden, um Oberflächen zu entwerfen
- • Den Zustand und die Wechselwirkungen jeder Komponente ausführlich beschreiben
- • KI-Tools (z. B. v0) verwenden, um anhand von Beschreibungen Code zu generieren
- • Design-Systeme und Komponentenbibliotheken bereitstellen
Praxisbeispiel: vollständiger Ablauf von PRD bis Code
Schritt 1: Das PRD verfassen
Produktziele, funktionale Anforderungen und nicht-funktionale Anforderungen klar definieren
Schritt 2: API-Spezifikation erstellen
Verwenden Sie die OpenAPI-Spezifikation, um API-Schnittstellen zu definieren, und KI kann anhand der Spezifikation API-Code generieren
Schritt 3: UI-Spezifikation schreiben
Beschreiben Sie das Interface-Design detailliert und nutzen Sie Tools wie v0, um UI-Code zu generieren
Schritt 4: Verwenden Sie Cursor, um Code zu generieren
Gib PRD, API Spec und UI Spec an Cursor Agent weiter, um den vollständigen Code zu generieren
Schritt 5: Testen und Optimieren
Erstellen Sie auf Grundlage der Spec Testfälle, um zu überprüfen, ob die Funktionalität die Anforderungen der Spec erfüllt
WBS-Zerlegung
Die WBS (Work Breakdown Structure) zerlegt große Aufgaben in ausführbare kleinere Aufgaben, macht Abhängigkeiten zwischen Aufgaben klar und erleichtert Projektmanagement sowie Fortschrittsverfolgung.
Prinzipien der Aufgabenzerlegung
Granularitätssteuerung
- • 2-4-Stunden-Prinzip: Jede Aufgabe sollte innerhalb von 2–4 Stunden abgeschlossen werden
- • Testbarkeit: Jede Aufgabe hat klare Abnahmekriterien
- • Unabhängigkeit：Abhängigkeiten zwischen Aufgaben so weit wie möglich reduzieren
- • Abschätzbar: kann die Fertigstellungszeit genau abschätzen
Abhängigkeiten
- • Abhängigkeiten identifizieren：Die Abhängigkeiten zwischen den Aufgaben klar festlegen
- • Kritischer Pfad: Den kritischen Pfad des Projekts identifizieren und zuerst abschließen
- • Parallele Aufgaben: Aufgaben identifizieren, die parallel ausgeführt werden können
- • Abhängigkeitsverwaltung：Verwenden Sie Tools (z. B. GitHub Projects), um Abhängigkeiten zu verwalten
Zeitschätzung
Drei-Punkte-Schätzung
Schätzformel:(optimistische Zeit + 4×wahrscheinlichste Zeit + pessimistische Zeit) / 6
Beispiel: optimistisch 2 Stunden, am wahrscheinlichsten 4 Stunden, pessimistisch 8 Stunden → Schätzung = (2 + 4×4 + 8) / 6 = 4,3 Stunden
Schätzung per Analogie
Orientieren Sie sich an der Bearbeitungszeit ähnlicher Aufgaben und passen Sie sie an die Komplexität der aktuellen Aufgabe an.
KI-gestützte Schätzung
KI-Tools verwenden, um die Aufgabenkomplexität zu analysieren und historische Daten zur Zeitschätzung heranzuziehen.
Ressourcenzuweisung
Personalzuweisung
- • Aufgaben anhand von Fähigkeiten und Erfahrung zuweisen
- • Die Arbeitslast der Mitarbeitenden berücksichtigen
- • Sicherstellen, dass für kritische Aufgaben Ersatzpersonal vorhanden ist
Werkzeugzuweisung
- • Sicherstellen, dass genügend Entwicklungstools und Ressourcen vorhanden sind
- • Lizenz und Kosten des Tools berücksichtigen
- • Einen Ausweichplan vorbereiten
Zeitaufteilung
- • Den Projekttermin berücksichtigen
- • Pufferzeit für Risiken einplanen
- • Parallele Aufgaben und serielle Aufgaben ausbalancieren
Praxisfall: Beispiel einer WBS-Zerlegung
Kritischer Pfad: 1 → 2.1 → 3.2 → 4.2 → 5 (Gesamtdauer ca. 34 Stunden)
DoD-Definition
DoD (Definition of Done) definiert die Kriterien für den Abschluss einer Aufgabe, stellt die Lieferqualität sicher und verhindert Situationen, in denen etwas „fertig aussieht, aber in Wirklichkeit nicht fertig ist“.
Qualitätsstandards
Codequalität
- • ESLint-Prüfungen bestehen, ohne schwerwiegende Warnungen
- • Der Code entspricht den Teamstandards
- • Der Code hat die Codeüberprüfung bestanden
- • Keine bekannten Fehler
Testabdeckung
- • Einheitstestabdeckung >80%
- • Wichtige Funktionen verfügen über Integrationstests
- • Alle Tests bestanden
- • Die Qualität des Testcodes erfüllt die Anforderungen
Die Dokumentation ist vollständig
- • Die API-Dokumentation ist vollständig
- • Code-Kommentare sind ausreichend
- • Benutzerhandbuch aktualisieren
- • Änderungsprotokoll aktualisiert
Leistungsmetriken
- • Seitenladezeit <2 Sekunden
- • API-Antwortzeit <500 ms
- • Optimierung von Datenbankabfragen
- • Keine Speicherlecks
Akzeptanzkriterien
Funktionsabnahme
- • Alle Funktionen gemäß der Spec implementieren
- • Die Akzeptanzkriterien der User Story sind erfüllt
- • Die Behandlung von Randfällen ist korrekt
- • Verbesserte Fehlerbehandlung
Performance-Abnahme
- • Die Leistungskennzahlen erfüllen die Anforderungen
- • Lasttest bestanden
- • Stresstest bestanden
- • Die Leistungsüberwachung ist normal
Sicherheitsabnahme
- • Durch Sicherheitsscans
- • Keine kritischen Schwachstellen
- • Die Datenverschlüsselung ist korrekt
- • Korrekte Berechtigungssteuerung
Praxisfall: DoD-Checkliste
Lernergebnisse
Nach Abschluss dieses Kapitels werden Sie:
- 1Die Methodik zur Anforderungsklärung beherrschen (Reverse Interview, User Stories, Priorisierung) und echte Bedürfnisse herausarbeiten können
- 2Die technischen Praktiken der Spec-getriebenen Entwicklung verstehen und klare PRDs, API-Specs und UI-Specs verfassen können
- 3Beherrschen Sie die WBS-Zerlegungsmethode und können Sie Aufgaben sinnvoll aufteilen, Zeit schätzen und Ressourcen zuweisen
- 4Die DoD-Qualitätsstandards verstehen, Abnahmekriterien definieren und die Lieferqualität sicherstellen
- 5Verfügt über Fähigkeiten im Projektmanagement und in der Qualitätskontrolle auf Enterprise-Niveau und kann so eine erfolgreiche Projektablieferung sicherstellen