Desarrollo ágil de aplicaciones

1,700 views

Published on

Paradigma de construcción d

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,700
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
56
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Desarrollo ágil de aplicaciones

  1. 1. Curso Ambientes de Desarrollo Énfasis II en Ingeniería de Sistemas Telemáticos programa de Ingeniería Electrónica y Telecomunicaciones
  2. 2. Paradigma de construcción de soluciones basa en la construcción de códigoDesarrollo Ágil de Aplicaciones
  3. 3. ¿Qué es el desarrollo ágil de aplicaciones?•Es una iniciativa que agrupa una serie de metodologías(eXtreme Programming, SCRUM, Crystal, etc. ...)• Basadas en la adaptabilidad ante el cambio comomedio para aumentar las posibilidades de éxito de unproyecto.•En general los procesos ágiles se centran en laspersonas; en su comunicación directa y sus habilidadesen vez de procesos muy formales.
  4. 4. El Manifiesto ÁgilIndividuos e interacciones sobre Procesos y herramientasSoftware que funciona sobre Documentación exhaustivaColaboración con el cliente sobre Negociación de contratosResponder ante el cambio sobre Seguimiento de un plan Firmado en 2001 por Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert Martin, Ron Jeffries, otros…
  5. 5. XP: eXtreme Programming“La Programación Extrema (desarrollapor Kent Beck - DaimerChrysler) es unametodología de desarrollo de aplicacionesque se basa en la simplicidad, lacomunicación y la realimentación oreutilización del código desarrollado”.
  6. 6. Lo que dice Beck...“Todo en el software cambia. Los requisitoscambian. El diseño cambia. El negociocambia. La tecnología cambia. El equipocambia. Los miembros del equipo cambian.El problema no es el cambio en sí mismo,puesto que sabemos que el cambio va asuceder; el problema es la incapacidad deadaptarnos a dicho cambio cuando éste tienelugar.”
  7. 7. Las cuatro variables• XP hace de sus cuatro variables, elementosvisibles tanto a clientes, programadores yjefes de proyectos.• Se busca jugar con sus valores hasta que elalcance del proyecto tenga ] Costoun valor que satisfaga a todos. ] Tiempo ] Calidad ] Alcance
  8. 8. Los cinco valores• Los cinco valores de XP son esenciales paraque sus practicas tengan sentido y puedan serllevadas a cabo con éxito.• Deben ser parte integral de lafilosofía de un profesional ] Comunicacióndel desarrollo ágil. ] Coraje ] Simplicidad ] Realimentación ] Respeto
  9. 9. Roles principales en XPProgramador Director• Responsable de decisiones • Organiza y guía las técnicas reuniones• Responsable de construir el • Asegura condiciones adecuadas para el proyecto sistema• Sin distinción entre analistas, Cliente diseñadores o codificadores • Es parte del equipo • Determina qué construir y• En XP, los programadores cuándo diseñan, programan y realizan • Establece las pruebas las pruebas funcionales
  10. 10. Roles secundarios en XP Preparador - Coach • Responsable del procesoProbador - Tester • Tiende a estar en un• Ayuda al cliente con las segundo plano a medida pruebas funcionales que el equipo madura• Se asegura de que las pruebas funcionales se superan Controlador - Tracker • Métricas • Observa sin molestar • Conserva datos históricos
  11. 11. Proceso de Desarrollo
  12. 12. Proceso de Desarrollo
  13. 13. Captura de RequisitosHistorias de Usuarios: • Establecen los requisitos del cliente • Trozos de funcionalidad que aportan valor • Se les asignan tareas de programación con un número de horas de desarrollo • Las establece el cliente • Son la base para las pruebas funcionales
  14. 14. Ejemplo de historia de usuario
  15. 15. Planificación Planificación por entregas (releases) Se priorizan aquellas historias de usuario que el cliente selecciona porque son más importantes para el negocio Entregas: • Lo más pequeñas posibles • Se dividen en iteraciones de 2 o 3 semanas • Están compuestas por historias de usuario A cada programador se le asigna una tarea de la historia de usuario
  16. 16. Diseño Diseño simple La programación de tareas se realiza por parejas La pareja diseña, prueba, implementa e integra el código de la tarea Código dirigido por las pruebas Código modular, intentando refactorizar siempre que se pueda
  17. 17. Desarrollo Cliente siempre disponible Implementación Pruebas de Unidad Integración Implantación Pruebas de Aceptación
  18. 18. Principios básicosRetroalimentación a escala fina:• El principio de pruebas• Proceso de planificación• Cliente en el sitio• Programación por parejas
  19. 19. Principios básicosProceso continuo en lugar de por lotes:• Integración continua• Refactorización• Entregas pequeñas
  20. 20. Principios básicosEntendimiento compartido:• Diseño simple• Metáfora• Propiedad colectiva del código• Estándares de codificación
  21. 21. Principios básicosBienestar del programador:• La semana de 40 horas• Dedicación exclusiva
  22. 22. Mejores prácticas
  23. 23. Proceso de Desarrollo
  24. 24. Proceso de Desarrollo
  25. 25. Proceso de Desarrollo
  26. 26. Proceso de Desarrollo
  27. 27. Lectura para la casa
  28. 28. SCRUM• Es una metodología ágil de desarrollo de software. que permite centrarse en ofrecer el más alto valor de negocio en el menor tiempo.• Ken Schwaber y Jeff Sutherland fueron los precursores de este método demostrando ampliamente su uso en proyectos de gran envergadura con un alto número de personal• El negocio fija las prioridades y los equipos se auto- organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.
  29. 29. Características• Desarrollo de software por medio de iteraciones “Sprints" de 2 semanas a un 1 de duración• Los requisitos son capturados como elementos de una lista de “Product Backlog”• No hay prácticas de ingeniería prescritas• Indicado para proyectos con un rápido cambio de requerimientos.• Gran protagonismo de reuniones a lo largo del proyecto.• Colaboración estrecha con el cliente.
  30. 30. Sprints• “Sprints”- Periodo de tiempo (2-4 semanas) donde se llevan a cabo una serie de tareas previamente establecidas. ( Análogo a las iteraciones en XP)• No hay cambios en un sprint• El producto es diseñado, codificado y testeado durante el Sprint• Al iniciar cada Sprints, el equipo revisa el trabajo pendiente y selecciona la parte que terminará como un incremento de funcionalidad incorporado al software.• Al final del Sprint el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto.
  31. 31. Desarrollo secuencial vs. superpuestoRequisitos Diseño Código Test En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo
  32. 32. Scrum Framework Roles•Propietario del producto•SCRUM Master Reuniones•Equipo SCRUM •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
  33. 33. SCRUM Framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
  34. 34. Propietario del Producto• Representa a todos los interesados en el producto final Sus áreas de responsabilidad son: – Financiación del proyecto – Requisitos del sistema – Retorno de la inversión del proyecto – Lanzamiento del proyecto – Decide sobre las fechas y contenidos de los Releases – Prioriza funcionalidades de acuerdo al valor del mercado/negocio – Ajusta funcionalidades y prioridades en cada Sprint – Acepta o rechaza los resultados del trabajo del equipo
  35. 35. El SCRUM Master• Representa a la gestión del proyecto• Responsable de promover los valores y prácticas de Scrum• Remueve impedimentos• Se asegura de que el equipo sea completamente funcional y productivo• Permite la estrecha cooperación en todos los roles y funciones• Garantiza el cumplimiento de roles y responsabilidad
  36. 36. El Equipo S SCRUM• Los equipos son auto-organizativos• Responsable de transformar Sprint Backlog en un incremento de la funcionalidad del software. Típicamente de 5 a 9 personas• Multi-funcional y de tiempo completo: Programadores, testers, analistas, diseñadores, etc.• El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.• Solo puede haber cambio de integrantes entre los sprints
  37. 37. SCRUM Framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
  38. 38. Capacidad Reunion de planeación Sprintdel Equipo PriorizaciónProduct • Analizar y evaluar el Product Backlog ObjetivoBacklog • Seleccionar el objetivo del Sprint del SprintCondicionesdel Negocio Planificación • Decidir como alcanzar el objetivo del Sprint (diseño)Producto • Crear el Sprint Backlog (tareas) en SprintActual base a los temas del Product Backlog Backlog • Estimar Sprint Backlog en horas (1-16 horas)Tecnología
  39. 39. Reuniones diarias• Parámetros – Diaria – Dura 15 minutos – Parados• No para la solución de problemas – Todo el mundo está invitado – Sólo los miembros del equipo, Scrum Master y Propietario del Producto, pueden hablar – Ayuda a evitar otras reuniones innecesarias
  40. 40. Todos responden 3 preguntas 1 ¿Qué hiciste ayer? 2 ¿Qué vas a hacer hoy? 3 ¿Hay obstáculos en tu camino? • No es dar un reporte de estado al SCRUM Master • Se trata de compromisos delante de pares
  41. 41. Reunión de Revisión Sprint• El equipo presenta lo realizado durante el sprint• Normalmente adopta la forma de un demo de las nuevas características o la arquitectura subyacente• Informal• Regla de 2 hs preparación• No usar diapositivas• Todo el equipo participa• Se invita a todo el mundo
  42. 42. Reunión de retrospectiva Sprint• Periódicamente, se echa un vistazo a lo que funciona y lo que no, normalmente dura de 15 a 30 minutos• Se realiza luego de cada sprint• Todo el integrantes del proyecto participa Además de Posiblemente clientes y otros• Todos discutes lo que les gustaría: – Comenzar a hacer – Dejar de hacer – Continuar haciendo – Esto es sólo una de las muchas maneras de hacer una retrospectiva.
  43. 43. SCRUM framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
  44. 44. Backlog del ProductoListado con los requisitos del sistema • Es responsabilidad del dueño del producto • Contenido • Priorizacion inicial y al comienzo de cada Sprint • Disponibilidad • Es un documento dinámico que incorpora constantemente las necesidades del sistema • Idealmente cada tema tiene valor para el usuarios o el cliente • Se mantiene durante todo el proceso.
  45. 45. Ejemplo Backlog del Producto
  46. 46. Sprint Backlog• Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad.• Se recomienda que las tareas tengan una duración de 4 a 16 horas de trabajo. Las de mayor duración deben dividirse en sub-tareas de ese rango de tiempo.• Los individuos eligen las tareas.• La estimación del trabajo restante es actualizada diariamente• Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog
  47. 47. Ejemplo de Sprint BacklogTareas L M M J VCodificar UI 8 4 8Codificar negocio 16 12 10 4Testear negocio 8 16 16 11 8Escribir ayuda online 12Escribir la clase foo 8 8 8 8 8Agregar error logging 8 4
  48. 48. Gráfica de progresoTareas L Ma Mi J VCodificar UI 8 4 8Codificar Negocio 16 12 10 7Testear Negocio 8 16 16 11 8Escribir ayuda online 12 50 40 30 20 10Hours 0 L Ma Mi J V
  49. 49. Resumen SCRUM
  50. 50. SCRUM y XP• SCRUM se enfoca a practicas de organización y gestión• XP se centra en practicas de programación• Tratan de áreas diferentes pero se complementan.
  51. 51. ágil contra no ágil METODOLOGÍA ÁGIL METODOLOGÍA NO ÁGILPocos Artefactos Más ArtefactosPocos Roles Más RolesNo existe un contrato tradicional o al Existe un contrato prefijadomenos es bastante flexibleCliente es parte del equipo de desarrollo El cliente interactúa con el equipo de(además in-situ) desarrollo mediante reunionesGrupos pequeños (< 10 integrantes) y Grupos grandestrabajando en el mismo sitioMenos énfasis en la arquitectura La arquitectura es esencial
  52. 52. Referencias• www.mountaingoatsoftware.com/scrum• www.scrumalliance.org• www.controlchaos.com• scrumdevelopment@yahoogroups.com
  53. 53. ¿Preguntas?¿Observaciones?
  54. 54. Elaborando un mapa conceptual…
  55. 55. http://cmap.ihmc.us

×