Thema: Teil 12. MVP
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden (Theorie: 1,5 Stunden, Praxis: 2,5-4,5 Stunden)
Voraussetzungen: Abschluss mindestens zweier kleiner Feature-Phasen (aus vorherigen Kursteilen)
Verständnis der Struktur von Projektdokumenten: mission.md, tech-stack.md, roadmap.md
Erfahrung mit dem Versionskontrollsystem Git
Grundkenntnisse in Testen und CI-Prüfungen
Vertrautheit mit der Arbeit von Code-Agenten (Qwen Code oder vergleichbare)
Lernziele: Die Projektbereitschaft für die MVP-Phase anhand einer Checkliste mit 6 Kriterien bestimmen
Klare MVP-Grenzen formulieren, die „innerhalb" von „außerhalb" abgrenzen, mit mindestens 5 Punkten in jeder Kategorie
Die Technik der gruppierten MVP-Implementierung mit Erstellung von „grünen Punkten" für Rollbacks über Git-Tags anwenden
MVP-Abweichungsprüfungen mit automatischen und manuellen Kontrollen durchführen
Post-MVP-Analyse nutzen, um Spezifikationslücken aufzudecken und ProjektregeIn zu aktualisieren
Überblick: Die MVP-Phase ist ein kritischer Entwicklungsschritt mit Beteiligung eines Code-Agenten, bei dem statt schrittweiser Implementierung einzelner Features der verbleibende Teil des minimal lebensfähigen Produkts als Ganzes zusammengebaut wird. Im Unterschied zu normalen Feature-Phasen birgt das MVP ein erhöhtes Risiko: Der Agent verarbeitet gleichzeitig ein großes Volumen an Spezifikationen, was diese Phase zu einem leistungsstarken Stresstest der Reife der Projektdokumentation macht. Das Studienmaterial deckt die Bereitschaftskriterien für MVP, Risikomanagementtechniken, die Strukturierung von MVP-Spezifikationen, gruppierte Implementierung mit Kontrollpunkten, Timeboxing und Post-Analyse zur Verbesserung von ProjektregeIn ab.
Schlüsselkonzepte: MVP als Stresstest der Spezifikationen: Wenn der Agent, nachdem er alle Projektdokumente gelesen hat, nicht das erwartete Ergebnis liefert – liegt das Problem nicht beim Agenten, sondern in unzureichender Spezifikationsdetaillierung, übermäßiger Freiheit oder einer unklaren Roadmap. Das MVP deckt diese Probleme früher auf, bevor sie in der Produktion kritisch werden.
Bereitschaftskriterien für MVP: Mindestens zwei Features haben den vollständigen Zyklus durchlaufen; mission.md, tech-stack.md, roadmap.md sind aktuell; es existiert eine Testrichtlinie; ein Änderungsprotokoll wird geführt; das Team ist bereit zur Prüfung eines großen Änderungsvolumens; die Roadmap enthält klare MVP-Grenzen.
MVP-Grenzen: Klare Trennung zwischen dem, was in das MVP eingeht (Startseite, Kernfunktionen, Tests kritischer Routen) und dem, was außerhalb bleibt (Authentifizierung, Zahlung, externe Dienste, Admin-Oberfläche). Grenzen verhindern Scope-Creep.
Gruppierte Implementierung: Selbst eine einheitliche MVP-Spezifikation wird in Teilen – Aufgabengruppen – implementiert. Nach jeder Gruppe: Stopp, Prüfung, Commit, Tag des „grünen Punkts". Die nächste Gruppe darf Dateien der vorherigen nur bei Bedarf bearbeiten.
Grüne Punkte für Rollbacks: Git-Tags (z.B. mvp-green-1), die nach erfolgreichem Typecheck und Tests gesetzt werden. Bei Fehlfunktion der nächsten Gruppe – harter Rollback zum letzten grünen Punkt, statt Debuggen im „schmutzigen" Zustand.
Timeboxing der MVP-Sitzung: Festes Zeitbudget (2–4 Stunden für das Lern-MVP). Nach Ablauf – Stopp, Bewertung, bewusste Entscheidung, nicht „noch eine Gruppe".
Abweichungsprüfung: Strenge Prüfung, dass die MVP-Grenzen nicht überschritten wurden: Authentifizierung nicht hinzugefügt, Client-Framework nicht eingeführt, externe Dienste nicht erforderlich. Verhindert „schleichende Funktionsausweitung".
Post-MVP-Lückenanalyse: Frage an den Agenten: „Was musstest du selbst ableiten, weil es nicht explizit vorgegeben war?" Eine ehrliche Antwort ist ein Geschenk zur Verbesserung der Spezifikationen, kein Grund für Bestrafung.
Übungsaufgaben: Titel: MVP-Bereitschaftsaudit
Problem: Ihnen liegt die Projektbeschreibung „EcoTracker" vor – einer App zur Nachverfolgung ökologischer Gewohnheiten. Das Projekt verfügt über: roadmap.md (letzte Aktualisierung vor 3 Monaten), ein implementiertes Feature (Benutzerregistrierung), Tests nur für dieses Feature, fehlendes journal.md. Bewerten Sie anhand der Checkliste aus dem Material, ob das Projekt für die MVP-Phase bereit ist. Falls nicht – erstellen Sie einen Aktionsplan bis zur Erreichung der Bereitschaft mit Prioritäten und Fristen.
Lösung: 1. Prüfen Kriterium „mindestens zwei Features haben vollständigen Zyklus durchlaufen" – NEIN, nur ein Feature. 2. Prüfen Aktualität von roadmap.md – NEIN, vor 3 Monaten aktualisiert. 3. Prüfen Testrichtlinie – TEILWEISE, Tests nur für ein Feature. 4. Prüfen Änderungsprotokoll – NEIN, journal.md fehlt. 5. Prüfen Bereitschaft zur Prüfung großen Volumens – UNBESTIMMT. 6. Prüfen klare MVP-Grenzen in Roadmap – NICHT ÜBERPRÜFBAR aufgrund von Veraltung. URTEIL: nicht bereit. PLAN: (1) Zweites Feature im vollständigen Zyklus implementieren (1-2 Wochen); (2) roadmap.md mit klaren MVP-Grenzen aktualisieren (2-3 Tage); (3) Tests auf Richtlinie zur Abdeckung aller kritischen Pfade erweitern (1 Woche); (4) journal.md erstellen und befüllen (1 Tag); (5) Wiederholung des Bereitschaftsaudits.
Schwierigkeitsgrad: Mittelstufe
Titel: Formulierung von MVP-Grenzen
Problem: Entwickeln Sie ein Dokument „Anforderungen – MVP" für den Coworking-Buchungsservice „DeskShare". Der Service soll demonstrieren: Verfügbare Plätze anzeigen, Filterung nach Standorten, Platzkarte mit Foto und Ausstattung, Buchungsformular mit Datums-/Zeitauswahl, Buchungsbestätigung. Außerhalb der Grenzen bleiben: Zahlung, Kalenderintegrationen, persönlicher Nutzerbereich, Bewertungen und Rezensionen, mobile App. Formulieren Sie außerdem 3 technische Entscheidungen und 5 Punkte zur Abweichungsprüfung.
Lösung: GRENZEN INNERHALB: Platzkatalog mit Suche; Filter nach Städten und Ausstattung; Platzkarte mit Galerie; Buchungsformular (Datum, Zeit, Kontakte); Bestätigungsseite; responsives Layout; Tests der Katalog- und Buchungsrouten. AUSSERHALB DER GRENZEN: Zahlung (Buchung ohne Bezahlung); Integrationen mit Google/Apple Calendar; persönlicher Bereich (Buchung per E-Mail); Bewertungen und Rezensionen; native mobile App; SMS-Benachrichtigungen. ENTSCHEIDUNGEN: (1) Speicherung von Buchungen in SQLite mit E-Mail als Identifikator; (2) Serverseitiges Rendering aller Seiten, ohne React/Vue; (3) Foto-Upload über statische Dateien, ohne CDN. ABWEICHUNGSPRÜFUNG: Stripe/PayPal nicht verbunden; OAuth-Autorisierung nicht hinzugefügt; React/Vue/Angular nicht eingeführt; Firebase/AWS Lambda nicht verwendet; SMS-Gateway nicht integriert; clientseitige Routing nicht angewendet.
Schwierigkeitsgrad: Mittelstufe
Titel: Rollback-Szenario zum grünen Punkt
Problem: Sie implementieren ein MVP in 3 Gruppen. Nach Gruppe 1 (Agenten und Krankheiten) haben Sie einen Commit und Tag mvp-green-1 erstellt, Typecheck läuft durch. Bei Implementierung von Gruppe 2 (Therapien und Buchungsformular) hat der Agent „nebenbei" Dateien der Gruppe 1 geändert, und nun: (a) Tests der Gruppe 1 fallen durch; (b) git diff --stat zeigt Änderungen in 12 Dateien, von denen 4 in keinen Plan der Gruppen fallen; (c) der Agent schlägt vor, „gleich" Caching hinzuzufügen. Beschreiben Sie Ihre Schritte nacheinander, einschließlich Git-Befehlen und der Entscheidung über Fortsetzung/Rollback.
Lösung: 1. SOFORTIGER STOPP: Nicht dem „gleich" Caching zustimmen – das ist ein Zeichen der Grenzverwischung. 2. BEWERTUNG: Kritische Anzeichen – Tests der Gruppe 1 fallen durch, Dateien außerhalb des Plans geändert, Agent schlägt Grenzüberschreitung vor. 3. ZEITPRÜFUNG: Wenn <50% des Timeboxes verbraucht und Problem lokalisierbar – kann man versuchen, nur Änderungen der Gruppe 1 zurückzunehmen; sonst – vollständiger Rollback. 4. VOLLSTÄNDIGER ROLLBACK: git log --oneline zur Prüfung der Commits; git reset --hard mvp-green-1; git clean -fd falls der Agent neue Dateien erstellt hat; Prüfung: npm run typecheck muss durchlaufen. 5. URSACHENANALYSE: Spezifikation der Gruppe 2 war nicht detailliert genug und verbot nicht, Gruppe 1 zu ändern. 6. AKTION: Separate Feature „Präzisierung der MVP-Gruppenisolation" erstellen, plan.md überarbeiten mit explizitem Verbot der Bearbeitung von Dateien vorheriger Gruppen. 7. WIEDERHOLUNG: Gruppe 2 mit aktualisierter Spezifikation beginnen.
Schwierigkeitsgrad: Fortgeschritten
Titel: Post-MVP-Agentenbefragung
Problem: Erstellen Sie einen Prompt für Qwen Code auf Russisch, der nach MVP-Abschluss die impliziten Ableitungen des Agenten aufdeckt. Analysieren Sie dann die hypothetische Agentenantwort: „Ich habe selbst entschieden, localStorage zur Speicherung von Formular-Entwürfen zu nutzen, weil in der Spezifikation nicht angegeben war, wie abgebrochene Eingaben zu behandeln sind. Außerdem habe ich Debounce auf die Suche gelegt – das schien für UX offensichtlich, obwohl es in den Anforderungen nicht erwähnt war." Formulieren Sie, welche Aktualisierungen in welche Dokumente einzubringen sind.
Lösung: PROMPT: „Sag mir zur MVP-Implementierung, was du selbst ableiten musstest, weil es nicht explizit vorgegeben war. Liste Lücken in den Spezifikationen auf und schlage Aktualisierungen für mission.md, tech-stack.md, roadmap.md oder die MVP-Spezifikation vor. Dateien nicht ändern." ANALYSE DER ANTWORT: (1) localStorage für Entwürfe – Architekturentscheidung ohne Genehmigung; beeinflusst Datenschutz, Inkognito-Modus-Betrieb, Geräteübergreifende Synchronisation. (2) Debounce auf Suche – UX-Entscheidung mit technischen Folgen (Verzögerung, Anfragehäufigkeit). AKTUALISIERUNGEN: In specs/mission.md – Prinzip hinzufügen „Alle Entscheidungen zur Speicherung des Benutzerzustands werden explizit abgestimmt"; in specs/tech-stack.md – Zulässige Mechanismen für clientseitige Speicherung angeben (oder deren Fehlen); in specs/YYYY-MM-DD-mvp/requirements.md – Verhalten bei abgebrochener Eingabe explizit beschreiben („Entwürfe werden nicht gespeichert, Formular wird zurückgesetzt"); in validation.md – Abweichungsprüfung „localStorage wird nicht verwendet" hinzufügen; in tech-stack.md oder roadmap.md – Debounce als separate UX-Feature mit messbaren Parametern auslagern (Verzögerung in ms).
Schwierigkeitsgrad: Mittelstufe
Fallstudien: Titel: AgentClinic: Vom Scheitern des ersten MVP zur kontrollierten Implementierung
Szenario: Ein Startup entwickelt die Demo-Anwendung AgentClinic – einen Simulator einer medizinischen Klinik mit KI-Agenten. Nach zwei erfolgreichen kleinen Phasen (Agenten-Seite, Krankheits-Seite) beschließt das Team, zu beschleunigen und die verbleibende Funktionalität in einer einzigen Anfrage an Qwen Code zu implementieren.
Herausforderung: Die erste MVP-Anfrage ohne Vorbereitung führte zu: (1) Hinzufügen von Authentifizierung „nebenbei", obwohl sie außerhalb der Grenzen lag; (2) Einführung von React auf dem Client, trotz serverseitigem Rendering in tech-stack; (3) 47 geänderten Dateien ohne Verständnis, was zu welchem Feature gehört; (4) Fehlschlagender Tests, die vor dem MVP noch durchliefen; (5) 6 Stunden erfolgloses Debuggen – das Team verlor die Orientierung.
Lösung: Das Team wandte die Methodik aus Teil 12 an: (1) Rollback zum letzten stabilen Commit vor dem MVP; (2) Erstellung einer vollständigen MVP-Spezifikation mit expliziten Grenzen; (3) Aufteilung in 4 Gruppen: Startseite+Navigation, Therapien, Buchungsformular, Verwaltungspanel; (4) Timebox von 3 Stunden pro Gruppe; (5) Git-Tags mvp-green-1, mvp-green-2 usw. nach jeder Gruppe; (6) Strenge Abweichungsprüfung nach jeder Gruppe.
Ergebnis: Das zweite MVP wurde in 10 Stunden abgeschlossen (4 Gruppen × 2,5 Stunden Durchschnitt). Alle Tests liefen durch. Authentifizierung und Client-Frameworks drangen nicht in den Code ein. Das Änderungsprotokoll enthielt eine klare Historie. Die Post-Analyse deckte 7 implizite Agentenentscheidungen auf, die in aktualisierten Spezifikationen formalisiert wurden.
Gelernte Lektionen: Das erste „schnelle" MVP ohne Spezifikation beanspruchte 6 Stunden und führte zu einem Rollback; das zweite, methodische – 10 Stunden mit funktionierendem Ergebnis. Zeitersparnis bei der Vorbereitung ist eine Illusion.
Git-Tags der „grünen Punkte" retteten 2 Mal: Bei Fehlfunktion der Gruppe 3 dauerte der Rollback zu mvp-green-2 30 Sekunden statt Stunden des Debuggings.
Die Abweichungsprüfung nach Gruppe 2 erwischte den Versuch des Agenten, Caching hinzuzufügen – frühes Aufdecken verhinderte Ansammlung technischer Schulden.
Die Post-MVP-Befragung deckte auf, dass der Agent „selbst entschieden" hatte, einen bestimmten Templating-Engine zu verwenden – das führte zu einer Präzisierung von tech-stack.md, die ähnliche Probleme in folgenden Projekten verhinderte.
Verwandte Konzepte: MVP als Stresstest der Spezifikationen
Gruppierte Implementierung
Grüne Punkte für Rollbacks
Timeboxing der MVP-Sitzung
Abweichungsprüfung
Post-MVP-Lückenanalyse
Titel: EduPlatform: Wenn die Ablehnung des MVP die richtige Entscheidung war
Szenario: Ein Bildungsprojekt entwickelt eine Plattform für Online-Kurse. Nach einem implementierten Feature (Kurskatalog-Anzeige) besteht der Product Owner auf „Beschleunigung durch MVP" für eine Investorendemo in einer Woche.
Herausforderung: Die Bereitschaftsanalyse zeigte: roadmap.md fehlt (es gibt nur „Vision" im Kopf des Gründers); Tests existieren nur für den Katalog; kein Änderungsprotokoll vorhanden; der Agent fügte in der vorherigen Feature-Phase zweimal „Nützlichkeiten" außerhalb der Spezifikation hinzu. Klassische Anzeichen der MVP-Nichtbereitschaft.
Lösung: Das Team lehnte das MVP zugunsten zweier zusätzlicher kleiner Phasen ab: (1) Benutzerregistrierungssystem mit vollständigem Testzyklus; (2) Videoplayer mit Lernfortschritt. Parallel: Formalisierung von roadmap.md mit klaren Grenzen des zukünftigen MVP, Erstellung von journal.md, Einführung einer Testrichtlinie (Abdeckung >80% kritischer Pfade).
Ergebnis: Die Investorendemo fand nach 3 statt 1 Woche statt, zeigte aber ein stabiles, vorhersagbares Produkt. Die MVP-Phase, als sie schließlich gestartet wurde, verlief ohne Rollbacks und 2 Stunden unter dem geplanten Timebox. Die Investoren hoben den „professionellen Entwicklungsansatz" als Vertrauensfaktor hervor.
Gelernte Lektionen: Zeitdruck ist der schlechteste Grund für ein vorzeitiges MVP; ein unvorbereitetes MVP riskiert, Chaos statt Produkt zu zeigen.
Zwei zusätzliche kleine Phasen (2 Wochen) sparten potenzielle 1-2 Wochen Debuggen nach einem gescheiterten MVP ein.
Die Formalisierung von Dokumenten im Prozess kleiner Phasen erwies sich als effektiver als der Versuch, alles „für das MVP" zu schreiben – Dokumente wurden in der Praxis geprüft.
Ein zu „Nützlichkeiten" neigender Agent erfordert besonders strenge MVP-Grenzen; die frühe Fixierung dieses Verhaltens in den ProjektregeIn verhinderte Probleme später.
Verwandte Konzepte: Bereitschaftskriterien für MVP
Timeboxing der MVP-Sitzung
MVP als Stresstest der Spezifikationen
Studientipps: Arbeiten Sie die MVP-Bereitschaftscheckliste auf Papier oder in einer Tabelle ab – nicht aus dem Gedächtnis. Das physische Abhaken jedes Punkts verringert die Versuchung „naja, fast bereit".
Üben Sie das Schreiben des Prompts für Qwen Code exakt nach dem Vorlage aus dem Material, einschließlich /clear und der Struktur „zuerst Analyse, dann Plan, dann Code". Abweichungen von der Vorlage sind ein häufiger Grund für unvorhersagbares Agentenverhalten.
Erstellen Sie eine persönliche „Rollback-Karte" – Spickzettel mit Git-Befehlen: git commit -m '...', npm run typecheck, git tag mvp-green-N, git reset --hard mvp-green-N. In stressigen Situationen ist ein fertiger Spickzettel wertvoller als das Gedächtnis.
Für visuelle Wahrnehmung: Zeichnen Sie ein MVP-Gruppendiagramm mit „grünen Punkten" als Ampel. Rot – aktuelle Arbeit, Gelb – in Prüfung, Grün – getaggt. Aktualisieren Sie den Status in Echtzeit.
Rollenspiel-Praxis: Bitten Sie einen Kollegen oder nutzen Sie „Doppelkontrolle" – einer spielt die Rolle des Agenten, der „nebenbei verbessern" will, der andere muss standhaft bleiben und die Abweichungsprüfung anwenden.
Führen Sie parallel zum offiziellen ein „MVP-Tagebuch": Fixieren Sie den emotionalen Zustand, Momente der Versuchung „noch eine Gruppe", Ist-Zeit vs. Timebox. Das sind Daten zur Verbesserung Ihrer Selbsteinschätzung.
Führen Sie nach jeder Übung eine „5 Warum"-Analyse durch: Warum hat der Agent X gemacht? Warum hat die Spezifikation das nicht verhindert? Warum hat die Prüfung es nicht erwischt? Und so weiter bis zur Wurzelursache.
Zusätzliche Ressourcen: Originalmaterial des Kurses – Teil 12: Vollständiger Text mit Prompt-Beispielen und MVP-Dokumentvorlagen
Git-Dokumentation zu Tags: https://git-scm.com/book/en/v2/Git-Basics-Tagging – für vertieftes Verständnis von annotierten und leichten Tags
Artikel „The Lean Startup" von Eric Ries (Kapitel über MVP): Klassische Basis der Konzeption des minimal lebensfähigen Produkts, angepasst für den Kontext der Agenten-Entwicklung
Qwen Code-Dokumentation: Offizielle Empfehlungen zur Arbeit mit Kontext und Dateiverweisen (@Datei)
Vorlagen für Projektdokumente (Mission, Tech-Stack, Roadmap): Beispiele aus vorherigen Kursteilen zum Vergleich der Dokumentationsreife
Interaktiver Git-Trainer: https://learngitbranching.js.org/?locale=de_DE – zum Üben von Rollback- und Tagging-Szenarien
Zusammenfassung: Die MVP-Phase mit einem Code-Agenten ist keine Beschleunigung durch Skalierung, sondern ein kontrolliertes Risiko, das Reife der Projektdokumentation erfordert. Schlüsselprinzipien: (1) Nicht ohne zwei durchlaufene kleine Phasen und aktuelle Dokumente beginnen; (2) MVP-Grenzen als explizite Ein- und Ausschlüsse formalisieren; (3) In Gruppen mit „grünen Punkten" für Rollbacks implementieren; (4) Timebox anwenden und harten Rollback bei Verstößen; (5) Abweichungen prüfen – was NICHT hinzugefügt wurde; (6) Nach MVP implizite Agentenentscheidungen extrahieren zur Spezifikationsverbesserung. MVP – Stresstest Ihrer Entwurfsdisziplin, nicht nur des Agenten-Codes.