lunes, 25 de junio de 2012

Revisando: Programación Extrema XP (25/06/2012)


  • Programación extrema [Wikipedia].
  • A propósito de programación extrema XP (eXtreme Programming) [Monografia].
  • XP PROGRAMACION EXTREMA [Presentacion].
  • Las prácticas de Extreme Programming [Wikipedia traducción automática].
  • Extreme Programming Explained: Embrace Change [Libro en ingles].
  • Reglas y Prácticas en eXtreme Programming [PDF].
  • Una explicación de la programación extrema (XP) [PDF].
  • Extreme programming [DOC].
  • Desarrollo en comunidad con eXtreme Programming [PDF].
  • Una explicación de la programación extrema XP [PPT].
  • Metodología XP [Video].
  • XP - Decisión de Negocio [Video].
  • Programacion Extrema - Tests Unitarios - Tarea Zombies - Explicacion Inversion de Control [Video].
  • Programación Extrema (Exposicion de Maestria 2007) [Presentación].
  • Introducción Ágil a eXtreme Programming [Presentación].
  • Seminario MetodologíAs áGiles Y Xp, Extreme Programming [Presentación].
  • Métodos Ágiles-Scrum y XP [Presentación].
  • XPWeb: gestión de proyectos Extreme Programming.


Programación extrema [Wikipedia]

Fuente: es.wikipedia.org

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Valores

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
  • Simplicidad:
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
  • Comunicación:
La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.
  • Retroalimentación (feedback):
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
  • Coraje o valentía:
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.
  • Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

Características fundamentales

Las características fundamentales del método son:
  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Véase también

Enlaces externos





A propósito de programación extrema XP (eXtreme Programming)

Fuente: monografias.com



XP PROGRAMACION EXTREMA [Presentación]

Fuente: es.scribd.com

Cargado por Dennis Zamo Adunay
       


Las prácticas de Extreme Programming [wikipedia traducción automática]

Fuente: en.wikipedia.org

La programación extrema (XP) es un popular ágiles de desarrollo de software metodología utilizada para la aplicación de software de proyectos. Este artículo detalla las prácticas utilizadas en esta metodología. La programación extrema tiene 12 prácticas, agrupadas en cuatro áreas, derivadas de las mejores prácticas de ingeniería de software . [1]

escala de Fine

La programación en parejas

Par de programación significa que todo el código es producido por dos personas en una tarea de programación en una estación de trabajo. Un programador tiene el control de la estación de trabajo y está pensando principalmente acerca de la codificación en detalle. El otro programador se centra más en el cuadro grande, y está continuamente revisando el código que está siendo producido por la primera programadora. Los programadores cambiará roles con regularidad.
Las parejas no son fijas: se recomienda que los programadores tratan de mezclar tanto como sea posible, de manera que todo el mundo sabe lo que cada uno está haciendo, y todo el mundo pueda familiarizarse con el sistema en su conjunto. De esta manera, la programación en parejas también pueden mejorar la comunicación de todo el equipo. (Esto también va mano a mano con el concepto de propiedad colectiva).

Juego de Planificación

El proceso de planificación principal dentro de la programación extrema se llama el Juego de Planificación. El juego es una reunión que se produce una vez por iteración, por lo general una vez por semana. El proceso de planificación se divide en dos partes:
  • Planificación de autorización: Esta se centra en determinar qué requisitos se incluyen en el que a corto plazo las liberaciones, y cuándo deben ser entregados. Los clientes y los desarrolladores son parte de esto. Planificación de la difusión consiste en tres fases:
    • Fase de Exploración: En esta fase, el cliente proporcionará una lista de requisitos de alto valor para el sistema. Estos serán escritas en la historia del usuario de tarjetas.
    • Fase de Compromiso: Dentro de la fase de compromiso de negocios y los desarrolladores se comprometen a la funcionalidad que se incluirán y la fecha de la próxima versión.
    • Fase de dirección: En la fase de dirección del plan se puede ajustar, los nuevos requisitos se pueden añadir y / o requisitos existentes pueden ser cambiadas o eliminadas.
  • Planificación de la iteración: Este planes de las actividades y tareas de los desarrolladores. En este proceso el cliente no está implicado. Planificación de la iteración también se compone de tres fases:
    • Fase de Exploración: En esta fase, el requisito será traducida a diferentes tareas. Las tareas se graban en tarjetas de trabajo.
    • Fase de Compromiso: Las tareas serán asignadas a los programadores y el tiempo que tarda en completar se estimará.
    • Dirigir Fase: Las tareas se llevan a cabo y el resultado final se corresponde con la historia de usuario original.
El propósito del juego de planificación es guiar el producto en la entrega. En lugar de predecir las fechas exactas de cuando entregas serán necesarios y producido, lo cual es difícil de hacer, su objetivo es "dirigir el proyecto" en la prestación de utilizar un enfoque directo. [2]

la planificación de lanzamiento

Exploración fase de
Este es un proceso iterativo de reunir los requisitos y la estimación del impacto en el trabajo de cada uno de esos requisitos.
  • Escribir una historia: El negocio ha llegado con un problema, durante una reunión, el desarrollo se tratará de definir este problema y obtener los requisitos. Basado en el problema de negocio, una historia ( historia de usuario ) tiene que ser por escrito. Esto se hace por las empresas, en el que señalan lo que quieren una parte del sistema de hacer. Es importante que el desarrollo no tiene influencia en esta historia. La historia está escrita en una tarjeta de historia de usuario.
  • Estimar una historia: el Desarrollo calcula cuánto tiempo se tardará en poner en práctica el trabajo que implica la tarjeta de la historia. El desarrollo también pueden crear soluciones de espiga para analizar o resolver el problema. Estas soluciones se utilizan para la estimación y se desecha una vez que todo el mundo tiene una visualización clara del problema. Una vez más, esto no puede influir en los requerimientos del negocio.
  • Dividir una historia: Cada complejidad del diseño crítico tiene que ser abordado antes de iniciar la planificación de la iteración. Si el desarrollo no es capaz de estimar la historia, tiene que ser dividido y vuelto a escribir.
Cuando el negocio no puede venir con los requisitos más, se procede a la fase de compromiso.
fase de Compromiso
Esta fase consiste en la determinación de los costos, beneficios y el impacto previsto. Tiene cuatro componentes:
  • Ordenar por Valor: tipo de negocio de las historias de los usuarios por valor de negocio .
  • Ordenar por riesgo: tipo de desarrollo de las historias de los riesgos.
  • Velocidad de Ajuste: Desarrollo determina a qué velocidad se puede llevar a cabo el proyecto.
  • Elija ámbito de aplicación: Las historias de usuario que se terminarán en la próxima versión será recogido. Basado en las historias de los usuarios la fecha de lanzamiento está determinada.
Ordenar por valor de
El lado comercial tipo las historias de los usuarios por el valor del negocio. Se va a organizar en tres grupos:
  • Crítica: historias sin las cuales el sistema no puede funcionar o no tiene sentido.
  • Significativo valor comercial : no críticos historias de usuario que tienen un importante valor empresarial.
  • Es bueno tener: Historias de usuarios que no tienen valor comercial significativo.
Ordenar por riesgo
Los desarrolladores de clasificar los casos de uso por el riesgo. También se clasifican en tres grupos: historias de riesgo bajo, medio y alto de los usuarios. El siguiente es un ejemplo de una aproximación a este:
  • Determinar el Índice de Riesgo: Dar a cada historia de usuario un índice de 0 a 2 en cada uno de los siguientes factores:
    • Integridad (no sabemos todos los detalles de la historia?)
      • Completa (0)
      • Incompleta (1)
      • Desconocido (2)
    • Volatilidad (es probable que cambie?)
      • bajo (0)
      • medio (1)
      • de alto (2)
    • Complejidad (lo difícil que es construir?)
      • sencillo (0)
      • estándar (1)
      • complejo (2)
Todos los índices de una historia de usuario se agregan, la asignación de las historias de los usuarios un índice de riesgo de baja (0-1), mediano (2-4) o alto (5-6).
Fase de Dirección
Dentro de la fase de dirección de los programadores y gente de negocios puede "dirigir" el proceso. Es decir, pueden hacer cambios. Las historias individuales de los usuarios, o las prioridades relativas de las historias de usuarios, puede cambiar; estimaciones podrían resultar erróneos. Esta es la oportunidad para ajustar el plan en consecuencia.

planificación de la iteración

Exploración fase de
La fase de exploración de la planificación de la iteración se trata de la creación de tareas y la estimación de su tiempo de ejecución.
  • Traducir el requisito de tareas: Coloque las tarjetas de trabajo.
  • Combinar / Dividir tarea: Si el programador no puede estimar la tarea, porque es demasiado pequeño o demasiado grande, el programador tendrá que combinar o dividir la tarea.
  • Estimación de la tarea: Calcule el tiempo que se necesita para poner en práctica la tarea.
fase de Compromiso
Dentro de la fase de compromiso de los programadores de planificación de iteración se les asignan tareas que hacen referencia a los casos de uso diferentes.
  • Un programador acepta una tarea: Cada programador elige una tarea para la cual él o ella asume la responsabilidad.
  • Programador estima que la tarea: Debido a que el programador es ahora responsable de la tarea, él o ella debe dar a la estimación final de la tarea.
  • Selección del factor de carga: El factor de carga representa la cantidad ideal de la práctica en el tiempo de desarrollo por el programador en una iteración. Por ejemplo, en una semana de 40 horas, con 5 horas dedicadas a las reuniones, esto sería no más de 35 horas.
  • Equilibrio: Cuando todos los programadores dentro del equipo se han asignado las tareas, se hace una comparación entre el tiempo estimado de las tareas y el factor de carga. A continuación, las tareas se compensan entre los programadores. Si un programador está excesivamente comprometido, otros programadores deben hacerse cargo de algunas de las tareas de sus, y viceversa.
Fase de Dirección
La ejecución de las tareas se lleva a cabo durante la fase de dirección de la planificación de la iteración.
  • Obtenga una tarjeta de tarea: El programador tiene la tarjeta de tarea para una de las tareas a las que él o ella ha cometido.
  • Encuentre un socio: El programador incorpora esta tarea, junto con otro programador. Esto se discute en la práctica de la programación en parejas .
  • Diseño de la tarea: Si es necesario, a los programadores a diseñar la funcionalidad de la tarea.
  • Escribir prueba de unidad : Antes de que los programadores empiezan a codificar la funcionalidad que escribir primero las pruebas automatizadas. Esto se discute en la prueba de la unidad práctica.
  • Escriba el código: Los programadores empiezan a codificar.
  • Ejecutar la prueba: Las pruebas unitarias se realizan para probar el código.
  • Refactorizar : eliminar cualquier código de los olores desde el código.
  • Ejecutar funcional de prueba: las pruebas funcionales (sobre la base de los requisitos en la historia de usuario asociada y la tarjeta de trabajo) se ejecutan.

Test Driven Development

Las pruebas unitarias son pruebas automatizadas que ponen a prueba la funcionalidad de las piezas del código (por ejemplo, clases, métodos). En XP, las pruebas unitarias se escriben antes que el código final se codifica. Este enfoque tiene por objeto estimular al programador a pensar sobre las condiciones en que su código puede fallar. XP dice que el programador ha terminado con una determinada pieza de código cuando él o ella no puede llegar a ninguna otra condición en la que el código puede fallar.

Todo el equipo


En XP, el "cliente" no es el que paga la cuenta, pero el que realmente utiliza el sistema. XP dice que el cliente debe tener a la mano en todo momento y disponibles para preguntas. Por ejemplo, el equipo de desarrollo de un sistema de administración financiera debe incluir un administrador financiero.


Proceso continuo

La integración continua

El equipo de desarrollo siempre debe estar trabajando en la versión más reciente del software. Dado que diferentes miembros del equipo pueden tener versiones guardadas localmente con varios cambios y mejoras, deben tratar de subir su versión actual en el repositorio de código de cada pocas horas, o cuando una ruptura significativa se presenta. La integración continua evitará retrasos más tarde en el ciclo de los proyectos, causada por problemas de integración.

Diseño de mejora

Debido a que la doctrina defiende la programación de XP sólo lo que se necesita hoy en día, y su aplicación más sencilla posible, a veces esto puede resultar en un sistema que se ha quedado atascado. Uno de los síntomas de esto es la necesidad de una doble (o múltiple) de mantenimiento: cambios funcionales empezar a requerir cambios en las múltiples copias de la misma (o similar) de código. Otro síntoma es que los cambios en una parte del código afectan a muchas otras partes. XP doctrina dice que cuando esto ocurre, el sistema le está diciendo a refactorizar el código, cambiando la arquitectura, por lo que es más simple y más genérico.

Las pequeñas emisiones

La entrega del software se realiza a través de lanzamientos frecuentes de la funcionalidad en vivo, creando un valor concreto. Las pequeñas emisiones ayudar al cliente a adquirir confianza en el progreso del proyecto. Esto ayuda a mantener el concepto de todo el equipo que el cliente puede llegar a sus sugerencias sobre el proyecto basado en la experiencia real.


La comprensión compartida

La codificación estándar

La codificación estándar es un conjunto acordado de normas que el equipo de desarrollo de acuerdo a adherirse a lo largo del proyecto. La norma especifica un estilo consistente y el formato de código fuente, en el lenguaje de programación elegido, así como diversas construcciones de programación y los patrones que deben ser evitados con el fin de reducir la probabilidad de defectos. [3] El estándar de codificación puede ser una serie de convenciones estándar especificada por el fabricante idioma (por ejemplo, las convenciones de codificación para el lenguaje de programación Java, recomendado por Sun), o personalizado definido por el equipo de desarrollo.

Propiedad colectiva del código

Propiedad colectiva del código significa que cada uno es responsable de todo el código, lo que, a su vez, significa que todo el mundo se le permite cambiar cualquier parte del código. La programación en parejas contribuye a esta práctica: por el trabajo en parejas diferentes, todos los programadores la oportunidad de ver todas las partes del código. Una gran ventaja reclamada por la propiedad colectiva es que se acelera el proceso de desarrollo, ya que si se produce un error en el código de cualquier programador puede arreglarlo.
Al dar a todos los programadores el derecho a modificar el código, no hay riesgo de errores que se introducen por los programadores que creen que saben lo que están haciendo, pero no prevén ciertas dependencias. Suficientemente bien definidas las pruebas de unidad frente a este problema: si las dependencias imprevistas crear errores, a continuación, cuando se ejecutan las pruebas unitarias, se muestran las fallas.

El diseño simple

Los programadores deben tener un "simple es lo mejor" para el diseño de software. Cada vez que una nueva pieza de código está escrito, el autor debe preguntarse a sí mismos 'hay una manera más sencilla de introducir la misma funcionalidad?'. Si la respuesta es sí, el curso más sencillo debe ser elegido. Refactorización también se debe utilizar, para hacer más sencillo el código complejo.

Sistema de la metáfora


La metáfora del sistema es una historia que todo el mundo - los clientes, programadores y administradores - se puede decir acerca de cómo funciona el sistema. Es un concepto de nomenclatura para las clases y métodos que deberían hacer que sea fácil para un miembro del equipo de adivinar la funcionalidad de un método particular de clase /, a partir de su propio nombre. Por ejemplo, un sistema de bibliotecas pueden crear loan_records (clase) para los prestatarios (clase), y si el tema se convirtiera en mora, puede realizar una operación de make_overdue en un catálogo (de clase). Para cada clase o el funcionamiento de la funcionalidad es obvio para todo el equipo.


Programador de bienestar

ritmo sostenible

El concepto es que los programadores o desarrolladores de software no deben trabajar más de 40 horas a la semana, y si hay horas extras de una semana, que la semana que viene no debe incluir más horas extras. Dado que los ciclos de desarrollo son los ciclos cortos de integración continua y completa los ciclos de desarrollo (la liberación) son más frecuentes, los proyectos de XP no siguen la hora de la verdad típico que requieren otros proyectos (que requiere horas extras).
Además, se incluyen en este concepto es que las personas se desempeñan mejor y más creativa si están descansados.
Un factor clave para lograr ritmo sostenible es frecuente el código de combinación de correspondencia y siempre ejecutable y prueba de código cubierto por la alta calidad. La forma en la refactorización constante de los miembros del equipo de trabajo cumplir con la mente fresca y alerta. La manera intensa de colaboración de trabajo dentro del equipo conduce a la necesidad de recargar los fines de semana.
Bien probado, de forma continua integrada, código de frecuencia desplegada y ambientes también reducir al mínimo la frecuencia de los problemas de producción y cortes inesperados, y la asociada después de horas de trabajo noches y fines de semana que se requiere.


Véase también


Referencias

  1. ^ Beck, K. Extreme Programming Explained: Embrace Change segundo. ed. Addison-Wesley, 2000 pp 54
  2. ^ Melnik, Grigori; Maurer, Frank (2004). "Introducción a los Métodos Ágiles: Tres años de experiencia". Actas de la 30 ª Conferencia Euromicro. IEEE. . pp 334-341 DOI : 10.1109/EURMIC.2004.1333388 .
  3. ^ . Kolawa, Adán, Huizinga, Dorota (2007) la prevención de defectos Automatizado: Las Mejores Prácticas en la Gestión de Software . Wiley-IEEE Computer Society Press. pág. 75. ISBN 0-470-04212-5 .


Enlaces externos





Extreme Programming Explained: Embrace Change (Libro en ingles)

Fuente: books.google.com.ar


Ver Libro ...

Escrito por Kent Beck




Reglas y Prácticas en eXtreme Programming [PDF]

Fuente: etnassoft.com

Ficha Técnica:
  • Título: Reglas y Prácticas en eXtreme Programming
  • Autor(es):José Joskowicz
  • Publicación:2008
  • Editorial:Autoedición
  • Núm. Páginas:22p.
  • Tamaño:93 Kbs (zip)
  • Idioma:Español

Contenido

“Extreme Programming” o “Programación Extrema” es una de las llamadas metodologías ágiles de desarrollo de software más exitosas y controversiales de los tiempos recientes. El presente trabajo presenta un resumen de las características más destacables de esta metodología, incluyendo las fases de su ciclo de vida, las reglas y prácticas propuestas, sus valores y su aplicabilidad.
Finalmente se presentan algunas críticas, y se cita el resultado de encuestas recientes realizadas acerca del uso y éxito de las prácticas de ésta nueva metodología.
Extreme Programming (XP) surge como una nueva manera de encarar proyectos de software, proponiendo una metodología basada esencialmente en la simplicidad y agilidad. Las metodologías de desarrollo de software tradicionales (ciclo de vida en cascada, evolutivo, en espiral, iterativo, etc.) aparecen, comparados con los nuevos métodos propuestos en XP, como pesados y poco eficientes. La crítica más frecuente a estas metodologías “clásicas” es que son demasiado burocráticas. Hay tanto que hacer para seguir la metodología que, a veces, el ritmo entero del desarrollo se retarda. Como respuesta a esto, se ha visto en los últimos tiempos el surgimiento de “Metodologías Ágiles”. Estos nuevos métodos buscan un punto medio entre la ausencia de procesos y el abuso de los mismos, proponiendo un proceso cuyo esfuerzo valga la pena.

Ing. José Joskowicz




Una explicación de la programación extrema (XP) [PDF]

Fuente: docs.google.com

V Encuentro usuarios xBase 2003 MADRID


Manuel Calero Solís.




Extreme programming [DOC]

Fuente: docs.google.com

Fausto Alberto Paredes Villarreal
Ingeniería de Software

   


Desarrollo en comunidad con eXtreme Programming [PDF]

Fuente: docs.google.com




Una explicación de la programación extrema XP [PPT]

Fuente: docs.google.com


Metodología XP [Video]

Fuente: youtube.com

Quinto grupo en la serie de exposiciones de Analisis y Diseño de Sistemas de Informacion. Universidad de Oriente Nucleo Monagas

1

2

Subido por  el 22/11/2010




XP - Decisión de Negocio [Video]

Fuente: youtube.com

Extreme Programming es una metodología que abraza el cambio; que mantiene competitiva a las empresas adaptando sus sistemas a las variaciones en el mercado. Seleccionar XP como metodología de desarrollo es una decisión estratégica basada en adquirir y mantener ventajas competitivas en el negocio.

Este video fue realizado como parte del Taller de Introducción a XP, dictado por Imolko.


Subido por  el 31/08/2010




Programacion Extrema - Tests Unitarios - Tarea Zombies - Explicacion Inversion de Control [Video]

Fuente: youtube.com

Video realizado para el curso de Programación Extrema impartido por imolko.com. Imolko es una empresa dedicada a servicios de mercadeo electrónico en Internet que utiliza Programación Extrema como metodología de desarrollo de software.

En este video se explica de una forma muy sencilla, cuál es el concepto de inversión de control y por qué es necesario entenderlo para realizar tests unitarios.

1

2

Subido por  el 25/03/2010




Programación Extrema (Exposicion de Maestria 2007) [Presentación]

Fuente:  slideshare.net


by Edgar Espinoza Silverio on Jul 13, 2008



Introducción Ágil a eXtreme Programming [Presentación]

Fuente: slideshare.net

Introducción resumida a Extreme Programming, actualizada a Agosto de 2008


by ChileAgil on Apr 12, 2008




Seminario MetodologíAs áGiles Y Xp, Extreme Programming [Presentación]

Fuente: slideshare.net



by guest123148 on Jul 09, 2008




Métodos Ágiles-Scrum y XP - [Presentación]

Fuente: slideshare.net



by iscrquinter on Dec 07, 2009

                                 


XPWeb: gestión de proyectos Extreme Programming

Fuente: navegapolis.net

XPWeb es una herramienta web para la gestión de proyectos con Extreme Programming; de uso gratuito con licencia GNU.
Requisitos: PHP4 (recomendado 5), Apache, MySQL (también postgresql). Hay versión en español y cubre todas las funcionalidades básicas para dar soporte a las prácticas de Extreme Programming. Integra una ayuda muy completa.
Hay una demo "on-line" para verlo en funcionamiento, aunque ahora mismo está hospedada sobre PHP4 y no funciona la exportación XML.

                       
Publicado por aegxxi-labBlgr en 2:07
Etiquetas: , ,

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)