RAD y RUP

SCRUM
Qu es?

Scrum es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversin para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.

Cundo se utiliza?

Con Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteracin a iteracin. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteracin.

Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar sus capacidades. Beneficios

Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta informacin el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.

Flexibilidad a cambios: Alta capacidad de reaccin ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodologa est diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

Reduccin del Time to Market: El cliente puede empezar a utilizar las funcionalidades ms importantes del proyecto antes de que est finalizado por completo.

Mayor calidad del software: La metdica de trabajo y la necesidad de obtener una versin funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.

Mayor productividad: Se consigue entre otras razones, gracias a la eliminacin de la burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos para organizarse.

Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de inversin.

Predicciones de tiempos: Mediante esta metodologa se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fcilmente para cuando se dispondr de una determinada funcionalidad que todava est en el Backlog.

Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de ms valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

XP COMO METODOLOGA
Bsicamente, la programacin extrema, busca dos objetivos claramente: hacer un software bien (con calidad) y de la forma ms rpida posible. De hecho estos son los objetivos fundamentales de cualquier metodologa aplicada al desarrollo de software y a cualquier otro rea en general. A pesar de esto, con las metodologas de desarrollo actuales, el 70% de los proyectos fracasan y aproximadamente, tambin, el 70% de los fallos no son debidos a cuestiones tcnicas, son debidos a cambios en la gestin o problemas de comunicacin.3 Con estos datos es lgico pensar en que las metodologas actuales no son lo suficientemente buenas, porque una tasa de xito inferior a una tercera parte del total de proyectos no es algo deseable. Una vez analizado el problema, podemos ver en XP la solucin, o al menos un acercamiento. La programacin extrema centra su atencin en la produccin de software con una fuerte arquitectura, intentando sacar productos al mercado rpidamente, con gran calidad y motivando al equipo de trabajo para seguir mejorando esta tendencia. Como metodologa, la programacin extrema, presenta muchos puntos comunes con el desarrollo incremental, comenzando por el hecho de que el software desarrollado con XP se realiza de forma incremental. Para ver todas los puntos en que se centra la XP, vamos a dividirlo por fases. Codificar: Trabajar significa que, al final del da, tienes algo que funcione y que proporcione beneficios al cliente. Por tanto, todo el software se produce mediante la puesta a punto de pequeas versiones incrementales de produccin corta. Probar: Hay que asegurarse de que todo lo que se hace funcione correctamente. Para ello, lo mejor es desarrollar la prueba desde el momento que se conocen los casos de uso (o, segn XP, las historias del usuario). Por ello, lo mejor es desarrollar las pruebas antes de generar el cdigo para tener una prueba ms objetiva del correcto funcionamiento de ste. Escuchar: Tanto para disear, como para desarrollar pruebas, como para desarrollar, . . . tienes que saber exactamente lo que quieres, para ello, se debe aprender a escuchar muy bien al cliente, al jefe de proyecto y a todo el mundo en general.

Disear:

El diseo tambin debe ser incremental y debe estar empotrado en el software, lo cul quiere decir que la estructura de ste debe ser clara. Hay que disear lo que las necesidades del problema requieren, no lo que uno cree que debera ser el diseo. Adems, siempre hay que tener en cuenta que disear cosas para el futuro es una perdida de tiempo, porque no las vas a necesitar.

VENTAJAS
Evidentemente, para que algo est siendo tomado tan en cuenta como la XP, debe ofrecer una serie de ventajas a la hora de ponerlo en prctica que hagan que el esfuerzo de entender y aplicar sus prcticas, sea insignificante con respecto a los beneficios obtenidos. Se consiguen productos usables con mayor rapidez. El proceso de integracin es continuo, por lo que el esfuerzo final para la integracin es nulo. Se consigue integrar todo el trabajo con mucha mayor facilidad. Se atienden las necesidades del usuario con mayor exactitud. Esto se consigue gracias a las continuas versiones que se ofrecen al usuario. Se consiguen productos ms fiables y robustos contra los falllos gracias al diseo de los test de forma previa a la codificacin. Obtenemos cdigo ms simple y ms fcil de entender, reduciendo el nmero de errores. Gracias a la filosofa del pair programming (programacin en parejas), se consigue que los desarrolladores apliquen las buenas prcticas que se les ofrecen con la XP. Gracias al refactoring es ms fcil el modificar los requerimientos del usuario. Conseguimos tener un equipo de desarrollo ms contento y motivado. Las razones son, por un lado el que la XP no permite excesos de trabajo (se debe trabajar 40 horas a la semana), y por otro la comunicacin entre los miembros del equipo que consigue una mayor integracin entre ellos.
Debido

a que se concibe que la propiedad del cdigo es

colectiva, cualquiera puede desarrollar, mejorar, simplificar, . . . cualquier necesidad del proyecto, eso s, siempre usando sistemas tipo CVS para evitar la duplicacin de trabajo usando el refactoring si se trata de una modificacin. Existen muchsimas ms ventajas, pero hemos nombrado las ms importantes y las ms generales, ya que la XP puede ofrecer otro tipo de ventajas en segn que entornos se aplique.

1.4 CUNDO Y DNDE USAR LA XP?

La XP no es algo universal, a que si fuese una herramienta que nos permitiese solventar cualquier tipo de situacin, sera la piedra filosofal de la informtica. Veremos en que situaciones y bajo que criterios es mejor aplicar la programacin extrema.

REQUERIMIENTOS DE LA XP

Aunque parezca algo un tanto estpido, la programacin extrema est orientada hacia proyectos con un escaso nmero de participantes (unos 10/12) trabajando en parejas de dos personas. Por lo que uno de los requerimientos ms importantes para poder aplicar esta metodologa es el tamao del proyecto. Sobre esta base, se disea un entorno tipo para poder practicar la XP. Las necesidades de este entorno son6: Semanas de 40 horas de trabajo. Todos los desarrolladores deben estar en una nica habitacin. Todos los das comienzan con una reunin de apertura. En la habitacin debe haber comida (bsicamente snacks para reforzamiento positivo). Alta velocidad de trabajo.

Para qu nos es til.

Una vez conocemos el entorno necesario para poder desarrollar las prcticas expuestas por la programacin extrema, vamos a ver en qu reas o en qu proyectos podemos utilizar la XP con xito. Como generalidad, la XP, puede ser usada en cualquier proyecto con un tamao relativamente pequeo, el cual pueda ser desarrollado por un equipo de entre 10-12 personas.

Se pueden aplicar otros criterios, ya que existen muchas opiniones acerca de esto en el mundo de la XP. Nosotros seguiremos bsicamente este criterio que es el, a priori, ms acertado, porque permite aplicar la XP sin modificar sus principios bsicos. Tambin podemos establecer un segundo criterio basado en la dificultad del proyecto. Si nos encontramos ante un proyecto inabordable, en el que no conseguimos avanzar, quizs sea bueno probar un enfoque cercano a la XP, incluso reduciendo el nmero de personas que participan en el, intentando acercarnos a las necesidades de la XP, pero sin obviar la carga de trabajo. En estos proyectos no podemos aventurar nada acerca de su resolucin, pero si podemos decir que el enfoque de la XP puede ser til si otros acercamientos han fracasado (y cuando menos, no perdemos nada, salvo tiempo).

bibliografa http://www.escet.urjc.es/~gtazon/IS/Metodologias.pdf http://www.slideshare.net/juliopari/4-clase-metodologia-de-desarrolo-de-software