Desarrollo de herramienta de gestión de proyectos RUP usando metodologías Scrum + XP : gestión del proyecto y requisitos

Texto completo

(1)Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Proyecto Fin de Máster Máster Universitario en Ingeniería Web. Desarrollo de herramienta de gestión de proyectos RUP usando metodología Scrum + XP Gestión del Proyecto y Requisitos. Autores: Javier Molina Romero Luis Quishpi Betún. Tutores: Jesús Bernal Bermúdez Luis Fernández Muñoz. Madrid, Julio 2015.

(2) Índice 1.. Resumen del proyecto ................................................................................................... 5. 2.. Abstract ......................................................................................................................... 6. 3.. Introducción ................................................................................................................... 7. 4.. 3.1.. ¿Qué es Rational Unified Process? ........................................................................ 7. 3.2.. ¿Qué es Scrum? ................................................................................................... 10. 3.3.. ¿Qué es XP (Extreme Programming)?.................................................................. 13. 3.4.. Motivación ............................................................................................................ 15. 3.5.. Objetivos ............................................................................................................... 16. Gestión del proyecto .................................................................................................... 17 4.1.. Planificación de Scrum ......................................................................................... 17. 4.2.. Sprint 1 ................................................................................................................. 25. 4.2.1.. Requisitos ...................................................................................................... 25. 4.2.2.. Planificación .................................................................................................. 38. 4.2.3.. Desarrollo y resultado del Sprint .................................................................... 41. 4.2.4.. Demo y retrospectiva ..................................................................................... 45. 4.3.. Sprint 2 ................................................................................................................. 48. 4.3.1.. Requisitos ...................................................................................................... 48. 4.3.2.. Planificación .................................................................................................. 52. 4.3.3.. Desarrollo y resultado del Sprint .................................................................... 56. 4.3.4.. Demo y retrospectiva ..................................................................................... 60. 4.4.. Sprint 3 ................................................................................................................. 65. 4.4.1.. Requisitos ...................................................................................................... 65. 4.4.2.. Planificación .................................................................................................. 72. 4.4.3.. Desarrollo y resultado del Sprint .................................................................... 76. 4.4.4.. Demo y retrospectiva ..................................................................................... 80. 4.5.. Sprint 4 ................................................................................................................. 85. 4.5.1.. Requisitos ...................................................................................................... 85. 4.5.2.. Planificación .................................................................................................. 91. 4.5.3.. Desarrollo y resultado del Sprint .................................................................... 95. 4.5.4.. Demo y retrospectiva ..................................................................................... 99. 4.6.. Sprint 5 ............................................................................................................... 103. 4.6.1.. Requisitos .................................................................................................... 103. 4.6.2.. Planificación ................................................................................................ 106. 4.6.3.. Desarrollo y resultado del Sprint .................................................................. 109 1.

(3) 4.6.4. 4.7. 5.. Demo y retrospectiva ................................................................................... 113. Resultados proyecto ........................................................................................... 119. Conclusiones y trabajos futuros ................................................................................. 124 5.1.. Conclusiones ...................................................................................................... 124. 5.2.. Trabajos futuros .................................................................................................. 126. 6.. Glosario ..................................................................................................................... 127. 7.. Bibliografía ................................................................................................................. 132. 2.

(4) Índice de ilustraciones Ilustración 1: Descripción general del proceso ...................................................................... 8 Ilustración 2: Proceso Scrum .............................................................................................. 12 Ilustración 3: Directorios Google Drive ................................................................................ 17 Ilustración 4: Wiki Github .................................................................................................... 18 Ilustración 5: Plano de distribución en aula ......................................................................... 20 Ilustración 6: Tablero de tareas inicial ................................................................................. 21 Ilustración 7: App Planning Poker ....................................................................................... 22 Ilustración 8: Prototipo de interfaz: Crear proyecto .............................................................. 29 Ilustración 9: Prototipo de interfaz: Listar proyectos ............................................................ 30 Ilustración 10: Prototipo de interfaz: Consultar proyecto ..................................................... 31 Ilustración 11: Prototipo de interfaz: Establecer horario ...................................................... 32 Ilustración 12: Prototipo de interfaz: Añadir contrato ........................................................... 33 Ilustración 13: Prototipo de interfaz: Listar contratos ........................................................... 34 Ilustración 14: Prototipo de interfaz: Añadir empleado ........................................................ 35 Ilustración 15: Prototipo de interfaz: Listar empleados ........................................................ 36 Ilustración 16: Prototipo de interfaz: Consultar empleado ................................................... 37 Ilustración 17: Tablero inicial Sprint 1.................................................................................. 40 Ilustración 18: Burn Down Sprint 1 ...................................................................................... 41 Ilustración 19: Tablero final Sprint 1 .................................................................................... 44 Ilustración 20: Pantalla Crear Proyecto ............................................................................... 45 Ilustración 21: Pantalla Listar contratos ............................................................................... 46 Ilustración 22: Prototipo de interfaz: Consultar fases teóricas - Duración ............................ 49 Ilustración 23: Prototipo de interfaz: Consultar fases teóricas - Esfuerzo ............................ 50 Ilustración 24: Prototipo de interfaz: Establecer vacaciones ................................................ 51 Ilustración 25: Tablero inicial Sprint 2.................................................................................. 54 Ilustración 26: Burn Down Sprint 2 ...................................................................................... 57 Ilustración 27: Tablero final Sprint 2 .................................................................................... 59 Ilustración 28: Pantalla Establecer horario .......................................................................... 60 Ilustración 29: Pantalla Añadir empleado ............................................................................ 61 Ilustración 30: Pantalla Listar empleados ............................................................................ 62 Ilustración 31: Pantalla Establecer Vacaciones ................................................................... 63 Ilustración 32: Prototipos de interfaz: Establecer festivos .................................................... 67 Ilustración 33: Prototipo de interfaz: Consultar calendario ................................................... 68 Ilustración 34: Prototipo de interfaz: Modificar proyecto ...................................................... 69 Ilustración 35: Prototipo de interfaz: Modificar contrato ....................................................... 70 3.

(5) Ilustración 36: Prototipo de interfaz: Modificar empleado .................................................... 71 Ilustración 37: Tablero inicial Sprint 3.................................................................................. 74 Ilustración 38: Burn Down Sprint 3 ...................................................................................... 77 Ilustración 39: Tablero final Sprint 3 .................................................................................... 79 Ilustración 40: Pantalla Eliminar contrato ............................................................................ 80 Ilustración 41: Pantalla Consultar calendario ...................................................................... 81 Ilustración 42: Pantalla Establecer días festivos.................................................................. 82 Ilustración 43: Pantalla Fases teóricas ................................................................................ 83 Ilustración 44: Prototipo de interfaz: Consultar disciplinas teóricas ..................................... 86 Ilustración 45: Prototipo de interfaz: Asignar recursos......................................................... 88 Ilustración 46: Prototipo de interfaz: Asignar recursos - Lista empleados ............................ 89 Ilustración 47: Prototipo de interfaz: Asignar recursos - Cálculos ........................................ 89 Ilustración 48: Prototipo de interfaz: Asignar recursos - Asignación de horas ..................... 90 Ilustración 49: Tablero inicial Sprint 4.................................................................................. 93 Ilustración 50: Burn Down Sprint 4 ...................................................................................... 96 Ilustración 51: Tablero final Sprint 4 .................................................................................... 98 Ilustración 52: Pantalla Consultar disciplinas teóricas ......................................................... 99 Ilustración 53: Pantalla Consultar disciplinas teóricas – Distribución ................................. 100 Ilustración 54: Pantalla Consultar disciplinas teóricas – Personas-Hora............................ 100 Ilustración 55: Pantalla Consultar disciplinas teóricas – Personas-Día .............................. 101 Ilustración 56: Pantalla Consultar disciplinas teóricas – Personas-Mes ............................ 101 Ilustración 57: Prototipo de interfaz: Consultar fases asignadas ....................................... 104 Ilustración 58: Prototipo de interfaz: Consultar disciplinas reales ...................................... 105 Ilustración 59: Tablero inicial Sprint 5................................................................................ 108 Ilustración 60: Burn Down Sprint 5 .................................................................................... 110 Ilustración 61: Tablero final Sprint 5 .................................................................................. 112 Ilustración 62: Pantalla Asignar recursos .......................................................................... 113 Ilustración 63: Pantalla Asignar recursos - Lista de empleados......................................... 114 Ilustración 64: Pantalla Asignar recursos - Cálculos .......................................................... 115 Ilustración 65: Pantalla Asignar recursos - Asignación de horas ....................................... 115 Ilustración 66: Pantalla Consultar fases asignadas ........................................................... 116 Ilustración 67: Pantalla Consultar disciplinas reales .......................................................... 117. 4.

(6) 1. Resumen del proyecto Una de las principales causas por las que los proyectos de desarrollo software fracasan es la ausencia de metodología en su desarrollo. La motivación que hay detrás de este proyecto es el desarrollo de una aplicación web usando la metodología Rational Unified Process (RUP) y aprender, en una situación real, cómo desarrollar utilizando las metodologías Scrum + XP.. El principal objetivo de este proyecto es el seguimiento y documentación de una aplicación web para gestionar proyectos mediante RUP que se ha desarrollado a lo largo de dos meses y medio, por un equipo de 6 personas, usando metodologías ágiles.. RUP es un proceso de Ingeniería de Software que proporciona un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de un desarrollo organizado. Su objetivo es asegurar la producción de software de alta calidad que cumpla las necesidades de los usuarios finales, dentro de unos tiempos y presupuestos predecibles.. RUP promueve la productividad del trabajo en equipo proporcionando a cada miembro del equipo un fácil acceso a una base de conocimiento con una serie de directrices, plantillas y herramientas para actividades de desarrollo críticas. No importa si los miembros del equipo trabajan en distintas disciplinas de un proyecto, como requisitos, diseño o pruebas, los distintos miembros del equipo comparten un lenguaje común, procedimientos y punto de vista sobre cómo desarrollar el software.. Se espera obtener un profundo conocimiento de las metodologías ágiles y su aplicación en situaciones reales. Se espera obtener las principales ventajas y desventajas de su aplicación.. 5.

(7) 2. Abstract One of the causes of failure in the IT projects it’s the absence of a methodology in software Development. This is the motivation behind this project, develop a web application that let you manage a project using Rational Unified Process (RUP) and learn how to use Scrum + XP methodology in a real situation.. The main goal of this project is the tracking and documentation of a RUP web application developed throughout two and a half months, by a team composed by 6 developers,using Agile Methodologies.. The Rational Unified Process (RUP) is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.. The Rational Unified Process enhances team productivity, by providing every team member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities. By having all team members accessing the same knowledge base, no matter if you work with requirements, design, test, project management, or configuration management, we ensure that all team members share a common language, process and view of how to develop software.. It hopes to acquire an in-depth knowledge of Agile Methodologies and its application in real situations. It will be able to obtain some advantages and disadvantages of its application.. 6.

(8) 3. Introducción 3.1. ¿Qué es Rational Unified Process? RUP es un proceso de Ingeniería de Software que proporciona un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de un desarrollo organizado. Su objetivo es asegurar la producción de software de alta calidad que cumpla las necesidades de los usuarios finales, dentro de unos tiempos y presupuestos predecibles.. RUP promueve la productividad del trabajo en equipo proporcionando a cada miembro del equipo un fácil acceso a una base de conocimiento con una serie de directrices, plantillas y herramientas para actividades de desarrollo críticas. No importa si los miembros del equipo trabajan en distintas disciplinas de un proyecto, como requisitos, diseño o pruebas, los distintos miembros del equipo comparten un lenguaje común, procedimientos y punto de vista sobre cómo desarrollar el software.. RUP contiene muchas de las buenas prácticas en el desarrollo de software moderno de una forma que es adaptable a un amplio rango de proyectos y organizaciones. Son las siguientes: Características: 1. Desarrollo de software iterativo 2. Administración de requisitos 3. Uso de arquitecturas basadas en componentes 4. Software de modelado visual 5. Verificación de la calidad del software 6. Control de cambios en el software. 7.

(9) Descripción general del proceso El proceso puede ser descrito en dos dimensiones, a lo largo de dos ejes: ●. El eje horizontal representa el tiempo y muestra el aspecto dinámico del proceso expresado en términos de ciclos, fases, iteraciones e hitos.. ●. El eje vertical representa el aspecto estático del proceso: cómo es descrito en términos de artefactos, trabajadores y flujos de trabajo.. Ilustración 1: Descripción general del proceso. 8.

(10) Fases e iteraciones – La dimensión temporal Ésta es la organización dinámica del proceso en el tiempo. El ciclo de vida del software está compuesto por ciclos, cada ciclo de trabajo en una nueva generación del producto. RUP divide un ciclo de vida de desarrollo en cuatro fases consecutivas. ●. Fase de Inicio. ●. Fase de Elaboración. ●. Fase de Construcción. ●. Fase de Transición. Cada fase concluye con un hito bien definido, un punto en el tiempo en el cual se debe realizar una decisión crítica y determinados objetivos clave deben haber sido alcanzados.. Estructura estática del proceso Un proceso describe quién hace qué, cómo y cuándo. RUP es representado usando los 4 primeros elementos del modelado: ●. Roles, el “quien”.. ●. Actividades, el “cómo”.. ●. Artefactos, el “qué”.. ●. Flujo de trabajo, el “cuando”.. 9.

(11) 3.2. ¿Qué es Scrum? Scrum es una forma ágil de gestionar un proyecto, por lo general de desarrollo de software. Realmente se puede definir como un conjunto de buenas prácticas para trabajar colaborativamente y en equipos altamente productivos. Se basa en equipos multifuncionales y auto-organizados donde no existe un líder global que decide qué persona, qué tarea o cómo se resolverá un problema.. El Equipo Scrum (Scrum Team) Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto terminado aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.. El equipo Scrum consiste en: ●. Dueño del producto (Product Owner): Es quien define los objetivos, planifica el proyecto, crea y mantiene la lista de requisitos priorizados que son necesarios para cumplir con los objetivos, establece un calendario de entregas y reparte los requisitos en los Sprints.. ●. Equipo de Desarrollo (Development team): Es un equipo de desarrolladores autoorganizado y multifuncional, que como equipo, cuenta con todas las habilidades necesarias para crear un incremento del producto.. ●. El facilitador (Scrum Master): Es el responsable de que el equipo trabaje ajustándose a la reglas de Scrum. Es un líder que está al servicio del equipo y ayuda a quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración y poder finalizar el proyecto con éxito.. 10.

(12) El Sprint El Sprint es considerado como el corazón de Scrum. Es un bloque de tiempo de un mes, o menos, de duración durante el cual se crea un incremento del producto terminado. Un Sprint consiste en la reunión de planificación del Sprint, los Scrums diarios, el trabajo de desarrollo, la revisión del Sprint, y la retrospectiva del Sprint. Cada Sprint tiene una definición sobre qué se va construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto resultante. Reunión de Planificación de Sprint (Sprint Planning Meeting) La reunión de planificación de Sprint es donde se planifica el trabajo a realizar durante el Sprint. La Reunión de Planificación de Sprint tiene una duración máxima de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es usualmente más corto.. Scrum Diario (Daily Scrum) Es una reunión diaria, de 15 minutos de duración, que tiene el objetivo de facilitar la transferencia de la información, la colaboración entre los miembros del equipo y se ponen de manifiesto puntos en la que se pueden ayudar unos a otros. Los objetivos del Scrum diario son aumentar la productividad en el proyecto, potenciar el compromiso de equipo, fomentar el aprendizaje de los miembros del equipo y conocer el estado del Sprint. Revisión de Sprint (Sprint Review) Se trata de una reunión informal donde el equipo presenta al cliente los requisitos completados en el Sprint. En la revisión del Sprint, el cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos que proporcionó y ver si se cumplen sus expectativas. Retrospectiva de Sprint (Sprint Retrospective) El objetivo de la retrospectiva es el de mejorar de manera continua la productividad y la calidad de producto que está desarrollando, se analiza cómo ha sido la forma de trabajar durante el Sprint y por qué se están consiguiendo o no los objetivos.. 11.

(13) Lista de Producto (Product Backlog) Se trata de un listado que contiene los requisitos del proyecto, expresados en forma de historias de usuario. El cliente es el responsable de crear y gestionar la lista, asignando una importancia a cada historia de usuario para priorizarlas sobre las demás.. Lista de Pendientes del Sprint (Sprint Backlog) Es una lista de tareas que el equipo elabora en la reunión de planificación (Sprint Planning Meeting) como un plan para completar los requisitos seleccionados. El Sprint Backlog pertenece únicamente al equipo de desarrollo. Es actualizado a medida que el trabajo se completa.. El tablero de tareas (Scrum Taskboard) Para poder gestionar la lista de historias del Producto Backlog y hacerla visible para el equipo de desarrollo, se puede realizar un tablero de tareas que puede ser dibujado en una pizarra y que actúa como un espacio donde el equipo puede interactuar e indicar su estado de progreso en el Sprint. Puntos de Historia Los puntos de historia, son unidades de medida empleadas para medir y estimar el tiempo de desarrollo de las historias de usuario, su objetivo es catalogar la dificultad de las tareas y no se pueden comparar a horas de esfuerzo.. Un punto de historia equivale a una jornada de trabajo de un miembro del equipo en dedicación exclusiva.. Ilustración 2: Proceso Scrum. 12.

(14) 3.3. ¿Qué es XP (Extreme Programming)? XP o Extreme Programming es una metodología complementaria a Scrum (y también considerada ágil) ya que mientras que ésta se centra en la gestión y organización del proyecto, XP pone más énfasis en los procesos seguidos a la hora de producir código, dándole gran importancia a la adaptabilidad antes que a la previsibilidad.. Esta metodología sigue cinco máximas que considera necesarias para crear un buen software: . Simplicidad: Es la base de la programación extrema, que busca simplificar y clarificar el código al máximo para así agilizar el desarrollo y facilitar el mantenimiento. De esta manera se intenta evitar la complejidad generada al aumentar el tamaño del código y disminuir la cantidad de bugs que aparecen por ello.. . Comunicación: Se refiere a cómo se comunica el código con el programador. Si este es complejo es mucho más difícil de entender mientras que sí es claro puede considerarse autodocumentado ya que es fácil conocer su funcionalidad. Las pruebas unitarias son otra forma efectiva de comunicación ya que describen el diseño de las clases y métodos al mostrar ejemplos de su funcionalidad.. . Retroalimentación: Es muy importante que haya retroalimentación continua por parte del cliente ya que de esta forma se evita tener que volver a programar secciones grandes del proyecto. El tener ciclos de desarrollo cortos ayuda de gran manera a este principio.. . Coraje: Se refiere a la capacidad de programar pensando únicamente en las necesidades actuales, de manera que no se pierda tiempo planificando a futuro con funcionalidades que pueden no ser necesarias. El coraje permite que los programadores se sientan cómodos al modificar su código para adaptarlo a nuevas necesidades.. 13.

(15) . Respeto: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de producción.. 14.

(16) 3.4. Motivación En la actualidad se calcula que únicamente el 39% de los proyectos IT consiguen superar la fase de desarrollo exitosamente, sin alargar con ello el tiempo, el coste o reducir el alcance. Esto supone alrededor del 61% de fracasos, ya sean totales o en los que el proyecto se terminará pero con alguno de los problemas previamente mencionados, sobre el total del software desarrollado, una cantidad desmesurada para una época en la que prácticamente todas las empresas y negocios dependen en gran medida de estas aplicaciones.. Una de las principales causas de fracaso en estos proyectos es la falta de una metodología efectiva en los mismos, lo que provoca un mal seguimiento de los avances, mala gestión del crecimiento del software y facilita la aparición de bugs y de fallos. Al no seguir una metodología clara, los responsables no son capaces de realizar una estimación efectiva de la duración y riesgos del proyecto ya que en la mayoría de los casos no llevan a cabo planificación ni documentación alguna.. Esto nos lleva a una de las principales motivaciones, crear una herramienta que facilite la gestión de un proyecto que siga una metodología. En este caso metodologías pesadas, Rational Unified Process (RUP), ya que asegura la producción de software de alta calidad dentro de unos tiempos y presupuestos predecibles. RUP promueve la productividad del trabajo en equipo proporcionando a cada miembro del equipo un fácil acceso a una base de conocimiento con una serie de directrices, plantillas y herramientas para actividades de desarrollo críticas, lo que supone una solución para el alto porcentaje de proyectos fracasados.. Dado que RUP es una metodología muy extensa y con cierto grado de complejidad, como se ha podido ver anteriormente, una aplicación de este tipo puede resultar más atractiva y accesible que complicadas hojas de cálculo y una gran cantidad de documentos distintos.. Otra de las motivaciones para desarrollar este proyecto ha sido la de aprender, en una situación real, a llevar a cabo un proyecto siguiendo una metodología.. Para el desarrollo de este proyecto se ha optado por las metodologías Scrum y XP, perteneciente al conjunto de metodologías de desarrollo software conocidas como ágiles, en lugar de RUP porque se pensó que sería más conveniente para un proyecto de estas características, al contar con un tiempo de desarrollo y número de desarrolladores muy limitado. 15.

(17) 3.5. Objetivos El principal objetivo de este proyecto es el seguimiento y documentación de la gestión de un proyecto de desarrollo de una aplicación web con metodologías ligeras, Scrum + XP, que permita la gestión de proyectos de desarrollo software usando la metodología RUP.. Con la realización del proyecto se espera adquirir un conocimiento mucho más profundo de las metodologías ágiles y su aplicación, ya que se van a emplear en un proyecto real, donde se van a poder observar todas las ventajas de un desarrollo de este tipo pero también los posibles problemas que pueden acarrear.. También se espera adquirir conocimiento teórico sobre RUP, ya que a pesar de no ponerla en uso, al realizar una aplicación sobre ella se deberá analizar en profundidad.. Se quiere saber la utilidad real de cada herramienta que proporciona Scrum para el desarrollo de un proyecto, el funcionamiento e implicación de un equipo de trabajo siguiendo esta metodología y si hay que seguirla al pie de la letra o por el contrario, deja un espacio para la improvisación.. Mediante el seguimiento en detalle de cada Sprint de desarrollo, se pretende conocer con exhaustividad el papel que desempeña cada rol y las distintas tareas que realiza cada uno a lo largo del proyecto.. Por último, también se pretende ahondar en la gestión de requisitos para un proyecto de estas características y si el método para estimar historias de usuario es correcto en nuestro caso.. 16.

(18) 4. Gestión del proyecto 4.1. Planificación de Scrum Durante la semana previa al comienzo del desarrollo del proyecto, se hicieron una serie de tareas y se tomaron determinadas decisiones para el conjunto del proyecto.. Forma de trabajo Toda la documentación del proyecto se ha ido subiendo a Google Drive durante el desarrollo del mismo para que fuera accesible a todos los miembros del equipo. Se ha añadido todo tipo de información, documentos para la gestión, libros de consulta, archivos de configuración, etc. A continuación se puede observar la estructura del directorio.. Ilustración 3: Directorios Google Drive. 17.

(19) Github fue el repositorio elegido para poder trabajar todos los miembros del equipo a la vez. Al inicio del proyecto se creó una wiki en Github, como se muestra en la imagen, para compartir algunas directrices y decisiones entre los miembros del equipo.. Ilustración 4: Wiki Github. Por otro lado, se trabajó sobre dos ramas principalmente: ●. Rama develop: sobre esta rama trabajaron los miembros del equipo cada día. Se tomó la decisión de no tener una rama por empleado por simplicidad y porque, en caso de que hubiera que solucionar un conflicto, todos los miembros del equipo estaban en permanente comunicación ya fuese en el aula o al trabajar de forma independiente.. ●. Rama master: esta rama era fusionada con la rama develop al final de cada Sprint para asentar las distintas historias que habían sido finalizadas.. La jornada de trabajo de cada miembro del equipo era de 8 horas, 5 horas de desarrollo en el aula, junto con el resto de compañeros, y 3 horas de forma independiente.. 18.

(20) Tecnologías Durante la semana de planificación del proyecto se decidieron las tecnologías que se iban a utilizar a lo largo del proyecto. También se realizó una pequeña investigación sobre ellas para empezar el desarrollo con los conocimientos apropiados.. Las tecnologías por las que se apostaron fueron las siguientes: . Lenguaje: Java. . Capa de datos: Hibernate. . Base de datos: MYSQL. . Interfaz de usuario: JSF + AngularJS. . Vista: EJB. Se eligieron tecnologías como AngularJS, EJB o Hibernate porque la mayoría de los miembros del equipo las desconocían y era una buena oportunidad para aprender sobre ellas.. Duración del proyecto, Sprints La duración del desarrollo del proyecto estaba limitada para la fecha de finalización de las clases y la fecha de entrega del Proyecto de Fin de Máster, por lo que se tuvieron 10 semanas disponibles.. Se decidió hacer Sprints de dos semanas para priorizar la gestión del proyecto mediante metodologías ágiles sobre el propio desarrollo de la aplicación, dado que cuantos más Sprints haya, más tiempo hay que dedicar a tareas como las demos, retrospectivas y corrección de errores. La ventaja de tener Sprints cortos es que el proyecto está más controlado, dado que se revisa con más frecuencia. La duración de cada Sprint era de dos semanas naturales, y no se tuvieron en cuenta los días festivos, por lo que se dieron Sprints de distinta duración.. Rotación de roles Como se ha comentado anteriormente, los roles en un proyecto Scrum son los siguientes: ●. Dueño del producto (Product Owner). ●. Equipo de Desarrollo (Development team). ●. Scrum Master. 19.

(21) Se decidió unir el rol Product Owner y Scrum Master al tener menor carga de trabajo que un desarrollador, aunque al tener un perfil técnico, pudo ayudar en la realización de las pruebas de aceptación y pruebas unitarias.. Dado que el objetivo era que todos los miembros del equipo aprendiesen lo máximo posible, el rol de Product Owner / Scrum Master fue rotando entre ellos. El orden se decidió por sorteo, y al ser un equipo formado por 6 personas y tener 5 Sprints disponibles, todos los miembros del equipo, menos uno, tuvieron la oportunidad de realizar un Sprint adoptando ese rol.. Distribución del equipo en el aula El equipo de desarrollo estuvo distribuido en el aula de forma que la comunicación y los desplazamientos fuesen fáciles y cómodos, dado que uno de los puntos en los que hace hincapié la metodología es el trabajo en parejas.. Ilustración 5: Plano de distribución en aula. Cada miembro del equipo está representado por un círculo verde y tiene a su lado un espacio libre, representado con un círculo blanco, para trabajar en pareja con otro compañero. La distribución de cada miembro del equipo también facilita la comunicación. 20.

(22) durante el desarrollo, dado que todos los desarrolladores están sentados cerca unos de otros.. También se ha de señalar que el miembro del equipo que adoptaba el rol de Product Owner / Scrum Master estaba en la misma aula en todo momento, por si era requerido por los desarrolladores.. Planificación de un Sprint La reunión de planificación de cada Sprint se hizo el primer día de cada uno, a las 9:15 de la mañana, y en un principio se pensaba que duraría toda la jornada de trabajo, aunque finalmente la duración fue variable dependiendo del Sprint. Las reuniones se realizaban con todos los miembros del equipo en frente del tablón de tareas.. El tablón de tareas estaba situado en el aula para que el equipo lo tuviese presente en todo momento, ya fuese para consultarlo, actualizarlo o sentir la presión que puede ejercer.. Ilustración 6: Tablero de tareas inicial. Como se puede ver en la imagen, el tablón estaba formado por tres columnas correspondientes al estado de las tareas: PENDIENTES, EN CURSO y TERMINADAS; y por filas que corresponden a cada historia de usuario planificada para el Sprint. En la parte derecha se encontraba el gráfico Burn Down en el que se podía observar si se iban acabando las tareas en el plazo estimado, la fecha de la demo, un espacio para las historias 21.

(23) de usuario técnicas y no planificadas, y otro para las siguientes historias de la Pila de Producto que no formaban parte del actual Sprint.. A la hora de estimar las historias de usuario se decidió dividir cada una en distintas tareas, lo que conlleva una serie de ventajas: ●. Estimación de historias de usuario más precisas.. ●. Análisis de más detallado de cada historia, frecuentemente revela trabajo adicional.. ●. Fraccionamiento del trabajo para que varios miembros del equipo puedan trabajar en la misma historia de usuario.. Para la estimación de la duración de las distintas tareas se utilizó una aplicación para móviles como la que se puede ver en la imagen, en la que cada miembro del equipo puede seleccionar una carta que representa la estimación en puntos de historia. Un punto de historia es un día-hombre, o lo que es lo mismo, 8 horas de trabajo de una sola persona.. Ilustración 7: App Planning Poker. A la hora de estimar una tarea, cada miembro del equipo mostraba su propia estimación, se discutía cuál era la más correcta o simplemente se asignaba la estimación media.. 22.

(24) En el gráfico Burn Down se mostraría una línea por las historias de usuario incluidas al inicio de cada Sprint, y en caso de que se añadieran nuevas historias no planificadas, se mostraría otra línea en distinto color.. Sprints diarios Se definió un lugar y una hora para las reuniones diarias, serían a las 9:15 de la mañana en el aula, y su duración de 15 minutos como máximo.. En estas reuniones cada miembro del equipo explicaba en qué estaba trabajando, qué había terminado y si tenía algún problema. A raíz de estos comentarios se producían debates y se tomaban decisiones sobre cómo abordar los distintos problemas que se estuviesen produciendo.. Al terminar la reunión, con el tablón de tareas completamente actualizado, el Scrum Master actualizaba el gráfico Burn Down.. Product Backlog La Pila de Productos o Product Backlog se rellenó parcialmente durante la fase inicial del proyecto, estableciendo una importancia a cada historia para priorizar su realización. Durante el desarrollo del proyecto se incluirían nuevas historias de usuario.. En la tabla se puede ver el Product Backlog con las historias de usuario ordenadas por importancia.. Id Nombre. Importancia Estimación Notas. 1. Crear Proyecto. 100. 2. Listar Proyectos. 100. 3. Consultar Proyecto. 100. 4. Establecer horario. 90. 5. Añadir contrato. 80. 6. Listar contratos. 80. 7. Añadir empleado. 70. 8. Listar empleados. 70. 23.

(25) 9. Consultar empleado. 70. 10 Consultar fases teóricas. 60. 11 Establecer días/iteración. 60. Establecer 12 festivos/vacaciones. 55. Establecer 13 vacaciones/empleado. 55. 14 Consultar calendario. 50. 15 Modificar Proyecto. 45. 16 Modificar contrato. 45. 17 Eliminar contrato. 45. 18 Modificar empleado. 45. Eliminar fechas 19 vacaciones/empleado. 40. 20 Eliminar festivos/vacaciones 20 Consultar disciplinas 21 teóricas. 18. Asignar horas por disciplina, 22 fase y recurso. 16. Guardar horas por 23 disciplina, fase y recurso. 16. 24 Consultar fases asignadas. 14. 25 Consultar disciplinas reales 14 Consultar desviaciones de asignación de disciplinas 26 relativas vs asignadas. 12. Consultar desviaciones de 27 fases relativas vs asignadas 12 28 Eliminar empleado. 3. 29 Eliminar Proyecto. 1. 24.

(26) 4.2. Sprint 1 4.2.1.. Requisitos. Historias de usuario #1 - Crear proyecto Se requiere que la aplicación permita el registro de distintos proyectos para ser gestionados mediante la metodología RUP. Cada proyecto debe contener la información mínima para gestionarlo: nombre, periodo de trabajo y coste.. De igual forma, al crear un proyecto la aplicación debe indicar la siguiente información: ●. Meses naturales. ●. Días naturales. ●. Meses laborables. ●. Días laborables. ●. Horas laborables. ●. Coste por mes natural. ●. Coste por día natural. ●. Coste por mes laboral. ●. Coste por día laboral. ●. Coste por hora laboral. #2 - Listar proyectos Se requiere listar todos los proyectos que han sido registrados. La lista de proyectos debe mostrar solo el nombre del proyecto y una lista de opciones a realizar. Las opciones disponibles para cada proyecto serán: ver detalles, eliminar y establecer horario.. #3 - Consultar proyecto Se requiere consultar los detalles del proyecto así como información de valor para el administrador del proyecto: ●. Meses, días y horas laborables. ●. Coste laboral por hora, mes, día. ●. Número de meses y días naturales. ●. Coste por mes y días naturales.. 25.

(27) La pantalla será únicamente de consulta y la información no podrá ser modificada desde aquí. #4 - Establecer horario Se requiere poder agregar a cada proyecto información relacionada a su horario de trabajo. Esta información contempla: ●. Días laborables por mes. ●. Horas laborables por día de semana. Una vez proporcionada esta información por el usuario la aplicación debe mostrar, en la misma interfaz, los siguientes cálculos para ayudar a la gestión del proyecto. ●. Meses laborables por año. ●. Horas laborables por día. ●. Días laborables por año. ●. Horas laborables por mes. ●. Horas laborables por año. ●. Total de horas semanales. ●. Media laboral por día. #5 - Añadir contrato Se requiere registrar diversos contratos para ser utilizados en la contratación de empleados. Cada contrato deberá contar con nombre y porcentaje de seguro. No podrán registrarse dos contratos con el mismo nombre.. #6 - Listar contratos Se requiere consultar un listado de todos los contratos registrados. La lista debe mostrar el nombre y porcentaje de seguro de cada contrato, adicionalmente se debe mostrar por cada contrato las opciones para editarlo y eliminarlo.. Solo se deben poder eliminar contratos que no estén asociados a empleados.. #7 - Añadir empleados Se requiere realizar el alta de empleados en la aplicación para poder posteriormente incluirlos como recursos en los proyectos administrados. La información solicitada para registrar un empleado es la siguiente: ●. Nombre. ●. Apellidos 26.

(28) ●. Código de empleado. ●. Salario bruto anual. ●. Tipo de Contrato (del catálogo de contratos definido previamente). ●. Roles: Elegir 1 o más entre: ○. Gestión de Proyecto. ○. Requisitos. ○. Análisis y diseño. ○. Implementación. ○. Pruebas. ○. Despliegue. ○. Entorno y control de versiones. #8 - Listar empleados Se requiere que la aplicación permita listar todos los proyectos que han sido registrados. La lista de empleados debe mostrar solo el nombre del empleado y una lista de opciones a realizar. Las opciones disponibles para cada proyecto serán: Ver detalles y eliminar. #9 - Consultar empleado Se requiere que la aplicación permita consultar los datos de un empleado seleccionado: ●. Código. ●. Nombre. ●. Contrato. ●. Bruto Anual. ●. Total Anual. ●. Total Mensual. ●. Roles. Los datos deberán ser de solo lectura.. 27.

(29) Historia técnica #1 - Investigación EJB. Historia técnica #2 - Instalación de Glassfish Se requiere la instalación del servidor GlassFish ante la falta de compatibilidad con Tomcat.. Historia técnica #3 - Implementación de AngularFaces. Integración AngularJS y JSF Se requiere el uso de una dependencia para la integración del back end con el front end. Historia técnica #4 - Instalación de entorno de pruebas front-end. AngularJS Jasmine Se requiere el uso de un framework para la ejecución de pruebas del lado del cliente.. Historia técnica #5 - Investigación Hibernate Se requiere la investigación e implementación de los archivos de configuración de la tecnología hibernate para generar tablas en base de datos.. 28.

(30) Prototipos de interfaz Crear proyecto. Ilustración 8: Prototipo de interfaz: Crear proyecto. El prototipo de la interfaz Crear proyecto incluye cuatro campos habilitados para la edición en la parte izquierda. Estos campos son el nombre del proyecto y las variables del mismo: la fecha de inicio y de fin del proyecto, y el presupuesto disponible para llevarlo a cabo. Los campos de fechas son calendarios desplegables.. El resto de campos, que se sitúan en la parte derecha de la pantalla, son campos no editables que corresponden a distintos cálculos que pueden ser de utilidad, al aportar información en tiempo real, a la hora de introducir las variables.. 29.

(31) Listar proyectos. Ilustración 9: Prototipo de interfaz: Listar proyectos. En el prototipo de la interfaz Listar proyectos simplemente se listan los nombres de los proyectos creados juntos con unas opciones para cada uno de ellos.. Por cada proyecto hay un botón para establecer el horario del proyecto, uno para modificar las variables y otro para eliminarlo. Finalmente esta interfaz fue rediseñada para establecer el horario a la hora de crear el proyecto, no una vez creado.. También hay un botón para ir a la pantalla Crear proyecto desde esta pantalla y otro para volver a la página de inicio.. 30.

(32) Consultar proyecto. Ilustración 10: Prototipo de interfaz: Consultar proyecto. El prototipo de la interfaz Consultar proyecto es similar al de crear proyecto, las diferencias radican en los campos de las variables, que ahora no son editables, y en el nombre del proyecto, que en esta pantalla se sitúa en el encabezado.. Contiene un botón para volver a la pantalla anterior.. 31.

(33) Establecer horario. Ilustración 11: Prototipo de interfaz: Establecer horario. El prototipo de la interfaz Establecer horario está compuesto por una series de campos editables, los días laborables al mes y el número de horas que se trabaja en el proyecto, cada día de la semana.. Por otro lado, también se encuentran campos no editables que corresponden a cálculos que son actualizados en tiempo real al añadir nuevos valores a los campos editables, como las horas totales del proyecto o las horas de media en días laborables.. En la parte inferior derecha se encuentran dos botones para establecer el horario y volver a la pantalla anterior.. 32.

(34) Añadir Contrato. Ilustración 12: Prototipo de interfaz: Añadir contrato. El prototipo de la interfaz Añadir contrato está compuesto únicamente por dos campos, el nombre del nuevo tipo de contrato y el porcentaje del seguro.. También contiene un botón para añadir el contrato al sistema y otro para volver a la pantalla anterior en la parte inferior derecha.. 33.

(35) Listar contratos. Ilustración 13: Prototipo de interfaz: Listar contratos. El prototipo de la interfaz Listar contratos está formado por un listado de los nombres de los distintos contratos añadidos al sistema y sus seguros correspondientes. Como un contrato no tiene más información que la comentada, se decidió no incluir una pantalla para consultar un contrato, dado que desde el listado se mostraba toda.. Además, por cada contrato listado se encuentra un botón para ir a la modificación del contrato y otro para eliminarlo.. También se incluyen botones para ir a la pantalla Añadir contrato y para volver a la pantalla de inicio en la parte inferior derecha.. 34.

(36) Añadir empleado. Ilustración 14: Prototipo de interfaz: Añadir empleado. El prototipo de la interfaz Añadir empleado está compuesto por campos correspondientes a los datos de un empleado: nombre, apellidos, código de empleado y el salario bruto anual. También hay un campo desplegable para elegir uno de los contratos que ya han sido añadidos al sistema.. En la parte derecha de la pantalla se encuentra un listado con los distintos roles que un empleado puede adoptar. Se puede seleccionar más de un rol por empleado.. En la parte inferior derecha se encuentran botones para confirmar la creación del empleado y para volver a la pantalla anterior.. 35.

(37) Listar empleados. Ilustración 15: Prototipo de interfaz: Listar empleados. El prototipo de la interfaz Listar empleados está compuesto por un listado de los nombres y apellidos de los empleados añadidos al sistema y sus respectivos tipos de contrato.. También hay un botón por cada empleado que enlaza con la pantalla para modificar sus datos, y otro para eliminarlo.. Además se incluyen tres campos no editables donde se muestran los cálculos del coste medio de todos los empleados dados de alta.. Finalmente, en la parte inferior derecha de la pantalla se encuentran los botones que llevan a la pantalla Añadir empleado y para volver a la pantalla de inicio.. 36.

(38) Consultar empleado. Ilustración 16: Prototipo de interfaz: Consultar empleado. El prototipo de la interfaz Consultar empleado está compuesto por los datos del empleado seleccionado y por unos campos no editables correspondientes al cálculo del salario que cobra por año, mes, día y hora.. En la parte derecha de la pantalla también se encuentra un listado con los roles asignados al empleado.. En la parte inferior derecha se encuentra un botón para volver a la pantalla anterior.. 37.

(39) 4.2.2.. Planificación. El primer Sprint se desarrolló durante 2 semanas, desde el 20 de Abril hasta el 1 de Mayo de 2015, teniendo un día festivo en el que no se trabajó, el viernes 1 de Mayo. De los 9 días laborables restantes, el primero se dedicó a la reunión de planificación del Sprint y el último, a la preparación y realización de la demo, y a la retrospectiva. Por lo tanto hubo 7 días de desarrollo.. Nº semanas. 2. Equipo. 5+1. Dedicación. 100%. El número de desarrolladores en el Sprint fue de 5, dado que un miembro del equipo asumió el rol de Product Owner / Scrum Master. Los días-hombre para este Sprint fueron 5(desarrolladores) x 7(días de desarrollo) = 35.. Factor de dedicación:. 60%. Días-Hombre:. 35. Esto permitiría que se añadiesen historias de usuario en el que la suma de sus estimaciones llegase hasta 35 puntos de historia, pero como una persona no se dedica el 100% del tiempo a su tarea, si no que siempre hay algún tipo de distracción o problema que hace que se pierda tiempo, se le aplica un factor de dedicación.. En el caso del primer Sprint, al no tener ninguna referencia de Sprints anteriores, asumimos que el factor de dedicación era del 60%.. Por lo tanto, la velocidad estimada es el resultado de los 35 días-hombre disponibles trabajando al 60%, 21 puntos de historia.. Velocidad estimada: 21. puntos de historia. 38.

(40) Se decidió añadir al Sprint Backlog las nueve historias de usuario con más prioridad, es decir, las primeras nueve historias de usuario del Product Backlog, que sumaban un total de 21.5 puntos de historia.. Sprint 1 Backlog Id. Nombre. Importancia. Estimación. Notas. 1 Crear proyecto. 100. 3. 2 Listar proyectos. 100. 2. 3 Consultar proyecto. 100. 2. 4 Establecer horario. 90. 3.5. 5 Añadir contrato. 80. 2.5. 6 Listar contratos. 80. 2. 7 Añadir empleado. 70. 2.5. 8 Listar empleados. 70. 2. 9 Consultar empleado. 70. 2. TOTAL:. 21.5. Una vez se realizó la estimación de las historias de usuario y se decidió cuáles se añadían al Sprint Backlog, se formó el tablón de tareas.. En el tablón se añadió una tarjeta por cada historia de usuario, que estaba compuesta por el nombre, una serie de notas aclaratorias, la importancia y la estimación. A su vez, también se añadieron las distintas tareas para cada historia, que realmente es lo que cada miembro del equipo movía entre las distintas columnas del tablón.. También se dibujó el gráfico Burn Down vacío y se determinó la fecha y hora de la demo.. En la siguiente imagen se puede apreciar el aspecto del tablón al inicio del primer Sprint.. 39.

(41) Ilustración 17: Tablero inicial Sprint 1. 40.

(42) 4.2.3.. Desarrollo y resultado del Sprint. Se va a comentar el desarrollo del Sprint a partir de la imagen del gráfico Burn Down una vez el Sprint había finalizado.. Ilustración 18: Burn Down Sprint 1. Durante el desarrollo del Sprint se dieron una serie de problemas que hicieron que no se cumpliesen los objetivos.. En los tres primeros días se finalizaron tareas a un ritmo que se aproximaba a la recta ideal, sin embargo, desde el tercer al sexto día se produce un estancamiento, incluso aumenta el número de tareas por hacer, debido a que se dieron por finalizadas antes de tiempo, y se tuvieron que rehacer debido a distintos cambios.. 41.

(43) Los problemas que se dieron en esa etapa del Sprint fueron causados por la inexperiencia del equipo utilizando determinadas tecnologías, la no estimación de historias técnicas que fueron surgiendo durante el desarrollo y la mala estimación de las tareas iniciales.. En la siguiente imagen se pueden ver las distintas historias técnicas que aparecieron durante el Sprint.. Historias técnicas añadidas a lo largo del Sprint Investigación EJB e Instalación de Glassfish Implementación de AngularFaces. Integración AngularJS y JSF Instalación de entorno de pruebas front-end. Angular - Jasmine Investigación Hibernate. Finalmente los dos últimos días se consiguieron finalizar algunas tareas, aunque el resultado no se acercó al resultado deseado. También hay que destacar que el equipo hizo un pequeño esfuerzo extra al dedicar gran parte del día de la demo y la retrospectiva a seguir desarrollando para acabar alguna tarea más. Debido a eso, el eje de días del Sprint del gráfico Burn Down tiene un día más.. Una de las historias de usuario que dio más problemas fue establecer horario, no se consiguió terminar a pesar de que tenía asignada una prioridad más alta que otras historias que fueron terminadas. Se tuvo que introducir en el siguiente Sprint y reestimarla.. 42.

(44) El Sprint Backlog resultante al finalizar el Sprint fue el siguiente:. Sprint 1 Backlog Id. Nombre. Importancia. Estimación. Notas. 1 Crear proyecto. 100. 3. 2 Listar proyectos. 100. 2. 3 Consultar proyecto. 100. 2. 4 Establecer horario. 90. 3.5. 5 Añadir contrato. 80. 2.5. 6 Listar contratos. 80. 2. 7 Añadir empleado. 70. 2.5. 8 Listar empleados. 70. 2. 9 Consultar empleado. 70. 2. TOTAL:. 21.5. Las historias finalizadas están indicadas en verde en la tabla, con lo que se terminaron un total de 11,5 puntos de historias de 21,5. No se han contemplado las historias técnicas porque no fueron estimadas ni incluidas en el Sprint Backlog, aunque se finalizaron.. El tablón al final del Sprint quedó de la siguiente manera:. 43.

(45) Ilustración 19: Tablero final Sprint 1. 44.

(46) 4.2.4.. Demo y retrospectiva. Demo La demo del primer Sprint se realizó el 30 de Abril, último día del Sprint, a las 12:30. Durante la demo se fueron comprobando, una a una, las distintas historias de usuario finalizadas, su correcto funcionamiento, y recogiendo los errores y posibles mejoras que se podrían hacer.. A continuación se van a mostrar algunas pantallas que se finalizaron en este Sprint y se pudieron ver en la demo.. Crear proyecto. Ilustración 20: Pantalla Crear Proyecto. Esta pantalla muestra el formulario para crear un nuevo proyecto y los cálculos resultantes de las variables del proyecto introducidas. Los cálculos cambian de valor en tiempo real, cada vez que se modifica el valor del presupuesto o las fechas del proyecto.. A diferencia del prototipo de la interfaz, aquí se puede ver que para crear un proyecto primero hay que establecer un horario y más adelante, establecer las variables del proyecto.. 45.

(47) Esto se decidió en el siguiente Sprint, en el momento de hacer esta demo, los proyectos eran creados sin un horario establecido.. Listar contratos. Ilustración 21: Pantalla Listar contratos. Esta pantalla sirve como ejemplo para todas las pantallas que muestran listados, ya sean proyectos, empleados o contratos, dado que tienen la misma estructura.. En el caso de los contratos, se muestra el nombre del tipo de contrato y el porcentaje del seguro. En la tercera columna se encuentra un campo desplegable con las distintas opciones que se pueden realizar con un contrato.. Se decidió introducir un campo desplegable para mostrar las opciones por simpleza visual, a diferencia del prototipo de la interfaz, donde hay un botón por opción.. Al finalizar la demo se obtuvieron los siguientes errores para solucionarlos en el siguiente Sprint.. 46.

(48) Errores Post-demo 1 Cambiar nombres de página (url's) en base a la Wiki del proyecto. Mostrar mensajes de validación. Mover botón guardar en Create. Cambiar label a coste en Create. Redirigir después de Crear elemento. Mostrar mensaje de confirmación al crear elemento. Validar que haya schedule en consultar proyecto. Hacer que los datos se muestren en una sola línea en consultar proyecto. Estandarizar el estilo de la app (Botones, títulos, etc.) Mostrar Unidades en labels (€, $, etc.) En contrato no mostrar el consultar. Cambiar el botón volver a Ir al inicio en las páginas de listar.. Retrospectiva La retrospectiva se hizo de forma hablada entre los miembros del equipo y se llegó a algunas conclusiones: ●. Los cambios o decisiones que se hablaban durante los Daily Sprints se debían documentar de alguna forma para tenerlos presentes en todo momento. En este primer Sprint se vivió alguna confusión debido a esto.. ●. Las estimaciones debían ser más realistas, dado que se subestimaron algunas tareas.. ●. Se debía tener más en cuenta el periodo de aprendizaje e investigación de nuevas tecnologías. 47.

(49) 4.3. Sprint 2 4.3.1.. Requisitos. Historias de usuario Dado que las historias iniciales pertenecían en un principio al primer Sprint, donde ya se encuentran detalladas, a continuación se describen únicamente las historias añadidas como extras durante el desarrollo del segundo Sprint y son las siguientes:. #1 - Consultar de fases teóricas. Se requiere que la aplicación permita consultar por cada fase del proyecto (Inicio, Elaboración, Construcción, Transición) valores que permitan tener una visión, según lo que indica la teoría de la metodología RUP, de cómo se debería distribuir el proyecto. Los valores a tener en cuenta son los siguientes: ●. Distribución de trabajo por fase. ●. Cantidad de horas, días, meses empleados por cada fase. ●. Fecha inicio y de fin de cada fase. ●. Número de iteraciones por cada fase. ●. Número de iteración de inicio y de fin en cada fase. ●. Media de horas, días y meses empleados en cada iteración. #2 - Establecer vacaciones empleado. Se requiere que la aplicación contemple el registro de vacaciones por empleado, lo cual es necesario para calcular las horas disponibles que tiene un empleado en cada fase y así no ver afectado el tiempo y los recursos asignados para cada fase.. 48.

(50) Prototipos de interfaz Los prototipos de las historias de usuario añadidas como extras durante el desarrollo del Sprint son: Consultar Fases Teóricas. El prototipo de interfaz Consultar fases teóricas se ha divido en dos pestañas: Duración y Esfuerzo. Siendo el campo días por iteración y días recomendados la parte común para las dos pestañas. -. Duración. Ilustración 22: Prototipo de interfaz: Consultar fases teóricas - Duración. Los campos en esta interfaz no son editables. Los porcentajes iniciales de distribución son valores fijos establecidos indicados por RUP y los demás son calculados en tiempo real.. Para realizar los cálculos de esta interfaz se utilizan los valores de la fecha de inicio, fecha de finalización, horas, días y meses del proyecto.. 49.

(51) -. Esfuerzo. Ilustración 23: Prototipo de interfaz: Consultar fases teóricas - Esfuerzo. Los campos en esta interfaz no son editables. Los porcentajes iniciales de distribución son valores fijos establecidos por la teoría de RUP y los demás son calculados en tiempo real.. Para realizar los cálculos de esta interfaz se utilizan los valores previamente establecidos en el proyecto tales como: coste total, coste por hora, coste por día y coste por mes de proyecto.. 50.

(52) Establecer Vacaciones del Empleado. Ilustración 24: Prototipo de interfaz: Establecer vacaciones. El prototipo de interfaz Establecer Vacaciones del Empleado está compuesto por una lista de empleados, un campo editable para establecer el rango de fechas y en la parte derecha se encuentra una lista donde se visualiza las fechas añadidas por el empleado para sus vacaciones.. El botón Agregar añade la fecha seleccionada al listado de vacaciones y está programado de tal manera que valida el solapamiento de las fechas.. 51.

(53) 4.3.2.. Planificación. El segundo Sprint se desarrolló durante dos semanas, desde el 4 de Mayo hasta el 15 de Mayo de 2015, teniendo un día festivo donde no se trabajó, el 15 de Mayo. EL primer día del Sprint se dedicó a la planificación y estimación de tiempos usando planning poker y el último día a la preparación, realización de la demo y retrospectiva, por lo tanto, de los 9 días laborables hubo 7 días de desarrollo.. Nº semanas. 2. Equipo. 5+1. Dedicación. 100%. En este Sprint, conformado por 6 miembros, el número de desarrolladores fueron 5, dado que un miembro del equipo asumió el rol de Product Owner / Scrum Master. Los díashombre para este Sprint fueron 5(desarrolladores) x 7(días de desarrollo) = 35.. Factor de dedicación:. 33%. Días-Hombre:. 35. Esto permitiría que se añadiesen historias de usuario en el que la suma de sus estimaciones llegase hasta 35 puntos de historia, pero como una persona no se dedica el 100% del tiempo a su tarea, si no que siempre hay algún tipo de distracción o problema que hace que se pierda tiempo, se le aplica un factor de dedicación.. En este Sprint se utilizó como factor de dedicación el resultante del primer Sprint, un 33%. A pesar de ser un factor de dedicación bajo, preferimos guiarnos por él y en caso de que se finalizaran las historias antes de tiempo, introducir alguna nueva en el Sprint.. La velocidad estimada para este Sprint es el resultado de los 35 días-hombre disponibles trabajando al 33%, 11,55 puntos de historia.. Velocidad estimada:. 11.55. puntos de historia. 52.

(54) Se decidió añadir al Sprint Backlog las cuatro historias de usuario con más prioridad, es decir, las 4 historias de usuario siguientes al del primer Sprint, que sumaban un total de 12 puntos de historia.. Sprint 2 Backlog Id. Nombre. Importancia Estimación. 4 Establecer horario. 90. 3. 7 Añadir empleado. 70. 4. 8 Listar empleados. 70. 2.5. 9 Consultar empleado. 70. 2.5. TOTAL:. 12. Notas. Una vez realizada la estimación de las historias de usuario, se decidió cuáles se añadían al Sprint Backlog y se formó el tablón de tareas.. En el tablón se añadió una tarjeta por cada historia de usuario, que estaba compuesta por el nombre, una serie de notas aclaratorias, la importancia y la estimación. A su vez, también se añadieron las distintas tareas para cada historia, que realmente es lo que cada miembro del equipo movía entre las distintas columnas del tablón.. También se dibujó el gráfico Burn Down vacío y se determinó la fecha y hora de la demo.. En la siguiente imagen se puede apreciar el aspecto del tablón al inicio del primer Sprint.. 53.

(55) Ilustración 25: Tablero inicial Sprint 2. 54.

(56) Como algunas de las historias pertenecientes a este Sprint. provienen del Sprint. anterior, no se detallan en este apartado ya que se hizo anteriormente.. Los últimos días del Sprint, como algunos miembros del equipo no tenían tareas que realizar, ya que las demás estaban finalizadas o en proceso, se agregaron dos historias de usuario nuevas y se reestimaron, quedando el nuevo Sprint Backlog de la siguiente manera:. Sprint 2 Backlog Id. Nombre. Importancia Estimación. 4 Establecer horario. 90. 3. 7 Añadir empleado. 70. 4. 8 Listar empleados. 70. 2.5. 9 Consultar empleado. 70. 2.5. Notas. 10 Consultar fases teóricas. 60. 4 Extra. 13 Establecer vacaciones empleado. 40. 4.5 Extra. TOTAL:. 20.5. 55.

(57) 4.3.3.. Desarrollo y resultado del Sprint. El primer día del Sprint, después de haber realizado la planificación, el Scrum Master presentó una tabla en Excel con los errores que se encontraron o fueron visibles durante la Demo del Sprint anterior y que debían ser resueltas. Las denominadas tareas del post demo, son llevadas a cabo al inicio del periodo dedicado al desarrollo.. Errores Post-demo 1 Cambiar nombres de página(url's) en base a Wiki Mostrar mensajes de validación Mover botón guardar en Create Cambiar label a coste en Create Redirigir después de Crear elemento Mostrar mensaje de confirmación al crear elemento Validar que haya schedule en consultar proyecto Hacer que los datos se muestren en una sola línea en consultar proyecto Estandarizar el estilo de la app (Botones, Títulos etc.) Mostrar Unidades en labels (€, $, etc.) En contrato no mostrar el consultar Cambiar el botón volver a Ir al inicio en las páginas de listar. 56.

(58) En el presente Sprint los resultados fueron representados a través de dos líneas en el Burn Down.. Ilustración 26: Burn Down Sprint 2. Al inicio del Sprint, el equipo desarrolló historias de usuario de forma más rápida de lo estimado debido al bajo factor de dedicación procedente del anterior Sprint, por lo que el Product Owner / Scrum Master agregó las dos siguientes historias de usuario del Product Backlog en el presente Sprint. No se añadió la historia Establecer días/iteración a pesar de que debería haber entrado en el Sprint Backlog porque se decidió fusionarla con Consultar fases teóricas, por lo que se eligió la siguiente historia del Product Backlog.. 57.

(59) La estimación total inicial era de 12 puntos de historia, pero ahora, con las nuevas historias agregadas, los puntos de historia aumentaron hasta los 20.5. Para reflejar la evolución del trabajo realizado a partir, tanto del Sprint Backlog inicial como del que contenía las nuevas historias, se decidió agregar otra línea (color rojo) que representará el proceso del desarrollo del Sprint con las nuevas historias.. Por el optimismo elevado del equipo se subestimó la complejidad de la historia “Consultar fases teóricas” con una estimación de cuatro días, por lo que al final de Sprint únicamente se pudo finalizar una historia de usuario, de las dos que se habían agregado, lo que explica el por qué la línea roja del Burn Down no termina en cero.. También hay que comentar que a pesar de tener 7 días dedicados al desarrollo de las historias de usuario, se dedicó parte del último día del Sprint a terminar alguna tarea, por lo que en el Burn Down aparecen 8 días de desarrollo.. El Sprint Backlog resultante al finalizar el Sprint fue el siguiente:. Sprint 2 Backlog Id. Nombre. Importancia Estimación Notas. 4. Establecer horario. 90. 3. 7. Añadir empleado. 70. 4. 8. Listar empleados. 70. 2.5. 9. Consultar empleado. 70. 2.5. 10. Consultar fases teóricas. 60. 4. EXTRA. 13. Establecer vacaciones empleado. 40. 4.5. EXTRA. TOTAL:. 12. TOTAL EXTRAS:. 20.5. Las historias finalizadas están indicadas en verde en la tabla, con lo que se terminaron un total de 16,5 puntos de historias de 20,5.. El tablón al final del Sprint quedó de la siguiente manera:. 58.

(60) Ilustración 27: Tablero final Sprint 2. 59.

(61) 4.3.4.. Demo y retrospectiva. Demo La demo del segundo Sprint se realizó el 14 de mayo, último día del Sprint, a las 12:30 de la mañana.. A continuación se muestra algunas pantallas que se finalizaron en este Sprint y se pudieron ver en la demo. Establecer Horario. Ilustración 28: Pantalla Establecer horario. Como estaba previsto en el prototipo de interfaz de Establecer Horario, en el aspecto final de la pantalla se puede observar que tanto los campos editables como los de sólo lectura, fueron diseñados y programados en su totalidad.. Esta pantalla forma parte de la de Crear proyecto, siendo una pestaña previa a la introducción de las variables del proyecto, aunque en principio estaban pensadas de forma independiente.. 60.

(62) Añadir Empleado. Ilustración 29: Pantalla Añadir empleado. Todos los campos y los botones corresponden y fueron desarrolladas acorde a la propuesta realizada en el prototipo de interfaz.. 61.

(63) Listar Empleados. Ilustración 30: Pantalla Listar empleados. En el momento de su desarrollo, el equipo decidió que los tres campos de costes planteados en el prototipo de interfaz no eran necesarios en esta lista, razón por la cual únicamente se visualiza el Nombre y su tipo de contrato. Las opciones Detalles y Editar fueron desarrolladas en los Sprints siguientes.. 62.

(64) Estableces Vacaciones del Empleado.. Ilustración 31: Pantalla Establecer Vacaciones. La pantalla final de esta historia de usuario es similar a la solicitada en el prototipo de interfaz y cumple en su totalidad sus requerimientos. La diferencia radica en que no se visualiza una sola fecha sino un rango.. 63.