Scrum en sistema grh tuc

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.

3

Roles que se desempeñan dentro de la Metodología Sc rum

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

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

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

6

Aplicación de la Metodología SCRUM en un proyecto d e 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.

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

8

Con esta información el product owner comienza a darle forma al listado.

Id Descripción Prioridad Estimación (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

través de usuario y contraseña Alta 36

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

número de curso Alta 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.

9

Sprint Planning Meeting y Spring Backlog (Reunión d e 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:

10


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

B1.4 Las opciones del sistema (manejo de datos) se accederá a través de usuario y contraseña Alta 36

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 diari as 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

11

Gráfico de esfuerzo

05

10152025

1-ab

r3-

abr

6-ab

r7-

abr

8-ab

r9-

abr

10-a

br

13-a

br

14-a

br

15-a

br

16-a

br

17-a

br

20-a

br

21-a

br

Días del Sprint

Hor

as d

e tra

bajo

pen

dien

tes Esfuerzo Pendiente

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:

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.

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

Id Descripción Prioridad Est imación (HS)

B2.1 Diseño de la Base de Datos Alta 56 B2.2 Registrar el ingreso de un nuevo empleado Alta 8

B2.3 Registrar el ingreso de un nuevo curso, asignándole su número de curso Alta 10

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

13


0

5

10

15

22-a

br

23-a

br

24-a

br

27-a

br

28-a

br

29-a

br

30-a

br

4-may

5-may

6-may

7-may

8-may

11-m

ay

12-m

ay

Días del Sprint

Hor

as d

e tra

bajo

pen

dien



0

5

10

15

13-m

ay

14-m

ay

15-m

ay

18-m

ay

19-m

ay

20-m

ay

21-m

ay

22-m

ay

26-m

ay

27-m

ay

28-m

ay

29-m

ay1-jun

2-jun

Días del Sprint

Hor

as d

e tra

bajo

pen

dien


Presentamos ahora el tercer Sprint:

SPRINT 3


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

Empresa (cliente) Baja 10

B3.13 Debe contar con una sección Quienes Somos Baja 4 B3.14 Debe contar con una sección Contacto Baja 4

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.

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

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 real 6

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 (Reunión de planeación para el período y la Lista de Tareas para el período) 9

Daily Scrum Meeting y Scrum Master (Reuniones diarias y la importancia del Scrum Master) 10

Sprint Review y Sprint Retrospective 12 Conclusiones 14 Escalabilidad 15 Sitios Web Recomendados 15

Scrum en sistema grh tuc

Documents

Transcript of Scrum en sistema grh tuc