Propósito
El Product Engineer utiliza agentes de programación para convertir el comportamiento previsto aprobado en software en funcionamiento, manteniendo la responsabilidad de lo construido. El ciclo de implementación debe ser incremental, observable y coherente con las restricciones permanentes del proyecto.
Rol responsable: Product Engineer.
Participantes: Agente de programación; arquitecto o diseñador de UX cuando las decisiones los requieran.
Entradas: Especificaciones actuales de funcionalidades, objetivos del proyecto, instrucciones y recursos aprobados, comportamiento del producto existente, restricciones identificadas.
Resultados: Implementación en funcionamiento, pruebas automatizadas habituales asociadas, especificaciones actualizadas cuando cambia el comportamiento y una relación clara de los problemas sin resolver.
Procedimiento
1. Elegir una porción implementable. Seleccione un conjunto coherente de comportamientos de una funcionalidad con suficiente contexto circundante. Las funcionalidades grandes pueden implementarse de forma incremental, pero conserve la relación con la especificación que las rige.
2. Proporcionar la fuente de referencia. Indique al agente que lea las instrucciones permanentes del proyecto y las especificaciones pertinentes. Identifique el comportamiento requerido, las condiciones de aceptación y cualquier límite que no resulte ya evidente en el contexto del proyecto.
3. Pedir implementación, no decisiones de política sin respaldo. El agente puede proponer una estrategia de implementación y reutilizar componentes existentes. No debe inventar permisos empresariales ni introducir nuevas dependencias, arquitectura o convenciones de sistema de diseño sin la aprobación necesaria.
4. Inspeccionar el comportamiento funcional. Ejercite usted mismo el resultado con flujos realistas y datos representativos. Compruebe el camino satisfactorio y las excepciones significativas. Leer un resumen de archivos generados no equivale a validar la experiencia.
5. Iterar con comentarios concretos. Comunique el comportamiento observado y lo que debería ocurrir en su lugar. Distinga un defecto de implementación de un cambio de intención de las partes interesadas. Si cambia el comportamiento previsto, actualice la especificación antes de la siguiente iteración de implementación o junto con ella.
6. Conservar la mantenibilidad. Utilice bibliotecas y componentes aprobados, mantenga el código comprensible, conserve comprobaciones automatizadas habituales y evite la proliferación innecesaria de implementaciones similares. Involucre al arquitecto para consecuencias estructurales o de seguridad que superen la autoridad del Product Engineer.
7. Registrar claramente el trabajo sin resolver. No oculte flujos incompletos, limitaciones de acceso, pruebas fallidas ni suposiciones sin aprobar. Hágalos visibles para su revisión y verificación posteriores.
Ejemplo de solicitud de implementación
«Implemente el comportamiento descrito en la especificación de funcionalidad SPEC-002 utilizando las instrucciones existentes del proyecto y los componentes aprobados. No invente reglas de aprobación nuevas ni introduzca dependencias. Muestre cualquier ambigüedad sin resolver antes de implementarla. Incluya comprobaciones automatizadas adecuadas y resuma qué comportamiento puede ejercitarse ahora».
Este es un ejemplo de solicitud productiva, no una sintaxis obligatoria. La especificación, y no la redacción de la solicitud, sigue siendo la referencia duradera del producto.
Criterios de finalización
El comportamiento pertinente puede demostrarse, sus requisitos aceptados siguen especificados con precisión, se han realizado las comprobaciones automatizadas habituales y los problemas importantes están identificados antes de pasar el trabajo a la revisión técnica o de las partes interesadas.
Problemas habituales que conviene evitar
Aceptar ciegamente los resúmenes generados; realizar lotes grandes de cambios imposibles de revisar; tratar la conjetura de un agente como una decisión de política; permitir que componentes a medida convenientes eludan los recursos aprobados; y no sincronizar las especificaciones después de cambios aprobados de comportamiento.