Guia de Procesos de La Plantilla de Scrum v1.0 - V1.0.0
175
1 Microsoft Visual Studio Scrum v1.0 Guía de Procesos (v1.0) By: Microsoft Compiled by: Denny Rodríguez [email protected] www.ALightM.com 2011
Transcript of Guia de Procesos de La Plantilla de Scrum v1.0 - V1.0.0
1
Microsoft Visual Studio Scrum v1.0 Guía de Procesos (v1.0)
By: Microsoft Compiled by:
Denny Rodríguez [email protected]
www.ALightM.com
2011
2
El contenido de esta guía es propiedad de Microsoft en su sitio http://msdn.microsoft.com.
Denny Rodríguez y el equipo de ALightM han realizado la recopilación y adaptación del contenido.
Esta guía está en constante revisión para su mejora y actualización. Para obtener la última versión por
favor conéctese al sitio http://www.alightm.com.
Para comentarios o notificar cualquier mejorar por favor enviar un correo a [email protected]
Deseando que esta guía sea de utilidad para su empresa.
El equipo de ALightM.
3
Capítulos
Principios y valores de Agile, por Jeff Sutherland ....................................................................................... 10
Scrum .......................................................................................................................................................... 15
Roles ............................................................................................................................................................ 27
Reunión de planeamiento de plazos ........................................................................................................... 31
Reunión de Scrum diaria ............................................................................................................................. 33
Reunión de revisión de sprint ..................................................................................................................... 35
Reunión retrospectiva ................................................................................................................................. 36
Visual Studio Scrum 1.0 .............................................................................................................................. 37
Instalar la plantilla de Visual Studio Scrum 1.0 ........................................................................................... 41
Crear un Product Backlog............................................................................................................................ 46
Comparar los trabajos pendientes del producto y el plazo ........................................................................ 50
Libro Planeación del producto .................................................................................................................... 51
Libro de trabajo pendiente de iteración ..................................................................................................... 62
Asociar elementos de trabajo a un conjunto de cambios .......................................................................... 81
Elemento del Product Backlog .................................................................................................................... 82
Caso de usuario ........................................................................................................................................... 93
Error .......................................................................................................................................................... 108
Sprint ......................................................................................................................................................... 118
Impedimento ............................................................................................................................................ 120
Tarea ......................................................................................................................................................... 125
Casos de prueba ........................................................................................................................................ 132
Caso de prueba ......................................................................................................................................... 133
Pasos compartidos .................................................................................................................................... 148
Pasos compartidos .................................................................................................................................... 149
Crear y modificar áreas e iteraciones ....................................................................................................... 155
Buscar elementos de trabajo para vincular o importar ............................................................................ 168
Títulos, Identificadores, Descripciones e Historial .................................................................................... 171
4
Índice
Principios y valores de Agile, por Jeff Sutherland ....................................................................................... 10
Individuos e interacciones ................................................................................................................... 10
Software que funciona sobre la documentación completa ................................................................... 11
Colaboración del cliente sobre la negociación del contrato .................................................................. 12
Responder al cambio sobre seguir un plan ............................................................................................ 13
El desarrollo ágil es un marco incluyente y las metodologías son implementaciones .......................... 13
Scrum .......................................................................................................................................................... 15
Planear el proyecto ................................................................................................................................. 16
Compilar el Product Backlog ............................................................................................................... 16
Determinar el progreso del equipo ..................................................................................................... 18
Establecer el plan de lanzamiento ...................................................................................................... 18
Preparar el primer sprint .................................................................................................................... 19
Planear un sprint................................................................................................................................. 19
Elegir casos de usuario ........................................................................................................................ 20
Identificar tareas ................................................................................................................................. 20
Estimar tareas ..................................................................................................................................... 21
Compromiso de tareas de usuario ...................................................................................................... 21
Ejecutar un sprint ................................................................................................................................... 22
Completar casos de usuario ................................................................................................................ 22
Seguir el progreso del sprint ............................................................................................................... 22
Finalizar el sprint ................................................................................................................................. 23
Realizar el seguimiento del proyecto ................................................................................................. 23
Preparar el siguiente sprint ................................................................................................................. 24
Realizar el seguimiento del progreso de la versión ............................................................................ 24
Informe de estado de todas las iteraciones ........................................................................................ 25
Finalizar la versión ............................................................................................................................... 26
Roles ............................................................................................................................................................ 27
Equipo ..................................................................................................................................................... 27
Cualidades de un buen equipo ........................................................................................................... 27
Responsabilidades básicas del equipo ................................................................................................ 28
5
Scrummaster ........................................................................................................................................... 28
Cualidades de un buen ScrumMaster ................................................................................................. 28
Las responsabilidades básicas de un scrummaster............................................................................. 29
Propietario del Producto ........................................................................................................................ 29
Características de un buen propietario de producto .......................................................................... 29
Las responsabilidades básicas del propietario del producto ............................................................. 29
Reunión de planeamiento de plazos ........................................................................................................... 31
Reunión de Scrum diaria ............................................................................................................................. 33
Reunión de revisión de sprint ..................................................................................................................... 35
Reunión retrospectiva ................................................................................................................................. 36
Visual Studio Scrum 1.0 .............................................................................................................................. 37
Definiendo y realizando el seguimiento de Work Items ........................................................................ 37
Supervisar y notificar el progreso de Equipo .......................................................................................... 39
Instalar la plantilla de Visual Studio Scrum 1.0 ........................................................................................... 41
Crear un Product Backlog............................................................................................................................ 46
Epopeyas y temas ................................................................................................................................... 47
Picos ........................................................................................................................................................ 48
Comparar los trabajos pendientes del producto y el plazo ........................................................................ 50
Libro Planeación del producto .................................................................................................................... 51
Administrar el Product Backlog .............................................................................................................. 53
Clasificar y estimar los casos de usuario ................................................................................................. 53
Para clasificar y estimar los casos de usuario ..................................................................................... 54
Planear los Sprints .................................................................................................................................. 55
Definir iteraciones adicionales ............................................................................................................ 55
Para agregar iteraciones al proyecto de equipo desde Office Excel ................................................... 56
Programar las iteraciones ................................................................................................................... 56
Para programar las iteraciones ........................................................................................................... 56
Tener en cuenta las vacaciones y las interrupciones planeadas ........................................................ 57
Para tener en cuenta las interrupciones del trabajo planeadas o por vacaciones ............................. 57
Equilibrar la carga de trabajo entre sprints ........................................................................................ 57
Para equilibrar la carga de trabajo entre las iteraciones .................................................................... 58
Revisar el progreso de Equipo ................................................................................................................ 59
6
Agregar casos de usuario al trabajo pendiente del producto ................................................................ 60
Para agregar casos de usuario a la base de datos para realizar el seguimiento de los elementos de
trabajo ................................................................................................................................................. 60
Reordenar la lista de casos de usuario ................................................................................................... 61
Para reordenar la lista de casos de usuario en el libro ....................................................................... 61
Recursos adicionales para administrar el trabajo pendiente del producto ........................................... 61
Libro de trabajo pendiente de iteración ..................................................................................................... 62
Administrar el trabajo pendiente de iteración ....................................................................................... 64
Crear libros específicos de la iteración ................................................................................................... 67
Para crear una consulta específica de la iteración .............................................................................. 67
Para guardar una copia del libro Trabajo pendiente de iteración ...................................................... 68
Para configurar la hoja de cálculo Trabajo pendiente de iteración para actualizar los datos a partir
de la consulta específica de la iteración ............................................................................................. 68
Estimar y asignar el esfuerzo de la tarea ................................................................................................ 69
Para estimar el esfuerzo de la tarea y asignar las tareas .................................................................... 69
Planear una iteración .............................................................................................................................. 71
Programar la iteración ........................................................................................................................ 71
Para programar la iteración ................................................................................................................ 71
Tener en cuenta las vacaciones y las interrupciones planeadas ........................................................ 72
Para tener en cuenta las interrupciones del trabajo planeadas o por vacaciones ............................. 72
Determinar la capacidad del equipo y el trabajo de equilibrio de carga ............................................ 72
Para determinar la capacidad del equipo y equilibrar la carga de trabajo del equipo ....................... 72
Visualizar la evolución ......................................................................................................................... 75
Para visualizar la evolución para la iteración ...................................................................................... 75
Seguimiento del progreso de la iteración ............................................................................................... 76
Para seguir el progreso de la iteración ............................................................................................... 77
Agregar casos de usuario y tareas al trabajo pendiente de iteración .................................................... 78
Para agregar casos de usuario y tareas al trabajo pendiente de iteración ......................................... 78
Recursos adicionales para administrar el trabajo pendiente de iteración ............................................. 80
Asociar elementos de trabajo a un conjunto de cambios .......................................................................... 81
Para asociar elementos de trabajo a un conjunto de cambios ........................................................... 81
Elemento del Product Backlog .................................................................................................................... 82
7
Definir un elemento del Product Backlog ............................................................................................... 82
Para definir un elemento de trabajo pendiente de producto ............................................................ 83
Agregar y vincular Tareas a un elemento Trabajo pendiente del producto ........................................... 85
Para crear una tarea que se vincula a un elemento de trabajo pendiente de producto ................... 86
Para vincular las tareas existentes a un elemento de trabajo pendiente de producto ...................... 87
Para agregar un nuevo caso de prueba a un elemento de trabajo pendiente de producto .............. 89
Para agregar los casos de prueba existentes a un elemento de trabajo pendiente de producto ...... 89
Agregar otros tipos de Work Items a un elemento del Product Backlog ............................................... 90
Crear un impedimento y vincularlo a un elemento de trabajo pendiente de producto .................... 90
Cambiar el Estado de un elemento Trabajo pendiente del producto .................................................... 91
Caso de usuario ........................................................................................................................................... 93
Para definir un caso de usuario........................................................................................................... 94
Para crear una tarea vinculada a un caso de usuario ......................................................................... 97
Para vincular varias tareas existentes a un caso de usuario ............................................................... 97
Para agregar un nuevo caso de prueba a un caso de usuario ............................................................ 99
Para agregar casos de prueba existentes a un caso de usuario ......................................................... 99
Para crear un problema y vincularlo a un caso de usuario ............................................................... 100
Para agregar detalles a un caso de usuario ...................................................................................... 101
Para agregar datos adjuntos a un caso de usuario ........................................................................... 101
Para agregar un hipervínculo a un caso de usuario .......................................................................... 101
Para resolver o cerrar un caso de usuario activo .............................................................................. 102
Activo (Nuevo) .................................................................................................................................. 103
Resuelto ............................................................................................................................................ 105
Closed ................................................................................................................................................ 106
Error .......................................................................................................................................................... 108
Definir un error ..................................................................................................................................... 108
Para definir un error ......................................................................................................................... 109
Para crear una tarea que se vincula a un error ................................................................................. 112
Para vincular las tareas existentes a un error ................................................................................... 112
Para agregar un caso de prueba a un error ...................................................................................... 114
Para agregar los casos de prueba existentes a un error ................................................................... 114
Agregar otro Work Items a un error ..................................................................................................... 115
8
Crear un elemento de trabajo y vincularlo a un error ...................................................................... 115
Sprint ......................................................................................................................................................... 118
Para definir un sprint ........................................................................................................................ 119
Impedimento ............................................................................................................................................ 120
Para definir un impedimento ............................................................................................................ 121
Vincular un Impedimento a un Elemento Trabajo pendiente del producto, Otro Tipo o un Tarea de
Elemento de trabajo ......................................................................................................................... 123
Para vincular un impedimento a un elemento de trabajo pendiente de producto, una tarea u otro
tipo de elemento de trabajo ............................................................................................................. 123
Tarea ......................................................................................................................................................... 125
Definir una tarea ................................................................................................................................... 126
Para definir una tarea ....................................................................................................................... 126
Para vincular una tarea a un elemento de trabajo existente ........................................................... 128
Casos de prueba ........................................................................................................................................ 132
Caso de prueba ......................................................................................................................................... 133
Para definir un caso de prueba ......................................................................................................... 136
Vincular un caso de prueba a un caso de usuario ................................................................................ 138
Para vincular un caso de prueba a un caso de usuario ..................................................................... 138
Agregar detalles, datos adjuntos o hipervínculos a un caso de prueba ............................................... 140
Para agregar detalles a un caso de prueba ....................................................................................... 140
Para agregar datos adjuntos a un caso de prueba ............................................................................ 141
Para agregar un hipervínculo a un caso de prueba .......................................................................... 141
Cambiar el estado de un caso de prueba ............................................................................................. 142
Para cambiar el estado de un caso de prueba .................................................................................. 143
Diseño [Nuevo] ................................................................................................................................. 145
Listo ................................................................................................................................................... 146
Closed ................................................................................................................................................ 147
Pasos compartidos .................................................................................................................................... 148
Pasos compartidos .................................................................................................................................... 149
Referencia de campos .......................................................................................................................... 151
Activo (Nuevo) .................................................................................................................................. 152
Cerrado ............................................................................................................................................. 153
9
Crear y modificar áreas e iteraciones ....................................................................................................... 155
Áreas ................................................................................................................................................. 158
Iteraciones......................................................................................................................................... 159
Restricciones de las rutas de acceso de las áreas y las iteraciones ...................................................... 161
Cambiar la estructura o las iteraciones del proyecto mediante Team Web Access ............................ 162
Para modificar la estructura o las iteraciones del proyecto de equipo mediante Team Web Access
.......................................................................................................................................................... 162
Cambiar las áreas o las iteraciones utilizando Team Explorer, Microsoft Excel o Microsoft Project ... 163
Para modificar las áreas o las iteraciones utilizando Team Explorer, Microsoft Excel o Microsoft
Project ............................................................................................................................................... 163
Controlar el acceso a los elementos de trabajo asignados a un área o iteración ................................ 164
Para controlar el acceso a un área o una iteración utilizando Team Explorer, Microsoft Excel o
Microsoft Project .............................................................................................................................. 164
Imprecisiones de dirección publicadas para valores de resumen ........................................................ 166
Para borrar los campos de hora de las tareas primarias o de resumen ........................................... 166
Buscar elementos de trabajo para vincular o importar ............................................................................ 168
Para buscar los elementos de trabajo que desea vincular o importar ............................................. 168
Títulos, Identificadores, Descripciones e Historial .................................................................................... 171
10
Principios y valores de Agile, por Jeff
Sutherland Jeff Sutherland es el creador de Scrum, inventado en 1993, y trabajó con Ken Schwaber para formalizar
Scrum en OOPSLA'95. Juntos, extendieron Scrum en muchas compañías de software. El blog de Jeff
revisa los orígenes y procedimientos recomendados de Scrum en http://scrum.jeffsutherland.com.
"Desarrollo ágil" es un término derivado del Manifiesto Ágil (Agile Manifesto), escrito en 2001 por un grupo que incluía: a los creadores de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) y Crystal; un representante de desarrollo controlado por características; y otros coordinadores diversos del pensamiento en la industria del software. El Manifiesto Ágil (Agile Manifesto) estableció un conjunto común de valores y principios dominantes para todas las metodologías ágiles individuales en el momento. Detalla cuatro valores básicos para habilitar equipos de alto rendimiento.
Los individuos y sus interacciones. Entregar software que funciona. Colaboración del cliente. Responder al cambio.
Estos valores básicos se sustentan en 12 principios, que puede encontrar en el siguiente sitio web: Manifesto for Agile Software Development.
Estos valores no son sólo algo que los creadores del Manifiesto Ágil (Agile Manifesto) pensaban encomiar y, a continuación, olvidarse. Son valores que funcionan. Cada metodología ágil individual enfoca estos valores de una manera ligeramente diferente, pero todas estas metodologías tienen procesos y ejercicios concretos que fomentan uno o más de estos valores.
Individuos e interacciones
Los individuos e interacciones son esenciales para los equipos de alto rendimiento. Los estudios de "saturación de la comunicación" durante un proyecto mostraron que, cuando ningún problema de la comunicación existe, los equipos pueden realizar 50 veces mejor trabajo que la media de industria. Para facilitar la comunicación, los métodos ágiles confían en los ciclos de inspección y adaptación frecuentes. Estos ciclos pueden variar de cada pocos minutos con programación entre iguales, cada pocas horas con integración continua o todos los días con una reunión de puesta en marcha, hasta cada sprint con una revisión y retrospectiva.
No obstante, simplemente aumentar la frecuencia de los comentarios y la comunicación no es suficiente para eliminar los problemas de comunicación. Estos ciclos de inspección y adaptación solo funcionan bien cuando los miembros del equipo presentan varios comportamientos clave:
Respeto por el valor de cada persona. Veracidad en cada comunicación. Transparencia de todos los datos, acciones y decisiones.
11
Confianza en que cada persona respaldará al equipo. Compromiso con el equipo y los objetivos del equipo.
Para fomentar estos tipos de comportamiento, la administración ágil debe proporcionar un entorno de apoyo, los entrenamientos del equipo deben facilitar su inclusión y los miembros del equipo deben mostrarlos. Sólo entonces los equipos podrán lograr todo su potencial.
Acercarse a estos tipos de comportamiento es más difícil de lo que puede parecer. La mayoría de los equipos evitan la verdad, la transparencia y la confianza debida a las normas culturales o las experiencias negativas pasadas de conflictos generados por comunicadores sinceros. Para combatir estas tendencias, la dirección y los miembros del equipo deben facilitar el conflicto positivo. Hacerlo no solo ayuda a crear un comportamiento productivo, también tiene varias ventajas más:
La mejora del proceso depende de que el equipo genere una lista de impedimentos o problemas en la organización, se enfrente a ellos directamente y, a continuación, los elimine sistemáticamente en orden de prioridad.
La innovación solo se produce con el intercambio libre de ideas conflictivas, un fenómeno estudiado y documentado por Takeuchi y Nonaka, los padrinos de Scrum.
Alinear al equipo hacia un objetivo común requiere que el equipo manifieste y resuelva las agendas conflictivas.
El compromiso de trabajar juntos sólo se consigue cuando las personas acuerdan los objetivos comunes y, a continuación, se esfuerzan por mejorar personalmente y como equipo.
Este último punto, sobre el compromiso, es especialmente importante. Sólo cuando los individuos y los equipos se comprometen, se sienten responsables para entregar un alto valor, que es la línea de base para los equipos de desarrollo de software. Las metodologías ágiles facilitan el compromiso animando a los equipos a extraer una lista de trabajo clasificada por orden de prioridad, administrar su propio trabajo y centrarse en mejorar sus prácticas de trabajo. Esta práctica es la base de la organización del equipo por sí mismo, que es la fuerza motriz para lograr resultados en un equipo ágil.
Para crear equipos de alto rendimiento, las metodologías ágiles valoran a los individuos y las interacciones sobre los procesos y herramientas. Hablando prácticamente, todas las metodologías ágiles buscan aumentar la comunicación y colaboración a través de los ciclos de inspección y adaptación frecuentes. Sin embargo, estos ciclos solo funcionan cuando los coordinadores ágiles fomentan el conflicto positivo que se necesita para generar una base sólida de verdad, transparencia, confianza, respeto y compromiso en sus equipos ágiles.
Software que funciona sobre la documentación completa
El software que funciona es una de las grandes diferencias que aporta el desarrollo ágil. Todas las metodologías ágiles que se representan en el Manifiesto Ágil (Agile Manifesto) subrayan la entrega al cliente de partes pequeñas de software que funciona a intervalos fijos.
Todos los equipos ágiles deben establecer lo que quieren decir cuando dicen " software que funcione ", que es con frecuencia conocido como la definición de terminado. En un nivel alto, una parte de la funcionalidad se ha completado solo cuando sus características pasan todas las pruebas y pueden ser utilizadas por un usuario final. Como mínimo, los equipos deben ir más allá del nivel de la prueba
12
unitaria y probar en el nivel del sistema. Los mejores equipos también incluyen pruebas de integración, rendimiento y aceptación del cliente en su definición de lo que significa haber terminado una parte de la funcionalidad.
Una compañía de CMMI nivel 5 ha mostrado, a través de datos extensos en muchos proyectos, que definir las pruebas de aceptación junto con la característica, implementar las características consecutivamente y en orden de prioridad, realizar las pruebas de aceptación en cada característica inmediatamente y corregir cualquier error identificado como prioridad máxima duplicará la velocidad de producción sistemáticamente y reducirá los defectos en un 40 por ciento. Esto procede de una compañía que ya tiene una de las tasas de defectos más bajas del mundo.
El Manifiesto Ágil (Agile Manifesto) recomienda que los equipos entreguen el software que funciona a intervalos establecidos. Acordar una definición de "terminado" es una de las maneras prácticas en que los equipos ágiles dan lugar al alto rendimiento y alta calidad que se necesitan para lograr este objetivo.
Colaboración del cliente sobre la negociación del
contrato
Durante las dos últimas décadas, las tasas de éxito de los proyectos han aumentado a más del doble en todo el mundo. Esto se atribuye a los proyectos menores y las entregas frecuentes, que permiten al cliente proporcionar comentarios sobre el software que funciona a intervalos regulares. Los redactores del manifiesto sabían de qué estaban hablando cuando enfatizaron que conseguir la implicación del cliente en el proceso de desarrollo de software es esencial para el éxito.
Las metodologías ágiles fomentan este valor ya que un representante del cliente trabaja mano a mano con el equipo de desarrollo. Por ejemplo, el primer equipo de Scrum tenía miles de clientes. Dado que no era factible implicarlos a todos en el desarrollo del producto, seleccionaron a un representante del cliente, llamado propietario del producto, para representar no solo a todos los clientes en el campo respectivo, también las áreas como administración, ventas, soporte técnico, servicios al cliente y otras partes interesadas. El propietario del producto era responsable de actualizar la lista de requisitos cada cuatro semanas a medida que el equipo liberaba el software que funciona, teniendo en cuenta la realidad actual y los comentarios reales de los clientes y partes interesadas. Esto permitía al cliente ayudar a dar forma al software que estaban creando.
El primer equipo de XP comenzó con un proyecto de TI interno. Pudieron tener a un usuario final de la compañía en su equipo para que trabajara con ellos a diario. Las consultorías y los equipos internos pueden encontrar a un usuario final que trabaje con el equipo todos los días aproximadamente el 10 por ciento del tiempo. Para el otro 90 por ciento del tiempo, deben designar a un representante. Este representante del cliente, a quien los equipos de XP llaman "el cliente", trabaja con los usuarios finales para proporcionar una lista clara, clasificada por orden de prioridad de las características que los desarrolladores de software deben implementar.
Colaborar con el cliente (o el representante del cliente) todos los días es uno de los motivos clave por los que los datos del sector muestran que los proyectos ágiles tienen más del doble de éxito que los proyectos tradicionales por término medio en todo el mundo. Las metodologías ágiles reconocen esto y,
13
por tanto, han creado en sus equipos de desarrollo un lugar que es específicamente para el representante del cliente.
Responder al cambio sobre seguir un plan
Responder al cambio es esencial para crear un producto que agrade el cliente y proporcione valor comercial. Los datos del sector muestran que más del 60 por ciento de los requisitos de producto o de proyecto cambian durante el desarrollo de software. Incluso cuando los proyectos tradicionales finalizan a tiempo, según el presupuesto y con todas las características del plan, los clientes se sienten a menudo insatisfechos porque lo que encuentran no es exactamente lo que deseaban. "La "Ley de Humphrey dice que los clientes nunca saben lo que desean hasta que vean funcionando el software. Si los clientes no ven el software que funciona hasta el fin de un proyecto, es demasiado tarde para incorporar sus comentarios. Las metodologías ágiles buscan los comentarios del cliente a lo largo del proyecto para que puedan incorporar comentarios y nueva información a medida que se desarrolla el producto.
Todas las metodologías ágiles tienen procesos integrados para cambiar sus planes a intervalos regulares en función de los comentarios del cliente o su representante. Sus planes están diseñados para entregar siempre primero el mayor valor comercial. Dado que el 80 por ciento del valor representa el 20 por ciento de las características, los proyectos ágiles bien realizados tienden a finalizar temprano, mientras que la mayoría de los proyectos tradicionales finalizan tarde. Como resultado, los clientes están más satisfechos y los desarrolladores de software disfrutan más de su trabajo. Las metodologías ágiles están basadas en el conocimiento de que para tener éxito, se debe planear para cambiar. Por eso han establecido procesos, como revisiones y retrospectivas, diseñados específicamente para desplazar las prioridades con regularidad en función de los comentarios del cliente y el valor comercial.
El desarrollo ágil es un marco incluyente y las
metodologías son implementaciones
El desarrollo ágil no es una metodología en sí mismo. Es un término incluyente que describe varias metodologías ágiles. En la firma del Manifiesto Ágil (Agile Manifesto) de 2001, estas metodologías incluían a Scrum, XP, Crystal, FDD y DSDM. Desde entonces, también han emergido las prácticas eficientes como una valiosa metodología ágil y, por tanto, se han incluido bajo el paraguas del desarrollo ágil en la ilustración que se encuentra más adelante en este tema.
Cada metodología ágil tiene un enfoque ligeramente diferente para implementar los valores básicos del Manifiesto Ágil (Agile Manifesto), exactamente igual que muchos lenguajes de computación manifiestan las características principales de la programación orientada a objetos de maneras diferentes. Una encuesta reciente muestra que aproximadamente un 50 por ciento de quienes usan metodologías ágiles dicen que su equipo está haciendo Scrum. Otro 20 por ciento dice que están haciendo Scrum con los componentes XP. Un 12 por ciento adicional dice que están haciendo XP exclusivamente. Dado que más del 80 por ciento de las implementaciones ágiles en todo el mundo es Scrum o XP, MSF for Agile Software Development v5.0 o Scrum v1.o se centra en los procesos y prácticas básicos de Scrum y XP.
14
Scrum es un marco de trabajo para los procesos de desarrollo ágiles. No incluye prácticas de ingeniería concretas. A la inversa, XP se centra en las prácticas de ingeniería, pero no incluye ningún marco de trabajo dominante de procesos de desarrollo. Esto no significa que Scrum no recomiende ciertas prácticas de ingeniería ni que XP no tenga ningún proceso. Por ejemplo, el primer Scrum implementó todas las prácticas de ingeniería que ahora se conocen como XP. Sin embargo, el marco de trabajo de Scrum para el desarrollo de software se diseñó para hacer que un equipo empezara en dos o tres días, mientras que las prácticas de ingeniería suelen tardar muchos meses en implementarse. Por consiguiente, queda la pregunta de cuándo (y si se deben) implementar practicas concretas para cada equipo. Los creadores de Scrum, Jeff Sutherland y Ken Schwaber, recomiendan que los equipos de Scrum empiecen inmediatamente y creen una lista de impedimentos y un plan de mejora del proceso. Como las prácticas de ingeniería se identifican como impedimentos, los equipos deben recurrir a las prácticas de XP como una manera de mejorar. Los mejores equipos ejecutan Scrum complementado con prácticas de XP. Scrum ayuda a XP a escalar y XP ayuda Scrum a funcionar bien.
La siguiente tabla muestra cómo se pueden intercambiar las condiciones clave en Scrum y XP.
Scrum XP
propietario del producto cliente
Scrummaster Instructor de XP
Equipo equipo
Sprint iteración
reunión de planeación de sprint juego de planeación
Nota del autor: En tecnologías Microsoft, Scrum con las prácticas de ingeniería son aplicadas en Team Foundation Server con la Plantilla de Scrum 1.0
15
Scrum
Scrum es un marco para ejecutar proyectos sobre la base de los principios y valores de Agile. Scrum define un conjunto de actividades que pueden ayudar al equipo a entregar más valor a los clientes más rápidamente. Estas actividades proporcionan a los clientes la oportunidad de revisar, guiar e influir en el trabajo del equipo a medida que progresa. Este enfoque no intenta definir todo al principio de un proyecto. En su lugar, el equipo trabaja en breves iteraciones (también denominadas sprints) y refina el plan a medida que progresa.
MSF for Agile Software Development v5.0 y Scrum v.10 están basados en Scrum. Por consiguiente, el equipo puede adoptar Scrum utilizando herramientas que se integran con las actividades de desarrollo básicas.
Preparar el proyecto
Antes de iniciar el proyecto, realice las siguientes tareas:
Establecer el caso comercial. Reunir un equipo. Preparar la infraestructura del equipo.
16
Para establecer un caso comercial, identifique la necesidad y la justificación comercial, defina la visión y obtenga financiación. El libro de Geoffrey Moore "Crossing the Chasm" proporciona una buena orientación para establecer la visión. Para obtener más información, vea el siguiente recurso web: Crossing the Chasm.
Después de establecer el caso comercial, debe reunir el equipo e identificar el scrummaster y el propietario del producto
Finalmente, el equipo debe preparar la infraestructura. Por ejemplo, instalar Visual Studio Team Foundation Server y Visual Studio Application Lifecycle Management (ALM), crear y, posiblemente, personalizar el proyecto de equipo, y configurar las prácticas de ingeniería. Para obtener más información, vea Introducción a Visual Studio Application Lifecycle Management, Personalizar el proyecto de equipo y Procedimientos de ingeniería.
Planear el proyecto
En un proyecto Scrum, el equipo empleará la mayoría del tiempo desarrollando el producto en una serie de sprints. No obstante, el equipo debe crear primero un plan de alto nivel para el proyecto. Este plan es una guía básica para que el equipo tome decisiones más detalladas durante el curso del proyecto. A medida que el equipo implemente el plan, cambiará. Cuando el equipo haya terminado de planear el proyecto, habrá creado un Product Backlog (Trabajo pendiente del producto) y, si es necesario, un plan de lanzamiento.
Compilar el Product Backlog
El Product Backlog es una lista de casos de usuario que describen lo que los usuarios necesitan y valoran. Los casos de usuario son clasificados por orden de prioridad por valor comercial y riesgo, y el equipo los estima en unidades abstractas que se denominan puntos de caso. En el siguiente gráfico se muestra un ejemplo del Product Backlog:
Para definir un Product Backlog se debe tener en cuenta:
17
Cree Casos de usuario: En su libro "User Stories Applied", Mike Cohn define los casos de usuario
esta manera: "Un caso de usuario describe funcionalidad que será valiosa a un usuario o
comprador de un sistema o software." Los casos de usuario se escriben del punto de vista del
usuario final. Por ejemplo: "Como un cliente que quiero volver, deseo encontrar una comida que he
ordenado antes."
Clasificar por orden de prioridad los casos de usuario: el propietario del producto clasifica los
casos de usuario por orden de prioridad en el trabajo pendiente del producto, trabajando con los
clientes para entender lo que valoran y trabajando con el equipo para entender los riesgos y las
dependencias. El propietario del producto especifica prioridades asignando un rango a cada caso
de usuario, para indicar el orden en el que el equipo debe implementarlos. El propietario del
producto puede utilizar muchas técnicas para analizar y comparar el valor de los casos de usuario.
Si el equipo tiene ya un método que funcione para realizar la clasificación por orden de prioridad,
utilícelo.
Hay algunas técnicas de clasificación por prioridades que están estrechamente asociadas a la
comunidad Agile, tales como el modelo de Kano de satisfacción del cliente y la ponderación relativa
de Karl Wiegers. (Para obtener más información sobre la ponderación relativa, vea la siguiente
página en la web: First Things First: Prioritizing Requirements.) Otras técnicas de clasificación por
prioridades, tales como las prioridades por costo, valor neto actual, período de reembolso y tasa
interna de retorno están bien establecidas fuera de la comunidad Agile. Estas técnicas también son
legítimas y adecuadas para clasificar por orden de prioridad el trabajo pendiente del producto en
un proyecto Scrum. Para obtener más información, vea la sección titulada "Part II: Estimating Size"
en el libro identificado en el siguiente recurso web: Agile Estimation and Planning.
Estimar los casos de usuario: el equipo estima de manera cooperativa cada caso de usuario en
puntos de caso. En su libro "Agile Estimation and Planing", Mike Cohn define los puntos de caso
esta manera: Los "puntos de caso son una unidad de medida para expresar el tamaño total de un
caso de usuario, característica u otra parte de trabajo." Los puntos de caso son valores relativos
que no traducen directamente en un número concreto de horas. En su lugar, los puntos de caso
ayudan al equipo a cuantificar el tamaño general del caso de usuario. Estas estimaciones relativas
son menos precisas, así que requieren menos esfuerzo para determinarlas y se mantienen mejor
con el tiempo. Estimando en puntos de caso, el equipo puede proporcionar ahora un tamaño
general de los casos de usuario y desarrollar más tarde la estimación más detallada en horas de
trabajo, cuando los miembros del equipo vayan a implementar los casos de usuario.
18
Determinar el progreso del equipo
Antes de que el equipo cree su plan de lanzamiento y planee cada sprint, debe determinar su progreso. El progreso del equipo es el número de puntos de caso que puede completar en un sprint.
Si el equipo ha medido su progreso recogiendo datos que muestran cuántos casos de usuario completa en un período determinado de tiempo, utilice esos datos. Proporcionarán la visión más clara del progreso del equipo. Si no tiene esos datos ahora pero está empezando a ejecutar el proyecto utilizando Visual Studio ALM y MSF for Agile Software Development v5.0 o Scrum v1.0, esos datos se recopilarán a lo largo del proyecto. Para ver más detalle revise “Informe de estado de todas las iteraciones” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Si no hay datos históricos disponibles, el equipo puede hacer una estimación aproximada de cuántos puntos de caso puede completar en el primer sprint. Observe los casos de usuario calculados de la parte superior de la pila de prioridades y realice una evaluación rápida de cuántos casos podría completar en un sprint. Sume los puntos de caso para cada uno de esos casos de usuario para obtener una estimación inicial. Después del primer sprint, puede utilizar datos históricos para determinar el progreso del equipo. En los primeros sprints, debe esperar variaciones sustanciales, a medida que el equipo aprende a realizar estimaciones de manera coherente. A lo largo de varios sprints, el progreso medido para el equipo se debe hacer más estable. Cuando el progreso medido para el equipo sea estable, evalúe de nuevo el plan de lanzamiento.
La estimación del progreso del equipo proporciona un punto inicial que puede utilizar para determinar cuántos casos de usuario se implementarán en el sprint, pero la estimación no es la base para el compromiso del equipo. El compromiso del equipo se hará dependiendo de estimaciones más detalladas de las tareas necesarias para completar los casos de usuario. Para obtener más información, vea “Libro Planeación del producto” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Establecer el plan de lanzamiento
En cada sprint, el equipo completará un incremento del producto que podría distribuirse. Aunque los casos de usuario que el equipo implementa están listos para ser distribuidos al final del sprint, quizá no proporcionen suficiente valor comercial para justificar realmente una versión del producto. Las versiones deben planearse asignándolas a las iteraciones:
Se deben identificar grupos de casos de usuario que, juntos, proporcionen suficiente valor comercial para publicarlos para los clientes.
Se debe determinar en qué sprints el equipo espera que se completen esos grupos de casos de usuario.
A medida que el equipo progrese, se van agregando casos de usuario al Product Backlog, y se pueden quitar casos de usuario. Además, la prioridad de algunos casos de usuario cambiará y se podrán implementar algunos casos de usuario antes o después de lo esperado originalmente. El propietario del producto mantendrá el plan de lanzamiento junto con el Product Backlog a lo largo del proyecto.
Para obtener más información, vea “Libro Planeación del producto” en la guía “Informes y Libros Agile” en http://www.alightm.com.
19
Preparar el primer sprint
Un sprint es una iteración de desarrollo dentro de un tiempo limitado, normalmente de una a cuatro semanas de duración y que produce un incremento del producto que el equipo podría distribuir. Antes de que el equipo inicie el primer sprint, el propietario del producto prepara el Product Backlog. Los casos de usuario cuya prioridad es lo suficientemente alta para ser considerados en el primer sprint deben estar listos para que el equipo los implemente. El propietario del producto debe preparar el Product Backlog realizando las siguientes tareas:
Debe desglosar los casos de usuario en casos menores. Debe proporcionar detalles sobre los casos de usuario que el equipo necesitará para desglosarlos
en tareas.
El propietario del producto sabrá que un caso de usuario es demasiado grande si representa una parte significativa del progreso total del equipo. Por ejemplo, un caso de usuario que tenga 15 puntos de caso es demasiado grande para llevarlo a la reunión de planeación si el progreso del equipo es de 30 puntos de caso. El equipo necesitaría la mitad del sprint sólo para completar ese caso de usuario.
El equipo también pedirá detalles sobre los casos de usuario para poder descomponerlos en tareas y estimar esas tareas. Por ejemplo, cuando el equipo examina el caso de usuario "Como cliente, deseo poder buscar un tipo de comida", puede formular los siguientes tipos de preguntas:
"¿Eso debe ser una búsqueda de texto libre o puede ser una selección en una lista de tipos disponibles?"
"¿Si más de un proveedor proporciona una comida que coincida con la búsqueda, cómo deben ordenarse los resultados?"
Para obtener más información, vea en esta guía “Preparar el siguiente sprint.”
Planear un sprint
Cuando su equipo ha desarrollado el trabajo pendiente del producto y ha establecido un plan del lanzamiento, su equipo puede empezar a trabajar en sprints. El equipo inicia el sprint con una reunión para planear el sprint, en la que el equipo se compromete a completar un conjunto de casos de usuario del trabajo pendiente del producto. Ese conjunto de casos de usuario, junto con las tareas de apoyo, es el trabajo pendiente del sprint. Para obtener más información, vea en esta guía “Comparar los trabajos pendientes del producto y el plazo”.
Una vez que se inicie el sprint, no se cambian los casos de usuario del trabajo pendiente del sprint. Por consiguiente, el plan se debe detallar lo suficiente como para que el equipo pueda asumir ese compromiso con confianza.
Para obtener más información, vea en esta guía “Reunión de planeamiento de plazos”.
20
Elegir casos de usuario
El equipo elige los casos de usuario que son candidatos a implementarse en el sprint. El equipo identifica los casos de usuario que tienen la prioridad máxima y cuyos puntos de caso no superan su progreso estimado. Por ejemplo, los cuatro casos de usuario que tienen la prioridad máxima podrían tener 8, 3, 7, 6 y 2 puntos de caso. Si el equipo tuviera una capacidad de 25 puntos de caso por sprint, incluiría los primeros cuatro casos en el trabajo pendiente del sprint.
Para obtener más información, vea “Libro de trabajo pendiente de iteración” en la guía “Informes y Libros Agile” el site de http://www.alightm.com.
Identificar tareas
El equipo evalúa cada caso de usuario para determinar lo que debe hacer para implementar ese caso. El equipo descompone los casos de usuario en tareas, como ayuda para entender los casos de usuario lo suficientemente bien como para asumir con confianza el compromiso de completarlos en el sprint.
Es posible que los equipos con mucha experiencia en Scrum puedan asumir este compromiso sin descomponerlos casos de usuario en tareas.
21
Estimar tareas
Una vez identificadas las tareas, el equipo estima cuánto tiempo durará cada tarea (en horas). Los equipos utilizan con frecuencia la técnica de planeamiento de póquer para estimar las tareas. Esta técnica ayuda a evitar que los equipos intenten estimar con más precisión que la necesaria.
Compromiso de tareas de usuario
El equipo utiliza el libro de Product Backlog de iteración para asegurarse de que tiene suficientes horas de trabajo para completar todas las tareas. Si el sprint tiene más trabajo que el que tiene disponible el equipo en el sprint, se debe quitar los casos de usuario con las clasificaciones más bajas hasta que el trabajo esté dentro de la capacidad del equipo para el sprint. Se pueden cambiar los casos mayores que no encajen en el sprint por casos menores con menor prioridad.
El equipo se compromete a completar los casos de usuario que haya determinado que puede completar. Asume este compromiso entendiendo que el propietario del producto no intentará introducir el trabajo adicional ni cambiar las prioridades de los casos de usuario que se estén implementando en el sprint.
22
Ejecutar un sprint
Durante un sprint, el equipo completa las tareas necesarias para implementar los casos de usuario en el trabajo pendiente del sprint. El equipo puede seguir su progreso y asegurarse de que cumple los criterios de aceptación de los clientes y los criterios del equipo para el software acabado antes de finalizar cada sprint.
Completar casos de usuario
Una vez que el equipo planea el sprint, se tiene una lista de casos de usuario que se ha comprometido a completar durante el sprint. Esos casos de usuario se han descompuesto en tareas. Cada miembro del equipo se inscribe en una tarea cuando se inicia el sprint. Después de completar esa tarea, el miembro del equipo actualiza su estado y se inscribe en otra tarea. De esta manera, el equipo trabaja siguiendo la lista de tareas, completando los casos de usuario en el trabajo pendiente del sprint. Un miembro del equipo puede indicar qué tareas están completadas al proteger el código. Para obtener más información, vea en esta guía “Asociar elementos de trabajo a un conjunto de cambios”.
Para obtener más información sobre cómo asignar las tareas y actualizar su estado, vea en esta guía
“Tarea”.
Scrum se apoya más en que las personas hablen entre sí que en procesos formales para asegurarse de que se entiendan las dependencias, que se compartan los conocimientos técnicos y que los cambios en los planes se realicen eficazmente. Se debe mantener a diario una corta reunión de Scrum, en la que cada miembro del equipo comparta algunos detalles sobre el trabajo que realizaron el día anterior, el trabajo que planear realizar ese día, y los problemas o impedimentos que podrían afectar a otros miembros del equipo o necesitar su ayuda. Para obtener más información, vea en esta guía “Reunión de Scrum Diaria”.
En su libro "Extreme Programming Explained", Kent Beck habla de cómo es más barato corregir un error más pronto que tarde. Dado ese hecho, el equipo debe entender lo que es importante para el cliente. Es posible que el cliente valore la calidad en lugar de más características. El propietario del producto debe conocer este tipo de información, porque los clientes controlan el flujo del trabajo al equipo.
El software que produce un equipo Scrum no debe contener errores. Sin embargo, es probable que el equipo encuentre errores en los proyectos. Se deben administrar los errores entendiendo que es más barato y más rápido corregirlos a medida que se encuentran que aplazarlo hasta después. Cuando el equipo encuentre errores, se deben corregir inmediatamente. Si el equipo no puede corregir el error el mismo día que se encontró, se debe crear un elemento de trabajo de error en Visual Studio ALM y corregirlo antes del fin del sprint.
Para obtener más información, vea en esta guía “Error”.
Seguir el progreso del sprint
El equipo puede realizar el seguimiento del progreso del sprint para asegurarse de que ese trabajo se complete cuando se espera y que cumpla los criterios de aceptación. Los equipos Scrum utilizan
23
frecuentemente un informe de evolución para realizar el seguimiento de su progreso a través de un sprint. MSF for Agile Software Development v5.0 y Scrum v1.0 proporciona un conjunto de informes que los equipos pueden utilizar para realizar el seguimiento del progreso de un sprint.
Para obtener más información de los informes, vea “Informe de evolución y tasa de avance. Informe Indicadores de calidad de la compilación. Informe de progreso del plan de pruebas. Informe Progreso de los casos.” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Los equipos descubren a menudo que necesitan más o menos tiempo para completar una tarea que lo que estimaron durante la reunión para planear el sprint. Este tipo de variación es habitual. Puede registrar esta información especificando el tiempo real que el equipo empleó en la tarea.
A medida que el sprint progresa, el equipo podría identificar trabajo que no había esperado pero que era necesario para completar un caso de usuario. En este caso, se debe crear una tarea, calcularla y, a continuación, determinar si el equipo puede completarla en las horas que quedan en el sprint. Si el equipo puede completar la tarea, se continúa con el sprint. Si el equipo no puede completar la tarea en el sprint, es preciso reunirse con el propietario del producto para discutir cómo continuar. El propietario del producto y el equipo pueden resolver el problema realizando los siguientes tipos de cambios:
Reducir los criterios de aceptación para el caso de usuario de modo que la tarea sea innecesaria. Quitar el caso de usuario del trabajo pendiente del sprint. Cancelar el sprint.
Finalizar el sprint
A medida que se aproxima el final del sprint, asegúrese de que el equipo esté completando todos los casos de usuario o los requisitos por completo. Por ejemplo, asegúrese de que las pruebas de aceptación se estén superando y que cada caso de usuario cumpla los criterios que el equipo haya definido. Para obtener más información acerca de lo que significa haber terminado, vea la página web siguiente: Mitch Lacey & Associates, Inc.
Para obtener más información de los informes de errores, vea “Informe Estado del error. Informe
Tendencias de errores” en la guía “Informes y Libros Agile” en el site de
http://www.alightm.com.
En el último día del sprint, el equipo mostrará los casos de usuario que haya completado al propietario del producto y posiblemente a los clientes. El propietario del producto y los clientes determinarán si aceptan cada caso de usuario. Para obtener más información, vea en esta guía “Reunión de revisión de sprint".
Después de la revisión del cliente, el equipo mantendrá una reunión retrospectiva. Para obtener más información, vea en esta guía “Reunión de retrospectiva".
Realizar el seguimiento del proyecto
A medida que el equipo trabaja en sprints para entregar incrementos del proyecto, los clientes desarrollan un mejor entendimiento de sus necesidades restantes y es necesario considerar cambios en
24
el entorno comercial. El propietario del producto trabaja con los clientes para entender estos cambios. El propietario del producto mantendrá el trabajo pendiente del producto y el plan de lanzamiento para reflejar esos cambios y asegurarse de que el equipo tenga lo que necesita al principio de cada sprint. El equipo realiza el seguimiento del progreso del producto en conjunto para asegurarse de que está progresando correctamente para completar proyecto.
Preparar el siguiente sprint
La actualidad del trabajo pendiente del producto tiene una relación directa con la calidad general y la integridad del proyecto. El trabajo pendiente debe actualizarse periódicamente, analizarse y modificarse para garantizar que esté listo cada vez que el equipo esté a punto de iniciar un sprint.
El propietario del producto prepara el trabajo pendiente del producto para el siguiente sprint realizando las siguientes tareas:
Actualiza los casos de usuario y sus prioridades según las necesidades de los clientes. Desglosa los casos de usuario que probablemente vayan a implementarse en el siguiente sprint.
Cuando el equipo finaliza un sprint, otros casos de usuario se acercan a la parte superior del Product Backlog. El propietario del producto debe analizar y desglosar los casos que se encuentran en la parte superior, para que el equipo los pueda implementar en el próximo sprint. (Para obtener más información, vea la sección “Prepara el primer sprint”, anteriormente en este tema). Mike Cohn habla a menudo de este proceso como el iceberg del trabajo pendiente del producto. A medida que el equipo trabaja en un conjunto de funcionalidad, el iceberg se funde, emerge nuevo trabajo y el iceberg se reduce. En este proceso, emergen detalles adicionales, solo los suficientes y en su momento.
Ahora que el equipo está ocupado ejecutando un sprint, el propietario del producto no puede esperar tener el mismo nivel de implicación del equipo para mantener el trabajo pendiente del producto que ofreció al preparar el primer sprint. Para ayudar al propietario del producto a preparar el trabajo pendiente del producto con un mínimo de interrupciones del sprint, el equipo y el propietario del producto hablarán de los problemas abiertos relativos al trabajo pendiente del producto a lo largo del sprint.
Realizar el seguimiento del progreso de la versión
A medida que el proyecto pase de sprint a sprint, el equipo realizará el seguimiento del progreso general hacia la siguiente versión. El equipo también realizará el seguimiento de su progreso para evaluarlo y
25
mejorarlo. A medida que el equipo realice el seguimiento de su progreso, deberá intentar responder a los siguientes tipos de preguntas:
¿Estamos trabajando en los casos de usuario más adecuados? El Product Backlog se refinará con nuevos casos de usuario a medida que el proyecto progrese. Sin embargo, si el número total de casos del Product Backlog no se reduce, aunque esté completando casos en cada sprint, el equipo debe investigar la causa. Es posible que los casos que se estén completando no sean las mejores opciones. El equipo debería tener una visión y un objetivo para cada versión y asegurarse de que los casos estén directamente vinculados a lo que pide el cliente.
¿Acarreamos una deuda técnica? Algunos equipos tratan un caso de usuario como acabado aunque quede por completar trabajo tal como la corrección de errores. Esos equipos asumen una deuda técnica que deben pagar después, normalmente con un costo superior.
Visual Studio ALM proporciona varios informes que ayudan al equipo a realizar el seguimiento de su progreso a lo largo de muchos sprints.
Informe de estado de todas las iteraciones
Para más información vea “Informe Información general sobre los casos” e “Informe Progreso de los casos.” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Puede crear informes personalizados y consultas de elementos de trabajo para ayudar a realizar el seguimiento del progreso. Para obtener más información, vea “Crear, personalizar y administrar
informes para Visual Studio ALM y Buscar errores, tareas y otros elementos de trabajo” en la guía
“Informes y Libros Agile” en http://www.alightm.com.
26
Finalizar la versión
Si el equipo no está acumulando deuda técnica, puede publicar el producto una vez completados los scripts de esa versión, sin trabajo adicional. El equipo y el propietario del producto mantienen reuniones de revisión del cliente y reuniones retrospectivas para examinar la versión en conjunto.
Sin embargo, la deuda técnica es un problema importante, que los equipos no pueden eliminar fácilmente. Si el equipo, como muchos otros equipos, todavía está acumulando deuda técnica, debe dedicar tiempo a hacer el trabajo pendiente para finalizar los casos de usuario antes de publicar el producto. En la reunión retrospectiva para la versión, tenga en cuenta lo que debe hacer el equipo en los próximos sprints para evitar acumular más deuda.
27
Roles
Los miembros de un equipo del Scrum realizan uno de tres roles por lo menos. La mayoría de los individuos realizan el rol del equipo, que tiene la responsabilidad para crear el software. Además, el propietario del producto debe asegurarse de que sus clientes se representan en el equipo, y el Scrummaster ayuda al equipo y al propietario del producto sigue los procesos del Scrum eficazmente.
Equipo
El equipo está compuesto de los individuos que son responsables de la creación del software. Selecciona los casos de usuario al principio del sprint, colabora para implementar y probar los casos de usuario durante el sprint y presenta el software finalizado en la revisión del sprint. El equipo está auto-organizado porque administra su trabajo. El equipo es un cruce funcional porque contiene los conocimientos que exige entregar los casos de usuario en el trabajo pendiente del producto. La Plantilla V5.0 de MSF for Agile Software Development o la plantilla de Scrum v1.0 no distingue los roles dentro del equipo por criterios como diseñar disciplina o área de especialización.
Cualidades de un buen equipo
Un equipo de software bueno es difícil de ensamblar y toma el tiempo para compilar. Los ejemplos de equipos buenos están alrededor de nosotros: equipos quirúrgicos, equipos del baloncesto y perros ovejeros y sus controladores. Cada miembro del equipo puede tener su especialidad, aunque el equipo funciona en conjunto y tiene éxito o fracasa en conjunto.
Los equipos del software buenos también se crean de individuos que se reúnen hacia un objetivo común. Un equipo del software simplemente no debería ser una recopilación de expertos, cada uno de quien toma una representación del giro sólo las tareas en las que especializan. En su lugar, un equipo debería ser un grupo de las personas cuyas los conocimientos colectivos y especialización pesan más que los conocimientos de cualquier individual. A través de la colaboración, comunicación, confianza y franqueza, un equipo puede entregar el éxito y crecer más allá de las capacidades individuales de sus miembros para volverse una unidad de la representación alta.
Un equipo bueno tiene las personas y conocimientos que se exigen para entregar funcionando el software. Los miembros jornada completa del equipo deberían tener la mayoría o todos los conocimientos que se exigen para cumplir el proyecto. Los individuos especializados como diseñadores, las personas de las operaciones, arquitectos o expertos en una tecnología concreta no podrían estar disponibles a tiempo completo. El equipo puede contener especialistas externos para las actividades a corto plazo. Sin embargo, los miembros del equipo jornada completa deberían comprender a las personas que pueden cubrir la mayoría de los conocimientos que se exigen para completar el trabajo.
28
Responsabilidades básicas del equipo
La responsabilidad primaria del equipo es crear software que cumple con las expectativas del cliente y los criterios del equipo para el software acabado. El inicio de las responsabilidades del equipo comienza con la reunión de planeación del sprint y finaliza en la reunión de revisión del sprint. En la reunión de planeación del sprint, el equipo divide los casos de usuario en las tareas. En la reunión de revisión del sprint, el equipo presenta el software del funcionamiento al propietario del producto y posiblemente los clientes.
El equipo también es responsable de sus propios resultados. El equipo se administra para definir y completar el trabajo que ha seleccionado y para colaborar entre los miembros del equipo para optimizar la efectividad del equipo. Además, siempre debe trabajar para mejorar los resultados comprometiéndose en las siguientes actividades:
Definir los criterios para las tareas que están finalizados y finalice cada tarea antes de iniciarse el siguiente sprint.
Adoptar los ejercicios de la ingeniería efectivos.
Para obtener más información, vea Procedimientos de ingeniería.
Ayudar al propietario del producto a definir las tareas del sprint y dé prioridad a los casos de usuario efectivos.
Estimar los casos de usuario.
Scrummaster
Como ScrumMaster, tiene la responsabilidad de crear y mantener un equipo con una actitud positiva que cumpla los procesos de Scrum. Es el agente del cambio que ayuda al equipo a superar los impedimentos.
Cualidades de un buen ScrumMaster
Para ser un Scrummaster bueno, debería poseer o compilar comunicación excelente, negociación y conocimientos de la resolución de conflictos. Utilizará estos conocimientos diariamente para ayudar a su equipo a desarrollarse. Debe escuchar no sólo las palabras que las personas dicen y escriben activamente sino también cómo entregan sus mensajes (su lenguaje del cuerpo, expresiones faciales, paso vocal y otra comunicación no verbal). Debería hacer preguntas que revelan los problemas ocultos y confirman que se ha entendido lo que las personas dicen. Debería utilizar estos conocimientos para identificar los problemas potenciales en el equipo y ayudar a evitar que ellos se vuelvan los problemas reales. Es más barato corregir un error poco después de detectarlo, y es más fácil y menos molesto corregir un problema del equipo cuando es pequeño y manejable que cuando es grande y está fuera de control. Debería hacer que el equipo, el propietario del producto y la otra percepción de los interesados comercial estén a gusto como usted controle el equipo para aumentar su productividad significativamente. Debería recopilar, analizar y presentar datos a los interesados comerciales de una manera que muestra cómo el equipo está mejorando y crece. Por ejemplo, si su equipo ha aumentado la
29
cantidad de valor que ha entregado significativamente generando menos errores, debe mostrar esa mejora a los interesados comerciales.
Las responsabilidades básicas de un scrummaster
Su responsabilidad primaria es asegurarse de que el equipo y el propietario del producto siguen los procesos del Scrum. Por ejemplo, no debería permitir que la reunión del Scrum cotidiana se vuelva una discusión abierta que dura 45 minutos. También asegurarse de que el propietario del producto no pida al equipo que agregue más trabajo a un sprint cuando esté iniciado dicho sprint. Evitará que el equipo presente los casos de usuario en la reunión de revisión de sprint si esos casos de usuario no están finalizados completamente.
Ayudará a solucionar los problemas de bloqueo que pueda encontrar el equipo. Podría necesitar realizar las tareas pequeñas, como ayudar a aprobar un pedido de compra para un nuevo equipo de compilación o realizaría las tareas mayores, más desafiantes, como resolver los conflictos entre los miembros de su equipo. Cuando el equipo tiene un sprint complicado, debe ayudar al equipo a recuperarse y trabajar más eficazmente en el futuro.
Propietario del Producto
Como propietario del producto, su función primaria es actuar como punto de contacto entre los clientes y el equipo. Una variedad de clientes e interesados lo distraerá en muchas direcciones.
Características de un buen propietario de producto
Debe analizar los requisitos de cliente y articularlos como casos de usuario. Debe tener buenos conocimientos de la negociación para que pueda ayudar los clientes a entender los intercambios entre las características solicitadas y el impacto que tienen en la programación. Debe trabajar con los clientes para dar prioridad al Product Backlog para que el equipo genere los casos de usuarios más valiosos en cada sprint. Debe tener la especialización del contenido en el área comercial o industria del sistema que se compila. Por ejemplo, debe tener un fondo en el healthcare y seguros del healthcare si su equipo está construyendo un sistema de healthcare para un hospital. Sin este conocimiento, no se pueden asignar prioridades al Product Backlog con eficacia, ni explicar los elementos del Product Backlog al equipo. También beneficiará de los conocimientos financieros básicos, como la capacidad de entender el período del reembolso en un sistema, amortización del presupuesto y gasto presupuestado. Su comprensión del Scrum también es importante al éxito del equipo.
Las responsabilidades básicas del propietario del producto
Sus responsabilidades básicas son representar al cliente y sus requisitos al equipo y responder a las preguntas del equipo. Debe mantener el Product Backlog actual y darle prioridad a las tareas más importantes. Para mantener el Product Backlog, se debe comunicar regularmente con los clientes, los interesados y el equipo. Debe reunirse con las partes interesadas al menos cada semana o cada dos semanas. El orden en el que se implementan los casos de usuario afectará al período de reembolso y la cantidad de trabajo que el equipo debe realizar. El equipo le ayudará a entender cómo la secuencia de casos de usuario afecta al trabajo. Debe ayudar a los interesados a entender los efectos de estas
30
decisiones. También reduce la necesidad de las características técnicas detalladas estando disponible a los miembros del equipo cuando tienen las preguntas sobre cómo implementar la funcionalidad. Para mantener al equipo en acción, debe tener estas respuestas o ser capaz de encontrarlas muy rápidamente (en unas horas). Si no está disponible, los resultados del equipo sufrirán.
Nota
El nivel de detalle en las especificaciones depende de muchos factores, que incluyen el tipo de
aplicación que su equipo está desarrollando. Para muchas aplicaciones, casos de usuario elaborados
correctamente y líneas abiertas de comunicación son las características técnicas más efectivas. Sin
embargo, una aplicación de pruebas de laboratorio de procesos podrían requerir las características
técnicas detalladas para que el equipo pueda analizar el impacto de modificaciones que realizan con el
tiempo con más detalle.
También trabajará con el equipo y los interesados en las pruebas de aceptación de la compilación. La prueba de aceptación ayuda a determinar si un caso de usuario determinado se completa y prepara para la revisión del sprint. Debe entender, identificar y articular el riesgo para el equipo y las partes interesadas.
31
Reunión de planeamiento de plazos
El equipo compila el trabajo pendiente del sprint en la reunión de planeación el primer día del sprint. En dicha reunión, el propietario del producto trabaja junto con el equipo para determinar los casos que se van a completar en el sprint. La reunión de planeación tiene dos partes, y cada una se limita a la mitad de la duración total de la reunión. En la primera parte, el equipo y el propietario del producto identifican los casos de usuario que el equipo cree que puede completar en el sprint, según la experiencia de sprints anteriores. Una vez identificados los casos de usuario, se puede utilizar el libro Planeación del producto para asignarlos al sprint. Para obtener más información, vea el “Libro Planeación del producto” en la guía “Informes y Libros Agile” en el site de http://www.alightm.com.
En la segunda parte de la reunión, el equipo determina cómo desarrollará y probará esos casos de usuario. A continuación, el equipo desglosa esos casos de usuario en tareas y estima el trabajo necesario para completarlos. Por último, el equipo se compromete a implementar todos o algunos de los casos de usuario en función de dichas estimaciones.
En la primera parte de la reunión, el propietario del producto se reúne con el equipo para ver qué casos de usuario podrían incluirse en el sprint. El propietario del producto compartirá información y responderá a todas las preguntas del equipo referentes a esos casos. Esta conversación podría revelar detalles como los orígenes de datos, el diseño de la interfaz de usuario, las expectativas en materia de tiempo de respuesta y consideraciones referentes a la seguridad y la utilidad. El equipo deberá agregar estos detalles a los casos de usuario. En esta parte de la reunión, el equipo obtendrá información sobre lo que deberá compilar.
Después de abordar el equipo todos los detalles de los casos de usuario que crea oportunos, el scrummaster iniciará la segunda parte de la reunión de planeación. El propietario del producto debería asistir a esta parte de la reunión para ayudar a clarificar los requisitos y ayudar a entender y seleccionar las alternativas. El scrummaster facilita esta parte de la reunión cuando el equipo determina cómo va a implementar los casos de usuario y si puede comprometerse a implementar todos los casos solicitados por el propietario del producto. Para entender mejor lo que implica la finalización de cada caso de usuario, el equipo desglosa cada uno de los casos en tareas que debe realizar para implementar dicho caso y asegurarse de su finalización. Podría encontrar las siguientes tareas de ejemplo en el trabajo pendiente de la carrera corta: "Actualice el procedimiento almacenado para utilizar la nueva fuente de datos" y "Crear la clase para el recopilador del servicio web."
El equipo puede utilizar el libro Trabajo pendiente de iteración para desglosar los casos de usuario en tareas. Para obtener más información, vea “Libro de trabajo pendiente de iteración” en la guía “Informes y Libros Agile” en el site de http://www.alightm.com.
A continuación, el equipo hace una estimación del número de horas necesarias para cada una de las tareas. Dado que las tareas no se asignan sin estimación, los miembros del equipo se dedican a elaborar estas estimaciones. A menudo los equipos no pueden identificar y estimar todo el trabajo durante la reunión de planeación del sprint. Hasta el 40% del trabajo que completa un equipo durante un sprint sale a la luz después de la reunión de planeación del sprint.
La técnica de planeación de póquer es una herramienta apropiada para calcular las horas de una tarea. Con esta herramienta, cada miembro del equipo puede participar en la estimación, en lugar de
32
depender de los expertos en la materia para hacer una estimación de sus propias tareas. Independientemente de la técnica que se use, es necesario implicar a todo el equipo a la hora de determinar el número de horas que requerirá cada tarea. Para obtener más información, vea el siguiente recurso web: Planning Poker.
Las tareas no deberían tardar más de un día en completarse. Si una tarea es demasiado grande, el equipo deberá desglosarla. En algunos casos, quizás no pueda estimar algunas tareas eficazmente hasta que se hayan completado otras tareas. Cree la tarea ahora, pero estímela cuando tenga bastante información. Se suman las estimaciones de cada una de las tareas a fin de determinar cuántas horas va a necesitar probablemente el equipo para completar cada caso de usuario.
El equipo continúa analizando cada caso de usuario y hace estimaciones de sus tareas hasta que determine que dispone de suficientes casos para el sprint. Para ello, compara el número de horas estimadas con el número de horas que el equipo espera completar en el sprint.
Se puede utilizar la hoja de cálculo “Capacidad del equipo” incluida en el libro Trabajo pendiente de sprint como ayuda para determinar la capacidad del equipo para el sprint. Los detalles del sprint se deben rellenar en la hoja de cálculo “Configuración”. Para justificar los días de vacaciones, los días festivos y otras interrupciones, se debe rellenar la hoja de cálculo Interrupciones. Para obtener más información, vea “Libro de trabajo pendiente de iteración” en la guía “Informes y Libros Agile” en el site de http://www.alightm.com.
Se ha de avisar al propietario del producto si el equipo determina que no puede completar uno o varios de los casos solicitados por dicho propietario ya que las estimaciones para las tareas superan el número de horas disponibles. Puede que el propietario del producto opte por un caso de usuario más pequeño, divida el caso o lo guarde en el trabajo pendiente del producto para un futuro sprint. Después de que el equipo complete las dos partes de la reunión de planeación, habrá hecho lo siguiente:
Creado el trabajo pendiente del sprint, con tareas y horas para cada caso de usuario. Confirmado los casos de usuario que entregará en el sprint. Comprendiendo, como equipo autogestionado, cómo funcionarán juntos para cumplir con sus
compromisos.
33
Reunión de Scrum diaria
En rugby, un Scrum es una jugada, similar a un down en fútbol americano. En la metodología Scrum, la reunión de Scrum hace un día de trabajo como una jugada de rugby. Puede que se avance a base de golpes, pero el objetivo de progresar está claro y el equipo se esfuerza en conjunto para alcanzar ese objetivo común. El equipo debe celebrar reuniones de Scrum a diario para determinar lo que necesita hacer al día siguiente a fin de optimizar sus posibilidades de cumplir con los compromisos. Cada miembro del equipo describe lo que ha hecho desde la última reunión, el trabajo que piensa realizar ese día, y cualquier problema u obstáculo que pueda afectar o requerir la ayuda de los demás miembros del equipo.
El scrummaster hace cumplir estrictamente la estructura de la reunión, garantiza que se inicie a su hora y que termine, como máximo, en 15 minutos. En esta reunión, cada miembro del equipo responde a tres preguntas:
¿Qué he logrado desde el último Scrum? ¿Qué lograré antes del próximo Scrum? ¿Qué problemas de bloqueo o impedimentos podrían afectar a mi trabajo?
Es importante que los miembros del equipo respondan a estas preguntas rápida y concisamente. Un ejemplo de una respuesta buena es, "Ayer, actualicé la clase para reflejar el nuevo elemento de datos que extraemos de la base de datos y lo conseguí para aparecer en la interfaz. La tarea se ha completado. Hoy, me aseguraré de que el nuevo elemento de datos calcule correctamente con el procedimiento almacenado y los demás elementos de datos de la tabla. Creo que cumpliré esta tarea hoy. Necesitaré que alguien revise mis cálculos. No tengo ningún impedimento.” Compare esa respuesta con la siguiente: "Ayer, trabajé en la clase y funciona. Hoy, trabajaré en la interfaz. No tengo ningún impedimento."
Como muestran estos ejemplos, la primera respuesta comunica lo que se logró, lo que se logrará y que al miembro del equipo le gustaría tener ayuda para examinar el código. El segundo ejemplo no proporciona suficientes detalles sobre la clase en la que trabajó la persona ni sobre qué componentes de la interfaz se terminarán. De hecho, en ningún momento habla de logros.
Observe que nadie interrumpió durante la respuesta del ejemplo. No hubo ninguna conversación posterior en la que se hablara sobre quién podría ser la mejor persona para revisar los cálculos o sobre cómo se implementó la clase. Cada persona debe tener el tiempo suficiente para responder a las tres preguntas. El tiempo para la elaboración viene después de la reunión, cuando las personas vuelven a sus mesas o, si se necesita una cantidad significativa de conversación, en una reunión de continuación. Muchos equipos retrasan las discusiones utilizando el "virtual método del estacionamiento. "Cuando surgen temas que un miembro del equipo piensa que se deben discutir después, cualquier miembro del equipo puede ir tranquilamente a una pizarra o rotafolio y apuntar el tema en el estacionamiento. Al final de la reunión, el equipo planea la discusión de los temas que aparecen en la lista.
Otro aspecto de un Scrum correcto es que las personas están de pie. Cuando el equipo está de pie, los miembros se sienten incómodos, sobre todo cuando están hablando. Si todos están de pie, la reunión avanzará y no se fomentarán las conversaciones largas.
34
En tercer lugar, la reunión se debe iniciar y finalizar a tiempo, y debe realizarse a la misma hora y en el mismo lugar todos los días. Esta coherencia ayuda al equipo porque se puede establecer un patrón. Además, el equipo puede exponer datos y notas en el área donde se celebra la reunión, tales como evoluciones, problemas, planes de versiones y tareas. Alistair Cockburn llama a esto radiadores de información en Agile Software Development. Tener una ubicación donde almacenar y ver estos importantes activos cuando el equipo se reúne es una manera fácil de facilitar que las cosas funcionen sin problemas.
35
Reunión de revisión de sprint
En el último día del sprint, el equipo se reúne con el propietario del producto, los clientes y las partes interesadas para aceptar el trabajo completado e identificar nuevos requisitos. En el transcurso del sprint, el equipo puede que ya haya recopilado e incorporado los comentarios. El equipo también debería de haber realizado ya las pruebas de aceptación para cada caso de usuario completado. En esta reunión, el equipo muestra cada caso de usuario que completó en el sprint. El propietario del producto, los clientes y las partes interesadas aceptan los casos de usuario que cumplen sus expectativas. En muchos casos, los clientes entenderán mejor sus necesidades adicionales después de ver las demostraciones e identificar y discutir los cambios que desean ver.
De acuerdo con esta reunión, algunos casos de usuario se aceptarán como completados. Los casos de usuario incompletos permanecerán en el trabajo pendiente del producto, y se agregarán nuevos casos de usuario al trabajo pendiente del producto. Ambos conjuntos de casos se clasificarán y se estimarán o se volverán a estimar en la siguiente reunión de planeación de sprint.
Después de esta reunión y de la reunión retrospectiva, el equipo planeará el próximo sprint. Dado que las necesidades comerciales cambian con rapidez, se puede aprovechar esta reunión con el propietario del producto, los clientes y las partes interesadas para revisar de nuevo las prioridades del trabajo pendiente del producto.
36
Reunión retrospectiva
La reunión retrospectiva tiene lugar el último día del sprint, tras la reunión de revisión del sprint. En esta reunión, el equipo examina y explora su funcionamiento en los procesos de Scrum. En función de este análisis, el equipo podría tomar la decisión de adaptar sus procesos para mejorar su propia eficacia, productividad, calidad y satisfacción. Esta reunión y las mejoras resultantes son fundamentales para lograr una organización ágil y autónoma.
Si el equipo no completó todos los casos de usuario asignados al sprint, en la reunión retrospectiva se abordarán los motivos. El equipo determinará si puede adaptar sus procesos de modo que la probabilidad de que surjan esos problemas sea menor. También deben abordarse los problemas que afectaron a la eficacia global del equipo, la productividad, la calidad y el grado de satisfacción del grupo con respecto al proyecto.
Por ejemplo, piense en un equipo que tenía varias tareas que solo podía realizar un miembro del equipo. Ese aislamiento de los conocimientos creó una ruta crítica que amenazó el desarrollo satisfactorio del sprint. El miembro del equipo tuvo que trabajar muchas horas durante el sprint mientras el resto del equipo se sentía frustrado por no poder hacer más para ayudarle. Ese equipo decidió probar Extreme Programming para ayudar a corregir este problema con el tiempo.
En algunos casos, su equipo puede necesitar hacer algún trabajo para implementar una mejora. Por ejemplo, piense en un equipo que dedicaba demasiado tiempo a solucionar problemas de compilación. Ese equipo decidió implementar la integración continua. El equipo no deseaba arriesgarse a interrumpir su proceso de compilación normal. Por tanto, se asignaron unas horas para configurar una compilación de prueba antes de activarla en su compilación de producción. El equipo creó una maqueta y dio prioridad a ese trabajo frente al resto del trabajo pendiente del producto.
Para obtener más información sobre cómo llevar a cabo reuniones retrospectivas eficaces, vea los siguientes recursos web: Project Retrospectives: A Handbook for Team Reviews y Agile Retrospectives.
37
Visual Studio Scrum 1.0
Puede desarrollar los productos complejos utilizando el marco del Scrum, que está basado en los principios ágiles y valores.
Su equipo puede practicar Scrum más fácilmente utilizando los artefactos en Microsoft Visual Studio Scrum 1.0. Cada artefacto se utiliza para una función concreta y proporciona oportunidades para refinar los procesos a lo largo del tiempo. Estos artefactos incluyen elementos de trabajo, informes y consultas del equipo y su equipo puede utilizarlos para realizar el seguimiento de información, analizar el progreso y realizar las decisiones.
Puede descargar Scrum 1.0 de Visual Studio en la siguiente página en el sitio web de Microsoft: Microsoft Visual Studio Scrum 1.0. Para obtener más información sobre cómo instalar esta plantilla, vea en esta guía “Instalar la plantilla de Visual Studio Scrum 1.0".
Definiendo y realizando el seguimiento de Work
Items
Puede utilizar los elementos de trabajo para rastrear, monitorear y generar informe el progreso de desarrollo de un producto y sus características. Un elemento de trabajo es un registro de la base de datos que usted crea en Visual Studio Team Foundation Server para registrar la definición, asignación, prioridad y estado de un trabajo. La plantilla de proceso para Scrum 1.0 de Visual Studio define los siguientes tipos de elementos de trabajo:
Product BackLog Item Error Tarea Sprint Impedimento Caso de prueba El paso compartido
Puede especificar y actualizar información para cada elemento de trabajo en el formulario para ese elemento. Puede tener acceso o a los artefactos del nodo de proyecto de equipo en Team Explorer o en el portal del proyecto de equipo.
Con la plantilla de procesos de Scrum v1.0 usted contará con los siguientes items:
38
Tareas Contenido relacionado en esta Guía
Realice el seguimiento de los requisitos de producto. Su equipo define y actualiza
los elementos del Product Backlog para capturar los requisitos de su producto y
realizar el seguimiento de su progreso.
Elemento del
Product Backlog
Abrir y seguir errores. Su equipo define y actualiza los elementos de trabajo del
error para realizar el seguimiento de los defectos en el producto. Al definir un
elemento de trabajo de error, debe notificar el defecto con bastante precisión para
que otros miembros del equipo puedan entender el impacto completo del
problema.
Error
Seguir y estimar las tareas. Su equipo define y actualiza las tareas para realizar el
seguimiento del nivel de esfuerzo que se exige para implementar un elemento de
trabajo pendiente de producto. Las tareas deberían representar una unidad
pequeña de trabajo. Puede volver a definir las tareas mayores como subtareas
menores.
Tarea
Sprint. Su equipo define los elementos de trabajo del Sprint para capturar el
objetivo u objetivos, las fechas de finalización e inicio y los resultados retrospectivos
para cada sprint en su proyecto.
Sprint
Defina y administre los impedimentos. Su equipo puede crear los elementos de
trabajo del impedimento para definir problemas conocidos o los posibles problemas
y riesgos a su proyecto.
Impedimento
Probar la aplicación. Su equipo puede definir los elementos de trabajo del caso de
prueba para especificar pruebas que permitirán probar de los elementos del Product
Backlog. Puede definir pruebas manuales o casos pruebas automatizadas. Los casos
de la prueba manual especifican una secuencia de acción y pasos de la validación
para ejecutarse; la prueba automatizada hace referencia a un archivo de
automatización.
Casos de Prueba
Definir pasos compartidos. Su equipo puede definir los pasos compartidos para
especificar más fácilmente y mantener los casos de la prueba manual. Al definir los
pasos compartidos, especifica una secuencia de acción y pasos de la validación para
ejecutarse como parte de un caso de prueba. Muchas pruebas requieren realizar la
Pasos
compartidos
39
misma secuencia de pasos para varios casos de prueba. Creando los pasos
compartidos, puede definir una secuencia de pasos un tiempo e insertarlo en
muchos casos de prueba.
Encuentre y haga una lista de los elementos de trabajo. Puede administrar su carga
de trabajo más fácilmente utilizando las consultas integradas para encontrar los
elementos del Product Backlog, tareas, impedimentos y otros elementos de trabajo
para los que desea tomar medidas.
Consultas de
equipo
Supervisar y notificar el progreso de Equipo
Puede utilizar los informes en la siguiente tabla para realizar el seguimiento del progreso del equipo y progreso. Para más detalle de informes vea la guía “Informes y Libros Agile” en http://www.alightm.com.
Nota
Estos informes requieren que la recopilación del proyecto de equipo que contiene su proyecto de
equipo se proporcionó con SQL Server Reporting Services. Estos informes no están disponibles si la
opción “Informes” no aparece al abrir Team Explorer y expande su nodo de proyecto de equipo.
También, “ver estos informes”, debe estar asignado o pertenecer a un grupo que ha tenido asignado el
Explorador o rol de Team Foundation Content Manager en Reporting Services. Para obtener más
información, vea Agregar usuarios a proyectos de equipo o Administrar permisos.
Tareas Contenido relacionado en esta Guía.
Evolución de equipo de pista para los elementos de trabajo pendiente y
tareas. Puede seguir cómo rápidamente su equipo ha completado el trabajo
y cuánto funcionan los restos en un trabajo pendiente del producto o en un
trabajo pendiente de la carrera corta revisando un informe de evolución de
lanzamiento o un informe de evolución de carrera corta.
Evolución de
Versiones.
Evolución de sprint.
Seguir el Progreso del equipo. Puede seguir cuánto esfuerzo su equipo ha
completado para cada sprint revisando su informe de progreso. Puede
predecir también cuánto esfuerzo del Product Backlog su equipo puede
ejercer en sprint futuros si su composición del equipo y estancia de duración
Progreso.
40
de sprint es constante.
Actividad de compilación de pista, éxito y tendencias. Puede realizar el
seguimiento con el tiempo de la calidad y éxito de las compilaciones de su
equipo revisando los informes de la compilación.
Informe de
compilaciones
correctas
Informe Resumen
de la compilación
Actividad de prueba de pista. Puede realizar el seguimiento del progreso del
equipo hacia desarrollar los casos de prueba y puede determinar cómo bien
el equipo cubre sus casos de usuario si revisa los informes de pruebas.
Informe
Disponibilidad de
casos de prueba
Informe de
progreso del plan
de pruebas
41
Instalar la plantilla de Visual Studio Scrum 1.0
A continuación se presenta la traducción del artículo Microsoft Visual Studio Scrum 1.0 de Jhon Bristowe
del 19 de Julio de 2010.
“¡Buenas noticias! El día de hoy, anunciamos Microsoft Visual Studio 1.0 Scrum , una plantilla de procesos construidos desde cero específicamente para equipos de Scrum. De MSDN:
Su equipo puede practicar Scrum más fácilmente mediante el uso de los artefactos en Visual Studio 1.0 Scrum. Cada artefacto tiene una función específica y ofrece la oportunidad de perfeccionar sus procesos a través del tiempo. Estos artefactos son los elementos de trabajo, informes y consultas de equipo, y su equipo puede utilizar para el seguimiento de información, analizar los avances y tomar decisiones.
Esta plantilla de proceso fue anunciado por primera vez en Microsoft TechEd 2010 en Nueva Orleans a principios de este verano y ha sido recientemente actualizada para incorporar una serie de nuevas capacidades. Usted puede leer el post del blog de Brian Harry para leer más acerca del motivo de la actualización. Para la liberación v1.0, Aaron Bjork proporciona un buen resumen de lo que puede esperar en esta liberación en su blog. De las preguntas en la lista, he encontrado este que es particularmente interesante:
Q: ¿Microsoft trabajó con líderes del pensamiento ágil en la construcción de esta plantilla? Por supuesto. Hemos trabajado estrechamente con un grupo de expertos y formadores de la enseñanza de Scrum el nuevo Programa de Desarrolladores Profesionales Scrum como Ken Schwaber de http://www.scrum.org/. Fue muy importante para nosotros que esta plantilla sea reconocida por la comunidad como una gran opción para los equipos de Scrum. El Programa Profesional de desarrollo Scrum se enseña con Microsoft Visual Studio 1.0 Scrum.
Un Tutorial de instalación rápida
En primer lugar, descargar e instalar Microsoft Visual Studio Scrum 1.0 de la Galería de Visual Studio . Es un paquete (pequeño) MSI 483kb que le proporcionará los archivos necesarios tanto para el Administrador de plantilla de procesos (para instalar la plantilla de proceso de Scrum) y el portal del proyecto (para los informes de Scrum). Como alternativa, puede descargar Microsoft Visual Studio 1.0 Scrum a través del Administrador de extensiones de Visual Studio 2010 (que aparece en línea Galería de plantillas de procesos → Herramientas →):
42
Microsoft Visual Studio 1.0 Scrum en el Administrador de extensiones de Visual Studio 2010
A continuación, ejecute el Explorador de plantillas de procesos en Visual Studio 2010 (Equipo → Equipo de Configuración de la colección del Proyecto → Administrador de plantillas de procesos ...):
Proceso del Administrador de plantilla
Haga clic en el botón Upload y seleccione la carpeta donde está instalado la plantilla de proceso de Microsoft Visual Studio Scrum 1.0 (es decir, C: \ Archivos de programa (x86) \ Microsoft \ Microsoft Visual Studio 1.0 Scrum plantilla de procesos \). Una vez instalado el Microsoft Visual Studio 1.0 Scrum debe aparecer en el Administrador de plantillas de procesos de la siguiente manera:
43
Administrador de plantillas de procesos con Microsoft Visual Studio 1.0 instalado Scrum
Para proyectos basados en esta plantilla, debería ver la estructura que se muestran en Team Explorer en Visual Studio 2010:
44
Estructura del Equipo de Explorer con Microsoft Visual Studio Plantilla de Proceso de Scrum 1.0 instalado
Como se puede ver en la imagen de la ventana Explorador de equipo (antes mencionados), artefactos (como los elementos de trabajo) se definen de acuerdo a la literatura de Scrum. Usted puede crear errores, un impedimento, sprints, y muchos otros artefactos, todo ello desde la ventana de Team Explorer.
Por cierto, si usted está buscando para mover los datos de un proyecto existente en un nuevo proyecto integrado de Microsoft Visual Studio Scrum 1.0, usted debe comprobar la integración de Plataforma TFS en CodePlex. “
45
46
Crear un Product Backlog
El equipo crea un Product Backlog, que normalmente contiene casos de usuario, para representar lo que los clientes necesitan y valoran. A lo largo del proyecto, el equipo agregará información detallada a los casos de usuario, los desglosará en casos más pequeños, los clasificará según su prioridad, realizará cálculos estimativos y, por último, los implementará y entregará los resultados a sus clientes. Al escribir excelentes casos de usuario y actualizar continuamente el trabajo pendiente del producto, el equipo podrá proporcionar más eficazmente valor a los clientes.
Bill Wake resume las características de un buen caso de usuario mediante el acrónimo INVEST (siglas en inglés de independiente, negociable, valioso, calculable, pequeño y susceptible de ser sometido a prueba). Para obtener más información, vea el siguiente sitio web: XPlorations. Mike Cohn explica cómo escribir casos de usuario uno de sus libros. Puede descargar el capítulo pertinente del siguiente sitio web: User Stories Applied for Agile Software Development.
Cuando el equipo crea una historia de usuario, asegúrese de que represente el correspondiente valor para el cliente. Para ello, responda a las siguientes preguntas:
¿Quién es el usuario? ¿Qué tiene que hacer el usuario? ¿Por qué el usuario necesita hacerlo?
En la mayoría de los casos, el equipo puede lograrlo creando un título eficaz. Mike Cohn sugiere el formulario "Como un < usuario >, necesito la < acción > en orden a < razón >." Puede considerar este enfoque en el ejemplo donde: “Como representante del soporte al cliente, necesito tener acceso a información del cliente para poder responder más rápidamente a las preguntas del cliente." En muchos casos, la razón es obvia. Por ejemplo, "Como un vegetariano, puedo filtrar mi vista para sólo ver las comidas vegetarianas."
Los casos de usuario también se deben definir de tal forma que se puedan implementar en cualquier orden. Sin embargo, no siempre resulta práctico crear casos de usuario completamente independientes. Bill Wake y Mike Cohn describen técnicas que el equipo puede utilizar cuando crear casos de usuario independientes plantee un reto.
Los casos de usuarios valiosos e independientes, como se ha descrito previamente, constituyen el trabajo pendiente del producto. Se calculan y clasifican por orden de prioridad. A continuación, el equipo empieza a trabajar en los casos de usuario que ocupan los primeros puestos de la clasificación. Antes de implementar un caso de usuario, el equipo debe disponer de las características de la siguiente lista de requerimientos. El propietario del producto trabajará para asegurarse de que los casos de usuario clasificados en los puestos prioritarios cumplan estos criterios antes de presentarlos en una reunión de planeación de sprint. Para ello se debe tener en cuenta:
Lo casos de usuario deben ser los bastante reducidos para implementarlos en el sprint:
Los casos de usuario que están a punto de implementarse deben tener un tamaño lo bastante reducido para poder finalizarlos en el sprint. El propietario del producto trabajará con el equipo a
47
fin de desglosar los casos de usuario que sean demasiado grandes. Por ejemplo, el caso de usuario "Como un representante del soporte al cliente, necesito el acceso a información del cliente para que pueda responder más rápidamente a las preguntas del cliente” puede ser demasiado grande para finalizar en una carrera corta. Se pudo irrumpir abajo en los artículos como "Como un representante del soporte al cliente, necesito tener acceso al nombre del cliente y el reciente resumen de llamadas utilizando el número de teléfono del cliente" y "Como un representante del soporte al cliente, necesito tener acceso al historial de la llamada completo de los clientes para que pueda investigar el problema actual con más detalle."
Con los detalles suficientes para describir y calcular el trabajo necesario para implementar el caso:
Antes de incluirlos en un sprint, se efectúa el cálculo de puntos de cada caso de usuario. Se trata de cálculos intencionadamente aproximados que se utilizan sobre todo para administrar el trabajo pendiente y ayudar a preparar el sprint. Al iniciar un sprint, el equipo desglosará el caso de usuario en las tareas necesarias para implementarlo. El equipo trabajará con el propietario del producto en la reunión de repaso del trabajo pendiente del producto, a fin de determinar qué casos requieren más información antes de poder desglosarlos en tareas y calcular las horas de trabajo. El propietario del producto puede recopilar estos detalles y registrarlos en la descripción del caso de usuario.
Asegúrese de no agregar más detalles de los necesarios al caso de usuario. El caso de usuario debe ser la base de una conversación y negociación con el propietario del producto y los clientes, que continuarán hasta que el caso de usuario quede finalizado y aceptado. Demasiados detalles pueden obstaculizar la negociación creando una idea implícita de precisión que no es exacta.
Definición de los criterios de aceptación:
Al final de un sprint, los clientes o el propietario del producto aceptarán el caso de usuario como finalizado o lo rechazarán. Antes de iniciar el sprint, se deben describir los criterios para la aceptación por parte del cliente con tanta claridad como sea posible. Por supuesto, puede suceder que un caso de usuario no acepte por motivos imprevistos. Sin embargo, las conversaciones que el equipo mantiene con los clientes para ayudar a definir los criterios de aceptación ayudarán a asegurarse de que el equipo entienda las expectativas de sus clientes. Los criterios de aceptación se pueden utilizar como base para las pruebas de aceptación, a fin de permitir una evaluación más eficaz de si un caso de usuario ha finalizado o no.
Epopeyas y temas
Se insiste con frecuencia en que los casos de usuario deben ser pequeños. Esto es así para aquellos que están a punto de implementarse. Sin embargo, los casos con menor rango pueden ser más grandes. De hecho, que sean grandes es una manera eficaz de impedir que el trabajo pendiente del producto sea demasiado grande para administrarlo bien. Los casos de usuario se pueden desglosar en casos de usuario más pequeños a medida que se acercan la parte superior de la clasificación según su prioridad del trabajo pendiente del producto. Resulta útil considerar los casos de usuario grandes como epopeyas y temas.
48
Las epopeyas son casos de usuario de gran tamaño que representan una cantidad de trabajo significativa. Al desglosar una epopeya, se pueden crear numerosos temas y otros casos de usuario más pequeños.
Los temas son casos de usuario de tamaño relativamente grandes, generalmente mayores de lo que se implementaría en un sprint. Antes de que el equipo implemente un tema, se debe desglosar en casos de usuario menores.
Al clasificar trabajo pendiente del producto según su prioridad, deben desglosarse las epopeyas y los temas más próximos a la parte superior. A continuación, deberán clasificarse según su prioridad los nuevos casos de usuario, más pequeños. Cuando haya finalizado, los casos de usuario de máxima prioridad deberían ser lo bastante pequeños para implementarlos. En general, la mayoría de los casos de usuario son más grandes a medida que se desciende por el trabajo pendiente clasificado según su prioridad.
Picos
En ocasiones, el equipo tendrá que realizar trabajos que no sean una implementación directa de un caso de usuario. Este trabajo se denomina pico. Tres tipos comunes de picos son investigación, errores pendientes y mejoras de procesos o de ingeniería. Para crear un pico en Team Foundation, cree un elemento de trabajo de caso de usuario, establezca su tipo en Pico y, a continuación, clasifíquelo según su prioridad en el trabajo pendiente del producto, junto con los demás casos de usuario.
Investigación:
La investigación se produce cuando hay preguntas abiertas sobre un caso de usuario que se deben responder para poder desglosar completamente en tareas el caso de usuario y calcularlo. Por ejemplo, el equipo se encuentra con el artículo "Como un prospecto frecuente, puedo reservar el viaje del premio" durante una reunión de planeación del sprint. Después de debatirlo, tienen más preguntas que respuestas. El equipo crea un caso de usuario que represente este pico. Como un miembro del equipo, puedo entender eso que 'viaje de premio' los recursos para que pueda escribir los artículos para incluir en sprints futuros. Cuántas horas el equipo determina está deseoso para dedicar a esa investigación y escribe ese número como timebox para la púa. Ninguno de los casos escritos durante el pico se puede realizar durante esa iteración. El trabajo se debe programar para una iteración futura utilizando el trabajo pendiente del producto.
Errores pendientes:
El mejor momento para corregir un error es cuando se encuentra. Si no puede corregirlo en el mismo día en que lo encontró, debe crear un elemento de trabajo de error para asegurarse de no perderle la pista. Asegúrese de no acumular errores. Si el equipo acumula errores, cree un caso de usuario y vincule los errores al pico, para poder calcularlo y clasificarlo según su prioridad junto con los demás casos de usuario y picos.
49
Mejoras de procesos o ingeniería:
El equipo realizará mejoras de procesos o ingeniería que le ayudarán a realizar correctamente su labor. Con frecuencia, estas mejoras se identifican durante las reuniones retrospectivas de los sprints y las reuniones de Scrum cotidianas. Por ejemplo, puede que el equipo necesite mejorar la cobertura de código de las pruebas unitarias, o reducir el tiempo de compilación en el servidor de integración continua.
50
Comparar los trabajos pendientes del producto
y el plazo
El trabajo pendiente del producto y el trabajo pendiente del sprint sirven para propósitos distintos pero similares. El trabajo pendiente del producto es administrado principalmente por el propietario del producto y contiene una vista de alto nivel de todo el trabajo que su equipo debe completar para crear el producto. El propietario del producto clasifica los casos de usuario en el trabajo pendiente del producto y proporciona el detalle suficiente durante la reunión de planeación del sprint para que el equipo pueda estimar e implementar cada caso de usuario.
En cambio, el equipo crea el trabajo pendiente del sprint, que contiene una lista detallada de todas las tareas que el equipo debe completar para finalizar los casos de usuario para el sprint. En el trabajo pendiente del producto, el equipo estima los casos de usuario con la unidad relativa de puntos del caso de usuario. En el trabajo pendiente del sprint, el equipo estima las tareas en horas.
El propietario del producto actualiza el trabajo pendiente del producto cada semana, pero el equipo actualiza al menos diariamente el trabajo pendiente del sprint.
El propietario del producto mantiene el mismo trabajo pendiente del producto a lo largo del proyecto, pero el equipo crea un nuevo trabajo pendiente del sprint para cada sprint.
En la tabla siguiente se detallan muchas de las diferencias clave entre el trabajo pendiente del producto y el del sprint.
Elemento Trabajo pendiente del producto Trabajo pendiente del sprint
Nivel de detalle Menos detallado Muy detallado
Unidades de estimación Puntos de caso Horas
Propiedad de la documentación Propietario del producto Equipo
Revisado Semanal Diario
Duración Proyecto Sprint
Libro Product Backlog Sprint Product Backlog
51
Libro Planeación del producto
Puede usar el libro Planeación del producto (Product Planning) para administrar el trabajo pendiente y el desarrollo de casos de usuario, determinar el progreso del equipo y equilibrar la carga de trabajo entre varias sprints, también conocidas como sprints. Para planear una iteración, revise, clasifique, establezca prioridades y asigne puntos a los casos de usuario que se implementarán para un proyecto. Para equilibrar la carga de trabajo, asigne cada caso de usuario a una iteración concreta y ajuste estas asignaciones hasta el número de puntos de caso de usuario asignados para todas las iteraciones sea aproximadamente igual.
Nota
El libro Planeación del producto está almacenado en el servidor que hospeda Productos de
SharePoint para su proyecto de equipo. Si no se ha habilitado un portal para el proyecto de equipo,
no se puede obtener acceso al libro. Para obtener más información, vea Acceso a la guía de procesos
y al portal del proyecto de equipo.
Además, al abrir el libro por primera vez, debe habilitar las macros haciendo clic en Opciones,
situado al lado de Advertencia de seguridad. Para modificar el contenido, debe hacer clic en Editar
libro, situado al lado de Libro del servidor. Para obtener más información, vea la guía “Informes y
Libros Agile en http://www.alightm.com.
Si su proyecto de equipo se creó antes del lanzamiento de Visual Studio Application Lifecycle
Management (ALM), debe realizar las tareas de actualización para que pueda utilizar el libro Trabajo
pendiente del producto con su proyecto de equipo. Para obtener más información, vea “Agregar
libros de trabajo a proyectos de equipo” en la guía “Informes y Libros Agile” en
http://www.alightm.com.
52
En el siguiente grafico se muestra la ubicación del Libro de Planeación del Producto:
Permisos necesarios
Para crear o modificar los casos de usuario o tareas, debe ser miembro del grupo Contributors o tener los permisos Ver los elementos de trabajo en este nodo o Editar elementos de trabajo en este nodo establecidos en Permitir.
Para agregar sprints o cambiar la estructura del proyecto, debe ser miembro del grupo Project Administrators o debe tener los permisos Crear y ordenar nodos secundarios, Eliminar este nodo y Editar este nodo establecidos en Permitir.
Para obtener más información, consulte Permisos de Team Foundation Server.
53
Administrar el Product Backlog
Puede usar el libro Planeación del producto para equilibrar la carga de trabajo entre varios sprints. Este libro proporciona tres hojas de cálculo, tal como muestra la ilustración siguiente y se describe más adelante en este tema.
Product Backlog: utilice esta hoja de cálculo para filtrar y clasificar los casos de usuario que desea administrar y clasificarlos por orden de prioridad. Puede especificar los puntos del caso de usuario y asignar los casos de usuario a los sprints.
La hoja de cálculo Product Backlog hace referencia a la consulta de equipo Product Backlog, que busca todos los casos de usuario definidos para el proyecto de equipo. Dentro del libro, puede filtrar los casos de usuario basándose en el área de producto. Además, puede realizar cualquiera de las acciones siguientes:
Agregar casos de usuario al trabajo pendiente del producto.
Reordenar la lista de casos de usuario.
Planeamiento del sprint: utilice esta hoja de cálculo para programar los sprints, revisar la carga de trabajo para cada sprint y determinar cómo equilibrar la carga de trabajo entre los sprints.
Interrupciones: utilice esta hoja de cálculo para especificar las vacaciones u otras fechas en que el equipo no realizará ningún trabajo.
Clasificar y estimar los casos de usuario
Después de crear el conjunto inicial de casos de usuario en el trabajo pendiente, el equipo estima el tamaño de cada caso y, a continuación, los clasifica para determinar el orden en el que el equipo los implementará. Normalmente, el proceso se inicia clasificando cada caso de usuario, a continuación, el equipo estima el tamaño de cada caso y, a continuación, los clasifica de nuevo en función de las estimaciones de punto de caso de usuario del equipo.
54
Los puntos de caso de usuario miden la cantidad y complejidad del trabajo que requiere cada caso de usuario en comparación con todos los demás casos de usuario del trabajo pendiente. Los equipos deben intentar no ser demasiado precisos con estas estimaciones. Solo sirven para ayudar a identificar las contrapartidas adecuadas cuando los equipos determinan el rango de cada caso de usuario, que indica la importancia del caso en comparación con los otros casos del trabajo pendiente. Los equipos también pueden especificar un nivel alto, medio o bajo de riesgo para que cada caso de usuario indique un nivel relativo de incertidumbre sobre los requisitos o el diseño del caso de usuario.
Para clasificar y estimar los casos de usuario
1. En el libro Planeación del producto, haga clic en la hoja de cálculo Trabajo pendiente del producto.
2. Si se ha abierto un libro guardado, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en Actualizar.
Este paso ayuda a asegurarse de que la lista de casos de usuario y tareas contiene la información más actual.
3. (Opcional) Para filtrar la lista de casos de usuario por área de producto, en la lista Área, active la casilla situada al lado de cada área de producto que desee incluir. Para definir más rutas de acceso de área, vea “Definir iteraciones adicionales” más adelante en este tema.
4. Revise los valores para el rango y los puntos de caso de usuario para cada caso y actualice los campos en la siguiente tabla según sea necesario:
Nombre del campo
Descripción
Rango en
la pila
Una clasificación subjetiva del caso de usuario comparado con todos los otros demás
casos de usuario en el trabajo pendiente. Un caso de usuario que tiene asignado un
número menor se debería implementar antes que un caso de usuario que tiene
asignado un número mayor.
Puntos de
caso
Una medida subjetiva del tamaño y complejidad del caso de usuario. Para asignar los
puntos del caso de usuario, el equipo debe considerar varios factores y estimar el
tamaño de un caso de usuario en comparación con los otros casos de usuario en el
trabajo pendiente.
Riesgo Clasificación subjetiva de la incertidumbre relativa en cuanto a la terminación
correcta del caso de usuario. Los equipos pueden especificar los valores siguientes:
1 - Alto
2 - Medio
3 – Bajo
55
5. En la ficha Equipo, en el grupo Elementos de trabajo, haga clic en Publicar.
Nota
Puede usar la característica de reversión de un comando en Excel para deshacer los cambios
recientes que realizó en los elementos de trabajo antes de publicar los cambios.
6. Para obtener más información, vea Publicar elementos de trabajo en Office Excel.
7. Haga clic en .
El libro se guarda en el sitio de portal del proyecto de equipo.
Planear los Sprints
La planeación de sprints es un proceso iterativo en el que se siguen estos pasos:
1. (Opcional) Definir sprints adicionales.
2. Programar los sprints.
3. Tener en cuenta las vacaciones y las interrupciones planeadas.
4. Equilibrar la carga de trabajo entre los sprints.
Definir iteraciones adicionales
Antes de poder asignar los casos de usuario a las iteraciones, será conveniente definir todas las iteraciones para el proyecto de equipo. La ilustración siguiente muestra la estructura de iteración predeterminada que se define en la plantilla de proceso para MSF for Agile Software Development v5.0.
Puede cambiar el nombre las iteraciones, agregar iteraciones y cambiar la jerarquía del árbol de las iteraciones.
Puede modificar el área de producto y la estructura de iteraciones mediante Team Web Access, Team Explorer, Office Excel u Office Project. El procedimiento siguiente describe cómo agregar iteraciones desde Office Excel. Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
56
Para agregar iteraciones al proyecto de equipo desde Office Excel
1. En el libro Planeación del producto, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en Editar áreas e iteraciones.
Se abrirá el cuadro de diálogo Áreas e iteraciones.
2. Haga clic en la pestaña Iteración y realice uno de los pasos siguientes o ambos: Para agregar una iteración, haga clic en el nodo primario, haga clic en el botón Agregar un
nodo secundario en la barra de herramientas, escriba un nombre para la nueva iteración y, a continuación, presione ENTRAR.
Para promover un nodo, degradar un nodo o mover un nodo arriba o abajo en la lista, haga clic en el nodo y, a continuación, haga clic en el botón adecuado en la barra de herramientas.
3. Haga clic en Cerrar.
Programar las iteraciones
Para programar las iteraciones, agregue cada iteración a la hoja de cálculo Planeamiento de la iteración y especifique sus fechas de inicio y fin. Este paso proporciona los datos necesarios para equilibrar los casos de usuario entre las iteraciones.
Para programar las iteraciones
1. En el libro Planeación del producto, haga clic en la hoja de cálculo Iteraciones.
2. (Opcional) Para filtrar los casos de usuario, haga clic en la flecha abajo en la celda situada al lado de Área y, a continuación, haga clic en el área de producto que desee incluir.
3. Para cada iteración del planeamiento, realice las siguientes acciones en el área de tabla que aparece bajo Puntos de caso por iteración:
a. Haga clic en la celda situada debajo de Iteración, haga clic en la flecha abajo y, a continuación, haga clic en la iteración que desee incluir.
b. Haga clic en la celda situada debajo de Fecha de inicio y escriba la fecha del calendario para el inicio de la iteración.
El formato de fecha debe ser el mes/día/año.
c. Haga clic en la celda situada debajo de Fecha de finalización y escriba la fecha del calendario para el fin de la iteración.
El formato de fecha debe ser el mes/día/año.
d. Haga clic en la celda en Tamaño del equipo y escriba el número de miembros del equipo que trabajarán en la iteración.
La hoja de cálculo halla automáticamente las siguientes columnas:
57
La columna de días se calcula dependiendo de las fechas de inicio y finalización. Las columnas de casos planeados y entregados se calculan a partir de la hoja de cálculo
Trabajo pendiente del producto. Los puntos de los casos de usuario que se han resuelto o cerrado se cuentan como entregados. Únicamente los puntos de caso que están asignados a casos de usuario activos se cuentan como planeados.
A medida que complete cada fila para cada iteración, aparecerá una barra en el gráfico Velocidad para indicar los puntos de caso que se asignan a cada iteración.
Tener en cuenta las vacaciones y las interrupciones planeadas
Puede usar la hoja de cálculo Interrupciones para especificar los días en que el equipo realizará poco trabajo o ninguno, como vacaciones o eventos del equipo. El número de días en cada iteración se actualiza en la hoja de cálculo Planeamiento de la iteración para reflejar estas interrupciones.
Para tener en cuenta las interrupciones del trabajo planeadas o por vacaciones
1. En el libro Planeación del producto, haga clic en la hoja de cálculo Interrupciones. 2. Haga clic en la celda situada debajo de Descripción y escriba el nombre de las vacaciones o del
motivo para la interrupción del trabajo. 3. Haga clic en la celda situada debajo de Fecha y escriba la fecha para las vacaciones o la
interrupción del trabajo. 4. Agregue a la hoja de cálculo todas las fechas que correspondan a las iteraciones planeadas.
Equilibrar la carga de trabajo entre sprints
Al asignar cada caso de usuario a un sprint, agregue el trabajo a ese sprint. Normalmente, los casos de usuario con una clasificación más alta se implementan primero. Sin embargo, para equilibrar la carga de trabajo entre varias iteraciones, podría ser necesario realizar ajustes iterativos en las asignaciones de iteración.
Inicialmente, podría dividir el número de casos de usuario que se van a implementar entre el número de iteraciones que ha planeado. Esta estrategia puede proporcionar una línea base para iniciar la asignación de casos de usuario a las iteraciones.
Antes de equilibrar los casos de usuario entre las iteraciones, asegúrese de que se han completado los pasos siguientes:
Cada caso de usuario tiene asignados los puntos de caso de usuario. Asimismo, un procedimiento recomendado es tener casos de usuario de un tamaño en puntos similar.
Se han clasificado los casos de usuario y la hoja de cálculo Trabajo pendiente del producto se ha ordenado por rango.
Las iteraciones que se van a planear se han agregado a la hoja de cálculo Iteraciones. El tiempo no laborable para el equipo se ha tenido en cuenta en la hoja de cálculo Interrupciones.
58
Para equilibrar la carga de trabajo entre las iteraciones
1. En la hoja de cálculo Trabajo pendiente del producto, realice el primer paso de especificar la
iteración para cada caso de usuario haciendo clic en la flecha abajo situada al lado de Iteración y, a continuación, haga clic en la iteración.
2. En la hoja de cálculo Iteraciones, vea los puntos del caso de usuario asignados a cada iteración. Si los puntos del caso de usuario no están uniformemente distribuidos entre las iteraciones, tal como muestra la ilustración siguiente, ajuste la asignación de las iteraciones hasta que estén equilibradas.
3. Determine cuántos puntos del caso de usuario debe mover de una iteración a otra.
Nota
Si el tamaño del equipo no sigue siendo constante entre las iteraciones, será conveniente
factorizar estas diferencias en el planeamiento.
4. En la hoja de cálculo Trabajo pendiente del producto, cambie las asignaciones de iteración hasta que el número de puntos de caso de usuario sea aproximadamente igual entre todas las iteraciones.
59
En la siguiente ilustración se muestra el trabajo que se ha equilibrado para cinco iteraciones.
5. Haga clic en .
El libro se guarda en el sitio de portal del proyecto de equipo.
Revisar el progreso de Equipo
El progreso de su equipo es el número de puntos de caso que puede completar en una iteración. Una vez completadas varias iteraciones, puede revisar el progreso del equipo viendo la hoja de cálculo de las Iteraciones. Como se muestra en la siguiente ilustración, el progreso del equipo es 15 puntos de caso para Iteración 1 y 16 puntos de caso para Iteración 2.
Continuando realizando el seguimiento de los puntos de caso por las iteraciones, puede pronosticar las próximas iteraciones mejor.
60
Agregar casos de usuario al trabajo pendiente del
producto
Puede definir los casos de usuario si los agrega al libro Trabajo pendiente del producto y lo publica en la base de datos para realizar el seguimiento del elemento de trabajo. Aunque el proyecto esté en curso, el equipo podría continuar creando, estimando y clasificando los casos de usuario.
Para agregar casos de usuario a la base de datos para realizar el seguimiento de los
elementos de trabajo
1. En Office Excel, abra el libro Planeamiento del producto. 2. Si se ha abierto un libro guardado, en la pestaña Equipo, en el grupo Elementos de trabajo,
haga clic en Actualizar.
Este paso ayuda a asegurarse de que la lista de casos de usuario contiene la información más actual.
3. Para cada caso de usuario que desee agregar, haga clic en la fila en la parte inferior de la lista y especifique la información siguiente:
En Título, escriba una entrada que identifique al cliente tan específicamente como sea posible y describa el objetivo del cliente en un nivel alto.
Por ejemplo, podría especificar "Como un < tipo de cliente >, deseo < realizar esta operación >."
En la lista Tipo de elemento de trabajo, haga clic en Caso de usuario.
Nota
Para poder publicar un elemento de trabajo, debe especificar el tipo de elemento de
trabajo que desea publicar.
4. (Opcional) Para mostrar campos adicionales de Team Foundation en la lista de elementos de trabajo, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en Elegir columnas.
Para obtener más información, vea Agregar o quitar columnas de una lista de elementos de trabajo.
5. Agregue información a los campos restantes según corresponda.
Para obtener más información sobre cada campo, vea en esta guía “Caso de usuario”.
61
6. (Opcional) Guarde el libro.
7. En la ficha Equipo, en el grupo Elementos de trabajo, haga clic en Publicar.
Reordenar la lista de casos de usuario
Puede reordenar los casos de usuario en el libro Planeamiento del producto mediante la característica para ordenar filas de Excel.
Para reordenar la lista de casos de usuario en el libro
1. Para reordenar los casos de usuario, realice una de las acciones siguientes:
Haga clic en la flecha abajo situada al lado de Rango en la pila y, a continuación, haga clic en la opción de ordenación que desee.
Haga clic en la flecha abajo situada al lado de Puntos de caso y, a continuación, haga clic en la opción de ordenación que desee.
2. (Opcional) Guarde el libro.
Recursos adicionales para administrar el trabajo
pendiente del producto
Para obtener más información sobre cómo modificar los casos de usuario mediante Office Excel, vea los temas siguientes:
Crear, abrir y modificar elementos de trabajo mediante Office Excel Agregar o quitar columnas de una lista de elementos de trabajo Publicar elementos de trabajo en Office Excel Conectar documentos de Microsoft Office con Team Foundation Server Ordenar, filtrar o dar formato a una lista de elementos de trabajo
62
Libro de trabajo pendiente de iteración
Puede usar el libro Trabajo pendiente de iteración para planear y seguir el progreso del trabajo para cada iteración, también conocida como sprint. Este libro calcula la capacidad del equipo y la evolución basada en el esfuerzo estimado y el restante definidos para las tareas. Los libros predeterminados proporcionan cinco hojas de cálculo que puede utilizar para planear el trabajo, calcular la capacidad del equipo y visualizar la evolución para la iteración. Puede crear libros adicionales según sea necesario para admitir las iteraciones adicionales.
Nota
El libro Trabajo pendiente de iteración está almacenado en el servidor que hospeda Productos de
SharePoint para su proyecto de equipo. Si no se ha habilitado un portal para el proyecto de equipo, no
se puede obtener acceso al libro. Para obtener más información, vea Acceso a la guía de procesos y al
portal del proyecto de equipo.
Además, al abrir el libro por primera vez, debe habilitar las macros haciendo clic en Opciones, situado
al lado de Advertencia de seguridad. Para modificar el contenido, debe hacer clic en Editar libro,
situado al lado de Libro del servidor. Para obtener más información, vea Libros.
Si su proyecto de equipo se creara antes del lanzamiento de Visual Studio Application Lifecycle
Management (ALM), tendrá que realizar las tareas de actualización para que su proyecto de equipo
pueda utilizar el libro de Iteración Trabajo pendiente. Para obtener más información, vea Agregar
libros de trabajo a proyectos de equipo.
63
En el siguiente grafico se muestra la ubicación del Libro de Planeación del Producto:
Permisos necesarios
Para ver una consulta del equipo o abrir un libro, debe estar asignado o pertenecer a un grupo que tenga asignados los permisos Lectura en la carpeta de consulta de equipo para el proyecto de equipo. Para modificar una consulta, debe tener asignados (o pertenecer a un grupo que tenga asignados) los permisos Contribuir o Control total para la consulta de equipo. Para obtener más información, vea Organizar y establecer los permisos en las consultas de elementos de trabajo.
Para crear o modificar los casos de usuario o tareas, debe ser miembro del grupo Contributors o tener los permisos Ver los elementos de trabajo en este nodo o Editar elementos de trabajo en este nodo establecidos en Permitir. Para obtener más información, consulte Permisos de Team Foundation Server.
64
Administrar el trabajo pendiente de iteración
Puede usar el libro Trabajo pendiente de iteración para determinar la capacidad del equipo y estimar la evolución para una iteración. Este libro proporciona cinco hojas de cálculo, como se muestra en la ilustración siguiente.
Las hojas de cálculo se usan de las formas siguientes:
Trabajo pendiente de iteración: comprueba que todas las tareas están asignadas a casos de usuario. Revise los niveles de esfuerzo y asigne uno a cada tarea. Asigne las tareas a las iteraciones.
La hoja de cálculo Trabajo pendiente de iteración hace referencia a la consulta de equipo Trabajo pendiente de iteración, que está configurada para mostrar todos los casos de usuario y las tareas vinculadas definidos para el proyecto de equipo.
65
Importante
Si ha agregado tareas pero no las ha vinculado a un caso de usuario con el tipo de vínculo
secundario, no aparecerán en el trabajo pendiente de iteración.
Dentro del libro, puede filtrar los casos de usuario basándose en el área de producto. Además, puede realizar cualquiera de las acciones siguientes:
Agregar casos de usuario y tareas al trabajo pendiente.
Configuración: programe la iteración y establezca el área y los filtros para la iteración.
Interrupciones: especifique días no laborables u otras fechas cuando no vayan a realizar ningún trabajo el equipo ni los miembros individuales del equipo.
66
Capacidad: equilibre la carga de trabajo del equipo.
67
Evolución: estime cuándo finalizará la iteración, basándose en las fechas de inicio para la iteración.
Crear libros específicos de la iteración
Después de definir las iteraciones para una versión del producto, puede crear libros específicos de la iteración. Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
Para crear los libros específicos de la iteración, realice las acciones siguientes:
Cree una consulta específica de la iteración. Guarde una copia del libro Trabajo pendiente de iteración. Configure la hoja de cálculo Trabajo pendiente de iteración para actualizar los datos a partir de la
consulta específica de la iteración. Personalice las hojas de cálculo restantes en el libro tal como se describe en “Planear una
iteración” más adelante en este tema.
Para crear una consulta específica de la iteración
1. Abra Team Explorer y expanda el nodo del proyecto de equipo.
68
2. Expanda sucesivamente el nodo Elementos de trabajo, Consultas del equipo y Consultas del libro.
3. Haga clic con el botón secundario en Trabajo pendiente de iteración y, a continuación, haga clic
en Copiar.
4. Haga clic con el botón secundario en Consultas del libro y, a continuación, haga clic en Pegar. 5. En el cuadro de diálogo Especificar nuevo nombre de elemento de consulta, escriba o
modifique el nombre de la consulta de forma que corresponda al nombre de la iteración que está definiendo y, a continuación, haga clic en Aceptar.
6. Haga clic con el botón secundario en la consulta que acaba de crear y a la que ha asignado un
nombre, y después haga clic en Editar consulta.
Se abre el Editor de consultas en una pestaña nueva.
7. Haga clic en Haga clic aquí para agregar una nueva cláusula y, a continuación, haga clic en Y. 8. En la lista Campo, haga clic en Ruta de acceso de la iteración. 9. En la lista Operador, haga clic en Inferior a. 10. En la lista Valor, haga clic en la iteración que desee usar.
11. Haga clic en Ejecutar consulta.
Compruebe que los resultados coinciden con sus expectativas.
12. Haga clic en Guardar consulta.
Para guardar una copia del libro Trabajo pendiente de iteración
1. Abra Team Explorer y expanda el nodo del proyecto de equipo. 2. Expanda sucesivamente el nodo Documentos, Documentos compartidos e Iteración 1.
3. Haga clic con el botón secundario en Iteration 1 Backlog.xlsm y, a continuación, haga clic en Copiar.
4. Haga clic con el botón secundario en la carpeta en la que desee copiar el libro y, a continuación,
haga clic en Pegar.
Nota
Puede arrastrar el libro hacia cualquier carpeta bajo el nodo Documentos compartidos.
5. Haga clic con el botón secundario en el libro copiado y, a continuación, haga clic en Cambiar nombre.
6. Escriba el nombre del libro específico de la iteración y, a continuación, presione ENTRAR.
Para configurar la hoja de cálculo Trabajo pendiente de iteración para actualizar los datos a
partir de la consulta específica de la iteración
1. Abra Team Explorer y expanda el nodo del proyecto de equipo.
69
2. Haga clic con el botón secundario en el libro de específico de la iteración que desee configurar y,
a continuación, haga clic en Abrir. 3. En el cuadro de diálogo Descarga de archivos, haga clic en Aceptar.
El libro se abre en Office Excel. Las macros se deshabilitan automáticamente. En la parte superior del libro, aparecen los avisos de la siguiente ilustración.
4. Haga clic en Opciones. 5. En el cuadro de diálogo Opciones de seguridad de Microsoft Office, en Macros, haga clic en
Habilitar este contenido y, a continuación, haga clic en Aceptar. 6. Haga clic en Editar libro. 7. En la pestaña Equipo en Office Excel, en el grupo Elementos de trabajo, haga clic en Configurar
y en Lista y, a continuación, haga clic en los puntos suspensivos (…). 8. En la lista Actualizar desde consulta, busque la consulta específica de la iteración que creó
anteriormente, haga clic en esa consulta y, a continuación, haga clic en Aplicar.
La hoja de cálculo se actualizará para hacer una lista de los elementos de trabajo encontrados por la consulta específica de la iteración que seleccionó. Este proceso puede tardar unos minutos.
9. Revise la hoja de cálculo para asegurarse de que los casos de usuario y tareas mostrados cumplen sus expectativas.
10. Haga clic en .
El libro se guarda en el sitio de portal del proyecto de equipo.
Estimar y asignar el esfuerzo de la tarea
El libro Trabajo pendiente de iteración contiene el conjunto de casos de usuario y las tareas asociadas que el equipo piensa implementar para una iteración concreta. El equipo estima el nivel de esfuerzo que requerirá cada tarea. Cada miembro del equipo se inscribe para las tareas con las que puede comprometerse, en función de su conjunto de conocimientos y carga de trabajo. Para obtener más información, vea en esta guía “Reunión de planeamiento de plazos”.
Para estimar el esfuerzo de la tarea y asignar las tareas
1. En el libro Trabajo pendiente de iteración, haga clic en la hoja de cálculo Trabajo pendiente de iteración.
2. Si ha abierto un libro que ha guardado en el equipo local, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en Actualizar.
70
Este paso ayuda a asegurarse de que la lista de casos de usuario y tareas contiene la información más actual.
3. (Opcional) Para filtrar la lista de artículos basándose en el área de producto, haga clic en la flecha abajo situada al lado de Área y, a continuación, haga clic en la casilla situada al lado de cada área de producto que desee incluir.
4. Revise las tareas asignadas a cada caso de usuario y defina las tareas adicionales si es necesario.
Para obtener más información, vea “Agregar casos de usuario y tareas al trabajo pendiente” más adelante en este tema.
5. En cada tarea, compruebe que Trabajo restante y Trabajo completado contienen los valores.
Nota
Utilice las características de edición de Excel para cambiar los valores de varias celdas. Para
obtener más información sobre cómo modificar las celdas en una hoja de cálculo, consulte los
temas sobre cómo escribir y modificar los datos en la Ayuda de Office Excel.
6. Actualice los siguientes campos para cada tarea según sea necesario:
Nombre del campo Descripción
Actividad Tipo de actividad necesaria para realizar una tarea.
Trabajo restante El número de horas de trabajo que se debe gastar para completar
una tarea.
Trabajo completado El número de horas de trabajo ya se pasadas para completar una
tarea.
Asignado a Nombre del miembro del equipo que se compromete a completar la
tarea.
Importante: Si se divide una tarea en subtareas, especifique las horas solamente para las
subtareas. En los informes de Team Foundation, las horas que defina para la subtarea se
acumularán como valores resumen para la tarea primaria y el caso de usuario. Si asigna horas
en ambos lugares, se contarán dos veces en los informes que realicen el seguimiento de las
horas. Para obtener información sobre cómo corregir esta situación, vea en esta guía
“Imprecisiones de dirección publicadas para valores de resumen”.
71
7. En la ficha Equipo, en el grupo Elementos de trabajo, haga clic en Publicar.
Nota
Puede usar la característica de reversión de un comando en Excel para deshacer los cambios
recientes que realizó en los elementos de trabajo antes de publicar los cambios.
8. Para obtener más información, vea en esta guía “Publicar elementos de trabajo en Office Excel”.
9. Haga clic en .
Planear una iteración
Antes de planear una iteración, quizá desee revisar el trabajo pendiente del producto y asegurarse de que la iteración que está asignada a cada caso de usuario satisface sus expectativas de planeación. Para obtener más información, vea el “Libro Planeación del producto” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Al planear una iteración, debe realizar los pasos siguientes de forma iterativa hasta que el plan cumpla los objetivos y la capacidad de su equipo:
Programar la iteración.
Tener en cuenta las vacaciones y las interrupciones planeadas.
Determinar la capacidad del equipo.
Visualizar la evolución.
Programar la iteración
Para programar la iteración, especifique los filtros aplicables a la iteración y defina la fecha de inicio y fin para la iteración. Este paso proporciona los datos necesarios para calcular la capacidad del equipo y la evolución.
Para programar la iteración
1. En el libro Trabajo pendiente de iteración, haga clic en la hoja de cálculo Configuración.
2. (Opcional) Haga clic en la flecha abajo en la celda situada al lado de Área y, a continuación, haga clic en el área de producto que desee incluir.
3. Haga clic en la flecha abajo en la celda situada al lado de Iteración y, a continuación, haga clic en la iteración que desee incluir.
4. Haga clic en la celda situada al lado de Fecha de inicio y escriba la fecha del calendario para el inicio de la iteración.
El formato de la fecha debe ser mes/día/año (por ejemplo, 8/2/2009).
72
5. Haga clic en la celda situada al lado de Fecha de finalización y escriba la fecha del calendario para la finalización de la iteración.
Tener en cuenta las vacaciones y las interrupciones planeadas
Puede usar la hoja de cálculo Interrupciones para especificar los días en que no se realizará ningún trabajo, ya sea por parte del equipo o de un miembro del equipo. El número de días calculados para la iteración se actualiza en la hoja de cálculo Configuración para reflejar estas interrupciones.
Para tener en cuenta las interrupciones del trabajo planeadas o por vacaciones
1. En el libro Trabajo pendiente de iteración, haga clic en la hoja de cálculo Interrupciones. 2. En Interrupciones planeadas, para cada miembro del equipo que ha planeado días de
vacaciones o días de interrupción del trabajo, siga estos pasos: a. Haga clic en una celda en la columna Miembro del equipo y, a continuación, haga clic en
el nombre del miembro del equipo. b. Rellene los campos Descripción, Fecha de inicio y Fecha de finalización.
El formato de la fecha debe ser mes/día/año (por ejemplo, 8/2/2009).
c. Agregue una fila para cada período no laborable.
3. En Vacaciones, siga estos pasos: a. Rellene los campos Descripción, Fecha de inicio y Fecha de finalización.
El formato de la fecha debe ser mes/día/año (por ejemplo, 8/2/2009).
b. Agregue una fila para cada período no laborable.
Agregue a la hoja de cálculo las fechas correspondientes a la iteración planeada.
Determinar la capacidad del equipo y el trabajo de equilibrio de carga
Antes de equilibrar la carga de trabajo entre los miembros del equipo, asegúrese de que se han completado los siguientes pasos:
Un valor se ha definido para el Trabajo restante y Trabajo completado para cada tarea. La Ruta de acceso de la iteración se asigna a todas las tareas que el equipo piensa completar para
la iteración actual que el equipo está planeando. El tiempo no laborable para el equipo y cada miembro del equipo se especifica en la hoja de
cálculo Interrupciones.
Para determinar la capacidad del equipo y equilibrar la carga de trabajo del equipo
1. En el libro Trabajo pendiente de iteración, haga clic en la hoja de cálculo Capacidad. 2. En Capacidad individual, agregue cada miembro del equipo a la lista y especifique las horas
esperadas que cada miembro del equipo trabajará en el proyecto cada día.
73
Los siguientes campos deberían actualizarse automáticamente con información específica de cada miembro del equipo:
Columna Descripción
Días Número de días laborables durante la iteración.
Capacidad Número total de horas de trabajo dejadas para la iteración. Este valor se calcula en
función de la longitud de la iteración definida en la hoja de cálculo Configuración,
la fecha actual (que indica cuántos días quedan en la iteración) y las horas por día
especificadas para el miembro del equipo.
Importante
No se puede planear trabajo en el pasado. Las celdas en la columna Capacidad
hacen referencia a las fechas en la hoja de cálculo Configuración y la fecha actual
al calcular la capacidad.
Asignado Número total de horas asignadas para la iteración. Este número es un paquete
acumulativo de actualizaciones de todas las horas de Trabajo restante que están
asignadas a las tareas.
Utilizado Número total de horas asignadas de la capacidad del miembro del equipo. Este
número es una rotación en torno al eje z a de todas las horas de Trabajo restante
de tareas que están asignadas a ese miembro del equipo, pero el número no
puede superar la capacidad del miembro del equipo.
Superior a Número de horas sobreasignadas al miembro del equipo. Este número se calcula
restando Capacidad de las horas de Asignado.
Pertenece
a
Número de horas que el miembro del equipo tiene que trabajar en el proyecto
pero no se usan. Este número se calcula restando Utilizado de las horas de
Capacidad.
3. Revise el gráfico Capacidad del equipo y determine si el equipo está sobreutilizado o infrautilizado. El gráfico ideal mostrará cerca del 100% Utilizado, sin ninguna barra roja en la utilización Superior a y con una barra de verde pequeña en la utilización Inferior a. Para obtener un ejemplo, vea la ilustración siguiente:
74
Para corregir la sobreutilización o infrautilización, realice una de las acciones siguientes:
Si el equipo está sobreutilizado, haga clic en la hoja de cálculo Trabajo pendiente de iteración y reasigne algunas tareas a una iteración posterior.
Si el equipo está infrautilizado, abra el libro Trabajo pendiente del producto y reasigne algunos casos de usuario y tareas a la iteración que está planeando. Actualice la hoja de cálculo Trabajo pendiente de iteración para mostrar las tareas asignadas recientemente.
Realice estos ajustes antes de equilibrar la carga de trabajo entre los miembros del equipo.
4. Revise el gráfico Capacidad individual e identifique a los miembros del equipo a quienes se han asignado demasiadas tareas o muy pocas.
Como muestra la ilustración siguiente, se han asignado demasiadas tareas a un miembro del equipo y muy pocas a tres miembros del equipo.
5. Haga clic en la hoja de cálculo Trabajo pendiente de iteración y realice las acciones siguientes:
75
Determine cómo reasignar el trabajo para usar los recursos eficazmente, sin tareas de más o de menos.
Discuta con el equipo qué tareas es más adecuado reasignar. Cambie la asignación para las tareas que se van a reasignar. Repita este paso hasta que
ningún miembro del equipo tenga demasiadas tareas ni muy pocas.
La ilustración siguiente muestra cómo se ha equilibrado la carga de trabajo entre los cuatro miembros del equipo.
6. Guarde el libro.
Visualizar la evolución
Los datos que aparecen en la hoja Evolución se derivan del almacenamiento de datos.
Nota
La hoja Evolución requiere que la colección de proyectos de equipo donde está almacenado su
proyecto de equipo se haya aprovisionado con SQL Server Analysis Services.
Para visualizar la evolución para la iteración
1. En el libro Trabajo pendiente de iteración, haga clic en la hoja de cálculo Evolución. 2. Haga clic en la celda situada al lado de Fecha de inicio de la tendencia y escriba la fecha en que
desea iniciar la iteración con el formato mes/día/año (por ejemplo, 8/2/2009). 3. Haga clic en Actualizar ahora.
76
El gráfico se actualiza con los datos almacenados en el almacenamiento de datos.
Nota
Podría experimentar un retraso entre el momento en que actualizó los campos de esfuerzo
para las tareas y el momento en que esos datos están disponibles en el almacenamiento de
datos.
La línea Tendencia ideal calcula una pendiente o trayectoria para la fecha en que se completará el trabajo, basada en la fecha de inicio de la tendencia, la cantidad de trabajo restante y la fecha de fin para la iteración.
4. (Opcional) Para visualizar la evolución basada en diferentes fechas de inicio de la tendencia, puede activar la casilla Actualización automática del gráfico.
El gráfico se actualizará cada vez que cambie Fecha de inicio de la tendencia.
Seguimiento del progreso de la iteración
Una vez que la iteración está en proceso, puede usar el libro Trabajo pendiente de iteración con el fin de determinar si el equipo va por el buen camino para completar el trabajo. Para seguir el progreso, cada miembro del equipo debe actualizar el Trabajo completado y el Trabajo restante para cada tarea.
Nota
Además de la hoja Evolución, puede ver la tasa de progreso del equipo y determinar la tasa de
avance del equipo en el informe Evolución y tasa de avance. Para obtener más información, vea en
esta guía “Informe de evolución y tasa de avance” en la guía “Informes y Libros Agile” en
http://www.alightm.com.
77
Para seguir el progreso de la iteración
1. Abra el libro Trabajo pendiente de iteración y, a continuación, haga clic en la hoja Evolución. 2. Haga clic en Actualizar ahora. 3. Revise la tasa de trabajo que el equipo está completando y el trabajo que queda todavía. La
línea Tendencia ideal debería estar sobre el área azul, que indica que el trabajo está progresando como se esperaba. La ilustración siguiente muestra un gráfico de evolución saludable:
78
Agregar casos de usuario y tareas al trabajo
pendiente de iteración
Para crear casos de usuario y tareas, agréguelos al libro Trabajo pendiente de iteración y publique el libro en la base de datos para el seguimiento de los elementos de trabajo. Para obtener más información sobre cómo modificar los elementos de trabajo mediante Office Excel, vea Realizar la planeación descendente mediante una lista de árbol de elementos de trabajo (en Excel).
Para agregar casos de usuario y tareas al trabajo pendiente de iteración
1. En Office Excel, abra su libro específico de la iteración. 2. Si se ha abierto un libro guardado, en la pestaña Equipo, en el grupo Elementos de trabajo,
haga clic en Actualizar.
Este paso ayuda a asegurarse de que la lista de casos de usuario y tareas contiene la información más actual.
3. Para cada caso de usuario que desee agregar, haga clic en la fila en la parte inferior de la lista y especifique la siguiente información para cada uno:
En la lista Tipo de elemento de trabajo, haga clic en Caso de usuario.
Nota
Debe especificar el tipo de elemento de trabajo que desea agregar antes de poder
publicarlo.
En Título, escriba texto que identifique al cliente tan específicamente como sea posible y describa el objetivo del cliente en un nivel alto.
En Iteración, haga clic en la iteración establecida para este libro.
Haga clic en una iteración diferente si el trabajo se va a realizar en otra iteración.
4. Para cada tarea que desee agregar, inserte una fila después del caso de usuario y especifique la siguiente información:
En la lista Tipo de elemento de trabajo, haga clic en Tarea. En Título 2, escriba una entrada que identifique al cliente tan específicamente como sea
posible y describa el objetivo del cliente en un nivel alto.
79
Nota
Asegúrese de escribir el título de la tarea en la columna Título 2.Este paso crea un
vínculo entre el caso de usuario y la tarea cuando se publica el libro.
En Iteración, haga clic en la iteración establecida para este libro.
Haga clic en una iteración diferente si el trabajo se va a realizar en otra iteración.
5. (Opcional) Especifique la información para los siguientes campos de tarea:
Nombre del campo Descripción
Actividad Tipo de actividad necesaria para realizar una tarea.
Estimación original Número de horas necesarias para completar una tarea.
Restante Número de horas que quedan para finalizar la tarea.
Completado Número de horas que ya se han empleado en trabajar en una
tarea.
Nota
Utilice las características de edición de Excel para cambiar los valores de varias celdas. Para
obtener más información acerca de cómo modificar las celdas en una hoja de cálculo, vea los
temas sobre cómo especificar y editar los datos en la Ayuda de Microsoft Excel.
6. (Opcional) Agregue información a los campos restantes según corresponda.
Para obtener más información sobre cada campo, vea en esta guía Caso de usuario o Tarea.
7. (Opcional) Para mostrar los campos adicionales de Team Foundation en la lista, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en Elegir columnas.
Para obtener más información, vea Agregar o quitar columnas de una lista de elementos de trabajo.
8. (Opcional) Guarde el libro.
Más adelante puede abrir la copia local del libro, actualizar la lista y realizar cambios adicionales. No necesita abrir el libro desde Team Explorer cada vez.
80
9. En la ficha Equipo, en el grupo Elementos de trabajo, haga clic en Publicar.
Para obtener más información, vea Publicar elementos de trabajo en Office Excel.
Recursos adicionales para administrar el trabajo
pendiente de iteración
Para obtener más información sobre cómo modificar los casos de usuario y tareas mediante Microsoft Excel, vea los temas siguientes:
Realizar la planeación descendente mediante una lista de árbol de elementos de trabajo (en Excel)
Crear, abrir y modificar elementos de trabajo mediante Office Excel Agregar o quitar columnas de una lista de elementos de trabajo Publicar elementos de trabajo en Office Excel Conectar documentos de Microsoft Office con Team Foundation Server
81
Asociar elementos de trabajo a un conjunto de
cambios
Durante el proceso de protección, puede asociar elementos de trabajo a un conjunto de cambios.
Permisos necesarios
Para realizar este procedimiento, el permiso Proteger o Desproteger debe estar establecido en Permitir. Para obtener más información, consulte Permisos de Team Foundation Server.
Para asociar elementos de trabajo a un conjunto de cambios
1. En la ventana Cambios pendientes o en el cuadro de diálogo Proteger, haga clic en el canal Elementos de trabajo. Para obtener más información sobre cómo proteger los cambios pendientes, vea Proteger los cambios pendientes.
2. En la lista Elemento de trabajo, desplácese hasta los elementos de trabajo que desea asociar a la operación de protección y seleccione las opciones correspondientes.
Nota
Antes de que aparezca la lista de elementos de trabajo, debe seleccionar una consulta en la
lista Consulta. La primera vez que se utiliza el canal la consulta predeterminada que se ejecuta
es Mis elementos de trabajo. Puede seleccionar una consulta diferente si así lo requiere.
3. En la columna Acción de protección, en la lista desplegable, indique la acción que desea asociar al elemento de trabajo. Haga clic en Asociar para asociar el elemento de trabajo a la operación de protección o en Resolver para asociar y resolver el elemento de trabajo.
Nota
Dependiendo del estado del elemento de trabajo, la opción de resolución puede no estar
disponible. Por ejemplo, si una consulta muestra errores cerrados, asociaría el elemento de
trabajo, pero no lo resolvería.
82
Elemento del Product Backlog
Definiendo y administrando los elementos del Product Backlog, el equipo puede capturar los requisitos del producto. El propietario del producto define, da prioridad y mantiene sus elementos de trabajo pendiente. El equipo estima el esfuerzo, el valor comercial y la prioridad para cada elemento del Product Backlog pendiente y entrega los elementos de prioridad máxima en cada carrera corta.
Permisos necesarios
Para ver un elemento del Product Backlog, debe ser un miembro del Lectores grupo o sus elementos de trabajo de Ver en este nodo debe estar establecido en Permitir. Crear o modificar un elemento de trabajo pendiente de producto, debe ser un miembro del grupo Contribuyentes o sus permisos Editar elementos de trabajo en este nodo debe estar establecido en Permitir.
Definir un elemento del Product Backlog
Cuando su propietario del producto define un elemento del Product Backlog, él o ella se deberían enfocar el valor del cliente y evitar las descripciones de cómo su equipo desarrolla una característica. El propietario del producto puede dar prioridad al Product Backlog basado en el valor de negocio de cada elemento, esfuerzo y la dependencia relativa en otros elementos del Product Backlog. El Product Backlog evolucionará rápidamente si los requisitos comerciales de su proyecto y otras condiciones del equipo no cambian constantemente. Su equipo sólo puede especificar los detalles para los elementos de prioridad máxima, minimizando el trabajo redundante.
83
El formulario de elemento de trabajo para un elemento de trabajo pendiente contiene los campos y pestañas en la siguiente ilustración:
Al crear un elemento de trabajo pendiente de producto, debe especificar el Título. Puede dejar todo el otro espacio en blanco de campos o acepta sus valores predeterminados y actualizarlos posterior.
Para definir un elemento de trabajo pendiente de producto
1. En la sección superior del formulario de elemento de trabajo, proporcione la siguiente información:
En Title (campo obligatorio), escriba una descripción breve. En Iteration, especifique la ruta de acceso de la iteración del elemento.
Puede especificar la ruta de acceso de iteración de raíz para iniciarse y a continuación, pasar el elemento a una carrera corta durante una carrera corta planee la reunión.
En la lista del Assigned To, haga clic en el nombre del miembro del equipo que posee el elemento.
84
Nota
Sólo los miembros del grupo Contribuyentes pueden poseer un elemento de trabajo.
En la lista State, deje el valor predeterminado, New.
Para obtener más información sobre el campo State y cómo lo utiliza para realizar el seguimiento del flujo de trabajo, vea “Cambiar el Estado de un elemento Trabajo pendiente del producto” posterior en este tema.
En la lista Reason, deje el valor predeterminado, New backlog item. En Effort, escriba un número que indica la calificación relativa para la cantidad de trabajo
que el elemento exigirá implementar.
Un número mayor indica más trabajo.
En Business Value, escriba un número que indica el valor de negocio relativo del elemento.
En Backlog Priority, escriba un número que indica la prioridad relativa del elemento.
Un número mayor indica una menor prioridad. El valor predeterminado de este campo es 1000, que colocan el elemento en la parte inferior de su trabajo pendiente.
Nota
Para determinar la prioridad de un elemento de trabajo pendiente, puede calcular el
retorno en la inversión (ROI) que espera. Para calcular este valor, divida el valor
comercial por el esfuerzo.
En la lista Area, especifique la ruta de acceso del área adecuada.
Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
2. En la sección más abajo del formulario de elemento de trabajo, proporcione la siguiente información:
En la ficha Description, proporcione los detalles sobre el elemento de trabajo pendiente de producto.
En la ficha Acceptance Criteria, describa los criterios que utiliza para comprobar si su equipo ha cumplido los requisitos del elemento.
85
En la ficha History, agregue comentarios que desea capturar como parte del registro histórico.
Cada vez que un miembro del equipo actualiza el elemento de trabajo, en su historial se muestra la fecha del cambio, el miembro del equipo que lo realizó y los campos que han cambiado.
En la ficha Attachments, adjunte archivos que proporcionan más detalles sobre el elemento.
Por ejemplo, puede adjuntar un subproceso del correo electrónico, un documento, una imagen o un archivo de registro.
3. Vincule el elemento de trabajo pendiente de producto a otros elementos de trabajo realizando las siguientes tareas:
En la ficha Test Cases, cree los vínculos a partir del elemento a los casos de prueba.
Para obtener más información, vea “Agregar y vincular Casos de Pruebas a elementos del Product Backlog” más adelante en este tema.
En la ficha Tasks, cree los vínculos a partir del elemento a las tareas.
Para obtener más información, vea “Agregar y vincular Tareas a elementos del Product Backlog” más adelante en este tema.
En la ficha Links, cree los vínculos a partir del elemento a otros elementos de trabajo pendiente o a otros tipos de elementos de trabajo, como impedimentos. También puede agregar un hipervínculo a un sitio web o a un archivo que está almacenado en un servidor o un sitio web.
Para obtener más información, vea Agregar otros tipos de Elementos de Trabajo a un elemento del Product Backlog más adelante en este tema.
4. Haga clic en Save Work Item.
Después de guardar el elemento, el identificador aparece en el título en la barra de herramientas de elemento de trabajo.
Agregar y vincular Tareas a un elemento Trabajo
pendiente del producto
Vincula los elementos de trabajo de la tarea a un elemento de trabajo pendiente de producto para realizar el seguimiento del progreso de trabajo que se ha producido para completar el elemento de trabajo pendiente.
86
Para crear una tarea que se vincula a un elemento de trabajo pendiente de producto
1. En la ficha Tasks, haga clic New.
Se abrirá el cuadro de diálogo Add new Linked Work Item to Product Backlog.
2. En la lista Link Type, deje la opción predeterminada, Child. 3. En la lista Work Item Type, haga clic en Task. 4. En Title, escriba un nombre que identifica el área de trabajo que se realizará tan
específicamente como posible. 5. (Opcional) Escriba información adicional en Comment. 6. Haga clic en OK.
Un formulario de elemento de trabajo para una tarea se abre y muestra la información que ha proporcionado.
7. Especifique los campos que permanecen y, a continuación, haga clic en Save Work Item.
Para obtener más información sobre los campos en el formulario para un elemento de trabajo de la tarea, vea en esta guía “Tarea”.
87
Para vincular las tareas existentes a un elemento de trabajo pendiente de producto
1. En la ficha Tasks, haga clic en Link To.
Se abre el cuadro de diálogo Add Link to Product Backlog Item.
2. En la lista Link Type, deje la opción predeterminada, Child. 3. Haga clic en Browse.
88
Aparece el cuadro de diálogo Choose linked work items.
4. Para especificar las tareas a las que desea vincular el elemento de trabajo pendiente, realice una de las siguientes tareas:
Ejecute una consulta para buscar las tareas a las que desea vincular. Escriba los identificadores de las tareas a las que desea vincular. Escriba algún texto en los títulos de los elementos de destino y, a continuación, haga clic
en Task como el tipo de elemento de trabajo.
Activar la casilla al lado de cada tarea que desea vincular al elemento de trabajo pendiente y, a continuación, haga clic en OK.
El cuadro de diálogo Choose linked work items desaparece.
Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o importar”.
5. (Opcional) Escriba una descripción de las tareas a las que está vinculando en el Add new Linked Work Item dialog box.
6. Haga clic en OK y, a continuación, en Save work ítem.
El elemento de trabajo pendiente y las tareas a las que lo vinculó están actualizados. Un vínculo primario al elemento de trabajo pendiente se crea para cada tarea que agregó.
89
Agregar y vincular Casos de prueba a un elemento
Trabajo pendiente del producto
Como parte de planear, crear los casos de prueba y vincular los elementos de Product Backlog, el cliente recomendado para crear conjuntos de pruebas y casos de prueba es Microsoft Test Manager. De este cliente, puede vincular también a un elemento de trabajo pendiente, tal y como se describe en Cómo: Ver los requisitos o casos de usuario mediante el Administrador de pruebas de Microsoft.
Para agregar un nuevo caso de prueba a un elemento de trabajo pendiente de producto
1. En la pestaña Casos de prueba, haga clic en Nuevo.
Se abrirá el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, deje la opción predeterminada, Prueba realizada por. 3. En la lista Tipo de elemento de trabajo, deje la opción predeterminada, Caso de prueba. 4. En Título, escriba un nombre descriptivo que define el área que se probará. 5. (Opcional) Escriba información adicional en Comentario. 6. Haga clic en Aceptar.
Un formulario de elemento de trabajo para un caso de prueba se abre y muestra la información que ha proporcionado.
7. Especifique los campos restantes y, a continuación, haga clic en Guardar elemento de trabajo.
Para obtener más información sobre los campos en el formulario para un caso de prueba, vea en esta guía “Casos de Prueba”.
Para agregar los casos de prueba existentes a un elemento de trabajo pendiente de producto
1. En la pestaña Casos de prueba, haga clic en Vincular a.
Se abre el cuadro de diálogo Agregar Vincular a producto trabajo pendiente elemento.
2. En la lista Tipo de vínculo, deje la opción predeterminada, Prueba realizada por. 3. En Identificadores de elementos de trabajo, escriba los identificadores de los casos de prueba a
los que desea vincular o búsquelos.
Puede ejecutar una consulta guardada para buscar los casos de prueba que desea agregar y, a continuación, activa la casilla al lado de cada caso de prueba al que desea vincular. Para obtener
más información, vea en esta guía “Buscar elementos de trabajo para vincular o importar”.
4. (Opcional) Escriba una descripción de los casos de prueba a los que está estableciendo vínculos.
5. Haga clic en Aceptar y, a continuación, en Guardar elemento de trabajo.
90
El elemento de trabajo pendiente y los casos de prueba a los que lo vinculó están actualizados. Un vínculo Pruebas al elemento de trabajo pendiente se crea para cada caso de prueba que agregó.
Agregar otros tipos de Work Items a un elemento del
Product Backlog
Puede agregar cualquier tipo de elemento de trabajo a un elemento de trabajo pendiente de producto en la ficha Vínculos. Por ejemplo, puede realizar el seguimiento mejor de la calidad y realización del elemento de trabajo pendiente si define un elemento de trabajo del impedimento y lo vincula al elemento de trabajo pendiente.
Crear un impedimento y vincularlo a un elemento de trabajo pendiente de producto
1. En la ficha Vínculos, haga clic Nuevo.
Se abrirá el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, haga clic en Relacionado. 3. En la lista Tipo de elemento de trabajo, haga clic en Impedimento. 4. En Título, escriba un nombre que describe el problema del agrupamiento en bloques tan
específicamente como posible. 5. (Opcional) Escriba información adicional en Comentario. 6. Haga clic en Aceptar.
Un formulario de elemento de trabajo para un impedimento se abre y muestra la información que ha proporcionado.
7. Defina los campos restantes y, a continuación, haga clic en Guardar elemento de trabajo.
Para obtener más información sobre los campos sobre el formulario para un elemento de trabajo del impedimento, vea en esta guía “Impedimento”.
91
Cambiar el Estado de un elemento Trabajo pendiente
del producto
Un equipo puede realizar el seguimiento del progreso de un elemento de trabajo pendiente de producto estableciendo su campo State en uno de los siguientes valores: New, Approved, Removed, Committed o Finished. El siguiente diagrama muestra ambos diagramas: una progresión típica y una progresión del flujo de trabajo atípica de un elemento de trabajo pendiente.
Diagrama para un elemento Trabajo pendiente del
producto
Progresión habitual del flujo de trabajo:
Cree un elemento de trabajo
pendiente de producto en el
estado predeterminado, New.
Cambie el estado de New a
Approved.
Cambie el estado en Approved a
Commited.
Cambie el estado en Commited a
Finished.
Transiciones atípicas:
Cambie el estado de New a
Removed.
Cambie el estado en Removed a
New.
Cambie el estado en Approved a
Removed.
Cambie el estado en Committed a
Approved.
Cambie el estado en Finished a
Commited.
Los cambios Estatales Cuándo utilizarlo
92
De New a Approved Cuando el propietario del producto
aprueba el elemento para el trabajo
pendiente del producto.
De New a Removed Cuando el propietario del producto
decide que el equipo no necesita
implementar el elemento de trabajo
pendiente.
De Approved a Committed Cuando el equipo ha confirmado a
implementar el elemento de trabajo
pendiente en la carrera corta actual.
De Approved a Removed Cuando el equipo no implementará el
elemento de trabajo pendiente porque
requisitos de producto u otras
condiciones de trabajo han cambiado.
De Removed a New Cuando el equipo revisa el elemento de
trabajo pendiente.
De Committed a Finished Cuando el equipo ha completado el
elemento de trabajo pendiente y ha
cumplido sus criterios de aceptación.
De Finished a Committed Cuando el equipo ha encontrado trabajo
adicional que el elemento de trabajo
pendiente exige haber finalizado.
De Committed a Approved Cuando el trabajo para el elemento de
trabajo pendiente se ha detenido debido
a cambios del personal o ajuste de la
prioridad.
93
Caso de usuario
En este tema se proporciona información sobre cómo rellenar los detalles de un elemento de trabajo de un caso de usuario. Para obtener información sobre qué son los casos de usuario y cómo se utilizan en procesos ágiles, vea “Crear un trabajo pendiente de producto grande”. Para obtener información sobre cómo se crea un elemento de trabajo para un caso de usuario, vea “Elementos de trabajo y flujo de trabajo”.
Permisos necesarios
Para ver un caso de usuario, debe ser miembro del grupo Readers o tener el permiso Ver los elementos
de trabajo en este nodo establecido en Permitir. Para crear o modificar un caso de usuario, debe ser
miembro del grupo Contributors o tener el permiso Editar elementos de trabajo en este nodo
establecido en Permitir. Para obtener más información, vea Administrar permisos.
Definir un caso de usuario
Un caso de usuario comunica funcionalidad valiosa para el usuario final del producto o sistema. Cada
caso de usuario debe exponer simplemente lo que un usuario desea realizar con una característica del
software y describirlo desde su perspectiva. Cuando se escriben casos de usuario, conviene centrarse en
lo siguiente: para quién es la característica, qué se desea conseguir con los casos en cuestión y por qué.
Deben evitarse descripciones que especifiquen cómo se ha de desarrollar la característica.
El formulario de elemento de trabajo para un caso de usuario almacena los datos en los campos y
pestañas que muestra la ilustración siguiente:
94
Cuando se define un caso de usuario, se debe definir el Título en la sección superior del formulario de elemento de trabajo. Puede dejar todos los demás campos en blanco o aceptar sus valores predeterminados.
Para definir un caso de usuario
1. En la sección superior del formulario de elemento de trabajo para el caso de usuario, especifique uno o varios de los siguientes tipos de información:
En Título (Requerido), escriba una descripción breve.
Un buen título del caso debe reflejar información valiosa para el cliente o la funcionalidad que se necesita implementar.
95
En la lista Asignado a, haga clic en el nombre del miembro del equipo propietario del caso de usuario.
Nota
Solamente puede asignar elementos de trabajo a los miembros del grupo
Contributors.
Si deja el caso sin asignar, se le asignará automáticamente. En el cuadro Rango, escriba un número que indique la importancia relativa del caso
comparada con la de los demás casos existentes en el trabajo pendiente del producto. En el cuadro Puntos de caso, escriba un número que especifique una valoración subjetiva
de la cantidad de trabajo que se necesitará para completar un caso de usuario.
Se necesitará más trabajo cuantos más puntos especifique.
En la lista Prioridad, haga clic en el nivel de importancia para el caso de usuario en una escala de 1 (más importante) a 4 (menos importante).
En las listas Área e Iteración, haga clic en la iteración y área adecuadas o deje estos campos en blanco para asignarlos después durante una reunión de planeación.
Nota
El administrador de cada proyecto de equipo define las rutas de acceso de área y de
iteración para dicho proyecto, de forma que el equipo pueda seguir el progreso
mediante dichas designaciones. Para obtener más información, vea en esta guía “Crear
y modificar áreas e iteraciones”.
2. En la pestaña Detalles, especifique uno o varios de los siguientes tipos de información:
En el cuadro Descripción con criterios de aceptación, proporcione una descripción lo más detallada posible, no solo del caso de usuario sino también de los criterios que utilizará para comprobar si se ha realizado.
El equipo utilizará esta información para crear elementos de trabajo para las tareas y los casos de prueba. Para obtener más información, vea en esta guía Tarea y Caso de prueba.
En el cuadro Historial, agregue los comentarios que desee capturar como parte del registro histórico.
96
Cada vez que un miembro del equipo actualiza el elemento de trabajo, en el historial de este se muestra la fecha del cambio, el miembro del equipo que lo realizó y los campos que han cambiado.
3. Vincule el caso de usuario a otros elementos de trabajo, como tareas, casos de prueba, errores y problemas.
Para obtener más información, vea las siguientes secciones en este tema:
Agregar y vincular tareas a un caso de usuario. Agregar y vincular casos de prueba a un caso de usuario. Agregar un error a un caso de usuario. Agregar un problema a un caso de usuario. Agregar detalles, datos adjuntos o hipervínculos a un caso de usuario.
4. Haga clic en Guardar elemento de trabajo.
Nota
Después de guardar el caso de usuario, aparecerá el identificador en el título debajo de la barra
de herramientas del elemento de trabajo.
Agregar y vincular tareas a un caso de usuario
Puede agregar tareas a un caso de usuario para realizar el seguimiento del progreso de trabajo realizado para completar el caso de usuario.
Nota
Los informes Información general sobre los casos y Progreso de los casos requieren la creación de
vínculos entre casos de usuario y tareas, y entre casos de usuario y casos de prueba. Para obtener más
información, vea Informe Información general sobre los casos (Agile) e Informe Progreso de los casos
(Agile).
97
Para crear una tarea vinculada a un caso de usuario
1. En la pestaña Implementación, haga clic en Nuevo.
Se abre el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, deje la opción predeterminada, Secundario. 3. En la lista Tipo de elemento de trabajo, haga clic en Tarea. 4. En Título, escriba un nombre que identifique con la mayor concreción posible el área del trabajo
que se va a realizar. 5. (Opcional) Escriba información adicional en Comentario. 6. Haga clic en Aceptar.
Se abre un formulario de elemento de trabajo para una tarea con la información que ha proporcionado.
7. Especifique los campos restantes tal como se describe en esta guía en “Tarea” y, a continuación,
haga clic en Guardar elemento de trabajo.
Para vincular varias tareas existentes a un caso de usuario
1. En la pestaña Implementación, haga clic en Vincular a.
Se abre el cuadro de diálogo Agregar vínculo a Caso de usuario.
98
2. En la lista Tipo de vínculo, deje la opción predeterminada, Secundario. 3. Haga clic en Examinar.
Aparece el cuadro de diálogo Elegir elementos de trabajo vinculados.
4. Escriba los elementos en Identificadores de elementos de trabajo o busque los elementos a los que desea establecer vínculos. También puede ejecutar la consulta de equipo Mis tareas para buscar las tareas a las que desea establecer vínculos. Active la casilla situada junto a cada una de las tareas que desea vincular al caso de usuario. Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o importar”.
5. (Opcional) Escriba una descripción de las tareas a las que está estableciendo vínculos.
6. Haga clic en Aceptar y, a continuación, en Guardar elemento de trabajo.
Nota
Se actualizan tanto el caso de usuario como las tareas vinculadas. Se crea un vínculo primario al caso de
usuario para cada tarea agregada.
99
Agregar y vincular casos de prueba a un caso de usuario
Como parte de la planeación, debe crear casos de prueba y vincularlos a casos de usuario. El cliente recomendado para crear conjuntos de pruebas y casos de prueba es Microsoft Test Manager. En este cliente, también puede establecer vínculos a un caso de usuario como se describe en “Cómo: Ver los requisitos o casos de usuario mediante el Administrador de pruebas de Microsoft”.
Para agregar un nuevo caso de prueba a un caso de usuario
1. En la pestaña Casos de prueba, haga clic en Nuevo.
Se abre el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, deje la opción predeterminada, Prueba realizada por. 3. En la lista Tipo de elemento de trabajo, deje la opción predeterminada, Caso de prueba. 4. En Título, escriba un nombre descriptivo que defina el área que se va a probar. 5. (Opcional) Escriba información adicional en Comentario. 6. Haga clic en Aceptar.
Se abre un formulario de elemento de trabajo para un caso de prueba con la información que ha proporcionado.
7. Especifique los campos restantes tal como se describe en esta guía “Caso de prueba” y, a
continuación, haga clic en Guardar elemento de trabajo.
Para agregar casos de prueba existentes a un caso de usuario
1. En la pestaña Casos de prueba, haga clic en Vincular a.
Se abre el cuadro de diálogo Agregar vínculo a caso de usuario.
2. En la lista Tipo de vínculo, deje la opción predeterminada,Prueba realizada por. 3. En Identificadores de elementos de trabajo, escriba los identificadores de los casos de prueba
que desea vincular o búsquelos.
Puede ejecutar la consulta de equipo Mis casos de prueba para buscar los casos de prueba que desea agregar y, a continuación, activar la casilla situada junto a cada uno de los casos de prueba a los que desea establecer vínculos. Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o importar”.
4. (Opcional) Escriba una descripción de los casos de prueba a los que está estableciendo vínculos.
5. Haga clic en Aceptar y en Guardar elemento de trabajo. 6.
100
Nota
Se actualizan tanto el caso de usuario como los casos de prueba a los que ha establecido vínculos. Se
crea un vínculo Pruebas al caso de usuario creado para cada caso de prueba agregado.
Agregar un problema a un caso de usuario
Puede crear un elemento de trabajo para un problema y vincularlo al caso de usuario en la pestaña Todos los vínculos. Mediante la definición del problema y su vinculación al caso de usuario, puede realizar mejor el seguimiento de la calidad y la realización del caso de usuario.
Para crear un problema y vincularlo a un caso de usuario
1. En la pestaña Todos los vínculos, haga clic en Nuevo.
Se abre el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, haga clic en Relacionado. 3. En la lista Tipo de elemento de trabajo, haga clic en Problema. 4. En Título, escriba un nombre que identifique con la mayor concreción posible el problema de
bloqueo. 5. (Opcional) Escriba información adicional en Comentario. 6. Haga clic en Aceptar.
Se abre un formulario de elemento de trabajo para un problema con la información que ha proporcionado.
7. Defina los campos restantes tal como se describe en esta guía en “Problema” y, a continuación,
haga clic en Guardar elemento de trabajo.
Agregar detalles, archivos e hipervínculos a casos de usuario
Puede agregar detalles a casos de usuario de las siguientes maneras:
Escriba información en el campo Descripción o Historial. Adjunte un archivo.
Por ejemplo, puede adjuntar un subproceso de correo electrónico, un documento, una imagen, un archivo de registro u otro tipo de archivo.
Agregue un hipervínculo a un sitio web o a un archivo que esté almacenado en un servidor o un sitio web.
101
Para agregar detalles a un caso de usuario
1. En la pestaña Detalles, escriba información en el campo Descripción. 2. (Opcional) Escriba la información en el campo Historial.
Puede aplicar formato a la información para dar énfasis o capturar una lista con viñetas. Para obtener más información, vea en esta guía “Títulos, Identificadores, Descripciones e Historial”.
3. Haga clic en Guardar elemento de trabajo.
Para agregar datos adjuntos a un caso de usuario
4. En la pestaña Datos adjuntos, realice una de las siguientes acciones: 5. Arrastre un archivo al área de datos adjuntos.
6. Haga clic en o presione CTRL+V para pegar un archivo que haya copiado.
7. Haga clic en Agregar y, a continuación, en Examinar. En el cuadro de diálogo Datos adjuntos, desplácese hasta el nombre del archivo que desea adjuntar o escríbalo.
8. (Opcional) Escriba información adicional sobre los datos adjuntos en el cuadro Comentario. Para volver a la pestaña Datos adjuntos, haga clic en Aceptar.
9. Haga clic en Guardar elemento de trabajo.
Para agregar un hipervínculo a un caso de usuario
1. En la pestaña Todos los vínculos, haga clic en Vincular a.
2. En la lista Tipo de vínculo, haga clic en Hipervínculo. 3. En el cuadro Dirección, escriba la dirección del destino del vínculo. 4. Si el destino es un sitio web, escriba la dirección URL o bien cópiela del explorador de Internet y
péguela en el cuadro Dirección. Si el destino es una ubicación del servidor, escriba la dirección con formato de nombre UNC.
5. (Opcional) Escriba información adicional sobre el hipervínculo en el cuadro Comentario.
102
6. Haga clic en Aceptar y, a continuación, en Guardar elemento de trabajo.
Resolver y cerrar un caso de usuario
Puede utilizar los estados Activo, Resuelto y Cerrado para seguir el progreso de los casos de usuario. Una vez escrito el código para implementar un caso de usuario y superadas todas las pruebas unitarias, puede cambiar el Estado del caso de usuario a Resuelto. Una vez completadas todas las tareas y superadas todas las pruebas de aceptación del caso de usuario, puede cambiar su Estado a Cerrado. Cualquier miembro del equipo puede cambiar el estado de un caso de usuario.
Para obtener más información sobre los campos de datos que puede utilizar para realizar el seguimiento de los estados de los elementos de trabajo, vea en esta guía “Asignaciones y flujo de trabajo”.
Para resolver o cerrar un caso de usuario activo
1. Abra el caso de usuario. 2. En la lista Estado, haga clic en Resuelto o Cerrado.
Si cambia el estado de Activo a Resuelto, el campo Motivo cambia automáticamente a Código completo y pruebas unitarias superadas.
Si cambia el estado de Resuelto a Cerrado, el campo Motivo cambia a Superación de las pruebas de aceptación.
Si cambia el estado de Activo a Cerrado, debe hacer clic en el Motivo que coincida con su intención, como de Activo a Cerrado más adelante en este tema.
3. Haga clic en Guardar elemento de trabajo.
Progresión habitual del flujo de
trabajo:
Un representante del cliente
crea un caso de usuario en el
estado Activo con el motivo
predeterminado, Nuevo.
Un miembro del equipo cambia
el estado del caso de usuario
de Activo a Resuelto una vez
completado el código y
superadas las pruebas
unitarias.
Un miembro del equipo cambia
el estado de Resuelto a
Cerrado una vez superados los
Diagrama de estado de caso de usuario
103
casos de prueba que se
definieron para el caso de
usuario.
Transiciones atípicas:
Un representante del cliente
determina que el caso de
usuario no es relevante o está
fuera de ámbito y cambia el
estado de Activo a Cerrado.
No se supera la prueba de
aceptación del caso de usuario.
Por consiguiente, un miembro
del equipo cambia el estado de
Resuelto a Activo.
Un representante del cliente
determina que el caso de
usuario se cerró por error o
está actualmente en el ámbito
y cambia el estado de Cerrado
a Activo.
Activo (Nuevo)
Los siguientes campos de datos se capturan automáticamente cuando un miembro del equipo crea un caso de usuario:
Creado por: nombre del miembro del equipo que creó el elemento de trabajo. Fecha de creación: fecha y hora en que se creó el elemento de trabajo registradas por el reloj del
servidor.
104
De Activo a Resuelto
Puede resolver un caso de usuario activo por el siguiente motivo:
Motivo Cuándo utilizarlo Acciones adicionales que se deben realizar
Código completo y
pruebas unitarias
superadas
Cuando el código para implementar un caso de
usuario está protegido y se han superado todas
las pruebas unitarias.
Asigne el caso de usuario al
miembro del equipo que lo
probará.
Los campos de datos siguientes se capturan cuando un miembro del equipo resuelve un caso de usuario activo:
Resuelto por: nombre del miembro del equipo que resolvió el elemento de trabajo. Fecha de resolución: fecha y hora en que se resolvió el elemento de trabajo registradas por el
reloj del servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
De Activo a Cerrado
Puede cerrar un caso de usuario activo por uno de los motivos siguientes:
Motivo Cuándo utilizarlo Acciones adicionales que se deben realizar
Rechazado (valor
predeterminado)
Determina que el caso de
usuario representa una
característica o requisito que no
admite una propuesta de valor,
escenario o requisito de
negocio.
Ninguno.
Abandonado No se considera necesaria la
implementación del caso de
usuario.
Ninguno.
Fuera de ámbito El equipo no dispone de
recursos suficientes para
Actualice el campo Iteración para especificar en
qué iteración se implementará el escenario.Si el
105
implementar el caso de usuario
para la iteración actual.
Un caso de usuario puede
identificarse como fuera de
ámbito si el equipo no dispone
de tiempo suficiente o si se han
detectado problemas de
bloqueo.
escenario se aplaza hasta la siguiente versión del
software, deje el campo Iteración en blanco,
pero describa detalladamente el motivo del
aplazamiento y cuándo debe implementarse el
citado escenario.
Los campos de datos siguientes se capturan cuando se cierra un caso de usuario activo:
Cerrado por: nombre del miembro del equipo que cerró el elemento de trabajo. Fecha de cierre: fecha y hora en que se cerró el elemento de trabajo registradas en el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
Resuelto
Cuando un caso de usuario se implementa en el código, el jefe de desarrollo establece el estado en Resuelto y asigna el caso a un evaluador para que se pueda iniciar la fase de pruebas.
De Resuelto a Cerrado
Puede cerrar un caso de usuario resuelto por el siguiente motivo:
Motivo Cuándo utilizarlo Acciones adicionales que se deben realizar
Superación de las pruebas
de aceptación
Se han superado todos los casos de
prueba asociados al caso de usuario.
Asigne el caso de usuario al
propietario del producto.
Los campos de datos siguientes se capturan automáticamente cuando un miembro del equipo cierra un caso de usuario resuelto:
Cerrado por: nombre del miembro del equipo que cerró el elemento de trabajo. Fecha de cierre: fecha y hora en que se cerró el elemento de trabajo registradas en el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
106
De Resuelto a Activo
Puede reactivar un caso de usuario resuelto por el siguiente motivo:
Motivo Cuándo utilizarlo Acciones adicionales que se deben realizar
No superación de las
pruebas de
aceptación
Cuando no se ha superado al
menos una de las pruebas del
caso de usuario.
Asigne el caso de usuario al jefe de desarrollo.
Además, el evaluador debe crear errores para
los puntos no superados de las pruebas.
Los datos siguientes se capturan automáticamente cuando se reactiva un caso de usuario resuelto:
Activado por: nombre del miembro del equipo que reactivó el elemento de trabajo. Fecha de activación: fecha y hora en que se reactivó el elemento de trabajo registradas en el reloj
del servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
Closed
Se puede reactivar un caso de usuario cerrado si vuelve al ámbito. Normalmente, los responsables de reactivar un caso de usuario cerrado son un analista de negocios o un administrador de programas.
De Cerrado a Activo
Puede reactivar un caso de usuario cerrado por los siguientes motivos:
Motivo Cuándo utilizarlo Acciones adicionales que se deben realizar
Reintroducido
en el ámbito
Hay recursos disponibles para
implementar el caso de usuario.
Asegúrese de que las tareas de implementación,
los casos de prueba y los detalles que se han
definido para el caso de usuario se han
completado y están actualizados.
Cerrado por
error
Un caso de usuario se ha
cerrado antes de cerrarse todas
las tareas asociadas, casos de
prueba o errores.
Asegúrese de que se han definido correctamente
las tareas de implementación, casos de prueba y
detalles para el caso de usuario, y son suficientes
para admitir su desarrollo.
Los datos siguientes se capturan automáticamente cuando se reactiva un caso de usuario cerrado:
107
Activado por: nombre del miembro del equipo que reactivó el elemento de trabajo. Fecha de activación: fecha y hora en que se reactivó el elemento de trabajo registradas en el reloj
del servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
108
Error
Definiendo y administrando los elementos de trabajo del error, su equipo puede seguir los defectos en el producto y dar prioridad esfuerzos por resolverlos. Al definir un error, debería realizar las siguientes tareas:
Notifique el problema con bastante precisión para que otros miembros del equipo pueden entender el impacto completo del problema.
Describa las medidas que tomó antes de encontrar el error para que otros miembros se puedan reproducir más fácilmente el comportamiento que está notificando.
Especifique el comportamiento esperado para ayudar a otros a entender si han corregido el error.
Permisos necesarios
Para ver un error, debe ser un miembro del Lectores grupo o sus elementos de trabajo de Ver en este permiso de nodo debe estar establecido en Permitir. Crear o modificar un error, debe ser un miembro del grupo Contribuyentes o su permiso Editar elementos de trabajo en este nodo debe estar establecido en Permitir. Para obtener más información, vea Administrar permisos.
Definir un error
El formulario de elemento de trabajo para un error contiene los campos y pestañas en la siguiente ilustración:
109
Al definir un error, debe definir el Title. Puede dejar todo el otro espacio en blanco de campos o acepta sus valores predeterminados y actualizarlos posterior.
Para definir un error
1. En la sección superior del formulario de elemento de trabajo para un error, especifique uno o más de los siguientes campos:
En Title (se requiere), escriba una frase que describe el defecto de código. En Iteration, especifique la ruta de acceso de la iteración del error.
Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
En la lista del Assigned To, haga clic en el nombre del miembro del equipo que posee el error.
Nota
Sólo los miembros del grupo Contribuyentes pueden poseer un elemento de trabajo.
110
En la lista State, deje el valor predeterminado, New.
Para obtener más información sobre el campo State y cómo lo utiliza para realizar el seguimiento del flujo de trabajo, vea “Cambiar el estado de un Error” posterior en este tema.
En la lista Reason, deje el valor predeterminado, New defect reported. En Backlog Priority, escriba un número que indica la prioridad relativa del error.
Un número mayor indica una menor prioridad. El valor predeterminado de este campo es 1000, que colocan el nuevo error en la parte inferior del trabajo pendiente.
En Effort, escriba un número que especifica la cantidad relativa de carga de trabajo que se exige para corregir el error.
Un número mayor indica más trabajo.
En la lista Severity, haga clic en el valor que indica el efecto del error en su proyecto.
De forma predeterminada, el valor de este campo es 3 - Medium.
En la lista Area, haga clic en la ruta de acceso del área adecuada.
2. En la más bajo sección del formulario de elemento de trabajo, proporcione la siguiente información:
En la ficha Steps to Reproduce, proporcione tanto detalle como otro miembro del equipo podría necesitar entender el problema que se debe corregir.
Puede dar formato al contenido que proporciona en este campo.
En la ficha Acceptance Criteria, describa los criterios que utilizará para comprobar si su equipo ha corregido el error.
En la ficha History, agregue comentarios que desea capturar como parte del registro histórico.
Cada vez que un miembro del equipo actualiza el elemento de trabajo, en su historial se muestra la fecha del cambio, el miembro del equipo que lo realizó y los campos que han cambiado.
En la ficha Attachments, puede adjuntar archivos que proporcionan más detalles sobre el error.
Por ejemplo, puede adjuntar un subproceso del correo electrónico, un documento, una imagen o un archivo de registro.
111
En la ficha System, describa el entorno de software en el que encuentra el error.
En la lista Encontrado en compilación, haga clic o escriba el nombre de la compilación en la que encuentra el defecto.
En Integrated in Build, no especifique una compilación al definir el error. Al resolver el error, escriba el nombre de la compilación que incorpora el código o corrige el error.
Nota
Un nombre de la compilación único está asociado a cada compilación. Para obtener
más información sobre cómo definir los nombres de compilación, vea Personalizar
números de compilación.
3. Vincule el error a otros elementos de trabajo realizando una o más de las siguientes tareas: En la ficha Tasks, cree uno o más vínculos a partir del error a las tareas.
Para obtener más información, vea “Agregar y vincular Tareas a un Error” más adelante en este tema.
En la ficha Test Cases, cree uno o más vínculos a partir del error a los casos de prueba.
Para obtener más información, vea “Agregar y vincular Casos de Pruebas a un Error” más adelante en este tema.
En la ficha Links, cree uno o más vínculos a partir del error a otros errores o a otros tipos de elementos de trabajo. También puede agregar uno o más hipervínculos a los sitios web o a los archivos que están almacenados en servidores o en sitios web.
Para obtener más información, vea Adding Other Work Items to a Bug más adelante en este tema.
4. En la barra de herramientas del elemento de trabajo, haga clic en Save work item.
Después de guardar el error, aparecerá el identificador en el título debajo de la barra de herramientas de elemento de trabajo.
Agregar y vincular Tareas a un error
Puede agregar los elementos de trabajo de la tarea a un error para realizar el seguimiento del progreso de trabajo que se ha producido para resolver y cerrar el error.
112
Para crear una tarea que se vincula a un error
1. En la ficha Tasks, haga clic New.
Se abrirá el cuadro de diálogo Add new Linked Work Item to Product Backlog.
2. En la lista Lin Type, deje la opción predeterminada, Child. 3. En la lista Work Item Type, haga clic en Task. 4. En Title, escriba un nombre que describe el área de trabajo que se realizará tan específicamente
como posible. 5. (Opcional) Escriba información adicional en Comments. 6. Haga clic en OK.
Un formulario de elemento de trabajo para una tarea se abre y muestra la información que ha proporcionado.
7. Especifique los campos restantes y, a continuación, haga clic en Save work item.
Para obtener más información sobre los campos en el elemento de trabajo de la tarea, vea en esta guía “Tarea”.
Para vincular las tareas existentes a un error
1. En la ficha Tasks, haga clic en Link to.
Se abre el cuadro de diálogo Add Link to Bug.
113
2. En la lista Link Type, deje la opción predeterminada, Child. 3. Haga clic en Browse.
Aparece el cuadro de diálogo Choose linked work items.
4. Para especificar las tareas a las que desea vincular el error, realice una de las siguientes tareas: Ejecute una consulta para buscar las tareas a las que desea vincular. Escriba los identificadores de las tareas a las que desea vincular. Escriba el texto que se contiene en los títulos de los elementos de destino y, a
continuación, haga clic en Task como el tipo de elemento de trabajo.
Activar la casilla al lado de cada tarea que desea vincular al error y, a continuación, haga clic en OK.
El cuadro de diálogo Choose linked work item desaparece. Para obtener más información, vea
en esta guía “Buscar elementos de trabajo para vincular o importar”.
5. (Opcional) En el Add new Linked Work Item dialog box, escriba una descripción para las tareas a las que está vinculando el error.
6. Haga clic en OK y, a continuación, en Save work item.
El error y las tareas a las que lo vinculó están actualizados. Para cada tarea que agregó, un vínculo primario al error se crea.
114
Agregar y vincular Casos de prueba a un error
Puede crear un caso de prueba y vincularlo a un error. El cliente recomendado para crear conjuntos de pruebas y casos de prueba es Microsoft Test Manager. De este cliente, puede vincular también a un error, tal y como se describe en Cómo: Ver los requisitos o casos de usuario mediante el Administrador de pruebas de Microsoft.
Para agregar un caso de prueba a un error
1. En la pestaña Test Cases, haga clic en Nuevo.
El cuadro de dialogo Add new Linked Work Item aparece.
2. En la lista Link Type, deje la opción predeterminada, Prueba realizada por. 3. En la lista Work Item Type, deje la opción predeterminada, Test Case. 4. En Title, escriba una descripción del área que se va a probar. 5. (Opcional) Escriba información adicional en Comments. 6. Haga clic en OK.
Un formulario de elemento de trabajo para un caso de prueba se abre y muestra la información que ha proporcionado.
7. Especifique los campos restantes y, a continuación, haga clic en Save work item.
Para obtener más información sobre los campos en el formulario de elemento de trabajo para
un caso de prueba, vea en esta guía “Caso de prueba”.
Para agregar los casos de prueba existentes a un error
1. En la pestaña Test Case, haga clic en Link to.
El cuadro de diálogo Agregar Vincular a error se abre.
2. En la lista Tipo de vínculo, deje la opción predeterminada, Prueba realizada por. 3. En Identificadores de elementos de trabajo, escriba los identificadores de los casos de prueba a
los que desea vincular o búsquelos.
Puede ejecutar una consulta guardada para buscar los casos de prueba que desea agregar y a continuación, activar la casilla al lado de cada caso de prueba al que desea vincular.
Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o
importar”.
4. (Opcional) Escriba una descripción para los casos de prueba a los que está vinculando el error.
5. Haga clic en Aceptar y, a continuación, en Guardar elemento de trabajo.
115
El error y los casos de prueba a los que lo vinculó están actualizados. Para cada caso de prueba que agregó, un vínculo Pruebas al error se crea.
Agregar otro Work Items a un error
Puede agregar otro error o cualquier otro tipo de elemento de trabajo a un error utilizando la ficha Vínculos.
Crear un elemento de trabajo y vincularlo a un error
1. En la ficha Vínculos, haga clic Nuevo.
Se abrirá el cuadro de diálogo Agregar nuevo elemento de trabajo vinculado.
2. En la lista Tipo de vínculo, haga clic en Relacionado. 3. En la lista Tipo de elemento de trabajo, haga clic en el tipo de elemento de trabajo que desea
crear. 4. En Title, describa el elemento de trabajo. 5. (Opcional) Escriba información adicional en Comments. 6. Haga clic en OK.
Un formulario de elemento de trabajo se abre y muestra la información que ha proporcionado.
7. Haga clic en Save work item.
Cambiar el estado de un error
Un equipo puede realizar el seguimiento del progreso de un error estableciendo su campo State en uno de los siguientes valores: New, Approved, Removed, Committed o Finished. El siguiente diagrama muestra ambos un típico y una progresión del flujo de trabajo atípica de un error.
116
Diagrama de estado de error
Progresión habitual del flujo de trabajo:
Cree un elemento de trabajo de
error en el estado
predeterminado, New.
Cambie el estado de New a
Approved.
Cambie el estado en Approved a
Committed cuando el equipo se
confirma a corregir el error.
Cambie el estado en Committed a
Finished.
Transiciones atípicas:
Cambie el estado de New a
Removed.
Cambie el estado en Removed a
New.
Cambie el estado en Approved a
Removed.
Cambie el estado en Committed a
Approved.
Los cambios Estatales Cuándo utilizarlo
De New a Approved Cuando el propietario del producto
aprueba el error.
De New a Removed Cuando el propietario del producto
desaprueba el error.
117
De Approved a Committed Cuando el equipo confirma que va a
corregir el error en el sprint actual.
De Approved a Removed Cuando el equipo decide no corregir el
error.
De Removed a New Cuando el equipo revisa el error.
De Committed a Finished Cuando el equipo corrige el error y
cumple sus criterios de aceptación.
De Listo a Committed Cuando el equipo ha encontrado trabajo
adicional que el error que fue corregido.
De Committed a Approved Cuando el equipo deja de trabajar en el
error debido al cambio de personal o
ajuste de la prioridad.
118
Sprint
Definiendo y administrando los elementos de trabajo del sprint, su equipo puede capturar el objetivo, las fechas de finalización e inicio y los resultados retrospectivos para cada sprint en un proyecto. Durante una carrera corta se planea la reunión, su equipo determina el objetivo del sprint y el número de elementos del Product Backlog que los miembros del equipo pueden lograr sobre el próximo sprint. En Scrum se debe asegurar que el objetivo del sprint sigue siendo constante a lo largo del sprint. Al final de cada sprint, su equipo discute lo que fue bien y lo que no fue bien durante el sprint y, a continuación, decidir qué pueden hacer de manera diferente los miembros del equipo para hacer que el sprint siguiente sea más efectivo.
Permisos necesarios
Para ver un sprint, debe ser un miembro del Lectores grupo o sus elementos de trabajo de Ver en este permiso de nodo debe estar establecido en Permitir. Para modificar un sprint, debe ser un miembro del grupo Contribuyentes o su permiso Editar elementos de trabajo en este nodo debe estar establecido en Permitir. Para obtener más información, vea Administrar permisos.
Definir un Sprint
El formulario de elemento de trabajo para un sprint contiene los campos y pestañas en la siguiente ilustración:
119
Para definir un sprint
1. En Iteration, especifique la ruta de acceso de la iteración del sprint.
Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
2. En la ficha Details, defina el inicio y fecha de fin para el sprint y proporcione bastante detalle cuando necesita describir el objetivo del sprint.
3. Deje el espacio en blanco de ficha de Retrospective hasta el fin del sprint.
Después de que el sprint finaliza, utiliza esta pestaña para describir los resultados del sprint, discusión y decisiones que realizó durante la revisión del sprint y la reunión retrospectiva del sprint. Puede resumir estos detalles en el siguiente formato: ¿Qué funcionó bien? ¿Qué no funcionó? ¿Qué hará funcionemos mejor?
4. En la ficha History, agregue comentarios que desea capturar como parte del registro histórico.
Cada vez que un miembro del equipo actualiza un elemento de trabajo, su historial muestra la fecha del cambio, el miembro del equipo que realizó la modificación, y los campos que cambiaron.
5. En la ficha Attachments, adjunte las características técnicas, imágenes u otros archivos que proporcionan más detalles sobre la carrera corta.
6. Haga clic en Save work item.
Después de guardar el sprint, el identificador aparece en el título en la barra de herramientas de elemento de trabajo.
120
Impedimento
Definiendo y administrando los impedimentos de los elementos de trabajo, su equipo puede identificar y seguir problemas que evitan que complete las tareas eficazmente. Puede identificar los impedimentos durante el scrum cotidiano. El scrummaster es responsable para ayudar a resolver estos impedimentos y mejorar la productividad del equipo.
Permisos necesarios
Para ver un impedimento, debe ser un miembro del Lectores grupo o sus elementos de trabajo de Ver en este permiso de nodo debe estar establecido en Permitir. Modificar un impedimento, debe ser un miembro del grupo Contribuyentes o su permiso Editar elementos de trabajo en este nodo debe estar establecido en Permitir. Para obtener más información, vea Administrar permisos.
121
Definir un Impedimento
El formulario de elemento de trabajo para un impedimento contiene los campos y pestañas en la siguiente ilustración:
Al definir un impedimento, todos los campos son opcionales excepto Title.
Para definir un impedimento
1. En la sección superior del formulario de elemento de trabajo, especifique uno o más de los siguientes tipos de información:
En Title (se requiere), escriba una frase que con precisión describe el problema y define las áreas de trabajo al que el impedimento afecta.
En Iteration, seleccione la ruta de acceso de la iteración para el impedimento.
Puede especificar la ruta de acceso de iteración de raíz para iniciarse y a continuación, pasar el impedimento a una carrera corta durante una carrera corta planee la reunión.
En la lista del Assigned To, haga clic en el nombre del miembro del equipo que es responsable para resolver el impedimento.
122
Nota
Sólo los miembros del grupo Contribuyentes pueden poseer un elemento de trabajo.
En la lista State, deje el valor predeterminado, New.
Después de que su equipo resuelve el impedimento, puede cambiar el estado en New a Closed.
En la lista Reason, deje el valor predeterminado, New impediment.
En la lista Priority, haga clic en un valor para especificar la importancia del impedimento en una escala de 1 a 4, 1 es muy importante.
El valor predeterminado es 2.
En Area, haga clic en la ruta de acceso del área adecuada o deje el espacio en blanco de campo y asígnelo posterior durante una reunión del planeamiento.
Para obtener más información, vea en esta guía Crear y modificar áreas e iteraciones.
2. Especifique información sobre una o más de las siguientes pestañas: En la ficha Description, describa el impedimento en detalle.
En la ficha Resolution, describa en detalle cómo su equipo resolvió el impedimento.
En la ficha History, agregue comentarios que desea capturar como parte del registro
histórico.
Puede dar formato al texto que escriba en este cuadro.
Cada vez que un miembro del equipo actualiza el elemento de trabajo, su historial muestra la fecha y los comentarios para el cambio, el nombre del miembro del equipo que realizó la modificación, y los campos que cambiaron.
3. En la ficha Links, vincule el impedimento a otros elementos de trabajo, como un elemento de trabajo pendiente de producto, una tarea u otro impedimento.
Para obtener más información, vea la siguiente sección de este tema.
4. En la ficha Attachments, adjunte archivos que proporcionan más detalles sobre el impedimento.
Por ejemplo, puede adjuntar un subproceso del correo electrónico, un documento, una imagen o un archivo de registro.
123
5. Haga clic en Save work item.
Vincular un Impedimento a un Elemento Trabajo pendiente del producto, Otro Tipo o un Tarea de
Elemento de trabajo
Puede vincular un impedimento a otro elemento de trabajo utilizando la ficha Links.
Para vincular un impedimento a un elemento de trabajo pendiente de producto, una tarea u otro tipo
de elemento de trabajo
1. En la pestaña Links, haga clic en Links to.
Se abre el cuadro de diálogo Add Link to Impediment.
2. En la lista Tipo de vínculo, haga clic en Relacionado. 3. Realice una de las acciones siguientes:
En Identificadores de elementos de trabajo, escriba los identificadores de los elementos de trabajo a los que desea vincular el impedimento. Identificadores independientes utilizando comas o espacios.
Haga clic en Browse para especificar elementos de trabajo en una lista.
Aparece el cuadro de diálogo Choose linked work item.
124
En la lista Saved Query, haga clic en una consulta que devuelve uno o más de los elementos de trabajo a los que desea vincular el impedimento. Por ejemplo, puede hacer clic en Sprint Backlog o Blocked Tasks.
Hacer clic en Browse y activar la casilla al lado de cada elemento de trabajo que desea vincular al impedimento y, a continuación, haga clic en OK.
(Opcional) Escriba una descripción o un comentario para los elementos a los que está vinculando.
4. Haga clic en OK.
Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o
importar”.
5. Haga clic en Save work item.
El impedimento y los elementos a los que lo vinculó están actualizados. Para cada elemento de trabajo que agregó, se define un vínculo Relacionado al impedimento.
125
Tarea
Definiendo y administrando los elementos de trabajo de la tarea, su equipo puede seguir y notificar el trabajo detallado que debe lograr para un trabajo pendiente del producto. Normalmente se pronostica el trabajo y se define las tareas en el inicio de cada sprint y cada miembro del equipo realiza un subconjunto de esas tareas. Las tareas pueden incluir el desarrollo, pruebas y otros tipos de trabajo. Por ejemplo, un desarrollador de software puede definir las tareas para implementar los elementos de trabajo pendiente de un producto y un probador puede definir las tareas para escribir y ejecutar los casos de prueba.
Permisos necesarios
Para ver una tarea, debe ser miembro del grupo Readers o tener el permiso Ver los elementos de trabajo en este nodo establecido en Permitir. Para crear o modificar una tarea, debe ser miembro del grupo Contributors o tener el permiso Editar elementos de trabajo en este nodo establecido en Permitir. Para obtener más información, vea Administrar permisos.
126
Definir una tarea
El formulario de elemento de trabajo para una tarea contiene los campos y pestañas en la siguiente ilustración:
Al definir una tarea, todos los campos son opcionales excepto Title.
Para definir una tarea
1. En la sección superior del formulario de elemento de trabajo para una tarea, especifique uno o más de los siguientes tipos de información:
En Title (se requiere), escriba un título que proporciona una información general concisa del área de trabajo en la tarea.
En Iteration, especifique la ruta de acceso de la iteración de la tarea.
Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
En la lista del Assigned To, haga clic en el miembro del equipo que es responsable por haber asegurarse de que se completa la tarea.
127
Si más de un miembro del equipo debería poseer la misma tarea, dividirlo en tareas independientes o subtareas y asignar cada tarea o subtarea a un propietario.
Nota
Sólo los miembros del grupo Contribuyentes pueden poseer un elemento de trabajo.
En la lista State, deje el valor predeterminado, To Do .
Para obtener más información sobre el campo State y cómo lo utiliza para realizar el seguimiento del flujo de trabajo, vea “Cambiar el estado de una Tarea” posterior en este tema.
En la lista Reason, deje el valor predeterminado, New Task Ctrl+T.
En la lista Blocked, haga clic en Yes si se bloquea esta tarea.
En Remaining Work, escriba un número que indica cuántas horas de trabajo usted espera que la tarea requiera.
Importante
Si divide una tarea en las subtareas, sólo especifique las horas para las subtareas.
En Backlog Priority, escriba un número que indica la prioridad relativa de la tarea.
Un número mayor indica una menor prioridad.
En la lista Activity, haga clic en el tipo de actividad que la tarea representa.
En la lista Area, haga clic en la ruta de acceso del área adecuada o deje el espacio en blanco de campo, estar asignado después durante una carrera corta planea la reunión.
Para obtener más información, vea en esta guía “Crear y modificar áreas e iteraciones”.
2. (Opcional) En la sección más abajo, especifique información sobre las siguientes pestañas: En Description, escriba bastantes detalles para describir el trabajo que se realizará.
En History, escriba los comentarios que desee capturar como parte del registro histórico.
Cada vez que un miembro del equipo actualiza el elemento de trabajo, en su historial se muestra la fecha del cambio, el miembro del equipo que lo realizó y los campos que han cambiado.
128
3. (Opcional) Vincule la tarea a otros elementos de trabajo, como elementos de trabajo pendiente de producto, errores, impedimentos u otras tareas. Para obtener más información, vea la siguiente sección.
4. Haga clic en Save work item. Después de guardar la tarea, el identificador aparece en la barra de herramientas de elemento de trabajo.
Vincular una tarea a otros elementos de trabajo
Puede vincular una tarea a otras tareas o a otros tipos de elementos de trabajo, como impedimentos o errores.
Para vincular una tarea a un elemento de trabajo existente
1. En la pestaña Links, haga clic en Vincular a.
Se abrirá el cuadro de diálogo Agregar vínculo a tarea.
2. En la lista Tipo de vínculo, haga clic en un tipo de vínculo adecuado.
Por ejemplo, podría hacer clic en Relacionado.
3. Realice una de las acciones siguientes: En Identificadores de elementos de trabajo, escriba los identificadores de uno o más
elementos. Haga clic en Browse para especificar elementos de trabajo en una lista.
129
Aparece el cuadro de diálogo Choose linked work items.
En Saved Query, haga clic en una consulta que devolverá el elemento o elementos a los que desea vincular. Haga clic en Browse y active la casilla al lado de cada elemento de trabajo que desea vincular a la tarea.
Para obtener más información, vea en esta guía “Buscar elementos de trabajo para
vincular o importar”.
4. (Opcional) Escriba una descripción de los elementos a los que está estableciendo vínculos. 5. Haga clic en OK y, a continuación, haga clic en Save.
Se actualizan la tarea y los elementos a los que estableció vínculos. Se define un vínculo Relacionado a la tarea para cada error o problema que agregó.
130
Cambiar el estado de una tarea
Su equipo puede realizar el seguimiento del progreso de una tarea estableciendo su campo State en uno de los siguientes valores: To Do, In Progress, Done o Removed. El siguiente diagrama muestra ambos diagramas un típico y una progresión del flujo de trabajo atípica de una tarea.
Diagrama de estados de las tareas
Progresión habitual del flujo de trabajo:
Cree una tarea en el estado del To Do.
Cambie el estado de To Do a In
Progress.
Cambie el estado In Progress a Done.
Los estados de transición de flujo de trabajo
atípicos:
Cambie el estado de To Do a Quitado.
Cambie el estado de In Progress a
Quitado.
Cambie el estado de In Progress a To
Do.
Cambie el estado de In Progress a
Done.
Los cambios Estatales Cuándo utilizarlo
De To Do a In Progress Cuando un miembro del equipo empieza a
trabajar en la tarea.
De To Do a Removed Cuando el trabajo que la tarea ya representa
no ayuda a completar el producto o cuando
el equipo quita la funcionalidad para la tarea
del producto.
De In Progress a Done Cuando el equipo ha completado la tarea y
ha cumplido sus requisitos.
De In Progress a Removed Cuando el trabajo que la tarea ya representa
131
no ayuda a completar el producto o cuando
el equipo quita la funcionalidad para la tarea
del producto.
De In Progress a To Do. Cuando el trabajo para la tarea se ha
detenido debido a cambios del personal o
ajuste de la prioridad.
En Done a In Progress. Cuando el equipo ha encontrado trabajo
adicional que la tarea exige haber finalizado.
132
Casos de prueba
La plantilla de proceso para Scrum proporciona un elemento de trabajo del caso de prueba que es idéntico al que la plantilla de proceso para v5.0 de MSF for Agile Software Development proporciona.
133
Caso de prueba
Un equipo utiliza casos de prueba para definir tanto pruebas manuales como automatizadas que se pueden ejecutar y administrar mediante Microsoft Test Manager. Utilizando Microsoft Test Manager, puede crear no solo casos de prueba, sino también conjuntos de pruebas y configuraciones de prueba que permitan probar el proyecto. Puede utilizar configuraciones de pruebas para definir cómo desea ejecutar los casos de prueba y las series de pruebas. Puede agrupar los casos de prueba y organizarlos en una jerarquía de series de pruebas en el plan de pruebas. Creando series de pruebas, puede ejecutar conjuntos de casos de prueba como un grupo. Para obtener más información, vea Definir el trabajo de pruebas mediante los planes de prueba.
Nota
Puede definir un caso de prueba utilizando Team Explorer, pero es mejor si define los casos de prueba
utilizando Microsoft Test Manager. Puede tener acceso Microsoft Test Manager de Visual Studio Test
Professional 2010, Visual Studio 2010 Professional o Visual Studio 2010 Ultimate. Para obtener más
información, vea Crear y administrar pruebas.
Para definir la secuencia de acción que define una prueba manual o un conjunto de pasos compartidos,
debe utilizar Microsoft Test Manager. Puede ver y modificar otros campos que se definen para los casos
de prueba y los pasos compartidos utilizando Team Explorer o Team Web Access. Sin embargo, no
puede modificar los campos que aparecen en la ficha Pasos en estos clientes.
Si actualizara un proyecto de equipo, puede necesitar realizar las tareas adicionales antes de poder
utilizar casos de prueba e interfaz con Microsoft Test Manager. Para obtener más información, vea
Habilitar la interfaz con el Administrador de pruebas de Microsoft para proyectos de equipo
actualizados.
Muchas pruebas exigen al probador que realice la misma secuencia de pasos para varios casos de prueba. Creando pasos compartidos, puede definir una secuencia de pasos una vez e insertarla en muchos casos de prueba. Por ejemplo, si cada caso de prueba exige a un probador que inicie sesión en la aplicación, puede crear un conjunto de pasos compartidos para realizar estas acciones. Puede agregar a continuación los pasos compartidos a cada caso de prueba y ejecutar los pasos utilizando Ejecutor de pruebas. Porque sólo utiliza los pasos compartidos para hacer aerodinámico la definición de prueba manual embala, debería utilizar Microsoft Test Manager para crear los pasos compartidos. Para obtener más información, vea Cómo: Compartir pasos de casos de pruebas mediante pasos compartidos.
134
En este tema Temas relacionados
Definir un caso de prueba
Vincular un caso de prueba a un caso de
usuario
Agregar datos adjuntos o hipervínculos a un
caso de prueba
Cambiar el estado de un caso de prueba
Procesos ágiles
Realizar pruebas tempranas y frecuentes
Informes ágiles (Reporting Services)
Informe Disponibilidad de casos de prueba
Informe de progreso del plan de pruebas
Informe Información general sobre los
casos (Agile)
Referencia de campos
Títulos, Identificadores, Descripciones e
Historial (Agile)
Asignaciones y flujo de trabajo (Agile)
Planeamiento, clasificación y prioridades
Áreas e iteraciones
Vincular elementos de trabajo (Agile)
Datos adjuntos
Permisos necesarios
Para ver un caso de prueba, debe ser miembro del grupo de seguridad Readers o tener el permiso Ver los elementos de trabajo en este nodo establecido en Permitir. Para crear o modificar un caso de prueba, debe ser miembro del grupo Contributors o tener los permisos Editar elementos de trabajo en este nodo establecidos en Permitir. Para obtener más información, vea Administrar permisos.
135
Definir un caso de prueba
Puede definir un caso de prueba utilizando Team Explorer o Team Web Access y después agregarlo a un plan de pruebas utilizando Microsoft Test Manager. Al definir un caso de prueba, especifique los campos que muestra la siguiente ilustración.
Al definir un caso de prueba, todos los campos son opcionales salvo Title.
Siempre puede modificar los campos y agregar más detalle cuando trabaje en el caso de prueba. Para realizar este procedimiento utilizando Microsoft Test Manager, vea Cómo: Crear un caso de prueba manual.
136
Para definir un caso de prueba
1. En la sección superior del formulario de elemento de trabajo para un caso de prueba, especifique uno o más de los campos siguientes:
(Obligatorio) En Title, escriba una frase descriptiva que defina los criterios que va a probar.
En la lista Assigned To, haga clic en el propietario que corresponde al caso de prueba.
Nota
Solamente puede asignar elementos de trabajo a los miembros del grupo Contributors.
Si deja el caso de prueba sin asignar, se le asignará automáticamente.
En la lista State, deje el valor predeterminado, Design.
Nota
Puede ejecutar un caso de prueba que esté en el estado Design.
En la lista Priority, haga clic en el nivel de importancia para el caso de prueba en una escala de 1 (más importante) a 4 (importante).
El valor predeterminado de este campo es 2.
En Estado de automatización, deje el valor predeterminado, No automatizado, para los casos manuales o haga clic en Planeado si piensa automatizar el caso de prueba.
Nota
Si agrega un método de automatización desde la pestaña Automatización asociada, el
valor de este campo se actualizará automáticamente a Automatizado. Para obtener
más información sobre cómo convertir un caso de prueba manual en un caso de prueba
automatizada, vea Asociar una prueba automatizada a un caso de prueba manual.
137
En la lista Area, haga clic en el área adecuada en el proyecto de equipo para el caso de prueba.
Este valor debe coincidir con el área que se especifica para el caso de usuario al que se dirige el caso de prueba. El valor predeterminado es el nodo de área superior que se define para el proyecto.
En la lista Iteration, haga clic en la iteración en su proyecto de equipo para el caso de prueba.
El valor predeterminado es el nodo de iteración superior que se define para el proyecto.
Nota
El administrador de cada proyecto de equipo define las rutas de acceso de Area e
Iteration para dicho proyecto, de forma que el equipo pueda seguir el progreso
mediante dichas designaciones. Para obtener más información, vea en esta guía “Crear y
modificar áreas e iteraciones”.
2. Haga clic en la pestaña Resumen y especifique uno o ambos de los siguientes campos:
En Description, proporcione tantos detalles como desee para describir el caso de prueba.
En History, agregue comentarios que desee capturar como parte del registro histórico.
Cada vez que un miembro del equipo actualiza el elemento de trabajo, en el historial de este se muestra la fecha del cambio, el miembro del equipo que lo realizó y los campos que han cambiado.
3. Vincule el caso de prueba al caso de usuario que prueba.
Para obtener más información, vea “Vincular un caso de prueba a un caso de usuario”, más adelante en este tema.
4. Haga clic en Save work item.
Nota
Después de guardar el caso de prueba, el identificador aparece en la barra de herramientas del
elemento de trabajo.
138
5. En la pestaña Pasos, haga clic en Open para definir los pasos de validación y acción, así como los parámetros que se van a realizar como parte de la prueba.
Microsoft Test Manager se abrirá y mostrará el caso de prueba.
Nota
Sólo puede definir los pasos de pruebas utilizando Microsoft Test Manager.
Para obtener más información, vea Crear y administrar pruebas.
Vincular un caso de prueba a un caso de usuario
Vincule los casos de prueba a un caso de usuario para realizar el seguimiento del progreso de las pruebas creadas para el caso de usuario. Después de haber definido los casos de prueba, puede vincularlos a los casos de usuario que implementan utilizando el siguiente procedimiento. Para obtener información sobre cómo realizar este procedimiento utilizando Microsoft Test Manager, vea Cómo: Agregar requisitos o casos de usuario al plan de pruebas.
Para vincular un caso de prueba a un caso de usuario
1. Haga clic en la pestaña Tested User Stories.
2. Haga clic en Link to.
Se abre el cuadro de diálogo Agregar el vínculo al caso de prueba.
3. En la lista Link Type, deje el valor predeterminado, Pruebas.
139
Puede especificar sólo el tipo Pruebas de vínculo al crear un vínculo desde la pestaña Elementos de trabajo probados.
4. Haga clic en Browse.
Aparecerá el siguiente cuadro de diálogo:
5. En la lista Saved Query, haga clic en la consulta de equipo Casos de usuario abiertos y, a continuación, haga clic en Browse.
6. Active la casilla situada junto al caso de usuario al que desea vincular al caso de prueba.
Para obtener más información, vea en esta guía “Buscar elementos de trabajo para vincular o
importar”.
7. (Opcional) En el cuadro de texto Comments, escriba una descripción para el vínculo. 8. Haga clic en OK.
9. Haga clic en Save work item.
140
Nota
Se actualizan tanto el caso de usuario como el caso de pruebas vinculados. Se agrega un vínculo
Prueba realizada por al caso de usuario.
Agregar detalles, datos adjuntos o hipervínculos a un
caso de prueba
Puede agregar información a un caso de prueba que proporcione más información para implementar el caso de prueba. Puede agregar detalles a los casos de prueba de las siguientes maneras:
En el campo Description o History, escriba información.
Adjunte un archivo.
Por ejemplo, puede adjuntar un subproceso de correo electrónico, un documento, una imagen, un archivo de registro u otro tipo de archivo.
Agregue un hipervínculo a un sitio web o a un archivo que esté almacenado en un servidor o sitio web.
Para agregar detalles a un caso de prueba
1. Haga clic en la pestaña Resumen. 2. En Description, escriba información. 3. (Opcional) En el campo history, escriba información.
Puede aplicar formato a la información para dar énfasis o capturar una lista con viñetas. Para obtener más información, vea Títulos, Identificadores, Descripciones e Historial (Agile).
4. Haga clic en Save work item.
141
Para agregar datos adjuntos a un caso de prueba
1. Haga clic en la pestaña Attachments.
2. Realice una de las acciones siguientes: Arrastre un archivo al área de datos adjuntos.
Haga clic en o presione CTRL+V para pegar un archivo que se haya copiado.
Haga clic en Agregar, en Examinar y, en el cuadro de diálogo Datos adjuntos, escriba o busque el nombre del archivo que desee asociar.
(Opcional) Escriba información adicional sobre los datos adjuntos en el cuadro Commentarios. Haga clic en OK para cerrar el cuadro de diálogo Attachments.
3. Haga clic en Save work item.
Para agregar un hipervínculo a un caso de prueba
1. Haga clic en la pestaña Otros vínculos.
2. Haga clic en Vincular a.
142
3. En la lista Tipo de vínculo, haga clic en Hipervínculo. 4. En el cuadro Dirección, escriba la dirección del destino del vínculo. 5. Si el destino es un sitio web, escriba la dirección URL o bien cópiela del explorador de Internet y
péguela en el cuadro Dirección. Si el destino es una ubicación del servidor, escriba la dirección con formato de nombre UNC.
6. (Opcional) Escriba información adicional sobre el hipervínculo en el cuadro Comentario. 7. Haga clic en Aceptar.
8. Haga clic en Guardar elemento de trabajo.
Cambiar el estado de un caso de prueba
Al crear un caso de prueba, su estado se establece automáticamente en Diseño. Cambie el estado a Listo después de definir todos los pasos de validación y acción para el caso de prueba y de aprobar el caso de prueba como listo para ejecutarse. Cuando ya no se requiera un caso de prueba, cambie su estado de Listo a Cerrado. Para obtener más información sobre los campos de datos que realizan el seguimiento de los cambios del estado, vea Asignaciones y flujo de trabajo (Agile).
Para obtener información sobre cómo realizar este procedimiento utilizando Microsoft Test Manager, vea Cómo: Cambiar el estado de un caso de prueba a cerrado. Puede modificar al mismo tiempo varios casos de prueba en Office Excel abriendo la consulta de equipo Abrir casos de prueba y actualizando el campo Estado para los casos de prueba que desee actualizar.
Después de guardar un caso de prueba, puede cambiar su estado a uno de los que describe el siguiente procedimiento.
143
Para cambiar el estado de un caso de prueba
1. Abra el caso de prueba. 2. En la lista Estado, haga clic en uno de los siguientes valores:
Diseño: el caso de prueba se está diseñando, aún no se ha revisado ni aprobado.
Nota
Puede ejecutar un caso de prueba que esté en el estado Diseño.
Listo: el caso de prueba se ha revisado y aprobado y está listo para ejecutarlo. Cerrado: el caso de prueba ya no es necesario para futuras iteraciones de este proyecto
de equipo. 3. En la lista Motivo, deje el valor predeterminado, Obsoleto. Si está cerrando el caso de prueba
por alguna otra razón, haga clic en Aplazado o Duplicado.
4. Haga clic en Guardar elemento de trabajo.
144
Progresión habitual del flujo de trabajo:
Un miembro del equipo crea un
caso de prueba en el estado
Diseño con un motivo
predeterminado Nuevo,
Un miembro del equipo cambia el
estado de un caso de prueba de
Diseño a Listo para indicar que
está listo para ser utilizado para la
prueba de aceptación de los casos
de usuario que prueba.
Un miembro del equipo cambia el
estado de un caso de prueba de
Listo a Cerrado para indicar que ya
no se utiliza.
Estados de transición adicionales del
flujo de trabajo:
Un miembro del equipo cambia el
estado de un caso de prueba de
Diseño a Cerrado para indicar que
un caso de prueba definido para
un caso de usuario no es
pertinente o es un duplicado de
otro caso de prueba.
Un miembro del equipo cambia el
estado de un caso de prueba de
Listo a Diseño para indicar que se
han detectado criterios de prueba
adicionales que se deben agregar a
un caso de prueba.
Diagrama de estado de caso de prueba
145
Un miembro del equipo cambia el
estado de un caso de prueba de
Cerrado a Diseño para indicar que
un caso de prueba se cerró por
error o que el caso de usuario que
prueba está ahora en ámbito.
Diseño [Nuevo]
Un miembro del equipo crea un caso de prueba, proporciona un título descriptivo y define los pasos y parámetros para la ejecución. Una vez de que el miembro del equipo ha definido todos los pasos para el caso de prueba y está listo para ejecutarse, el miembro del equipo cambia el estado de Diseño a Listo.
Los siguientes campos de datos se capturan automáticamente cuando un miembro del equipo crea un caso de prueba:
Asignado a: nombre del miembro del equipo que creó el caso de prueba. Creado por: nombre del miembro del equipo que creó el caso de prueba. Fecha de creación: fecha y hora en que se creó el caso de prueba registradas por el reloj del
servidor.
De Diseño a Listo
Cuando pueda cambiar el estado de un caso de prueba de Diseño a Listo. El campo Motivo se establecerá automáticamente en Completado.
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Completado Se definen todos los
pasos de validación y
acción para el caso de
prueba.
Revise los casos de prueba que se definen para casos de
usuario similares para determinar si puede definir cualquiera
de los pasos compartidos que minimizarán el mantenimiento
de los casos de prueba.
146
De Diseño o Listo a Cerrado
Puede cerrar un caso de prueba desde el estado Diseño o Listo debido a una de las siguientes razones:
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Obsoleto (valor
predeterminado)
El caso de prueba ya no es necesario para la
prueba de aceptación de casos de usuario.
Compruebe que todos los
casos de usuario que están
vinculados al caso de prueba
estén en un estado Cerrado.
Aplazada El caso de prueba no se ejecutará durante el ciclo
del producto o la iteración actual. También puede
especificar este motivo cuando el caso de usuario
que se prueba está Cerrado porque está Fuera de
ámbito o Abandonado.
Ninguno.
Duplicado Cuando el caso de prueba duplica otro caso de
prueba.
Cree un vínculo al caso de
prueba duplicado que
permanece abierto.
Los siguientes campos de datos se capturan cuando un miembro del equipo cierra un caso de prueba:
Cerrado por: nombre del miembro del equipo que cerró el caso de prueba. Fecha de cierre: fecha y hora en que se cerró el caso de prueba registradas por el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del caso de prueba.
Listo
Cuando un caso de prueba esté bien definido y listo para ejecutarse, cambie el estado a Listo.
147
De Listo a Diseño
Puede cambiar el estado de un caso de prueba de Listo a Diseño por los siguientes motivos:
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Actualizar
caso de
prueba
Se debe hacer cambios en el caso de prueba para solucionar los
criterios de aceptación para la prueba. Por ejemplo, puede
cambiar la secuencia de pasos, agregar nuevos pasos y cambiar o
agregar parámetros.
Ninguno.
Los siguientes datos se capturan automáticamente cuando un miembro del equipo reactiva un caso de prueba:
Activado por: nombre del miembro del equipo que reactivó el caso de prueba. Fecha de activación: fecha y hora en que se reactivó el caso de prueba registradas por el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del caso de prueba.
Closed
Puede reactivar un caso de prueba cerrado si los casos de usuario que prueba regresan al ámbito.
De Cerrado a Diseño o Listo
Al actualizar el estado de un caso de prueba de Cerrado a Diseño o Listo, el valor único y predeterminado para Motivo se muestra en la siguiente tabla:
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Reactivado El caso de prueba es necesario para
admitir la prueba de aceptación de un
caso de usuario.
Revise todos los pasos de validación y acción
para asegurarse de que son suficientes para
probar el caso de usuario.
Se capturan los siguientes campos de datos cuando un miembro del equipo actualiza el estado de un caso de prueba de Cerrado a Diseño o Listo:
Activado por: nombre del miembro del equipo que reactivó el caso de prueba. Fecha de activación: fecha y hora en que se reactivó el caso de prueba registradas por el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del caso de prueba.
148
Pasos compartidos
La plantilla de proceso para Scrum proporciona un elemento de trabajo de los pasos compartido que es idéntico al que la plantilla de proceso para v5.0 de MSF for Agile Software Development proporciona.
149
Pasos compartidos
Su equipo puede usar los pasos compartidos para simplificar la definición y mantenimiento de los casos de prueba manual. Muchas pruebas requieren que se realice la misma secuencia de pasos para varios casos de prueba. Si crea pasos compartidos, puede definir una secuencia de pasos una vez e insertarla en muchos casos de prueba. Por ejemplo, si cada caso de prueba exige a un probador que inicie sesión en la aplicación, puede crear un conjunto de pasos compartidos para realizar estas acciones. A continuación, puede agregar los pasos compartidos a cada caso de prueba y ejecutar los pasos mediante Ejecutor de pruebas.
Nota
Puede definir un caso de prueba utilizando Team Explorer, pero es mejor si define los casos de prueba
utilizando Microsoft Test Manager. Puede tener acceso Microsoft Test Manager de Visual Studio Test
Professional 2010, Visual Studio 2010 Professional o Visual Studio 2010 Ultimate. Para obtener más
información, vea Crear y administrar pruebas.
Especificar la secuencia de acción camina que define un conjunto de pasos compartidos, debe utilizar
Microsoft Test Manager. Puede ver y modificar otros campos que se definen para los casos de prueba y
los pasos compartidos utilizando Team Explorer o Team Web Access. Sin embargo, no puede modificar
los campos que aparecen en la ficha Pasos en estos clientes.
Dado que los pasos compartidos solo se definen para simplificar la definición de los casos de prueba manual, es mejor definir los pasos compartidos mediante Microsoft Test Manager. Para obtener más información sobre cómo definir y usar los pasos compartidos, vea los temas que se muestran en la tabla siguiente.
150
Tarea Temas relacionados
Reduzca el mantenimiento de las pruebas compartiendo los pasos
de prueba entre los casos de prueba. Los pasos compartidos se
definen para capturar una secuencia de pasos de prueba y
validación que se insertan en los pasos de prueba de dos o más
casos de prueba manual.
Cómo: Compartir pasos de
casos de pruebas mediante
pasos compartidos
Cómo: Crear una copia de
pasos compartidos
Realice las pruebas con datos diferentes varias veces. Puede
agregar parámetros a los pasos compartidos para usarlos en los
casos de prueba en los que desee realizar la misma prueba con
datos diferentes varias veces.
Cómo: Agregar parámetros
a los pasos compartidos
Cómo: Agregar pasos a un
caso de prueba manual
desde un documento de
Microsoft Word o
Microsoft Excel
Acelerar los esfuerzos de prueba. Puede realizar las pruebas más
rápidamente si graba y reproduce los pasos repetidos de las pruebas
manuales.
Cómo: Crear una grabación
de acciones para pasos
compartidos
Ejecutar las pruebas manuales desde un plan de pruebas. Puede
ejecutar las pruebas manuales desde su plan de pruebas mediante
Ejecutor de pruebas para grabar la información que indica si cada
paso se ha pasado o ha producido errores. Puede guardar el
resultado de las pruebas y los datos que se recopilan al hacer la
prueba.
Ejecutar pruebas manuales
mediante el ejecutor de
pruebas
Cómo: Usar pasos
compartidos cuando se
ejecuta una prueba
Cierre los pasos compartidos que ya no se necesitan. Si tiene pasos
compartidos que no se usan, puede cambiar el estado de activo a
cerrado. Los pasos compartidos cerrados permanecen en el
proyecto de equipo pero solo aparecen en la lista de resultados para
las consultas que busquen específicamente los pasos compartidos
cerrados.
Cómo: Cambiar el estado
de los pasos compartidos a
cerrado
151
Permisos necesarios
Para ver los pasos compartidos, debe ser miembro del grupo de seguridad Readers o tener el permiso Ver los elementos de trabajo en este nodo establecido en Permitir. Para crear o modificar los pasos compartidos, debe ser miembro del grupo Contributors o tener los permisos Editar elementos de trabajo en este nodo establecidos en Permitir. Para obtener más información, vea Administrar permisos.
Referencia de campos
Para obtener más información sobre los campos de datos y controles que se proporcionan dentro del formulario de elemento de trabajo para los pasos compartidos, vea los temas siguientes:
Asignaciones y flujo de trabajo (Agile). Áreas e iteraciones. Planeamiento, clasificación y prioridades. Títulos, Identificadores, Descripciones e Historial (Agile). Pasos y datos de prueba. Datos adjuntos.
Flujo de trabajo de los pasos compartidos
Puede usar los estados Activo y Cerrado para distinguir los pasos compartidos que se utilizan de los que no se utilizan. Todos los pasos compartidos se crean en el estado Activo. Un elemento de trabajo de los pasos compartidos sólo es útil si se inserta en uno o más casos de prueba. Puede cambiar el estado a Cerrado cuando se cierren también todos los casos de prueba que contienen los pasos compartidos.
Después de guardar un elemento de trabajo de los pasos compartidos, puede cambiar su estado de activo a cerrado.
152
Progresión habitual del flujo de trabajo:
Un miembro del equipo crea un elemento de trabajo de los
pasos compartidos en el estado activo con el motivo
predeterminado, Nuevo.
Un miembro del equipo cambia el estado de un elemento de
trabajo de los pasos compartidos de activo a cerrado para
indicar que el elemento de trabajo ya no se usa en ningún
caso de prueba.
Estados de transición adicionales del flujo de trabajo:
Un miembro del equipo determina que el elemento de
trabajo de los pasos compartidos se debe reactivar y cambiar
su estado de cerrado a activo.
Diagrama de estado de los pasos
compartidos
Activo (Nuevo)
Los pasos compartidos siguen estando activos con tal de que no se cierren los casos de prueba en los que están insertados.
Los siguientes campos de datos se capturan automáticamente al crear los pasos compartidos:
Creado por: nombre del miembro del equipo que creó el elemento de trabajo.
Fecha de creación: fecha y hora en que se creó el elemento de trabajo registradas en el reloj del servidor.
153
De Activo a Cerrado
Puede cerrar un elemento de trabajo de los pasos compartidos activo debido a uno de los motivos siguientes:
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Obsoleto (valor
predeterminado)
Los pasos compartidos ya no son necesarios para
la prueba de aceptación de los casos de usuario.
Compruebe que todos los
casos de prueba que hacen
referencia a los pasos
compartidos están en el
estado Cerrado.
Aplazada Los pasos de prueba no se ejecutarán durante el
ciclo del producto o la iteración actual. También
puede especificar este motivo cuando los casos de
prueba en los que se insertan los pasos
compartidos están establecidos en Aplazado.
Ninguno.
Duplicado El elemento de trabajo de los pasos compartidos
es un duplicado de otro elemento de trabajo de
los pasos compartidos.
Cree un vínculo al elemento
de trabajo duplicado que
sigue estando activo.
Los siguientes campos de datos se capturan al cerrar un elemento de trabajo de los pasos compartidos:
Cerrado por: nombre del miembro del equipo que cerró el elemento de trabajo. Fecha de cierre: fecha y hora en que se cerró el elemento de trabajo registradas en el reloj del
servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
Cerrado
Puede reactivar un elemento de trabajo de los pasos compartidos.
154
De Cerrado a Activo
Al reactivar un elemento de trabajo de los pasos compartidos, el campo Motivo se establece automáticamente en Reactivado.
Motivo Cuándo utilizarla Acciones adicionales que se deben realizar
Reactivado Los pasos compartidos son
necesarios para admitir la
definición de un caso de prueba.
Revise todos los pasos de acción y validación para
asegurarse de que admiten los casos de prueba
donde están insertados los pasos compartidos.
Los siguientes campos de datos se capturan al reactivar un elemento de trabajo de los pasos compartidos:
Activado por: nombre del miembro del equipo que reactivó el elemento de trabajo. Fecha de activación: fecha y hora en que se reactivó el elemento de trabajo registradas en el reloj
del servidor. Fecha de cambio de estado: fecha y hora en que se cambió el estado del elemento de trabajo.
155
Crear y modificar áreas e iteraciones
Puede definir áreas e iteraciones para que un proyecto de equipo admita la agrupación de elementos de trabajo en categorías útiles, como hitos y características relacionadas. También puede controlar quién puede modificar los elementos de trabajo que están asignados a un área o iteración. Puede definir áreas para organizar elementos de trabajo en categorías lógicas, físicas o funcionales. Puede definir iteraciones para agrupar elementos de trabajo en hitos o ciclos.
Si asigna cada elemento de trabajo a un área y una iteración, puede generar rápidamente consultas e informes sobre el progreso del trabajo en determinadas áreas e iteraciones. Además, muchos de los artefactos que las plantillas de procesos de Microsoft Solutions Framework (MSF), Scrum o CMMI proporcionan usan iteraciones para organizar el trabajo y mostrar el progreso del equipo. Para obtener más información, vea Artefactos (Agile) y Artefactos (CMMI).
Nota
De forma predeterminada, los proyectos de equipo basados en plantillas de procesos de MSF tienen
tres nodos de iteración y ningún nodo de área. Para obtener más información acerca de cómo se
cambia la configuración predeterminada, vea Definir el área inicial y las rutas de acceso de iteración
mediante el archivo de complemento Classification.xml.
Una vez creado un proyecto de equipo, puede utilizar cualquier programa cliente para que Team Foundation personalice sus áreas o iteraciones. Para controlar el acceso a un área o iteración del proyecto, debe usar Team Explorer, Microsoft Excel o Microsoft Project.
156
Áreas e iteraciones
Permisos necesarios
Para realizar estos procedimientos, debe ser miembro del grupo Project Administrators, o bien los permisos Crear y ordenar nodos secundarios, Eliminar este nodo y Editar este nodo del nodo que desea modificar deben estar establecidos en Permitir. Para obtener más información, vea Permisos de Team Foundation Server.
157
Instrucciones para especificar áreas e iteraciones
Cuando especifique áreas e iteraciones en su proyecto de equipo, tenga en cuenta las siguientes directrices:
En el caso de las áreas Defina áreas que admitan sus requisitos de seguridad y rastreabilidad. Puede crear una
jerarquía de áreas bajo las que el equipo puede organizar todos los errores, tareas, requisitos y casos de usuario.
Utilice áreas para representar los componentes lógicos o físicos y, a continuación, cree áreas secundarias para representar características concretas. El equipo puede usar esta estructura para mantener organizados los elementos de trabajo y mejorar la rastreabilidad en función de un componente o una característica.
Establezca los permisos de las áreas para restringir el acceso a los elementos de trabajo asignados a determinadas categorías. Puede establecer opciones de seguridad que determinen no solo quién puede cambiar cada nodo de área, sino también quién puede editar, o incluso consultar, los elementos de trabajo de un área determinada. Para obtener más información, vea Restringir el acceso a los elementos de trabajo asignados a un área o iteración, más adelante en este mismo tema.
Evite crear una estructura de áreas que sea demasiado compleja. Puede crear áreas para repartir los permisos de los elementos de trabajo, pero los árboles complejos generan una elevada carga adicional en la administración de permisos. Puede resultar muy trabajoso tener que duplicar la estructura y los permisos de otros proyectos de equipo.
En el caso de las iteraciones Utilice las iteraciones para representar sprints, hitos o ciclos del proyecto. Determine la duración del ciclo para que se ajuste a los procesos del equipo y defina las
iteraciones para que admitan ese ciclo. Cree una iteración independiente para los elementos, los casos de usuario, los requisitos,
las tareas u otros elementos de trabajo que estén pendientes y sin asignar. Para obtener información general acerca de cómo puede planearse un sprint utilizando
iteraciones y la plantilla de procesos de MSF Agile Software Development v5.0, vea en esta guía “Scrum”.
Si está utilizando la plantilla de procesos de Visual Studio Scrum 1.0, deseará definir primero las iteraciones y luego los elementos de trabajo del sprint. Para obtener más información, vea en esta guía “Sprint”.
En el caso de las áreas y las iteraciones Al asignar un nombre a un área o iteración, siga las convenciones que se indican en
Convenciones y restricciones de nomenclatura de las áreas e iteraciones, más adelante en este mismo tema.
Los campos de iteración y área utilizan el tipo de datos TreePath. Cuando ejecuta una consulta para buscar elementos de trabajo asignados a un área o
iteración, los resultados siempre incluyen todos los elementos de trabajo que se definen en la ruta de acceso de dicha área o iteración. También puede crear consultas para buscar elementos de trabajo que no se encuentran bajo un nodo específico. Para obtener más información, vea Variables, valores, operadores y campos de las consultas y Buscar errores, tareas y otros elementos de trabajo.
158
Los nodos de iteración y área que ha creado en un proyecto de equipo no se pueden exportar para utilizarlos en otro proyecto de equipo.
Áreas
La estructura de áreas de producto se compila creando los nodos que representan los componentes y las características. Puede crear, por ejemplo, tres áreas en un proyecto de equipo denominado MiAplicación. Estas áreas representarían los tres componentes de desarrollo principales de una aplicación web estructurada en niveles: el sitio web, los servicios Web y la base de datos. Tal y como se muestra en la ilustración siguiente, puede crear un nodo bajo el nodo del proyecto de equipo para cada uno de estos componentes, que se denominan Mis sitios web, Mis servicios Web y Mi base de datos.
MiAplicación Mis sitios web Mis servicios Web Mi base de datos
Después de crear estas áreas, puede asignar los elementos de trabajo, como los errores, tareas o casos de usuario, a un área concreta y ejecutar una consulta para encontrar todos los elementos asignados a dicha área.
También puede organizar los componentes primarios en agrupaciones más específicas. Tal y como se muestra en el ejemplo siguiente, cada nodo superior contiene ahora dos o más nodos secundarios.
MiAplicación
Mis sitios web
Diseño
Navegación
Páginas
Inicio
Products
Recursos
Servicios
Compatibilidad
159
Mis servicios Web
Inicio de sesión
Cierre de sesión
Rendimiento
Seguridad
Mi base de datos
Desencadenadores de eventos
Rendimiento
Esquema
Seguridad
Iteraciones
De forma predeterminada, Iteración 1, Iteración 2 e Iteración 3 se definen en las plantillas de procesos de MSF. Algunos artefactos, sobre todo la consulta Trabajo pendiente de iteración y el libro Trabajo pendiente de iteración, usan estas iteraciones. Para obtener más información, vea “Consultas de equipo (Agile) y Libro de trabajo pendiente de iteración” en la guía “Informes y Libros Agile” en http://www.alightm.com.
Importante
Si elimina o modifica las iteraciones predefinidas, debe modificar los artefactos que hacen referencia a
ellas.
La estructura del ciclo de vida del proyecto se genera creando nodos que representan una jerarquía de eventos, tales como sprints, entregas de versiones beta o anteriores y otros hitos de la versión. En el ejemplo siguiente, Trabajo pendiente, Beta 1, Beta 2, Versión 1.0 y Versión 2.0 se definen en el proyecto de equipo MiAplicación. Puede asignar todos los elementos de trabajo a la iteración Trabajo pendiente si aún no se han programado para alguna tarea o versión.
160
MyApplication
Trabajo pendiente
Beta 1
Beta 2
Versión 1.0
Versión 2.0
A medida que cree el trabajo pendiente de las tareas y las características del producto, puede empezar a asignarlas a los hitos en los que espera que el equipo las complete. A medida que cambien sus necesidades, podrá agregar eventos bajo cada hito primario que reflejen el modo en que el equipo programa y administra el trabajo. Tal y como se muestra en el ejemplo siguiente, la iteración Beta 1 contiene ahora cinco nodos secundarios, uno por cada sprint del período Beta 1.
MiAplicación
Trabajo pendiente
Beta 1
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Beta 2
Versión 1.0
161
Versión 2.0
Las iteraciones no exigen la aplicación de ninguna regla. Por ejemplo, puede asignar una tarea a una iteración pero no puede cerrarla o completarla en el transcurso de esa iteración. Al final de una iteración, deben encontrarse todos los elementos de trabajo que permanecen activos o que no se han cerrado en esa iteración para llevar a cabo después la acción apropiada. Puede moverlos, por ejemplo, a una iteración diferente o devolverlos a Trabajo pendiente.
Restricciones de las rutas de acceso de las áreas y las
iteraciones
Los campos Área e Iteración son rutas de acceso compuestas de varios elementos de nodo separados por caracteres de barra diagonal inversa (\).En la tabla siguiente se describen las restricciones que rigen la definición de nodos y rutas de acceso.
Tipo de restricción Restricción
Longitud de nodo No debe contener más de 255 caracteres
Caracteres
especiales de los
nodos
No debe contener caracteres de control Unicode
No debe contener ninguno de los siguientes caracteres: \ / $ ?* : " & > < #
% | ,
No debe contener caracteres prohibidos por el sistema de archivos
local.Para obtener más información sobre las restricciones de caracteres de
Windows, vea el tema dedicado a nombres de archivos en el sitio web de
Microsoft.
Nombres
reservados
Debe contener más de un punto (.) o dos puntos (..)
No deben ser nombres reservados del sistema, como PRN, COM1, COM2,
COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM10, LPT1, LPT2,
LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, NUL, CON, or AUX
Para obtener más información sobre los nombres reservados, vea el tema
dedicado a nombres de archivos en el sitio web de Microsoft.
Longitud de la ruta
de acceso
Debe contener menos de 4.000 caracteres Unicode
162
Importante
Si define un nombre de ruta de acceso que tiene más de 256 caracteres, no
podrá especificarlo en Office Project. Para evitar este problema, defina
nombres de rutas de acceso que tengan menos de 10 caracteres y no anide
los nodos en más de 14 niveles de profundidad.
Profundidad de
jerarquía de la ruta
de acceso
Debe tener menos de 14 niveles de profundidad
Cambiar la estructura o las iteraciones del proyecto
mediante Team Web Access
Para modificar la estructura o las iteraciones del proyecto de equipo mediante Team Web
Access
1. En Team Web Access, en la lista Proyecto, haga clic en el proyecto en el que desea modificar áreas o iteraciones.
2. Siga uno de estos pasos: Para modificar las áreas, haga clic en Configuración, seleccione Proyecto de equipo y, a
continuación, haga clic en Áreas. Para modificar las iteraciones, haga clic en Configuración, seleccione Proyecto de equipo
y, a continuación, haga clic en Iteraciones. 3. Para agregar un nodo, siga estos pasos:
a. Haga clic en el nodo primario. b. En la barra de herramientas, haga clic en el botón Agregar nodo secundario. c. En el cuadro Nombre del nodo, escriba un nombre para el nuevo nodo y, a continuación, haga clic en Aceptar. Para cambiar el nombre de un nodo, siga estos pasos: . Haga clic en el nodo. a. En la barra de herramientas, haga clic en el botón Cambiar nombre. b. En el cuadro Nombre del nodo, escriba un nombre diferente para el nodo y, a continuación, haga clic en Aceptar. Para eliminar un nodo, siga estos pasos: . Haga clic en el nodo. a. En la barra de herramientas, haga clic en el botón Eliminar. b. En la lista Nueva ruta de acceso de referencia, haga clic en el nombre de un nodo que no tenga pensado eliminar y, a continuación, haga clic en Aceptar.
163
Los elementos de trabajo que se asignaron al nodo eliminado se asignan a la nueva ruta de acceso de referencia.
Cambiar las áreas o las iteraciones utilizando Team
Explorer, Microsoft Excel o Microsoft Project
Para modificar las áreas o las iteraciones utilizando Team Explorer, Microsoft Excel o
Microsoft Project
1. Conéctese al proyecto de equipo siguiendo uno de los siguientes pasos: En Team Explorer, haga clic en el proyecto de equipo para el que desea modificar áreas o
iteraciones. Para obtener instrucciones detalladas sobre cómo conectar al proyecto de equipo
mediante Microsoft Excel u Microsoft Project, vea Conectar documentos de Microsoft Office con Team Foundation Server.
2. Siga uno de estos pasos: En Team Explorer, en el menú Equipo, elija Configuración del proyecto de equipo y, a
continuación, haga clic en Áreas e iteraciones. En Microsoft Excel, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en
Editar áreas e iteraciones. En Microsoft Project, en el menú Equipo, haga clic en Editar áreas e iteraciones.
3. En el cuadro de diálogo Áreas e iteraciones, siga uno de estos pasos: Para modificar las áreas del proyecto de equipo, haga clic en la pestaña Área. Para modificar las iteraciones, haga clic en la pestaña Iteración.
Para agregar, quitar o modificar la estructura de nodo, haga clic en los botones de la siguiente ilustración:
4. Para agregar un nodo, siga estos pasos: a. Haga clic en el nodo primario. b. En la barra de herramientas, haga clic en el botón Agregar un nodo secundario. c. Especifique un nombre para el nuevo nodo y, a continuación, presione Entrar. Para cambiar el nombre de un nodo, siga estos pasos: . Haga clic con el botón secundario en el nodo y, a continuación, haga clic en Cambiar nombre.
164
a. Especifique un nombre distinto para el nodo y, a continuación, presione Entrar. Para eliminar un nodo, siga estos pasos: . Haga clic en el nodo que desea eliminar. a. En la barra de herramientas, haga clic en el botón Eliminar nodo.
Se abre el cuadro de diálogo Eliminar nodos.
b. En la lista Seleccione la nueva ruta de acceso de los elementos a los que se hace referencia, haga clic en el nombre de un nodo que no tenga pensado eliminar y haga clic en Aceptar.
Los elementos de trabajo que se asignaron al nodo eliminado se asignan a la nueva ruta de acceso.
Para promover un nodo, degradar un nodo o mover un nodo arriba o abajo en la lista, haga clic en el nodo y, a continuación, haga clic en el botón de la barra de herramientas adecuado. Haga clic en Cerrar.
Controlar el acceso a los elementos de trabajo
asignados a un área o iteración
Mediante la asignación de permisos, puede limitar el conjunto de acciones que los usuarios o grupos pueden realizar en los elementos de trabajo o planes de pruebas que están asignados a un área o iteración. También puede restringir o permitir que los usuarios o grupos administren la estructura del proyecto para un área o iteración.
Para controlar el acceso a un área o una iteración utilizando Team Explorer, Microsoft Excel
o Microsoft Project
1. Conéctese al proyecto de equipo siguiendo uno de estos pasos: En Team Explorer, haga clic en el proyecto de equipo en el que desea configurar los
permisos. Para obtener instrucciones detalladas sobre cómo conectar al proyecto de equipo
mediante Microsoft Excel u Microsoft Project, vea Conectar documentos de Microsoft Office con Team Foundation Server.
2. Siga uno de estos pasos: En Team Explorer, en el menú Equipo, elija Configuración del proyecto de equipo y, a
continuación, haga clic en Áreas e iteraciones. En Office Excel, en la pestaña Equipo, en el grupo Elementos de trabajo, haga clic en
Editar áreas e iteraciones. En Office Project, en el menú Equipo, haga clic en Editar áreas e iteraciones.
3. En el cuadro de diálogo Áreas e iteraciones, haga clic en el área o iteración cuyos permisos desea establecer y, a continuación, haga clic en Seguridad.
Tal y como se muestra en la siguiente ilustración, se abrirá el cuadro de diálogo Seguridad del proyecto:
165
Puede agregar usuarios o grupos y, a continuación, establecer los permisos Permitir o Denegar de cada usuario o grupo. En concreto, puede conceder o denegar permisos para administrar la estructura de un nodo, para ver o modificar los elementos de trabajo que están asignados a ese nodo y para administrar los planes de pruebas.
Para obtener más información, vea Cambiar los permisos de un grupo o usuario.
4. Cuando haya terminado de modificar los permisos, haga clic en Cerrar. A continuación, vuelva a hacer clic en Cerrar para cerrar el cuadro de diálogo Áreas e iteraciones.
166
Imprecisiones de dirección publicadas para valores de
resumen
Si ve que las horas se cuentan dos veces en informes que contienen horas de tarea, puede corregir el problema con el procedimiento de este tema. El panel Progreso y los informes Evolución y tasa de avance y Trabajo restante pueden mostrar un doble recuento de horas de trabajo.
Nota
Cuando se utiliza Microsoft Project para tareas primarias y secundarias, asigna a las tareas primarias las
horas acumuladas definidas para todas sus tareas secundarias. Las horas acumuladas no se publican en
Team Foundation, para que no se cuenten dos veces en ciertos informes. El atributo de archivo de
asignación de Microsoft Project IfSummaryRefreshOnly suprime la publicación en Team Foundation de
las horas asignadas a las tareas de resumen. Puede ver las horas acumuladas para las tareas de resumen
en Office Project pero no en Team Foundation. Para obtener más información, vea El archivo de
asignaciones de campo en Microsoft Project.
Cuando tanto las tareas de resumen como sus tareas secundarias contienen horas en los campos de esfuerzo, en esencia se tiene una doble contabilidad del nivel de esfuerzo de la tarea. Para solucionar estas imprecisiones, debe borrar los campos Estimación original (o Trabajo de línea base para los proyectos de equipo que se han actualizado), Trabajo restante y Trabajo completado para las tareas de resumen o primarias.
Permisos necesarios
Para realizar este procedimiento, debe ser miembro del grupo Contributors o establecer los permisos Ver los elementos de trabajo en este nodo y Editar elementos de trabajo en este nodo en Permitir.Para obtener más información, vea Permisos de Team Foundation Server.
Para borrar los campos de hora de las tareas primarias o de resumen
1. En Team Explorer, expanda el nodo Elementos de trabajo para su proyecto de equipo y busque la consulta de equipo Elementos de trabajo con valores de resumen.
Esta consulta se encuentra o en la carpeta Consultas del equipo o la carpeta Planeación y seguimiento bajo la carpeta Consultas del equipo.
2. Ejecute la consulta.
3. Seleccione (Contraer todo) para que solo aparezcan los elementos de trabajos primarios o de resumen en los resultados de la consulta.
4. Presione CTRL+A para resaltar los elementos de trabajo primarios enumerados.
167
5. Haga clic con el botón secundario en el área resaltada y, a continuación, haga clic en Abrir en Microsoft Excel.
Importante
Exporte los resultados de la consulta a Microsoft Excel con las filas contraídas. Este estado solo exporta
las tareas primarias o de resumen.
6. En el documento de Microsoft Excel, para las rutas de acceso de iteración y de área que está administrando, borre los valores de las siguientes tres columnas:
Estimación original Trabajo restante Trabajo completado
7. (Opcional) Guarde el archivo de Microsoft Excel.
Nota
Los elementos de trabajo de esta lista se basan en los identificadores de elementos de trabajo y no en
una consulta de elementos de trabajo. Para solucionar las imprecisiones que puedan producirse más
adelante, debe repetir los pasos 1 a 6.
8. En la pestaña Equipo, haga clic en Publicar.
Para obtener más información, vea Publicar elementos de trabajo en Office Excel.
9. Espere una hora o más para que el almacenamiento de datos registre los cambios.
La frecuencia de actualización predeterminada para el almacenamiento de datos es una hora. Para obtener más información, vea Cambiar una configuración que controla el procesamiento del almacenamiento de datos o el cubo de Analysis Services.
10. Compruebe que los cambios se han recogido viendo el panel Progreso u otro informe de trabajo.
168
Buscar elementos de trabajo para vincular o
importar
Puede seleccionar los elementos de trabajo de una lista para importarlos en un documento de Office Excel o Office Project o para vincularlo al elemento de trabajo actual. Puede usar uno de los siguientes métodos para crear una lista de elementos de trabajo:
Consulta guardada. Utilice este método cuando haya creado una consulta que sabe que contiene el conjunto o supraconjunto de elementos de trabajo que desea. Para obtener más información, vea Buscar errores, tareas y otros elementos de trabajo.
Identificadores de elementos de trabajo. Utilice este método cuando conozca los identificadores de los elementos de trabajo que desea buscar.
Búsqueda de título. Utilice este método para buscar elementos de trabajo que contengan una palabra o frase común en el campo de título del elemento de trabajo.
Permisos necesarios
Para agregar, modificar o quitar un vínculo entre los elementos de trabajo, o para importar elementos de trabajo a Office Excel u Office Project, debe tener permisos para ver ambos elementos de trabajo y modificar al menos uno de ellos. Debe ser miembro del grupo Contributors o tener los permisos Ver los elementos de trabajo en este nodo y Editar elementos de trabajo en este nodo establecidos en Permitir. Para obtener más información, vea Permisos de Team Foundation Server.
Para buscar los elementos de trabajo que desea vincular o importar
1. (Opcional) Si va buscar y hacer una lista de los elementos de trabajo que va a vincular utilizando una consulta guardada, debe definir la consulta que desea usar. Para obtener más información, vea Buscar errores, tareas y otros elementos de trabajo.
2. (Opcional para Team Explorer) Para vincular a un elemento de trabajo almacenado en otro proyecto de equipo, en la lista Proyecto, haga clic en el nombre de ese proyecto de equipo.
Nota
La lista Proyecto solo aparece al buscar los elementos de trabajo que se van a vincular al elemento de
trabajo actual.
3. Para buscar los elementos de trabajo utilizando una consulta guardada, siga estos pasos: a. Haga clic en Consulta guardada. b. (Solo Team Web Access) En la lista Consulta guardada expanda el proyecto de equipo. c. En la lista Consulta guardada, expanda Mis consultas o Consultas de equipo y, a
continuación, haga clic en el nombre de la consulta guardada cuyos resultados desea mostrar.
169
(Solo Team Explorer) También puede hacer clic en el botón Examinar situado junto a la lista Consulta guardada, seleccione una consulta guardada en el cuadro de diálogo Seleccionar consulta y, a continuación, haga clic en Aceptar.
Nota
El cuadro de diálogo Seleccionar consulta es más fácil de usar si su proyecto de
equipo contiene muchas consultas. Puede arrastrar una esquina del cuadro de diálogo
para mostrar más consultas guardadas.
4. Para especificar los identificadores de los elementos de trabajo, siga estos pasos: a. Haga clic en Identificadores. b. En el cuadro Identificadores, escriba los identificadores de los elementos de trabajo que
desea buscar.
Separe los identificadores con comas o espacios.
5. Para buscar elementos de trabajo que tienen texto común en sus títulos, siga estos pasos: a. Haga clic en El título contiene. b. En el cuadro El título contiene, escriba las palabras que desea buscar en el título de
elemento de trabajo. c. (Opcional para Team Explorer) En la lista y tipo, haga clic en el tipo de elemento de
trabajo que desea recuperar. d. (Opcional para Team Web Access) En la lista Tipo de elemento de trabajo, haga clic en
el proyecto de equipo y en el tipo de elemento de trabajo que desea recuperar.
Nota
Para minimizar el tiempo necesario para ejecutar la consulta, restrinja los criterios de
filtro de la búsqueda.
6. Haga clic en Buscar.
Solo se muestran los elementos de trabajo definidos para el proyecto de equipo seleccionado y el tipo de elemento de trabajo especificado. Puede cambiar la presentación de los elementos de trabajo de los que se hacen una lista mediante uno de los controles de interfaz de usuario siguientes:
Para expandir o contraer una lista de vista de árbol, haga clic en los signos + o -. Para cambiar el tamaño de una columna, apunte con el cursor al borde de un encabezado
de columna y arrástrelo hacia una nueva ubicación.
170
Para ordenar por un campo de columna, haga clic en el título de la columna. Para mover un campo de columna, haga clic en el título de la columna y arrástrelo a otra
ubicación.
Para obtener controles adicionales, vea Accesos directos del teclado para el editor de consultas y la vista de resultados de la consulta.
En la lista de elementos de trabajo devueltos, siga estos pasos: En Team Web Access, especifique cada uno de los elementos de trabajo que desee
activando o desactivando la casilla situada junto a él. Puede hacer clic en Seleccionar todo para seleccionar todos los elementos de trabajo mostrados.
Para Team Explorer, seleccione cada elemento de trabajo que se debería vincular al elemento de trabajo actual. También puede presionar la tecla MAYÚS mientras hace clic para seleccionar un intervalo de elementos de trabajo o presionar la tecla CTRL mientras hace clic para seleccionar varios elementos de trabajo.
(Opcional para Team Web Access) Escriba una descripción en el cuadro de diálogo Comentario. Haga clic en Aceptar.
171
Títulos, Identificadores, Descripciones e Historial
Utilice los campos Título e Id para identificar de manera única los elementos de trabajo en una lista. Utilice los campos Descripción e Historial para proporcionar información adicional que se necesita para implementar el elemento de trabajo y para realizar el seguimiento de los cambios que se realizan en el elemento de trabajo.
Una vez creado un elemento de trabajo, puede modificar cada uno de estos campos excepto Id. Al crear y guardar un elemento de trabajo, Team Foundation asigna el identificador, que no se puede cambiar.
Los campos Título, Id., Descripción e Historial se utilizan para realizar el seguimiento de la información y los cambios para todos los tipos de elemento de trabajo proporcionados con la plantilla de proceso.
Campos que aparecen en formularios de elemento de trabajo
En la siguiente tabla se describen los campos que se utilizan para realizar el seguimiento de información detallada y las revisiones históricas realizadas para un elemento de trabajo. Para obtener información sobre los tipos de datos y los atributos de campo predeterminados, vea Trabajar con campos de elementos de trabajo.
Nombre de campo
Descripción Nombre de
referencia
Tipo de
datos
Valor
predeterminado
del atributo de
tipo reportable
Valor
predeterminado
del atributo de
índice
ID Identificador único
que se asigna a un
elemento de
trabajo. Los
identificadores de
los elementos de
trabajo son únicos
en todos los
proyectos de equipo
y los elementos de
trabajo definidos en
una colección de
proyectos.
System.Id Integer Dimensión True
172
Título Una descripción
corta que resume lo
que es el elemento
de trabajo y ayuda a
los usuarios a
distinguirlo de otros
elementos de
trabajo en una lista.
System.Title String Dimensión True
Descripción Descripción larga de
un elemento de
trabajo. Este campo
proporciona más
detalles que el título
sobre el elemento
de trabajo.
System.Description PlainText Ninguno False
Historial El registro de
cambios que se
realizaron en el
elemento de trabajo
una vez creado.
Cada vez que se
actualiza el
elemento de
trabajo, se anexa
información al
historial, que
especifica la fecha
del cambio, quién
realizó las
modificaciones y
qué campos se
System.History Historial Ninguno False
173
modificaron.
También puede
agregar texto con
formato al campo
de historial.
Campos que admiten el seguimiento de la revisión
Puede utilizar los campos de la tabla siguiente para filtrar consultas y crear informes. Estos campos se actualizan con información cada vez que se modifica un elemento de trabajo. Estos campos no aparecen en el formulario de elemento de trabajo, pero se someten a seguimiento para todos los tipos de elementos de trabajo.
Nombre de campo
Descripción Nombre de referencia
Tipo de datos
Valor predeterminado del atributo de tipo reportable
Valor predeterminado del atributo de índice
Modificado
por
Nombre del
miembro del
equipo que
modificó el
elemento de
trabajo por
última vez.
System.ChangedBy String Dimensión True
Fecha de
modificación
Fecha y hora
de la última vez
que se
modificó el
elemento de
trabajo.
System.RevisedDate DateTime Ninguno False
Rev Número que System.Rev Integer Dimensión False
174
está asignado a
la revisión
histórica de un
elemento de
trabajo.
Campos adicionales que admiten la realización de consultas e
informes
Puede utilizar los campos de la tabla siguiente para filtrar consultas y crear informes. Los campos siguientes no aparecen en los formularios de elemento de trabajo, pero se someten a seguimiento para todos los tipos de elementos de trabajo.
Nombre de campo
Descripción Nombre de referencia Tipo de datos
Valor predeterminado del atributo de tipo reportable
Valor predeterminado del atributo de índice
Nombre
de nodo
Nombre del nodo
primario al que
pertenece este
elemento de
trabajo.El valor
para este campo
es el mismo que el
proyecto de
equipo.
System.NodeName String Ninguno False
Proyecto
de equipo
Proyecto de
equipo al que
pertenece este
elemento de
trabajo.
System.TeamProject String Dimensión False
175
Tipo de
elemento
de trabajo
Nombre del tipo
de elemento de
trabajo.
System.WorkItemType String Dimensión True
![Scrum [Reparado]](https://static.fdocumento.com/doc/165x107/55cf863a550346484b9577aa/scrum-reparado.jpg)
