Diferencia entre revisiones de «Programación Extrema o XP»
| (No se muestran 15 ediciones intermedias de 4 usuarios) | |||
| Línea 1: | Línea 1: | ||
| − | {{ | + | {{Ficha Software |
| − | + | |nombre=Programación Extrema o XP | |
| − | + | |familia= | |
| − | + | |imagen=1XP.jpg | |
| − | + | |tamaño= | |
| − | + | |descripción=Metodología de desarrollo de Software | |
| − | == | + | |imagen2= |
| − | + | |tamaño2= | |
| − | + | |descripción2= | |
| − | + | |creador=Kent Beck, Ron Jeffries y Ward Cinningham | |
| + | |desarrollador= | ||
| + | |diseñador= | ||
| + | |modelo de desarrollo= | ||
| + | |fecha de creación= | ||
| + | |lanzamiento inicial= | ||
| + | |versiones= | ||
| + | |última versión estable= | ||
| + | |núcleo= | ||
| + | |tipo de núcleo= | ||
| + | |plataformas soportadas= | ||
| + | |género= | ||
| + | |sistemas operativos= | ||
| + | |idioma= | ||
| + | |licencia= | ||
| + | |premios= | ||
| + | |web= | ||
| + | }} | ||
| + | '''Programación Extrema o Extreme Programming. ''' Conocida comúnmente por sus siglas en [[inglés]] XP. Es una [[metodología de desarrollo del software]], enmarcada dentro de las [[metodologías ágiles]] de desarrollo. Constituye la metodología más utilizada dentro del grupo de las ágiles. Su objetivo principal es asegurar la producción de [[software]] con buena calidad y cubriendo las necesidades y requerimientos del usuario. | ||
| + | ==Características Generales de XP== | ||
| + | Surge como posible solución a los problemas derivados del cambio en los requerimientos; esta [[metodología]] ofrece la posibilidad de cambiar los requisitos en cualquier momento de la [[vida]] de un proyecto, ya que es adaptable a estos cambios. Se centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de [[software]], promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen [[clima]] de trabajo. | ||
| + | Este método es típicamente atribuido a [[Kent Beck]], [[Ron Jeffries]] y [[Ward Cinningham]]. El objetivo de Xp son grupos pequeños y medianos de construcción de [[software]] en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto. | ||
XP es un proceso muy orientado a la implementación, en el que se genera poca documentación y en que la funcionalidad exacta del sistema final no se define nunca formal y contractualmente. Es por eso que este método es más aplicable para desarrollos internos. (Palmero Sánchez, [[2007|2007]]) | XP es un proceso muy orientado a la implementación, en el que se genera poca documentación y en que la funcionalidad exacta del sistema final no se define nunca formal y contractualmente. Es por eso que este método es más aplicable para desarrollos internos. (Palmero Sánchez, [[2007|2007]]) | ||
| − | + | ===El ciclo de vida ideal de XP=== | |
| − | + | [[Image:XP 1.jpg|thumb|right|100px|XP 1.jpg]] | |
| − | == El ciclo de vida ideal de XP | ||
| − | |||
| − | [[Image:XP 1.jpg|right|100px|XP]] | ||
| − | |||
El ciclo de vida ideal de XP consta de seis fases: | El ciclo de vida ideal de XP consta de seis fases: | ||
| + | * Exploración. | ||
| + | * Planificación de la Entrega (Release) | ||
| + | * Iteraciones. | ||
| + | * Producción. | ||
| + | * Mantenimiento. | ||
| + | * Muerte del Proyecto. | ||
| − | + | ===Proceso XP=== | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar, basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El [[ciclo de desarrollo]] consiste de manera general en los siguientes pasos: | |
| + | # El cliente define el valor de negocio a implementar. | ||
| + | # El programador estima el esfuerzo necesario para su implementación. | ||
| + | # El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. | ||
| + | # El programador construye ese valor de negocio. | ||
| + | # Vuelve al paso 1. | ||
| − | + | En todas las interaciones de este ciclo tanto el cliente como el [[programador]] aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el [[software]] o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | En todas las | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ==Las Historias de Usuario en XP== | ||
| + | Las historias de usuario son utilizadas por la metodología XP como una técnica para especificar los requisitos del mismo, tanto requisitos no funcionales como funcionales. Se trata de tarjetas en las cuales el usuario describe las características que el sistema debe poseer, de forma muy breve. | ||
Las características fundamentales del método son: | 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. | ||
| + | * 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 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. | ||
| − | + | ==Roles XP== | |
| − | + | [[Image:XP 2.jpg|thumb|right|100px|XP 2.jpg]] La metodología XP de acuerdo con la propuesta original de Kent Beck propone los siguientes roles: | |
| − | + | * Programador. | |
| − | + | * Cliente. | |
| − | + | * Encargado de pruebas (Tester). | |
| − | + | * Encargado de seguimiento (Tracker). | |
| − | == Roles XP | + | * Entrenador (Coach). |
| − | + | * Consultor. | |
| − | [[Image:XP 2.jpg|right|100px|XP]] La metodología XP de acuerdo con la propuesta original de Kent Beck propone los siguientes roles: | + | * Gestor (Big boss). |
| − | |||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | |||
| − | |||
| − | + | ==Ver además == | |
| + | * [[Metodologías de desarrollo]] | ||
| − | + | == Fuentes == | |
| + | * [http://www.monografias.com/trabajos51/programacion-extrema/programacion-extrema.shtml A propósito de programación extrema XP (eXtreme Programming)] | ||
| + | * [http://es.wikipedia.org/wiki/Programacion_Extrema Programación Extrema] | ||
[[Category:Metodologías_de_desarrollo_de_software]] | [[Category:Metodologías_de_desarrollo_de_software]] | ||
última versión al 08:34 12 jun 2012
| ||||||
Programación Extrema o Extreme Programming. Conocida comúnmente por sus siglas en inglés XP. Es una metodología de desarrollo del software, enmarcada dentro de las metodologías ágiles de desarrollo. Constituye la metodología más utilizada dentro del grupo de las ágiles. Su objetivo principal es asegurar la producción de software con buena calidad y cubriendo las necesidades y requerimientos del usuario.
Sumario
Características Generales de XP
Surge como posible solución a los problemas derivados del cambio en los requerimientos; esta metodología ofrece la posibilidad de cambiar los requisitos en cualquier momento de la vida de un proyecto, ya que es adaptable a estos cambios. Se centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto. XP es un proceso muy orientado a la implementación, en el que se genera poca documentación y en que la funcionalidad exacta del sistema final no se define nunca formal y contractualmente. Es por eso que este método es más aplicable para desarrollos internos. (Palmero Sánchez, 2007)
El ciclo de vida ideal de XP
El ciclo de vida ideal de XP consta de seis fases:
- Exploración.
- Planificación de la Entrega (Release)
- Iteraciones.
- Producción.
- Mantenimiento.
- Muerte del Proyecto.
Proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar, basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste de manera general en los siguientes pasos:
- El cliente define el valor de negocio a implementar.
- El programador estima el esfuerzo necesario para su implementación.
- El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
- El programador construye ese valor de negocio.
- Vuelve al paso 1.
En todas las interaciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.
Las Historias de Usuario en XP
Las historias de usuario son utilizadas por la metodología XP como una técnica para especificar los requisitos del mismo, tanto requisitos no funcionales como funcionales. Se trata de tarjetas en las cuales el usuario describe las características que el sistema debe poseer, de forma muy breve. 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.
- 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 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.
Roles XP
La metodología XP de acuerdo con la propuesta original de Kent Beck propone los siguientes roles:
- Programador.
- Cliente.
- Encargado de pruebas (Tester).
- Encargado de seguimiento (Tracker).
- Entrenador (Coach).
- Consultor.
- Gestor (Big boss).
