tfs - pricing - diferencia entre el artículo y la característica de la cartera de pedidos de productos en los tipos de elementos de trabajo de Team Foundation
tfs tutorial (7)
Tengo una pregunta sobre Microsoft Team Foundation. En Visual Studio, Team Explorer, puedo crear un nuevo elemento de trabajo. Los tipos de elementos de trabajo aquí están dictados por la plantilla de proceso elegida por su equipo; No estoy seguro de qué plantilla de proceso estamos usando. En cualquier caso, en Team Explorer, cuando quiero crear un nuevo elemento de trabajo, me dan una lista de los tipos de elementos de trabajo para seleccionar, entre los que se encuentran "Artículo del archivo pendiente del producto" y "Función".
Noté una diferencia entre los dos tipos relacionados con la fecha de resolución objetivo. En el caso de un ítem de lista de pedidos de productos, esto parece estar dictado por la fecha de finalización de la iteración. Para una característica, no está tan claro. Una característica también está asociada con una iteración (y fecha de finalización de la iteración); sin embargo, la función también tiene un campo separado llamado "Fecha objetivo". El texto del mouse para la fecha objetivo es "La fecha objetivo para completar la función".
¿Debo elegir "Artículo de la cartera de pedidos del producto" o "Función" como el tipo de elemento de trabajo para mis nuevos elementos de trabajo? ¿Cuál es la diferencia entre los dos?
A medida que TFS aplica una estrategia de desarrollo ágil, creo que podemos decir:
Característica = Epic, elemento de Backlog = Story
Los contenidos épicos historias similares.
Así es como lo uso. Debajo de los elementos de la herramienta "Trabajo" -> "Atrasos" se enumeran tanto "Características" como "Elementos atrasados". Comienzo con las características para que no haya elementos atrasados en ese punto. Agrego las características seleccionando Características en el encabezado de la extensión y agregando el nombre de la función en el formulario y luego guardando y cerrando. A la izquierda de cada Característica recién agregada hay un signo verde +. Haga clic en el signo más y aparecerán las opciones de selección. Elija "Elementos de la cartera de productos". Cuando se abra, escriba el nombre del elemento atrasado en el campo superior como en Características. Está creando estos elementos atrasados, no hay ventanas emergentes. Complete la otra información según sea necesario, luego guárdela y cierre. Después de crear los ítems de Backlog, haga clic en el verde + en los Artículos de Backlog recién creados. Ingrese el nombre del elemento de trabajo como lo hizo para los Elementos del Registro y las Características. Al agregar los elementos de trabajo, incluya el sprint en el campo de iteración y estarán en el sprint cuando lo abra. Nada de esto está documentado en ningún lugar que pueda encontrar. Espero que sea con suficiente detalle.
Como otros dijeron aquí:
- Características: Nivel superior
- Atrasos: Características de un nivel a continuación (una característica se compone de elementos atrasados)
Tenga en cuenta que puede ENLACE elementos de trabajo y puede mostrarlos como una lista de árbol. Por lo tanto, puede vincular un elemento atrasado a una función y, más adelante, puede vincular una tarea a un elemento atrasado. Por lo tanto, obtienes una buena lista jerárquica de árboles.
La función es un nivel hasta ''artículos atrasados''. el equipo define el trabajo como iniciativas de alto nivel y las desglosa en características. que además desglosan y definen el trabajo a realizar como ''Backlog''. ref http://msdn.microsoft.com/en-us/library/dn306083.aspx ?
Parece que estás usando la plantilla de proceso de Scrum. El sitio TFS ha publicado información muy breve acerca de los elementos y características del Backlog del producto y la idea detrás de la creación de un nuevo tipo de elemento de trabajo. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx
La diferencia entre los dos se reduce a la granularidad con la que desea trabajar con sus elementos de trabajo en:
- Los elementos del inventario de productos se componen de tareas y tienen un esfuerzo estimado.
- Las características están compuestas de elementos de inventario de productos y tienen fechas de destino.
No he podido encontrar ninguna orientación oficial sobre cuándo usar las características frente a elementos de la cartera de productos, pero he creado mi propia guía, sobre la que baso esta respuesta ... http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/
¿Debería crear una característica o un elemento de registro de producto?
- Si crees / espero que el nuevo elemento de trabajo que vayas a crear se ajuste a un solo sprint, deberías crear un Elemento de acumulación de producto y luego dividirlo en tareas para tu sprint.
- Si piensa / sabe que el nuevo elemento de trabajo no cabe en un sprint único, debe crear una característica e identificar todos los elementos de tamaño de sprint que proporcionan valor (elementos de inventario de producto) en los que se puede desglosar la característica y utilizarlos cuando planeando sprints futuros.
[Actualización 2014-05-19]
Microsoft ha publicado más información sobre cómo usar las características y el concepto de cartera ágil que se ha implementado en TFS https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx
Tenía las mismas dudas que OP y mis pensamientos se han alineado con @josant answer, lo cual es muy razonable para mí.
Por otro lado, estoy usando el libro de Hundhausen [1] como referencia para adoptar TFS + Scrum.
Dijo cosas como:
Una característica es una unidad discreta de funcionalidad que brinda valor al usuario o empresa. Un PBI puede ser lo suficientemente grande como para tener varias características.
y entonces:
Una característica puede descomponerse en múltiples escenarios. Un escenario es una narrativa que describe un flujo de trabajo o una secuencia de pasos a través de la característica que ejerce un camino hacia el logro de un resultado esperado.
y continúa desarrollando estas ideas.
Para mí, Hundhausen parece estar hablando de casos de uso [2], pero aun así siento que su propuesta es contra intuitiva, ni parece que TFS guiaría este método de análisis. Encontré que se hacía referencia en la literatura de scrum que leí.
Probablemente solo se trate de elegir una convención con la que se sienta más cómodo y cumplirla.
Una característica es una cartera de cartera de productos.
http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx