3.2. Ejemplo conductor
4.2.3. Sprint Retrospective
Fig. 4.G. Diagrama de secuencia para la etapa Sprint Retrospective.
Luego de finalizado un sprint, el Scrum Master, por medio de VS, realiza la calificación del desempeño de los recursos. VS envía la información ingresada por el Scrum Master hacia SmartFox Server, quien entiende que esta información debe reenviarla hacia el componente MO, invocando al servicio “Qualify Resource”. MO recibe esta solicitud y actualiza la información del repositorio.
4.3.
Herramienta en acción
En esta sección se muestran imágenes de la solución final resultante de la integración de herramientas previamente mencionadas.
Virtual Scrum es un ambiente 3D que consiste de una sala en la que múltiples usuarios pueden interactuar con paneles ubicados en las paredes de la misma. Esta sala puede apreciarse en la figura 4.J. Cada panel muestra información relativa al proyecto sobre el que se está trabajando y, algunos de ellos, da la posibilidad al usuario de modificar ciertos datos. Existe un panel que muestra el estado actual de las tareas de cada user story (figura 4.L.) del product backlog (figura 4.K) y permite al usuario modificar dicho estado cuando, por ejemplo, se ha finalizado con una tarea. Existen otros paneles entre los que se puede apreciar información tal como un gráfico de burndown o listado de user stories.
Para poder realizar el armado y planificación de un sprint es necesaria la manipulación de mucha información. Esta incluye el manejo del product backlog para seleccionar las tareas que formarán parte del sprint backlog, elegir que recursos estarán disponibles para el sprint sobre el que se realizará la planificación, etc. Por este motivo, se optó por el uso de ventanas en 2D que brindan a los usuarios una mejor usabilidad del sistema.
Figura 4.K: Panel de Product Backlog.
Figura 4.L: Panel que muestra el estado actual de cada tarea.
Mediante una de las ventanas, mostrada en la figura 4.M, el usuario puede manipular toda la información relevante al proyecto y/o sprint que desea planificar. Se brinda la posibilidad de gestionar tareas, recursos, roles y sprints, así como las habilidades de cada recurso y las habilidades requeridas en cada rol, lo que permitirá al algoritmo de planeamiento, determinar si un recurso es apto o no para ejercer determinado rol requerido para la realización de una determinada tarea. Esto último resulta una pieza clave en la planificación de un proyecto, ya que el algoritmo siempre trata de asignar, a una tarea, el recurso libre más capacitado para la resolución de la misma.
Figura 4.M: Ventana de gestión de proyectos.
En la figura 4.N. se puede apreciar la ventana por la cual el usuario puede armar el sprint antes de planificarlo. Para brindar una mayor usabilidad se optó por mostrar, en una lista, todas las user stories que forman parte del product backlog, y en otra, todas las que forman parte del sprint backlog. De esta manera, el usuario con sólo presionar un botón puede remover una user story del sprint backlog para que vuelva a formar parte del product backlog o viceversa.
Figura 4.N: Ventana de armado de sprint backlog para planificación del sprint.
La última ventana relevante de Virtual Scrum, se muestra en las figuras 4.O. Esta ventana es la que muestra la información devuelta por el algoritmo de planeamiento luego de que el usuario solicite la planificación de un determinado sprint. En la ventana mencionada se muestra
información tal como las user stories propias del sprint planeado con las tareas que involucra cada una, así como, el/los recurso/s al cual el algoritmo encontró más apto para resolver el sprint de forma eficiente. Dado que cada recurso puede ejercer diferentes roles de acuerdo a sus habilidades, en la ventana se muestra también que rol debería ejercer el recurso asignado para resolver las tareas eficientemente. Se muestra además, la duración estimada de la tarea (indicada por el Scrum Master) así como la duración que el algoritmo calcula que tardará el recurso asignado, en resolver la tarea en cuestión, basándose en las habilidades requeridas para la resolución y en las habilidades propias del recurso. Además se brinda al usuario la posibilidad de posponer user stories para un próximo sprint y entonces replanear el sprint nuevamente.
4.4. Conclusión
Los diagramas de secuencia ilustran un conjunto de aplicaciones heterogéneas que se comunican por medio de un canal común. Esta comunicación es totalmente transparente ya que ningún componente debe conocer detalles de implementación del otro. El componente integrador se comporta como un canal de comunicación común para todas las partes del sistema.
La combinación del estilo arquitectónico elegido más la utilización de SmartFox Server como componente integrador, permite que nuevos componentes sean fácilmente integrados a la arquitectura de IVS, sin afectar a las aplicaciones presentes en la arquitectura. Además, los componentes de la arquitectura son independientes entre sí: cualquier cambio en alguno de ellos, no afectará al resto, mientras su componente integrador respete las interfaces definidas por SmartFox.
Capítulo 5
Resultados Experimentales
Al principio de este trabajo, se mencionó que la gestión de un proyecto puede ser llevada a cabo siguiendo diferentes metodologías de trabajo. En este capítulo se explican los procedimientos utilizados para probar experimentalmente el desempeño que posee la combinación de metodologías ágiles junto con las técnicas de Memoria Organizacional y de Planning sobre una herramienta de administración de proyectos real, y se muestran los beneficios obtenidos al aplicar dicha combinación por sobre una gestión de proyectos siguiendo la metodología clásica tipo “cascada”. Se presenta, además, el marco de trabajo propuesto para simular el ambiente de trabajo y cuáles son las suposiciones tenidas en cuenta para generar un entorno controlado de experimentación. Como último experimento, se invierten los criterios de calificación utilizados por el algoritmo. Con esta prueba, se explica el concepto de capacidad de recuperación, que muestra la adaptación del algoritmo frente a un cambio en el criterio de calificación.
A lo largo del presente capítulo se podrán observar los resultados obtenidos luego de diversas ejecuciones del algoritmo de planeamiento utilizando las diferentes configuraciones de proyectos, pero manteniendo siempre, para cada uno de ellos, los mismos datos de entrada, lo que permitirá realizar comparaciones claras entre ellos.
Al final de este capítulo, se pondrá a prueba la capacidad de aprendizaje de la herramienta. Particularmente, se evidenciará que en un ambiente ágil Scrum, la curva de aprendizaje es más rápida con respecto a la metodología cascada. Se compararán los resultados obtenidos de estos dos enfoques, utilizando gráficas que permitan visualizar el comportamiento de la herramienta con respecto a los parámetros de entrada utilizados, lo que permitirá, además, comprobar experimentalmente la validez de los resultados obtenidos.