Scrum

Scrum es un marco para ejecutar proyectos sobre la base de los principios y valores de Agile. 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. Para obtener información sobre los principios y valores de Agile en los que se basa Scrum, vea Principios y valores de Agile, por Jeff Sutherland.

MSF for Agile Software Development v5.0 está basado en Scrum. Por consiguiente, el equipo puede adoptar Scrum utilizando herramientas que se integran con las actividades de desarrollo básicas.

En este tema Preparar el proyecto Planear el proyecto Planear un sprint Ejecutar un sprint Realizar el seguimiento del proyecto

Preparar el proyecto

Antes de iniciar el proyecto, realice las siguientes tareas:

• establecer el caso comercial

• reunir un equipo

• preparar la infraestructura del equipo

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. Para obtener más información, vea Roles.

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 trabajo pendiente del producto y, si es necesario, un plan de lanzamiento.

Compilar el trabajo pendiente del producto

El trabajo pendiente del producto 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.

	Crear los casos de usuario: en su libro "User Stories Applied", Mike Cohn define los casos de usuario de esta manera: "Un caso de usuario describe la funcionalidad que tendrá valor para un usuario o comprador de software o de un sistema". Los casos de usuario se escriben desde el punto de vista del usuario final. Por ejemplo: "Como cliente habitual, deseo encontrar una comida que he pedido antes". Para obtener más información, vea Crear un trabajo pendiente de producto grande.
	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 Planning", Mike Cohn define los puntos de caso de esta manera: "Los puntos de caso son la unidad de medida para expresar el tamaño total de un caso de usuario, la característica u otro elemento de trabajo". Los puntos de caso son valores relativos que no se traducen directamente a 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.

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, esos datos se recopilarán a lo largo del proyecto. Para obtener más información, vea Informe de estado de todas las iteraciones.

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.

Establecer el plan de lanzamiento

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 trabajo pendiente del producto, 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 trabajo pendiente del producto a lo largo del proyecto.

Para obtener más información, vea Libro Planeación del producto.

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 trabajo pendiente del producto. Los casos de usuario cuya prioridad es lo suficientemente alta para ser considerados en el primer sprint deben estar listos que el equipo los implemente. El propietario del producto debe preparar el trabajo pendiente del producto 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 Preparar el siguiente sprint.

Planear un sprint

Cuando el equipo haya desarrollado el trabajo pendiente del producto y haya establecido un plan de lanzamiento, 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 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 Reunión de planeamiento de plazos.

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.

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.

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 Trabajo pendiente 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.

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, 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 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 Tarea (Agile).

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 problema o impedimentos que podrían afectar a otros miembros del equipo o necesitar su ayuda. Para obtener más información, vea 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 Error (Agile).

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 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 proporciona un conjunto de informes que los equipos pueden utilizar para realizar el seguimiento del progreso de un sprint.

Informe de evolución y tasa de avance (Agile)

Informe Indicadores de calidad de la compilación

Informe de progreso del plan de pruebas

Informe Progreso de los casos (Agile)

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.

Informe Estado del error

Informe Tendencias de errores

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 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 Reunión 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 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, modificarse y pensarse de menos 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 trabajo pendiente del producto. 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 Preparar 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 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 trabajo pendiente del producto se refinará con nuevos casos de usuario a medida que el proyecto progrese. Sin embargo, si el número total de casos del trabajo pendiente 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

Informe Información general sobre los casos (Agile)

Informe Progreso de los casos (Agile)

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.

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.

Vea también

Conceptos

Procedimientos de ingeniería

Elegir una plantilla de procesos

Planear y seguir proyectos

Otros recursos

MSF for Agile Software Development v5.0