TFC

GESTION DE PROYECTOS
INFORMTICOS

Metodologa Scrum.
Desarrollo detallado de la fase de aprobacin de un proyecto
informtico mediante el uso de metodologas giles.

Autor: Manuel Trigas Gallego.

Consultora: Ana Cristina Domingo Troncho.

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Tabla de contenido
1.-

QU ES UN PROYECTO? ............................................................................................... 3

1.1.-

Fases y ciclos de vida de un

proyecto ................................................................................. 6
1.2.- El modelo tradicional de planificacin
PDCA...................................................................... 9
1.2.1.- Primer paso:
PLANIFICAR. ........................................................................................ 10
1.2.2.- Segundo paso:
HACER. ............................................................................................. 10
1.2.3.- Tercer paso:
VERIFICAR. ........................................................................................... 10
2.EL CONCEPTO DE METODOLOGA. ............................................................................... 11
2.1.-

La metodologa
tradicional. ............................................................................................. 14
2.1.1.- La metodologa en
cascada. ..................................................................................... 15
2.1.2.- Metodologa RUP. ....................................................................................................
17
2.2.- Metodologas
giles ......................................................................................................... 21
2.3.- Comparativa Entre Desarrollo gil Y Desarrollo Tradicional............................................
23
2.4.- Manifiesto
gil ................................................................................................................. 26
2.5.- Los 12 principios del manifiesto
gil. ............................................................................... 31
3.SCRUM. ...................................................................................................................... 32
3.1.-

Introduccin: ..................................................................................................................
.. 32
3.2.- Componentes de
Scrum. ................................................................................................... 35
3.2.1.- Las
Reuniones. ..........................................................................................................
3.2.2.- Los
35
Roles. ..................................................................................................................
3.3.- Elementos
de
35
Scrum. ........................................................................................................ 36
3.3.1.- Product
Baklog. ........................................................................................................ 37
3.3.1.1 Las historias de
Usuario........................................................................................ 38
3.3.1.2 Formato de la Pila Del Producto (Product Baklog). ..............................................
39
3.3.2.- Sprint
Backlog. .......................................................................................................... 40
3.3.3.- Incremento. ............................................................................................................
.. 41
4.DESARROLLO DE LAS FASES DE UN PROYECTO EN SCRUM. ...........................................
41
4.1.- Preparacin del
proyecto. ............................................................................................... 41
4.1.1.- Las Estimaciones del
Backlog ................................................................................... 42
4.2.- Planificar un
Sprint. .......................................................................................................... 44
4.2.1.- La Estimacin del
Sprint. .......................................................................................... 47
4.2.1.1 Planificacin De
Pker. ......................................................................................... 47
4.2.1.2 Mantener el Backlog del
Sprint. ........................................................................... 48
Pgina 1

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

4.2.1.3 Interpretacin del diagrama de Burndown. .........................................................

48
4.3.- El desarrollo del
Sprint...................................................................................................... 49
4.3.1.- Reuniones del
Sprint ................................................................................................ 49
4.3.1.1 Reunin de Planificacin (Sprint Panning Meeting).............................................
49
4.3.1.2 Reunin Diaria (Sprint Daily Meeting)..................................................................
50
4.3.1.3 Reunin Revisin del Sprint (Sprint Review Meeting) ........................................
50
4.3.1.4 Reunin de Retrospectiva (Sprint Retrospective Meeting) .................................
52
4.4.- Diagrama detallado de las fases de
Scrum. ..................................................................... 54
5.BIBLIOGRAFA:............................................................................................................ 55

Pgina 2

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1.- QU ES UN PROYECTO?
Segn la definicin que nos proporciona PMI en su gua PMBOOK, un proyecto se podra definir
como un servicio temporal que se lleva a cabo para crear un producto, servicio o resultado
nico.
Podemos decir entonces que un proyecto tiene un inicio y un fin, este fin se tiene que
alcanzar
dentro de un tiempo fijado.
En un proyecto la consecucin de los objetivos al final del mismo es la mxima deseada, pero
la
mayor parte de las veces, bien por una mala planificacin, o bien por una mala gestin de los
recursos, es imposible finalizar el proyecto con xito. Aun as se da por finalizado (Figura.- 1).

Marco temporal
Objetivo
Alcanzado

Fin

Inicio

Fracaso

Figura.- 1: Grfica definicin de proyecto.

Que el proyecto llegue o no a alcanzar los objetivos depende en gran medida de varios
factores.
El proyecto ideal sera aquel que cumple las siguientes condiciones:
Entorno: No sufre modificaciones de forma rpida, sino que se alargan en el
tiempo.
Cliente: Tiene muy claro que es lo que se necesita, sabe transmitirlo y nosotros
entendemos perfectamente sus necesidades.
Equipo: Disponemos del equipo de profesionales necesario para poder atender a esa
necesidad y adems sabemos cmo resolverla.
Fases: Las fases se haran de una forma lineal, organizada y no surgira ningn
problema
durante su realizacin.
Durante estas fases se realizan las siguientes
actividades:
1. Se hace una toma de requerimientos al principio de nuestro proyecto y no sera
necesaria ninguna reunin ms hasta la entrega final.
2. Se crea la documentacin necesaria en cada fase, y se hace entrega de ella a las
fases siguientes.

Pgina 3

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

3. El cliente ya tiene su producto y este se ajusta a lo indicado, por lo tanto no hay

modificaciones que realizar sobre l.

Toma de
requerimientos de
forma adecuada

Elaboracin de la
documentacin de
forma correcta
para cada fase.

PROYECTO
IDEAL

No hay
modifaciones. El
producto es
correcto.

Figura.- 2: Esquema proyecto ideal.

Pero desgraciadamente el desarrollo de un servicio o producto software no es tan fcil. Esto

es
debido a que el entorno en el que se desarrolla (tecnologa, nuevas funcionalidades, la
competencia) sufre modificaciones de forma constante, de tal manera que la idea de proyecto
inicial difiere mucho de lo que realmente se desea finalmente.
En el planteamiento para crear cualquier producto sera necesario definir los elementos que
van a
participar:

Cliente

Usuarios

Tiempo

Coste

Jefe de
Proyecto

Figura.- 3: Elementos principales a tener en cuenta en la creacin de un producto.

Pgina 4

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1. El cliente: Ser la persona que nos est pidiendo una solucin para un problema
especfico.
2. El usuario: La persona que utilizar esta nueva solucin.
3. El tiempo: El proyecto se atendr a unas fechas de comienzo y unas fechas de
fin.
4. Jefe de Proyecto: Figura necesaria para la gestin de los recursos, as como la
planificacin del proyecto.
Para poder realizar una buena interrelacin de todos estos elementos se debera tener en
cuenta
una serie de puntos:
Deberamos definir qu estructura de organizacin se va a usar. Es importante en este
punto, la aplicacin de la experiencia en proyectos anteriores, puesto que, una buena
comunicacin entre los diferentes departamentos que la definen es vital en la gestin
del
proyecto.
Cuando se defina la organizacin a usar, se tendr especial cuidado en que pueda
cambiar
a lo largo del tiempo, es necesario realizar revisiones peridicas.
Se deberan de definir qu fases van a componer el proyecto.
Creacin de roles y las responsabilidades que implica cada uno de
ellos.
Las tareas que definen el proyecto deberan de estar definidas de forma correcta. Al
mismo tiempo, las tareas tienen que ser validadas por el personal responsable.
Gestionar todos estos elementos necesitan de una figura - sera aqu donde aparece el
Jefe de Proyectos - y tambin una entidad dentro de la organizacin que sera la
Oficina
de Direccin de Proyectos.
Todos estos puntos llevan a la aparicin de una nueva disciplina, la Gestin de
Proyectos.
Realmente la Gestin de Proyectos surgi ya como necesidad en los aos 50 en el mbito
militar.
Los proyectos que se desarrollaban eran de gran magnitud y necesitaban de personal
cualificado
en
diferentes
disciplinas,
lo tanto,
la coordinacin
estos
grupos
era un paso
A partir
de este
momentopor
surgen
nuevos
conceptos a de
la par
que
herramientas
que natural.
van a
facilitar
la gestin de un proyecto, como son el ciclo de vida, descomposicin en tareas, realizacin de
grficos, etc
La Gestin de Proyectos se podra definir como la disciplina de planear, organizar, asegurar y
coordinar recursos y personas para cumplir con los Objetivos, Entregables y Criterios de xito
de
los proyectos (fuente Wikipedia).

Pgina 5

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Una breve descripcin de la evolucin histrica de la gestin de proyectos podramos

mostrarla
en la siguiente grfica.

Figura.- 4: Evolucin histrica de la gestin de proyectos.

1.1.- Fases y ciclos de vida de un proyecto

El comienzo de un proyecto siempre viene acompaado de un grado de incertidumbre. Como
opcin para paliarlo se optar por anidar las tareas a realizar en diferentes fases.
Estas fases servirn para tener un control ms especfico de cada una de las tareas, y
formarn el
denominado Ciclo de Vida de un Proyecto.
Los ciclos de vida de un proyecto servirn para definir el comienzo y el final del mismo.
Generalmente cuando una empresa emprende un proyecto lo primero que solicitar ser un
estudio de viabilidad o factibilidad. Este procedimiento puede ser la base para que se marque
un
inicio del proyecto.
De la misma manera, el ciclo de vida se usa como vnculo con las distintas tareas que se
realizan
dentro de la empresa u organizacin.
Las fases definidas por la mayora de los ciclos de vida de proyectos en general incluyen
alguna
forma de transferencia de tecnologa, tales como requisitos a diseo, construccin a
operaciones
o de diseo a implementacin. Al finalizar una fase se entregar una documentacin, proceso,
etcque comnmente se denomina entregable, que ser revisada y aceptada antes de
continuar
con la siguiente fase; adems servir para corregir y detectar los posibles errores que se
vayan
Pgina 6

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

produciendo, as como las desviaciones en los costes. Las evaluaciones de cada final de fase
suelen tener diferentes nombres como salidas de fase, puntos de impacto o puertas de
etapas.
Sin embargo, en algunas ocasiones se comienza la fase siguiente antes de la aprobacin de
los
productos a entregar de la fase anterior, cuando los riesgos percibidos se pueden asumir. A la
prctica de superponer fases suele denominarse va rpida.
La mayor parte de los ciclos de vida comparten las siguientes
caractersticas:
El coste del personal es bajo al comienzo, ms alto hacia la mitad, y menor al llegar al
final
del proyecto.
El riesgo y la incertidumbre de finalizar el proyecto con xito es ms alta al principio
del
proyecto y la probabilidad de fracaso disminuye a medida que se va avanzando en el
proyecto.
La influencia por parte de los participantes en el producto es ms alta al comienzo del
mismo y decae progresivamente con la continuacin del proyecto. Hay que tener en
cuenta que el coste de los cambios y los errores tiende a aumentar a medida que
avanza
el proyecto.
Los ciclos de vida del proyecto responden a:
Qu trabajo se va a realizar en cada fase?
Quin participar en cada fase?

Las fases se definirn de forma secuencial, es decir, que una fase no comienza hasta
que
termina la otra. Suelen contener una serie hitos o tareas que marcan los momentos
ms
importantes
el desarrollo
del proyecto.
As pues,
la base deen
cada
fase se puede
resumir en:

Entradas

Hitos
Entregables

Figura.- 5: Elementos bsicos que formarn una fase.

Pgina 7

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

El enfoque de ciclo de vida ms usado en las ciencias de la informacin es el que usa las
siguientes
seis fases definidas en funcin de los recursos necesarios:
Fase Inicial
Hito 1: Anlisis de
requerimientos

Hito 2: Viabilidad tcnica

Hito 3: Busqueda de una

solucin tcnica.

Hito 4: Viabilidad financiera.

Definicin
Hito 5: Definicin de las actividades.

Hito 6: Creacin de un diagrama de

actividades.

Hito 7: Crear los planes para la ejecucin.

Ejecucin
Hito 8: Desarrollo.

Hito 9:Integracin del producto.

Hito 10 :Pruebas del producto.

Entrega
Hito 11: Entrega del producto.

Soporte y Mantenimiento.
Hito 12: Desarrollo de productos para el soporte. No siempre es necesario.

Cierre del proyecto

Hito 13: Se formaliza el cierre del proyecto y las lecciones aprendidas.

Figura.- 6: Ciclo de vida bsico de un proyecto.

Todas estas fases, sobre todo en la fase de ejecucin del proyecto suelen ir acompaadas de
unas
etapas complementarias como son, el control, la verificacin y el cumplimiento de las normas.
En
Espaa
existe la
norma UNE157001
estde
ligada
a las TI. el cual puede comenzar o
Es importante
diferenciar
entre cicloque
de vida
un proyecto,
terminar
de forma independiente al inicio de la gestin de proyecto, y el ciclo de vida de la gestin de
proyectos el cual puede finalizar antes de que el producto est finalizado. A pesar de que son
ciclos diferentes, no son independientes.

Pgina 8

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Figura.- 7: Relacin entre el ciclo de vida del producto y el ciclo de vida de un proyecto (Fuente INTECO: Gua
prctica de gestin de Proyectos).

Tanto para el ciclo de vida de un proyecto como para el ciclo de vida de gestin de proyectos
se
puede seguir aplicando el modelo tradicional de planificacin PDCA (Plan, Do, Check, Act), es
decir, Planificar, Hacer, Verificar, Actuar.

1.2.- El modelo tradicional de planificacin PDCA

El modelo PDCA fue desarrollado por Walter Shewhart en los laboratorios Bell en 1930, pero
fue
popularizado por W. Edwards Deming y se suele uno referir a este modelo como circulo de
Deming o tambin espiral de mejora continua.

ACTUAR

PLANIFICAR

Decidir qu
cambios son
necesarios para
mejorar el proceso.

Diseo y revisin
de los procesos
empresarialesy su
perfeccionamiento.

Evaluar las medidas

tomadas e informar
de los resultados a
los que tomarn las
decisiones.

Poner en prctica el
plan y medir su
rendimiento.

VERIFICAR

HACER

Figura.- 8: Grfico PDCA.

Pgina 9

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1.2.1.- Primer paso: PLANIFICAR.

Reconocer el problema y establecer prioridades. El problema puede ser descrito en
trminos muy generales basados en la informacin de varias fuentes.
Formar el equipo de la resolucin de problemas. Equipos interdisciplinarios de las
personas cercanas al problema son los mejores.
Definir el problema y su mbito de aplicacin claramente. Quin, Qu, Cundo y
Dnde.
Anlisis de Pareto puede ser til en la definicin del problema.
Analizar el problema / proceso. Diagramas de flujo del proceso pueden ser
herramientas
tiles.
Determinar las posibles causas. Los diagramas de Causa y efecto servirn para
identificar
las causas de la raz de un problema. Los datos de los diagramas se pueden organizar
mediante el uso de hojas de verificacin, diagramas de dispersin, histogramas, y
grficas
ejecucin.
de
Identificar las posibles soluciones. Lluvia de ideas para encontrar
soluciones.
Evitar la tentacin de proponer soluciones rpidas e inmediatas.
Los objetivos deben ser especficos, medibles, alcanzables y
realistas.
Evaluar las posibles soluciones. Centrarse en las soluciones que aborden las causas
fundamentales y la prevencin de la ocurrencia problema.
Las soluciones deben ser rentables, lograr el consenso del grupo es
importante.

1.2.2.- Segundo paso: HACER.

Implementar la solucin de cambio o proceso.
Seguimiento de los resultados y recopilar datos.

1.2.3.- Tercer paso: VERIFICAR.

Revisar y evaluar el resultado del cambio.
Medir el progreso en contra de los hitos.
Verificar que no haya consecuencias imprevistas.

Pgina 10

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Figura.- 9: Ejemplo desarrollo bsico de un ciclo de mejora con PDCA para la gestin de
competencias (fuente: www.pdca.es).

A la hora de describir el ciclo de vida de un proyecto se podra hacer de forma general o ms

detalladamente.
Estos enfoques detallados en los que se incluyen, formularios, grficos, etc dan lugar al
siguiente
punto: metodologas para la gestin de proyectos.

2.- EL CONCEPTO DE METODOLOGA.

Definiremos la metodologa como aquella disciplina que indicar que mtodos y tcnicas hay
que
usar en cada fase del ciclo de vida de desarrollo del proyecto.
Los elementos que componen a una metodologa son:

Fases

Control y
Evaluacin

Documentacin

Metodologa

Tcnicas y
herramienas

Mtodos

Figura.- 10: Elementos bsicos de una metodologa.

Pgina 11

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1. LAS FASES: En este punto se marcarn las diferentes actividades que hay que realizar
por
cada fase.
2. LOS METODOS: Se tendr que identificar el modo en el que se realizar el proceso de
desarrollo del producto software. Generalmente se suele descomponer los procesos en
tareas ms pequeas, en estas tareas se definen los valores que recibir cada fase as
como los que generar y la tcnica que se tendr que usar.
3. TECNICAS Y HERRAMIENTAS: Indicarn cmo se debera de resolver cada tarea y qu
herramientas podramos usar. Existe diferentes tipos de tcnicas, algunas de ellas son:
a. De recopilacin de datos: Uso de entrevistas, formularios, etc
b. Tcnicas grficas: Diagramas, organigrama, diagramas de matrices,
etc
c. Tcnicas de modelado: Desarrollos estructurados y orientados a objetos:
4. DOCUMENTACIN: Es necesario indicar qu documentacin se va a entregar durante
todas las fases, esa documentacin se debera de realizar de una manera exhaustiva y
completa usando todos los valores de entrada y salida que se van generando, esto
servir
para recoger los resultados y tomar decisiones de las diferentes situaciones planteadas.
5. CONTROL Y EVALUACIN: El control y la evaluacin tambin se debe de realizar a lo
largo
de todo el ciclo de vida. Consistir en comprobar y aceptar/denegar todos los resultados
que se vayan obteniendo y poder replantear, si es necesario, una nueva planificacin de
las tareas asignadas, la meta ser lograr el objetivo.
Suelen usarse tcnicas, como PERT o los diagramas de Gannt.
Aunque no todas las metodologas tienen las mismas caractersticas, s deberan de compartir
los
siguientes puntos para poderse catalogar como una buena metodologa:
1. Ha de ser una metodologa impersonal.
2.

El tiempo de aprendizaje tendra que ser reducido.

3.

Apoyar de forma grfica.

4.

Uso de un estndar para la documentacin.

5.

Que cubra todo o la mayor parte del ciclo de vida del proyecto.

6.

Que simplifique el trabajo y consecuentemente que aumente la

productividad.

7.

Herramientas que ayuden a aumentar tambin la productividad.

8.

Que sea de fcil mantenimiento.

9.

Que la metodologa haya evolucionado y madurado.

10. La formacin.
11. El coste.

Pgina 12

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Las ventajas que aporta el uso de una metodologa para crear un producto se podra resumir
en
los siguientes puntos:
Facilitan la planificacin.
Facilitan el control y el seguimiento adecuado del proyecto.
Mejoran el uso de los recursos.
Permiten evaluar de forma ms fcil los resultados obtenidos y valorar los objetivos
conseguidos.
Mejoran la comunicacin entre el cliente y las personas que van a llevar a cabo el
proyecto.
Garantizan que el producto final tendr la calidad esperada.
Se tendrn presentes unos plazos para el desarrollo del producto.
Permitir definir el ciclo de vida adecuado al proyecto.
Una vez conocidas las ventajas llegar el momento de escoger la metodologa. Esta seleccin
depender de factores como el tamao de la organizacin, experiencia profesional y la
capacidad
de innovar, las herramientas tcnicas de las que se dispone y el tipo de proyecto a desarrollar.
Estos factores se tienen que tener en cuenta, puesto que una metodologa adecuada para el
desarrollo de un servicio o de un producto, no tiene por qu serlo para otro, por muy similar
que
sea.
Podramos realizar una clasificacin de las metodologas existentes en base a los siguientes
enfoques:
El sistema se concibe como un conjunto de unidades que
entran-se procesan-salen. Aplican los conceptos de la
Metodologas
programacin estructurada y fueron las primeras en
orientadas al flujo de aparecer.
informacin:

SEG
N LA
NATUR
ALEZA

Diseo estructurado de Yourdon

Basado en la orientacin de objetos. Se desarrollan

Metodologas
alrededor del concepto de clase.
orientadas a objetos:
Rational Unified Process.

Metodologas hbridas:

Son metodologas que abarcan ms de una de las familias

anteriores. No se centran en la naturaleza tecnolgica del
proyecto, sino en normalizar todos los desarrollos de
software de una organizacin.
Mtrica versin 3

SSADM.

Pgina 13

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Son las metodologas clsicas, los mtodos de trabajo son

muy formales. Conlleva realizar una gran carga de trabajo

SEGN
Metodologas Pesadas: de gestin y generar una gran cantidad de documentacin.
EL
Cascada, RUP.
GRADO
DE
Son las ltimas en aparecer y se basan en dar respuestas a

FORMALI
SMO Metodologas giles:

los problemas con los que se encuentran las metodologas

tradicionales. Usan el concepto de adaptacin a los
requisitos que no se conocen en lugar de la prediccin.
Extrem Programming.
Scrum.

Este ltimo enfoque da lugar a que aparezcan detractores de las metodologas giles. El
motivo es
que estas metodologas al simplificar el proceso ya no son tan rigurosas y afectarn a la
calidad
del software, sin embargo ser la nueva tendencia a seguir.

2.1.- La metodologa tradicional.

Las metodologas tradicionales son el primer tipo de metodologa que surge como gua para
garantizar la creacin de un producto con un nivel de calidad.
Esta metodologa es una disciplina que tiene como base una gestin predictiva, es decir, que
parte de unos requisitos iniciales. Con estos requisitos se configurar un plan adecuado
usando
los recursos y el tiempo necesarios, durante la fase de creacin se comprueba si hay
desviaciones,
si las hay se definen las medidas a tomar y valorar cules son las modificaciones que puede
experimentar la planificacin original.
Por lo tanto, esta metodologa define un conjunto de fases secuenciales en las que se indican
las
operaciones que se van a realizar, el tiempo que van a llevar y cual va a ser su coste.
Las caractersticas ms relevantes de esta metodologa son:
Los requisitos son definidos durante todo el proyecto.
Se basa en los procesos.
Se supone que el proyecto no va a surgir ningn tipo de cambio por lo tanto no est
sujeto a variables.
Los proyectos suelen estar bien documentados.
Gestin predictiva.
El desarrollo se define en fases cuyo conjunto se denomina ciclo de
vida.
Documentacin exhaustiva de todo el proyecto.
Se enfocan en obtener el producto en tiempo estimado y con el coste
establecido.

Pgina 14

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

PMBOOK define los siguientes procesos para una gestin de proyectos con base de una
metodologa tradicional.

Figura.- 11: Imagen extrada del PMBOOK 2004 que representa los procesos de una gestin de
proyectos clsica o tradicional.

2.1.1.- La metodologa en cascada.

La primera metodologa que se empieza a usar es la que denominamos metodologa en
cascada.
Dar lugar al ciclo de vida usado en su implantacin denominado ciclo de vida en cascada.
El ciclo de vida en cascada o waterfall se caracteriza porque todas las fases se realizan de
forma
secuencial, es decir, que las etapas se llevan a cabo una despus de la otra, pero eso s, cada
etapa tiene que estar finalizada antes de comenzar la siguiente. Cada una de estas etapas o
fases
son realizadas por personas o equipos de trabajo especializados.
Las fases que se corresponden con:
1. Requerimientos del sistema.
2. Requerimientos del software.
3. Anlisis.
4. Diseo del programa.
5. Codificacin.
6. Pruebas.
7. Implantacin.
Las tareas que se realizan durante las etapas son:

1. Anlisis de requerimientos: Se analizar el problema, se definirn los requisitos y qu

objetivos se tienen que conseguir.
2. Diseo: Toda la informacin recogida se intenta plasmar mediante una estructura de
datos adecuada, una arquitectura algoritmos a usar, integrales.
3. Codificacin: El diseo se implementar usando la tecnologa escogida como
solucin.
4. Prueba: En esta fase se intenta encontrar los errores para corregirlos adems de
comprobar si el software cumple con el objetivo inicial.

Pgina 15

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

5. Implantacin y mantenimiento: Esta fase servir para corregir errores que no se

detectaron antes, adaptarse al entorno de trabajo y mejorar la aplicacin.
Los roles que se puedan identificar en el modelo de cascada son:
Gestor de proyectos: Gestionar y controlar el proyecto en todas las etapas del
mismo.
Deber de controlar si el proyecto sigue la planificacin y si se estn cumpliendo los
plazos temporales.
Arquitecto del software: Son los encargados de buscar una solucin y estn en las
fases
de especificacin y obtencin de los requisitos adems de en la fase de diseo.
Desarrolladores: Implementarn las instrucciones indicadas por el arquitecto software.
Participa en las fases de desarrollo, pruebas y mantenimiento.
Probadores: Realizaran las pruebas necesarias para comprobar el correcto
funcionamiento del software creado. Se tendr que comprobar si realmente la
aplicacin
satisface las necesidades marcadas por los clientes.
Consejeros: Es una figura necesaria porque a pesar de que no se trata de una persona
tcnica, es experta en ayudar a entender el problema y qu solucin se podr tomar.

Requerimientos
del Sistema

Analista

Requerimientos
del Software

Analista

Anlisis

Analista

Diseo del
Programa

Analista
Arquitectos del software

Codificacin

Desarrolladores

Pruebas

Desarrolladores
Probradores

Implantacin

Gestor de Proyectos

Desarrolladores

Figura.- 12: Relacin de Roles con cada una de las fases.

La metodologa en cascada presenta la ventaja de ser una planificacin sencilla, la calidad

obtenida del producto es alta y no se necesita de un personal altamente cualificado.

Pgina 16

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Sin embargo tiene el inconveniente de que para el desarrollo es necesario tener todos los
requisitos al principio, el problema es que la mayor parte de las veces el cliente al comienzo
del
proyecto no tiene definidas todas las especificaciones y puede ser que surjan situaciones o
casos
imprevistos. Adems aade el inconveniente de que al ser secuencial la correccin de errores
se
vuelve ms difcil, estos errores no se descubren hasta el final que es cuando el cliente va a
Todos
ver el estos inconvenientes hacen que la metodologa finalmente sea ms costosa y
lenta.
resultado, por lo tanto habr que gastar recursos otra vez.
Quizs s es una metodologa adecuada cuando se tienen todas las especificaciones de forma
inicial, el tipo de producto ya es conocido o es un proyecto que se entiende su naturaleza
perfectamente.

2.1.2.- Metodologa RUP.

Otra metodologa caracterstica de la metodologa tradicional es RUP (Rational Unified
Proces).
RUP fue desarrollado por Rational Software y ahora perteneciente a IBM. Se basa en un marco
de
procesos de trabajo que pueden ser adaptados por las organizaciones que hagan el desarrollo
y
por
los desarrolladores,
seleccionando
elementos
ms de
apropiados
del proceso.y se vio
El proceso
Unificado Rational
resulta delos
una
combinacin
varias metodologas
influenciado por otros mtodos como el espiral. Es una metodologa que est basada en
Objectory, metodologa que fue creada por Ivan Jacobson, y el proceso fue desarrollado con
las
mismas tcnicas que el equipo de creadores y desarrollo usaba para el diseo del software.
Se
usara UML (Unified Modeling Language).
RUP se basa en tres mdulos principales que contestan a las preguntas de: quin hace el
proceso,
qu productos de trabajo se van a realizar, qu documentos y modelos se van a producir y
cmo
se
a realizar
las tareas.
Lasvan
fases
que forman
el ciclo de vida de RUP se dividen en cuatro:
1. Inicio: Se establece el objetivo del sistema y se recogen los requisitos del
usuario.
2. Elaboracin: Se busca reducir riesgos y cumplir con la planificacin y coste indicado. Se
genera una estructura arquitectnica que se puede ejecutar y que servir de punto de
partida para despus permitir desarrollar la disciplina de disear, implementar y probar.
3. Fase de construccin: Partiendo de la arquitectura elaborada en la fase anterior se
realizar casi toda la implementacin, creando versiones totalmente funcionales para
comprobar que satisface las necesidades del usuario.
4. Transicin: Se comprueba que el software cumple con todas las necesidades y se
realizan
feedback con el cliente para ajustar el software, dado una de estas fases contiene
interacciones necesarias para alcanzar los objetivos del producto y cada fase tiene un
objetivo y un hito que indicar que el objetivo se ha alcanzado.

Pgina 17

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Figura.- 13: Ciclo de vida RUP (Fuente: http://es.wikipedia.org)

Cada una de estas fases se desarrollar mediante un ciclo de interacciones, stas consisten
en
hacer un ciclo de vida en cascada reducido, en la que el flujo de trabajo ir variando segn la
fase
en
la que
se encuentre.
Estas
interacciones
son llevadas a cabo bajo las disciplinas
de:

1) Disciplina de desarrollo
Requerimientos: Se trasladan las necesidades del negocio a un sistema
automatizado.
Anlisis y diseo: Los requerimientos se trasladan a una arquitectura
software.
Implementacin: Se crea el software adaptndolo a las
necesidades.
Pruebas: Se comprueba que el software acta de forma
adecuada.
2) Disciplina de soporte:
Configuracin y administracin de los cambios.
Administracin de los horarios y recursos.
Ambiente de desarrollo y su administracin.
Los roles que se definen en RUP indican las tareas que tiene que hacer cada uno de los
miembros
del proyecto y el objetivo que se debe de conseguir.
Anthony Crain nos da una visin de los roles segn su grado de detalle, donde en primera
instancia se tiene una visin global de la solucin y el rol asociado, y en una nueva iteracin
se
obtiene el rol especfico:

Pgina 18

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Tabla 1: Roles de RUP (Fuente: Blog de Anthony Crain).

DISCIPLINA

ROLES GENERALES

ROLES ESPECFICOS

Analista de procesos de negocio.

Diseador de negocio. Detallar un
Modelado de negocio Descubrir todos los casos de uso de conjunto de los casos de uso de
negocio.
negocio.

Requisitos

Analista de sistemas. Descubrir

todos los casos de uso.

Especificador de casos de uso.

Detallar un conjunto de los casos
de uso.

Anlisis y diseo

Arquitectos de Software. Toma

decisiones tecnolgicas de la
solucin a nivel global.

Diseadores. Detallan el anlisis y

diseo para un conjunto de casos
de uso.

Implementacin

Integrador. Es el propietario del plan Desarrollador o programador.

de construccin que muestra como Implementa un conjunto de clases
se integrarn cada una de las clases,o un conjunto de operaciones de
las unas con las otras.
una clase.

Pruebas

Despliegue o
Implantacin

Gestin del proyecto

Gestor de las pruebas. Asegura que

las pruebas han sido realizadas
Diseador de pruebas. Implementa
correctamente.
Analista de pruebas. Selecciona qu las pruebas automticas de la
se va a probar segn lo estimado. iteracin.
Diseador de pruebas. Decide qu Probador. Ejecuta un test
pruebas deberan ser automticas o especfico.
manuales, y crea las automticas.

Artista grfico, escritor tecnolgico

Gestor de la implantacin. Supervisa
y desarrollador de material. Crean
la implantacin de todas las
el material necesario para asegurar
unidades.
la correcta implantacin.
Gestor del proyecto. Crea los casos
Gestor de proyectos. Planifica,
de negocio y un plan general, y toma
monitoriza y gestiona los riesgos
decisiones crticas al respecto de que
para una sola iteracin.
cosas hacer y cuales no hacer.
Pgina 19

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Entorno

Ingeniero de procesos. Es el
responsable de los procesos del
proyecto.

Especialista en herramientas. Crea

manuales de uso de herramientas
especficas.

Gestor de la configuracin .

Crea una unidad de despliegue

Gestor de la configuracin.

o implantacin, reportes del

Establece las polticas y planes.
estado de la configuracin,
Gestor de control de cambios.
auditorias, ...
Establece un proceso de control de
Gestor de control de cambios.
los
cambios.
RUP se define por una serie de caractersticas denominadas prcticas y que vienen definidas
Revisa y gestiona las peticiones de
en
RUP, Best Software practices development. cambios.
Configuracin y
Mantenimiento

RUP, BEST SOFTWARE PRACTICES DEVELOPMENT

Decidir qu riesgos tener en cuenta en cada iteracin. Actualizar la lista de
Gestin de los riesgos riesgos y hacerla visible. Utilizar herramientas de gestin de riesgos y
trazabilidad.

Entregas iterativas. Replanificacin basada en el feedback. Planificar las

Desarrollos iterativos iteraciones en funcin de los riesgos. Usar mini y super iteraciones

Usar componentes
basados en la
arquitectura

Aplicar componentes y principio de diseo de servicios. Modelar

componentes, servicios e interfaces. Crear especificaciones detalladas de los
componentes y los servicios.

Gestin de los
requisitos

Identificar escenarios. Capturar casos de uso, y relacionarlos con sus

respectivos escenarios. Trocear casos de uso en requisitos gestionados
independientemente. Utiliza UML para la realizacin de un modelo visual del
software.

La calidad debe ser revisada respecto a los requisitos basndose en la

Modelado del software
fiabilidad, funcionalidad, rendimiento de la aplicacin y del sistema.
visual
Planificacin, diseo, implementacin, ejecucin y evaluacin de las
pruebas.
Verificar la calidad del Controlar y hacer el seguimiento de los cambios. Utilizacin de entornos de
software
trabajos independientes para aislar los diferentes cambios.
La metodologa RUP quizs sea la ms adecuada para proyectos grandes ya
Control de los cambios que necesita disponer de un equipo de trabajo que sea capaz de manejar
del software
procesos en varias etapas.

Pgina 20

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

2.2.- Metodologas giles

Las metodologas giles surgen como una alternativa a las metodologa tradicionales las
cuales,
tal y como acabamos de ver en los apartados anteriores son demasiado burocrticas y por
tanto
rgidas
paralalas
actualesde
caractersticas
Aos atrs
evolucin
los productosdel
eramercado.
lenta y se produca siempre en un entorno

estable en
el que apenas haba variaciones.
Hoy en da sin embargo el entorno en el que se mueve el software es demasiado inestable y
cambiante por lo que estas metodologas no se adaptan, ya que hay que reducir el tiempo de
creacin pero sin dejar de todo la calidad del software.
Las metodologas convencionales presentan para este tipo de proyectos los siguientes
inconvenientes:
1. Es necesario conocer desde el inicio qu desea el cliente.
2. No se deben de cambiar los requisitos iniciales puesto que a medida que se sigue
construyendo el proyecto las modificaciones y la correccin de los errores es ms
costosa.
Adems todos los cambios que se produzcan los sufrir econmicamente el cliente.

Figura.- 14

3. Se establecen mecanismos de control para el proyecto que a veces dan sensacin de

inflexibilidad a posibles cambios y que de hacerlo incrementara el coste.
4. Excesiva documentacin que a veces incluso no es til.
5. Quizs este sera el punto ms importante, la lentitud del desarrollo. Hoy en da para
ser competitivos es necesario la agilidad y flexibilidad a la hora de la creacin de los
productos.
6. Las metodologas tradicionales se encuentran con las dificultades al final del proyecto,
lo
que termina retrasando las entregas.
Pgina 21

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Figura.- 15

Todos estos inconvenientes han hecho que las metodologas clsicas no hayan sido capaces
de
eliminar los fallos y que haya una explosin de creacin de software orientado a la Web, en la
que
se requieren cambios constantes, y que los tiempos de desarrollo sean ms cortos hacen que
aparezca el concepto de metodologa gil como una alternativa atractiva.
El desarrollo gil est centrado en la iteracin, comunicacin y en reducir elementos
intermedios.
El desarrollo con interacciones se realiza normalmente en porciones de tiempo pequeas
denominadas timeboxes y se ocupar de desarrollarlas un equipo multidisciplinar
autoorganizado, ellos mismo decidirn como realizar las tareas de la iteracin.
Adems el mtodo de desarrollo gil fomenta la comunicacin entre los miembros del equipo
lo
que previene problema que en otra metodologa quedan escondidos.
Esta comunicacin no solo se establece de forma cerrada entre los miembros del equipo sino
que
tambin se realiza con la figura que representa al cliente.
El representante del cliente es necesario como elemento de apoyo para los desarrolladores
puesto que ser la persona a la que se podrn hacer las preguntas necesarias y que junto con
el
resto de personas involucradas en el negocio comprobarn si se cumplen los objetivos.
Por lo tanto trabajar con una buena comunicacin permite que se puedan tomar las
decisiones de
forma ms rpida y aplicarlas.
La caracterstica realmente nueva que aportan estas metodologas es reconocer a las
personas
como el principal valor para que un proyecto consiga terminarse de forma correcta. El factor
ms
importante en el desarrollo de software no son las tcnicas y las herramientas que emplean
los
Podemos deducir que las metodologas giles a diferencia de las metodologas tradicionales o
programadores, sino la calidad de los programadores. (Robert. L. Class).
clsicas son ms adecuadas cuando el entorno presenta una cierta incertidumbre o es
cambiante.

Pgina 22

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

En este contexto se podran definir las siguientes ventajas:

1. Gran capacidad de respuesta ante los cambios, los cuales no se entienden como un
problema sino como algo necesario para que el producto sea mejor y satisfaga al
cliente.
Los cambios formarn parte del proceso de desarrollo.
2. Las entregas no se hacen al final sino que se hacen pequeas entregas. Estas entregas
permiten al cliente valorar el producto adems de ir trabajando con algunas
funcionalidades.
3. Los ciclos cortos de entrega ayudarn a disminuir los riesgos sobre todo al principio del
proyecto.
4. Se trabaja en equipo entre el cliente y los desarrolladores mediante una comunicacin
casi diaria para evitar errores y documentacin innecesaria.
5. Eliminar el trabajo que no es necesario y que realmente no aporta un valor al
negocio.
6. Buscar la mejor tcnica y el mejor diseo para conseguir productos de
calidad.
7. Mejorar los procesos y al equipo que realiza el desarrollo.

2.3.- Comparativa Entre Desarrollo gil Y Desarrollo Tradicional

En la planificacin de cualquier proyecto hay una serie de conceptos que son
comunes:
1. El tringulo de hierro, en el que se tienen en cuenta las tres variables principales del
proyecto
El alcance, definir las tareas necesarias para alcanzar las caractersticas que
deseamos obtener de nuestro producto.
El tiempo, previsin de la duracin que llevar el proyecto.
El presupuesto o coste, dinero y recursos que se van a destinar al proyecto.

Figura.- 16: Tringulo de hierro.

Pgina 23

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

La modificacin de uno de los vrtices de este tringulo influenciar sobre los otros 2,
atacando al
punto ms importante que es la calidad del software o del producto.
2. Qu riesgos pude haber para poder reducirlos.
3. Definicin de hitos para realizar entregas.
4. Las dependencias funcionales y la cohesin de los trabajos para ahorrar esfuerzos y
realizar planificaciones coherentes.
De forma esquemtica podemos presentarlas siguientes diferencias entre la metodologa
tradicional y la metodologa gil.

DESARROLLO
TRADICIONAL

1.

Se identifican las tareas al inicio del proyecto.

2.

Control predictivo en que predice las variables de tiempo, alcance

y
presupuesto. El desarrollo se realiza en cascada, se hace una
entrega final del proyecto.

3.

Debido a que las entregas se hacen al final, puede que el producto

no cumpla con los requisitos establecidos y sea necesario hacer
cambios que comprometan a dos elementos o vrtices del
tringulo: coste y tiempo.

4.

Proceso controlado con muchas ms normas.

5.

Uso de reuniones entre equipo y cliente.

6.

Resistencia a los cambios.

7.

No se suelen hacer anlisis del trabajo realizado, denominado

retrospeccin, en el que se intenta ver las cosas que se han
realizado, de forma correcta, qu hay que mejorar y qu problemas
podran aparecer.

8.

Mayor nmero de roles.

Figura.- 17: Esquema planificacin tradicional (Fuente www.proyectosagiles.org)

Pgina 24

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1. Se basa en el control emprico, en que se asume que va a haber

cambios en el contexto del proyecto, por lo tanto, el control del
proyecto se basar en controlar los resultados obtenidos y en funcin
de stos, hacer las adaptaciones adecuadas (ciclo PDCA).

DESARROLLO
GIL

2. Las fases se plantean en funcin de los objetivos del producto, que

suelen ser en cortos perodos de tiempo y en los que se hacen
demostraciones del producto a los clientes; de esta forma es ms fcil
realizar los cambios.
3. El proceso no necesita de tanto control.
4. El cliente es parte del proyecto.
5. Todo el equipo participa en todas las fases del proyecto.
6. Hay menos roles.
7. Se realiza retrospectiva durante todo el proyecto.

Figura.- 18: Esquema Planificacin gil (Fuente www.proyectosagiles.org)

Pgina 25

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

2.4.- Manifiesto gil

Podramos utilizar como definicin de agilidad la ofrecida por Quomer y Henderson
Selles
La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta
flexibilidad para adaptarse a los cambios esperados o inesperados, rpidamente; persigue la
duracin ms corta en tiempo, usa instrumentos econmicos; y utiliza los conocimientos y
experiencias previos para aprender tanto del entorno interno como del externo.
Basndose en esta metodologa, y entendiendo que las necesidades del entorno han
cambiado el
tipo del cliente y las necesidades de su empresa, en el ao 2001 se produce una reunin
convocada por Kent Beck autor aos antes del libro Extrem Programming Explained - en el
que se dio origen al trmino Mtodos giles.
A causa de estos mtodos giles, que estaban surgiendo, se definieron los 4 postulados que
dan
origen a:

Estamos poniendo al descubierto mejores mtodos para desarrollar

software, hacindolo y ayudando a otros a que lo hagan con este
trabajo, hemos llegado a valorar:

A los individuos y su iteracin

Por encima de

los procesos y las herramientas.

El software que funciona

Por encima de

documentacin exhaustiva.

La colaboracin con el cliente

Por encima de

de la negociacin contractual.

Las respuestas al cambio

Por encima de

seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos ms los

de
la izquierda
Jeff Sutherland inventor de Scrum en 1993, y que particip en la creacin del manifiesto gil,
nos
describe de la siguiente manera los 4 postulados del manifiesto en su artculo Principios y
valores de Agile, por Jeff Sutherland .
El siguiente artculo fue extrado, por su inters, ntegramente para este trabajo de
investigacin
del blog de Jeff Sutherland:
Pgina 26

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Estos valores no son slo algo que los creadores del Manifiesto gil (Agile Manifesto)
pensaban encomiar y, a continuacin, olvidarse. Son valores que funcionan. Cada
metodologa
gil individual enfoca estos valores de una manera ligeramente diferente, pero todas estas
metodologas tienen procesos y ejercicios concretos que fomentan uno o ms de estos
valores

Individuos e interacciones

Los individuos e interacciones son esenciales para los equipos de alto rendimiento. Los
estudios
de "saturacin de la comunicacin" durante un proyecto mostraron que, cuando no existe
ningn
problema de comunicacin, los equipos pueden rendir 50 veces ms que el promedio del
sector.
Para facilitar la comunicacin, los mtodos giles confan en los ciclos de inspeccin y
Estos
ciclos pueden variar de cada pocos minutos con programacin entre iguales, cada
adaptacin
pocas
frecuentes.
horas con integracin continua o todos los das con una reunin de puesta en marcha, hasta
cada
iteracin
con simplemente
una revisin yaumentar
retrospectiva.
No obstante,
la frecuencia de los comentarios y la comunicacin no es
suficiente para eliminar los problemas de comunicacin. Estos ciclos de inspeccin y
adaptacin
solo funcionan bien cuando los miembros del equipo presentan varios comportamientos clave:

respeto por el valor de cada persona

veracidad en cada comunicacin

transparencia de todos los datos, acciones y decisiones

confianza en que cada persona respaldar al equipo

compromiso con el equipo y los objetivos del equipo

Para fomentar estos tipos de comportamiento, la administracin gil debe proporcionar un

entorno de apoyo, los entrenamientos del equipo deben facilitar su inclusin y los miembros
del
equipo deben mostrarlos. Slo entonces podrn lograr los equipos todo su potencial.
Acercarse a estos tipos de comportamiento es ms difcil de lo que puede parecer. La mayora
de
los equipos evitan la verdad, la transparencia y la confianza debido a las normas culturales o
las
experiencias
pasadas de
conflictosygenerados
por del
comunicadores
sinceros.
Para
combatirnegativas
estas tendencias,
la direccin
los miembros
equipo deben
facilitar el
conflicto
positivo. Hacerlo no solo ayuda a crear un comportamiento productivo, tambin tiene varias
ventajas ms:

La mejora del proceso depende de que el equipo genere una lista de impedimentos o
problemas en la organizacin, se enfrente a ellos directamente y, a continuacin, los
elimine sistemticamente en orden de prioridad.

La innovacin solo se produce con el intercambio libre de ideas conflictivas, un

fenmeno
estudiado y documentado por Takeuchi y Nonaka, los padrinos de Scrum.
Alinear al equipo hacia un objetivo comn requiere que el equipo manifieste y resuelva
las agendas conflictivas.

Pgina 27

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

El compromiso de trabajar juntos slo se consigue cuando las personas acuerdan los
objetivos comunes y, a continuacin, se esfuerzan por mejorar personalmente y como
equipo.

Este ltimo punto, sobre el compromiso, es especialmente importante. Slo cuando los
individuos
y los equipos se comprometen, se sienten responsables para entregar un alto valor, que es la
lnea de base para los equipos de desarrollo de software. Las metodologas giles facilitan el
compromiso animando a los equipos a extraer una lista de trabajo clasificada por orden de
prioridad, administrar su propio trabajo y centrarse en mejorar sus prcticas de trabajo. Esta
prctica es la base de la organizacin del equipo por s mismo, que es la fuerza motriz para
lograr
resultados en un equipo gil.
Para crear equipos de alto rendimiento, las metodologas giles valoran a los individuos y las
interacciones sobre los procesos y herramientas. Hablando prcticamente, todas las
metodologas
giles buscan aumentar la comunicacin y colaboracin a travs de los ciclos de inspeccin y
adaptacin frecuentes. Sin embargo, estos ciclos solo funcionan cuando los coordinadores
giles
fomentan el conflicto positivo que se necesita para generar una base slida de verdad,
transparencia, confianza, respeto y compromiso en sus equipos giles.

Software que funciona sobre la documentacin completa

El software que funciona es una de las grandes diferencias que aporta el desarrollo gil. Todas
las
metodologas giles que se representan en el Manifiesto gil (Agile Manifesto) subrayan la
entrega al cliente de partes pequeas de software que funciona a intervalos fijos.
Todos los equipos giles deben establecer lo que significa que digan "software que funciona",
conocido con frecuencia como la definicin de terminado. En un nivel alto, una parte de la
funcionalidad se ha completado solo cuando sus caractersticas pasan todas las pruebas y
pueden
ser utilizadas por un usuario final. Como mnimo, los equipos deben ir ms all del nivel de la
prueba unitaria y probar en el nivel del sistema. Los mejores equipos tambin incluyen
pruebas
de integracin, rendimiento y aceptacin del cliente en su definicin de lo que significa haber
terminado una parte de la funcionalidad.
Una compaa de CMMI nivel 5 ha mostrado, a travs de datos extensos en muchos
proyectos,
que definir las pruebas de aceptacin junto con la caracterstica, implementar las
caractersticas
consecutivamente y en orden de prioridad, realizar las pruebas de aceptacin en cada
caracterstica inmediatamente y corregir cualquier error identificado como prioridad mxima
duplicar la velocidad de produccin sistemticamente y reducir los defectos en un 40 por
ciento. Esto procede de una compaa que ya tiene una de las tasas de defectos ms bajas
del
El Manifiesto gil (Agile Manifesto) recomienda que los equipos entreguen el software que
mundo.
funciona a intervalos establecidos. Acordar una definicin de "terminado" es una de las
maneras
prcticas en que los equipos giles dan lugar al alto rendimiento y alta calidad que se
necesitan
para lograr este objetivo.

Pgina 28

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Colaboracin del cliente sobre la negociacin del contrato

Durante las dos ltimas dcadas, las tasas de xito de los proyectos han aumentado a ms
del
doble en todo el mundo. Esto se atribuye a los proyectos menores y las entregas frecuentes,
que
permiten al cliente proporcionar comentarios sobre el software que funciona a intervalos
regulares. Los redactores del manifiesto saban de qu estaban hablando cuando enfatizaron
que
conseguir la implicacin del cliente en el proceso de desarrollo de software es esencial para el
Las
metodologas giles fomentan este valor ya que un representante del cliente trabaja
xito.
mano a
mano con el equipo de desarrollo. Por ejemplo, el primer equipo de Scrum tena miles de
clientes.
Dado que no era factible implicarlos a todos en el desarrollo del producto, seleccionaron a un
representante del cliente, llamado propietario del producto, para representar no solo a todos
los
clientes en el campo respectivo, tambin la a administracin, ventas, soporte tcnico,
servicios al
cliente y otras partes interesadas. El propietario del producto era responsable de actualizar la
lista
de requisitos cada cuatro semanas a medida que el equipo liberaba el software que funciona,
teniendo en cuenta la realidad actual y los comentarios reales de los clientes y partes
El
primer equipo de XP comenz con un proyecto de TI interno. Pudieron tener a un usuario
interesadas.
final
Esto permita al cliente ayudar a dar forma al software que estaban creando.
de la compaa en su equipo para que trabajara con ellos a diario. Las consultoras y los
equipos
internos pueden encontrar a un usuario final que trabaje con el equipo todos los das
aproximadamente el 10 por ciento del tiempo. Para el otro 90 por ciento del tiempo, deben
designar a un representante. Este representante del cliente, a quien los equipos de XP llaman
"el
cliente", trabaja con los usuarios finales para proporcionar una lista clara, clasificada por
Colaborar
orden de con el cliente (o el representante del cliente) todos los das es uno de los motivos
clave
prioridad de las caractersticas que los desarrolladores de software deben implementar.
por los que los datos del sector muestran que los proyectos giles tienen ms del doble de
xito
que los proyectos tradicionales por trmino medio en todo el mundo. Las metodologas giles
reconocen esto y, por tanto, han creado en sus equipos de desarrollo un lugar que es
especficamente para el representante del cliente.

Responder al cambio sobre seguir un plan

Responder al cambio es esencial para crear un producto que agrade el cliente y proporcione
valor
comercial. Los datos del sector muestran que ms del 60 por ciento de los requisitos de
producto
o de proyecto cambian durante el desarrollo de software. Incluso cuando los proyectos
tradicionales finalizan a tiempo, segn el presupuesto y con todas las caractersticas del plan,
los
clientes se sienten a menudo insatisfechos porque lo que encuentran no es exactamente lo
que
deseaban. "La "Ley de Humphrey" dice que los clientes nunca saben lo que desean hasta que
ven
el software que funciona. Si los clientes no ven el software que funciona hasta el fin de un
proyecto,
es demasiadogiles
tarde tienen
para incorporar
comentarios.
Las metodologas
Todas las metodologas
procesos sus
integrados
para cambiar
sus planesgiles
a
buscan
intervalos
los
comentarios
del cliente
lo largo del del
proyecto
puedan incorporar
comentarios
y
regulares
en funcin
de los a
comentarios
clientepara
o suque
representante.
Sus planes
estn
nueva
informacin
a
medida
que
se
desarrolla
el
producto.
diseados para entregar siempre primero el mayor valor comercial. Dado que el 80 por ciento
del
Pgina 29

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

valor representa el 20 por ciento de las caractersticas, los proyectos giles bien realizados
tienden a finalizar temprano, mientras que la mayora de los proyectos tradicionales finalizan
tarde. Como resultado, los clientes estn ms satisfechos y los desarrolladores de software
disfrutan ms de su trabajo. Las metodologas giles estn basadas en el conocimiento de
que
para tener xito, se debe planear para cambiar .Por eso han establecido procesos, como
revisiones y retrospectivas, diseados especficamente para desplazar las prioridades con
regularidad en funcin de los comentarios del cliente y el valor comercial.

Pgina 30

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

2.5.- Los 12 principios del manifiesto gil.

1.-

2.-

3.-

4.-

5.-

6.-

7.-

8.-

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua
de softwarecon valor.
Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los
procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses,

con
preferencia al periodo de tiempo ms corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana
durante todoel proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno
y
el apoyo que necesitan, y confiarles la ejecucin del trabajo.
El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo
y
entre sus miembros es la conversacin cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores

y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9.-

La atencin continua a la excelencia tcnica y al buen diseo mejora la

Agilidad.

10.-

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

11.-

Las mejores arquitecturas, requisitos y diseos emergen de equipos autoorganizados.

12.-

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a

continuacin ajustar y perfeccionar su comportamiento en consecuencia.

Figura.- 19: Los 12 principios del Manifiesto gil.

Pgina 31

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Algunos de las metodologas giles ms utilizadas hoy en da, por mayor orden de presencia
segn
la mayora de los estudios realizados son:
Extreme Programming.
Test Drive Development.
Agile Project Management.
Scrum. Ser en este ltimo ser en el que centraremos el resto del trabajo de
investigacin.

3.- SCRUM.
3.1.- Introduccin:
En el ao 1986 Takeuchi y Nonaka publicaron el artculo The New Product Developroent
Game
el cual dar a conocer una nueva forma de gestionar proyectos en la que la agilidad,
flexibilidad, y
la
incertidumbre
son
elementos
principales.
Nonaka
y Takeuchi
selos
fijaron
en empresas
tecnolgicas que, estando en el mismo entorno en
el
que se encontraban otras empresas, realizaban productos en menos tiempo, de buena calidad
y
menos
costes.
Observando
a empresas como Honda, HP, Canonetc., se dieron cuenta de que el producto
no
segua unas fases en las que haba un equipo especializado en cada una de ellas, si no que se
parta de unos requisitos muy generales y el producto lo realizaba un equipo multidisciplinar
que
trabajaba desde el comienzo del proyecto hasta el final.
Se compar esta forma de trabajo en equipo, con la colaboracin que hacen los jugadores de
Rugby y la utilizacin de una formacin denominada SCRUM.
Scrum aparece como una prctica destinada a los productos tecnolgicos y ser en 1993
cuando
realmente Jeff Sutherland aplique un modelo de desarrollo de Software en Ease/Corporation.
En 1996, Jeff Sutherland y Ken Schwaber presentaron las prcticas que se usaban como
proceso
formal para el desarrollo de software y que pasaran a incluirse en la lista de Agile Alliance.
Scrum es adecuado para aquellas empresas en las que el desarrollo de los productos se
realiza en
entornos que se caracterizan por tener:
1. Incertidumbre: Sobre esta variable se plantea el objetivo que se quiere alcanzar sin
proporcionar un plan detallado del producto.
Esto genera un reto y da una autonoma que sirve para generar una tensin
adecuada
para la motivacin de los equipos.
2. Auto-organizacin: Los equipos son capaces de organizarse por s solos, no
necesitan
roles para la gestin pero tienen que reunir las siguientes caractersticas:

Pgina 32

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Autonoma: Son los encargados de encontrar la solucin usando la estrategia

que
encuentren adecuada.
Autosuperacin: Las soluciones iniciales sufrirn mejoras.
Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos
de
forma mutua, aportando soluciones que puedan complementarse.
3. Control moderado: Se establecer un control suficiente para evitar descontroles. Se
basa
en crear un escenario de autocontrol entre iguales para no impedir la creatividad y
espontaneidad de los miembros del equipo.
4. Transmisin del conocimiento: Todo el mundo aprende de todo el mundo. Las personas
pasan de unos proyectos a otros y as comparten sus conocimientos a lo largo de la
organizacin.
Scrum al ser una metodologa de desarrollo gil tiene como base la idea de creacin de ciclos
breves para el desarrollo, que comnmente se llaman iteraciones y que en Scrum se llamarn
Sprints.
Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5 fases que definen el
ciclo
de desarrollo gil:
1. Concepto: Se define de forma general las caractersticas del producto y se asigna
el
equipo que se encargar de su desarrollo.
2. Especulacin: en esta fase se hacen disposiciones con la informacin obtenida y se
establecen los lmites que marcarn el desarrollo del producto, tales como costes y
agendas.
Se construir el producto a partir de las ideas principales y se comprueban las
partes
realizadas y su impacto en el entorno.
Esta fase se repite en cada iteracin y consiste, en rasgos generales, en:
Desarrollar y revisar los requisitos generales.
Mantener la lista de las funcionalidades que se esperan.
Plan de entrega. Se establecen las fechas de las versiones, hitos e
iteraciones.
Medir el esfuerzo realizado en el proyecto.
3. Exploracin: Se incrementa el producto en el que se aaden las funcionalidades de la
fase
de especulacin.
4. Revisin: El equipo revisa todo lo que se ha construido y se contrasta con el
objetivo
deseado.
5. Cierre: Se entregar en la fecha acordada una versin del producto deseado. Al
tratarse
de una versin, el cierre no indica que se ha finalizado el proyecto, sino que seguir
habiendo cambios, denominados mantenimiento, que har que el producto final se
acerque al producto final deseado.

Pgina 33

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Concepto

Cierre

Especulacin
ITERACCIONES

Revisin

Exploracin

Figura.- 20: Ciclo de desarrollo gil.

Scrum gestiona estas iteraciones a travs de reuniones diarias, uno de los elementos
fundamentales de esta metodologa.

Figura.- 21: Ciclo principal de Scrum

Pgina 34

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

3.2.- Componentes de Scrum.

Para entender todo el proceso de desarrollo del Scrum, se describir de forma general las
fases y
los roles. Estas fases y roles se detallarn de forma ms concisa ms adelante.
Scrum se puede dividir de forma general en 3 fases, que podemos entender como reuniones.
Las
reuniones forman parte de los artefactos de esta metodologa junto con los roles y los
elementos
que
lo forman.
3.2.1.Las Reuniones.
1. Planificacin del Backlog
Se definir un documento en el que se reflejarn los requisitos del sistema por
prioridades.
En esta fase se definir tambin la planificacin del Sprint 0, en la que se decidir cules
van a
ser los objetivos y el trabajo que hay que realizar para esa iteracin.
Se obtendr adems en esta reunin un Sprint Backlog, que es la lista de tareas y que es
el
objetivo ms importante del Sprint.
2. Seguimiento del Sprint
En esta fase se hacen reuniones diarias en las que las 3 preguntas principales para
evaluar el
avance de las tareas sern:
Qu trabajo se realiz desde la reunin anterior?
Qu trabajo se har hasta una nueva reunin?
Inconvenientes que han surgido y qu hay que solucionar para poder
continuar.
3. Revisin del Sprint
Cuando se finaliza el Sprint se realizar una revisin del incremento que se ha generado.
Se presentarn los resultados finales y una demo o versin, esto ayudar a mejorar el
feedback con el cliente.

3.2.2.- Los Roles.

Los roles se dividen en 2 grupos: cerdos y gallinas, esto surge en el chiste sobre un cerdo
y
una gallina y su intencin de poner un restaurante.

Pgina 35

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

1. LOS CERDOS
Son las personas que estn comprometidas con el proyecto y el proceso de
Scrum.
Product Owner: Es la persona que toma las decisiones, y es la que realmente
conoce el
negocio del cliente y su visin del producto. Se encarga de escribir las ideas del
cliente,
ordena por Es
prioridad
y las coloca
en el Product
Backlog.
las
ScrumMaster:
el encargado
de comprobar
que el
modelo y la metodologa
funciona. Eliminar todos los inconvenientes que hagan que el proceso no fluya e
interactuar con el cliente y con los gestores.
Equipo De Desarrollo: suele ser un equipo pequeo de unas 5-9 personas y tienen
autoridad para organizar y tomar decisiones para conseguir su objetivo. Est
involucrado en la estimacin del esfuerzo de las tareas del Backlog.
2. LAS GALLINAS
Aunque no son parte del proceso de Scrum, es necesario que parte de la
retroalimentacin d la salida del proceso y as poder revisar y planear cada sprint.
Usuarios: Es el destinatario final del producto.
Stakeholders: Las personas a las que el proyecto les producir un beneficio.
Participan
durante las revisiones del Sprint.
Managers: Toma las decisiones finales participando en la seleccin de los objetivos y
de los requisitos.

3.3.- Elementos de Scrum.

Los elementos que forman a Scrum son:
Product Backlog: lista de necesidades del cliente.
Sprint Backlog: lista de tareas que se realizan en un Sprint.
Incremento: parte aadida o desarrollada en un Sprint, es un parte terminada y
totalmente operativa.

Figura.- 22: Ciclo de desarrollo Scrum.

Pgina 36

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

3.3.1.- Product Backlog.

Es el inventario en el que se almacenan todas las funcionalidades o requisitos en forma de
lista
priorizada. Estos requisitos sern los que tendr el producto o los que ir adquiriendo en
sucesivas iteraciones.
La lista ser gestionada y creada por el cliente con la ayuda del Scrum Master, quien indicar
el
coste estimado para completar un requisito, y adems contendr todo lo que aporte un valor
final
al
Lasproducto.
tres caractersticas principales de esta lista de objetivos
sern:

Contendr los objetivos del producto, se suele usar para expresarlos las historias de
usuario.
En cada objetivo, se indicar el valor que le da el cliente y el coste estimado; de
esta
manera, se realiza la lista, priorizando por valor y coste, se basar en el ROI.
En la lista se tendrn que indicar las posibles iteraciones y los releases que se han
indicado al cliente.
La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para
solventarlos.

Es necesario que antes de empezar el primer Sprint se definan cules van a ser los objetivos
del
producto y tener la lista de los requisitos ya definida. No es necesario que sea muy detallada,
simplemente deber contener los requisitos principales para que el equipo pueda trabajar.
Realizar este orden de tareas tiene como beneficios:
El proyecto no se paraliza simplemente por no tener claro los requisitos menos
relevantes, y el cliente podr ver resultados de forma ms rpida.
Los requisitos secundarios aparecern a medida que se va desarrollando el
proyecto,
por lo tanto, no se pierde tanto tiempo en analizarlos al principio y el cliente ser
ms consciente de sus necesidades.
Los requisitos secundarios puede que no se lleguen a necesitar porque se han
sustituido o porque no reportan un retorno ROI interesante.
Una vez definidos los requisitos se tendr que acordar cundo se tiene que entender un
objetivo
como terminado o completado.
Se entiende que un producto est completado si:
Asegura que se puede realizar un entregable para realizar una demostracin de los
requisitos y ver qu se han cumplido.
Incluir todo lo necesario para indicar que se est realizando el producto que el
cliente desea.
Como complemento a la definicin de completado, se debera de asociar una condicin de
aceptacin o no aceptacin a cada objetivo en el mismo momento en el que se crea la lista.

Pgina 37

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Finalmente el Product Backlog ir evolucionando mientras el producto exista en el mercado.

Esta
es la forma para evolucionar y tener un valor de producto para el cliente suficiente para ser
competitivo.

3.3.1.1 Las historias de Usuario.

Son las descripciones de las funcionalidades que va a tener el
software.
Estas historias de usuario, sern el resultado de la colaboracin entre el cliente y el equipo, e
irn
evolucionando durante toda la vida del proyecto.
Las historias de usuario se componen de tres fases denominadas Las 3
C:
Card: Ser una breve descripcin escrita que servir como
recordatorio.
Conversation: Es una conversacin que servir para asegurarse de que se ha
entendido bien todo, y concretar el objetivo.
Confirmation: Tests funcionales para fijar detalles que sean relevantes e indicar cul
va
a ser el lmite.
En cuanto al formato, un modelo podra ser como el que se muestra en la siguiente
imagen:

Figura.- 23: Ejemplo de Historia de usuario (fuente: http://devnettips.blogspot.com.es/)

ID: Identificador de la historia de usuario.

TTULO: Ttulo descriptivo de la historia de usuario.

Pgina 38

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

DESCRIPCIN: Descripcin sintetizada de la historia de usuario.

ESTIMACIN: Evaluacin del coste de implementacin en unidades de desarrollo.
Estas unidades representarn el tiempo terico (desarrollo/hombre) que se haya
estimado al comienzo del proyecto.
PRIORIDAD: Prioridad en la implementacin de la historia de usuario respecto al
resto
de las historias de usuario. A mayor nmero, mayor prioridad. Otra aproximacin a
la
priorizacin
dese
tareas
hace a travs
del mtodo MoSCoW:
M Must,
debe se
completar
este requerimiento
para finalizar el
proyecto.
S Should, se debe completar este proyecto por todos los medios, pero el xito
del proyecto no depende de l.
C Could, se debera completar este requerimiento si su implementacin no
afecta a la consecucin de los objetivos principales del proyecto.
W Would, se puede completar este requerimiento si sobra tiempo de
desarrollo
(o en futuras versiones del mismo)
DEPENDENCIAS: Una historia de usuario no debera ser dependiente de otra
historia,
pero a veces es inevitable. En este apartado se indicaran los IDs de las tareas de
las
que depende
una Del
tarea.
3.3.1.2 Formato
de la Pila
Producto (Product Backlog).
En Scrum, la preferencia por tener documentacin en todo momento es menos estricta. Se
encuentra ms necesario el mantener una comunicacin directa con el equipo, por eso se usa
como herramienta el Backlog.
Aunque no hay ningn producto especial a la hora de confeccionar la lista, es conveniente
que
incluya informacin relativa a:
Identificador para la funcionalidad.
Descripcin de la funcionalidad.
Sistema de priorizacin u orden.
Estimacin.

Figura.- 24: Ejemplo de un Product Backlog(Fuente: Srum Manager. Gestin de Proyectos)

Pgina 39

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

3.3.2.- Sprint Backlog.

Es la lista de tareas que elabora el equipo durante la planificacin de un Sprint.
Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.
De esta manera el proyecto se descompone en unidades ms pequeas y se puede
determinar o
ver en qu tareas no se est avanzando e intentar eliminar el problema.

Figura.- 25: Ejemplo de Sprint Backlog.

Cmo funciona la lista:

Es una lista ordenada por prioridades para el cliente.
Puede haber dependencias entre una tarea y otra, por lo tanto se tendr que
diferenciar de alguna manera.
Todas las tareas tienen que tener un coste semejante que ser entre 4-16
horas.
Formato de la lista:
Hay 3 opciones:
Hojas de clculo.
Pizarras.
Herramientas colaborativas.
Generalmente, las tareas a completar se suelen gestionar mediante el Scrum Taskboard, a
cada
objetivo se le asignan las tareas necesarias para llevarlo a cabo, se usan post-its que se van
moviendo de una columna a otra para cambiar el estado.
Se debe incluir:
Lista de tareas.
Persona responsable de cada tarea, el estado en el que se encuentra y el tiempo
que
queda por terminarla.
Pgina 40

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Permite la consulta diaria del equipo.

Permite tener una referencia diaria del tiempo que le queda a cada tarea.

3.3.3.- Incremento.
Representa los requisitos que se han completado en una iteracin y que son perfectamente
operativos.
Segn los resultados que se obtengan, el cliente puede ir haciendo los cambios necesarios y
replanteando el proyecto.

4.- DESARROLLO DE LAS FASES DE UN PROYECTO EN SCRUM.

4.1.- Preparacin del proyecto.
Conocida como Sprint 0, es la fase inicial en la que se intenta comprender el caso de negocio
con
la finalidad de tomar decisiones que agreguen valor al producto.
Durante esta fase se producen gran nmero de inexactitudes con las estimaciones, pero es
lgico,
debido a que se hacen a alto nivel, por lo tanto es aconsejable no perder tiempo en buscar las
estimaciones exactas, es mejor invertir ese tiempo en el desarrollo del producto. De esta
manera
el Backlog del producto usar como unidad de tiempo das.
Las tareas a realizar en el sprint O son:
Definir el proyecto: Se debera de indicar de forma clara el propsito del proyecto,
no
es necesario entrar en detalle pero s que todo el equipo sea capaz de entender
cules
las terminado:
necesidades del
producto
y delen
cliente.
son
Definir
Marcar
el punto
el que se va a considerar que la tarea est
terminada.
Definicin del Backlog inicial: Se comienza la creacin del Backlog del producto para
que el Sprint siguiente contenga elementos de la lista suficientes para comenzar a
trabajar. Esta lista de elementos ser marcada por el Product Owner, que tendr
como
responsabilidad priorizar las funcionalidades que, al desarrollarlas e implementarlas
cumplan las especificaciones consiguiendo adems que su beneficio supere a su
coste.
Definicin de los entregables: Una vez que se tiene el Backlog con las
funcionalidades,
es necesario establecer criterios para hacer pequeas entregas entregables del
producto y as obtener su valor y un feedback temprano.
El plan de entregables puede sufrir modificaciones, muchas de ellas propiciadas
por:
Cambia el entorno y aparecen nuevas oportunidades para el negocio.
Se encuentran nuevas funcionalidades y estas proporcionan un valor si se pusiese
en
produccin.
Replanteamiento del entregable.

Pgina 41

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

El plan de entregas lo determinar el negocio, que ser el encargado de marcar qu

funciones,
calidad y coste va a tener.
De la misma manera, estar sujeto a unas determinadas condiciones determinadas por el
equipo
de trabajo que sern:
Tiempo para un entregable.
La estimacin inicial.
Seleccin del Backlog del producto.
Constitucin del equipo:
Se hace una reunin inicial con todos los roles del equipo para
tratar:
Dimensin del proyecto.
Revisiones del Backlog.
Organizacin del equipo y horario para establecer reuniones de control.

4.1.1.- Las Estimaciones del Backlog

Antes de la primera reunin de la planificacin el Equipo tiene que conocer cul va a ser su
velocidad inicial y su factor de dedicacin.
Para poder realizar las estimaciones, primeramente hay que decidir qu historias incluir en la
pila
del Sprint.
La forma en la que se podr decidir qu historias poner o no se puede realizar mediante 2
tcnicas:
De forma aproximada.
Realizando clculos de velocidad.
1. De forma aproximada:
En la estimacin aproximada, el equipo debate el nmero de historias a introducir hasta llegar
a
un acuerdo. Suele funcionar de forma correcta si los Sprints son cortos.
2. Realizando los clculos de velocidad:
Esta tcnica se realiza en dos pasos:
Seleccionar la velocidad estimada.
Calcular el nmero de historias que se pueden aadir sin pasar la velocidad
estimada.
La manera ms adecuada de estimar la velocidad, es revisar el historial del equipo, de esta
manera, basndonos en Sprints anteriores se podr deducir que ser muy similar.

Pgina 42

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Para poder realizar esta tcnica, es necesario que los equipos tengan un historial, que vayan
hacer
los prximos Sprints de la misma manera, mismo tamao de equipo y las mismas condiciones
de
trabajo.
La tcnica
se conoce
como el
elclculo
tiempode
que
hizo ayer.
Otra forma
de hacerlo
es mediante
recursos.
1. Se calcula el nmero de das hombre disponible, este es un valor poco real porque
influyen
factores externos de ah que tengamos que usar el factor de dedicacin.

Nombre

Das

USER 1

15

USER 2

13

USER 3

USER 4

13

TOTAL

Planificacin de un Sprint de 3
semanas con disponibilidades
distintas

48 Das-Hombre Disponibles

VELOCIDAD ESTIMADA
(

)(

El factor de dedicacin se basa en estimar el estado del equipo, si es bajo entonces se espera
encontrar dificultades.
La forma ms adecuada para determinar factores de dedicacin razonable es el estado
de los
ltimos Sprints.
FACTOR DE DEDICACIN
(

Velocidad real = suma de las estimaciones iniciales que se realizaron completamente

en
el ltimo Sprint.
Ejemplo:
Si tenemos un equipo que complet 20 historias de usuario, con 3 personas sumando 35 dashombre, para calcular el prximo Sprint en el que habr un componente ms, sumando 45
dashombre y teniendo en cuenta que en el ltimo Sprint se completaron 20 puntos, el resultado
sera:

De esta manera se obtendr la velocidad estimada por el siguiente

Sprint.

Pgina 43

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Si el equipo fuese nuevo, se puede mirar el factor de dedicacin de otros equipos con lo que
fijarte y de no haberlo, se pondra un valor aproximado para empezar por defecto. El factor
que se
suele usar es de 70%.

4.2.- Planificar un Sprint.

Figura.- 26: Entras/Salidas de un Planning Meeting.

Denominado tambin Sprint Planning Meeting, tiene como finalidad realizar una reunin, en
la
que participarn el Product Owner, el Scrum Master y el equipo, con la intencin de
seleccionar
de la lista Backlog del producto las funcionalidades sobre las que se va a trabajar, y que
darn
Antes de comenzar la reunin el Product Owner tendr que preparar el
valor al producto.
Backlog.
La reunin se realiza en con time-box de ocho horas que se divide en 2 partes de 4
horas.
Primera parte de la reunin:
El equipo selecciona los items para transformarlos en entregables.
El equipo hace sugerencias, pero es el Product Owner el que decidir si formarn
parte del Sprint.
El equipo seleccionar el elemento a implementar, de los seleccionados por el
Product Owner para ese Sprint.
Segunda parte de la reunin:
El equipo har las preguntas necesarias que tengan sobre el Product Baklog al
Product Owner.
El equipo se encargar de encontrar la solucin adecuada para transformar la parte
seleccionada de una funcionalidad entregable.
Pgina 44

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

El resultado de la segunda parte de la reunin es una lista denominada Sprint Backlog con
las
tareas, estimaciones y las asignaciones de trabajo al equipo para poder empezar a desarrollar
la
funcionalidad.
Las caractersticas del Backlog del producto sern las
siguientes:
La estimacin ser entre 4 y 16 horas, si son mayores a este valor, se
descompondrn.

Las tareas del Sprint deben de ser como consecuencia de la necesidad de un

requerimiento del Backlog del producto.
El progreso de las tareas en las que se mide la velocidad y el progreso del Sprint
con
respecto a las horas, se realizar mediante grficos Burndown Chart.

Figura.- 27: Grfico de avance de un Sprint

El soporte en el que se presentan el Sprint Backlog puede

ser:
Hoja de clculo.
Pizarra.
Herramientas colaborativas de red.
La herramienta como soporte quizs ms utilizada es el (Scrum Taskboard) en la que en una
pizarra se crea una tabla con la siguiente informacin:

Pgina 45

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Figura.- 28: Ejemplo de Scrum Task Board(Fuente: Proyectos giles.org)

1 fila: Tareas que no se han planificado pero que son necesarias de hacer por su
urgencia (errores, cambios importantes decididos por el cliente, etc).
2 fila: Mejora continua. Se ponen las tareas de retrospectivas anteriores que se
quieren analizar en ese Sprint.
Columna tareas no empezadas: Se pondrn todas las tareas que se han
especificado
en la reunin del Sprint planning.
En curso: Tareas que se estn realizando y que deberan ser mnimas y resueltas de
arriba abajo.
Hecho: Tarea realizada completamente.
Impedimentos: Lista de obstculos que impedirn continuar de forma adecuada el
proyecto. Hay que indicar quin ser el responsable de solucionarlos.
Retrospectiva: Sirve para anotar qu partes estn bien durante la iteracin y cules
mal. Se reflejan con un + y un -
Otro ejemplo de Scrum TaskBoard sera:

Figura.- 29: Scurm TaskBoard(Fuente: Scrum y Xp desde las trincheras)

Pgina 46

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

4.2.1.- La Estimacin del Sprint.

4.2.1.1 Planificacin De Pker.
Realizar las estimaciones para los tems seleccionados, es una tarea que deber involucrar a
todos
los miembros del equipo. Para poder hacer una estimacin y que los miembros del equipo no
estn condicionados por la estimacin de los compaeros se usar, la tcnica de Planning
Poker.

Figura.- 30

1. Cada miembro del equipo tendr una baraja de 13 cartas.

2. Se propone una historia, el miembro del equipo selecciona una carta y
la coloca boca abajo. Esta carta representar su estimacin para la
historia propuesta.
3. Cuando todos los miembros han seleccionado su carta, se le da la
vuelta al mismo tiempo.
4. Se comprueban las estimaciones, y si hay muchas discrepancias se
discute sobre esas diferencias y se ponen en comn las ideas sobre la
naturaleza del trabajo. Este proceso se repetir hasta que las
estimaciones sean parejas o aproximadas.
5. Se comprueban las estimaciones y si hay muchas discrepancias se
discute sobre esas diferencias y se ponen en comn las ideas sobre la
naturaleza del trabajo. Este proceso se repetir hasta que las
estimaciones sean parejas o aproximadas.
6. El tiempo estimado es para el desarrollo de toda la historia, por ese
motivo la secuencia de nmeros no es lineal y, por ejemplo, hay un
salto entre 40 y 100. De esta manera se evita sensaciones falsas para
estimaciones grandes.

Si las estimaciones fuesen ms detalladas las historias se podran dividir en historias ms

pequeas.

Pgina 47

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Hay 3 cartas especiales:

O Esta historia ya est hecha o requiere poco tiempo de
trabajo.
No hay idea de cunto puede ser la estimacin.
Taza de caf: Realizar un descanso para retomar despus la
estimacin.

4.2.1.2 Mantener el Backlog del Sprint.

El equipo tiene que mantener actualizado el Backlog del Sprint para poder tener feedback y
tomar
cualquier decisin de manera rpida.
Es necesario, adems, para que el grfico de Burdown del Sprint tambin est
actualizado.

4.2.1.3 Interpretacin del diagrama de Burndown.

Ejemplo 1:
50
Trabajo
40
restante(pun
30
tos de
20
historia) 10
0
1

10

11

12

15

16

17

18

19

Tiempo
El da1 de Enero se estiman 7 puntos de historia, y a da 16 se observa que, incluso se est
bien de
tiempo y que segn estos datos, completaramos el Sprint. Hay que tener en cuenta que se
saltan
los
fines 2:
de semana para no generar confusiones en la lectura del diagrama.
Ejemplo
50
Trabajo
40
restante(pun
30
tos de
20
historia) 10
0
1

10

11

12

15

16

17

18

19

Tiempo
Si el grfico que se genera es similar al del ejemplo 2, puede ocurrir que los puntos de historia
se
hagan ms rpido de lo previsto, con lo que se podran aadir ms puntos de historia.

Pgina 48

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Ejemplo 3:
50
Trabajo 40
restante 30
(puntos de20
historia) 10
0
1

10

11

12

15

16

17

18

19

Tiempo
En este caso, lo que nos muestra el grfico es que se han escogido demasiados tems para
realizarlo y habra que analizar qu tems del Backlog habra que eliminar en esta fase.
En los Sprints, el equipo trabaja para conseguir un incremento del producto, que ser
productivo
para el Product Owner y los Stakeholders.
El tiempo ms conveniente est entre 2 y 4 semanas, o 30 das consecutivos como mximo.
Estos
intervalos de tiempo, son los que se consideran ms apropiados para que el Stakeholders no
pierda el inters.

4.3.- El desarrollo del Sprint

En los Sprints, el equipo trabaja para conseguir un incremento del producto, que ser
productivo
para el Producto Owner y los Stakeholders.
El tiempo ms conveniente est entre 2 y 4 semanas, o 30 das consecutivos como mximo.
Estos
intervalos de tiempo, son los que se consideran ms apropiados para que el Stakeholders no
pierda el inters.

4.3.1.- Reuniones del Sprint

Durante la ejecucin del Sprint se van a realizar 3
reuniones:
Reunin de Planificacin (Sprint Planning Meeting).
Reunin diaria (Scrum Daily Meeting).
Reunin Revisin del Sprint (Sprint Review Meeting).

4.3.1.1 Reunin de Planificacin (Sprint Planning Meeting)

Definirn qu tareas se tienen que realizar y cules son los
objetivos.
Una vez definidos, el equipo comienza su desarrollo, pero teniendo en cuenta una serie de
normas:
El equipo puede realizar consultas de agenda fuera del Sprint.
No se permite a nadie gobernar al equipo durante el Sprint. El equipo se
autogestionar.

Pgina 49

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

Si durante el desarrollo del Sprint no se puede realizar, porque no es viable, se

puede
realizar una nueva planificacin para realizar un nuevo Sprint.
Si el equipo no puede comprometerse a cumplir todo el Backlog, realizar una
consulta con el Producto Owner para decidir qu tems eliminar.
Si de la misma manera, el equipo se ve capaz de realizar ms tems del Backlog
durante el Sprint, que el indicado inicialmente, consultar tambin con el Product
Owner qu tems se podrn aadir.
Teniendo en cuenta estas caractersticas, a lo largo del desarrollo, se producirn adems,
reuniones diarias.

4.3.1.2 Reunin Diaria (Sprint Daily Meeting)

En esta reunin, los componentes del equipo comparten informacin relativa al desarrollo y
colaborarn para hacer las adaptaciones necesarias, aumentando as su productividad.
En esta reunin se tendr como referencia el Backlog del Sprint y el equipo grfico burn-down
con
la informacin de la reunin anterior y, adems, qu tareas hizo cada persona del equipo. La
reunin no podr consumir ms de 15 minutos y contestar a tres preguntas bsicas:
Qu se ha hecho de nuevo con respecto a la ltima reunin diaria?
Qu ser lo siguiente a realizar?
Qu problemas hay para realizarlos?
Se usar como herramienta de apoyo, con la lista de tareas del Sprint actualizada y con el
esfuerzo pendiente de cada tare. Tambin se tendr un grfico con las tareas pendientes en la
iteracin.

4.3.1.3 Reunin Revisin del Sprint (Sprint Review Meeting)

Figura.- 31

Pgina 50

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

En esta reunin, los desarrolladores presentan el producto entregable que han implementado
y,
los gestores, clientes, usuarios y Product Owner analizan esa entrega y escuchan al equipo
sobre
los problemas
que han
tenido
durante
el proceso.
Esta
reunin servir
para
tomar
decisiones
que ayudan a escoger el camino ms adecuado
para
alcanzar las metas.
Las caractersticas de esta reunin se limitan a:
Mximo 4 horas.
Se presenta el producto completado, entendiendo como tal la definicin acordada
con el Product Owner y los Stakeholders.
Si la funcionalidad no est completa no se puede presentar.
Artefactos que no son funcionalidades, no se presentan para no equivocar a los
Stakeholders.
Se presenta la funcionalidad en equipos que pertenezcan a los desarrolladores.
Siempre se har desde un servidor lo ms parecido posible al de produccin.
El Sprint Review transcurre siguiendo el siguiente proceso:

Figura.- 32

Pgina 51

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

El ScrumMaster determina cuntas personas asistirn al Sprint Review

Meeting.
Al final de la reunin, el ScrumMaster anuncia al Product Owner y a los Stakeholders
la prxima reunin.
Estas reuniones son beneficiosas para todos, puesto que se
comprueba:
Si el equipo ha cumplido las expectativas.
Y si el equipo ha entendido al cliente.
Se produce entonces una satisfaccin personal al comprobar y ver funcionando la
entrega.

4.3.1.4 Reunin de Retrospectiva (Sprint Retrospective Meeting)

En esta reunin, el equipo debatir temas relacionados con el Sprint recientemente
finalizado y
los cambios que se podran hacer para mejorar el prximo Sprint y que sea ms productivo.
Generalmente, ser el ScrumMaster quin realiza esta reunin y tendr una duracin
mxima de
3 horas.
Las caractersticas generales de la reunin sern:
Asistirn el ScrumMaster, el Equipo y el Product Owner.
La reunin girar entorno a dos preguntas bsicas: Qu ha ido bien durante el
ltimo Sprint?, Qu ser mejorado para el siguiente Sprint?.
El ScrumMaster toma nota delas respuestas del Equipo en un formulario.
El Equipo hablar de las posibles mejoras que se puedan realizar, indicando cules
van a tener mayor preferencia.
El ScrumMaster ayudar a entrar mejores vas de apoyo, para las mejoras indicadas
por el Equipo.
Si hay puntos que merezca atencin se aadirn para el siguiente Sprint,
considerndolo como un Backlog no funcional, pero de alta prioridad

Pgina 52

METODOLOGA SCRUM

Figura.- 33: Ejemplo de Retrospectiva, de James Shore

Pgina 53

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

4.4.- Diagrama detallado de las fases de Scrum.

Se ha realizado de esta manera una gua por todo el proceso de creacin de un proyecto
Scrum en
el que se van realizando las diferentes 5 fases en forma de ciclos, hasta completar todas las
tareas del Backlog.

REVISIN DE PLANES DE VERSIN:

Se revisa que hay que hacer y en que punto est
la distribucin actual.

SPRINT:
Es la fase de desarrollo iterativa.
Desarrollo: Anlisis, implementacin, testing.
Empaquetar: Generar paquetes ejecutables
Revisin: Resolucin de problemas y se aaden
nuevos tems.
Ajustes: Uso de los ajustes para mejorar el
producto.

SPRINT REVIEW:
Despus del Sprint se hace una reunin con el
ScrumMaster donde se revisa el producto del
Sprint anterior y en el que se pueden aadir
puntos nuevos al backlog.

Cierre:
En esta fase se encuentran las tpicas actividades
de fin de proyecto como, hacer una versin
distribuible, testear, marketing etc.
Tabla 2: Esquema de las 5 fases de desarrollo en Scrum.

Pgina 54

METODOLOGA SCRUM

Desarrollo detallado de la fase de

aprobacin de un proyecto
informtico mediante el uso de
metodologas giles

5.- BIBLIOGRAFA:
Libros.
Scrum Manager Gestin de Proyectos. Juan Palacio, Claudia Ruata.
Flexibilidad con Scrum. Juan Palacio.
Scrum y Xp desde las trincheras. Henrik Kniberg.
Agile Project Management with Scrum. Ren Schaner.
Pginas Web Consultadas.
http://www.scrumsense.com
http://www.proyectosagiles.org
http://www.acis.org.co
http://www.mastersoft.com.ar
http://assets.scrumfoundation.com
http://www.gestiondeproyectosit.es
http://agileee.org
http://www.pdca.es
http://msdn.microsoft.com/es-es/library/dd997578l

Pgina 55