Entiendo los picos como tareas de investigación cuando hay una incertidumbre sobre cómo se debe hacer una historia, pero mi pregunta es más sobre cómo incluir una tarea de arquitectura de software en un Sprint.
Como ejemplo, estamos comenzando un nuevo proyecto, trabajando con conceptos de arquitectura de diseño controlado por dominio (DDD). Para este nuevo proyecto, no quiero que el equipo de desarrollo comience a codificar antes de definir cómo se verá la estructura de back-end. Es posible que deseen incluir algunos conceptos basados en eventos, etc. en la estructura y, para llegar a esta conclusión, necesito que el arquitecto lo piense y analice las soluciones con el equipo de desarrollo de back-end.
¿Cómo, como propietario del producto, debo incluir esas tareas de diseño/arquitectura en el Sprint?
Esto no es competencia del propietario del producto (PO).
Al PO no debería importarle cómo se construye el producto, esa preocupación recae en el Equipo de Desarrollo. El PO solo debe preocuparse por lo que se construye y en qué orden .
En mi experiencia, las tareas puramente de desarrollo como estas deben ser creadas por el equipo de desarrollo, no por el PO.
Si algo puede expresarse de una manera que proporcione un valor comercial directo , entonces debería ser una Historia creada por la OP. Si no (como creo que es el caso aquí), entonces debería ser una tarea creada por el equipo de desarrollo.
Ahora, puede dar sugerencias al equipo de desarrollo, pero tenga en cuenta que administrar tales tareas no debe ser parte de sus responsabilidades.
Esta es una pregunta para la que siempre he estado buscando una respuesta. Con mi experiencia con esto, es como estoy manejando:
Este tipo de tareas técnicas se consideran 'criterios de aceptación'. O puede tener una historia basada en su infra-requisito, como:
"Como (rol), necesito que el sistema responda bien cuando hay una carga de 10 000 solicitudes simultáneas"
O
Puedes tener una tarea/subtarea de la historia (asumiendo que estás usando una herramienta como JIRA).
Jon
Sarov