METODOLOGÍA XP
Ventajas
- Programación organizada.
- Menor taza de errores.
- Satisfacción del programador.
- Solución de errores de programas
- Versiones nuevas
- Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias
|
Desventajas
- Es recomendable emplearlo solo en proyectos a corto plazo
- Altas comisiones en caso de fallar
- Imposible prever todo antes de programar
- Demasiado costoso e innecesario
|
Entendimiento
1. Diseño simple: se busca en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla l. 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 cómo 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. Como dice Beck, está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.
PROCESO DE DESARROLLO:
La programación extrema parte del caso habitual de una compañía que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo.
1. Interacción con el cliente
En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones. En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista de características que el cliente necesita que existan en el producto final. Estas constan de dos fases:
En la primera fase, el cliente describe con sus propias palabras las características y, es el responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tienen pera él. De esta manera ya es posible definir unas fechas aproximadas para ellos.
En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de trabajo, esto dará como resultado una planificación más exacta. Este método se repetirá para cada historia.
PLANIFICACIÓN DEL PROYECTO
En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes interaciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada interacción, el cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente.
Una de las máximas a aplicar es, los cambios, no han de suponer más horas de programación para el programador, ya que el que no se termina en un día, se deja para el día siguiente.
Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán mecanismos de revisión. Cada tres o cinco interacciones es normal revisar las historias de los usuarios, y re negociar la planificación.
Cada interacción necesita también ser planificada, es lo que se llama planificación iterativa, en la que se anotarán las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días.
Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no han estado programados.
Este tipo de planificación en interacciones y el diseño iterativo, hace que aparezca una práctica que no existía en la programación tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos.
EJEMPLO:
http://fcaenlinea1.unam.mx/anexos/1656/1656_u2_act5.pdf
