Extreme Programming es una metodología de desarrollo de software diseñada para mejorar la calidad del software y su capacidad de adaptarse adecuadamente a las necesidades cambiantes del cliente o cliente. A mediados y finales de los noventa, mientras trabajaba en el sistema de compensación integral de Chrysler (C3) para ayudar a administrar la nómina de la compañía, El ingeniero de software Ken Beck desarrolló por primera vez la metodología de programación extrema., En octubre de 1999, publicó Extreme Programming Explained, detallando todo el método para otros, y poco después se lanzó el sitio web oficial también.

Similar a otros métodos ágiles de desarrollo, Extreme Programming tiene como objetivo proporcionar versiones pequeñas iterativas y frecuentes a lo largo del proyecto, lo que permite tanto a los miembros del equipo como a los clientes examinar y revisar el progreso del proyecto a lo largo de todo el SDLC.,

a lo largo de este artículo, examinaremos exactamente qué es la programación extrema y cómo funciona, desde los valores y principios que están detrás de ella, hasta las reglas y las mejores prácticas de procedimiento que se utilizan para implementar un nuevo proyecto de programación extrema, ¡así que comencemos!,/td>

Rational Unified Process Big Bang Model V-Model Conceptual Model Kaizen Model Kanban Model Spiral Model

valores extremos

estos cinco valores fundamentales proporcionan la base sobre la que se construye la totalidad del paradigma de programación extrema, lo que permite a las personas involucradas en el proyecto sentirse seguras en la dirección que el proyecto está tomando y comprender que su retroalimentación personal y su visión es tan necesaria y bienvenida como cualquier otra persona.,

simplicidad: haremos lo que se necesita y se pide, pero no más. Esto maximizará el valor creado por la inversión realizada hasta la fecha. Tomaremos pequeños pasos sencillos hacia nuestro objetivo y mitigaremos los fracasos a medida que ocurran. Crearemos algo de lo que estamos orgullosos y lo mantendremos a largo plazo por costos razonables.

comunicación: Todos somos parte del equipo y nos comunicamos cara a cara diariamente. Trabajaremos juntos en todo, desde los requisitos hasta el código. Crearemos la mejor solución a nuestro problema que podamos juntos.,

Feedback: tomaremos en serio cada compromiso de iteración al entregar software de trabajo. Demostramos nuestro software temprano y, a menudo, escuchamos atentamente y hacemos los cambios necesarios. Hablaremos del proyecto y adaptaremos nuestro proceso a él, no al revés.

respeto: todo el mundo da y siente el respeto que se merece como miembro valioso del equipo. Todo el mundo aporta valor aunque sea simplemente entusiasmo. Los desarrolladores respetan la experiencia de los clientes y viceversa. La gerencia respeta nuestro derecho a aceptar responsabilidad y recibir autoridad sobre nuestro propio trabajo.,

coraje: diremos la verdad sobre el progreso y las estimaciones. No documentamos excusas para el fracaso porque planeamos tener éxito. No le tememos a nada porque nadie trabaja solo. Nos adaptaremos a los cambios cuando ocurran.

Extreme Rules

inicialmente publicado por Don Wells en 1999, el propietario del Sitio Web de Extreme Programming, este conjunto de reglas de Extreme Programming fueron originalmente destinadas a ayudar a contrarrestar las afirmaciones de que Extreme Programming no soporta algunas de las disciplinas prominentes necesarias para el desarrollo moderno.,

planificación

• Se escriben historias de usuario.
• Release planning crea el programa de lanzamiento.
• hacer lanzamientos pequeños frecuentes.
• El proyecto se divide en iteraciones.
• La planificación de iteraciones inicia cada iteración.

administrar

• Dar al equipo un espacio de trabajo abierto dedicado.
• Establecer un ritmo sostenible.
• Una reunión de pie comienza cada día.
• Se mide la velocidad del proyecto.
• mueve a la gente.
• arregla la programación extrema cuando se rompe.

Diseño

• la Sencillez.,
• elija una metáfora del sistema.
• utilice tarjetas CRC para sesiones de diseño.
• Crear soluciones de spike para reducir el riesgo.
• No se añade ninguna funcionalidad antes.
• Refactor siempre y cuando sea posible.

Codificación

• El cliente siempre está disponible.
• El código debe escribirse según los estándares acordados.
• codifique primero la prueba unitaria.
• Todo el código de producción está programado por pares.
• solo un par integra código a la vez.
• Integrar a menudo.
• configurar un equipo de integración dedicado.
• Usar propiedad colectiva.,

Testing

• Todo código debe tener pruebas unitarias.
• Todo el código debe pasar todas las pruebas unitarias antes de que pueda ser liberado.
• cuando se encuentra un error se crean pruebas.
• Las pruebas de aceptación se ejecutan a menudo y la puntuación se publica.

Extreme Practices

creadas utilizando lo que se consideraban las mejores prácticas de desarrollo de software en ese momento, estas doce mejores prácticas de programación extrema detallan los procedimientos específicos que deben seguirse al implementar un proyecto utilizando Extreme Programming.,

retroalimentación a escala fina

programación de pares

En esencia, la programación de pares significa que dos personas trabajan en tándem en el mismo sistema al desarrollar cualquier código de producción. Mediante la rotación frecuente de socios en todo el equipo, Extreme Programming promueve una mejor comunicación y la formación de equipos.

juego de planificación

a menudo esto toma la forma de una reunión en un intervalo frecuente y bien definido (cada una o dos semanas), donde se lleva a cabo la mayor parte de la planificación del proyecto.,

dentro de este procedimiento existe la etapa de planificación de la liberación, donde se hacen determinaciones con respecto a lo que se requiere para las liberaciones inminentes. Las secciones de planificación de versiones incluyen:

• Fase de exploración: las tarjetas de historia se utilizan para detallar los requisitos más valiosos de los clientes.
• Fase de compromiso: la planificación y los compromisos del equipo se realizan para satisfacer las necesidades de la próxima versión del calendario y sacarla a tiempo.,
• Steering Phase: esto permite que los planes previamente desarrollados se ajusten en función de las necesidades cambiantes del proyecto, de manera similar a muchas otras metodologías de modelos ágiles.

después de la planificación del lanzamiento está también la sección de planificación de iteración, que consta de las mismas tres sub-fases propias, pero con variantes en sus implementaciones:

• Fase de exploración: todos los requisitos del proyecto están escritos.
• Fase de Compromiso: las tareas necesarias aún por completar para cumplir con la próxima versión de iteración se asignan a los desarrolladores y se programan adecuadamente.,
• Fase de dirección: el desarrollo se lleva a cabo y, al finalizar, la iteración resultante se compara con las tarjetas de historia contorneadas creadas al inicio del procedimiento de planificación.

desarrollo basado en pruebas

si bien se podría escribir un artículo completo sobre desarrollo basado en pruebas, el concepto es bastante conocido entre los desarrolladores y significa efectivamente que se generan pruebas para todos y cada uno de los requisitos del proyecto, y solo entonces se desarrolla código que pasará con éxito esas pruebas.,

Todo el equipo

Al igual que con muchos otros métodos y prácticas SDLC, Extreme Programming promueve la inclusión de clientes y clientes a lo largo de todo el proceso, utilizando sus comentarios para ayudar a dar forma al proyecto en todo momento.

proceso continuo

integración continua

otra práctica común en el desarrollo moderno, la idea detrás de la integración continua es que todo el código desarrollado a través de todo el equipo se fusiona en un repositorio común muchas veces al día., Esto asegura que cualquier problema con la integración en todo el proyecto sea notado y tratado tan pronto como sea posible.

refactorización de código

otra práctica muy común, la idea detrás de la refactorización de código es simplemente mejorar y rediseñar la estructura del código ya existente, sin modificar su comportamiento fundamental. Ejemplos simples de refactorización incluyen la fijación de nombres incorrectos variables o métodos, y la reducción de código repetido a un solo método o función.,

versiones Pequeñas

muy en línea con las prácticas del modelo iterativo, este concepto garantiza que el proyecto contará con versiones pequeñas iteradas de forma frecuente, lo que permite al cliente, así como a todos los miembros del equipo, tener una idea de cómo se está desarrollando el proyecto.

comprensión compartida

estándares de codificación

el estándar de codificación es simplemente un conjunto de mejores prácticas dentro del código en sí, como el formato y el estilo, que todo el equipo cumple durante todo el ciclo de vida del proyecto., Esto promueve una mejor comprensión y legibilidad del código no solo para los miembros actuales, sino también para los futuros desarrolladores.

propiedad colectiva del código

Esta práctica permite a cualquier desarrollador del equipo cambiar cualquier sección del Código, según sea necesario. Si bien esta práctica puede sonar peligrosa para algunos, acelera el tiempo de desarrollo, y cualquier problema potencial puede ser sofocado con pruebas unitarias adecuadas.

diseño Simple

Hay pocas razones para complicar las cosas cada vez que una opción más simple está disponible., Esta práctica básica de mantener todos los componentes y el código tan simple como sea posible garantiza que todo el equipo siempre esté evaluando si las cosas se podrían hacer de una manera más fácil.

metáfora del sistema

Mejor pensada como parte de los estándares de codificación, la metáfora del sistema es la idea de que cada persona en el equipo debe ser capaz de mirar el código de alto nivel que se desarrolla, y tener una comprensión clara de qué funcionalidad está realizando ese código.,

Programmer welfare

Sustainable pace

Un concepto clave para un mejor equilibrio entre el trabajo y la vida personal con los desarrolladores en un proyecto de programación extrema es la noción de que a nadie se le debe exigir que trabaje más allá de la semana normal de trabajo programada. Las horas extras están mal vistas, al igual que el concepto de «tiempo de crisis», donde se espera que los desarrolladores trabajen horas extremas cerca del final de una versión para completar todo a tiempo.