descargar 68.4 Kb.
|
4 TUNE-UP Process Tool La mejor forma de ilustrar la gestión de tiempos en TUNE-UP es describir cómo a este aspecto se le ha dado apoyo mediante la herramienta TUNE-UP Process Tool. Un aspecto clave para el proyecto es que los agentes se dediquen a las actividades acertadas de acuerdo con las prioridades. El agente decide qué actividad realizar dependiendo de los plazos de la versiónl producto (fechas de inicio y de término de versión), la prioridad de la unidad de trabajo en la versión, y la posición de la actividad en el workflow. El Planificador Personal (Fig. 2) ayuda a los agentes a conocer las unidades de trabajo que tiene asignadas y el estado en el que se encuentran. Cada unidad está en una o más actividades en un instante de tiempo (si su workflow permite el paralelismo de dichas actividades) y asignada a un único agente por actividad. El grid de la derecha en la Fig. 2 muestra información de cada actividad incluyendo: producto, versión, descripción de la unidad de trabajo, tiempos calculados, y el estado actual de la actividad, etc.. El grid de la izquierda de la Fig. 2 resume las unidades de trabajo según la actividad y el estado en el cual se encuentran. Con los tiempos calculados el agente puede visualizar (ver columnas del grid de la derecha de la Fig. 2) y así conocer el tiempo que lleva registrado en cada actividad (T.Real), y compararlo con los tiempos que ha estimado (T. Est., estimado y estimado ajustado), el porcentaje completado con respecto el estimado (%Com.) y las horas restantes (H. Rest.) que le quedan para finalizar la actividad. El grid de la izquierda de la Fig 2. resume las unidades de trabajo según la actividad y el estado en el cual se encuentran. ![]() Fig. 2. Fragmento de interfaz del Planificador Personal Cuando el tiempo registrado supera al que se ha estimado se alerta coloreando la celda Horas Restantes (H. Rest., ver Fig. 2) y Dicho tiempo (que sería negativo) se consideraándolo como como valor nulo en respecto del cómputocómputo total. Cuanto antes Eel agente debería re-estimar la la actividad en esta situación cuanto antes. ![]() Fig. 3. Fragmento de interfaz del Gestor de Unidades de Trabajo ![]() Fig. 2. Fragmento de interfaz del Planificador Personal Cuando el agente decide en qué actividad trabajar, accede al Gestor de Unidades de Trabajo (Fig. 3) en el cual se le apoya en la realización de las actividades de una unidad de trabajo. En la parte superior de la Fig.3 se observan los datos generales de la unidad de trabajo. En la parte inferior se observa la pestaña Seguimiento la cual resume los registros de seguimiento, es decir, una línea generada cada vez que se pasa a una actividad en el workflowpara cada actividad realizada o pendiente en de la unidad de trabajo (incluyendo fechas-horas de inicio y finalización, agente, y otros datos). El Gestor de Unidades de Trabajo ofrece además otras pestañas entre las que destacan: Peticiones (mecanismo de comunicación entre los agentes en el contexto de una unidad de trabajo), Documentación (espacio de documentación para compartir especificaciones de la unidad de trabajo), Relaciones (relaciones de dependencia de la unidad de trabajo con respecto de otras), Planificación (asignación de agentes a actividades de la unidad de trabajo y asignación a una versión del producto) y Tiempos, que explicaremos a continuación.la cual explicaremos en más detalle a continuación. Con los botones Comenzar/Continuar/Pausar (es el mismo botón que cambia de nombre según el estado de la actividad) y Finalizar Actividad el agente puede controlar el registro de tiempo, activando, pausando o finalizando la actividad. respectivamente. ![]() Fig. 3. Fragmento de interfaz del Gestor de Unidades de Trabajo Con los botones Comenzar/Continuar/Pausar (es el mismo botón que cambia de nombre según el estado de la actividad) y Finalizar Actividad el agente puede controlar el registro de tiempo, activando, pausando o finalizando la actividad respectivamente. ![]() Fig. 4. Fragmento de Pestaña Tiempos La pestaña Tiempos (Fig. 4) ofrece funcionalidad específica de tiempos para la unidad de trabajo. En la parte superior los agentes establecen las estimaciones para cada actividad. En la parte inferior se muestran los registros de tiempo producidos automáticamente por los pares de acciones Comenzar/Continuar – Pausar/Finalizar. Tanto en las estimaciones como en los registros de tiempo el agente puede realizar ajustes cuando por ejemplo, prevea que la estimación anterior no se va a cumplir, o cuando haya olvidado Activar, Pausar o Finalizar. ![]() Fig. 5. Fragmento de interfaz Gestión de Productos – Unidades de Trabajo de la Versión Para realizar la planificación y seguimiento el Product Manager utiliza el módulo Gestión de Productos (donde se gestionan las versiones de los productos) y desde allí, seleccionando un producto y versión se accede a Unidades de Trabajo en la Versión (Fig.5) y a la Carga de Agentes en la Versión (Fig.6). Así, ![]() Fig. 5. Fragmento de interfaz Gestión de Productos – Unidades de Trabajo de la Versión Enen la interfaz mostrada en la Fig.5, se muestran las unidades de trabajo asignadas a la versión seleccionada. En esta interfaz el Product Manager puede consultar los datos resumidos de cada unidad de trabajo en la versión (en particular, puede conocer la actividad actual y el agente asignado a cada unidad de trabajo) o acceder al Gestor de Unidades de Trabajo con una determinada. También puede establecer el orden de prioridad de las unidades de trabajo en una versión o cambiar su versión. ![]() Fig. 6. Fragmento de interfaz Gestión de Productos – Carga de Agentes en Versión En la Fig. 6 se muestra la Pestaña Carga de Agentes en Versión. En ella se puede conocer en cualquier momento la holgura simple de los agentes respecto de sus actividades en una versión del producto. En esta interfaz se ofrecen potentes mecanismos de filtros y agrupaciones por columnas. Cuando una versión tiene problemas de holgura, en esta misma interfaz el Product Manager puede cambiar el agente asignado a la actividad (para balancear la carga de un agente) o cambiar de versión alguna unidad de trabajo. Otras alternativas son modificar la fecha de término de la versión, asignar más recursos humanos a la versión o dividir partir unidades de trabajo para realizarlas incrementalmente en varias versiones. 5 Trabajos relacionados Modelos de referencia como CMMI y estándares como ISO 90003 y SPICE, así como otras guías para gestión de proyectos tales como el PMBOK [3] (Project Management Book of Knowledge) [13] sólo recomiendan prácticas muy generales para la gestión del tiempo. Así, corresponde a Son las metodologías el las encargadas de definir mecanismos concretos para aplicar dichas prácticas. Las metodologías ágiles aciertan respecto de la granularidad en la definición de las unidades de trabajo, su asignación y estimación, y en el seguimiento continuo. Además, y promueven informalmente en cierto grado el registro actualizado de tiempos invertidos. Sin embargo, sula definición de roles tan genéricos y la no existencia , acompañada del prácticamente inexistente concepto de workflows explícitos, resulta suele ser incompatible con otros enfoques squemas de desarrollo basados en mayor especialización (analistas, programadores, testers, etc.) de roles juntoy con mayores necesidades de workflows que coordinaciónn el trabajo. Cuando el mismo agente desempeña varios roles se reduce la comunicación y coordinación con otros agentes (al menos respecto de las tareas de dichos roles). Pero encontrar agentes que satisfagan un perfil múltiple es difícil. Además, cuando el trabajo es colaborativo existe una tendencia natural hacia la especialización de los agentes. Por último, el seguimiento en un enfoque ágil se delega en gran medida a los agentes (confiando en su propia disciplina para abordarlo). Por otra parte, curiosamente cuando se utiliza una metodología tradicional en los planes se suele asumir un modelo de proceso en cascada, lo cual resulta fácil de elaborar y entender (, algo positivo para cerrar un acuerdo con el cliente), pero contraproducente para el control y seguimiento si dicho modelo de proceso no es el más apropiado para el proyecto. AAdemás, auunque las metodologías tradicionales ponen más énfasis en el trabajo colaborativo basado en workflows, no ofrecen mecanismos para su aplicación. Tampoco promueven la asignación ni estimación detallada respecto de esfuerzos estimados o registrados por los agentes. Existe una gran cantidad de herramientas genéricas para gestión de proyectos, sin embargo, éstas presentan inconvenientes importantes para la gestión de tiempos en proyectos software. Por una parte, no consideran las particularidades de un proyecto de software, especialmente no soportan adecuadamente un proceso iterativo e incremental (usando versiones) basado en unidades de trabajo que se implementan de forma colaborativa. Por otra parte, no promueven/soportan un registro actualizado de estimaciones y tiempos invertidos pues en la práctica se usan desconectadas del trabajo de los agentes, los cuales periódicamente deberían actualizar los datos del proyecto. TUNE-UP hace que la planificación y seguimiento del proyecto se integre en el trabajo diario de los agentes. En los últimos años han aparecido diversas herramientas para gestión planificación ágil de proyectos software, las cuales, a diferencia de las herramientas tradicionales sí, que asumen que el proceso de desarrollo es iterativo e incremental y basado en unidades de trabajo más que en actividades. HEntre las herramientas que hemos estudiado erramientasdestacan tales como: Rally (www.rallydev.com), TargetProcess (www.targetprocess.com), ScrumWorks (www.danube.com) y VersionOne (www.versionone.com) . Estas herramientas presentan un especial atractivo respecto de sula interfaz y plataforma Web. S, sin embargo, en cuanto a gestión de tiempos los mecanismos ofrecidos son muy rudimentarios y n. inguna de ellas utiliza Además no tienen el concepto de workflows asociado a cadapara la gestión de unidades de trabajo (usan simplemente un atributo estado, por ejemplo: pendiente, finalizada, etc.). Los trabajos de J. Eder y E. Panagos en el área de sistemas de workflows [4, 5] ilustran el interés en mecanismos para la gestión del tiempo y especificación de restricciones de tiempo. Estos trabajos, si bien no están enmarcados en workflows para procesos de desarrollo de software, resultan complementarios a nuestra propuesta. De hecho, la recolección y cómputo de tiempo ofrecidos por TUNE-UP constituirían la base para poder aplicar dichos mecanismos. Los llamados Process-Centered Software Engineering Environments [6] impulsaron gran actividad de investigación a fines de los 90’s, sin embargo, hasta donde sabemos, dicha línea de investigación desapareció y sus resultados no llegaron a aplicarse en el ámbito industrial. Los trabajos de M. Richter, D. Rombach y F. Maurer respecto del entorno MILOS [14, 15] son representativos de dicha generación de herramientas. De estos trabajos pueden extraerse algunas ideas para una gestión más sofisticada de los tiempos y del soporte para el trabajo de los agentes, por ejemplo, gestión integrada de la planificación y de los workflows, almacenamiento y recuperación de experiencias para ser reutilizadas, ambas en [15], o la combinación de enfoques workflows y groupware para flexibilizar la aplicación de técnicas de workflows en contextos de procesos menos estructurados [3]. No descartamos, que un futuro, evaluemos la incorporación en TUNE-UP de algunas de esas ideas. 6 Conclusiones y trabajo futuro La adecuada gestión de los tiempos en un proyecto permite tomar acciones correctivas oportunas. Tanto el Product Manager como cada uno de los agentes pueden detectar desajustes en el cumplimiento de compromisos observando las holguras. Sin embargo, estos beneficios sólo se alcanzan cuando se dispone de la información actualizada y completa de los tiempos del proyecto. Sin embargo, ePor otra parte, no existe un sistema perfecto en cuanto a precisión ningún mecanismo es perfecto, pues en las estimaciones de tiempos y de disponibilidades de agentes os cálculos intervienen fluyen muchos factores no predecibles ni controlables totalmente, por ejemplo: la fiabilidad de las estimaciones, cambios en los requisitostrabajo no considerado inicialmente y que hay que incluir en la planificación, modificación cambios de prioridades, imprevistos del agente que afectan la disponibilidad del agentesu disponibilidad planificada, etc. Aún con estos inconvenientes, las mejoras en la gestión de tiempos de proyectos reportan beneficios significativos para el desempeño del equipo de desarrollo. Es reconocido que la implantación de una metodología es un proceso largo y que presenta dificultades, tales como la formación y entrenamiento del equipo o la resistencia al cambio por parte de algunos agentes. Una gestión del tiempo como la ofrecida por TUNE-UP conlleva además otros obstáculos:
TUNE-UP ha evolucionado en elun contexto de una PYME de desarrollo de software bajo el marco de varios proyectos universidad-empresa. Comenzamos con la definición e implantación de un proceso dirigido modificación del proceso centrándolo enpor las pruebas de aceptación y al mismo tiempo fuimos fuimos paulatinamente ddesarrollando y utilizando la herramienta de apoyo TUNE-UP Process Tool. Esta herramienta con sus principales funcionalidades para gestión de tiempos comentadas en este artículo lleva 2 años en funcionamiento y satisface las necesidades de desarrollo y mantenimiento de un producto de tamaño considerable (un ERP dirigido al sector socio-sanitario) y de cinco productos más pequeños, extensiones de dicho ERP. En el ERP trabaja un equipo con 32 analistas, 44 testers y 6 programadores, con versiones de alrededor de un mes que incluyen entre 50 y 100 solicitudes de cambios. , y en las extensiones trabajan equipos más pequeños que cuentan con 1 analista, 1 tester y 1 programador. TUNE-UP Process Tool en sí misma es un también otro proyectoproducto de la empresa, que sigue la metodología TUNE-UP y utiliza la herramienta. En el desarrollo de TUNE-UP Process Tool participan 2 programadores. Actualmente tenemos definidos 20 workflows, algunos unos específicos para un determinado producto, otros compartidos entre diferentes productos, unos con pocas actividades, y otros con hasta 30 actividades. Cada producto utiliza alrededor de cinco workflows. Hemos comenzado a implementar refinamientos en el cálculo de holgura de los agentes con la intención de proponer un ordenamiento orientativo de las actividades y fechas límite para el comienzo o finalización de actividades. Sin embargo, de antemano sabemos que en el contexto de desarrollo de software dicha precisión, en la práctica, no constituye una mejora sustancial. Resulta más conveniente y sencillo que los agentes organicen por sí mismos el trabajo que puedan tener en paralelo, llevando a la vez varias actividades y respondiendo con agilidad al dinamismo del proyecto. Referencias
|