Zyklus 1: Erstentwicklung

Zyklus 1 führt ein Produkt von der Anforderungsaufnahme bis zur fachlichen Abnahme und schafft dabei technisches und produktbezogenes Wissen, das spätere Änderungen wiederverwenden können. UX-Ausrichtung, Vorbereitung der technischen Grundlage und Spezifikationserstellung erfolgen nach Bedarf parallel vor und während der frühen Implementierung. Der Product Engineer koordiniert die Iteration. Zwei Architektenprüfungen der Implementierung sichern die technische Qualität vor und nach wesentlichem Stakeholder-Feedback.

Leitung: Product Engineer. Teilnehmer: Fachliche Stakeholder, Domänenexperten; bei Bedarf Architekt oder UX-Designer.

Beginnen Sie beim tatsächlichen Problem. Ermitteln Sie Stakeholder, vorgesehene Benutzer, Abläufe, heutige Schwierigkeiten, gewünschte Ergebnisse, organisatorische Beschränkungen und was außerhalb des anfänglichen Umfangs liegt. Verwechseln Sie eine vorgeschlagene Funktion nicht mit dem dahinterliegenden Geschäftsziel. Erfassen Sie Ziele und offene Fragen und identifizieren Sie Entscheidungen, die einen Geschäftsverantwortlichen benötigen.

Ergebnis: Ein gemeinsames Problemverständnis und eine erste Beschreibung von Produktzielen, Grenzen und wesentlichen Abläufen. Die Discovery kann bei neuen Fragen fortgesetzt werden.

Verantwortliche: Product Engineer, Architekt / Senior Engineer und UX-Designer; die Verantwortung richtet sich nach dem Fachgebiet.

UX-Ausrichtung. Legen Sie zentrale Benutzerabläufe, Interaktionsprinzipien, relevante Einschränkungen der Benutzererfahrung und geeignete bestehende Designsystem-Muster fest. Schaffen Sie genügend frühe Orientierung für produktive Implementierung, ohne jede Ansicht vollständig vorab gestalten zu müssen.

Technische Grundlage. Der Architekt bestimmt den geeigneten unternehmensweit freigegebenen Stack und wiederverwendbare Fähigkeiten, legt erste Architekturgrenzen fest und sorgt gemeinsam mit den zuständigen Verantwortlichen für eine geeignete, technisch beschränkte Agentenausführungsumgebung. Dokumentieren Sie projektspezifische Entscheidungen und stellen Sie sicher, dass dauerhafte Anweisungsdateien stimmig und auffindbar sind. Der Umfang der Architekturvorbereitung richtet sich nach Komplexität, Risiko und Neuartigkeit der Arbeit.

Spezifikationserstellung. Der Product Engineer formuliert versionierte Funktionsspezifikationen mithilfe von Stakeholder-Gesprächen und, wo hilfreich, dialogbasierter KI. Beschreiben Sie beobachtbares Verhalten, wichtige Regeln, Berechtigungen, Ausnahmen und Akzeptanzbedingungen. Klären Sie folgenreiche geschäftliche Ungewissheit mit autorisierten Stakeholdern, statt einen Coding-Agenten Richtlinien erfinden zu lassen.

Die drei Aktivitäten beeinflussen einander: Eine technische Einschränkung kann einen vorgeschlagenen Ablauf verändern; eine UX-Erkundung oder ein Spezifikationsgespräch kann eine übersehene Regel aufdecken. Die Vorbereitung genügt, wenn das Team mit freigegebenen Fähigkeiten und Zugriffsgrenzen sinnvoll implementieren kann und wesentliche offene Entscheidungen erkannt und vom zuständigen Verantwortlichen behandelt werden.

Ergebnis: Nützliche UX-Ausrichtung, ein erster gepflegter Spezifikationsbestand und eine ausreichend für autorisierte Implementierung vorbereitete Projektumgebung. SHAPE verlangt in dieser Phase weder ein gesondert benanntes Architecture Readiness Review noch eine formale Bereitschaftsfreigabe.

Verantwortlich: Product Engineer. Implementierung: KI-Coding-Agent.

Leiten Sie den Coding-Agenten mit den etablierten Spezifikationen, der freigegebenen technischen Grundlage und auffindbaren Projektanweisungen an. Implementieren Sie zusammenhängende Schritte funktionierenden Verhaltens. Der Product Engineer erprobt relevante Abläufe, prüft Ergebnisse, klärt Anforderungen und veranlasst Korrekturen. Änderungen am beabsichtigten Verhalten müssen in den Spezifikationen festgehalten werden; gewöhnliche Codeumstrukturierung ohne Verhaltensänderung erfordert keine neue Funktionsspezifikation.

Ergebnis: Eine funktionierende Implementierung für eine sinnvolle technische Prüfung, deren bekannte Einschränkungen dokumentiert und nicht verborgen sind.

Leitung: Architekt / Senior Engineer. Zusammenarbeit: Product Engineer.

Prüfen Sie Struktur der Implementierung, Einsatz freigegebener Komponenten und Dienste, Sicherheitslage, Trennung der Verantwortlichkeiten, Wartbarkeit, Integrationsentscheidungen und weitere produktrelevante Risiken. Erkennen Sie wesentliche Probleme früh genug, damit Feedback-Iterationen nicht auf untragfähigen Grundlagen aufbauen. Der Product Engineer steuert Korrekturen, der Architekt bestätigt die Behebung kritischer Befunde.

Ergebnis: Eine technisch glaubwürdige Grundlage für substanzielles Stakeholder-Feedback.

Leitung: Product Engineer. Teilnehmer: Fachliche Stakeholder, gegebenenfalls UX-Designer, Coding-Agent zur Implementierung.

Zeigen Sie funktionierende Funktionen und bitten Sie Stakeholder, aussagekräftige Abläufe zu durchlaufen oder zu bewerten. Unterscheiden Sie Missverständnisse, fehlendes Verhalten, Bedienprobleme und tatsächlich neuen Umfang. Aktualisieren Sie die Spezifikationen entsprechend vereinbarter Änderungen und implementieren und prüfen Sie diese anschließend. Wiederholen Sie dies, bis Stakeholder das Produkt für formale Verifikation und Abnahmevorbereitung als bereit ansehen.

Ergebnis: Ein stimmiges Produkt, dessen Implementierung und Spezifikationen das nach dem Feedback vereinbarte Verhalten abbilden.

Leitung: Gesonderter Verifikationsagent oder -kontext; der Product Engineer bewertet die Befunde.

Leiten Sie Tests in einem unabhängigen Kontext aus den eingecheckten Spezifikationen ab, statt sich vollständig auf Vorschläge des Implementierungsagenten zu verlassen. Prüfen Sie laufende Anwendung, API und Benutzerabläufe nach Möglichkeit praktisch. Dokumentieren Sie Anforderungsabdeckung und Ergebnisse einschließlich bestandener, fehlgeschlagener und blockierter Prüfungen sowie offener Unklarheiten. Beheben Sie Fehler, aktualisieren Sie nötigenfalls Spezifikationen und wiederholen Sie betroffene Verifikation.

Ergebnis: Dokumentierte Nachweise der Übereinstimmung und eine ausdrückliche Darstellung verbleibender Einschränkungen. Spezifikationsbasiertes Testen kann nicht beweisen, dass eine unvollständige Spezifikation jeden Geschäftsbedarf erfasst.

Leitung: Architekt / Senior Engineer.

Prüfen Sie den finalen technischen Stand anhand früherer Befunde, Stakeholder-Änderungen, Verifikationsergebnisse und etwaiger Architektur- oder Sicherheitsfolgen der Iteration. Bestätigen Sie, dass wesentliche Befunde behoben oder gemäß geltender Richtlinie ausdrücklich behandelt wurden. Technische Freigabe betrifft Engineering-Bereitschaft; sie ist keine fachliche Abnahmeentscheidung des Stakeholders.

Ergebnis: Technische Prüfung für den UAT-Eintritt gemäß Unternehmensrichtlinien abgeschlossen.

Verantwortung: UAT- und fachlicher Abnahmeprozess des Unternehmens. Koordination: Product Engineer.

Übergeben Sie Produkt, Anforderungskontext, bekannte Einschränkungen und relevante Verifikationsnachweise in den bestehenden UAT-Prozess der Organisation. Autorisierte fachliche Stakeholder bestätigen, ob das Produkt den beabsichtigten Bedarf erfüllt, und entscheiden nach etablierter Praxis über die Abnahme. Führt der UAT zu Änderungen, gleichen Sie diese mit den Spezifikationen ab, implementieren Korrekturen und wiederholen die notwendigen Prüfungen.

Ergebnis: Eine dokumentierte fachliche Abnahmeentscheidung oder eine klare Liste zu lösender Probleme. Der durch SHAPE definierte Entwicklungszyklus endet hier.

Phasen beschreiben Verantwortung und wichtige Prüfungen, nicht acht isolierte Abteilungen oder die Aufforderung, Verständnis vorzeitig einzufrieren. Teams können frühere Materialien erneut aufgreifen. Entscheidend ist, dass akzeptierte Verhaltensänderungen die Spezifikationen aktualisieren, Agentenarbeit innerhalb freigegebener Grenzen bleibt und unabhängige technische und fachliche Prüfungen aussagekräftig bleiben.