METODOLOGA DE DISEO DE SISTEMAS

METODOLOGIA SCRUM Proyecto Sistema GRH-TUC

Profesor:

Ing. JUAREZ, Gustavo

Alumnos:

MUCCELA, Jos Daniel

- Leg.: 20196

UNIVERSIDAD TECNOLGICA NACIONAL FACULTAD REGIONAL TUCUMN

METODOLOGIA SCRUM

La metodologa SCRUM Proyecto Sistema GRH-TUC

Introduccin

Que mejor introduccin que aclarar un poco los conceptos? Primeramente mencionaremos sobre lo que es una metodologa. En el ambiente de desarrollo de sistemas, una metodologa es el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. Ahora estamos en condiciones de hablar de la metodologa Scrum. Marco terico Scrum es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo. Tiene las siguientes caractersticas: o o o Permite el manejo gil de proyectos. Define una serie de roles, reuniones y herramientas (artefactos). Muy utilizada en proyectos de software donde el desarrollo es un caos, los cambios son una constante y existe poca previsibilidad. o o o Delega completamente en el equipo la responsabilidad. Se basa en la auto-organizacin. Abarca prcticas relacionadas con la gestin de proyectos.

Cabe mencionar lo que son las metodologas giles. Nos referimos a: Responder a los cambios que surjan durante las etapas del ciclo de vida del software

ms que seguir estrictamente un plan. Seguir estrictamente un plan propuesto muchas veces ocasiona que el esfuerzo para corregir un sistema en desarrollo sea mucho ms complejo y sea una ardua tarea. Como vemos la metodologa gil propone responder a los cambio cuando surgen.

Es buscar un justo medio entre ningn proceso y demasiado proceso,

proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.

Roles que se desempean dentro de la Metodologa Scrum

En esta metodologa se presentan una serie de papeles o roles que desempean las personas para su ejecucin. Estos roles estn bien definidos y permanecen a lo largo de un proyecto y hasta su finalizacin. 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 o o Financiacin del proyecto. Retorno de la inversin del proyecto. Lanzamiento del proyecto.

Scrum Master: es la persona que asegura el seguimiento de la metodologa 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 caractersticas: o o o Formacin y entrenamiento del proceso. Incorporacin de Scrum en la cultura de la empresa. Garanta 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 iteracin en un incremento de la funcionalidad del software. Sus caractersticas son: o o o Auto-gestionado. Auto-organizado. Multi-funcional.

Scrum, ms que una metodologa de desarrollo software, es una forma de autogestin de los equipos de programadores. Un grupo de programadores deciden cmo hacer sus tareas y cunto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la misma direccin, con un objetivo claro. Scrum permite adems seguir de forma clara el avance de las tareas a realizar, de forma que los "jefes" puedan ver da a da cmo progresa el trabajo. Sin embargo, Scrum no es una metodologa de desarrollo, puesto que no indica qu se debe hacer para hacer el cdigo. Debera, por tanto, complementarse con alguna otra
3

metodologa de desarrollo. Se lleva bien con las metodologas giles y en concreto, con la programacin extrema. Esta metodologa nos da la posibilidad de llevar a cabo un proyecto de software sacando el mayor provecho de los participantes, en trminos de productividad. Para que esto sea posible, el equipo completo (el Scrum) debe estar bien constituido y todos los actores que intervendrn en la consecucin del proyecto. En el apartado anterior se mencion sobre los roles que existen dentro de la metodologa 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 metodologa carece de sentido y difcilmente se puedan lograr resultados satisfactorios. Delegar completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo ms 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 constitucin de los equipos de trabajo los cuales estn formados de hasta 7 personas que revisan los requisitos, la tecnologa disponible y evalan los conocimientos para que colectivamente puedan determinar como incrementar la funcionalidad. Estos equipos llevan a cabo reuniones diarias que no debera consumir ms de 15 minutos. El Scrum Master ejecuta la reunin y se encarga del xito global del proyecto, supervisa las respuestas por parte de los miembros del equipo y elimina los obstculos identificados durante estas reuniones, permitiendo que el equipo avance hacia sus objetivos. Muchas veces, los miembros de los equipos pueden desempear mltiples funciones, la energa y la eficiencia de cada uno tiene que ver con la combinacin correcta. Como buena metodologa, Scrum posee tambin iteraciones en sus procesos de desarrollo. Estas iteraciones se podrn llevar a cabo luego de que transcurra un Sprint. Un Sprint es un periodo de 30 das de duracin y durante este periodo se establecen los objetivos y tareas que debern llevar a cabo los equipos de trabajo. Al finalizar este perodo se produce una reunin donde se ponen de manifiesto los resultados obtenidos, se presentan los ejecutables obtenidos; tambin se plantean las desviaciones encontradas y cualquier cuestin que requiera de atencin. Como dijimos, el equipo est ligado a travs de la organizacin por un scrum diario y una reunin mensual de planificacin, lo que proporciona una visibilidad vertical a travs de toda la organizacin. Esta situacin provoca que los problemas de organizacin y los retos impuestos salten a la vista. Como todos los miembros del equipo tienen vinculacin directa con el proyecto, la comunicacin entre las partes es breve, rpida y eficiente. El equipo es

auto-organizado y se centra en los objetivos del sprint (30 das planificados). Toda esta situacin genera como resultado extraer lo mejor de cada individuo del equipo. Por ultimo diremos que una correcta aplicacin de esta metodologa requiere un equipo muy motivado, un buen liderazgo y una buena y estrecha relacin con el cliente. Despus de todo, el esfuerzo en conseguir y mantener un buen lder 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 an en ejecucin. Modelo de la metodologa Scrum

Aplicacin de la Metodologa SCRUM en un proyecto de desarrollo de software real

Sistema GRH-TUC Vamos a utilizar el sistema GRH-TUC para aplicar la metodologa que estamos desarrollando. Las especificaciones sobre el sistema mencionado se encuentran anexas a esta documentacin.

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 da de trabajo). Team Member: compuesto por: o o o Alejandra Emmanuel Pablo

Presentacin del Sistema El proyecto tiene por objeto crear un sistema para la gestin 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 gestin de empleados. Facilitar la registracin de los cursos. Facilitar la registracin de empleados. Facilitar la registracin de puestos. Facilitar la registracin de reas de la empresa Control de empleados, cursos, puestos y reas de la Empresa. Permitir el seguimiento de la capacitacin de Empleados.

Lista de funciones a implementar (Product Backlog) El backlog es un inventario o una lista priorizada de requerimientos funcionales, mejoras, tecnologa y correccin de errores que deben incorporarse al producto a travs de las sucesivas iteraciones. Siempre esta en continuo crecimiento y evolucin. 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 reunin surge la lista con ciertas caractersticas que la identifican.

Enunciamos entonces la lista preparada por el Product Owner: Requerimientos Debe basarse en Web Debe tener un diseo atractivo Debe usarse tecnologas libres Las opciones del sistema (manejo de datos) se acceder a travs de usuario y contrasea Consultar las preferencias del dueo del producto Diseo de la Base de Datos Registrar el ingreso de un nuevo empleado Registrar el ingreso de un nuevo curso, asignndole su nmero 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 travs de su nombre Registrar la realizacin de cursos Registrar para cada curso la fecha de realizacin Permitir la eliminacin de un empleado Permitir la eliminacin de un curso Permitir la eliminacin de un puesto Permitir la eliminacin de un rea Permitir la modificacin de datos de un empleado Permitir la modificacin de datos de un curso Permitir la modificacin de datos de un puesto Permitir la modificacin de datos de un rea Permitir la creacin 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 informacin para cada lnea: Identificador nico de la funcionalidad o trabajo. Descripcin de la funcionalidad. Campo o sistema de priorizacin. Estimacin
7

Con esta informacin el product owner comienza a darle forma al listado. Id Descripcin Debe basarse en Web Investigar sobre tecnologas Web Investigar sobre hardware necesario Debe tener un diseo atractivo Investigar sobre buenos diseos de aplicaciones Web Investigar sobre plantillas prediseadas Debe usarse tecnologas libres Investigar sobre las tecnologas libres aplicadas a Web Investigar sobre licencias de aplicaciones libres Investigar sobre hardware y software necesario Las opciones del sistema (manejo de datos) se acceder a travs de usuario y contrasea Investigar mtodos de acceso al sistema Investigar mtodos de validacin de datos de entrada Consultar las preferencias del dueo del producto Diseo de la Base de Datos Registrar el ingreso de un nuevo empleado Registrar el ingreso de un nuevo curso, asignndole su nmero 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 travs de su nombre Registrar la realizacin de cursos Registrar para cada curso la fecha de realizacin Permitir la eliminacin de un empleado Permitir la eliminacin de un curso Permitir la eliminacin de un puesto Permitir la eliminacin de un rea Permitir la modificacin de datos de un empleado Permitir la modificacin de datos de un curso Permitir la modificacin de datos de un puesto Permitir la modificacin de datos de un rea Permitir la creacin de nuevos usuarios del sistema Prioridad Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Media Media Media Media Media Media Media Media Media Media Estimacin (HS) 24 12 12 36 24 12 48 24 12 12 36 24 12 20 56 8 10 8 8 12 8 6 6 6 6 6 8 8 8 8 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 reunin (la de planeacin) se decidir qu requisitos irn para el primer perodo, 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 tambin por parte del product owner con la ayuda del equipo. Luego la estimacin 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.

Sprint Planning Meeting y Spring Backlog (Reunin de planeacin para el perodo y la Lista de Tareas para el perodo) El primer da que empecemos a trabajar en el proyecto, se hace una reunin, en la que estarn el Product Owner y los programadores (Scrum Team) que van a participar en el proyecto. En esta reunin se elije un plazo de tiempo que Scrum aconseja que sea un mes. En nuestro caso lo definimos para 15 (quince) das. De todas formas, en funcin del proyecto, necesidades y dems, puede elegirse otro plazo: una semana, dos semanas u otro tiempo. Nunca debera 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 tardarn en hacerla y dicen "s". Si dicen que no, habr que descomponerla en tareas ms 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 das. El jefe puede decidir el orden, intercambiar tareas, modificarlas o partirlas, pero los programadores tienen la ltima palabra de cunto tiempo necesitan (estimacin) para cada tarea. El tiempo necesario para todas las tareas seleccionadas no puede superar los 15 das. 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 das vamos a entregar al Product Owner una versin del programa que tenga todas las tareas del Srpint Backlog funcionando. Finalmente se decide que para el primer perodo (Sprint1) la lista de tareas es la siguiente:

Id
B1.1 B1.1.1 B1.1.2 B1.2 B1.2.1 B1.2.2 B1.3 B1.3.1 B1.3.2 B1.3.3

Descripcin

Prioridad Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta Alta

Debe basarse en Web Investigar sobre tecnologas Web Investigar sobre hardware necesario Debe tener un diseo atractivo Investigar sobre buenos diseos de aplicaciones Web Investigar sobre plantillas prediseadas Debe usarse tecnologas libres Investigar sobre las tecnologas libres aplicadas a Web Investigar sobre licencias de aplicaciones libres Investigar sobre hardware y software necesario Las opciones del sistema (manejo de datos) se acceder B1.4 a travs de usuario y contrasea B1.4.1 Investigar mtodos de acceso al sistema B1.4.2 Investigar mtodos de validacin de datos de entrada B1.5 Consultar las preferencias del dueo del producto

Estimacin (HS) 24 12 12 36 24 12 48 24 12 12 36 24 12 20

Vemos que ya fueron definidos los IDs para las tareas, las tareas fueron descompuestas segn las apreciaciones del equipo, cada tarea tiene su prioridad y se estableci la estimacin en horas de cada una de las tareas. El ID esta configurado de la siguiente manera:

B X1.X2.X3 B = Representa al trmino Backlog X1 = representa al n de perodo (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) Despus de la reunin anterior en la que se decide el Spring Backlog, nos vamos todos a trabajar. A partir de ese da, todos los das, preferiblemente a primera hora, el Scrum Team se rene 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 reunin y se le llama Scrum

Master. Este no es jefe de los dems, simplemente debe encargarse de que la reunin no

10

dure ms de 15 minutos y de que las ayudas/problemas que plantean los programadores se resuelvan a lo largo del da. El Product Owner tambin debera colaborar en lo que respecta a quitar obstculos, estar disponible para consultas, etc. La ayuda necesaria puede ser de cualquier tipo: "no conozco este tema y necesito alguien que me ayude", "necesitara 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 reunin tambin se aprovecha para volver a estimar el tiempo de las tareas en curso. Puede que una tarea, el primer da, se dijera que se iba a tardar ocho horas. Resulta que hoy, despus de haber trabajado el da de ayer en ella, sale un problema inesperado y hoy decidimos que vamos a tardar 10 horas ms en resolverla. Lo que se hace es dejar asentado el cambio y continuar normalmente. Despus de varios das de reuniones se ver rpidamente de esta forma si vamos segn lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, adems, puede verlo, sobre todo si vamos registrando en algn grfico el da a da, indicando cuantas horas suponemos que nos quedan para terminar en el eje vertical y los das en el eje horizontal. El grfico de la figura, por ejemplo:
Horas de trabajo pendientes Grfico de esfuerzo

Esfuerzo Pendiente

25 20 15 10 5 0
10 -a br 13 -a br 14 -a br 15 -a br 20 -a br 16 -a br 17 -a br 21 -a br 1ab r 6ab r 3ab r 7ab r 8ab r 9ab r

Das del Sprint

Aunque en teora Scrum dice que la lista de tareas a hacer (Sprint Backlog) no se toca, hay mucha gente que decide aadir o quitar tareas en caso de ir adelantados o retrasados. Lo importante es entregar a fin del periodo una versin con determinadas funcionalidades implementadas y no adelantarse ni retrasarse demasiado en ese periodo.

11

Sprint Review y Sprint Retrospective Ya ha pasado el periodo de plazo. Si estimamos bien, tenemos nuestra versin del programa con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizs esta versin tenga alguna funcionalidad menos o alguna de ms. Ahora se hace una reunin 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 ensea la versin a los dems. Los asistentes pueden dar opiniones, posibles mejoras, etc. Inmediatamente despus, se hace otra reunin, 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 comunicacin ha sido buena o debe mejorarse, si hay algn problema que deba subsanarse. En general, con un ambiente distendido y espritu constructivo, ver cmo 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 versin del mes que viene, se confecciona y decide un nuevo Sprint Backlog. Y se continua con el trabajo. Presentamos a continuacin el segundo Sprint.

SPRINT 2 Id
B2.1 B2.2 B2.3 B2.4 B2.5 B2.6 B2.7

Descripcin Diseo de la Base de Datos Registrar el ingreso de un nuevo empleado Registrar el ingreso de un nuevo curso, asignndole su nmero 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 travs de su nombre Registrar la realizacin de cursos

Prioridad Alta Alta Alta Alta Alta Alta Alta

Estimacin (HS) 56 8 10 8 8 12 8

12

Horas de trabajo pendientes

Grfico de esfuerzo

Esfuerzo Pendiente

15 10 5 0
4m ay 5m ay 8m ay 11 -m ay 7m ay 6m ay 12 -m ay 23 -a br 24 -a br 22 -a br 27 -a br 28 -a br 29 -a br 30 -a br

Das del Sprint

Presentamos ahora el tercer Sprint: SPRINT 3 Id

B3.1 B3.2 B3.3 B3.4 B3.5 B3.6 B3.7 B3.8 B3.9 B3.10 B3.11 B3.12

Descripcin

Prioridad Media Media Media Media Media Media Media Media Media Media Baja Baja Baja Baja

Registrar para cada curso la fecha de realizacin Permitir la eliminacin de un empleado Permitir la eliminacin de un curso Permitir la eliminacin de un puesto Permitir la eliminacin de un rea Permitir la modificacin de datos de un empleado Permitir la modificacin de datos de un curso Permitir la modificacin de datos de un puesto Permitir la modificacin de datos de un rea Permitir la creacin de nuevos usuarios del sistema Debe contener enlaces a otras pginas de inters Debe contar con una seccin de novedades de la Empresa (cliente) B3.13 Debe contar con una seccin Quienes Somos B3.14 Debe contar con una seccin Contacto

Estimacin (HS) 6 6 6 6 6 8 8 8 8 12 4 10 4 4

Horas de trabajo pendientes

Grfico de esfuerzo

Esfuerzo Pendiente

15 10 5 0
19 -m ay 13 -m ay 14 -m ay 15 -m ay 18 -m ay 21 -m ay 22 -m ay 20 -m ay 28 -m ay 29 -m ay 26 -m ay 27 -m ay 1ju n 2ju n

Das del Sprint

13

Cada iteracin 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 planificacin de los Sprints y la gestin de la lista de requerimientos (Sprint Backlog) se utiliz una planilla de Excel configurada adecuadamente segn las caractersticas 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 caractersticas del mercado argentino de software y su demanda las empresas dedicadas al desarrollo de sistemas deben abocarse a adoptar tcnicas 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 ms le retribuyan ganancias. Para ser competitivas, estas empresas requieren de una sistematizacin de sus procesos y actividades para responder rpidamente a sus clientes. Esto genera que dichas empresas encarguen la construccin 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 administracin gil y segura de todos los procesos de la empresa. La metodologa Scrum rene todas las caractersticas necesarias para lograr dicho objetivo. Es cuestin de rever los procesos y tcnicas usadas actualmente y considerar la posibilidad de implementar esta metodologa como gran arma y escudo contra la competencia.

14

Escalabilidad

Respecto de la escalabilidad del sistema que comentamos en el presente trabajo, la misma est en funcin de las necesidades del cliente al que se destinar el producto software final. Anteriormente mencionamos que al finalizar cada iteracin de la metodologa el equipo presenta al cliente una versin del producto con las funcionalidades propuestas. Esto lleva a la situacin en que el cliente una vez con el producto en mano puede decidir ms adelante agregarle funcionalidades nuevas. Gracias a la forma en que se trabaja en la metodologa Scrum, esto ser posible sin ningn 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

Indice

Pagina La metodologa SCRUM Proyecto Sistema GRH-TUC Introduccin Marco terico Roles que se desempean dentro de la Metodologa Scrum Modelo de la metodologa Scrum Aplicacin de la Metodologa SCRUM en un proyecto de desarrollo de software real Sistema GRH-TUC Roles dentro del proyecto Presentacin del Sistema El Cliente Metas Lista de funciones a implementar (Product Backlog) Sprint Planning Meeting y Spring Backlog (Reunin de planeacin para el perodo y la Lista de Tareas para el perodo) Daily Scrum Meeting y Scrum Master (Reuniones diarias y la importancia del Scrum Master) Sprint Review y Sprint Retrospective Conclusiones Escalabilidad Sitios Web Recomendados 2 2 2 3 5 6 6 6 6 6 6 7 9

10 12 14 15 15

16