Principios del marco SHAPE
Estos principios explican qué hace reconocible una implementación del marco SHAPE. Los detalles de las herramientas, las plantillas y las listas de revisión pueden variar, pero estos compromisos deben seguir siendo visibles.
1. Partir de la intención empresarial. El desarrollo de productos comienza por comprender el problema, las personas afectadas y el resultado esperado. Producir código no demuestra por sí mismo que se haya satisfecho una necesidad empresarial.
2. Mantener la responsabilidad humana. Los agentes de programación pueden implementar y proponer soluciones. Los Product Engineers y los especialistas siguen siendo responsables de los requisitos, las decisiones técnicas importantes, la validación y la aceptación.
3. Especificar el comportamiento previsto. Mantener especificaciones de funcionalidades con control de versiones. Revisar y actualizar las especificaciones cuando cambie el comportamiento. No tratar los mensajes sin estructurar ni los historiales de conversación como el único registro duradero de los requisitos del producto.
4. Utilizar primero los recursos empresariales aprobados. Reutilizar bibliotecas, componentes, servicios, capacidades de seguridad y patrones obligatorios. Introducir nueva tecnología compartida o cambiar estándares requiere la revisión y la autorización correspondientes.
5. Aplicar técnicamente los límites de los agentes. Las instrucciones escritas por sí solas no restringen el acceso de un agente. Los entornos aprobados, los permisos y las restricciones de herramientas son controles necesarios.
6. Preferir la retroalimentación sobre software funcional a una predicción inicial exhaustiva. Establecer una orientación inicial de UX y restricciones técnicas suficientes y, después, perfeccionar el comportamiento mediante software en funcionamiento y la revisión de las partes interesadas.
7. Verificar de forma independiente contra las especificaciones. Utilizar un contexto de verificación separado para derivar y ejecutar comprobaciones a partir de requisitos registrados en el repositorio. Registrar qué se verificó, qué falló y qué sigue siendo incierto.
8. Conservar la revisión especializada. Los arquitectos y los diseñadores de UX participan cuando se necesitan sus conocimientos. El desarrollo inicial incluye revisiones del arquitecto; las revisiones posteriores siguen la política empresarial y el riesgo aplicables.
9. Mantener una responsabilidad del producto continua y limitada. Los Product Engineers siguen siendo responsables de las aplicaciones que mantienen, incluidos sus cambios futuros. Limitar las carteras para que el mantenimiento y el trabajo nuevo sigan siendo manejables.
10. Mejorar el sistema compartido. Aprender de cada proyecto. Incorporar patrones útiles a los recursos compartidos mediante la gobernanza arquitectónica correspondiente, en lugar de resolver repetidamente los mismos problemas de forma aislada.
11. Mantener la proporcionalidad al riesgo. El marco no es una excusa para eludir controles ni una invitación a añadir formalidades a cada decisión menor. Utilizar garantías más sólidas cuando lo exijan el riesgo de la aplicación o las políticas.
12. Respetar los límites del proceso. El ciclo de desarrollo SHAPE abarca desde la recepción de requisitos hasta las UAT. La publicación y las operaciones posteriores a las UAT continúan bajo los procedimientos establecidos de la empresa.
Cómo interpretar estos principios
Un principio describe un requisito o una preferencia duraderos. Una guía para profesionales describe una forma de llevarlo a cabo. Por ejemplo, la verificación independiente forma parte del marco; el entorno de pruebas o el formato del informe de pruebas pueden variar según la organización. Del mismo modo, los límites de ejecución aprobados son obligatorios, mientras que la empresa elige su implementación concreta.