Procesos Clave en el Desarrollo Ágil con Scrum
Al iniciar un Sprint, se lleva a cabo la Sprint Planning Meeting, que consta de dos reuniones:
1. Reunión de Planificación del Sprint (Parte 1)
- Durante esta reunión, se discute qué se va a hacer y lo que desea el Product Owner (PO). El Product Owner y el equipo se reúnen para discutir, revisar y refinar el Product Backlog, incluyendo historias de usuario y criterios de aceptación.
- Están presentes el PO, el equipo de desarrollo y el Scrum Master.
2. Reunión de Planificación del Sprint (Parte 2)
- En esta reunión, el equipo define la planificación detallada de tareas, mediante la obtención de información adicional, diseño de pantallas, cambios en el modelo de datos, desarrollo de las partes entregables, pruebas, etc. En esta reunión se deciden los elementos para el Sprint Backlog en base a las estimaciones finales de cada uno.
Durante el Sprint, se realiza diariamente un Daily Stand-up Meeting (o Daily Scrum), donde el equipo se reúne para tratar lo que se va a hacer durante el día.
Al finalizar el Sprint, se realizan la Sprint Review y la Sprint Retrospective, además de una actualización:
1. Sprint Review
- Durante esta reunión, se presenta el producto al Product Owner, se revisa el Sprint y hay una conversación entre el PO y el equipo.
2. Sprint Retrospective
- El equipo realiza una retrospectiva sobre el Sprint, tratando de buscar posibles mejoras en el proceso.
3. Actualización del Backlog
- Se actualiza el Sprint Backlog y la gráfica de trabajo restante de todo el producto.
Optimización del Backlog: Backlog Refinement
Para facilitar la planificación de Sprints posteriores, se realiza el Backlog Refinement (anteriormente conocido como Backlog Grooming). Esto consiste en:
- Analizar los requisitos.
- Separar elementos grandes en elementos más pequeños.
- Estimar nuevos elementos.
- Reestimación de elementos ya existentes.
Buenas Prácticas Ágiles
Son consideradas buenas prácticas ágiles:
- Adaptarse a los cambios.
- Realizar microincrementos con versiones funcionales cada pocas semanas.
- Interactuar frecuentemente con el cliente.
- Realizar pruebas continuas.
Ingeniería de Requisitos de Software
Características Principales de los Requisitos
- Identificable: Debe tener un identificador único.
- Singular: Deben especificar una idea o propiedad del sistema.
- Inéquivoco: Deben estar libres de ambigüedades.
- Trazable: Se debe poder identificar qué productos se obtienen a partir de un determinado requisito.
- Verificable: Deben poder comprobarse que el software satisface los requisitos.
Niveles de Requisitos
Existen varios niveles de requisitos:
- Requisitos de Usuario: Definen los requisitos para un sistema que pueda proporcionar los servicios requeridos por los clientes y las partes interesadas.
- Requisitos del Sistema: Transforman los requisitos de las partes interesadas de los servicios deseados en una vista técnica del producto que pueda ofrecer dichos servicios.
- Requisitos de Negocio: Se representan en términos de los objetivos de la organización.
Tipos de Requisitos
También hay distintos tipos de requisitos:
- Funcionales
- No Funcionales
- Restricciones
Representación de Requisitos: Métrica v3 y Scrum
Métrica v3
- Requisitos de Usuario (producto del EVS):
- Lista de requisitos.
- Requisitos del Sistema (producto del ASI):
- Escenarios + Casos de Uso (Estructura Jerárquica y Descripción detallada).
- Modelo de Dominio.
- Especificación UI.
Scrum
- Requisitos de Usuario:
- Lista de requisitos.
- O lista de Épicas.
- Requisitos del Sistema:
- Backlog: Historias de Usuario (HU) + Criterios de Aceptación (Backlog unidimensional).
- Modelo de Dominio.
- Prototipos.
Mapeo de Historias Bidimensional
- Columnas dedicadas a usuarios/procesos.
- Filas en las que se agrupan las historias por orden de prioridad, agrupadas en Sprints.
Proceso de Gestión de Requisitos
Para gestionar los requisitos, se suele seguir una serie de pasos:
- Elicitación: Consiste en identificar y obtener las necesidades de las partes interesadas (stakeholders).
- Análisis: Estudio detallado de las necesidades de los stakeholders en varios niveles de detalle y representación.
- Especificación: Consiste en la documentación de los requisitos.
- Validación: Revisión de los requisitos para comprobar que están bien escritos y satisfacen a la parte interesada.
Técnicas de Obtención de Requisitos
Los requisitos se pueden obtener de la siguiente manera:
- Escenarios (casos de uso).
- Prototipos.
- Reuniones.
- Observaciones in situ.
- Análisis de los sistemas existentes y de la información manejada.
- Entrevistas.
Las Entrevistas como Técnica de Elicitación
Las entrevistas son una técnica efectiva para obtener información del sistema actual, la organización de las unidades, las funciones de los roles de los usuarios y los requisitos del software.
Proceso de Entrevista
El proceso de entrevista se divide en tres fases:
- Preparación:
- Fijar objetivos.
- Documentarse e investigar.
- Hacer una lista de asistentes y enviarles el guion con los temas a discutir.
- Desarrollo:
- Apertura: Aspectos formales (presentaciones, etc.).
- Desarrollo: Preguntas abiertas, cuidar el vocabulario, repetir las respuestas dadas para confirmar.
- Cierre: Preguntas para ponderar la efectividad (¿Nos olvidamos algo?).
- Consolidación:
- Documentar los resultados en un acta.
- Enviar el acta a todos los participantes.
- Contrastar los resultados con entrevistas anteriores.
Pruebas de Software: Detección de Fallos y Calidad
Una prueba de software consiste en la ejecución de un programa con el fin de detectar fallos. Un buen caso de prueba es aquel que tiene altas probabilidades de detectar un nuevo fallo. Un caso de prueba exitoso es aquel que ha detectado un nuevo fallo.
Conceptos Clave en Pruebas
- Un error es aquel que proviene de un humano (ej. un error de codificación).
- Un fallo es la diferencia entre el comportamiento esperado de un programa y el observado.
- Un defecto es aquel que proviene de un desperfecto en un componente o del sistema.
Técnicas y Casos de Prueba
Las técnicas de prueba son procedimientos en los que se derivan casos de prueba para detectar fallos, cumpliendo con las limitaciones y costes.
Los casos de prueba son conjuntos de entradas, condiciones de ejecución y resultados esperados por los desarrolladores para un objetivo concreto. Un conjunto de estos es llamado test suite.
Las clases de equivalencia son un conjunto de datos para los cuales se espera un comportamiento similar.
Identificación de Clases de Equivalencia
Para identificar clases de equivalencia, se siguen estos pasos:
- Identificar las clases de entrada.
- Dividirlas en clases de equivalencia.
- Si hay razones para creer que estas clases no se tratarán de igual manera, se pueden dividir en clases más pequeñas.
- Se derivan los casos de prueba para cubrir las clases de equivalencia.
Las clases de equivalencia también se pueden combinar para crear una prueba más completa.
Calidad del Software y Aseguramiento
La calidad del software se puede definir como el grado en el cual un componente, producto o sistema satisface los requisitos especificados por un cliente/usuario.
Aseguramiento y Control de Calidad
- El aseguramiento de la calidad (QA) es un patrón sistemático y planificado de las actividades necesarias para ofrecer confianza en un producto que debe cumplir unos requisitos técnicos.
- El control de calidad (QC) es el conjunto de acciones necesarias para evaluar la calidad de un producto desarrollado. Es el proceso de verificar tu trabajo o el de otro.
Proceso para Asegurar la Calidad
Para asegurar la calidad, se sigue el siguiente proceso:
- Verificación y Validación: ¿Estamos construyendo el producto correcto y lo estamos construyendo correctamente?
- Pruebas: Comprobar la calidad y ofrecer confianza en el producto.
- Revisiones: Detección temprana de defectos en la calidad.
- Gestión de la Configuración: Asegurar la integridad del producto.
- Evaluación y Mejora del Proceso Software: Trabajar de manera sistemática y cada vez mejor.
Tipos de Revisiones de Software
Existen varios tipos de revisiones:
Revisiones Muy Formales (Inspección)
- Hay un equipo de inspectores que representan las diferentes perspectivas. El autor forma parte del equipo, además de otras partes interesadas.
Revisiones Más Informales
- Recorrido (Walkthrough): El autor expone su trabajo a una audiencia y solicita preguntas.
- Revisión por Pares (Peer Review): Se distribuye el trabajo a otras partes buscando discrepancias.
- Revisión Técnica: Similar a la revisión por pares, pero más formal.
Roles en las Revisiones
Suelen intervenir en las revisiones:
- Director
- Autor
- Moderador
- Secretario
- Revisor
Gestión de la Configuración de Software (SCM)
La Gestión de la Configuración de Software (SCM) consiste en un conjunto de actividades diseñadas para gestionar los cambios durante todo el ciclo de vida de un producto o servicio, con el objetivo de mantener su integridad, controlar los cambios y hacerlos visibles a todo el equipo.