• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
2012 The Requirements Week Visure Solutions Jose Manuel Muñoz Ingeniería de requisitos en metodologías de desarrollo ágiles
 

2012 The Requirements Week Visure Solutions Jose Manuel Muñoz Ingeniería de requisitos en metodologías de desarrollo ágiles

on

  • 353 views

 

Statistics

Views

Total Views
353
Views on SlideShare
353
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    2012 The Requirements Week Visure Solutions Jose Manuel Muñoz Ingeniería de requisitos en metodologías de desarrollo ágiles 2012 The Requirements Week Visure Solutions Jose Manuel Muñoz Ingeniería de requisitos en metodologías de desarrollo ágiles Presentation Transcript

    • Ingeniería de Requisitos enmetodologías de desarrollo ágiles ySCRUMJosé Manuel Muñoz
    • Agenda• Introducción• Metodologías Ágiles• Scrum• Requisitos en Scrum• Un ejemplo: Scrum en IRQA 2
    • La importancia de los requisitos“The hardest single part of building a software system is decidingprecisely what to build.No other part of the conceptual work is as difficult as establishing thedetailed technical requirements, including all the interfaces to people,machines, and other software systems.No other part of the work so cripples the resulting system if done wrong.No other part is more difficult to rectify later.” -Fredrick P. Brooks (1986), “No Silver Bullet – Essence and Accident in Software Engineering” Proceedings of the IFIP Tenth World Computing Conference: 1069-1076 3
    • Problemas típicos de la ingeniería de requisitos• El desarrollo y la gestión de los requisitos son un problema de (versan sobre) comunicación• Stakeholders y equipos de desarrollo no suelen tener un claro entendimiento de los requisitos conforme son escritos• La validación es tardía en el ciclo de vida• Los usuarios ven el producto en los últimos estadios del proyecto• Se tiende a “congelar” los requisitos demasiado pronto, lo que muchas veces termina en que no se construirá lo que la gente necesita, sino lo que inicialmente pensaban que querían “No tiene por qué cambiar, la supervivencia no es obligatoria” Edward Deming 4
    • Metodologías Ágiles• “Para triunfar el solo planteamiento (planificación) es insuficiente, es necesario improvisar” Isaac Asimov - Fundación• En el año 2001 un grupo de profesionales de la industria del SW deja de lado los modelos predictivos y adoptan los principios de agilidad identificados en la década de los 80 por Nonaka y Takeuchi (The New New Product Development Game, 1986) creando el llamado manifiesto Ágil (Agile Manifesto) 5
    • Agile Manifesto http://agilemanifesto.org Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. 6
    • Agile Manifesto http://agilemanifesto.org Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. 7
    • SCRUM 8
    • SCRUM• Scrum es una metodología ágil que nos permite centrarnos en crear aquello que aporte más valor al negocio en el mínimo tiempo posible.• Equipos auto-organizados: El cliente, los usuarios y/o las necesidades del negocio establece las prioridades. Los equipos se organizan para determinar la mejor manera de producir las funcionalidades de mayor prioridad.• Iterativo: Nos permite rápida y repetidamente inspeccionar el funcionamiento del software. Aproximadamente cada 2 semanas cualquiera puede ver el software funcionando y decidir liberarlo o continuar mejorándolo durante otro sprint.• Número reducido de artefactos: Los requisitos se capturan en el “product backlog”.• Comenzar más tarde: La ingeniería de requisitos no ocurre exclusivamente al inicio del proyecto sino que es un proceso continuo.• Número reducido de roles (product owner, scrum master, equipo). 9
    • Requisitos en SCRUM• Software funcionando sobre documentación extensiva.• La documentación sigue siendo necesaria (así como los requisitos)• En SCRUM los requisitos se representan por medio del “product backlog” y el “sprint backlog” – Product backlog: Una lista priorizada de funcionalidades con tiempos estimados para su implementación. Se sitúan en el dominio del problema Requisitos de Usuario – Sprint backlog: Lista de tareas definidas por el equipo para un sprint. Se sitúa en el dominio de la solución. Requisitos de Sistema. 10
    • User Stories• Es una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario• Se deben identificar el quién, el qué y el por qué. – Como (rol) quiero (algo) para poder (beneficio)• Los User Stories no son por tanto un conjunto de requisitos altamente documentados sino mas bien un recordatorio para colaborar sobre una funcionalidad (feature) concreta• Si bien generalmente recogen funcionalidad pueden también recoger elementos no funcionales – Como visitante de la página, quiero poder volver a la página de inicio rapida y facilmente. 11
    • Requisitos vs User Stories• Requisitos tradicionales (“shall” statements) – The system shall provide a user configurable interface for all user and system manager functions – The user interface shall be configurable in the areas of: ‒ Screen layout ‒ Font ‒ Background and text color• User Story correspondiente – Como un usuario del sistemas o administrador del sistema, – Quiero poder configurar la interfaz de usuario incluyendo el layout, la fuente, el color del fondo y el color del texto, – Para poder usar el sistema de la forma más cómoda posible 12
    • Casos de Uso vs User Stories• Mientras que un Caso de Uso esta fuertemente estructurado y cuenta una “historia”, los User Stories describen someramente una funcionalidad o una necesidad.• Un User Story podría considerarse como el preludio de un Caso de uso, enunciando la necesidad antes de que el caso de uso nos cuente una historia.• Los User Stories son muy útiles para recoger y priorizar las funcionalidades de alto nivel.• Las User Stories pueden evolucionar a casos de uso o requisitos una vez que se tenga más nivel de detalle 13
    • Resumen “Software funcionando sobre documentación extensiva“• Los requisitos siguen siendo necesarios (¿Cómo sabremos si no que tenemos que hacer?).• Generalmente recogidos en forma de User Stories en el Product Backlog.• Más enfocados a la comunicación.• Más dinámicos y cambiantes (aunque no durante el sprint).Y ahora… ¿Cómo podríamos dar soporte a Scrum en IRQA?... 14
    • Scrum en IRQA 15
    • Scrum en IRQA – Product Backlog 16
    • Scrum en IRQA – CU y Pruebas 17
    • Scrum en IRQA – Sprint Backlog 18
    • Informes – Burn Down Chart 19
    • Informes – Burn Down Chart 20
    • Despedida y CierreGracias por su Atención 21
    • Despedida y Cierre 22