• Save
Requisitos Riguros Vs User Stories en metodos ágiles
Upcoming SlideShare
Loading in...5
×
 

Requisitos Riguros Vs User Stories en metodos ágiles

on

  • 379 views

UPM, Juan Garbajosa

UPM, Juan Garbajosa

Statistics

Views

Total Views
379
Views on SlideShare
376
Embed Views
3

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 3

http://wildfire.gigya.com 3

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

Requisitos Riguros Vs User Stories en metodos ágiles Requisitos Riguros Vs User Stories en metodos ágiles Presentation Transcript

  • Pilar Rodríguez, Agustín Yagüe, Juan Garbajosa Universidad Politécnica de Madrid (UPM) Grupo de Tecnología de Software y Sistemas (SYST) https://syst.eui.upm.es http://www.upm.es Madrid, 20 de Junio 2008
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Algunas pistas de lo que sucede
    • Transformación de la economía industrial
    • Economía basada en el conocimiento y la información
    • Time-to-market se va reduciendo
    • La ventaja competitiva se encuentra en aumentar la productividad y disminuir el tiempo de reacción
    • En este entorno turbulento existe un alto grado de variabilidad en las necesidades del cliente.
    © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    Juan Garbajosa - UPM /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Fleeger 3 ed. Figure1.12 The key factors that have changed software development Time to market Shifts in economics Desktop computing Networking Object technology Problems with waterfall User interfaces CHANGES IN SOFTWARE ENGINEERING
  • Abordar el cambio © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • ¿se adaptan bien a las actuales necesidades de dinamismo y variabilidad del mercado? ¿Necesitamos alternativas? Metodologías convencionales © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Reflexionemos
    • " Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change "
    • (Kent Beck, 2004)
    Juan Garbajosa - UPM /25
    • "If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit. Great companies have both in measures appropriate to their goals and environment."
    • (Boehm, 2003)
    © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Requisitos convencionales
    • En la metodologías convencionales la especificación de requisitos se percibe como un fin dentro del desarrollo del proyecto
    • Centrada en habilidades de predicción en las primeras fases del desarrollo
    • Las metodologías convencionales actúan basadas en principios de estabilidad y control del contexto
    • Se pone mucho énfasis en...
    © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • /25 * Imagen basada en el estándar IEEE Std 1233, 1998 Edition ENTORNO CLIENTE COMUNIDAD TÉCNICA CLIENTE Identificar requisitos Necesidades FeedBack Técnico FeedBack Imposiciones / infuencias Requisitos Construir requisitos bien formados COLECCIÓN DE REQUISITOS REQUISITOS BIEN FORMADOS Organizar requisitos Presentar SyRS CLIENTE COMUNIDAD TÉCNICA Requisitos organizados © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Requisitos bien formados
    • Objetivo: obtener un documento de especificación de requisitos rigurosos
      • No ambiguo
      • Completo
      • Comprensible
      • Consistente
      • Realizable
    © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Importante pero ¿suficientemente valorado? /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM Comunicación cliente equipo e intraequipo
  • Requisitos convencionales
    • En este contexto el coste en tiempo y dinero para corregir un requisito equivocado al principio de proyecto aumenta drásticamente durante la implementación del producto
    • Se pretende reducir el coste eliminando cambios (utópico en el entorno actual)
    © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Un cambio de mentalidad
    • Extreme Programming Explained.
    • Kent Beck (2004)
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Valores
    • Los individuos y su interacción, por encima de los procesos y las herramientas.
    • El software que funciona, por encima de la documentación exhaustiva.
    • La colaboración con el cliente, por encima de la negociación contractual.
    • La respuesta al cambio, por encima del seguimiento de un plan.
    • The Agile Manifesto (2001)
  • /25 “ De la idea al producto en 6 meses” en un entorno global © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Juan Garbajosa - UPM /25 Producto Desarrollo Pre-game Realimentación User Stories Daily Scrum Meeting Sprint 2-4 semanas Review Retrospective Sprint N Backlog Sprint --- Backlog
  • Historias de usuario
    • Se utilizan en metodologías ágiles
    • Centrada en el cliente
    • Describir las características que el usuario espera que tenga el software que se va a desarrollar.
    • Guían la planificación del proyecto
    • No son requisitos, no son casos de uso, es más sencillo que todo eso: una o dos líneas que describen el trabajo que el equipo de desarrollo deberá producir
  • Una historia de usuario /25 - Usuario : Ingeniero de pruebas - Descripción : Monitorizar la velocidad del triturador - Motivación : Monitorizar el tanque de trituración © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Importante pero suficientemente valorado /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM Comunicación cliente equipo e intraequipo
  • Cliente, cliente…
    • Escritas en terminología del cliente
    • Insitu con el cliente
    • Alta comprensión del negocio del cliente
    • Requieren alta implicación del cliente en el proceso de desarrollo
    • Describen un resultado final que el cliente quiere, no detalles de implementación
  • Además
    • Nivel muy alto de control del cambio (CM)
    • Claramente verificables
    • Ingeniería de requisitos iterativa
    • Repriorización continua: basado en el valor
    • Proporcionan flexibilidad
    • Desarrollo dirigido por test
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • /25 Documentación para la Especificación de requisitos Interacción con el cliente e intraequipo Historias de Usuario Espíritu Agile © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM Requisitos Convencionales Historias de Usuario FINALIDAD: “Documentar de manera escrita las necesidades planteadas por el cliente” Contenidos en un documento formal de especificación de requisitos con valor contractual Contenidas en el formato que el equipo de desarrollo considere adecuado Representados principalmente desde la perspectiva de implementación del producto Representados desde la perspectiva del usuario Descritas en base a un lenguaje correcto, no ambiguo y, en la medida de lo posible, verificable (lenguaje técnico) Descritas en un lenguaje cercano al dominio de aplicación, aunque mejor si es no ambiguo; puede haber luego tests Centrado en habilidades de predicción Centrado en habilidades de reacción Necesidad de conocer el producto desde el principio de desarrollo Posibilidad de ir dando forma al producto a lo largo del desarrollo Requisitos perfectamente definidos para su implementación Descripción del resultado final
  • Juan Garbajosa - UPM /25
    • ¿Por qué User Stories?
      • Disminuyen el coste de realización del ERS
      • Centrado en funcionalidad
      • Reducen problemas de comunicación con el cliente
      • Mejor adaptación a cambios
      • Flexibilidad
    • Inconveniente
      • Vacío en el manejo de algunos tipos de requisitos (requisitos no funcionales)
      • Alta dependencia de la cualificación del equipo de desarrollo
      • Alta implicación del cliente (no siempre posible)
  • PFleeger 3 ed. Figure 14.1 Adopter types and the chasm between the early and mainstream markets (Rogers 1995 and Moore 1991).
  • Contenido
    • Introducción
    • Requisitos convencionales
    • Historias de usuario en metodologías ágiles
    • Requisitos convencionales frente a historias de usuario
    • Conclusiones
    /25 © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM
  • Conclusiones
    • Para abordar el cambio se necesitan nuevos enfoques
    • Vale la pena explorar las historias de usuario en el contexto de metodologías ágiles
    • No es conveniente quedarse sólo en técnicas
    • Hay que coger lo mejor de cada enfoque
    • Metodologías ágiles y CMMI: compañeros de ruta…¿Por qué no?
  • Juan Garbajosa - UPM /25
  • /25 Juan Garbajosa jgs at eui.upm.es © P. Rodriguez, A. Yagüe, Jgarbajosa Garbajosa - UPM ¡¡Gracias!!