Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| ingenieria_de_requisitos:procesoir_ciclo_global [2023/11/27 10:26] – thejuanvisu | ingenieria_de_requisitos:procesoir_ciclo_global [2023/11/29 08:11] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 45: | Línea 45: | ||
| * Solamente se usa para entender ciertos procesos | * Solamente se usa para entender ciertos procesos | ||
| * Se usan historias de usuario | * Se usan historias de usuario | ||
| + | * Validación de requisitos | ||
| + | * Se usan reuniones de revisión | ||
| + | * Gestión de requisitos | ||
| + | * No hay trazabilidad total como el la tradicional | ||
| + | * Aquí se pueden dejar requisitos To Be Defined (TBD) | ||
| + | Las metodologías tradicionales se utilizan en proyectos críticos ya que ahí es imposible utilizar metodologías Agiles. En Agile las fases no están definidas y hay muy poca documentación, | ||
| + | ===== Scrum ===== | ||
| + | Es una metodología ágil " | ||
| + | ==== Roles de Scrum ==== | ||
| + | * Product Owner: el cliente | ||
| + | * Gestiona las necesidades que serán satisfechas por el proyecto | ||
| + | * Recoger y tener claras las necesidades de la aplicación | ||
| + | * Fijar criterios de aceptación para cada historia de usuario | ||
| + | * Equipo de desarrollo: los que desarrollan el proyecto | ||
| + | * Autoorganizado | ||
| + | * Multifuncional | ||
| + | * Autónomo | ||
| + | * Scrum Master: Se encarga de solucionar problemas en el sprint y de revisar que se cumplan los plazos | ||
| + | * Sería equivalente a un jefe de proyecto | ||
| + | * Soluciona todo lo que pasa, problemas, impedimentos, | ||
| + | * Actúa como mentor. | ||
| + | |||
| + | ==== Artefactos de Scrum ==== | ||
| + | |||
| + | * Historias de usuario: Similar a los requisitos, pero a más alto nivel | ||
| + | * Son requisitos ambiguos | ||
| + | * Descripciones breves de lo que quiere el cliente | ||
| + | * Ejemplo: " | ||
| + | * Product Backlog: Documento de especificación de requisitos | ||
| + | * Es como un documento de requisitos | ||
| + | * Recopila historias de usuario y las organiza por prioridad | ||
| + | * Puede crecer y decrecer, nunca va a estar completo. | ||
| + | * El product Owner prioriza con Moscow: <- **Importante** | ||
| + | * M (Must) | ||
| + | * S (Should) | ||
| + | * C (Could) | ||
| + | * W (Wont) | ||
| + | * Sprint Backlog: El Subconjunto de tareas que se realizarán en un sprint | ||
| + | * Tareas seleccionadas a realizar durante un sprint | ||
| + | * Se coge un subconjunto de tareas del Product Backlog. | ||
| + | * Las tarjetas tendrán puntos y el valor de las tarjetas tomadas no puede superar cierto valor para evitar sobresaturación. | ||
| + | |||
| + | ==== Eventos de Scrum ==== | ||
| + | |||
| + | * Sprint: período de tiempo en el que hay que hacer una entrega | ||
| + | * De 1 a 4 Semanas. | ||
| + | * El resultado será un producto de software potencialmente entregable (Prototipo operativo) | ||
| + | * Planificación del Sprint | ||
| + | * Primer día del sprint | ||
| + | * Product owner, Scrim Master y el equipo de desarrollo | ||
| + | * Reuniones de Sprint | ||
| + | * Daily meeting: | ||
| + | * No más de 15 minutos | ||
| + | * Scrum Master y Equipo de desarrollo | ||
| + | * Para solucionar problemas y ver como va el p´royecto | ||
| + | * Revisión del sprint | ||
| + | * No más de 4 horas | ||
| + | * Product Owner, Scrum Master y Equipo de desarrollo | ||
| + | * BurnDown Chart. | ||
| + | * Retrospectiva: | ||
| + | * Se reune todo el equipo para ver aspectos positivos y negativos del sprint. | ||
| + | * Product Owner y equipo de desarrollo. | ||
| + | |||
| + | ==== Scrum vs Requisitos ==== | ||
| + | * No hay planificación | ||
| + | * Requisitos poco completos, a alto nivel | ||
| + | * Las historias de usuario se considerarán algo similar a los requisitos. | ||