• Compartir
  • Enviar por correo
  • Insertar
  • Me gusta
  • Guardar
  • Contenido privado
Scrum en sistema grh tuc
 

Scrum en sistema grh tuc

on

  • 1,389 reproducciones

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

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

Estadísticas

reproducciones

reproducciones totales
1,389
reproducciones en SlideShare
1,388
reproducciones incrustadas
1

Actions

Me gusta
1
Descargas
93
Comentarios
3

1 insertado 1

http://www.linkedin.com 1

Accesibilidad

Categorias

Detalles de carga

Uploaded via as Adobe PDF

Derechos de uso

© Todos los derechos reservados

Report content

Marcada como inapropiada Marcar como inapropiada
Marcar como inapropiada

Seleccione la razón para marcar esta presentación como inapropiada.

Cancelar

13 de 3 anterior siguiente Comentar

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Tu mensaje aparecerá aquí
    Processing...
Publicar comentario
Edite su comentario

    Scrum en sistema grh tuc Scrum en sistema grh tuc Document Transcript

    • METODOLOGÍA DE DISEÑO DE SISTEMAS METODOLOGIA SCRUM “Proyecto Sistema GRH-TUC”Profesor: Ing. JUAREZ, GustavoAlumnos: MUCCELA, José Daniel - Leg.: 20196 UNIVERSIDAD TECNOLÓGICA NACIONAL FACULTAD REGIONAL TUCUMÁN
    • METODOLOGIA SCRUM La metodología SCRUM – Proyecto Sistema GRH-TUCIntroducció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 aplicarciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o unsistema, 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 eselevar 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 softwaremás que seguir estrictamente un plan. Seguir estrictamente un plan propuesto muchasveces ocasiona que el esfuerzo para corregir un sistema en desarrollo sea mucho máscomplejo y sea una ardua tarea. Como vemos la metodología ágil propone responder a loscambio 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
    • 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 laspersonas para su ejecución. Estos roles están bien definidos y permanecen a lo largo de unproyecto 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 guiandolas reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Suresponsabilidad es entre otras, la de hacer de paraguas ante las presiones externas. Siendoresponsable 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 ofuncionalidades elegidas por el Product Owner. Son Responsables de transformar elBacklog de la iteración en un incremento de la funcionalidad del software. Suscaracterí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 hacersus tareas y cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en lamisma dirección, con un objetivo claro. Scrum permite además seguir de forma clara el avance de las tareas a realizar, deforma 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
    • metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con laprogramación extrema. Esta metodología nos da la posibilidad de llevar a cabo un proyecto de softwaresacando el mayor provecho de los participantes, en términos de productividad. Para que esto sea posible, el equipo completo (el Scrum) debe estar bien constituidoy 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 lametodología Scrum. Cuando no fuera posible o cueste involucrar al cliente en el desarrollodel 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 resultadossatisfactorios. Delegar completamente en el equipo la responsabilidad de decidir la mejor manerade trabajar para ser lo más productivos posibles y darle gran protagonismo a las reunionesque realicen a lo largo del proyecto es de vital importancia a la hora de los resultados. Estoes así, debido en primera medida a la constitución de los equipos de trabajo los cuales estánformados de hasta 7 personas que revisan los requisitos, la tecnología disponible y evalúanlos conocimientos para que colectivamente puedan determinar como incrementar lafuncionalidad. Estos equipos llevan a cabo reuniones diarias que no debería consumir másde 15 minutos. El Scrum Master ejecuta la reunión y se encarga del éxito global delproyecto, supervisa las respuestas por parte de los miembros del equipo y elimina losobstáculos identificados durante estas reuniones, permitiendo que el equipo avance haciasus objetivos. Muchas veces, los miembros de los equipos pueden desempeñar múltiplesfunciones, 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 dedesarrollo. Estas iteraciones se podrán llevar a cabo luego de que transcurra un Sprint. UnSprint es un periodo de 30 días de duración y durante este periodo se establecen losobjetivos y tareas que deberán llevar a cabo los equipos de trabajo. Al finalizar este períodose produce una reunión donde se ponen de manifiesto los resultados obtenidos, sepresentan los ejecutables obtenidos; también se plantean las desviaciones encontradas ycualquier cuestión que requiera de atención. Como dijimos, el equipo está ligado a través de la organización por un scrum diario yuna reunión mensual de planificación, lo que proporciona una visibilidad vertical a través detoda la organización. Esta situación provoca que los problemas de organización y los retosimpuestos salten a la vista. Como todos los miembros del equipo tienen vinculación directacon el proyecto, la comunicación entre las partes es breve, rápida y eficiente. El equipo es 4
    • auto-organizado y se centra en los objetivos del sprint (30 días planificados). Toda estasituació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 unequipo 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 motivadose compensa al momento de obtener los resultados de productividad, beneficios quellegaron a ser en muchos casos un 600 % de nivel de eficacia incluso en proyectos aún enejecución.Modelo de la metodología Scrum 5
    • Aplicación de la Metodología SCRUM en un proyecto de desarrollo de software realSistema GRH-TUC Vamos a utilizar el sistema GRH-TUC para aplicar la metodología que estamosdesarrollando. Las especificaciones sobre el sistema mencionado se encuentran anexas aesta documentación.Roles dentro del proyecto• Product Owner: el encargado es Daniel• Scrum Master: Alejandra (es un miembro del equipo – responsable de moderarreuniones y de que las ayudas/problemas que plantean los programadores se resuelvan a lolargo del día de trabajo).• Team Member: compuesto por: o Alejandra o Emmanuel o PabloPresentación del Sistema El proyecto tiene por objeto crear un sistema para la gestión de Recursos Humanosde una Empresa.El Cliente El cliente en este caso es cualquier Empresa que requiere el control y seguimientode 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
    • 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 delas sucesivas iteraciones. Siempre esta en continuo crecimiento y evolución. Representatodo 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 elbacklog. Primeramente vamos a definir los requerimientos crudos. Veremos que luego de laprimera 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 dereferencia para el equipo. Es recomendable el formato de lista que incluya al menos lasiguiente 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
    • 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 porel equipo. El ID del requerimiento (que luego se convertirá en tarea o tareas) surgirá en basea 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 estocolocaremos el ID del mismo. La prioridad surge de las apreciaciones de los requisitos; sedeterminará también por parte del product owner con la ayuda del equipo. Luego laestimació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 vitalimportancia la experiencia de los integrantes de equipo. 8
    • Sprint Planning Meeting y Spring Backlog (Reunión de planeación para el período y laLista de Tareas para el período) El primer día que empecemos a trabajar en el proyecto, se hace una reunión, en laque estarán el Product Owner y los programadores (Scrum Team) que van a participar en elproyecto. En esta reunión se elije un plazo de tiempo que Scrum aconseja que sea un mes. Ennuestro 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 mirandolas tareas empezando por la primera. Se realizan una serie de preguntas al Scrum Team: ¿la primera tarea puede estarhecha dentro de un mes? El Scrum Team la examina, descompone en subtareas si hace falta, estiman eltiempo que tardarán en hacerla y dicen "sí". Si dicen que no, habrá que descomponerla entareas 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 lasegunda en un mes? Vuelven a estimar y dicen "sí". Se repite el proceso con las siguientes tareas hasta que el Scrum Team comience adudar si se va a terminar con todo lo previsto. Si el Product Owner quiere que esté algunatarea que no va a estar, puede cambiarla por otra que sí esté, o "reducir" el alcance de unade las que ha entrado para que entre otra. En fin, este es el momento de "negociar" entre losprogramadores 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 palabrade cuánto tiempo necesitan (estimación) para cada tarea. El tiempo necesario para todas lastareas 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 aentregar al Product Owner una versión del programa que tenga todas las tareas del SrpintBacklog funcionando. Finalmente se decide que para el primer período (Sprint1) la lista de tareas es lasiguiente: 9
    • Estimación Id Descripción Prioridad (HS)B1.1 Debe basarse en Web Alta 24B1.1.1 Investigar sobre tecnologías Web Alta 12B1.1.2 Investigar sobre hardware necesario Alta 12B1.2 Debe tener un diseño atractivo Alta 36B1.2.1 Investigar sobre buenos diseños de aplicaciones Web Alta 24B1.2.2 Investigar sobre plantillas prediseñadas Alta 12B1.3 Debe usarse tecnologías libres Alta 48B1.3.1 Investigar sobre las tecnologías libres aplicadas a Web Alta 24B1.3.2 Investigar sobre licencias de aplicaciones libres Alta 12B1.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ñaB1.4.1 Investigar métodos de acceso al sistema Alta 24B1.4.2 Investigar métodos de validación de datos de entrada Alta 12B1.5 Consultar las preferencias del dueño del producto Alta 20 Vemos que ya fueron definidos los ID’s para las tareas, las tareas fuerondescompuestas según las apreciaciones del equipo, cada tarea tiene su prioridad y seestableció 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 ScrumMaster) Después de la reunión anterior en la que se decide el Spring Backlog, nos vamostodos a trabajar. A partir de ese día, todos los días, preferiblemente a primera hora, el ScrumTeam 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 ScrumMaster. Este no es jefe de los demás, simplemente debe encargarse de que la reunión no 10
    • dure más de 15 minutos y de que las ayudas/problemas que plantean los programadores seresuelvan a lo largo del día. El Product Owner también debería colaborar en lo que respectaa quitar obstáculos, estar disponible para consultas, etc. La ayuda necesaria puede ser decualquier tipo: "no conozco este tema y necesito alguien que me ayude", "necesitaría tenerdatos en la base de datos para hacer pruebas", "necesito tener mi PC conectado alServidor", etc. En fin, cualquier cosa que uno de los programadores considere que le facilitael trabajo. En esta reunión también se aprovecha para volver a estimar el tiempo de las tareasen 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 problemainesperado y hoy decidimos que vamos a tardar 10 horas más en resolverla. Lo que se hacees dejar asentado el cambio y continuar normalmente. Después de varios días de reuniones se verá rápidamente de esta forma si vamossegún lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, además, puedeverlo, sobre todo si vamos registrando en algún gráfico el día a día, indicando cuantas horassuponemos que nos quedan para terminar en el eje vertical y los días en el eje horizontal. Elgrá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 setoca, hay mucha gente que decide añadir o quitar tareas en caso de ir adelantados oretrasados. Lo importante es entregar a fin del periodo una versión con determinadasfuncionalidades 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 versión delprograma con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizás estaversión tenga alguna funcionalidad menos o alguna de más. Ahora se hace una reunión de aproximadamente un par de horas, llamada SprintReview, a la que acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otrapersona 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 laque el Scrum Master, el Scrum Team y el Product Owner analizan qué cosas puedenmejorarse a la hora de trabajar para el siguiente Sprint, si la comunicación ha sido buena odebe mejorarse, si hay algún problema que deba subsanarse. En general, con un ambientedistendido y espíritu constructivo, ver cómo se puede mejorar la forma de trabajo en el SprintBacklog 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 unnuevo Sprint Backlog. Y se continua con el trabajo. Presentamos a continuación el segundoSprint.SPRINT 2 Estimación Id Descripción Prioridad (HS)B2.1 Diseño de la Base de Datos Alta 56B2.2 Registrar el ingreso de un nuevo empleado Alta 8 Registrar el ingreso de un nuevo curso, asignándole suB2.3 Alta 10 número de cursoB2.4 Registrar el ingreso de un nuevo puesto de trabajo Alta 8B2.5 Registrar el ingreso de una nueva área de la Empresa Alta 8B2.6 Permitir Buscar un empleado a través de su nombre Alta 12B2.7 Registrar la realización de cursos Alta 8 12
    • 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 6B3.2 Permitir la eliminación de un empleado Media 6B3.3 Permitir la eliminación de un curso Media 6B3.4 Permitir la eliminación de un puesto Media 6B3.5 Permitir la eliminación de un área Media 6B3.6 Permitir la modificación de datos de un empleado Media 8B3.7 Permitir la modificación de datos de un curso Media 8B3.8 Permitir la modificación de datos de un puesto Media 8B3.9 Permitir la modificación de datos de un área Media 8B3.10 Permitir la creación de nuevos usuarios del sistema Media 12B3.11 Debe contener enlaces a otras páginas de interés Baja 4B3.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 4B3.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
    • 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 conformecon el producto desarrollado o bien cuando deba liberarse el producto por cuestiones demercado, 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 (SprintBacklog) se utilizó una planilla de Excel configurada adecuadamente según lascaracterísticas de nuestro proyecto. Adjunto al trabajo se encuentran la planilla base (listapara 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 sudemanda las empresas dedicadas al desarrollo de sistemas deben abocarse a adoptartécnicas que le permitan actuar con rapidez y contundencia. Tomando por ejemplo el caso de las Pymes, estas compiten duramente por obtenerlas 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 yactividades para responder rápidamente a sus clientes. Esto genera que dichas empresasencarguen la construcción de los sistemas para administrar su negocio y muchas veces deun momento a otro y aquí es donde la velocidad de respuesta de las empresas de desarrollode software cobra importancia. Para poder dar una respuesta eficaz y eficiente a la demanda y teniendo en cuentalas fuertes disputas en el ámbito regional, las empresas de software deben contar con unaadministración ágil y segura de todos los procesos de la empresa. La metodología Scrum reúne todas las características necesarias para lograr dichoobjetivo. Es cuestión de rever los procesos y técnicas usadas actualmente y considerar laposibilidad de implementar esta metodología como gran arma y escudo contra lacompetencia. 14
    • Escalabilidad Respecto de la escalabilidad del sistema que comentamos en el presente trabajo, lamisma está en función de las necesidades del cliente al que se destinará el productosoftware final. Anteriormente mencionamos que al finalizar cada iteración de la metodologíael 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 decidirmás adelante agregarle funcionalidades nuevas. Gracias a la forma en que se trabaja en lametodología Scrum, esto será posible sin ningún inconveniente. El producto puede crecer enfuncionalidades 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 PaginaLa metodología SCRUM – Proyecto Sistema GRH-TUC 2Introducción 2Marco teórico 2Roles que se desempeñan dentro de la Metodología Scrum 3Modelo de la metodología Scrum 5Aplicación de la Metodología SCRUM en un proyecto de desarrollo de software 6realSistema GRH-TUC 6Roles dentro del proyecto 6Presentación del Sistema 6El Cliente 6Metas 6Lista de funciones a implementar (Product Backlog) 7Sprint 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 10Scrum Master)Sprint Review y Sprint Retrospective 12Conclusiones 14Escalabilidad 15Sitios Web Recomendados 15 16