DE
Menü
Framework-Referenz

Grundprinzipien

Die Verpflichtungen, die Menschen, Artefakte, Agentengrenzen und Entwicklungszyklen des SHAPE Frameworks bestimmen.

Prinzipien des SHAPE Frameworks

Diese Prinzipien erklären, woran eine Umsetzung des SHAPE Frameworks erkennbar ist. Einzelheiten bestimmter Werkzeuge, Vorlagen und Prüflisten können variieren; diese Verpflichtungen sollten jedoch sichtbar bleiben.

1. Bei der geschäftlichen Absicht beginnen. Produktentwicklung beginnt damit, das Problem, die betroffenen Menschen und das erwartete Ergebnis zu verstehen. Das Erzeugen von Code belegt noch nicht, dass ein geschäftlicher Bedarf erfüllt wurde.

2. Menschen verantwortlich halten. Coding-Agenten dürfen implementieren und Lösungen vorschlagen. Product Engineers und Spezialisten bleiben für Anforderungen, folgenreiche technische Entscheidungen, Validierung und Abnahme verantwortlich.

3. Beabsichtigtes Verhalten spezifizieren. Pflegen Sie versionierte Funktionsspezifikationen. Prüfen und aktualisieren Sie Spezifikationen bei Verhaltensänderungen. Unstrukturierte Prompts oder Chatverläufe dürfen nicht die einzige dauerhafte Aufzeichnung der Produktanforderungen sein.

4. Zuerst freigegebene Unternehmensbausteine nutzen. Verwenden Sie vorgeschriebene Bibliotheken, Komponenten, Dienste, Sicherheitsfunktionen und Muster wieder. Die Einführung neuer gemeinsamer Technologien oder Änderungen an Standards erfordern angemessene Prüfung und Autorisierung.

5. Agentengrenzen technisch durchsetzen. Schriftliche Anweisungen allein beschränken den Zugriff eines Agenten nicht. Freigegebene Umgebungen, Berechtigungen und Werkzeugbeschränkungen sind notwendige Kontrollen.

6. Feedback an funktionierender Software einer vollständigen Vorhersage vorziehen. Schaffen Sie ausreichende anfängliche UX-Ausrichtung und technische Beschränkungen und verfeinern Sie das Verhalten anschließend anhand funktionierender Software und Stakeholder-Prüfung.

7. Unabhängig anhand von Spezifikationen verifizieren. Nutzen Sie einen gesonderten Verifikationskontext, um Prüfungen aus eingecheckten Anforderungen abzuleiten und auszuführen. Dokumentieren Sie, was verifiziert wurde, was fehlgeschlagen ist und was ungewiss bleibt.

8. Fachliche Prüfung bewahren. Architekten und UX-Designer wirken dort mit, wo ihre Expertise benötigt wird. Die Erstentwicklung umfasst Architektenprüfungen; spätere Prüfungen richten sich nach Unternehmensrichtlinien und Risiko.

9. Produktverantwortung durchgehend und begrenzt halten. Product Engineers bleiben für ihre Anwendungen einschließlich künftiger Änderungen verantwortlich. Begrenzen Sie Portfolios so, dass Wartung und neue Arbeit beherrschbar bleiben.

10. Das gemeinsame System verbessern. Lernen Sie aus jedem Projekt. Übernehmen Sie nützliche Muster durch geeignete Architektur-Governance in gemeinsame Bausteine, statt dieselben Probleme wiederholt isoliert zu lösen.

11. Dem Risiko angemessen bleiben. Das Framework rechtfertigt weder das Umgehen von Kontrollen noch zusätzlichen Formalismus für jede Kleinigkeit. Nutzen Sie stärkere Nachweise, wenn Anwendungsrisiko oder Richtlinien dies erfordern.

12. Die Prozessgrenze respektieren. Der SHAPE-Entwicklungszyklus reicht von der Anforderungsaufnahme bis zum UAT. Release und Betrieb nach dem UAT folgen weiterhin den etablierten Unternehmensverfahren.

Diese Prinzipien verstehen

Ein Prinzip beschreibt eine dauerhafte Anforderung oder Präferenz. Ein Praxisleitfaden beschreibt eine mögliche Umsetzung. Unabhängige Verifikation gehört beispielsweise zum Framework; die konkrete Testumgebung oder das Testberichtsformat kann je nach Organisation variieren. Ebenso sind freigegebene Ausführungsgrenzen verpflichtend, während das Unternehmen ihre konkrete Umsetzung wählt.