METODOLOGÍA DE DISEÑO DE SISTEMAS
METODOLOGIA SCRUM
“Proyecto Sistema GRH-TUC”
Profesor: Ing. JUAREZ, Gustavo
Alumnos:
MUC...
2
METODOLOGIA SCRUM
La metodología SCRUM – Proyecto Sistema GRH-TUC
Introducción
¿Que mejor introducción que aclarar un po...
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...
4
metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la
programación extrema.
Esta me...
5
auto-organizado y se centra en los objetivos del sprint (30 días planificados). Toda esta
situación genera como resultad...
6
Aplicación de la Metodología SCRUM en un proyecto de desarrollo de software real
Sistema GRH-TUC
Vamos a utilizar el sis...
7
Lista de funciones a implementar (Product Backlog)
El backlog es un inventario o una lista priorizada de requerimientos ...
8
Con esta información el product owner comienza a darle forma al listado.
Id Descripción Prioridad
Estimación
(HS)
Debe b...
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...
10
Id Descripción Prioridad
Estimación
(HS)
B1.1 Debe basarse en Web Alta 24
B1.1.1 Investigar sobre tecnologías Web Alta ...
11
Gráfico de esfuerzo
0
5
10
15
20
25
1-abr
3-abr
6-abr
7-abr
8-abr
9-abr
10-abr
13-abr
14-abr
15-abr
16-abr
17-abr
20-ab...
12
Sprint Review y Sprint Retrospective
Ya ha pasado el periodo de plazo. Si estimamos bien, tenemos nuestra versión del
p...
13
Gráfico de esfuerzo
0
5
10
15
22-abr
23-abr
24-abr
27-abr
28-abr
29-abr
30-abr
4-m
ay
5-m
ay
6-m
ay
7-m
ay
8-m
ay
11-m
...
14
Cada iteración el equipo muestra al cliente los resultados que consigue. No está
meses trabajando sin poder exhibir su ...
15
Escalabilidad
Respecto de la escalabilidad del sistema que comentamos en el presente trabajo, la
misma está en función ...
16
Indice
Pagina
La metodología SCRUM – Proyecto Sistema GRH-TUC 2
Introducción 2
Marco teórico 2
Roles que se desempeñan ...
Próxima SlideShare
Cargando en…5
×

Scrum en sistema grh tuc

218 visualizaciones

Publicado el

Caso de aplicación de metodología Scrum

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
218
En SlideShare
0
De insertados
0
Número de insertados
4
Acciones
Compartido
0
Descargas
8
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Scrum en sistema grh tuc

  1. 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. 2. 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. 3. 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
  4. 4. 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. 5. 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. 6. 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.
  7. 7. 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. 8. 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. 9. 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:
  10. 10. 10 Id Descripción Prioridad Estimación (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 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 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
  11. 11. 11 Gráfico de esfuerzo 0 5 10 15 20 25 1-abr 3-abr 6-abr 7-abr 8-abr 9-abr 10-abr 13-abr 14-abr 15-abr 16-abr 17-abr 20-abr 21-abr Díasdel Sprint Horasdetrabajopendientes EsfuerzoPendiente 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. 12. 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 Estimació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. 13. 13 Gráfico de esfuerzo 0 5 10 15 22-abr 23-abr 24-abr 27-abr 28-abr 29-abr 30-abr 4-m ay 5-m ay 6-m ay 7-m ay 8-m ay 11-m ay 12-m ay Díasdel Sprint Horasdetrabajopendientes EsfuerzoPendiente Gráfico de esfuerzo 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 ay 1-jun 2-jun Díasdel Sprint Horasdetrabajopendientes EsfuerzoPendiente Presentamos ahora el tercer Sprint: SPRINT 3 Id Descripción Prioridad Estimación (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 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. 14. 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. 15. 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. 16. 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

×