Cambios continuos sin repetir la preparación inicial
Una vez que un producto tiene unos fundamentos técnicos aprobados, especificaciones mantenidas y una orientación de diseño conocida, el desarrollo posterior puede seguir un ciclo más breve. El Product Engineer sigue siendo responsable de los cambios en una cartera limitada de aplicaciones.
Etapa 1. Mejora de especificaciones e implementación
El Product Engineer recoge el cambio solicitado, aclara su efecto sobre los usuarios y el comportamiento existente, y actualiza o añade especificaciones de funcionalidades. El agente de programación implementa el cambio acordado dentro de las instrucciones, las bibliotecas aprobadas y la arquitectura existentes del proyecto. El Product Engineer comprueba el resultado e itera según sea necesario.
Las correcciones que cambian lo que deben experimentar los usuarios deben reflejarse en el conjunto de especificaciones. El mantenimiento sin efecto sobre el comportamiento sigue necesitando las comprobaciones de calidad adecuadas al cambio, pero no debe presentarse como una nueva funcionalidad empresarial.
Etapa 2. Pruebas independientes basadas en especificaciones
Un contexto de verificación separado examina las especificaciones pertinentes registradas en el repositorio, deriva pruebas y comprueba la aplicación modificada. Debe cubrir el cambio y los riesgos significativos de regresión en los comportamientos relacionados. Los hallazgos se corrigen o reciben un tratamiento explícito; el comportamiento modificado se vuelve a probar.
Etapa 3. Revisión del arquitecto según corresponda
El arquitecto revisa los cambios que cumplen los umbrales de riesgo o política de la organización. Algunos ejemplos son nuevas integraciones, cambios de permisos, cambios arquitectónicos importantes o cambios que afectan a bibliotecas empresariales compartidas. Las modificaciones habituales dentro de patrones aprobados pueden requerir menos revisión. El Product Engineer no exime de revisiones obligatorias por preferencia personal.
Etapa 4. UAT
Las partes interesadas del negocio realizan la aceptación conforme a las prácticas existentes de la organización. El Product Engineer coordina los problemas y registra el comportamiento aceptado en las especificaciones mantenidas. La publicación y las operaciones continúan fuera del ciclo de desarrollo SHAPE.
Cuándo el ciclo breve es insuficiente
Un rediseño fundamental, un nuevo límite de sistema o un cambio importante en las responsabilidades de seguridad pueden justificar descubrimiento, trabajo de UX, preparación y revisión adicionales similares a los del Ciclo 1. El propósito del marco es eliminar repeticiones innecesarias, no ignorar riesgos técnicos o empresariales reales.