Metodologia Scrum aplicada a un proyecto de creacion de un sistema informático

1. METODOLOGÍA DE DISEÑO DE SISTEMAS
METODOLOGIA SCRUM
“Proyecto Sistema GRH-TUC”
Profesor: Ing. JUAREZ, Gustavo
Alumnos:
MUCCELA, José Daniel - Leg.: 20196
UNIVERSIDAD TECNOLÓGICA NACIONAL
FACULTAD REGIONAL TUCUMÁN

2. METODOLOGIA SCRUM
La metodología SCRUM – Proyecto Sistema GRH-TUC
Introducción
¿Que mejor introducción que aclarar un poco los conceptos?
Primeramente mencionaremos sobre lo que es una metodología.
En el ambiente de desarrollo de sistemas, una metodología es el proceso de aplicar
ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un
sistema, con suficientes detalles como para permitir su interpretación y realización física.
Ahora estamos en condiciones de hablar de la metodología Scrum.
Marco teórico
Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es
elevar al máximo la productividad de un equipo. Tiene las siguientes características:
o Permite el manejo ágil de proyectos.
o Define una serie de roles, reuniones y herramientas (artefactos).
o Muy utilizada en proyectos de software donde el desarrollo es “un caos”, los
cambios son una constante y existe poca previsibilidad.
o Delega completamente en el equipo la responsabilidad.
o Se basa en la auto-organización.
o Abarca prácticas relacionadas con la gestión de proyectos.
Cabe mencionar lo que son las metodologías ágiles. Nos referimos a:
• Responder a los cambios que surjan durante las etapas del ciclo de vida del software
más que seguir estrictamente un plan. Seguir estrictamente un plan propuesto muchas
veces ocasiona que el esfuerzo para corregir un sistema en desarrollo sea mucho más
complejo y sea una ardua tarea. Como vemos la metodología ágil propone responder a los
cambio cuando surgen.
• Es buscar un justo medio entre ningún proceso y demasiado proceso,
proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
2

3. Roles que se desempeñan dentro de la Metodología Scrum
En esta metodología se presentan una serie de papeles o roles que desempeñan las
personas para su ejecución. Estos roles están bien definidos y permanecen a lo largo de un
proyecto y hasta su finalización. Los roles son los siguientes:
• Product Owner: conoce y marca las prioridades del proyecto o producto.
Representa a todos los interesados en el producto final. Sus áreas de responsabilidad son:
o Financiación del proyecto.
o Retorno de la inversión del proyecto.
o Lanzamiento del proyecto.
• Scrum Master: es la persona que asegura el seguimiento de la metodología guiando
las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su
responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas. Siendo
responsable del proceso Scrum, tiene las siguientes características:
o Formación y entrenamiento del proceso.
o Incorporación de Scrum en la cultura de la empresa.
o Garantía de cumplimiento de roles y responsabilidades.
• Team Member: son las personas responsables de implementar la funcionalidad o
funcionalidades elegidas por el Product Owner. Son Responsables de transformar el
Backlog de la iteración en un incremento de la funcionalidad del software. Sus
características son:
o Auto-gestionado.
o Auto-organizado.
o Multi-funcional.
Scrum, más que una metodología de desarrollo software, es una forma de auto-
gestión de los equipos de programadores. Un grupo de programadores deciden cómo hacer
sus tareas y cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la
misma dirección, con un objetivo claro.
Scrum permite además seguir de forma clara el avance de las tareas a realizar, de
forma que los "jefes" puedan ver día a día cómo progresa el trabajo.
Sin embargo, Scrum no es una metodología de desarrollo, puesto que no indica qué
se debe hacer para hacer el código. Debería, por tanto, complementarse con alguna otra
3

4. metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la
programación extrema.
Esta metodología nos da la posibilidad de llevar a cabo un proyecto de software
sacando el mayor provecho de los participantes, en términos de productividad.
Para que esto sea posible, el equipo completo (el Scrum) debe estar bien constituido
y todos los actores que intervendrán en la consecución del proyecto.
En el apartado anterior se mencionó sobre los roles que existen dentro de la
metodología Scrum. Cuando no fuera posible o cueste involucrar al cliente en el desarrollo
del proyecto, cuando el equipo no es experto y no es capaz de auto-organizarse o bien,
cuando no vale la pena aplicar el Scrum por tratarse el proyecto a ejecutar de algo trivial,
usar esta metodología carece de sentido y difícilmente se puedan lograr resultados
satisfactorios.
Delegar completamente en el equipo la responsabilidad de decidir la mejor manera
de trabajar para ser lo más productivos posibles y darle gran protagonismo a las reuniones
que realicen a lo largo del proyecto es de vital importancia a la hora de los resultados. Esto
es así, debido en primera medida a la constitución de los equipos de trabajo los cuales están
formados de hasta 7 personas que revisan los requisitos, la tecnología disponible y evalúan
los conocimientos para que colectivamente puedan determinar como incrementar la
funcionalidad. Estos equipos llevan a cabo reuniones diarias que no debería consumir más
de 15 minutos. El Scrum Master ejecuta la reunión y se encarga del éxito global del
proyecto, supervisa las respuestas por parte de los miembros del equipo y elimina los
obstáculos identificados durante estas reuniones, permitiendo que el equipo avance hacia
sus objetivos.
Muchas veces, los miembros de los equipos pueden desempeñar múltiples
funciones, la energía y la eficiencia de cada uno tiene que ver con la combinación correcta.
Como buena metodología, Scrum posee también iteraciones en sus procesos de
desarrollo. Estas iteraciones se podrán llevar a cabo luego de que transcurra un Sprint. Un
Sprint es un periodo de 30 días de duración y durante este periodo se establecen los
objetivos y tareas que deberán llevar a cabo los equipos de trabajo. Al finalizar este período
se produce una reunión donde se ponen de manifiesto los resultados obtenidos, se
presentan los ejecutables obtenidos; también se plantean las desviaciones encontradas y
cualquier cuestión que requiera de atención.
Como dijimos, el equipo está ligado a través de la organización por un scrum diario y
una reunión mensual de planificación, lo que proporciona una visibilidad vertical a través de
toda la organización. Esta situación provoca que los problemas de organización y los retos
impuestos salten a la vista. Como todos los miembros del equipo tienen vinculación directa
con el proyecto, la comunicación entre las partes es breve, rápida y eficiente. El equipo es
4

5. auto-organizado y se centra en los objetivos del sprint (30 días planificados). Toda esta
situación genera como resultado extraer lo mejor de cada individuo del equipo.
Por ultimo diremos que una correcta aplicación de esta metodología requiere un
equipo muy motivado, un buen liderazgo y una buena y estrecha relación con el cliente.
Después de todo, el esfuerzo en conseguir y mantener un buen líder y un equipo motivado
se compensa al momento de obtener los resultados de productividad, beneficios que
llegaron a ser en muchos casos un 600 % de nivel de eficacia incluso en proyectos aún en
ejecución.
Modelo de la metodología Scrum
5

6. Aplicación de la Metodología SCRUM en un proyecto de desarrollo de software real
Sistema GRH-TUC
Vamos a utilizar el sistema GRH-TUC para aplicar la metodología que estamos
desarrollando. Las especificaciones sobre el sistema mencionado se encuentran anexas a
esta documentación.
Roles dentro del proyecto
• Product Owner: el encargado es Daniel
• Scrum Master: Alejandra (es un miembro del equipo – responsable de moderar
reuniones y de que las ayudas/problemas que plantean los programadores se resuelvan a lo
largo del día de trabajo).
• Team Member: compuesto por:
o Alejandra
o Emmanuel
o Pablo
Presentación del Sistema
El proyecto tiene por objeto crear un sistema para la gestión de Recursos Humanos
de una Empresa.
El Cliente
El cliente en este caso es cualquier Empresa que requiere el control y seguimiento
de su personal.
Metas
• Mejorar la velocidad y mantenimiento en la gestión de empleados.
• Facilitar la registración de los cursos.
• Facilitar la registración de empleados.
• Facilitar la registración de puestos.
• Facilitar la registración de áreas de la empresa
• Control de empleados, cursos, puestos y áreas de la Empresa.
• Permitir el seguimiento de la capacitación de Empleados.
6

7. Lista de funciones a implementar (Product Backlog)
El backlog es un inventario o una lista priorizada de requerimientos funcionales,
mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de
las sucesivas iteraciones. Siempre esta en continuo crecimiento y evolución. Representa
todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto.
Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el
backlog.
Primeramente vamos a definir los requerimientos crudos. Veremos que luego de la
primera reunión surge la lista con ciertas características que la identifican.
Enunciamos entonces la lista preparada por el Product Owner:
Requerimientos
Debe basarse en Web
Debe tener un diseño atractivo
Debe usarse tecnologías libres
Las opciones del sistema (manejo de datos) se accederá a
través de usuario y contraseña
Consultar las preferencias del dueño del producto
Diseño de la Base de Datos
Registrar el ingreso de un nuevo empleado
Registrar el ingreso de un nuevo curso, asignándole su
número de curso
Registrar el ingreso de un nuevo puesto de trabajo
Registrar el ingreso de una nueva área de la Empresa
Permitir Buscar un empleado a través de su nombre
Registrar la realización de cursos
Registrar para cada curso la fecha de realización
Permitir la eliminación de un empleado
Permitir la eliminación de un curso
Permitir la eliminación de un puesto
Permitir la eliminación de un área
Permitir la modificación de datos de un empleado
Permitir la modificación de datos de un curso
Permitir la modificación de datos de un puesto
Permitir la modificación de datos de un área
Permitir la creación de nuevos usuarios del sistema
El product backlog no es un documento de requisitos, sino una herramienta de
referencia para el equipo. Es recomendable el formato de lista que incluya al menos la
siguiente información para cada línea:
Identificador único de la funcionalidad o trabajo.
Descripción de la funcionalidad.
Campo o sistema de priorización.
Estimación
7

8. Con esta información el product owner comienza a darle forma al listado.
Estimación
Id Descripción Prioridad
(HS)
Debe basarse en Web Alta 24
Investigar sobre tecnologías Web Alta 12
Investigar sobre hardware necesario Alta 12
Debe tener un diseño atractivo Alta 36
Investigar sobre buenos diseños de aplicaciones Web Alta 24
Investigar sobre plantillas prediseñadas Alta 12
Debe usarse tecnologías libres Alta 48
Investigar sobre las tecnologías libres aplicadas a Web Alta 24
Investigar sobre licencias de aplicaciones libres Alta 12
Investigar sobre hardware y software necesario Alta 12
Las opciones del sistema (manejo de datos) se accederá a 36
Alta
través de usuario y contraseña
Investigar métodos de acceso al sistema Alta 24
Investigar métodos de validación de datos de entrada Alta 12
Consultar las preferencias del dueño del producto Alta 20
Diseño de la Base de Datos Alta 56
Registrar el ingreso de un nuevo empleado Alta 8
Registrar el ingreso de un nuevo curso, asignándole su
Alta
número de curso 10
Registrar el ingreso de un nuevo puesto de trabajo Alta 8
Registrar el ingreso de una nueva área de la Empresa Alta 8
Permitir Buscar un empleado a través de su nombre Alta 12
Registrar la realización de cursos Alta 8
Registrar para cada curso la fecha de realización Media 6
Permitir la eliminación de un empleado Media 6
Permitir la eliminación de un curso Media 6
Permitir la eliminación de un puesto Media 6
Permitir la eliminación de un área Media 6
Permitir la modificación de datos de un empleado Media 8
Permitir la modificación de datos de un curso Media 8
Permitir la modificación de datos de un puesto Media 8
Permitir la modificación de datos de un área Media 8
Permitir la creación de nuevos usuarios del sistema Media 12
El product owner decide colocar prioridades al listado, dejando que sea revisado por
el equipo. El ID del requerimiento (que luego se convertirá en tarea o tareas) surgirá en base
a los objetivos del primer Sprint, es decir en la primera reunión (la de planeación) se decidirá
qué requisitos irán para el primer período, para el segundo, etc., y en base a esto
colocaremos el ID del mismo. La prioridad surge de las apreciaciones de los requisitos; se
determinará también por parte del product owner con la ayuda del equipo. Luego la
estimación surge en base a las apreciaciones y a la experiencia de los miembros del equipo.
Los miembros del equipo eligen las tareas (no son asignadas). Aquí es de vital
importancia la experiencia de los integrantes de equipo.
8

9. Sprint Planning Meeting y Spring Backlog (Reunión de planeación para el período y la
Lista de Tareas para el período)
El primer día que empecemos a trabajar en el proyecto, se hace una reunión, en la
que estarán el Product Owner y los programadores (Scrum Team) que van a participar en el
proyecto.
En esta reunión se elije un plazo de tiempo que Scrum aconseja que sea un mes. En
nuestro caso lo definimos para 15 (quince) días. De todas formas, en función del proyecto,
necesidades y demás, puede elegirse otro plazo: una semana, dos semanas u otro tiempo.
Nunca debería ser un plazo muy largo.
Una vez elegido el plazo de tiempo, se revisa el Product Backlog y se van mirando
las tareas empezando por la primera.
Se realizan una serie de preguntas al Scrum Team: ¿la primera tarea puede estar
hecha dentro de un mes?
El Scrum Team la examina, descompone en subtareas si hace falta, estiman el
tiempo que tardarán en hacerla y dicen "sí". Si dicen que no, habrá que descomponerla en
tareas más sencillas hasta que digan al menos que sí a una de ellas.
Se toma la segunda tarea y se pregunta al Scrum Team: ¿puede estar la primera y la
segunda en un mes? Vuelven a estimar y dicen "sí".
Se repite el proceso con las siguientes tareas hasta que el Scrum Team comience a
dudar si se va a terminar con todo lo previsto. Si el Product Owner quiere que esté alguna
tarea que no va a estar, puede cambiarla por otra que sí esté, o "reducir" el alcance de una
de las que ha entrado para que entre otra. En fin, este es el momento de "negociar" entre los
programadores y el jefe “qué va a entrar o no en 15 días”. El jefe puede decidir el orden,
intercambiar tareas, modificarlas o partirlas, pero los programadores tienen la última palabra
de cuánto tiempo necesitan (estimación) para cada tarea. El tiempo necesario para todas las
tareas seleccionadas no puede superar los 15 días.
Una vez llegado a un acuerdo, esas funcionalidades se pasan a una nueva lista,
llamada Sprint Backlog. Hemos quedado todos de acuerdo que dentro de 15 días vamos a
entregar al Product Owner una versión del programa que tenga todas las tareas del Srpint
Backlog funcionando.
Finalmente se decide que para el primer período (Sprint1) la lista de tareas es la
siguiente:
9

10. Estimación
Id Descripción Prioridad
(HS)
B1.1 Debe basarse en Web Alta 24
B1.1.1 Investigar sobre tecnologías Web Alta 12
B1.1.2 Investigar sobre hardware necesario Alta 12
B1.2 Debe tener un diseño atractivo Alta 36
B1.2.1 Investigar sobre buenos diseños de aplicaciones Web Alta 24
B1.2.2 Investigar sobre plantillas prediseñadas Alta 12
B1.3 Debe usarse tecnologías libres Alta 48
B1.3.1 Investigar sobre las tecnologías libres aplicadas a Web Alta 24
B1.3.2 Investigar sobre licencias de aplicaciones libres Alta 12
B1.3.3 Investigar sobre hardware y software necesario Alta 12
Las opciones del sistema (manejo de datos) se accederá
B1.4 Alta 36
a través de usuario y contraseña
B1.4.1 Investigar métodos de acceso al sistema Alta 24
B1.4.2 Investigar métodos de validación de datos de entrada Alta 12
B1.5 Consultar las preferencias del dueño del producto Alta 20
Vemos que ya fueron definidos los ID’s para las tareas, las tareas fueron
descompuestas según las apreciaciones del equipo, cada tarea tiene su prioridad y se
estableció la estimación en horas de cada una de las tareas.
El ID esta configurado de la siguiente manera:
B X1.X2.X3
B = Representa al término Backlog
X1 = representa al nº de período (Sprint)
X2 = representa al nº de una tarea
X3 = representa al nº de una subtarea (si existiera)
Daily Scrum Meeting y Scrum Master (Reuniones diarias y la importancia del Scrum
Master)
Después de la reunión anterior en la que se decide el Spring Backlog, nos vamos
todos a trabajar. A partir de ese día, todos los días, preferiblemente a primera hora, el Scrum
Team se reúne y cada uno contesta a tres preguntas:
• ¿Qué hiciste ayer?
• ¿Qué vas a hacer hoy?
• ¿Qué ayuda necesitas?
Uno de los programadores hace de moderador de la reunión y se le llama Scrum
Master. Este no es jefe de los demás, simplemente debe encargarse de que la reunión no
10

11. dure más de 15 minutos y de que las ayudas/problemas que plantean los programadores se
resuelvan a lo largo del día. El Product Owner también debería colaborar en lo que respecta
a quitar obstáculos, estar disponible para consultas, etc. La ayuda necesaria puede ser de
cualquier tipo: "no conozco este tema y necesito alguien que me ayude", "necesitaría tener
datos en la base de datos para hacer pruebas", "necesito tener mi PC conectado al
Servidor", etc. En fin, cualquier cosa que uno de los programadores considere que le facilita
el trabajo.
En esta reunión también se aprovecha para volver a estimar el tiempo de las tareas
en curso. Puede que una tarea, el primer día, se dijera que se iba a tardar ocho horas.
Resulta que hoy, después de haber trabajado el día de ayer en ella, sale un problema
inesperado y hoy decidimos que vamos a tardar 10 horas más en resolverla. Lo que se hace
es dejar asentado el cambio y continuar normalmente.
Después de varios días de reuniones se verá rápidamente de esta forma si vamos
según lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, además, puede
verlo, sobre todo si vamos registrando en algún gráfico el día a día, indicando cuantas horas
suponemos que nos quedan para terminar en el eje vertical y los días en el eje horizontal. El
gráfico de la figura, por ejemplo:
Gráfico de esfuerzo
Horas de trabajo pendientes
Esfuerzo Pendiente
25
20
15
10
5
0
br
br
br
br
br
br
br
br
r
r
r
r
r
r
ab
ab
ab
ab
ab
ab
-a
-a
-a
-a
-a
-a
-a
-a
1-
3-
6-
7-
8-
9-
10
13
14
15
16
17
20
21
Días del Sprint
Aunque en teoría Scrum dice que la lista de tareas a hacer (Sprint Backlog) no se
toca, hay mucha gente que decide añadir o quitar tareas en caso de ir adelantados o
retrasados. Lo importante es entregar a fin del periodo una versión con determinadas
funcionalidades implementadas y no adelantarse ni retrasarse demasiado en ese periodo.
11

12. Sprint Review y Sprint Retrospective
Ya ha pasado el periodo de plazo. Si estimamos bien, tenemos nuestra versión del
programa con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizás esta
versión tenga alguna funcionalidad menos o alguna de más.
Ahora se hace una reunión de aproximadamente un par de horas, llamada Sprint
Review, a la que acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otra
persona interesada en el producto. En ella el Scrum Master enseña la versión a los demás.
Los asistentes pueden dar opiniones, posibles mejoras, etc.
Inmediatamente después, se hace otra reunión, llamada Sprint Restropective, en la
que el Scrum Master, el Scrum Team y el Product Owner analizan qué cosas pueden
mejorarse a la hora de trabajar para el siguiente Sprint, si la comunicación ha sido buena o
debe mejorarse, si hay algún problema que deba subsanarse. En general, con un ambiente
distendido y espíritu constructivo, ver cómo se puede mejorar la forma de trabajo en el Sprint
Backlog del siguiente mes.
Y se vuelve a empezar; se realiza otro Sprint Planning Meeting para ver qué
funcionalidades va a tener la nueva versión del mes que viene, se confecciona y decide un
nuevo Sprint Backlog. Y se continua con el trabajo. Presentamos a continuación el segundo
Sprint.
SPRINT 2
Estimación
Id Descripción Prioridad
(HS)
B2.1 Diseño de la Base de Datos Alta 56
B2.2 Registrar el ingreso de un nuevo empleado Alta 8
Registrar el ingreso de un nuevo curso, asignándole su
B2.3 Alta 10
número de curso
B2.4 Registrar el ingreso de un nuevo puesto de trabajo Alta 8
B2.5 Registrar el ingreso de una nueva área de la Empresa Alta 8
B2.6 Permitir Buscar un empleado a través de su nombre Alta 12
B2.7 Registrar la realización de cursos Alta 8
12

13. Horas de trabajo pendientes Gráfico de esfuerzo
Esfuerzo Pendiente
15
10
5
0
ay
ay
ay
ay
ay
ay
ay
br
br
br
br
br
br
br
-a
-a
-a
-a
-a
-a
-a
m
m
m
m
m
-m
-m
22
23
24
27
28
29
30
4-
5-
6-
7-
8-
11
12
Días del Sprint
Presentamos ahora el tercer Sprint:
SPRINT 3
Estimación
Id Descripción Prioridad
(HS)
B3.1 Registrar para cada curso la fecha de realización Media 6
B3.2 Permitir la eliminación de un empleado Media 6
B3.3 Permitir la eliminación de un curso Media 6
B3.4 Permitir la eliminación de un puesto Media 6
B3.5 Permitir la eliminación de un área Media 6
B3.6 Permitir la modificación de datos de un empleado Media 8
B3.7 Permitir la modificación de datos de un curso Media 8
B3.8 Permitir la modificación de datos de un puesto Media 8
B3.9 Permitir la modificación de datos de un área Media 8
B3.10 Permitir la creación de nuevos usuarios del sistema Media 12
B3.11 Debe contener enlaces a otras páginas de interés Baja 4
B3.12 Debe contar con una sección de novedades de la
Baja 10
Empresa (cliente)
B3.13 Debe contar con una sección Quienes Somos Baja 4
B3.14 Debe contar con una sección Contacto Baja 4
Horas de trabajo pendientes
Gráfico de esfuerzo
Esfuerzo Pendiente
15
10
5
0
ay
ay
ay
ay
ay
ay
ay
ay
ay
ay
ay
ay
n
n
ju
ju
-m
-m
-m
-m
-m
-m
-m
-m
-m
-m
-m
-m
1-
2-
13
14
15
18
19
20
21
22
26
27
28
29
Días del Sprint
13

14. Cada iteración el equipo muestra al cliente los resultados que consigue. No está
meses trabajando sin poder exhibir su obra.
Estas iteraciones pueden ocurrir tantas veces hasta que el cliente queda conforme
con el producto desarrollado o bien cuando deba liberarse el producto por cuestiones de
mercado, lo cual no quita la posibilidad de mejoras.
Nota
Para la planificación de los Sprint’s y la gestión de la lista de requerimientos (Sprint
Backlog) se utilizó una planilla de Excel configurada adecuadamente según las
características de nuestro proyecto. Adjunto al trabajo se encuentran la planilla base (lista
para configurar) y la planilla empleada para el proyecto que presentamos como ejemplo.
Conclusiones
Teniendo en cuenta las características del mercado argentino de software y su
demanda las empresas dedicadas al desarrollo de sistemas deben abocarse a adoptar
técnicas que le permitan actuar con rapidez y contundencia.
Tomando por ejemplo el caso de las Pymes, estas compiten duramente por obtener
las mejores franjas del mercado o en todo caso las franjas que más le retribuyan ganancias.
Para ser competitivas, estas empresas requieren de una sistematización de sus procesos y
actividades para responder rápidamente a sus clientes. Esto genera que dichas empresas
encarguen la construcción de los sistemas para administrar su negocio y muchas veces de
un momento a otro y aquí es donde la velocidad de respuesta de las empresas de desarrollo
de software cobra importancia.
Para poder dar una respuesta eficaz y eficiente a la demanda y teniendo en cuenta
las fuertes disputas en el ámbito regional, las empresas de software deben contar con una
administración ágil y segura de todos los procesos de la empresa.
La metodología Scrum reúne todas las características necesarias para lograr dicho
objetivo. Es cuestión de rever los procesos y técnicas usadas actualmente y considerar la
posibilidad de implementar esta metodología como gran arma y escudo contra la
competencia.
14

15. Escalabilidad
Respecto de la escalabilidad del sistema que comentamos en el presente trabajo, la
misma está en función de las necesidades del cliente al que se destinará el producto
software final. Anteriormente mencionamos que al finalizar cada iteración de la metodología
el equipo presenta al cliente una versión del producto con las funcionalidades propuestas.
Esto lleva a la situación en que el cliente una vez con el producto en mano puede decidir
más adelante agregarle funcionalidades nuevas. Gracias a la forma en que se trabaja en la
metodología Scrum, esto será posible sin ningún inconveniente. El producto puede crecer en
funcionalidades y verse modificado permanentemente.
Sitios Web Recomendados
[1] Control Chaos – Living on the Edge
http://www.controlchaos.com/download/Living%20on%20the%20Edge.pdf
[2] Control Chaos – Rup in a Dialogue with Scrum
http://www.controlchaos.com/module/RationalEdge0205.pdf
[3] http://www.dosideas.com/wiki/Backlog_Del_Producto
[4] http://www.chuidiang.com/ood/metodologia/scrum.php
[5] http://www.proyectosagiles.org/jardin-ejemplo-scrum
[6] http://www.dosideas.com/wiki/Sesion_De_Ejemplo_De_Scrum
[7] http://www.geronet.com.ar/?p=61
15

16. Indice
Pagina
La metodología SCRUM – Proyecto Sistema GRH-TUC 2
Introducción 2
Marco teórico 2
Roles que se desempeñan dentro de la Metodología Scrum 3
Modelo de la metodología Scrum 5
Aplicación de la Metodología SCRUM en un proyecto de desarrollo de software
6
real
Sistema GRH-TUC 6
Roles dentro del proyecto 6
Presentación del Sistema 6
El Cliente 6
Metas 6
Lista de funciones a implementar (Product Backlog) 7
Sprint Planning Meeting y Spring Backlog
9
(Reunión de planeación para el período y la Lista de Tareas para el período)
Daily Scrum Meeting y Scrum Master (Reuniones diarias y la importancia del
10
Scrum Master)
Sprint Review y Sprint Retrospective 12
Conclusiones 14
Escalabilidad 15
Sitios Web Recomendados 15
16