Una de las experiencias que QuarkSoft, S.C. ha tenido en el desarrollo de software utilizando metodologías como Personal Software ProcessSM (PSP) y Team Software ProcessSM (TSP), ha sido realizar un proyecto para generar un cambio a la nómina a nivel nacional de una dependencia de gobierno.
Cuando QuarkSoft tomó el proyecto, éste ya llevaba un retraso de varias semanas con respecto a la fecha de inicio planeada, aún no se realizaba la fase de análisis de requerimientos y la fecha de terminación, como en muchos otros casos, no era negociable, por lo que para terminar el proyecto en tiempo y forma, el equipo de desarrollo debía ser muy eficiente.
Los problemas principales que enfrentamos fueron los siguientes:
- • Falta de toma de requerimientos.
• Muy poca gente conocía
la regla del negocio.
• El proyecto de inicio ya contaba con un retraso importante.
• No existía una planeación del proyecto.
• Los participantes por parte del cliente no estaban familiarizados con PSP y TSP.
QuarkSoft decidió tomar esta oportunidad ya que era un claro ejemplo de falta de organización en la administración de un proyecto y era un buen momento para probar si realmente los procesos funcionaban en tiempos de crisis.
Nuestro principal reto era decidir cuáles serían los procesos mínimos a implementar para trabajar bajo esta metodología, tomando en consideración que la mayor parte del equipo no contaba con capacitación en PSP y TSP, requerida para asegurar el control del proyecto.
El proyecto inició con un proceso de lanzamiento como lo plantea TSP. Este lanzamiento consiste de una serie de 9 juntas que se realizan en un periodo de 3 a 4 días con el equipo completo de desarrollo. Los objetivos de cada sesión son los siguientes:
Sesión 1 – Definir objetivos del cliente y del producto a construir.
Sesión 2 – Asignar roles y responsabilidades de cada miembro del equipo.
Sesión 3 – Obtener diseño conceptual del producto, estrategia de desarrollo y lista de principales componentes.
Sesión 4 – Identificar y estructurar actividades necesarias para la construcción.
Sesión 5 – Generar plan de calidad basado en métricas cuantitativas para monitorear la calidad de los componentes creados.
Sesión 6 – Detallar plan de trabajo.
Sesión 7 – Analizar riesgos.
Sesión 8 – Preparar presentación para el cliente con resultados del lanzamiento.
Sesión 9 – Presentar al cliente.
Toda la información que se genera durante el proceso de lanzamiento es necesaria para evaluar si el proyecto es factible en el tiempo que se requiere, además de tener todo un plan de acción detallado a seguir durante el desarrollo del proyecto con metas específicas y, sobre todo, verificables.
Los mecanismos seleccionados para la administración del proyecto fueron los siguientes:
1. Registro del tiempo real invertido por cada ingeniero en el proyecto para compararlo contra el tiempo planeado.
2. Juntas de comunicación entre los integrantes del equipo.
3. Juntas de estatus semanales con el equipo y el cliente.
4. Control y seguimiento cuantitativo del avance de los componentes a nivel individual.
El plan del proyecto contaba con actividades específicas y con tiempos planeados para realizarlas. Los tiempos que se registraron se dividieron en 3 tipos: tiempo real, que es el tiempo que se invirtió al realizar una actividad del plan de trabajo; tiempo de espera, que es el tiempo muerto que un ingeniero tiene por dependencias con actividades de otros ingenieros o por esperar decisiones o actividades por parte del cliente; y, finalmente, el overhead, que se define como el tiempo que se tiene que invertir en actividades que no se planearon pero que se deben realizar para terminar el proyecto. Cada semana se convocaba a una junta de estatus con el objetivo de mantener informado al cliente del avance cuantitativo del proyecto.
Se generó un reporte en el cual se incluía el número total de programas o componentes por módulo, la etapa del ciclo de desarrollo en la que estaban cada uno de ellos y el porcentaje de avance de cada módulo como se muestra en la siguiente tabla:
La tabla nos muestra de manera sencilla y puntual los módulos a desarrollar dentro del proyecto, el número de componentes de los que consta y las diferentes fases por las que tiene que pasar cada componente, desde el análisis hasta las pruebas necesarias para verificar que efectivamente se cumplen con los requerimientos solicitados por el cliente.
PSP propone la realización de revisiones e inspecciones de los componentes al término de las fases de diseño detallado, codificación y pruebas de unidad. El objetivo de las revisiones e inspecciones es que el ingeniero de software identifique mediante un checklist que contiene los puntos más importantes a revisar, el mayor número de defectos posibles en cada componente. Posteriormente se genera una inspección por un ingeniero que es ajeno a la construcción de ese componente y, apoyado por un checklist de inspección, identifica el mayor número posible de defectos que no se detectaron en la revisión. Esto permite que el producto contenga la menor cantidad de defectos cuando se encuentre en la etapa de pruebas de integración de componentes, con lo cual se pretende reducir los tiempos de las fases de pruebas de integración y de sistema, que regularmente dentro de un proyecto de desarrollo de software son impredecibles y costosas.
Adicionalmente, y con el objetivo de mantener un mayor control del proyecto, se incluyó una gráfica para conocer el porcentaje de avance real del equipo con respecto al plan. La gráfica se genera mediante la consolidación de datos que cada uno de los ingenieros de software registra. La información contenida en la gráfica nos brinda la oportunidad de identificar el avance real del proyecto mediante el concepto de valor ganado. Cada una de las actividades planeadas en la construcción de los componentes tiene asignado un determinado valor ganado. El valor ganado del proyecto se obtiene considerando únicamente todas aquellas actividades que han sido concluidas satisfactoriamente y no se asignan valores parciales por actividades inconclusas. El valor ganado se define como el valor otorgado a cada una de las actividades del plan detallado como un porcentaje de su duración con respecto al tiempo total del proyecto.
Sobre el autor
Ricardo Vidrio es director de operaciones de QuarkSoft. Es instructor de PSP autorizado por el SEI y coach de equipos TSP. Es egresado del ITESM y tiene una maestría en Ingeniería de Software en la Universidad Carnegie Mellon.
- Log in to post comments