Uso de cookies
Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies
ACEPTAR
Otra alternativa de solución que se me ocurre es:
Como ingeniero de producto de la api
Quiero que la api brinde información de los 10 productos mas vendidos
Para que cualquier front end o aplicación que quiera consumir la api, pueda contar con esa información
Criterios de aceptación:
– Que se pueda indicar un rango de fechas para calcular los 10 mas vendidos
– Que se provea en formato xml
…
Hola Fernando.
Efectivamente, esa es una posibilidad, siempre y cuando la API se cree para ser consumida por otra aplicación. Este ejemplo lo encontramos en un cliente que, por hacer las historias más pequeñas, partía entre Front y API. La explicación que tenían era que esa API, en algún momento, sería abierta y consumible por otras aplicaciones. Nuestra opinión es que, si en el momento actual la API es para consumo de tu propio frontal, debería ser una única historia de usuario.
Caso distinto es aquel en que la API es el propio producto, que es el que tú planteas. Ahí, por ejemplo, se nos ocurre que el formato, si damos opción a que haya varios, podría ser un factor de división de la historia. Quizá ofrecer la respuesta en XML o en JSON son «paras» distintos. Lo mismo pasa con los criterios de ordenación, filtrado… ¿Qué opinas tú?
¡Un saludo!
Coincido plenamente, mi planteo es pensando a la API como producto.
También es cierto que se puede divir la historia según los formatos en los cuales proveeríamos la información desde la API.