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                          ...
La importancia de los requisitos“The hardest single part of building a software system is decidingprecisely what to build....
Problemas típicos de la ingeniería de requisitos• El desarrollo y la gestión de los requisitos son un problema de  (versan...
Metodologías Ágiles• “Para triunfar el solo planteamiento (planificación) es insuficiente, es  necesario improvisar”      ...
Agile Manifesto                     http://agilemanifesto.org Estamos descubriendo formas mejores de desarrollar software ...
Agile Manifesto                     http://agilemanifesto.org Estamos descubriendo formas mejores de desarrollar software ...
SCRUM    8
SCRUM•   Scrum es una metodología ágil que nos permite centrarnos en crear aquello    que aporte más valor al negocio en e...
Requisitos en SCRUM• Software funcionando sobre documentación extensiva.• La documentación sigue siendo necesaria (así com...
User Stories•   Es una representación de un requisito de software escrito en una o dos    frases utilizando el lenguaje co...
Requisitos vs User Stories• Requisitos tradicionales (“shall” statements)   – The system shall provide a user configurable...
Casos de Uso vs User Stories• Mientras que un Caso de Uso esta fuertemente estructurado y  cuenta una “historia”, los User...
Resumen       “Software funcionando sobre documentación extensiva“• Los requisitos siguen siendo necesarios (¿Cómo sabremo...
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
Próxima SlideShare
Cargando en…5
×

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

414 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
414
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

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

  1. 1. Ingeniería de Requisitos enmetodologías de desarrollo ágiles ySCRUMJosé Manuel Muñoz
  2. 2. Agenda• Introducción• Metodologías Ágiles• Scrum• Requisitos en Scrum• Un ejemplo: Scrum en IRQA 2
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 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. 6
  7. 7. 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
  8. 8. SCRUM 8
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Scrum en IRQA 15
  16. 16. Scrum en IRQA – Product Backlog 16
  17. 17. Scrum en IRQA – CU y Pruebas 17
  18. 18. Scrum en IRQA – Sprint Backlog 18
  19. 19. Informes – Burn Down Chart 19
  20. 20. Informes – Burn Down Chart 20
  21. 21. Despedida y CierreGracias por su Atención 21
  22. 22. Despedida y Cierre 22

×