MÉTODOS ÁGILES DE PROGRAMACIÓN
SESIÓN 4
6IM7
GONZALEZ GARCIA GONZALO
PARRA GARCILAZO CINTHYA DOLORES
TAREA
Programación extrema
Preguntas
¿Qué es la Programación Extrema?
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.
La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de prácticas correctas que propician un aumento en la productividad a la hora de generar software.
La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar pura lógica.
¿Cuáles son los valores y principios de la Programación Extrema?
Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:
1. Comunicación.
Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
2. Sencillez.
Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
3. Retroalimentación.
Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
4. Valentía.
Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de ‘meter la pata’.
5. Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.
¿Cuáles son las actividades, recursos y prácticas de la Programación Extrema?
Las prácticas son las siguientes:
1. El juego de la planificación (the planning game).
Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
2. Pequeñas entregas (small releases).
Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, no puedes implementar media característica y lanzar la versión.
3. Metáfora (metaphor).
Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
4. Diseño sencillo (simple design).
5. Pruebas (testing).
No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa más seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
6. Refactorización (refactoring).
Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo más simple posible, después de implementar esta característica, nos preguntamos cómo hacer el programa más simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring).
7. Programación por parejas (pair programming).
Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente. Cualquier miembro del equipo se puede emparejar con cualquiera.
8. Propiedad colectiva (collective ownership).
Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
9. Integración continua (continuos integration).
El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
10. 40 horas semanales (40-hour week).
Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche.
Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
11. Cliente en casa (on-site costumer).
Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades.
12. Estándares de codificación (coding standards).
Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.
XP ha sido adoptado por un gran número de equipos en los últimos años y de sus experiencias se ha extraído una conclusión sencilla: es mejor empezar a hacer XP gradualmente.
¿Cuál son las fases del proceso de desarrollo de XP?
El proceso que recomiendan los autores de XP es el siguiente:
- Identifica el principal problema del proceso de desarrollo actual.
- Escoge la práctica que ayuda a resolver ese problema y aplícala. Cuando ese haya dejado de ser un problema, escoge el siguiente. En realidad se recomienda que se apliquen las prácticas de dos en dos. El objetivo es que las prácticas de XP se apoyan unas a otras y por tanto dos prácticas aportan más que la suma de ambas y por tanto es más fácil comprobar los resultados.
- El objetivo final debe ser aplicar todas las prácticas, ya que representan un conjunto completo, "si no las aplicas todas no estás haciendo eXtreme Programming".
En resumen sería Planificación del proyecto, diseño, codificación y pruebas.
¿Qué es una historia de usuario?
Es una representación de un requisito de software escrita por el cliente en 1 a 4 frases en su lenguaje común. Son usadas para la especificación de requerimientos y para estimar tiempos de desarrollo. El tiempo de desarrollo de cada una es entre 1 y 3 semanas.
Las historias de usuario son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requisitos cambiantes.
Referencias Bibliográficas:
Beck, K. (1999) "Extreme Programming Explained. Embrace Change": Pearson Education.
Highsmith, J. (2002) "Agile Software Development Ecosystems". Addison-Wesley
Wells D. (2002) Extreme Programming: A gentle introduction
Martin, R. & Newkirk, J. (2002). La Programacion Extrema en Practica. Pearson Addison-Wesley
No hay comentarios:
Publicar un comentario