TaskReviewProcess
Universidad de Sevilla
Escuela Técnica Superior de Ingeniería Informática
Sprint 1
BanquetBuddy
Procedimiento de revisión de tareas
Grado en Ingeniería Informática – Ingeniería del Software
Ingeniería del Software y Práctica Profesional
Curso 2023 – 2024
| Fecha | Versión |
|---|---|
| 29/02/2024 | 1.0 |
| --- | --- |
| Grupo de prácticas: 8 |
|---|
| Alberto Benitez Morales |
| --- |
| Álvaro Carrera Bernal |
| --- |
| Álvaro Navarro Rivera |
| --- |
| Álvaro Jose Sanchez Flores |
| --- |
| Artemio Rodriguez Asensio |
| --- |
| Eduardo de Bustamante Lucena |
| --- |
| Fernando Barroso Barroso |
| --- |
| Francisco Jose Vargas Castro |
| --- |
| Gonzalo Santigo Martín |
| --- |
| Guillermo Alonso Pacheco Rodrigues |
| --- |
| Jaime Caballero Hernandez |
| --- |
| Javier Nunes Ruiz |
| --- |
| Javier Rodríguez Cordero |
| --- |
| Juan Martínez Cano |
| --- |
| Marco Antonio Roca Rodríguez |
| --- |
| Mario Sanchez Naranjo |
| --- |
| Pablo Martínez Valladares |
| --- |
Control de Versiones
| Fecha | Versión | Descripción |
|---|---|---|
| 29/02/2024 | 1.0 | Creación del documento |
| --- | --- | --- |
Introducción
El proceso de revisión de tareas en un proyecto de desarrollo de software es un componente crítico para garantizar la calidad del producto final. Esta fase de revisión no solo implica la detección de errores y fallos, sino también la validación de requisitos, la coherencia con el diseño y la evaluación de la eficiencia y la efectividad de las soluciones propuestas. Este documento establece los procedimientos y las pautas a seguir para llevar a cabo una revisión exhaustiva y sistemática de las tareas asignadas, con el objetivo de mejorar la calidad del software desarrollado y garantizar la satisfacción del cliente.
Roles y responsabilidades
Para llevar a cabo la realización de las tareas definimos los siguientes roles:
- Revisor: El revisor es responsable de evaluar la tarea en función de los criterios de evaluación establecidos.
- Autor: El autor es responsable de realizar las modificaciones sugeridas por el revisor y de entregar la tarea finalizada.
Para realizar las revisiones se han definido las siguientes parejas de revisión en función de los subgrupos.
- El subgrupo 1 será el encargado de revisar las tareas del subgrupo 4 y viceversa.
- El subgrupo 2 será el encargado de revisar las tareas del subgrupo 3 y viceversa.
Procedimiento de revisión
El procedimiento a seguir para realizar la revisión de las tareas es el siguiente:
- Planificación de la revisión: Antes de comenzar la revisión, se establece un calendario detallado que incluye las fechas límite para la entrega de las tareas a revisar y los plazos para completar la revisión.
- Abrir una solicitud de pull request: Una vez que se hayan completado los cambios, se creará una pull request con los cambios realizados. En dicha pull request se proporcionará una descripción clara y concisa de los cambios que se realicen, así como cualquier información relevante para que los revisores comprendan el contexto del trabajo realizado.
- Asignar revisores: Los integrantes del subgrupo correspondiente encargados de realizar la revisión dejarán claro en la pull request qué miembro del subgrupo es el encargado de realizar la revisión.
- Revisión del código: El/Los revisor/es examinarán tu código, probando su funcionamiento de forma práctica, y proporcionarán comentarios y sugerencias para mejorarlo. Pueden hacer preguntas, señalar posibles problemas o sugerir formas de optimizar tu código.
- Es de obligatorio cumplimiento probar de manera local las características implementadas.
- Los revisores deberán añadir los comentarios de la revisión en la misma solicitud de pull request, siendo este el principal método de comunicación entre revisor y autor.
- Realizar cambios adicionales: Si los revisores solicitan cambios adicionales, el autor de la tarea será el encargado de recoger el feedback y realizar los cambios solicitados.
- Completar la solicitud de pull request: Una vez que todos los comentarios hayan sido abordados y los revisores estén satisfechos con los cambios, la pull request puede ser aprobada y fusionada en la rama principal del repositorio.
Ejemplos prácticos
A continuación mostraremos como NO hay que realizar la revisión de una pull request.
Un comentario simple no aporta información al autor de la tarea, qué aspectos se han revisado, aprobado o si se necesitan realizar cambios adicionales.
Un buen mensaje asociado a la pull request deberá seguir un aspecto parecido a este:
