Método de desarrollo ágil - Programación extrema XP
2025-02-10 15:36:00 1 Informe
Inicie sesión para ver el contenido completo
El método de desarrollo ágil, conocido como Programación Extrema o XP, es una innovadora estrategia de ingeniería de software que prioriza la adaptabilidad sobre la predictibilidad. Fundado por visionarios como Kent Beck, Ward Cunningham y Ron Jeffries, XP busca reducir los costos asociados a cambios inevitables en los requisitos del sistema, especialmente en campos de rápida evolución. A través de prácticas como la programación en pareja, ciclos de entrega cortos y un diseño simple, XP fomenta la comunicación, la retroalimentación rápida y el coraje para aceptar cambios. Este enfoque iterativo y colaborativo mejora la calidad y eficiencia del desarrollo de software.
Otras obras del autor
Esquema/Contenido
Los 4 valores del Extreme Programming
Comunicación
Una de las tareas básicas de un sistema de software
Comunicarse con los desarrolladores del sistema para aclarar los requisitos específicos del sistema.
El objetivo es proporcionar a todos los desarrolladores una perspectiva compartida del sistema,
y que esta perspectiva coincida con la de los usuarios finales del sistema.
y que esta perspectiva coincida con la de los usuarios finales del sistema.
Fomentar la comunicación oral frecuente y la retroalimentación
simple
Comience con el método de solución más simple.
Lograr mejores resultados a través de una continua reestructuración
Concéntrese únicamente en el diseño y codificación para las necesidades actuales,
y no preste atención a las necesidades que puedan surgir mañana, la próxima semana o el próximo mes.
y no preste atención a las necesidades que puedan surgir mañana, la próxima semana o el próximo mes.
Es muy probable que las necesidades futuras cambien antes de que las hayan planteado.
La simplificación en el diseño y el código puede mejorar la calidad de la comunicación.
Respuesta
La retroalimentación lo más rápido posible.
"La retroalimentación" está relacionada con muchos aspectos diferentes del desarrollo del sistema
Feedback del sistema
Pruebas unitarias
Obtener de manera intuitiva el estado del sistema después de las modificaciones.
De los clientes, retroalimentación.
Pruebas funcionales
Los clientes y los probadores escriben
Conocer el estado actual del sistema
Planeo hacerlo una vez cada 2 o 3 semanas.
Los clientes pueden entender y controlar fácilmente el progreso del desarrollo.
De la retroalimentación del grupo
El cliente acude a la reunión de planificación del proyecto con nuevas necesidades.
El equipo puede evaluar directamente el tiempo necesario para implementar los nuevos requisitos y luego proporcionar la retroalimentación al cliente.
La retroalimentación está estrechamente relacionada con los valores de "comunicación" y "simplicidad".
Defectos en el sistema de comunicación
Escribir pruebas unitarias
Demostrar sencillamente que un fragmento de código tiene un problema
Los usuarios realizan pruebas periódicas en el sistema basándose en los requisitos funcionales definidos.
El optimismo en la programación es peligroso, y la retroalimentación oportuna es el método para resolverlo.
Kent Beck
Coraje
Diseñado y codificado solo para las necesidades de hoy,
no consideres el mañana.
no consideres el mañana.
Evitar caer en el fango del diseño y, en cambio,
gastar demasiada energía innecesaria en otros problemas
gastar demasiada energía innecesaria en otros problemas
cuando necesiten reestructurar su código se sientan cómodos
Revisar y perfeccionar el sistema existente
Los cambios futuros serán más fáciles de implementar.
Entender cuándo se debe descartar por completo el código existente
Pasé todo el día enredado en un problema complejo de mi propio diseño y código
sin obtener nada
sin obtener nada
Al día siguiente, considera con una perspectiva nueva y clara.
En media hora se resuelve fácilmente.
Los 5 principios de la programación extrema
Retroalimentación rápida
Respuesta oportuna y rápida
Cliente
Proporcionar retroalimentación oportuna durante todo el proceso de desarrollo.
Ser capaz de controlar la dirección de desarrollo del sistema cuando sea necesario
Pruebas unitarias
También juega un papel en la aplicación del principio de retroalimentación.
Suposición simple
Cualquier problema se puede resolver de manera "extremadamente simple".
Métodos tradicionales de desarrollo de sistemas
Considerar los cambios futuros
Considera la reutilización del código
El Extreme Programming se niega a hacerlo así.
Cambio incremental
Roma no se construyó en un día.
Por ejemplo
Cada tres semanas se publica una nueva versión que incluye pequeños cambios.
Un paso a la vez avanzando.
Abrazar el cambio
No adoptes una actitud de resistencia ante los cambios, sino más bien, acéptalos.
Por ejemplo, en una reunión de etapa, el cliente planteó algunos requisitos aparentemente dramáticos.
Como programador, debes abrazar estos cambios,
y planificar para que el próximo producto satisfaga los nuevos requisitos.
Como programador, debes abrazar estos cambios,
y planificar para que el próximo producto satisfaga los nuevos requisitos.
trabajo de alta calidad
cuatro variables de desarrollo de software
Alcance
Tiempo
costo
calidad
La calidad no es negociable.
Programación extrema
Programación extrema
Extreme programming
Abreviado como XP
Un método de ingeniería de software
Diferente
Más enfatiza la adaptabilidad que la predictibilidad
fundador
Kent Beck, Ward Cunningham
Ron Jeffries
El objetivo de la programación extrema
Reducir los costos derivados de cambios en los requisitos
Los requisitos del sistema deben ser establecidos al comienzo de la fase de desarrollo del proyecto.
Cuando el desarrollo del proyecto entra en etapas posteriores, los cambios de requisitos que surgen provocarán un aumento drástico en los costos de desarrollo, y tales cambios de requisitos son inevitables en algunos campos que se desarrollan extremadamente rápido.
Mediante la introducción de conceptos como valores básicos, principios, métodos, etc.
El propósito de reducir los costos de cambio
Las 12 prácticas centrales de Extreme Programming
Ciclo de entrega corto
Al igual que Scrum, utiliza un método de entrega iterativo.
Cada iteración toma de 1 a 3 semanas.
Iteración finalizada
Equipo entrega funcionalidad probada y operativa
Estas funciones pueden ser puestas en uso inmediatamente.
Plan de juego
Dos preguntas
¿Cuánto trabajo se puede completar antes de la fecha de entrega?
¿Qué hacer ahora y en el siguiente paso?
Respondiendo constantemente a estas dos preguntas
Para dos problemas, dos procesos correspondientes.
Planificación de lanzamiento de software (Release Planning)
Según el costo de desarrollo, los riesgos y la importancia de cada requisito, elabore un plan general del proyecto.
El plan inicial del proyecto no es necesario (ni posible) que sea muy preciso.
Planificación de Iteración
Durante el proceso de desarrollo
Hay muchos planes de etapas.
Por ejemplo, un plan cada tres semanas.
Durante un cierto ciclo, realice una reorganización y optimización interna del sistema (código y diseño).
En algún ciclo se ha añadido una nueva función.
Se realizará trabajo en ambos aspectos dentro de un ciclo.
Tiene sus ventajas y desventajas.
Ventajas
Los clientes pueden saber de inmediato
¿Qué se ha completado?
¿Es útil lo que se ha hecho?
¿Qué más hay que hacer o mejorar?
Desventajas
Al ver el producto terminado, es posible que se sienta muy insatisfecho e incluso decida rescindir el contrato.
Para detectar y resolver problemas temprano
Programación en pareja
Dos personas están sentadas frente a una computadora trabajando juntas.
Un programador controla la computadora y principalmente considera los detalles del código.
Otra persona se enfoca principalmente en la estructura general.
Continuamente revisando el código escrito por el primer programador
La asociación no es fija.
ritmo sostenible
Esfuerzo constante a una velocidad sostenida a largo plazo
Ahorrar energía
Considera el proyecto como una maratón.
en lugar de correr a toda velocidad
Código de propiedad colectiva
Cada persona es responsable de todo el código.
Cualquiera puede cambiar cualquier parte del código.
La programación en equipo contribuye mucho a esta práctica.
Trabajar en diferentes equipos
Todos los programadores pueden ver el código completo.
Normas de codificación
Todas las personas siguen un estándar de programación unificado.
Todos los códigos parecen haber sido escritos por una sola persona.
Diseño simple
No hay un diseño general único y exhaustivo para todas las necesidades en el modelo tradicional de desarrollo.
El proceso de diseño casi siempre ocurre durante todo el proceso de desarrollo del proyecto.
desde la elaboración del plan del proyecto
Hasta la elaboración del plan para cada ciclo de desarrollo (Iteration)
al diseño simplificado para cada módulo de requisito
Revisión del diseño
así como un rediseño y optimización ininterrumpidos
El proceso de diseño entero es un proceso de avance y desarrollo en espiral, que siempre progresa.
Desarrollo guiado por pruebas
Reestructuración
Metáfora del sistema
Integración continua
El equipo de desarrollo de XP utiliza muchas metáforas vívidas para describir cómo funcionan los sistemas o módulos de功能.
Cliente en el sitio
Cliente
No es la persona que paga por el sistema.
sino las personas que realmente utilizan el sistema
Cliente
Esté siempre presente para resolver problemas.
Escribir una historia
Pruebas de aceptación
交流os y discusiones más frecuentes
Recolectar
Recolectar
Recolectar
0 Comentarios
Página siguiente
Recomendado para ti
Ver más
