Metodologa ScrumScrum 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.

Con la metodologa 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 sin ningn problema.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 /historiadel proyecto, el equipo los estima y con esta informacin elProduct Ownerestablece su prioridad. De manera regular, en las demos de Sprint elProduct Ownercomprueba 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.Programacin ExtremaSe puede definir la programacin extrema como la adopcin de las mejoresMetodologas de Desarrollode acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante elCiclo de Vida del Software. La programacin extrema se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo, para algunos no es ms que aplicar una pura lgica.Losvaloresoriginales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained.Las Cuatro Actividades BsicasAhora que tenemos nuestros cuatro valores estamos preparados para construir una Disciplina deDesarrollo 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 cdigo fuente no hay programa, aunque hay gente que cuenta que existe software en produccin del que se perdi el cdigo fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a travs del cdigo. En una programacin en PX en pareja el cdigo expresa tu interpretacin del problema, as podemos utilizarlo para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar.Hacer pruebas: Las caractersticas 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 haba 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 cdigo, con el tiempo llegaras a conclusiones sobre las pruebas y podrs 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 ms rpido que slo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perders mucho tiempo en laDepuracion.Tendrs menos errores, tendrs que volver menos veces sobre el cdigo, te costar menos localizar los errores, perders 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 que nos querran?. Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la informacin.Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fcil y difcil de obtener, y laRealimentacinentre ambos nos ayudan a todos a entender los problemas.Disear: ElDiseocrea una estructura que organiza la lgica del sistema, un buen diseo permite que el sistema crezca con cambios en un solo lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divdela en varias. Si hay fallos en el diseo o malos diseos, estos deben de ser corregidos cuanto antes.Tenemos que codificar porque sin cdigo 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 que codificar ni probar, y tenemos que disear para poderCodificar, probar y escuchar indefinidamente.

Bibliografias:http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.htmlhttp://www.ecured.cu/index.php/Programacin_Extrema_%28XP%29#Programaci.C3.B3n_Extrema