QUIZ PROYECTO DE GRADO

Para poder realizar el quiz por favor dar CLIC AQUI

TECNICAS DE ANALISIS

LA IDENTIFICACIÓN DE LOS REQUERIMIENTOS

                                                                                                                                

Un requerimiento es una característica necesaria que deberá poseer el nuevo sistema.

Por otra parte, la determinación de requerimientos es el estudio de un sistema para comprender cómo trabaja y dónde es necesario efectuar mejoras.

Ahora bien, existen tres formas (actividades) de determinar de requerimientos, a saber

• Anticipación de requerimientos: prever las características del nuevo sistema con base en experiencia previa.

• Investigación de requerimientos: actividad más importante del análisis de sistemas. Es el estudio y documentación del sistema actual usando para ellos técnicas de para hallar hechos, análisis de flujo de datos y análisis de decisión. Es aquí donde aplicamos entrevistas, cuestionarios, observación y revisión de documentación entre otros.

• Especificación de requerimientos: los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripción de las características del nuevo sistema. Esta actividad tiene tres partes relacionadas entre sí, a saber:

• Análisis de datos basados en hechos reales

• Identificación de requerimientos esenciales

• Selección de estrategias para satisfacer los requerimientos

Todo sistema de información posee un conjunto de requerimientos básicos y un conjunto de requerimientos específicos dependiendo si el sistema será de soporte para transacciones o para la toma de decisiones.

                              

LISTA DE VERIFICACIÓN (CHECK-LIST)

Las Planillas de Verificación, o "Check-List" en idioma inglés, son listados de ítems. Hay dos tipos diferentes de ellos:

ü  Listado de elementos

ü  Secuencia de acciones.

Básicamente en ellas se pone información en forma concisa, la cual es revisada como procedimiento para "no olvidarse de nada", siendo típica su aplicación en las jornadas de lanzamiento, o pruebas en el campo.

·         Importancia De Las Listas De Verificación (Lv)

Muestra que es fundamental su aplicación para asegurar que no se está olvidando nada, ni se salteo algún paso al realizar lanzamientos o pruebas en el campo.

En general se subvalora su importancia y tiende a no usárselas, entonces se termina aprendiendo por el camino desagradable que son imprescindibles.
Cosas que parecen sencillas y obvias son olvidadas en algún momento y eso lleva a errores que pueden tener graves consecuencias. Es increíble como los nervios, la tensión y excitación que se vive en momentos de preparar un lanzamiento pueden hacer olvidar ítems esenciales.

·         Prepare Y Use Listas De Verificación

  La Lista de Verificación aplicada como "listado de elementos":

La Lista de Verificación usada como "listado de elementos" es aplicable para verificar que se tenga, o se esté llevando, todo lo necesario para las actividades a realizar.
Al redactarla con tiempo, e ir revisándola varias veces, permite detectar elementos que estarían faltando, o que podrían ser útiles. No dejar de anotar cosas que parecen obvias como documentos personales, carnet de la asociación cohetera, documentación de vehículo (si se lo utiliza), permisos escritos para hacer usos de espacios privados, etc. No olvidarse tampoco de una madera o chapa donde apoyar la planilla para escribir sobre ella y con algo para sujetar la hoja de papel para que no se vuele.

Otro aspecto importante en el uso de las LV es ir anotando en forma manuscrita y provisoria todo lo que durante las actividades vaya apareciendo como útil de incorporar en las LV. En general lo más sencillo es hacerlo al dorso de las mismas. Luego para la próxima actividad se las prolija y ordena.

Estos Listados se pueden preparar en una computadora personal (PC) por la facilidad de armado, corrección y actualización de las mismas. Básicamente se genera una lista o planilla "madre", a la cual se revisa y adecúa para cada ocasión en particular.

·         La Lista De Verificación Aplicada Como "Secuencia De Acciones O Procedimientos"

La LV usada como "verificación de secuencias de acciones o procedimientos" es un listado de la secuencia de acciones, o verificaciones, u operaciones a realizar, como por ejemplo para el lanzamiento de un cohete o en una prueba estática.
Es increíble con qué facilidad se olvida uno de sacar una clavija de seguridad o mover una llave. El resultado es que por un detalle menor se arruina el esfuerzo y la satisfacción de un trabajo bien realizado.

Estos Listados también se recomienda prepararlos en una computadora personal (PC) por la facilidad de armado, corrección y actualización de las mismas. Este tipo de LV (secuencia de acciones) se va armando en general cuando voy haciendo el armado de los elementos del cohete. Al realizar ensayos de los subsistemas voy verificando que tengan todos los pasos necesarios y elementos que se necesite verificar.

·         Quien Controla Los Listados De Verificación?

Para aplicar las LV pueden ser controladas por el propio grupo de investigación pero es recomendable que las maneje un individuo ajeno al proceso.

Por temas de seguridad no es recomendable que haya una sola persona presente durante una prueba, por lo tanto hay disponible otra persona a quien encargar para que vaya leyendo y tildando la planilla. Esto es muy útil ya que "cuatro ojos ven más que dos " y además quien debe ir haciendo las conexiones y ajustes puede concentrarse mejor en su tarea.

En función de las circunstancias se tilda en la LV cada uno de los elementos que voy verificando, aunque en general no lo hago a no ser LV largas ni complejas. Para LV largas o complejas es mandatorio ir tildando todos los ítems verificados. Si se debe reiniciar la verificación y no hay una copia de la Planilla simplemente se cruza la marca en otra posición.

MATRIZ DE REQUERIMIENTOS

La matriz de Requerimientos es un documento esencial dentro de la administración de requerimientos, algunos de los datos que se pueden poner son los señalados en la imagen, prioridad, Prueba a realizar y el riesgo
La prioridad puede ser alta (el requerimiento es crítico para el sistema), Media (el sistema puede funcionar aunque de manera deficiente), baja (el requerimiento sería deseable tenerlo). A través de la columna de riesgos se puede determinar que requerimientos deberán ser probados forzosamente y cuales dependerá del tiempo con que se cuente.

NEGOCIACIÓN DE REQUERIMIENTOS

La parte más dura en la construcción de un sistema software es decidir cómo construirlo. Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después”

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional.

Identificación De Requisitos

Christel y Kang identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.

• Problemas de alcance.

• Problemas de comprensión.

Análisis Y Negociación De Requisitos

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.

Especificación De Requerimientos

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema.

Requerimientos Funcionales Y No Funcionales

A menudo los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio.

Requerimientos funcionales

Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Requerimientos No Funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.

Requerimientos Del Dominio

Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.

Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares.

Requerimientos Del Usuario Y Del Sistema

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer.

Requerimientos Del Usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.

Los Requerimientos Del Sistema

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. 

El Documento De Requerimientos Del Software

Éste es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema.

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.

Requerimientos específicos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección.

Requerimientos específicos.

Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeño del sistema, especificar los requerimientos lógicos de la base de datos, las restricciones de diseño, las propiedades emergentes del sistema y las características de calidad.

NEGOCIACIÓN DE REQUERIMIENTOS

El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad.  Algunas actividades dentro de la negociación de requerimientos son:

·               Resolver conflictos entre requerimientos.

·               Decisiones pueden ser tomadas unilateralmente.

·               Se aconseja consultar con las partes implicadas (roles)

METODOLOGIA A UTILIZAR

 ¿Que es la programación extrema (XP)?

La Programación Extrema  es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas, realimentación o reutilización de código  y coraje para enfrentar los cambios. XP se define como una metodología especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

2. Uso de la metodología XP

XP surgió como respuesta y posible solución a los problemas derivados del cambio en los requerimientos, 2. XP se plantea como una metodología a emplear en proyectos de riesgo y 3. XP aumenta la productividad

3. ¿En que consiste XP? Sus objetivos.

Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación.

El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

3.1. Las cuatro variables.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito.

Además de estas cuatro variables, Beck propone que sólo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en función de las otras tres

Pongámonos en un episodio diario de desarrollo.

El jefe de proyecto: “Quiero estos requisitos realizados para el día 1 de mes próximo, con lo que contáis con el equipo actual. ¡Ah ya sabéis que la calidad es lo primero!”

Todos sabemos qué es lo primero que salta por la ventana en estos casos: “la calidad”, ¿Por qué? Porqué nadie es capaz de trabajar bien cuando se le somete a mucha presión.

XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el valor que alcancen las cuatro variables sea el correcto para todas las partes: “Si quieres más calidad en menos tiempo tendrás que aumentar el equipo e incrementar el coste”.

Además con el agravante de que estas cuatro variables no guardan una relación tan directa como en principio pueda parecer. El incremento del número de programadores no repercutirá de manera lineal en el tiempo de desarrollo del proyecto, siendo de todo conocido el dicho: “nueve mujeres no pueden tener un hijo en un mes”.

Con la calidad suele suceder un fenómeno extraño: frecuentemente un proyecto que tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo, siempre con unos márgenes obviamente. Es verdad que cuando un equipo de desarrollo se acostumbra a realizar pruebas intensivas, se siguen estándares de codificación, poco a poco se comenzara a andar más rápido y más seguro, por tanto más preparados para futuros cambios, sin estrés y así sucesivamente.

Frente a esto existe la tentación de entregar el trabajo más rápido, por tanto probar menos, codificar más rápido y peor, sin hacer planteamientos maduros, esto repercutirá en la confianza de nuestros clientes, al entregarle trabajos con fallos. Esta es una apuesta a muy corto plazo y suele ser una invitación al desastre, conduce a la desmoralización del equipo, y con ello a la larga a la ralentización del proyecto y la pérdida de tiempo que habríamos conseguido en un principio.

La cuarta variable, el ámbito del proyecto, suele ser conveniente que sea establecida por el equipo de desarrollo. Es una variable muy importante que nos va a decir donde vamos a llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para siguientes versiones. Cuántas veces hemos escuchado “Los clientes no nos pueden decir lo que quieren. Cuando le damos lo que nos piden no les gusta”. Y es que los requisitos nunca son claros al principio y el mismo desarrollo del software hace cambiar los requisitos. Por tanto el ámbito debe de ser dúctil, podremos jugar con él, si el tiempo para el lanzamiento es

limitado, siempre habrá cosas que podremos diferir para siguientes versiones.

Por tanto implementaremos primero los requisitos más importantes para el cliente, de forma que si tenemos que dejar algo para después que sea menos importante que las que ya incorporen un sistema

3.2. El coste del cambio.

Una de las suposiciones establecidas en la industria del software es que el coste de los cambios en un programa crece exponencialmente con el tiempo. XP propone que si el sistema que empleas hace que el coste del software aumente con el tiempo debes de actuar de forma diferente a cómo lo haces. XP propugna que esta curva ha perdido validez y con una combinación de buenas prácticas de programación y tecnología es posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto:

Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva, pero ¿cómo se consigue dicha curva?, no existe una forma mágica desde luego hay varias medidas que nos ayudan a conseguirla.

Diseñar lo más sencillo que sea posible, para hacer sólo lo imprescindible en un momento dado, la simplicidad del código y los test continuos hace que los cambios sean posibles tan a menudo como sea necesario.

La programación orientada a objetos es una tecnología clave para el mantenimiento del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar el código existente, esto no quiere decir que no puedas tener flexibilidad sin programar orientado al objeto y el caso contrario que haya programas orientados a objetos que nadie quería tocar, sólo se dice que el programar orientado a objetos reduce el costo del cambio.

En vez de tomar grandes decisiones al principio y pocas posteriormente, podemos idear una aproximación para desarrollar software en la que se tomen decisiones rápidamente, pero estas decisiones apoyadas por pruebas y que te preparan para mejorar el diseño del software cuando aprendas una mejor manera de diseñarlo.

He oído a muchos programadores (entre los que me incluyo) decir: “Hasta que no he terminado el programa no lo he entendido ahora lo haría con esta jerarquía y que esta clase herede de esta otra”, dejemos pues abierta la puesta a esta posibilidad.

3.3. Los cuatro valores.

Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, todo va a cambiar. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios.

Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iníciales.

Estos cuatro valores son:

·        Comunicación

·        Sencillez

·        Retroalimentación

·        Valentía

Comunicación.

Cuántas veces hemos tenido problema en nuestro equipo de desarrollo por falta de comunicación, por no comentar un cambio crítico en el diseño, por no preguntar lo que pensamos al cliente.

 La mala comunicación no surge por casualidad y hay circunstancias que conducen a la ruptura de la comunicación, como aquel jefe de proyecto que abronca al programador cuando éste lo comunica que hay un fallo en el diseño. XP ayuda mediante sus prácticas a fomentar la comunicación.

Sencillez.

Siempre debemos hacernos esta pregunta ¿Qué es lo más simple que pueda funcionar? Lograr la sencillez no es fácil. Tenemos cierta tendencia a pensar en qué programaremos mañana, la próxima semana y el próximo mes. Cuántos de nosotros no hacemos a veces más de lo que debemos: “Ya que estoy tocando esta clase voy a añadirle dos métodos más para visualizar los mensajes en colores”, cuando eso no está entre los requisitos, “es que mañana puede que lo necesite”, si mañana está entre los requisitos, hazlo entonces.

XP nos enseña a apostar, apuesta por hacer una cosa sencilla hoy y pagar un poco más para mañana, si es necesario, que hacer una cosa complicada hoy y no utilizarla después.

La sencillez y la comunicación se complementan, cuanto más simple es tu sistema menos tienes que comunicar de él.

Retroalimentación.

“No me preguntes a mí, pregúntale al sistema”, es la primera clave de la retroalimentación, por medio de pruebas funcionales a nuestro software este nos mantendrá informado del grado de fiabilidad de nuestro sistema, esta información realmente no tiene precio. Los clientes y las personas que escriben pruebas tienen una retroalimentación real de su sistema.

La retroalimentación actúa junto con la sencillez y la comunicación, cuanto mayor retroalimentación más fácil es la comunicación. Cuanto más simple un sistema más fácil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendrá mucho echo.

Valentía.

Asumir retos, ser valientes antes los problemas y afrontarlos. En mi experiencia como programador estuve realizando un programa de Nominas para la delegación portuguesa de SP.

Yo estaba encargado de elaborar unos informes para la seguridad social portuguesa denominados “Balanço Social”, nunca se me olvidará. Mientras más avanzaba en el trabajo más engorro montaba en el código por tal de que aquello funcionara después de 3 semanas de trabajo casi lo tenía resuelto, pero el código estaba tan súper parcheado que no había nadie que lo entendiera. Realmente hasta ese momento yo no entendía realmente lo que se necesitaba y decidí tirarlo todo y reprogramar todo el sistema, al principio de los cambios todo empezó a fallar, pero ahora avanzaba firme y seguro, a los pocos días todas las pruebas empezaron a funcionar, hasta que finalicé el trabajo. Es una de las acciones valientes que adoptas y después te enorgulleces de ellas, otras veces me he escondido detrás de la complejidad de los cambios y no los he realizado, me acobarde pensando en las consecuencias, en las broncas de mis jefes si les decía que había cambiado el sistema.

Cuando no afrontas el problema y parcheas un código que positivamente sabes que está mal acabas odiando el sistema, y cada mañana cuando vas a la oficina en el coche te entra dolor de barriga. Cuando vayas hacia el trabajo y se te revuelva el estomago piensa en cambiar de trabajo.

Nuestro trabajo se asimila al de un escalador cuando hacemos una cima tenemos que volver a bajar para hacer otra cima y así constantemente, planteándonos hacer sistemas cada vez más sencillos y fiables.

La valentía junto con la comunicación y la sencillez se convierte en extremadamente valiosa. “Odio este código ¿vamos a ver cuanto podemos cambiar en esta tarde?”

Para continuar tenemos que disponer de unas guías más concretas que satisfagan y encarnen estos cuatro valores.

3.4. Las cuatro actividades básicas

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software?

Codificar

Es la única actividad de la que no podremos prescindir. Sin código fuente no hay Programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar.

Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo.

No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegaras a conclusiones sobre las pruebas y podrás pensar que si dos de  tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza.

Programar y probar es más rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración. Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona.

Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro.

Escuchar

Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?

 Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos qué codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

4. La solución

Hasta ahora sólo hemos montado la escena, conocemos nuestros problemas, hemos adoptado nuestros valores y hemos decidido cuales son las actividades básicas para desarrollar software.

Nuestra intención es que todo lo expuesto funcione y para ello vamos a relacionar una serie de prácticas para que todo llegue a buen puerto:

4.1. Fases de la metodología XP

Existen diversas prácticas inherentes al desarrollo de software.

4.4.1.- Planificación.

XP plantea la planificación como un permanente dialogo entre las partes la empresarial (deseable) y la técnica (posible). Las personas del negocio necesitan determinar:

Ámbito: ¿Qué es lo que el software debe de resolver para que este genere valor?

Prioridad: ¿Qué debe ser hecho en primer lugar?

Composición de versiones: ¿ Cuánto es necesario hacer para saber si el negocio va mejor con software que sin él ?. En cuanto el software aporte algo al negocio debemos de tener lista las primeras versiones.

Fechas de versiones: ¿Cuáles son las fechas en la presencia del software o parte del mismo pudiese marcar la diferencia?

El personal del negocio no puede tomar en vació estas decisiones, y el personal Técnico tomará las decisiones técnicas que proporcionan la metería prima para las decisiones del negocio.

Estimaciones: ¿Cuánto tiempo lleva implementar una característica?

Consecuencias: Informar sobre las consecuencias de la toma de decisiones por parte del negocio. Por ejemplo el cambiar las bases de datos a Oracle.

Procesos: ¿Cómo se organiza el trabajo y el equipo?

Programación detallada: Dentro de una versión ¿Qué problemas se resolverán primero?

4.1.2.- Pequeñas versiones.

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, me explico no puedes implementar media característica y lanzar la versión.

Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.

4.2.- Diseño

4.2.1.- Metáfora.

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.2.2. Diseño sencillo.

El diseño adecuado para el software es aquel que:

1. Funciona con todas las pruebas.

2. No tiene lógica duplicada.

3. Manifiesta cada intención importante para los programadores

4. Tiene el menor número de clases y métodos.

Haz el diseño lo mas simple posible borra todo lo que puedas sin violar las reglas 1,2 y 3. Contrariamente a lo que se pensaba el “Implementa para hoy, diseña para mañana”, no es del todo correcto si piensas que el futuro es incierto.

4.3.- Desarrollo.

4.3.1.- Recodificación.

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). Esto a veces nos puede llevar a hacer más trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.

4.3.2.- Programación por parejas.

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 mas estratégicamente, ¿Va a funcionar?, ¿ Puede haber pruebas donde no funcione ?, ¿ Hay forma de simplificar el sistema global para que el problema desaparezca.

El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.

4.3.3.- Propiedad colectiva.

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. Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.

4.3.4.- Integración continúa.

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%.

4.3.5.- 40 Horas semanales.

Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.

4.3.6.- Cliente In-situ.

Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.

4.3.7.- Estándares de codificación.

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.

4.4.- Pruebas

4.4.1.- Hacer pruebas.

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.

5.- ¿Como hacemos funcionar esto?

Vamos a tratar de explicar cómo se ponen en marcha todas estas prácticas se apoyan entre si y toman valor, veremos como todo esta historia de XP puede funcionar

5.1.- Planificación

En principio no podríamos comenzar el programa con tan sólo un plan aproximando y no podríamos estar actualizando este plan constantemente a no ser que:

·        Los propios clientes hiciesen su planificación con las estimaciones que les pasan los programadores.

·        Le diéramos a los clientes un plan para hacerles una idea de lo que sería posible en los próximos meses.

·        Hiciéramos versiones pequeñas para que el cliente detecte cualquier error en el plan.

·        Tu cliente esté incorporado al equipo, para observar rápidamente los posibles cambios.

5.2.- Versiones reducidas

En principio no podíamos tener una producción después de unos pocos meses, a no ser que:

·        La planificación te ayudase a trabajar sobre las historias más valiosas, de tal forma que un pequeño tuviese valor para el negocio.

·        Estuvieses integrando constantemente de tal forma que el coste de la versión fuese mínimo.

·        Tus pruebas redujesen los defectos lo suficiente, para evitar los largos ciclos de testeo.

·        Hiciéramos diseños sencillos necesarios únicamente para esta versión.

5.3.- Metáfora.

No podríamos comenzar a desarrollar con tan solo una metáfora a no ser que:

·        Tengas rápidamente retroalimentación a partir del código real y de las pruebas, sobre si esta metáfora esta funcionando en la práctica.

·        Tus clientes estén a gusto hablando sobre el sistema en términos de metáfora.

·        La Recodificación que hagas refine continuamente vuestro conocimiento de lo que la metáfora significa en la práctica.

5.4.- Diseño sencillo.

En principio no tendríamos bastante diseñado para codificar hoy, a no ser que:

·        Utilizáramos la Recodificación, haciendo cambios que no fuesen preocupantes.

·        Tuviésemos una metáfora global clara, de tal forma que los cambios del diseño tenderían a seguir caminos convergentes.

·        Estuviésemos codificando con un compañero, de tal forma que tuvieses confianza en hacer un diseño sencillo, y no un diseño estúpido.

5.5.- Hacer pruebas.

En principio escribir pruebas nos llevaría mucho tiempo, a menos que:

·        El diseño sea tan simple como pueda ser de tal forma que escribir pruebas no sea difícil.

·        Estemos programando con un compañero, así no puedes pensar en otra prueba pero tu compañero si puede.

·        Te sientas bien cuando veas las pruebas funcionando.

·        Tus clientes se sientan bien cuando vean todas las pruebas funcionando.

5.6.- Recodificación.

En principio no podríamos hacer Recodificación del sistema durante todo el tiempo, nos llevaría mucho tiempo y sería difícil de controlar, a menos que:

·        Estemos habituados a la propiedad colectiva y no tengamos inconvenientes en hacer cambios necesarios.

·        Trabajemos sobre estándares de codificación, para que no tengamos que cambiar el formato del código antes de re codificar.

·        Codifiquemos por parejas y esto nos de valentía a la hora de afrontar mejoras difíciles en el código.

·        Tengamos diseños sencillos donde re codificar sea más fácil.

·        Tengamos integración continua para que si accidentalmente dañemos algo lo sepamos en cuestión de horas.

·        Estemos descansados y así tengamos más valentía y sea más improbable que cometamos errores

.

5.7.- Programación en parejas.

En principio escribir todo el código por parejas seria más lento, a no ser que:

·        Los estándares de codificación reduzcan las disputas.

·        Cada uno este fresco y descansado y así evitar las discusiones absurdas.

·        Las parejas escribas las pruebas juntas, dando la posibilidad de alinear su comprensión antes de afrontar el meollo de la implementación.

·        Las parejas tengan la metáfora para fundamentar sus discusiones sobre los nombres y el diseño básico.

·        Las parejas estén trabajando sobre diseños sencillos.

5.8.- Integración continúa.

·        Posiblemente no podremos integrar tras unas pocas horas de trabajo, a no ser que:

·        Podamos ejecutar pruebas rápidamente para saber que no hemos perdido nada.

·        Codifiques en parejas, así hay la mitad de cambios a integrar.

·        Recodifiques, así hay piezas más pequeñas, reduciendo la posibilidad de conflicto.

5.9.- Clientes in-situ.

En principio no podremos tener a un cliente in-situ ya que este produce más valor en otra parte, a menos que:

·        Puedan producir valor para el proyecto escribiendo pruebas funcionales.

·        Puedan producir valor para el proyecto priorizando el a pequeña escala y tomando decisiones junto a los programadores.

5.10.- Prácticas XP        

La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las prácticas que describiremos a continuación.

5.11.- El juego de la planificación

Es un espacio frecuente de comunicación entre el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. Esta práctica se puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aporta para el negocio.

Los programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración, apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego se realiza durante la planificación de la entrega, en la planificación de cada iteración y cuando sea necesario reconducir el proyecto.

5.12.- Entregas pequeñas

La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero sí que constituyan un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses.

6.-  Las Historias de Usuario

Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales.

El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras más específicas o generales, añadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas.

Respecto de la información contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto. En muchos casos sólo se propone utilizar un nombre y una descripción  o sólo una descripción, más quizás una estimación de esfuerzo en días. Beck en su libro presenta un ejemplo de ficha (customer story and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios.

Una de las interrogantes (que también se presenta cuando se utilizan casos de uso) es ¿cuál es el nivel de granularidad adecuado para una historia de usuario? La respuesta no es tajante. Jeffries en dice que depende de la complejidad del sistema, debe haber al menos una historia por cada característica importante, y propone realizar una o dos historias por programador por mes. Si se tienen menos, probablemente sea conveniente dividir las historias, si se tienen más lo mejor es disminuir el detalle y agruparlas. Para efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración).

No hay que preocuparse si en un principio no se identifican todas las historias de usuario. Al comienzo de cada iteración estarán registrados los cambios en las historias de usuario y según eso se planificará la siguiente iteración.

Las historias de usuario son descompuestas en tareas de programación y asignadas a los programadores para ser implementadas durante una iteración.

7.-  Roles XP

Aunque en otras fuentes de información aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck.

7.1.- Programador

El programador escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.

7.2.- Cliente

El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es sólo uno dentro del proyecto pero puede corresponder a un interlocutor que está representando a varias personas que se verán afectadas por el sistema.

7.3.- Encargado de pruebas (Tester)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

7.4.- Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.

También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración.

7.5.- Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

7.6.- Consultor

Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico.

7.7.-Gestor (Big boss)

Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

 8.- Proceso XP

Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

1.     El cliente define el valor de negocio a implementar.

2.     El programador estima el esfuerzo necesario para su implementación.

3.     El cliente selecciona qué construir, de acuerdo con sus prioridades y las

4.     restricciones de tiempo.

5.     El programador construye ese valor de negocio.

6.     Vuelve al paso 1.

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.

El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

Fase I: Exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.

Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

Fase II: Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de usuario, y

Correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.

Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración.

La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.

Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción.

Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la

Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores. Wake en proporciona algunas guías útiles para realizar la planificación de la entrega y de cada iteración.

Fase IV: Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.

Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo, durante la fase de mantenimiento).

Fase V: Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

Fase VI: Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

Comentarios respecto de las prácticas

El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 1,  donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí.

La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica (ver [1] para un análisis histórico de ideas y prácticas que sirven como antecedentes a las utilizadas por las metodologías ágiles). El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

CONCLUSIONES

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.

Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes.

Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como:

están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen no más de 10 participantes), el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio, etc.

Falta aún un cuerpo de conocimiento consensuado respecto de los aspectos teóricos y prácticos de la utilización de metodologías ágiles, así como una mayor consolidación de los resultados de aplicación. La actividad de investigación está orientada hacia líneas tales como: métricas y evaluación del proceso, herramientas específicas para apoyar prácticas ágiles, aspectos humanos y de trabajo en equipo. Entre estos esfuerzos destacan proyectos como NAME12 (Network for Agile Methodologies Experience).

Aunque en la actualidad ya existen libros asociados a cada una de las metodologías ágiles existentes y también abundante información en internet, es XP la metodología que resalta por contar con la mayor cantidad de información disponible y es con diferencia la más popular.

En XP no existe la fase de análisis de requerimientos como si lo hay en RUP, tampoco existen los casos de uso en XP se llaman Historia de Usuario que a diferencia de los casos de uso que son escritos por los analistas en base a el análisis de requerimientos , las historias de usuarios son escritas por el propio cliente. Un proyecto XP va creciendo poco a poco hasta alcanzar un producto final. Esto quiere decir que a diferencia de de RUP que se espera terminar todo el proyecto para poder implantarlo en XP todo el proyecto es dividido en funcionalidades más pequeñas de tal manera que se puede hacer entrega funcional del producto mientras se avanza con el resto.