Presentacion agil

433 views

Published on

  • Be the first to comment

  • Be the first to like this

Presentacion agil

  1. 1. UniversidadTecnológica delValle deToluca“METODOLO GÍA ÁGIL DEDESARROLLO DE SOFTWARE”Presentado por:Jaime Crisóstomo CuartoJorge Juárez OliveraMauricio Gutiérrez Solano
  2. 2. INDICE• Resumen• Objetivo• ¿Qué es?• ¿Quién la creo?• Historia• El ManifiestoÁgil• Certificaciones• Versiones• Descripción DetalladaComponentes• Características principales• Tabla de diferencias vs otro parecido• Ejemplo
  3. 3. Resumen• La metodología ágil ayuda a los equipos desarrollar software de manerarápida y flexible a los cambios que puedan surgir a lo largo del proyecto.• Ofrece una alternativa a los procesos de desarrollo de softwaretradicionales, caracterizados por ser rígidos y enfocados a ladocumentación.• Varias de las denominadas metodologías ágiles cada vez son más utilizadaspor los desarrolladores //ya estaban siendo utilizadas con éxitoen proyectos reales, pero les faltaba una mayor difusión y reconocimiento.
  4. 4. Objetivo• Describir las características fundamentales de la metodología ágil, suhistoria, y realizar un comparativo con otras metodologías de desarrollodel software, para ofrecer una visión completa acerca de sus aplicaciones ysu viabilidad en nuestro entorno profesional.
  5. 5. ¿Qué es?• Es una metodología de desarrollo de software alternativa a la gestióntradicional de proyectos de software.• Supone una mejora o innovación al modelo tradicional de cascada osecuencial.¿Quién la creo?• Surge formalmente en Febrero de 2001, con el “Manifiesto Ágil” (AgileManifiesto), redactado por 17 desarrolladores norteamericanos de softwaredestacados: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, AndrewHunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, entre otros.
  6. 6. Historia• En 1970, el Dr. Winston Royce presentó un documento titulado "Gestión deldesarrollo de sistemas de software grandes", que criticaba el desarrollosecuencial.• La definición evolucionó a mediados de 1990 como parte de una reaccióncontra los métodos tradicionales, demasiado rígidos y estructurados.• En el 2001 se adopto el nombre de “Metodología ágil” y luego nacería la“Alianza Ágil”
  7. 7. El Manifiesto Ágil• El individuo y las interacciones del equipo de desarrollo tienen mayor peso quelos procesos y las herramientas.• La colaboración con el cliente mas que la negociación de un contrato.• Ser flexibles antes los cambios mas que seguir estrictamente un plan.• Los responsables de negocio y los desarrolladores trabajan juntos de formacotidiana durante todo el proyecto.• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, esesencial.
  8. 8. CAPM® PMI-SP PMI-RMP PgMP® ITIL®V3NombreCertified Associatein ProjectManagementPMI SchedulingProfessionalPMI RiskManagementProfessionalProgramManagementProfesional.intermediate continual serviceimprovementRol de ProyectoContribuye aequipo deproyectoDesarrolla ymantienecalendario delproyectoEvalúa e identificalos riesgos, mitigalas amenazas yaprovecha lasoportunidades.Alcanza unobjetivo deorganización através de ladefinición ysupervisión deproyectos yrecursos.ITIL® consiste en una serie delibros que ofrecen unaorientación en la provisión deservicios de TI de calidad.Está basado en un conjunto deexperiencias de profesionalestanto del sectorpúblicocomo privado,alrededor del mundoCERTIFICACIONES
  9. 9. Características básicas de la metodología ágil• Incertidumbre: la dirección indica la necesidad estratégica que se deseacubrir• Equipos auto-organizados: no existen roles especializados• Autonomía: libertad para la toma de decisiones.• Auto-superación: de forma periódica se evalúa el producto que se estadesarrollando.• Auto-enriquecimiento: transferencia del conocimiento.• Fases de desarrollo solapadas: Las fases no existen como tal sino que sedesarrollan tareas/actividades
  10. 10. Metodología Acrónimo Creación Tipo de modelo CaracteristicaAdaptative SoftwareDevelopmentASD Highsmith 2000 Prácticas + ciclo de vida Inspirado en sistemas adaptativos complejosAgile Modeling AM Ambler 2002 Metodología basada en laprácticaSuministra modelado ágil a otros métodosCrystal Methods CM Cockbum 19998 Familia de metodologías Metodología ágil con énfasis en modelo deciclosAgile RUP dX Booch, Martin, Newkirk 1998 Framework/Disciplina XP dado vuelta conartefactos RUPDinamyc Solutions DeliveryModelDSDM Stapleton 1997 Framework/modelo deciclo de vidaCreado por 16 expertosen RADEvolutionary ProjectManagementEvo Gilb 1976 Framework adaptativo Primer método ágilexistenteExtreme Programming XP Beck 1999 Disciplina en prácticas deingenieríaMétodo ágil radicalFeature Solutions Delivery Model FDD De Luca & Coad 1998 Palmer&Felsing 2002Metodología Método ágil de diseño y construcciónLean Development LD Charette 2001, Mary yTomPoppenddieckForma de pensar – modelologísticoMetodología basada en procesos productivosMicrosoft Solutions Framework MSF Microsoft 1994 Survey de técnicas ymodelosSelección de best practices, no métodoRapid Development RAD McConnell 1996 Lineamientos, disciplinas,prácticasFramework de desarrollo de solucionesScrum Scrum Sutherland 1994-schwaber 1995 Proceso – framework demanagementComplemento de otros métodos, ágiles o noMetodologías Ágiles
  11. 11. Metodología Ágil MetodologíaTradicionalPocos Artefactos. El modelado es prescindible, modelosdesechables.Más Artefactos. El modelado es esencial, mantenimiento demodelosPocos Roles, más genéricos y flexibles Más Roles, más específicosNo existe un contrato tradicional, debe ser bastante flexible Existe un contrato prefijadoCliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediantereunionesOrientada a proyectos pequeños. Corta duración (o entregasfrecuentes), equipos pequeños (< 10 integrantes) y trabajando enel mismo sitioAplicables a proyectos de cualquier tamaño, pero suelen serespecialmente efectivas/usadas en proyectos grandes y conequipos posiblemente dispersosLa arquitectura se va definiendo y mejorando a lo largo delproyectoSe promueve que la arquitectura se defina tempranamente en elproyectoÉnfasis en los aspectos humanos: el individuo y el trabajo enequipoÉnfasis en la definición del proceso: roles, actividades y artefactosBasadas en heurísticas provenientes de prácticas de producciónde códigoBasadas en normas provenientes de estándares seguidos por elentorno de desarrolloSe esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto durante elproyectoTabla 2. Diferencias entre metodologías ágiles y no ágiles
  12. 12. RequerimientosDiseñoDesarrolloPruebasMantenimientoRequerimientosDiseñoDesarrolloPruebasMantenimientoRequerimientosDiseñoDesarrolloPruebasMantenimiento
  13. 13. MultifuncionalAuto-OrganizadoEnfocado en las entregasRepresenta los intereses del clienteExpertoTiene una visión clara del productoFacilitadorCoach del procesoRemueve obstáculosPila del ProductoProduct BacklogLista priorizada derequerimientosJunta de Planeación( 1- 2 hrs)Retrospectiva( 1- 2 hrs)Junta de Revisión( 1- 2 hrs)Reunión Diaria( 10-15 min)¿Qué hiciste ayer?¿Qué hay para hoy?¿Qué necesitas?Identificar oportunidadesde mejoraMostrar las nuevas características del incrementoRetroalimentación del equipoReasignar prioridades en el Product BacklogINCREMENTO
  14. 14. ID Orden Estimado Descripcíon CriterioValidación Observ1 10 30 Plataforma tecnológica Se tiene el diagrama de laarquitectura, validado porXXXXXLa arquitecturadebe permitirescalabilidad2 20 40 Prototipos Interfaz deusuarioTodas las pantallas deinterfaz están hechas y sepuede recorrer lafuncionalidadAplicable paralasfuncionalidadesde la pila a lafecha4 30 40 Diseño de datos Diagrama BD. Realizado.Validado por XXXXX
  15. 15. ¿Por qué utilizar metodologías ágiles?•Para reducir el tiempo de desarrollo: 45%•Para mejorar la calidad: 43%•Para reducir costes: 23%•Para alinear el desarrollo con los objetivos denegocio: 39%•Otras razones: 12%.
  16. 16. Conclusiones• Las metodologías ágiles presentan una propuesta de mejora para lasmetodologías secuenciales o tradicionales; sin embargo, no son aplicables atodos los proyectos, ya que dependen del tamaño de la organización
  17. 17. Bibliografía• Principios del Manifiesto Ágil. http://www.agilemanifesto.org/iso/es/principles.html• Project Management Institute. PMI® Agile Certification Integrated Services FrequentlyAsked Questions.• Cockbun, A. “Agile Software Development”. Addison-Wesley. 2001.• Abrahamsson, P., Salo, O., Ronkainen, J.,Warsta, J. “Agile software developmentmethods Review and analysis”.VTT Publications. 2002.• Martinez, Gustavo (2011). Coding, quality check and documentation (300%): Getthem from the same development team!.VPD.• West, D. Water-Scrum-Fall IsThe Reality Of Agile For Most OrganizationsToday.http://www.cohaa.org/content/sites/default/files/water-scrum-fall_0.pdf• Wikipedia. Agile Software Development.http://en.wikipedia.org/wiki/Agile_software_development

×