Metodologa Scrum

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.

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

Programacin Extrema
Se puede definir la programacin extrema como la adopcin de las
mejores Metodologas de Desarrollo de acuerdo a lo que se pretende llevar a
cabo con el proyecto, y aplicarlo de manera dinmica durante el Ciclo 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.

Los valores originales 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 Bsicas
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 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 la Depuracion.
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 la Realimentacin entre ambos nos ayudan a todos a
entender los problemas.
Disear: El Diseo crea 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 poder Codificar, probar y
escuchar indefinidamente.

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