Mtodo SCRUM

SCRUM
Scrum es un marco de trabajo para la gestin y desarrollo de software basada en un proceso iterativo e
incremental utilizado comnmente en entornos basados en el desarrollo gil de software.
Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado
en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de
Scrums.

Caracteristicas de SCRUM
Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse
como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los
roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al
director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o
internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el
equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de
caractersticas que forma parte de cada sprint viene del Product Backlog, que es un conjunto de
requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog
que forman parte del sprint se determinan durante la reunin de Sprint Plaan. Durante esta reunin, el
Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del
conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos estn congelados durante el sprint.
Scrum permite la creacin de equipos auto-organizados impulsando la co-localizacin de todos los
miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el
proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden
cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los
desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por
lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser
completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar
rpidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas
amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que
es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Roles en SCRUM
Roles Principales

Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de
forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de
usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstculos que
impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo
(porque ellos se auto-organizan), sino que acta como una proteccin entre el equipo y
cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se
utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3 a 9
personas con las habilidades transversales necesarias para realizar el trabajo (anlisis, diseo,
desarrollo, pruebas, documentacin, etc).

Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran
frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto
importante de una aproximacin gil es la prctica de involucrar en el proceso a los usuarios, expertos
del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue
retroalimentacin con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el
beneficio acordado que justifica su produccin. Slo participan directamente durante las
revisiones del sprint.

Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum
Daily Scrum
Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama "daily
standup". El scrum tiene unas guas especficas:
La reunin comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipopara quien llegue tarde (por ejemplo: dinero, flexiones, etc).
Todos son bienvenidos, pero slo los responsables pueden hablar.
La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del
equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunin corta)
La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das.
Durante la reunin, cada miembro del equipo contesta a tres preguntas:3
Qu has hecho desde ayer?
Qu es lo que ests planeando hacer hoy?
Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del
ScrumMaster recordar estos impedimentos).

Scrum de Scrum
Cada da normalmente despus del Daily Scrum:
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose
especialmente en reas de solapamiento e integracin.
Asiste una persona asignada por cada equipo.
La agenda ser la misma que la del Daily Scrum, aadiendo adems las siguientes cuatro preguntas:

Qu ha hecho tu equipo desde nuestra ltima reunin?

Qu har tu equipo antes que nos volvamos a reunir?
Hay algo que demora o estorba a tu equipo?
Ests a punto de poner algo en el camino del otro equipo?

Reunin de Planificacin del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin del Sprint se lleva a cabo.
Seleccionar qu trabajo se har
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomar hacer el
trabajo.
Identificar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como lmite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la Reunin de Revisin del Sprint y la
Retrospectiva del Sprint

Reunin de Revisin del Sprint (Sprint Review Meeting)

Revisar el trabajo que fue completado y no completado

Presentar el trabajo completado a los interesados (alias demo)
El trabajo incompleto no puede ser demostrado
Cuatro horas como lmite

Retrospectiva del Sprint (Sprint Retrospective)

Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del
equipo dejan sus impresiones sobre el sprint recin superado. El propsito de la retrospectiva es
realizar una mejora continua del proceso. Esta reunin tiene un tiempo fijo de cuatro horas.

Sprint
El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la duracin de
los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede
comenzar con una duracin de sprint en particular (2 o 3 semanas) e ir ajustndolo con base en el
ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deber presentar
los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente.
Asimismo, se recomienda no cambiar los objetivos del sprint o sprint backlog a menos que la falta de
estos cambios amenace al xito del proyecto. La constancia permite la concentracin y mejora la
productividad del equipo de trabajo.

Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones
genricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas segn su retorno
sobre la inversin (ROI) . Es el qu va a ser construido. Es abierto y cualquiera puede modificarlo.
Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo
de desarrollo requerido. Esta estimacin ayuda al product owner a ajustar la lnea temporal y, de
manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos caractersticas tienen el
mismo valor de negocio la que requiera menor tiempo de desarrollo tendr probablemente ms
prioridad, debido a que su ROI ser ms alto.

Sprint backlog
El sprint backlog es un documento detallado donde se describe el cmo el equipo va a implementar los
requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duracin
superior a 16 horas. Si una tarea es mayor de 16 horas, deber ser divida en otras menores. Las tareas
en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les
parezca oportuno.

Burn down
La burn down chart es una grfica mostrada pblicamente que mide la cantidad de requisitos en el
Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los
puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta
lnea sea descendente (en casos en que todo va bien en el sentido de que los requisitos estn bien
definidos desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el cual el
proyecto se ha terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si
durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente en determinados
segmentos, y si se modifican algunos requisitos la pendiente variar o incluso valdr cero en algunos
tramos.

Scrum aplicado al desarrollo de software

Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en
entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones
frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en Easel Corporation
(Empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y
finalmente en Ascential Software Corporation). En 1995 lo present junto con Ken Schwaber como
proceso formal, tambin para gestin del desarrollo de software en OOPSLA 95. Ms tarde, en 2001
seran dos de los promulgadores del Manifiesto gil. En el desarrollo de software scrum est
considerado como modelo gil por la Agile Alliance.[1]

Mtodo DSDM
Mtodo de desarrollo de sistemas dinmicos
El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development Method o
DSDM) es un mtodo que provee un framework para el desarrollo gil de software, apoyado por su
continua implicacin del usuario en un desarrollo iterativo y creciente que sea sensible a los
requerimientos cambiantes, para desarrollar un sistema que reuna las necesidades de la empresa en
tiempo y presupuesto. Es uno de un nmero de mtodos de desarrollo gil de software y forma parte
del alianza gil.
DSDM fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos
en la materia del desarrollo de sistemas de informacin (IS), el consorcio de DSDM, combinando sus
experiencias de mejores prcticas. El consorcio de DSDM es una organizacin no lucrativa y proveedor
independiente, que posee y administra el framework. La primera versin fue terminada en enero de
1995 y publicada en febrero de 1995. La versin actualmente en uso (abril de 2006) es la versin 4.2: El
framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003.
Como extensin del Desarrollo rpido de aplicaciones (RAD), DSDM se centra en los proyectos de
sistemas de informacin que son caracterizados por presupuestos y agendas apretadas. DSDM trata los
problemas que ocurren con frecuencia en el desarrollo de los sistemas de informacin en lo que
respecta a pasar sobre tiempo y presupuesto y otras razones comunes para la falta en el proyecto tal
como falta de implicacin del usuario y de la comisin superior de la gerencia.
DSDM consiste en 3 fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del postproyecto. La fase del ciclo de vida del proyecto se subdivide en 5 etapas:
1.
2.
3.
4.
5.

estudio de viabilidad,
estudio de la empresa,
iteracin del modelo funcional,
diseo e iteracin de la estructura, e
implementacin.

DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes acorde a las
necesidades de la empresa. Para alcanzar estas metas, DSDM promueve el uso del RAD con el
consecuente peligro que demasiadas esquinas estn cortadas. DSDM aplica algunos principios, roles, y
tcnicas.
En algunas circunstancias, hay posibilidades para integrar contenido de otros mtodos, tal como el
Proceso Unificado de Rational (RUP), Programacin Extrema (XP), y Proyectos en ambientes controlados
(PRINCE2), para complementar el DSDM en la realizacin de un proyecto. Otro mtodo gil que tiene
semejanzas proceso y concepto con DSDM es Scrum.

Origen del Mtodo de Desarrollo de Sistemas Dinmicos (DSDM)

El DSDM empez en Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que queran
construir sobre RAD [N. del T. Desarrollo Rpido de Aplicaciones] y desarrollo iterativo. Habiendo
empezado con 17 fundadores ahora tiene ms de mil miembros y ha crecido fuera de sus races
britnicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros
mtodos giles. Tiene una organizacin de tiempo completo que lo apoya con manuales, cursos de
entrenamiento, programas de certificacin y dems. Tambin lleva una etiqueta de precio, lo qu ha

limitado la investigacin sobre su metodologa. Sin embargo Jennifer Stapleton ha escrito un libro que
da una apreciacin global de la metodologa.
El mtodo empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es
apropiado para el proyecto. El estudio de negocio es una serie corta de talleres para entender el rea
de negocio dnde tiene lugar el desarrollo. Tambin propone arquitecturas de esbozos del sistema y un
plan del proyecto.
El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce
documentacin de anlisis y prototipos, el ciclo de diseo del modelo disea el sistema para uso
operacional, y el ciclo de implantacin se ocupa del despliegue al uso operacional.
DSDM tiene principios subyacentes que incluyen una interaccin activa del usuario, entregas
frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Como otros mtodos giles usan ciclos de
plazos cortos de entre dos y seis semanas. Hay un nfasis en la alta calidad y adaptabilidad hacia
requisitos cambiantes.
No se ha visto mucha evidencia de su uso fuera del Reino Unido, pero DSDM es notable por tener mucha
de la infraestructura de las metodologas tradicionales ms maduras, al mismo tiempo que sigue los
principios de los mtodos giles. Parece haber una pregunta en si sus materiales animan ms de una
orientacin al proceso y ms ceremonia de lo que se gustara.

Definicin del Mtodo de Desarrollo de Sistemas Dinmicos

(DSDM) segn fuentes consultadas
Definicin:
El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development
Method o DSDM) es un mtodo que provee un framework para el desarrollo gil de software,
apoyado por su continua implicacin del usuario en un desarrollo iterativo y creciente que sea
sensible a los requerimientos cambiantes, para desarrollar un sistema que rena las
necesidades de la empresa en tiempo y presupuesto. Es uno de un nmero de mtodos de
desarrollo gil de software y forma parte de alianza gil.[3]
Las metodologas de desarrollo de software son importantes para determinar los recursos
humanos, materiales y financieros, adems de ahorrarle trabajo a los analistas y diseadores
de sistemas.[4]
Es un mtodo que provee un framework para el desarrollo gil de software, apoyado por su
continua implicacin del usuario en un desarrollo iterativo y creciente que sea sensible a los
requerimientos cambiantes, para desarrollar un sistema que rena las necesidades de la
empresa en tiempo y presupuesto. Es uno de un nmero de mtodos de desarrollo gil de
software y forma parte del alianza gil.[5]

Principios del DSDM

Hay 9 principios subyacentes al DSDM consistentes en cuatro fundamentos y cinco puntos de partida
para la estructura del mtodo. Estos principios forman los pilares del desarrollo mediante DSDM.

 Involucrar al cliente es la clave para llevar un proyecto eficiente y efectivo, donde ambos,
cliente y desarrolladores, comparten un entorno de trabajo para que las decisiones puedan ser
tomadas con precisin.
El equipo del proyecto debe tener el poder para tomar decisiones que son importantes para el
progreso del proyecto, sin esperar aprobacin de niveles superiores.
DSDM se centra en la entrega frecuente de productos, asumiendo que entregar algo temprano
es siempre mejor que entregar todo al final. Al entregar el producto frecuentemente desde una
etapa temprana del proyecto, el producto puede ser verificado y revisado all donde la
documentacin de registro y revisin puede ser tenida en cuenta en la siguiente fase o
iteracin.
El principal criterio de aceptacin de entregables en DSDM reside en entregar un sistema que
satisface las actuales necesidades de negocio. No est dirigida tanto a proporcionar un
sistema perfecto que resuelva todas las necesidades posibles del negocio, si no que centra sus
esfuerzos en aquellas funcionalidades crticas para alcanzar las metas establecidas en el
proyecto/negocio.
El desarrollo es iterativo e incremental, guiado por la realimentacin de los usuarios para
converger en una solucin de negocio precisa.
Todos los cambios durante el desarrollo son reversibles.
El alcance de alto nivel y los requerimientos deberan ser base-lined antes de que comience
el proyecto.
Las pruebas son realizadas durante todo el ciclo vital del proyecto. Esto tiene que hacerse
para evitar un caro coste extraordinario en arreglos y mantenimiento del sistema despus de la
entrega.
La comunicacin y cooperacin entre todas las partes interesadas en el proyecto es un
prerrequisito importante para llevar un proyecto efectivo y eficiente.
DSDM tambin se apoya en otros principios (tambin llamadas asunciones).
Ningn sistema es construido a la perfeccin en el primer intento (El principio de pareto regla 80/20). En el proceso de desarrollar un sistema de informacin, el 80% del beneficio de la
empresa proviene del 20% de los requisitos del sistema, as DSDM comienza implementando
primero este 20% de requisitos para cumplir con el 80% de las necesidades de la empresa, lo
que es suficientemente bueno tanto en cuanto los usuarios estn nitmamente involucrados en
el proceso de desarrollo y en una posicin de asegurar que el 20% restante no causar serias
consecuencias al negocio. Implementar la totalidad de requerimientos a menudo causa que un
proyecto supere plazos y presupuestos, as la mayora de las veces es innecesario construir la
solucin perfecta.
La entrega del proyecto debera ser a tiempo, respetando presupuestos y con buena
calidad.
DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que
empiece el siguiente paso. De este modo una nueva iteracin del proyecto puede comenzar
sin tener que esperar a que la previa se complete enteramente. Y con cada nueva iteracin el
sistema se mejora incrementalmente. Recurdese que las necesidades del negocio cambian
constantemente y a cualquier ritmo con el tiempo.
Ambas tcnicas de Desarrollo y Gestin del proyectos estn incluidas en DSDM.
Adems de desarrollar nuevos SI, DSDM puede ser usado tambin en proyectos de ampliacin
de sistemas TI actuales o incluso en proyectos de cambio no relacionados con las TI.
La Evaluacin de riesgos debiera centrarse en entregar funcin de negocio, no en el proceso
de construccin.
La gestin recompensa la entrega de productos ms que la consecucin de tareas.

 La Estimacin debera estar basada en la funcionalidad del negocio en lugar de lneas de

cdigo.[2]

 http://es.wikipedia.org/wiki/Scrum
http://wiki.monagas.udo.edu.ve/index.php/M%C3%A9todo_de_Desarrollo_de_Sistemas_Din
%C3%A1micos
http://es.wikipedia.org/wiki/
http://www.javamexico.org/blogs/carraro/
http://dsdm-chile.blogspot.com