Programacion extrema - Historial de revisiones

Leandro.bronard en 16:45 13 oct 2022

2022-10-13T16:45:31Z

Majibacoa2 jc en 18:37 3 may 2011

2011-05-03T18:37:44Z

Humberto0601ad jc en 14:39 17 may 2010

2010-05-17T14:39:00Z

Humberto0601ad jc en 13:50 17 may 2010

2010-05-17T13:50:40Z

Mostrar los cambios

Humberto0601ad jc: /* Fuentes */

2010-05-14T18:26:43Z

‎Fuentes

Humberto0601ad jc: /* Fuentes */

2010-05-14T18:13:52Z

‎Fuentes

Kenia idict en 15:58 14 may 2010

2010-05-14T15:58:19Z

Majibacoa3 jc: Página creada con ''''Programación Extrema'''
La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que p…'

2010-05-12T21:06:10Z

Página creada con ''''Programación Extrema''' La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que p…'

Página nueva

'''Programación Extrema''' La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación. Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software. El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.

= Metodologías Ágiles =

Las metodologías ágiles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc...). Forman parte del movimiento de desarrollo ágil de sotfware, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto. De forma que una metodología ágil es la que tiene como principios que: • Los individuos y sus interacciones son más importantes que los procesos y las herramientas • El software que funciona es más importante que la documentación exhaustiva. • La colaboración con el cliente en lugar de la negociación de contratos. • La respuesta delante del cambio en lugar de seguir un plan cerrado. 

= Historia =

 La Programación Extrema, como proceso de creación de software diferente al convencional, nace de la mano de Kent Beck (autor de los libros más influyentes sobre el tema). 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. Beck reconoció que el proceso (o metodología) de creación de software o la carencia de este era la causa de todos los problemas y llegó a la conclusión que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenían que acomodar al cambio a realizar. El tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema. 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 dentro del equipo, que la implementación fuera sencilla, que el usuario tenía que estar muy informado y implicado y que la toma de decisiones tenía que ser muy rápida y efectiva. Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programación Extrema, fueron a la 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. Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. Fue tanta esta molestia que nació el fenómeno XP Free Zone (zona libre de XP) en determinadas webs como petición de no hablar de Programación Extrema en ella. La discusión sobre temas de diseño de modelos de programación sobre los cambios recientes se hizo tema difícil porque la mayoría de la actividad fue relacionada con la Programación Extrema. 

= Principios básicos =

 La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías:

=== • Retroalimentación a escala fina. ===

 1. El principio de pruebas: se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. 2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones periódicas durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico. 3. El cliente en el sitio: se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento. Este representante del cliente estará con el equipo de trabajo durante toda la realización del proyecto.

4. Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones más buenas, de manera consistente, a iguales o menores costes.

=== • Proceso continuo en lugar de por lotes. ===

 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. Esto reduce los problemas de integración comunes en proyectos largos y estilo cascada. 2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y re codifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado y/o ineficiente. 3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo.

=== • Entendimiento compartido. ===

 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla. 2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de como funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). 3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán. 4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.

=== • Bienestar del programador. ===

 1. La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. 

 

= Concluciones =

La Programacion extrema tiene muchas criticas especialmente contra la pair programing – sobre todo por parte de muchos programadores con gran sentimiento de posesión del código, piensan que ellos son los mejores conocedores de las herramientas y lenguajes que utilizan y que si no lo entiendes es por que no sabes lo suficiente. Las metodologías tradicionales imponen un proceso disciplinado para tratar de hacer el trabajo predecible, eficiente y planificado. Estos métodos están orientados a documentos y se vuelven demasiado burocráticas e ineficaces. XP es más liviana y ágil y están orientadas más a las personas que a los procesos. Por lo que supone que: •Las personas son claves en los procesos de desarrollo. •Los programadores son profesionales no necesitan supervisión. •Los procesos se aceptan y se acuerdan, no se imponen. •Desarrolladores y gerentes comparten el liderazgo del proyecto. •El trabajo de los desarrolladores con las personas que conocen el negocio es regular, no puntual. 

 

= Fuentes =

www.agile-spain.com 

www.design-up.com/methodes/XP 

www.programacionextrema.org 

www.extremeprogramming.org 

Una explicación de la Programación extrema: aceptar el cambio. Kent Beck 

[[Category:Herramientas_de_programación]]

← Revisión anterior		Revisión del 16:45 13 oct 2022
Línea 1:		Línea 1:
−	~~{{Software~~
−	~~\|nombre=Programación extrema~~
−	~~\|logo=~~
−	~~\|descripcion=Metodología de desarrollo ligera.~~
−	~~\|creador=[[Kent Beck]]~~
−	~~\|fecha_de_creacion=[[1996]]~~
−	~~\|versiones=~~
−	~~\|sitio_web=[http://www.extremeprogramming.org/ Programación extrema] (en inglés)~~
−	}}

		+	{{Ficha Software \|nombre=Programación extrema \|familia= \|imagen= \|tamaño= \|descripción= \|imagen2= \|tamaño2= \|descripción2= \|creador= [[Kent Beck]]\|desarrollador= \|diseñador= \|modelo de desarrollo= \|fecha de creación= [[1996]]\|lanzamiento inicial= \|versiones= \|última versión estable= \|núcleo= \|tipo de núcleo= \|plataformas soportadas= \|género= \|sistemas operativos= \|idioma= inglés\|licencia= \|premios= \|web= http://www.extremeprogramming.org}}
	La '''programación extrema''' es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.		La '''programación extrema''' es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

@@ Línea 63: / Línea 63: @@
 La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad.
-== Valores ==
+== 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.
+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.
+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|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 que 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.
+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''':
 Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad.
-La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (''frameworks'') mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas aproximaciones.
+Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (''frameworks'') mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas aproximaciones.
 *'''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, si no orientandolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de produccion en el  equipo.
 == Características fundamentales ==

← Revisión anterior		Revisión del 14:39 17 may 2010
Línea 1:		Línea 1:
−	La '''programación extrema''' es una metodología de desarrollo ligera (o ágil) basada en una ~~serie51~~ de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.	+	{{Software
		+	\|nombre=Programación extrema
		+	\|logo=
		+	\|descripcion=Metodología de desarrollo ligera.
		+	\|creador=[[Kent Beck]]
		+	\|fecha_de_creacion=[[1996]]
		+	\|versiones=
		+	\|sitio_web=[http://www.extremeprogramming.org/ Programación extrema] (en inglés)
		+	}}
		+
		+	La '''programación extrema''' es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

	Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación.		Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación.

@@ Línea 42: / Línea 42: @@
 = Fuentes =
-* [www.agile-spain.com Agile Spain]
+* [http://www.agile-spain.com Agile Spain]
-* [www.design-up.com/methodes/XP XP]
+* [http://www.design-up.com/methodes/XP XP]
-* [www.programacionextrema.org Programación Extrema]
+* [http://www.programacionextrema.org Programación Extrema]
-* [www.extremeprogramming.org Extreme Programming]
+* [http://www.extremeprogramming.org Extreme Programming]
-* Una explicación de la Programación extrema: aceptar el cambio. Kent Beck
+* Una explicación de la Programación extrema: aceptar el cambio. [[Kent Beck]].
 [[Category:Herramientas_de_programación]]

@@ Línea 40: / Línea 40: @@
 <br>
-= Fuentes<br>  =
+= Fuentes =
-www.agile-spain.com<br>
+* [www.agile-spain.com Agile Spain]
+* [www.design-up.com/methodes/XP XP]
-www.design-up.com/methodes/XP<br>
+* [www.programacionextrema.org Programación Extrema]
+* [www.extremeprogramming.org Extreme Programming]
-www.programacionextrema.org<br>
+* Una explicación de la Programación extrema: aceptar el cambio. Kent Beck
 [[Category:Herramientas_de_programación]]

← Revisión anterior		Revisión del 15:58 14 may 2010
Línea 1:		Línea 1:
−	'''Programación Extrema'''<br>La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una ~~serie~~ de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.<br>Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación.<br>Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software. <br>El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.	+	{{Mejorar\|vínculos en el texto}}
		+	'''Programación Extrema'''<br>La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie51 de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.<br>Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación.<br>Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software. <br>El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.

	= Metodologías Ágiles =		= Metodologías Ágiles =

Programacion extrema - Historial de revisiones

Leandro.bronard en 16:45 13 oct 2022

Majibacoa2 jc en 18:37 3 may 2011

Humberto0601ad jc en 14:39 17 may 2010

Humberto0601ad jc en 13:50 17 may 2010

Humberto0601ad jc: /* Fuentes */

Humberto0601ad jc: /* Fuentes */

Kenia idict en 15:58 14 may 2010

Majibacoa3 jc: Página creada con ''''Programación Extrema'''La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que p…'

Majibacoa3 jc: Página creada con ''''Programación Extrema'''
La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que p…'