Esta pregunta podría ser similar a ¿A qué nivel debe priorizar el trabajo el propietario del producto? . Sin embargo, hago preguntas basadas en casos de uso específicos que no se abordan allí.
Nuestro equipo está revisando nuestro proceso Agile mientras analizamos pasar al flujo de estilo Kanban en lugar de Sprints. Una pregunta que nos cuesta mucho responder es
¿A qué nivel (qué tipo de
Work Item) debe priorizar el propietario del producto ?
En nuestra mente, todo se reduce a Featureo User Story (Bug). Sin embargo, no importa cuál elijamos, estamos viendo escenarios en los que causaría problemas.
Historia del usuario
Entendemos que los desarrolladores siempre trabajan al User Storynivel. (Sí... también pueden trabajar en el nivel de Tarea, pero el punto más alto es Historia).
Eso implica que el Product Owner está enviando y priorizando User Stories y Bugs.
Sin embargo, es posible que un desarrollo divida una historia de usuario en varias historias debido a la programación, la división del trabajo con otros desarrolladores o alguna otra razón.
En este caso, es posible que al Propietario del producto no le importe o incluso se confunda con la apariencia de estas Historias aparentemente no relacionadas en el tablero.
Rasgo
Alternativamente, podríamos hacer que el Product Owner trabaje en el Featurenivel, mientras dejamos que los desarrolladores continúen trabajando con User Stories.
Esto significa que el PO está enviando y priorizando Features. También permitiría al desarrollador crear más de uno User Storysin que la orden de compra se confunda.
El problema con este enfoque es el manejo Bugs. Dado que los errores aparecen en el nivel de la historia del usuario, ¿cómo priorizaría correctamente el PO en los dos diferentes Boards ? Supongo que el error podría ingresarse como Feature(con un niño que Bugtambién existe), pero eso parece incorrecto.
Grupo de Funcionalidad
Esta sección probablemente podría enviarse como una pregunta separada, pero la he agregado porque mi segundo enfoque expone el problema...
Tal vez "Característica" sea la palabra incorrecta utilizada en TFS, pero en mi opinión Work Item Featuresería "funcionalidad particular en una aplicación". Por ejemplo, una función titulada " La capacidad de ordenar los resultados de búsqueda ". Ejemplo, Historias de usuario debajo de eso podría ser " Ordenar por campo Id " y " Ordenar por campo Última modificación ".
Suponga que esta función se implementa y luego, algún tiempo después, se envía una mejora titulada " Ordenar por nombre ". ¿Debería presentarse como nuevo Feature? Si es así, ¿cómo (y debería) estar relacionado con el original Feature? ¿O debería presentarse como User Storyrelacionado con el original Featureprovocando que el ahora cerrado Featuresea reabierto?
¿Cómo afecta esto a los errores? ¿Debería Bugestar asociado con el original Feature?
¿ EpicsEntraría en juego algo de esto?
Creo que puede haber cierta confusión entre qué es una función, qué es una historia y qué es una tarea.
Usando tu ejemplo, esperaría algo como esto...
El propietario del producto está trabajando en la función de búsqueda . Agregan varias historias de usuarios a la cartera de pedidos:
Como usuario estándar, quiero poder ordenar los resultados de búsqueda por Fecha de última modificación para poder saber qué resultados son recientes.
Como usuario administrador, quiero poder ordenar los resultados de búsqueda por ID, para poder completar la lista de reabastecimiento
El equipo podría tomar estas historias de usuario y dividirlas en una serie de tareas de implementación técnica , como:
Agregar la última fecha de modificación a la base de datos e indexarla
Crear una página web que presente resultados
Cree algunos datos ficticios para probar
Al propietario del producto no le importan las tareas, pero sí las historias de los usuarios, ya que brindan un claro beneficio a los usuarios del producto. Quieren informar sobre el progreso de las historias de usuario a sus partes interesadas.
No es inusual que el propietario del producto y el equipo de desarrollo trabajen juntos para desglosar las historias de los usuarios. El equipo de desarrollo puede preferir historias más pequeñas, ya que les ayuda con la programación y la división del trabajo. Sin embargo, no esperaría que el equipo de desarrollo creara historias de usuario sin la participación del propietario del producto.
Un resumen podría ser:
nvoigt