Proceso Scrum: desde los elementos de la cartera de pedidos del producto hasta el incremento del producto que se puede enviar

Table of Contents hide

El objetivo del trabajo diario de un sprint es crear un incremento de producto que se pueda enviar para el producto en una forma que se pueda entregar a un cliente o usuario.

Dentro del contexto de un solo sprint, un incremento de producto o incremento entregable significa que un producto de trabajo ha sido desarrollado, integrado, probado y documentado de acuerdo con la definición del proyecto de hecho y se considera listo para su lanzamiento.

El equipo de desarrollo puede o no lanzar ese producto al final del sprint; el tiempo de lanzamiento depende del plan de lanzamiento. El proyecto puede requerir varios sprints antes de que el producto contenga el conjunto de productos mínimos comercializables (MMP) necesarios para justificar un lanzamiento al mercado.

Para crear una funcionalidad entregable, el equipo de desarrollo y el propietario del producto participan en tres actividades principales:

elaborando

En un proyecto ágil, la elaboración es el proceso de determinar los detalles de la característica de un producto. Cada vez que el equipo de desarrollo aborda una nueva historia de usuario, la elaboración garantiza que cualquier pregunta sin respuesta sobre una historia de usuario sea respondida para que el proceso de desarrollo pueda continuar.

El propietario del producto trabaja con el equipo de desarrollo para elaborar historias de usuario, pero el equipo de desarrollo debe tener la última palabra en las decisiones de diseño. El propietario del producto debe estar disponible para consultas si el equipo de desarrollo necesita más aclaraciones sobre los requisitos a lo largo del día.

Desarrollando

Durante el desarrollo del producto, la mayor parte de la actividad, naturalmente, recae en el equipo de desarrollo. El propietario del producto continúa trabajando con el equipo de desarrollo según sea necesario para proporcionar aclaraciones y aprobar la funcionalidad desarrollada. Durante el Sprint, los miembros del equipo:

Empareje a los miembros del equipo de desarrollo para completar las tareas. Si lo hace, mejora la calidad del trabajo y fomenta el intercambio de habilidades.
Siga los estándares de diseño acordados por el equipo de desarrollo. Si no puede seguirlos por cualquier motivo, revise estos estándares y mejórelos.
Inicie el desarrollo configurando pruebas automatizadas. Puede encontrar más información sobre las pruebas automatizadas en la siguiente sección y en el Capítulo 15. Si aparecen características nuevas y agradables durante el desarrollo, agréguelas a la cartera de productos. Evite codificar nuevas funciones que estén fuera del objetivo del sprint.
Integre los cambios que se codificaron durante el día, un conjunto a la vez. Prueba de 100 por ciento de corrección. Integrar cambios al menos una vez al día; algunos equipos se integran muchas veces al día. Realice revisiones de código para asegurarse de que el código sigue los estándares de desarrollo. Identificar las áreas que necesitan revisión. Agregue las revisiones como tareas en el backlog del sprint.
Cree documentación técnica mientras trabaja. No espere hasta el final del sprint o, peor aún, el final del sprint antes de un lanzamiento.

Verificando

La verificación del trabajo realizado en un sprint tiene tres partes: pruebas automatizadas, revisión por pares y revisión del propietario del producto. El equipo puede realizar:

Pruebas automatizadas

La prueba automatizada significa usar un programa de computadora para hacer la mayoría de las pruebas de código por usted. Con las pruebas automatizadas, el equipo de desarrollo puede desarrollar y probar el código rápidamente, lo que es un gran beneficio para los proyectos ágiles. A menudo, los equipos de proyectos ágiles codifican durante el día y dejan que las pruebas se ejecuten durante la noche. Por la mañana, el equipo del proyecto puede revisar el informe de defectos que generó el programa de prueba, informar sobre cualquier problema durante el scrum diario y corregir esos problemas inmediatamente durante el día.

Las pruebas automatizadas pueden incluir lo siguiente: Pruebas unitarias: Probar el código fuente en sus partes más pequeñas: el nivel del componente.
Pruebas del sistema: prueba del código con el resto del sistema
Pruebas estáticas: verificación de que el código del producto cumple con los estándares basados en reglas y mejores prácticas que el equipo de desarrollo ha acordado.

revisión por pares

La revisión por pares simplemente significa que los miembros del equipo de desarrollo revisan el código de los demás.

Revisión del propietario del producto

Cuando se ha desarrollado y probado una historia de usuario, el equipo de desarrollo mueve las historias a la columna Aceptar en el tablero de tareas. Luego, el propietario del producto revisa la funcionalidad y verifica que cumpla con los objetivos de la historia de usuario, según los criterios de aceptación de la historia de usuario. El propietario del producto verifica las historias de los usuarios a lo largo de cada día.

Resumen

El equipo de desarrollo informa sobre el progreso de la tarea actualizando el sprint backlog con qué tareas se completaron y cuánto trabajo, en horas, queda por hacer en las nuevas tareas iniciadas. Según el software que utilice el equipo de scrum, los datos de acumulación de sprint también pueden actualizar automáticamente el gráfico de trabajo pendiente de sprint.

Otros artículos de Scrum

Desarrollando

Verificando

Pruebas automatizadas

Resumen

Dejar una contestacion Cancelar la respuesta