SlideShare una empresa de Scribd logo
Maestría en Ingeniería de Sistemas con  Mención en Gestión En Tecnología de la Información Ingeniería de Software LIMA - 2007
Esta situación resulta conocida……???
Fuerzas que influyen en los enfoques para el desarrollo de software Grado de  Control  en el proceso Tiempo 1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s Fuente: Diapositiva obtenida de la presentación “ A History of Agile Methods” presentada por Alan Davis en JISBD 2002 Libertarios Fundamentalistas Tendencia global
Metodología Ágil
Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto. Metodología Ágil
El Manifiesto de la metodología Ágil: Al  individuo y las interacciones del equipo de desarrollo  sobre el proceso y las herramientas. Desarrollar software que funciona  más que conseguir una buena documentación. La colaboración con el cliente  más que la negociación de un contrato. Responder a los cambios  más que seguir estrictamente un plan. Es importante la derecha pero valoramos más la izquierda  Metodología Ágil
¿Qué es una Metodología Ágil? Las Metodologías Ágiles (MAs) valoran: Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas Desarrollar software que funciona más que conseguir una buena documentación    Minimalismo respecto del modelado y la documentación del sistema La colaboración con el cliente más que la negociación de un contrato  Responder a los cambios más que seguir  estrictamente una planificación
¿Por qué surgen las Metodologías Ágiles? Dificultades para implantar metodologías tradicionales. Procesos ceremoniosos, herramientas CASE y notaciones de modelado sofisticadas (UML) Una solución a medida para un segmento importante de proyectos de desarrollo de software Pugna entre comunidades/gurús “ Aceptar el cambio” ...
¿Cuándo utilizar una Metodología Ágil? ¿Tienes ya un proceso? No existe pero no reacciona bien a los cambios existe pero el equipo no está contento con él    Una Metodología Ágil puede ser una buena  forma de empezar No involucra gran inversión A los programadores les (suele) gustar A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto
Comparación Ágil v/s Tradicional Se espera que no ocurran cambios de gran impacto durante el proyecto Se esperan cambios durante el proyecto Énfasis en la definición del proceso: roles, actividades y artefactos Énfasis en los aspectos humanos: el individuo y el trabajo en equipo  Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos Orientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio Se promueve que la arquitectura se defina tempranamente en el proyecto  La arquitectura se va definiendo y mejorando a lo largo del proyecto El cliente interactúa con el equipo de desarrollo mediante reuniones Cliente es parte del equipo de desarrollo (además in-situ) Existe un contrato prefijado No existe un contrato tradicional, debe ser  bastante flexible Más Roles, más específicos  Pocos Roles, más genéricos y flexibles Más Artefactos. El modelado es esencial, mantenimiento de modelos Pocos Artefactos. El modelado es prescindible, modelos desechables. Metodología Tradicional Metodología Ágil
Costo de los Cambios en SW Cost o del   c ambio ti empo Tradicional Suposición MAs
Principales MAs Crystal Methodologies, Alistarir Cockburn,  www.crystalmethodologies.org SCRUM, Ken Schwaber & Jeff Sutherland,  www.controlchaos.com DSDM (Dynamic Systems Development Method),  www.dsdm.org Lean Programming, Mary Poppendieck,  www.poppendieck.com FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,  www.nebulon.com/fdd,  www.coad.com/peter/#fdd Extreme Programming, Kent Beck  www.extremeprogramming.org,  www.xprogramming.com Adaptative Software Development, Jim Highsmith  www.adaptivesd.com
Programación Extrema
Antecedentes e Historia de  Programación extrema
Sin embargo, se reconoce a Kent Beck como el que articuló esta propuesta y le dio nombre propio.  Kent Beck En 1989, Cunningham formó un equipo que usaba los principios y muchas de las prácticas que después adoptaría XP, mientras trabajaba para la compañía “Wyatt Software” [Fowler 2000]. Antecedentes e Historia de  Programación extrema
Posteriormente, la consolidación de XP se logra con la publicación del libro “Extreme Programming Explained: embrace change” en el año 1999, donde Beck resume su propia experiencia y le da forma y nombre a la entonces nueva metodología de desarrollo de software, la cual le valió el premio: “Software Development Jolt Product Excellence”.  Antecedentes e Historia de  Programación extrema
Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal. Antecedentes e Historia de  Programación extrema
Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que ésta le hizo el año 1999. En ésta decía que él estaba convencido que la mejor metodología era un proceso: Que enfatizase la comunicación del equipo. Que la implementación fuera sencilla. Que que el usuario tenía que estar muy informado e implicado. Que la toma de decisiones tenía que ser muy rápida y efectiva. Antecedentes e Historia de  Programación extrema
Los autores de la Programación Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación. Antecedentes e Historia de  Programación extrema Portland Pattern Repository
¿Qué es XP?
La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de prácticas que propician un aumento en la productividad a la hora de generar software. XP permite controlar los problemas de riesgo en los proyectos.  XP permite la participación de pequeños grupos de programadores.  XP requiere un variado equipo de desarrollo.  XP permite la capacidad de hacer pruebas  La meta real de XP es entregar el software requerido a tiempo.  ¿Que es XP?
Las características generales de XP es deliberadamente una metodología “liviana” que pasa por alto la utilización de elaborados casos de uso, la exhaustiva definición de requerimientos y la producción de una extensa documentación.  Todo lo anterior puede parecer caótico según el enfoque tradicional de la ingeniería de software, aunque no hay que olvidar que XP tiene asociado un ciclo de vida y es considerado a su vez un proceso.  La tendencia de entregar software en lapsos cada vez menores de tiempo y con exigencias de costos reducidos y altos estándares de calidad, hace que XP sea una opción a considerar.  Características de XP
Justificación y fundamentos de XP
Justificación y fundamentos de XP
Enfoque Tradicional vs. XP
Principios, roles y prácticas  de  Programación extrema
Principios de la Programación extrema Se busca : Realimentación rápida Asumir la simplicidad Cambio incremental Aceptar el cambio Hacer trabajo de calidad.
Principios de la Programación extrema Las Prácticas son: 1. El juego de la planificación 2. Pequeñas entregas 3. Metáfora 4. Diseño simple  5. Pruebas 6. Refactorización
Principios de la Programación extrema 7. Programación por parejas 8. Propiedad colectiva 9. Integración continua 10. 40 horas semanales  11. Cliente en casa 12. Estándares de codificación.
Objetivos de la  Programación extrema
Objetivos de XP Son: La satisfacción del cliente. Potenciar el trabajo en grupo, todos están involucrados en el desarrollo del software.
Interacción entre Las cuatro variables de Gestión de proyecto
El coste de Cambio El coste de los cambios crece con el tiempo. XP propone que los costes de los cambios no tienen por que aumentar con el tiempo.
Las cuatro valores Valores para desarrollar software:  Comunicación Sencillez Retroalimentación Valentía.
Roles de XP Cliente Escribe “Historias de Usuario” y especifica Pruebas Funcionales.  Establece prioridades, explica las Historias Puede ser o no un usuario final Tiene autoridad para decidir cuestiones relativas a las Historias. Programador Hace estimaciones sobre las Historias Define Tareas a partir de las Historias y hace estimaciones Implementa las Historias y las Pruebas Unitarias
Roles de XP Tutor Observa todo, identifica señales de peligro, se asegura que el proyecto se mantiene en curso Ayuda en todo Da avisos cuando se necesita. Perseguidor (calidad) Monitoriza el progreso de los programadores, toma acción si las cosas tienden a salirse de su senda. Las acciones incluyen reuniones con el Cliente, solicitar ayuda al Tutor u otro Programador.
Roles de XP Verificador Implementa y corre las Pruebas Funcionales (no Pruebas Unitarias) Presenta gráficas de los resultados y se asegura de que la gente conoce cuándo los resultados empiezan a decaer. “ Agorero” Se asegura que todos conocen los riesgos que existen  Se asegura que las malas noticias no se ocultan, se disculpan o se reducen de proporción.
Roles de XP Gestor Planifica las reuniones (por ej., plan de iteraciones, plan de lanzamientos releases), se asegura que el proceso de las reuniones se sigue, anota los resultados de la reunión para futuros informes y los pasa al Perseguidor. Posiblemente responsable ante el “Propietario de Oro” Asiste a las reuniones, aporta información útil anterior. “ Propietario de Oro” La persona que paga el proyecto, que puede ser o no la misma que el Cliente.
Las cuatro actividades básicas Codificar Hacer pruebas Escuchar Diseñar.
Proceso de Desarrollo
Artefactos esenciales en XP Historias del Usuario Tareas de Ingeniería Pruebas de Aceptación Pruebas Unitarias y de Integración Plan de la Entrega Código
Historia de Usuario Observaciones: Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Puntos Reales: Riesgo en Desarrollo:  (Alto / Medio / Bajo) Puntos Estimados: Prioridad  en Negocio:  Alta (Alta / Media / Baja) Iteración Asignada: 2 Modificación de Historia Número: Usuario: Autor  Nombre: Enviar artículo Número: 1 Historia de Usuario
Spike para Historia de Usuario
Tarea de Ingeniería Descripción: Programador responsable: Fecha fin:  Fecha inicio:  Puntos estimados: Tipo de tarea :  Desarrollo / Corrección / Mejora / Otra  Nombre tarea: Número historia: Número tarea: Tarea
Prueba de Aceptación Evaluación: Resultado esperado: Entradas: Condiciones de ejecución: Descripción: Nombre Caso de Prueba: Número Historia de Usuario: Número Caso de Prueba: Caso de Prueba
Escenarios en XP : Exploración Prioridad Riesgo Esfuerzo (puntos) Definir Historias de Usuario Elaborar Spikes Estimar Esfuerzo y Riesgo ? Historias de Usuario Spikes (Bosquejos)
Escenarios en XP:  Planificación de la Entrega Historias de Usuario Primera Iteración Segunda Iteración Última Iteración … N-ésima Iteración Historias fuera de la entrega Velocidad de  Proyecto (VP) puntos/semana Entrega <= 3 meses 2 a 3 semanas
Escenarios en XP :  Comenzar Iteración Historias de la Iteración Definir y  ordenar Tareas de Ingeniería Tareas de  la iteración
Escenarios en XP :  Programación Pruebas de Aceptación de Historias  de la iteración Programación en Parejas Historias de la Iteración Versión del Producto Diseño Refactoring Programación Pruebas Unitarias Integración Pruebas de Integración Pruebas de Aceptación Tareas de  Historias de la iteración
Escenarios en XP :  Pruebas de Aceptación Pruebas de Aceptación Definir Pruebas de Aceptación Aplicar Pruebas de Aceptación Corregir errores Definir nuevas Historias
Entorno y clima de trabajo  Espacio de trabajo XP Espacio abierto Mesas centrales Cubículos en el espacio exterior Espacio de trabajo del proyecto C3   de  DaimlerChrysler
Reunión diaria: “ Stand-up Meeting ”   Todo el equipo Problem as Solucion es De pie en un círculo   Evitar discusiones largas   Sin conversaciones separadas …  Entorno y clima de trabajo  Reunión diaria XP
…  Entorno y clima de trabajo  Gantt de Pared Obtenida de www.agiletek.com “ Centro del universo del proyecto” “ Punto de reunión para la “Stand-up Meeting”
Fases de la metodología XP
Como hacemos funcionar la Metodología XP
XP plantea la planificación como un permanente dialogo entre las partes la empresarial (deseable) y la técnica (posible).  Planificación deseable posible
.1 El Juego de la Planificación Negocio Ámbito  ¿Qué debe resolver el software? Prioridad  ¿Qué debe ser echo en primer lugar? Composición de versiones  ¿Cuánto es necesario hacer para aportar valor? Fechas de versiones  ¿Fechas para presencia del software? …  Planificación
.1 El Juego de la Planificación Técnico . Estimaciones  ¿Cuánto lleva implementar una característica? Consecuencias,  informar sobre consecuencias de las decisiones que adopta el negocio . Procesos  ¿Cómo se organiza el trabajo en el equipo? Programación detallada: En una versión  ¿Qué se resolverá primero? …  Planificación
.2 Pequeñas versiones. Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo. …  Planificación .3 Metáfora. Es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema.
.4 Diseño simple. El diseño adecuado par el software es aquel que: Funciona con todas las pruebas. No tiene lógica duplicada. Manifiesta cada intención importante para los programadores  Tiene el menor número de clases y métodos. Diseño
.5 Recodificación. Este proceso se le denomina recodificar o refactorizar (refactoring).y consiste en hacer el programa mas simple sin perder funcionalidad.  No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.  Codificación
.6 Programación por parejas. Todo el código de producción se escribe con dos personas mirando a una máquina, con un solo teclado y un solo ratón. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?.  …  Codificación
.7 Propiedad Colectiva. Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. .8 Integración continúa. El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. …  Codificación
.9 Cuarenta horas. Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche .   del sistema. .10 Cliente In Situ. Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. …  Codificación
.11 Estándares de Codificación. Se debe establecer un estándar de codificación aceptado e implantado por todo el equipo.  …  Codificación
Pruebas .12 Hacer pruebas. Toda característica en el programa debe ser probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que soporte cambios en el tiempo.
Prácticas XP El juego de la planificación Entregas pequeñas Metáfora Diseño simple  Recodificación Programación en parejas Propiedad colectiva Integración continua Semana de 40 horas Cliente in situ Estándares de programación Pruebas DISEÑO CODIFICACION PLANIFICACION PRUEBAS
…  Prácticas XP Interacción entre Prácticas XP: Kent  Beck Cliente in situ Metáfora Propiedad Colectiva Integración Continua El juego de la  planificación Semana  de 40 horas Programación  en parejas Recodificación Estándares de programación Pruebas Diseño simple Pequeñas versiones
Aspectos sobre Programación Extrema
Aspectos Positivos De Xp   Pruebas unitarias en el código factor clave para obtener un software de alta calidad. La integración continua es aceptada y recomendada para evitar catástrofes ocasionadas por defectos no detectados a tiempo. la simplicidad y la refabricación es encontrado como un factor saludable en la práctica de programación.  El enfoque “extremadamente humano”, siendo este un aspecto que el resto del campo del software debería tratar de emular.  Cliente también se percibe el enfoque humano, ya que tenemos su presencia constante en las instalaciones del desarrollador.
Aspectos Controversiales de Xp   La XP se ha afirmado que no es la metodología que va a resolver todos los problemas en IS y se han resaltado sus limitaciones.  No es aconsejable XP si no es posible disminuir la curva costo/tiempo. Tampoco si la tecnología o el entorno no permiten realizar integraciones frecuentes o realizar pruebas continuamente.  No se recomienda intentar XP si la distribución física impide la programación en pares o si no todos los programadores se encuentran en el mismo sitio.
Desalienta el diseño, que es débil en la documentación, que el modelo no aplica para proyectos donde la seguridad es crítica. Exceso de pruebas retrasa el desarrollo, el diseño simple solo aplica a proyectos simples, que la programación en pares consume mayor tiempo y recursos. XP asume implícitamente que siempre se utiliza el enfoque de programación orientada a objetos. Aspectos Controversiales de Xp
La refabricación, como sinónimo de rediseño constante y que se puede tomar como una excusa para relegar hasta el último minuto el diseño. La planeación, según algunos críticos, no debería hacerse “sobre la marcha” como parece recomendar XP. La programación en pares. Se argumenta que no cualquier “clase” de programador desea trabajar de esta manera. Beneficios, tales como: producir menos defectos, aumentar la productividad, elevar la moral del equipo, mejorar la confianza y el trabajo en equipo, naturalidad en la transferencia del conocimiento y favorecer el aprendizaje. Aspectos Controversiales de Xp
Posturas A Favor Y En Contra
Extrapolación De Las Prácticas De Xp  XP adecuada para proyectos de software pequeños o cuando mucho medianos. Diseño al inicio: Aquí se recomienda un buen diseño inicial (up-front) que respalde al proyecto. Se producen funcionalidades completas en cada iteración (entrega) durante el ciclo del software. El tiempo entre cada entrega es corto.
Extrapolación De Las Prácticas De Xp  (Cont..I) Se simula al cliente en las instalaciones, en lugar de ser un cliente real como dice XP, este rol lo asume alguien con experiencia. Programación en pares flexible. Se modifica la práctica de XP y en lugar de ser obligatoria para todo el código que se escribe. Selección y administración del equipo de desarrollo. Se buscan diferentes habilidades y experiencias en los programadores.
BENEFICIOS Satisfacción del cliente. Cumplimiento de plazos. El cliente tiene el control sobre las prioridades. Se hacen pruebas continuas durante el proyecto. Calidad en el trabajo. La XP es mejor utilizada en la implementación de nuevas tecnologías donde los requerimientos cambian rápidamente.
CONCLUSIONES  La programación extrema es una forma ligera, eficiente, flexible, predecible, científica y divertida de generar software.  La programación extrema se beneficia de la existencia de un gran número de herramientas de software libre que permiten aplicarla con gran productividad. El software libre se inspira en algunas de las prácticas de la XP .
CONCLUSIONES Cont.. (II) Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado, evitando que se desmoralice por no sabe como preparar pruebas de aceptación. El proceso de desarrollo de las pruebas ayuda al cliente a clarificar y concretar la funcionalidad de la historia de uso y favorece la comunicación entre el cliente y el equipo de desarrollo. El desarrollo de pruebas ayuda identificar y corregir fallos u omisiones en las historias de uso.
CONCLUSIONES Cont.. (III) Permite corregir errores en las ideas del cliente, por ejemplo encontrando resultados que el cliente espera encontrar en la implementación. Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situación. Garantiza la cobertura de la funcionalidad de las pruebas de aceptación, garantizando que no se deja ningún punto importante de la funcionalidad de una historia de uso sin probar.
RECOMENDACIONES  Algunas prácticas podrán ser controversiales y hasta contraproducentes fuera de un dominio específico. Las metodologías ágiles se recomiendan.  Para proyectos y equipos pequeños. Requerimientos cambiantes (enfoque evolutivo). Equipo de desarrollo competente. Cliente dispuesto a participar con el equipo.  El proceso como una manera de agilizar el Proceso Unificado, combinándolo con la XP.
BIBLIOGRAFÍA Una explicación de la Programación extrema: aceptar el cambio Autor: Kent Beck. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. – 2002. La Programación Extrema en la práctica Autor: James Newkirk, Robert C. Martin. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. – 2002. Extreme Programming Installed. Autor: Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. Publicado: Addison-Wesley Pub Co; 1 edición (13 Octubre 2000). Extreme Programming Explained: Embrace Change.  Autor: Kent Beck.Publicado: Addison-Wesley Pub Co; 1 edición (5 Octubre 1999).
BIBLIOGRAFÍA Extreme Programming Pocket Guide.  Autor: chromatic. Publicado: O'Reilly & Associates; 1 edición (Junio 2003). Extreme Programming Refactored: The Case Against XP.  Autor: Matt Stephens, Doug Rosenberg.  Publicado: APress; (1 Enero 1970). Planning Extreme Programming. Autor: Kent Beck, Martin Fowler.  Publicado: Addison-Wesley Pub Co; 2000
 
Referencias Web Sitio Extreme Programming: A Gentle Introduction.  www.extremeprogramming.org  Secciones “Artículos” y “Roadmap” del sitio de la Agile Alliance.  www.agilealliance.org Sitio Xprogramming, mantenido por Ron Jeffries.  www.xprogramming.com WikiWiki de Extreme Programming  http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap Revista electrónica Software Development.  www.sdmagazine.com Número monográfico de revista CrossTalk: Agile Software Development.  www.stsc.hill.af.mil/crosstalk/2002/10/ Una extensiones de XP, Agile+.  www.agiletek.com Sitios de modelado ágil, mantenidos por Scott W. Ambler.  www.agilemodeling.com  y  www.agiledata.org Refactoring, mantenido por Martin Fowler.  www.refactoring.com Pruebas en contexto ágil,  www.junit.org   International Conference on eXtreme Programming and Agile Methods in Software Development (XP200x)  http://www.xp2004.org XP Agile Universe  http://www.agileuniverse.com
Ejemplo de Programador Extremo
GRACIAS

Más contenido relacionado

La actualidad más candente

Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
Jose Patricio Bovet Derpich
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
Cesar Prado
 
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
Saul Villarreal
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
Fundación Universitaria Konrad Lorenz
 
Xp
XpXp
Metodologia xp cortesserranoeliud
Metodologia xp cortesserranoeliudMetodologia xp cortesserranoeliud
Metodologia xp cortesserranoeliud
Eliud Cortes
 
GESTION DE PROCESOS Sistemas Operativos
GESTION DE PROCESOS Sistemas OperativosGESTION DE PROCESOS Sistemas Operativos
GESTION DE PROCESOS Sistemas Operativos
adriel91
 
Microsoft azure presentacion
Microsoft azure presentacionMicrosoft azure presentacion
Microsoft azure presentacion
Juan Paucar
 
Extreme Programming (XP).pptx
Extreme Programming (XP).pptxExtreme Programming (XP).pptx
Extreme Programming (XP).pptx
LisethGiraldoMorales
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Miguel Rodríguez
 
Metodologia incremental
Metodologia incrementalMetodologia incremental
Metodologia incremental
Anel Sosa
 
1ra presentacion metodologias agiles
1ra presentacion metodologias agiles1ra presentacion metodologias agiles
1ra presentacion metodologias agiles
Informatica Puente Alto
 
Tecnicas de ingenieria de software
Tecnicas de ingenieria de softwareTecnicas de ingenieria de software
Tecnicas de ingenieria de software
'Jorge Martinez
 
Construccion y Pruebas de Software
Construccion y Pruebas de SoftwareConstruccion y Pruebas de Software
Construccion y Pruebas de Software
Gustavo Bazan Maal
 
Mapa mental de Ing. de requisito y requerimiento
Mapa mental de Ing. de requisito y requerimientoMapa mental de Ing. de requisito y requerimiento
Mapa mental de Ing. de requisito y requerimiento
Jose Gregorio Brito Villarroel
 
Rup disciplinas
Rup disciplinasRup disciplinas
Rup disciplinas
NELSON RODRIGUEZ
 
Mapa conceptual - Institutos Reguladores Calidad de Software
Mapa conceptual - Institutos Reguladores Calidad de SoftwareMapa conceptual - Institutos Reguladores Calidad de Software
Mapa conceptual - Institutos Reguladores Calidad de Software
Karloz Dz
 
Arquitectura dirigida a eventos
Arquitectura dirigida a eventosArquitectura dirigida a eventos
Arquitectura dirigida a eventos
rehoscript
 
METODOLOGIA SCRUM
METODOLOGIA SCRUM METODOLOGIA SCRUM
METODOLOGIA SCRUM
Yenzy yaquelin Aragon Mayta
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
Andrés Felipe Montoya Ríos
 

La actualidad más candente (20)

Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
INGENIERIA DE SOFTWARE - METODOLOGIA SCRUM, EJEMPLO PRACTICO, t3
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Xp
XpXp
Xp
 
Metodologia xp cortesserranoeliud
Metodologia xp cortesserranoeliudMetodologia xp cortesserranoeliud
Metodologia xp cortesserranoeliud
 
GESTION DE PROCESOS Sistemas Operativos
GESTION DE PROCESOS Sistemas OperativosGESTION DE PROCESOS Sistemas Operativos
GESTION DE PROCESOS Sistemas Operativos
 
Microsoft azure presentacion
Microsoft azure presentacionMicrosoft azure presentacion
Microsoft azure presentacion
 
Extreme Programming (XP).pptx
Extreme Programming (XP).pptxExtreme Programming (XP).pptx
Extreme Programming (XP).pptx
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
 
Metodologia incremental
Metodologia incrementalMetodologia incremental
Metodologia incremental
 
1ra presentacion metodologias agiles
1ra presentacion metodologias agiles1ra presentacion metodologias agiles
1ra presentacion metodologias agiles
 
Tecnicas de ingenieria de software
Tecnicas de ingenieria de softwareTecnicas de ingenieria de software
Tecnicas de ingenieria de software
 
Construccion y Pruebas de Software
Construccion y Pruebas de SoftwareConstruccion y Pruebas de Software
Construccion y Pruebas de Software
 
Mapa mental de Ing. de requisito y requerimiento
Mapa mental de Ing. de requisito y requerimientoMapa mental de Ing. de requisito y requerimiento
Mapa mental de Ing. de requisito y requerimiento
 
Rup disciplinas
Rup disciplinasRup disciplinas
Rup disciplinas
 
Mapa conceptual - Institutos Reguladores Calidad de Software
Mapa conceptual - Institutos Reguladores Calidad de SoftwareMapa conceptual - Institutos Reguladores Calidad de Software
Mapa conceptual - Institutos Reguladores Calidad de Software
 
Arquitectura dirigida a eventos
Arquitectura dirigida a eventosArquitectura dirigida a eventos
Arquitectura dirigida a eventos
 
METODOLOGIA SCRUM
METODOLOGIA SCRUM METODOLOGIA SCRUM
METODOLOGIA SCRUM
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 

Destacado

Metodología xp
Metodología xpMetodología xp
Metodología xp
Piskamen
 
Introducción Ágil a eXtreme Programming
Introducción Ágil a eXtreme ProgrammingIntroducción Ágil a eXtreme Programming
Introducción Ágil a eXtreme Programming
ChileAgil
 
Monografia metodologia xp
Monografia   metodologia xpMonografia   metodologia xp
Monografia metodologia xp
Christian O. Gonzalez Horna
 
Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp
deborahgal
 
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3   Extreme ProgrammingSeminario MetodologíAs áGiles Y Xp, Tema 3   Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
guest82ea27
 
Manual01
Manual01Manual01
Manual 02
Manual 02Manual 02
Manual 02
Ricardo Quintero
 
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3   Extreme ProgrammingSeminario MetodologíAs áGiles Y Xp, Tema 3   Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
guest123148
 
Programación Extrema (Extream Programming XP)
Programación Extrema (Extream Programming XP)Programación Extrema (Extream Programming XP)
Programación Extrema (Extream Programming XP)
Cesar Acosta
 
4. Desarrollo ágil de software
4. Desarrollo ágil de software4. Desarrollo ágil de software
4. Desarrollo ágil de software
Coesi Consultoria
 
Programacion extrema
Programacion extremaProgramacion extrema
Programacion extrema
Cheo Mateo
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
CrisCobol
 
Programación Extrema (XP)
Programación Extrema (XP)Programación Extrema (XP)
Programación Extrema (XP)
Lucas Passalacqua
 
Programación Extrema
Programación ExtremaProgramación Extrema
Programación Extrema
urumisama
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Roberto Allende
 
Historias de Usuario (Tarjetas)
Historias de Usuario (Tarjetas)Historias de Usuario (Tarjetas)
Historias de Usuario (Tarjetas)
Ares Atzarel Hernández Rodríguez
 
Plan de Pruebas
Plan de PruebasPlan de Pruebas
Plan de Pruebas
choselin
 
Metodologias agiles
Metodologias agilesMetodologias agiles
Metodologias agiles
ronaljulio347
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacion
Abner Gerardo
 
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Miquel Mora
 

Destacado (20)

Metodología xp
Metodología xpMetodología xp
Metodología xp
 
Introducción Ágil a eXtreme Programming
Introducción Ágil a eXtreme ProgrammingIntroducción Ágil a eXtreme Programming
Introducción Ágil a eXtreme Programming
 
Monografia metodologia xp
Monografia   metodologia xpMonografia   metodologia xp
Monografia metodologia xp
 
Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp
 
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3   Extreme ProgrammingSeminario MetodologíAs áGiles Y Xp, Tema 3   Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
 
Manual01
Manual01Manual01
Manual01
 
Manual 02
Manual 02Manual 02
Manual 02
 
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3   Extreme ProgrammingSeminario MetodologíAs áGiles Y Xp, Tema 3   Extreme Programming
Seminario MetodologíAs áGiles Y Xp, Tema 3 Extreme Programming
 
Programación Extrema (Extream Programming XP)
Programación Extrema (Extream Programming XP)Programación Extrema (Extream Programming XP)
Programación Extrema (Extream Programming XP)
 
4. Desarrollo ágil de software
4. Desarrollo ágil de software4. Desarrollo ágil de software
4. Desarrollo ágil de software
 
Programacion extrema
Programacion extremaProgramacion extrema
Programacion extrema
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
 
Programación Extrema (XP)
Programación Extrema (XP)Programación Extrema (XP)
Programación Extrema (XP)
 
Programación Extrema
Programación ExtremaProgramación Extrema
Programación Extrema
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Historias de Usuario (Tarjetas)
Historias de Usuario (Tarjetas)Historias de Usuario (Tarjetas)
Historias de Usuario (Tarjetas)
 
Plan de Pruebas
Plan de PruebasPlan de Pruebas
Plan de Pruebas
 
Metodologias agiles
Metodologias agilesMetodologias agiles
Metodologias agiles
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacion
 
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
 

Similar a Programacion Extrema

METODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILESMETODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILES
Humbert Ramirez Jaramillo
 
METODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TIMETODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TI
Humbert Ramirez Jaramillo
 
10245215.ppth
10245215.ppth10245215.ppth
10245215.ppth
DiegoAngolassj
 
Requirements Engineering for Software and Systems_chapter07 (1).pdf
Requirements Engineering for Software and Systems_chapter07 (1).pdfRequirements Engineering for Software and Systems_chapter07 (1).pdf
Requirements Engineering for Software and Systems_chapter07 (1).pdf
LuciaMartnez7
 
Metodologías Ágiles - Scrum y XP
Metodologías Ágiles - Scrum y XPMetodologías Ágiles - Scrum y XP
Metodologías Ágiles - Scrum y XP
Jose I. Honrado
 
Public3
Public3Public3
Díme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usarDíme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usar
Kiberley Santos
 
FACCI METODOLOGIAS AGILES
FACCI METODOLOGIAS AGILESFACCI METODOLOGIAS AGILES
FACCI METODOLOGIAS AGILES
afrancoing
 
Proceso Unificado de Desarrollo
Proceso Unificado de DesarrolloProceso Unificado de Desarrollo
Proceso Unificado de Desarrollo
Fausto J Loja Mora
 
Métodos agiles
Métodos agilesMétodos agiles
Métodos agiles
Piere Andre Ruiz Alba
 
Tw ¿Por qué elegir ágil?
Tw   ¿Por qué elegir ágil? Tw   ¿Por qué elegir ágil?
Tw ¿Por qué elegir ágil?
Agile Express Ecuador / Thoughtworks
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicional
Jesenia Escobar
 
Angello revista digital
Angello revista digitalAngello revista digital
Angello revista digital
Angello Segundo
 
Los metodos agiles
Los metodos agilesLos metodos agiles
Los metodos agiles
Jose Johan Torres Almonte
 
Exposicion
ExposicionExposicion
Exposicion
Erik Mosquera
 
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
Walter Ariel Risi
 
Metodologias agiles
Metodologias agilesMetodologias agiles
Metodologias agiles
Joel Canta Cuipal
 
Pracicas de Ingenieria de Software
Pracicas de Ingenieria de SoftwarePracicas de Ingenieria de Software
Pracicas de Ingenieria de Software
eeencalada
 
Desarrollo ágil
Desarrollo ágilDesarrollo ágil
Desarrollo ágil
fponceh
 
Metodologías ágiles
Metodologías ágilesMetodologías ágiles
Metodologías ágiles
Pablo Macon
 

Similar a Programacion Extrema (20)

METODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILESMETODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILES
 
METODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TIMETODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TI
 
10245215.ppth
10245215.ppth10245215.ppth
10245215.ppth
 
Requirements Engineering for Software and Systems_chapter07 (1).pdf
Requirements Engineering for Software and Systems_chapter07 (1).pdfRequirements Engineering for Software and Systems_chapter07 (1).pdf
Requirements Engineering for Software and Systems_chapter07 (1).pdf
 
Metodologías Ágiles - Scrum y XP
Metodologías Ágiles - Scrum y XPMetodologías Ágiles - Scrum y XP
Metodologías Ágiles - Scrum y XP
 
Public3
Public3Public3
Public3
 
Díme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usarDíme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usar
 
FACCI METODOLOGIAS AGILES
FACCI METODOLOGIAS AGILESFACCI METODOLOGIAS AGILES
FACCI METODOLOGIAS AGILES
 
Proceso Unificado de Desarrollo
Proceso Unificado de DesarrolloProceso Unificado de Desarrollo
Proceso Unificado de Desarrollo
 
Métodos agiles
Métodos agilesMétodos agiles
Métodos agiles
 
Tw ¿Por qué elegir ágil?
Tw   ¿Por qué elegir ágil? Tw   ¿Por qué elegir ágil?
Tw ¿Por qué elegir ágil?
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicional
 
Angello revista digital
Angello revista digitalAngello revista digital
Angello revista digital
 
Los metodos agiles
Los metodos agilesLos metodos agiles
Los metodos agiles
 
Exposicion
ExposicionExposicion
Exposicion
 
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
 
Metodologias agiles
Metodologias agilesMetodologias agiles
Metodologias agiles
 
Pracicas de Ingenieria de Software
Pracicas de Ingenieria de SoftwarePracicas de Ingenieria de Software
Pracicas de Ingenieria de Software
 
Desarrollo ágil
Desarrollo ágilDesarrollo ágil
Desarrollo ágil
 
Metodologías ágiles
Metodologías ágilesMetodologías ágiles
Metodologías ágiles
 

Programacion Extrema

  • 1. Maestría en Ingeniería de Sistemas con Mención en Gestión En Tecnología de la Información Ingeniería de Software LIMA - 2007
  • 2. Esta situación resulta conocida……???
  • 3. Fuerzas que influyen en los enfoques para el desarrollo de software Grado de Control en el proceso Tiempo 1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s Fuente: Diapositiva obtenida de la presentación “ A History of Agile Methods” presentada por Alan Davis en JISBD 2002 Libertarios Fundamentalistas Tendencia global
  • 5. Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto. Metodología Ágil
  • 6. El Manifiesto de la metodología Ágil: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Desarrollar software que funciona más que conseguir una buena documentación. La colaboración con el cliente más que la negociación de un contrato. Responder a los cambios más que seguir estrictamente un plan. Es importante la derecha pero valoramos más la izquierda Metodología Ágil
  • 7. ¿Qué es una Metodología Ágil? Las Metodologías Ágiles (MAs) valoran: Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas Desarrollar software que funciona más que conseguir una buena documentación  Minimalismo respecto del modelado y la documentación del sistema La colaboración con el cliente más que la negociación de un contrato Responder a los cambios más que seguir estrictamente una planificación
  • 8. ¿Por qué surgen las Metodologías Ágiles? Dificultades para implantar metodologías tradicionales. Procesos ceremoniosos, herramientas CASE y notaciones de modelado sofisticadas (UML) Una solución a medida para un segmento importante de proyectos de desarrollo de software Pugna entre comunidades/gurús “ Aceptar el cambio” ...
  • 9. ¿Cuándo utilizar una Metodología Ágil? ¿Tienes ya un proceso? No existe pero no reacciona bien a los cambios existe pero el equipo no está contento con él  Una Metodología Ágil puede ser una buena forma de empezar No involucra gran inversión A los programadores les (suele) gustar A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto
  • 10. Comparación Ágil v/s Tradicional Se espera que no ocurran cambios de gran impacto durante el proyecto Se esperan cambios durante el proyecto Énfasis en la definición del proceso: roles, actividades y artefactos Énfasis en los aspectos humanos: el individuo y el trabajo en equipo Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos Orientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio Se promueve que la arquitectura se defina tempranamente en el proyecto La arquitectura se va definiendo y mejorando a lo largo del proyecto El cliente interactúa con el equipo de desarrollo mediante reuniones Cliente es parte del equipo de desarrollo (además in-situ) Existe un contrato prefijado No existe un contrato tradicional, debe ser bastante flexible Más Roles, más específicos Pocos Roles, más genéricos y flexibles Más Artefactos. El modelado es esencial, mantenimiento de modelos Pocos Artefactos. El modelado es prescindible, modelos desechables. Metodología Tradicional Metodología Ágil
  • 11. Costo de los Cambios en SW Cost o del c ambio ti empo Tradicional Suposición MAs
  • 12. Principales MAs Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com DSDM (Dynamic Systems Development Method), www.dsdm.org Lean Programming, Mary Poppendieck, www.poppendieck.com FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com Adaptative Software Development, Jim Highsmith www.adaptivesd.com
  • 14. Antecedentes e Historia de Programación extrema
  • 15. Sin embargo, se reconoce a Kent Beck como el que articuló esta propuesta y le dio nombre propio. Kent Beck En 1989, Cunningham formó un equipo que usaba los principios y muchas de las prácticas que después adoptaría XP, mientras trabajaba para la compañía “Wyatt Software” [Fowler 2000]. Antecedentes e Historia de Programación extrema
  • 16. Posteriormente, la consolidación de XP se logra con la publicación del libro “Extreme Programming Explained: embrace change” en el año 1999, donde Beck resume su propia experiencia y le da forma y nombre a la entonces nueva metodología de desarrollo de software, la cual le valió el premio: “Software Development Jolt Product Excellence”. Antecedentes e Historia de Programación extrema
  • 17. Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal. Antecedentes e Historia de Programación extrema
  • 18. Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que ésta le hizo el año 1999. En ésta decía que él estaba convencido que la mejor metodología era un proceso: Que enfatizase la comunicación del equipo. Que la implementación fuera sencilla. Que que el usuario tenía que estar muy informado e implicado. Que la toma de decisiones tenía que ser muy rápida y efectiva. Antecedentes e Historia de Programación extrema
  • 19. Los autores de la Programación Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación. Antecedentes e Historia de Programación extrema Portland Pattern Repository
  • 21. La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de prácticas que propician un aumento en la productividad a la hora de generar software. XP permite controlar los problemas de riesgo en los proyectos. XP permite la participación de pequeños grupos de programadores. XP requiere un variado equipo de desarrollo. XP permite la capacidad de hacer pruebas La meta real de XP es entregar el software requerido a tiempo. ¿Que es XP?
  • 22. Las características generales de XP es deliberadamente una metodología “liviana” que pasa por alto la utilización de elaborados casos de uso, la exhaustiva definición de requerimientos y la producción de una extensa documentación. Todo lo anterior puede parecer caótico según el enfoque tradicional de la ingeniería de software, aunque no hay que olvidar que XP tiene asociado un ciclo de vida y es considerado a su vez un proceso. La tendencia de entregar software en lapsos cada vez menores de tiempo y con exigencias de costos reducidos y altos estándares de calidad, hace que XP sea una opción a considerar. Características de XP
  • 26. Principios, roles y prácticas de Programación extrema
  • 27. Principios de la Programación extrema Se busca : Realimentación rápida Asumir la simplicidad Cambio incremental Aceptar el cambio Hacer trabajo de calidad.
  • 28. Principios de la Programación extrema Las Prácticas son: 1. El juego de la planificación 2. Pequeñas entregas 3. Metáfora 4. Diseño simple 5. Pruebas 6. Refactorización
  • 29. Principios de la Programación extrema 7. Programación por parejas 8. Propiedad colectiva 9. Integración continua 10. 40 horas semanales 11. Cliente en casa 12. Estándares de codificación.
  • 30. Objetivos de la Programación extrema
  • 31. Objetivos de XP Son: La satisfacción del cliente. Potenciar el trabajo en grupo, todos están involucrados en el desarrollo del software.
  • 32. Interacción entre Las cuatro variables de Gestión de proyecto
  • 33. El coste de Cambio El coste de los cambios crece con el tiempo. XP propone que los costes de los cambios no tienen por que aumentar con el tiempo.
  • 34. Las cuatro valores Valores para desarrollar software: Comunicación Sencillez Retroalimentación Valentía.
  • 35. Roles de XP Cliente Escribe “Historias de Usuario” y especifica Pruebas Funcionales. Establece prioridades, explica las Historias Puede ser o no un usuario final Tiene autoridad para decidir cuestiones relativas a las Historias. Programador Hace estimaciones sobre las Historias Define Tareas a partir de las Historias y hace estimaciones Implementa las Historias y las Pruebas Unitarias
  • 36. Roles de XP Tutor Observa todo, identifica señales de peligro, se asegura que el proyecto se mantiene en curso Ayuda en todo Da avisos cuando se necesita. Perseguidor (calidad) Monitoriza el progreso de los programadores, toma acción si las cosas tienden a salirse de su senda. Las acciones incluyen reuniones con el Cliente, solicitar ayuda al Tutor u otro Programador.
  • 37. Roles de XP Verificador Implementa y corre las Pruebas Funcionales (no Pruebas Unitarias) Presenta gráficas de los resultados y se asegura de que la gente conoce cuándo los resultados empiezan a decaer. “ Agorero” Se asegura que todos conocen los riesgos que existen Se asegura que las malas noticias no se ocultan, se disculpan o se reducen de proporción.
  • 38. Roles de XP Gestor Planifica las reuniones (por ej., plan de iteraciones, plan de lanzamientos releases), se asegura que el proceso de las reuniones se sigue, anota los resultados de la reunión para futuros informes y los pasa al Perseguidor. Posiblemente responsable ante el “Propietario de Oro” Asiste a las reuniones, aporta información útil anterior. “ Propietario de Oro” La persona que paga el proyecto, que puede ser o no la misma que el Cliente.
  • 39. Las cuatro actividades básicas Codificar Hacer pruebas Escuchar Diseñar.
  • 41. Artefactos esenciales en XP Historias del Usuario Tareas de Ingeniería Pruebas de Aceptación Pruebas Unitarias y de Integración Plan de la Entrega Código
  • 42. Historia de Usuario Observaciones: Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Puntos Reales: Riesgo en Desarrollo: (Alto / Medio / Bajo) Puntos Estimados: Prioridad en Negocio: Alta (Alta / Media / Baja) Iteración Asignada: 2 Modificación de Historia Número: Usuario: Autor Nombre: Enviar artículo Número: 1 Historia de Usuario
  • 43. Spike para Historia de Usuario
  • 44. Tarea de Ingeniería Descripción: Programador responsable: Fecha fin: Fecha inicio: Puntos estimados: Tipo de tarea : Desarrollo / Corrección / Mejora / Otra Nombre tarea: Número historia: Número tarea: Tarea
  • 45. Prueba de Aceptación Evaluación: Resultado esperado: Entradas: Condiciones de ejecución: Descripción: Nombre Caso de Prueba: Número Historia de Usuario: Número Caso de Prueba: Caso de Prueba
  • 46. Escenarios en XP : Exploración Prioridad Riesgo Esfuerzo (puntos) Definir Historias de Usuario Elaborar Spikes Estimar Esfuerzo y Riesgo ? Historias de Usuario Spikes (Bosquejos)
  • 47. Escenarios en XP: Planificación de la Entrega Historias de Usuario Primera Iteración Segunda Iteración Última Iteración … N-ésima Iteración Historias fuera de la entrega Velocidad de Proyecto (VP) puntos/semana Entrega <= 3 meses 2 a 3 semanas
  • 48. Escenarios en XP : Comenzar Iteración Historias de la Iteración Definir y ordenar Tareas de Ingeniería Tareas de la iteración
  • 49. Escenarios en XP : Programación Pruebas de Aceptación de Historias de la iteración Programación en Parejas Historias de la Iteración Versión del Producto Diseño Refactoring Programación Pruebas Unitarias Integración Pruebas de Integración Pruebas de Aceptación Tareas de Historias de la iteración
  • 50. Escenarios en XP : Pruebas de Aceptación Pruebas de Aceptación Definir Pruebas de Aceptación Aplicar Pruebas de Aceptación Corregir errores Definir nuevas Historias
  • 51. Entorno y clima de trabajo Espacio de trabajo XP Espacio abierto Mesas centrales Cubículos en el espacio exterior Espacio de trabajo del proyecto C3 de DaimlerChrysler
  • 52. Reunión diaria: “ Stand-up Meeting ” Todo el equipo Problem as Solucion es De pie en un círculo Evitar discusiones largas Sin conversaciones separadas … Entorno y clima de trabajo Reunión diaria XP
  • 53. … Entorno y clima de trabajo Gantt de Pared Obtenida de www.agiletek.com “ Centro del universo del proyecto” “ Punto de reunión para la “Stand-up Meeting”
  • 54. Fases de la metodología XP
  • 55. Como hacemos funcionar la Metodología XP
  • 56. XP plantea la planificación como un permanente dialogo entre las partes la empresarial (deseable) y la técnica (posible). Planificación deseable posible
  • 57. .1 El Juego de la Planificación Negocio Ámbito ¿Qué debe resolver el software? Prioridad ¿Qué debe ser echo en primer lugar? Composición de versiones ¿Cuánto es necesario hacer para aportar valor? Fechas de versiones ¿Fechas para presencia del software? … Planificación
  • 58. .1 El Juego de la Planificación Técnico . Estimaciones ¿Cuánto lleva implementar una característica? Consecuencias, informar sobre consecuencias de las decisiones que adopta el negocio . Procesos ¿Cómo se organiza el trabajo en el equipo? Programación detallada: En una versión ¿Qué se resolverá primero? … Planificación
  • 59. .2 Pequeñas versiones. Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo. … Planificación .3 Metáfora. Es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema.
  • 60. .4 Diseño simple. El diseño adecuado par el software es aquel que: Funciona con todas las pruebas. No tiene lógica duplicada. Manifiesta cada intención importante para los programadores Tiene el menor número de clases y métodos. Diseño
  • 61. .5 Recodificación. Este proceso se le denomina recodificar o refactorizar (refactoring).y consiste en hacer el programa mas simple sin perder funcionalidad. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida. Codificación
  • 62. .6 Programación por parejas. Todo el código de producción se escribe con dos personas mirando a una máquina, con un solo teclado y un solo ratón. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?. … Codificación
  • 63. .7 Propiedad Colectiva. Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. .8 Integración continúa. El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. … Codificación
  • 64. .9 Cuarenta horas. Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche . del sistema. .10 Cliente In Situ. Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. … Codificación
  • 65. .11 Estándares de Codificación. Se debe establecer un estándar de codificación aceptado e implantado por todo el equipo. … Codificación
  • 66. Pruebas .12 Hacer pruebas. Toda característica en el programa debe ser probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que soporte cambios en el tiempo.
  • 67. Prácticas XP El juego de la planificación Entregas pequeñas Metáfora Diseño simple Recodificación Programación en parejas Propiedad colectiva Integración continua Semana de 40 horas Cliente in situ Estándares de programación Pruebas DISEÑO CODIFICACION PLANIFICACION PRUEBAS
  • 68. … Prácticas XP Interacción entre Prácticas XP: Kent Beck Cliente in situ Metáfora Propiedad Colectiva Integración Continua El juego de la planificación Semana de 40 horas Programación en parejas Recodificación Estándares de programación Pruebas Diseño simple Pequeñas versiones
  • 70. Aspectos Positivos De Xp Pruebas unitarias en el código factor clave para obtener un software de alta calidad. La integración continua es aceptada y recomendada para evitar catástrofes ocasionadas por defectos no detectados a tiempo. la simplicidad y la refabricación es encontrado como un factor saludable en la práctica de programación. El enfoque “extremadamente humano”, siendo este un aspecto que el resto del campo del software debería tratar de emular. Cliente también se percibe el enfoque humano, ya que tenemos su presencia constante en las instalaciones del desarrollador.
  • 71. Aspectos Controversiales de Xp La XP se ha afirmado que no es la metodología que va a resolver todos los problemas en IS y se han resaltado sus limitaciones. No es aconsejable XP si no es posible disminuir la curva costo/tiempo. Tampoco si la tecnología o el entorno no permiten realizar integraciones frecuentes o realizar pruebas continuamente. No se recomienda intentar XP si la distribución física impide la programación en pares o si no todos los programadores se encuentran en el mismo sitio.
  • 72. Desalienta el diseño, que es débil en la documentación, que el modelo no aplica para proyectos donde la seguridad es crítica. Exceso de pruebas retrasa el desarrollo, el diseño simple solo aplica a proyectos simples, que la programación en pares consume mayor tiempo y recursos. XP asume implícitamente que siempre se utiliza el enfoque de programación orientada a objetos. Aspectos Controversiales de Xp
  • 73. La refabricación, como sinónimo de rediseño constante y que se puede tomar como una excusa para relegar hasta el último minuto el diseño. La planeación, según algunos críticos, no debería hacerse “sobre la marcha” como parece recomendar XP. La programación en pares. Se argumenta que no cualquier “clase” de programador desea trabajar de esta manera. Beneficios, tales como: producir menos defectos, aumentar la productividad, elevar la moral del equipo, mejorar la confianza y el trabajo en equipo, naturalidad en la transferencia del conocimiento y favorecer el aprendizaje. Aspectos Controversiales de Xp
  • 74. Posturas A Favor Y En Contra
  • 75. Extrapolación De Las Prácticas De Xp XP adecuada para proyectos de software pequeños o cuando mucho medianos. Diseño al inicio: Aquí se recomienda un buen diseño inicial (up-front) que respalde al proyecto. Se producen funcionalidades completas en cada iteración (entrega) durante el ciclo del software. El tiempo entre cada entrega es corto.
  • 76. Extrapolación De Las Prácticas De Xp (Cont..I) Se simula al cliente en las instalaciones, en lugar de ser un cliente real como dice XP, este rol lo asume alguien con experiencia. Programación en pares flexible. Se modifica la práctica de XP y en lugar de ser obligatoria para todo el código que se escribe. Selección y administración del equipo de desarrollo. Se buscan diferentes habilidades y experiencias en los programadores.
  • 77. BENEFICIOS Satisfacción del cliente. Cumplimiento de plazos. El cliente tiene el control sobre las prioridades. Se hacen pruebas continuas durante el proyecto. Calidad en el trabajo. La XP es mejor utilizada en la implementación de nuevas tecnologías donde los requerimientos cambian rápidamente.
  • 78. CONCLUSIONES La programación extrema es una forma ligera, eficiente, flexible, predecible, científica y divertida de generar software. La programación extrema se beneficia de la existencia de un gran número de herramientas de software libre que permiten aplicarla con gran productividad. El software libre se inspira en algunas de las prácticas de la XP .
  • 79. CONCLUSIONES Cont.. (II) Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado, evitando que se desmoralice por no sabe como preparar pruebas de aceptación. El proceso de desarrollo de las pruebas ayuda al cliente a clarificar y concretar la funcionalidad de la historia de uso y favorece la comunicación entre el cliente y el equipo de desarrollo. El desarrollo de pruebas ayuda identificar y corregir fallos u omisiones en las historias de uso.
  • 80. CONCLUSIONES Cont.. (III) Permite corregir errores en las ideas del cliente, por ejemplo encontrando resultados que el cliente espera encontrar en la implementación. Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situación. Garantiza la cobertura de la funcionalidad de las pruebas de aceptación, garantizando que no se deja ningún punto importante de la funcionalidad de una historia de uso sin probar.
  • 81. RECOMENDACIONES Algunas prácticas podrán ser controversiales y hasta contraproducentes fuera de un dominio específico. Las metodologías ágiles se recomiendan. Para proyectos y equipos pequeños. Requerimientos cambiantes (enfoque evolutivo). Equipo de desarrollo competente. Cliente dispuesto a participar con el equipo. El proceso como una manera de agilizar el Proceso Unificado, combinándolo con la XP.
  • 82. BIBLIOGRAFÍA Una explicación de la Programación extrema: aceptar el cambio Autor: Kent Beck. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. – 2002. La Programación Extrema en la práctica Autor: James Newkirk, Robert C. Martin. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. – 2002. Extreme Programming Installed. Autor: Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. Publicado: Addison-Wesley Pub Co; 1 edición (13 Octubre 2000). Extreme Programming Explained: Embrace Change. Autor: Kent Beck.Publicado: Addison-Wesley Pub Co; 1 edición (5 Octubre 1999).
  • 83. BIBLIOGRAFÍA Extreme Programming Pocket Guide. Autor: chromatic. Publicado: O'Reilly & Associates; 1 edición (Junio 2003). Extreme Programming Refactored: The Case Against XP. Autor: Matt Stephens, Doug Rosenberg. Publicado: APress; (1 Enero 1970). Planning Extreme Programming. Autor: Kent Beck, Martin Fowler. Publicado: Addison-Wesley Pub Co; 2000
  • 84.  
  • 85. Referencias Web Sitio Extreme Programming: A Gentle Introduction. www.extremeprogramming.org Secciones “Artículos” y “Roadmap” del sitio de la Agile Alliance. www.agilealliance.org Sitio Xprogramming, mantenido por Ron Jeffries. www.xprogramming.com WikiWiki de Extreme Programming http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap Revista electrónica Software Development. www.sdmagazine.com Número monográfico de revista CrossTalk: Agile Software Development. www.stsc.hill.af.mil/crosstalk/2002/10/ Una extensiones de XP, Agile+. www.agiletek.com Sitios de modelado ágil, mantenidos por Scott W. Ambler. www.agilemodeling.com y www.agiledata.org Refactoring, mantenido por Martin Fowler. www.refactoring.com Pruebas en contexto ágil, www.junit.org International Conference on eXtreme Programming and Agile Methods in Software Development (XP200x) http://www.xp2004.org XP Agile Universe http://www.agileuniverse.com