Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos




descargar 68.4 Kb.
títuloTune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos
página1/2
fecha de publicación03.02.2016
tamaño68.4 Kb.
tipoDocumentos
b.se-todo.com > Derecho > Documentos
  1   2

TUNE-UP: Seguimiento de proyectos software dirigido por la gestión de tiempos

María Isabel Marante1, Patricio Letelier1 y Francisco Suárez2
1 Departamento Sistemas Informáticos, Universidad Politécnica de Valencia

2 Aphelion Soluciones Informáticas S.L.
{ mmarante, letelier }@dsic.upv.es, Francisco.Suarez@addinformatica.com

Resumen. El convencimiento de que el proceso de desarrollo de software es determinante para el éxito de un proyecto ha impulsado el interés por estándares para la evaluación y mejora de procesos, junto con la implantación de metodologías. Sin embargo, ni los estándares para proceso software ni las metodologías modernas más populares han conseguido satisfacer totalmente las expectativas de equipos de desarrollo, particularmente en lo relativo a conseguir un mayor control en sus proyectos. TUNE-UP es una metodología nacida de las necesidades de mejora de proceso en una PYME de desarrollo de software. TUNE-UP combina aspectos de metodologías ágiles y tradicionales, pero su característica más innovadora es el énfasis en la gestión de tiempos como factor clave para la planificación y seguimiento del proyecto. Este trabajo ilustra el enfoque ofrecido por TUNE-UP para gestión de tiempos en proyectos software.

Palabras clave: Proceso software, metodologías para desarrollo de software, planificación de proyectos software.

1 Introducción

Un proyecto de desarrollo y/o mantenimiento de software conlleva todas las dificultades de un proyecto de ingeniería, pero además incluye los particulares retos que tiene la construcción de un producto software; complejidad de la implementación, requisitos volátiles, desafíos tecnológicos, desarrollo colaborativo, dificultad para asegurar la calidad, etc. Además, el mercado cada vez exige plazos de entrega más reducidos y presupuestos más ajustados.

En la última década hemos visto un creciente interés por metodologías y estándares asociados al proceso de desarrollo de software. El modelo de referencia CMMI [2] y los estándares SPICE [9] e ISO 90003 [10] han logrado reconocimiento y atraído el interés de empresas desarrolladoras de software. Metodologías Ágiles (p.e. XP [1] y Scrum [16]) y Tradicionales (p.e. RUP [11] y Métrica 3.0 [12]) han animado una interesante discusión respecto de las estrategias para desarrollar software y su , cuestionando la efectividad del proceso software visto desdeen diferentes contextos, (envergadura del proyecto, características del dominio de aplicación, composición del equipo de desarrollo, tecnología utilizada, etc.), confirmáandose que cada proyecto requiere un proceso ajustado a sus necesidades, es decir, deben considerarse: composición del equipo, envergadura del proyecto, características del dominio de aplicación, tecnología utilizada, etc..

Desgraciadamente, la eminente realidad de la gran mayoría de empresas de desarrollo de software es insatisfactoria respecto del éxito de sus proyectos, incluso después de introducir mejoras de proceso siguiendo los estándares o metodologías modernas.

Los proyectos de desarrollo de software suelen enfrentarse durante su realización a un ámbito de trabajo muy cambiante (especialmente en cuanto a las especificaciones del producto y las prioridades de las características solicitadas) e intensivo en comunicación (entre el equipo y con el cliente). Las técnicas y herramientas genéricas para seguimiento de proyectos resultan claramente ineficaces para enfrentar estos desafíos. Las metodologías ágiles destacan esta situación pero la resuelven de una manera excesivamente simplista, utilizando roles muy genéricos (reduciendo así la comunicación necesaria entre diferentes roles) y confiando en la habilidad de cada uno de los miembros del equipo para que, verbalmente y/o con soportes no informatizados [7]en papel o pizarra, realicen el seguimiento continuo del proyecto.

TUNE-UP es una metodología nacida en el trabajo día a día en una PYME de desarrollo de software y con una vocación de mejora continua del proceso. En tres años de aplicación y evolución TUNE-UP ha conseguido una madurez suficiente para ser presentada como una alternativa interesante, al menos enpara contextos de desarrollo conde equipos pequeños. TUNE-UP incorpora elementos de metodologías ágiles y también del ámbito más tradicional. Una de las características clave de TUNE-UP es la planificación y seguimiento del proyecto centrada en la gestión de tiempos. TUNE-UP se inspira en la esencia de la propuesta de PSP (Personal Software Process) [17], donde se destaca que la base del éxito radica en una disciplina de trabajo y productividad individual centrada en la gestión de los compromisos. TUNE-UP ayuda en cada momento del proyecto a responder a la pregunta: ¿conseguiré cumplir con los plazos de entrega de mis tareas? o ¿seremos capaces de cumplir con los plazos de entrega al cliente? Estas simples preguntas inquietan a cualquier gestor o participante de un proyecto. No contar con una respuesta acertada y sobre todo oportuna conlleva implica en la mayoría de los casos graves complicaciones en el proyecto.

TUNE-UP combina de forma pragmática y minimalista tres aspectos: metodologías para desarrollo de software, planificación y seguimiento de proyectos, y aplicación de workflows flexibles para coordinar el intenso trabajo colaborativo que requiere un proyecto software.

El objetivo de este trabajo es ilustrar cómo TUNE-UP aborda la gestión de tiempos contribuyendo a que todos los agentes, y en especial el Product Manager (jefe responsable de desarrollo y mantenimiento de un producto software), tengan mayor control respecto de los plazos y compromisos en un proyecto de desarrollo o mantenimiento de software.

En la sección siguiente se describe brevemente la metodología TUNE-UP. En la sección 3 se detalla la gestión de tiempos en TUNE-UP. Posteriormente en la sección 4 se presenta TUNE-UP Process Tool, una herramienta de apoyo al proceso. En la sección 5, se comentan los trabajos relacionados. Finalmente, en la sección 6 se establecen las conclusiones y se comenta el trabajo futuro.

2 Introducción a TUNE-UP

TUNE-UP es una metodología que incorpora aspectos ágiles y tradicionales con un sentido marcadamente pragmático. TUNE-UP se caracteriza fundamentalmente por combinar los siguientes elementos:

  • Modelo iterativo e incremental para el desarrollo y mantenimiento del software. El trabajo se divide en unidades de trabajo que son asignadas a versiones del producto. Se realizan ciclos cortos de desarrollo, entre 3 y 66 semanas, dependiendo del producto.

  • Workflows flexibles para la coordinación del trabajo asociado a cada unidad de trabajo. Los productos, según sus características, tienen disponible un conjunto de workflows los cuales se asignan a cada una de las unidades de trabajo.

  • Proceso de desarrollo dirigido por las pruebas de aceptación (Test-Driven). La definición de una unidad de trabajo es básicamente la especificación de sus pruebas de aceptación. A partir de allí, todo gira en torno a ellas, se estima el esfuerzo de implementar, diseñar y aplicar dichas pruebas, se diseñan e implementan y luego se aplican para garantizar el éxito de la implementación.

  • Planificación y seguimiento centrados en la gestión del tiempo. Este artículo se centra precisamente en este aspecto.




Fig. 1. Un workflow de desarrollo simple para unidades de trabajo
La Fig.1 ilustra un workflow mínimo para el desarrollo de una unidad de trabajo. Un workflow, en general, incluye debería incluir tres grupos de actividades asociadas a tres fases del procesode:

  • Pre-Asignación: todas las actividades hasta la que se asignación den los RRHH y versión.

  • Preparación: se pueden realizar cuando están asignados los RRHH y una versión, y deberían concluirse antes del comienzo de la versión objetivo en la cual se implementará la unidad de trabajo. Incluye el análisis, las revisiones y estimaciones.

  • Implementación: que se realizan durante la versión objetivo. Incluye la implementación, aplicación de pruebas e implantación.

Las actividades de cada workflow pueden variar significativamente dependiendo de factores tales como: cantidad y especialización de agentes participantes, validaciones o negociaciones predeterminadas con el cliente, características del producto (necesidad de migración, traducción, etc.), niveles y actividades de pruebas (unitarias, de integración, de aceptación, pruebas de regresión, automatización de pruebas), etc.

Cada unidad de trabajo en una iteración del proyecto podría tener su propio workflow. Sin embargo, en la práctica basta con disponer de un reducido conjunto de workflows que permitan cubrir los tipos de unidades de trabajo que se presentan en el proyecto.

Los estados en los que se puede encontrar una actividad (asociada a una unidad de trabajo) son los siguientes:

  • Por Llegar: el agente está asignado a la actividad pero aún no ha recibido la unidad de trabajo pues está en alguna actividad anterior en el workflow.

  • Pendiente: el agente ha recibido la unidad de trabajo en la actividad pero aún no ha comenzado a trabajar en ella.

  • Activa: el agente está trabajando en la actividad (y el sistema está registrando tiempo dedicado a ella).

  • Pausada: el agente ha interrumpido su trabajo en la actividad (y se ha detenido el registro de tiempo.

  • Finalizada: el agente ha terminado la actividad (la unidad de trabajo ha pasado automáticamente a las actividades siguientes en el workflow asociado).

  • Omitida: la actividad ha sido omitida, es decir, se ha decidido no realizar la actividad (se ha saltado hacia adelante en el workflow). A menos que la unidad de trabajo de un salto hacia atrás en el workflow, la unidad de trabajo no pasaría por la actividad.

3 Gestión del tiempo en TUNE-UP

En cualquier tipo de proyecto a priori es interesante contar con una previsión del ordenamiento de las actividades, de los tiempos máximos y mínimos de comienzo y finalización de las actividades, y de las holguras asociadas. Sin embargo, cuando se trata de un proyecto de desarrollo de software, establecer esto puede serresultar muy complejo de establecer y poco puede que en la práctica no resulte todo lo efectivo que fuera de esperar, especialmente si se pretende que los agentes respondan de forma ágil y autónoma ante los cambios cuando los plazos de entrega son reducidos. Así, eEn un proyecto de desarrollo de software soncobran más protagonistasonismo aspectos como los siguientes:

  • Los agentes en general no realizan una actividad de forma ininterrumpida. Frecuentemente es necesario discutir alternativas o analizar elementos previamente no considerados, o simplemente hay cambios en las prioridades. Esto provoca que los agentes detengan actividades y continúen con otras, para posteriormente retomar aquellas detenidas. Además, es inevitable el retrabajo generado por saltos atrás en el procesoworkflow, como por ejemplo desde actividades de pruebas hacia actividades de implementación, cuando se detectan defectosfallos.

  • Para el ordenamiento y restricciones de tiempo entre actividades deben analizarse todas las actividades del proyecto (o incluso de otros proyectos si los recursos son compartidos) pues el trabajo en general es colaborativo y el retraso o anticipación en el trabajo de un agente afectará los tiempos de otros agentestiene complejas consecuencias en los tiempos.

  • Cada iteración o versión del producto suele incluir muchas unidades de trabajo, cada una de ellas siguiendo un workflow específico y siendo realizada por agentes asignados específicos. UnEl grafo que represente la de precedencia de actividades puede así llegar a tener fácilmente cientos o, incluso miles de nodos.

  • Los workflows tienen una expresividad mucho mayor que la abordada en diagramas de red PERT/CPM (, uno de los métodos más populares utilizados en para representar y analizar los tiempos en un planificación de proyectos). Así, dichos métodos deben ser adaptados para poder aplicarse a workflows [92].

Por lo anterior, en TUNE-UP, como una primera aproximación a dichos cálculos de tiempo, trabajamos con lo que denominamos “holgura simple” del agente, la cual sólo considera el tiempo restante con respecto del tiempo disponible. Con la información que se recolecta en TUNE-UP es muy sencillo y rápido calcular dicha holgura simple. Así, cuando la holgura simple de algún agente es negativa (o positiva pero muy pequeña) podemos asegurar que el proyecto está desnivelado. Sin embargo, cuando el agente tiene teóricamente suficiente disponibilidad respecto de las horas restantes, no se puede asegurar que el agente se encuentre en situación de desbalanceo de carga puesto que no estamos considerando que el trabajo depende también de otros agentes. Aún así, la holgura simple nos ha resultado útil como indicador de sobrecarga del agente y síntoma de riesgo en los compromisos de una versión. La gestión del tiempo en TUNE-UP incorpora fundamentalmente las siguientes prácticas:

  • Dividir el trabajo en unidades de trabajo que sean convenientes no sólo de cara a la captura y negociación de requisitos con el cliente sino también para la planificación y seguimiento del proyecto. De forma orientativa una actividad no debería suponer más de una semana de trabajo para un agentelas unidades de trabajo no deben superar una semana de trabajo para una actividad de un agente. Esto facilita el seguimiento continuo del trabajo.

  • Definición del workflow de cada unidad de trabajo previendo el flujo de actividades por las cuales pasará.

  • Asignación de unidades de trabajo a agentes considerando el balanceandoo de la carga de trabajo de los cada agentes.

  • Estimación (y re-estimación) del esfuerzo para realizar las actividades asociadas a la realización de las unidades de trabajo.

  • Registro actualizado del tiempo invertido en actividades. Cada vez que un agente realiza una actividad (y la finaliza) se genera un registro de seguimiento de tiempo, con lo cual, es sencillo distinguir entre el trabajo realizado la primera vez y el posterior retrabajo.

  • Seguimiento contiinuo del estado del proyecto posibilitando las acciones correctivas oportunas.

  • Definición del workflow de cada unidad de trabajo previendo el flujo de actividades por las cuales pasará.

Tabla . Abreviaturas usadas en las formulas de tiempo.

Abreviatura

Significado



Tiempo estimado



Tiempo registrado



Tiempo del período, considerado como una fracción respecto al tiempo en un mes



Tiempo contractual del agente en un mes



Tiempo no considerado en el período, por festivos, ausencias, permisos, bajas, etc.



Tiempo extra del agente en el período



Tiempo restante para finalizar actividades en el período



Tiempo disponible para abordar actividades en el período



Tiempo de holgura simple del agente en el período


La fórmula (1) permite obtener el tiempo restante del agente sumando las diferencias entre tiempo estimado y real para cada actividad asignada y que deba entregarse en el período analizado. La fórmula (2) determina el tiempo disponible del agente en un período a partir del día de hoy. Con el resultado de (1) y (2) conseguimos la holgura simple del agente reflejada en (3).
(1)
(2)
(3)
La fórmula (1) permite obtener el tiempo restante del agente sumando las diferencias entre tiempo estimado y real para cada actividad asignada y que deba entregarse en el período analizado. La fórmula (2) determina el tiempo disponible del agente en un período a partir del día de hoy. Con el resultado de (1) y (2) conseguimos la holgura simple del agente reflejada en (3).

Así, por ejemplo si quisiéramos conocer la holgura simple de un agente en las próximas dos semanas (). Calcularíamos la suma de las diferencias entre estimaciones y registros de tiempo para todas sus actividades que tienen fecha de entrega en las próximas dos semanas, supongamos que esta suma nos da un tiempo restante de 65 hrs (). Suponiendo que el agente trabaja 120 hrs/mes (), y que no existe tiempo a descartar en el período () ni tiempo extra , entonces el tiempo disponible para el agente en el período son 60 hrs (= 0.5*120 – 0 + 0). Así, finalmente la holgura simple para el agente es – 5 hrs, es decir, a día de hoy el agente no podría cumplir con sus compromisos.
La implementación de dichos cálculos de holgura es más compleja pues debe considerar otros elementos (ya incorporados en TUNE-UP Process Tool) como por ejemplo:

  • Si uUn agente puede trabajar en varios productos a la vez, y puede interesar fijar porcentajes de distribución de tiempo del agente ena cada producto. Así, , con lo cual a nivel global el agente puede tener una cierta situación de holgura y ésta que puede ser diferente cuando se analiza a nivel de actividades de un determinado producto. De forma similar puede ser interesante que el agente tenga porcentajes prefijados de distribución de tiempo respecto de las actividades, es decir, su situación de holgura puede ser incluso relativa a una determinada actividad.

  • Cuando el tiempo registrado sobrepasa al tiempo estimado el cálculo de tiempo restante se invalida pues se considerarían tiempo restante negativo para una actividad. En estos casos se descarta dicho tiempo y se alerta de la situación para que el agente proceda a una re-estimación.

  • La flexibilidad del workflow de la unidad de trabajo obliga a hacer reajustes de estado de las actividades cuando se produce re-asignación del agente de una actividad, saltos hacia atrás o hacia adelante en el workflow o incluso cambio del workflow de una unidad de trabajo.

  • Todas las actividades no finalizadas y con fecha de entrega anterior al período consultado deben ser consideradas en dicho período como actividades retrasadas.


Así, con estos mecanismos de cálculo, un agente puede en cualquier momento visualizar su estado de holgura con respecto a una cierta fecha futura, y en particular con respecto a las fechas de término de la versión de algún producto. El Product Manager puede también visualizar la situación de holgura de cada agente y efectuar las acciones pertinentes, por ejemplo: reasignación de actividades entre agentes, reasignación de versiones de las unidades de trabajo, cambios en fechas de término de versión, cambios en distribución de tiempos de los agentes a los productos, etc.
  1   2

similar:

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconTaller de gestion de proyectos

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconY desde Junio 11 de 2007 se emitió por la emisora ondas e la montañA,...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconSe trata de un documental de observación natural, dirigido por el...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconEste libro va dirigido al gran público y, por consiguiente, no se...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconTransversalización de los proyectos a las áreas por grado

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconEste pequeño libro está, sin ninguna vergüenza, dirigido a la gente...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconEs un proyecto de Ley por medio del cual se incentiva el uso de software...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconInforme de gestion por depenencias

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconLa Chinchilla ha sido apreciada desde tiempos previos a la conquista...

Tune-up: Seguimiento de proyectos software dirigido por la gestión de tiempos iconEn Colombia la educación ha sufrido cambios considerables en los...




Todos los derechos reservados. Copyright © 2019
contactos
b.se-todo.com