4.5. PSP/TSP

4.5. PSP/TSP

Team Software Process (TSP) Integración de Equipos de Desarrollo de Alto Rendimiento.

Equipo

Para lograr comprender mejor lo que esta nueva metodología establece, debemos de comprender el concepto de trabajo en equipo o lo que es un equipo.

Una buena definición de equipo seria al menos dos personas que, están trabajando juntos por una meta, objetivo, misión común, donde a cada persona se le ha asignado roles o funciones específicas a desarrollar, y en donde el cumplimiento de la misión requiere algún tipo de dependencia entro los miembros del grupo.

Como se establece en la definición, un equipo se nutre de características como las siguientes:

• Cohesión: es mantener una unión muy fuerte por parte de los integrantes del equipo, logrando así sentirse mas como un todo, que como partes individuales de un todo.

• Metas claras: establecer metas claras y concisas, alcanzables que puedan ayudar al equipo a trabajar para desarrollar algo en concreto sin perderse en detalles que no están dentro del marco de trabajo.

• Retroalimentación: el equipo de trabajo debe de estar continuamente en alimentación del progreso del proyecto o tareas, medir el avance del mismo y pluralizar los resultados, más que individualizarlos.

• Ambiente de trabajo común: es sin duda alguna esencial establecer un muy buen ambiente de trabajo, principalmente basado en la comunicación y en el establecimiento y la definición de cada uno de los roles, así como de las tareas de los miembros del grupo, esto con el fin de evitar mal entendidos y reproches entre los integrantes.

Dentro de esta perspectiva, le team process software, se fomenta en equipos de trabajo para realizar tareas de manera integral y estableciendo pautas para realizar dichas tareas.

Team Process Software (TSP)

El team process software inicio como una herramienta capaz de ayudarle a los equipos de gerentes de proyectos, así como a los ingenieros a organizar y producir proyectos de software a gran escala; se dio a conocer en 1996 y fue desarrollado por el ingeniero y físico Watts S. Humprey, el cual publico el primer reporte técnico en el 2000. Humprey buscaba dotar a sus estudiantes de ingeniería de software, una visión total del ciclo de vida del software.

Esta novedosa herramienta es considerada como una metodología para administrar el trabajo de mejora y desarrollo de los procesos de software, además de garantizar un entorno de trabajo agradable y natural para los equipos. El TSP brinda un conjunto de pasos bien estructurados que indican qué hacer en cada fase del desarrollo del proyecto y muestra cómo conectar cada fase para construir un producto completo, además brinda una ayuda acerca de como conformar equipos para el desarrollo de software de calidad (Humphrey, 2000a; 2000b).

El desarrollo de esta metodología se originó debido a las limitaciones que presentaba PSP (Personal Software Process) a nivel industrial (McAndrews, 2001) ya que el PSP abarca solo las fases de desarrollo de software desde el diseño a las pruebas unitarias y permite tener control del personal mediante la mejora de las habilidades personales, en busca de la reducción de los efectos presentados en los productos y no proporciona la manera de como los ingenieros podrían aplicar estas habilidades en la practica dentro de las organizaciones.

Conociendo estas limitaciones, el ingeniero y físico Watts S. Humprey creó esta metodología con el fin de sufragar los aspectos que quedaban inconclusos por parte de otras metodologías en la evaluación y mejora de procesos. El TSP acopla los principios de los equipos de producto integrados con los métodos de PSP y el modelo CMM, con el fin de producir equipos efectivos de trabajo.

Como se menciono anteriormente, el TSP trabaja en base a la conformación de equipos de trabajo, pero esta forma de laborar no debe de ser tomada a la ligera. Se necesita una planificación de los equipos de trabajo para establecer los roles y las responsabilidades, ya que muchos de los proyectos fallan debido a que los grupos de trabajo se concentran en resolver problemas de manejo de equipos y no en las tareas fundamentales del proyecto. Para ello el TSP se sustenta en el PSP para crear profesionales con cualidades actas para la realización de proyectos muy grandes, dentro de este marco se incluyen los aspectos de generar planes detallados, reunir y usar datos de procesos, medir y gestionar la calidad del producto y definir y usar procesos operacionales.

Objetivos de Team Process Software:

• Maximizar la calidad del software en detrimento de los costos
• Formar equipos que sean capaces de planear y registrar su trabajo, establecer metas bien definidas y sean aptos para realimentar su propio trabajo mediante la medición del mismo.
• Brindar un punto de vista a los gerentes y lideres de proyecto acerca de como monitorear y como motivar a sus equipos de trabajo para sacar el máximo potencial del mismo.
• Establecer una guía para el mejoramiento en organizaciones maduras; asi como acelerar la mejora continua de procesos.

Fases de ciclo de vida de TSP (Team Process Software)

Como toda metodología que busca la continua mejora de procesos, el TSP posee fases en donde se describe una serie de pautas para ayudar a realizar un buen desarrollo de software por parte del equipo de trabajo.

Las fases son:

• Lanzamiento: en esta etapa se establecen las metas a seguir por parte del equipo, se evalúan los objetivos y se dictan los roles y responsabilidades por parte de cada uno de los miembros del equipo. Además se toman en cuenta los requerimientos por parte del cliente y se arma la estrategia a seguir para la culminación del proyecto.
• Estrategia: en esta etapa se crea un modelo conceptual de lo que se requiere para brindar la solución más óptima, estableciendo el desarrollo a seguir, así como las estimaciones de esfuerzo y de riesgos.
• Planeación: una vez desarrollada la estrategia y teniendo en cuenta los procedimientos a seguir y el modelo de la solución del producto, se procede a brindar los roles y las tareas a cada miembro del grupo. En esta etapa se establece el cronograma para la gestión del tiempo y de las tareas que deben de realizarse.
• Requerimientos: para la gestión de los requerimientos se establecen entrevistas con el cliente a fin de delimitar lo que realmente es necesario producir. Los requerimientos son inspeccionados, con el fin de desarrollar un plan de pruebas para el producto terminado.
• Diseño: dentro de las tareas de la etapa de diseño, se establece la elaboración de un diseño de alto nivel, especificando todo los detalles acera de todos los procesos del producto. En esta fase se desarrolla un plan de pruebas de integración.
• Implementación: esta es la fase en la cual el diseño se pasa a nivel de código, se analiza y se hace una revisión exhaustiva en busca de errores. Se compilan y se ejecutan los módulos y unidades, al tiempo que se analiza la calidad de estos.
• Pruebas: en esta etapa el producto ya casi esta terminado, solo falta la integración de los módulos y la documentación para el usuario final, como lo son los manuales de uso. En esta etapa e presentan las diferentes pruebas al sistema con el fin de asegurar su calidad y evaluar el desempeño del equipo de trabajo. 
• Postmorten: se evalúan los análisis de los resultados de las diferentes pruebas y del desempeño del equipo. Se escribe con detalles el reporte del ciclo de vida del proyecto.

Problemas comunes en los equipos

En las organizaciones y para la elaboración de proyectos a menudo se necesita de la formación de equipos para llegar a concluir las tareas. Sin embargo como la mayoría de las personas son diferentes físicamente, también sus personalidades varían de una persona a otra; esto hace que algunas veces se presenten confrontaciones en los puntos de vista de los equipos de trabajo. Entre los problemas más comunes de los equipos de trabajo tenemos:

• Falta de cooperación y compromiso

• Falta de liderazgo

• Falta de confianza

• Revisiones entre colegas inefectivas

• Diferencia en la distribución de cargas de trabajo

• Cabe la pena resaltar que la mayoría de estos problemas son causados por la falta de comunicación y por un mal manejo de situaciones, en las cuales se necesitan estrategias de negociación, cualidades que debería de tener un líder.

Dentro de las estrategias de resolución de conflictos tenemos:

• Evitar/Salirse (Withdrawal): esta técnica se caracteriza porque las personas tienden a evadir el conflicto, aceptar decisiones por defectos y no querer herir los sentimientos de nadie. Aunque esta técnica no es la más óptima, puede ser usada cuando la victoria parece imposible, cuando el conflicto o la disputa es trivial o bien cuando existe una persona en una mejor posición para resolver el conflicto.
• Suavizar/Acomodar: este método concierne en adecuarse a las necesidades de los demás, sin importar las necesidades propias. En esta técnica el acomodador es la persona que sabe cuándo ceder a otros; casi siempre se muestra persuasivo a renunciar a una posición aun cuando no se justifica. Este tipo de persona denominado acomodador nunca es firme, pero siempre se muestra cooperativo. Este enfoque es apropiado cuando existe algo muchos más valioso que las razones del conflicto, por ejemplo la paz; o bien cuando se está en condiciones de ceder hacia el bien común. 

Sin embargo este enfoque es poco probable que brinde los mejores resultados.

• Comprometerse: se presenta cuando existen algunas personas que prefieren lidiar para tratar de encontrar alguna solución al conflicto que trate de satisfacer a todas las partes. Este enfoque se aplica cuando el precio de perder el proyecto es mayor que el precio de los intereses de las partes, esto es cuando las fuerzas de las partes se encuentran muy equilibradas o cuando el tiempo para la resolución del conflicto es apremiante.
• Confrontar/Resolver el problema: se basa en tratar el problema de forma directa, examinando las posibles alternativas. La confrontación es necesaria cuando las personas o las partes no pueden alcanzar una solución, o cuando el problema ha abarcado mucho tiempo sin una aparente solución.

La confrontación debe de realizarse en un lugar aparte y esta debe constituir una conversación objetiva entre las partes o personas involucradas y el mediador

PSP – Personal Software Process

Para hablar de PSP es necesario mencionar que existe un proceso de mejora a nivel de organización el cual está compuesto por tres vértices, y PSP es uno de ellos.

• CMM se enfoca a nivel organizacional
• TSP se enfoca en grupos de trabajo
• PSP se enfoca a nivel personal

El PSP (Personal Software Process o Proceso Personal de Software) es un conjunto de prácticas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones que ya usen modelos de procesos como el CMMI (Capability Maturity Model Integration) o ISO 15504. El PSP fue propuesto por Watts Humphrey en el año 1995 y originalmente estaba dirigido solamente a estudiantes.

El origen del PSP se dio debido a ciertos problemas que se empezaron a presentar en forma recurrente respecto al proceso de desarrollo de software. Por ejemplo:

• Imposibilidad de cumplir con las fechas de entrega
• Defectos detectados en el último minuto
• Incapacidad de demostrar el avance del desarrollo, no hay una medición clara ni exacta
• Esfuerzos duplicados y por ende desperdicio de recursos
• Clientes insatisfechos con el servicio brindado

El pensamiento de Humphrey es que la calidad del software está dada por la calidad de los procesos usados para desarrollar y mantener el software. Dentro de las principales ventajas están:

• Ayuda a estimar, planear y desarrollar sistemas de software
• Orientado a manejar de forma continua las habilidades
• Exige disciplina
• Brinda documentación clara sobre:

1. Registros
2. Procedimientos
3. Formularios y plantillas
4. Estándares

• Disminuye la cantidad de errores
• Permite desarrollar planes precisos
• Da a conocer los pasos a seguir para mejorar la calidad
• Provee de datos para medir la mejora
• Asigna tiempo inclusive en etapas de diseño
• Reduce defectos en el código
• Reduce costos
• Se da un seguimiento a los procesos

Bien es cierto que el PSP es considerado como una guía de trabajo personal para ingenieros de software en organizaciones que utilizan el CMMI, sin embargo también existen algunas desventajas:

• Requiere capturar muchos datos
• Requiere mucho tiempo
• Hay resistencia por parte de los desarrolladores hacia el cambio
• Puede extender los tiempos de desarrollo

El PSP trabaja en una estructura de siete niveles, de lo más básico hasta el control.

PSP 0

 Identificar actividades: definición, secuencia

 Bases mejoras: planeación, evaluación, resultados

 Documentar proceso:

• Actividades (Scripts)
• Tiempos (Logs Time)
• Defectos (Defect Logs)
• Resumir planes, resultados (Proyect plan summary)

PSP 0.1

Registrar tamaño del producto y hacer un histórico:

• Líneas de código
• Function points
• Estandarización de la codificación

Registrar problemas y mejoras de propuestas

PSP 1

Mejora la planeación:

• Con la estimación tamaño del producto (histórico)
• Decidir en base a reportes de pruebas

PSP 1.1

Mejora la planeación:

• Con la estimación de recursos
• Introducción de calendarizar, plasmar el plan con números, un presupuesto. 

PSP 2

Mejora la ejecución: 

• Detección temprana de defectos, en base a la predicción de estos.
• Revisiones de diseño
• Revisiones de código
• Uso de checklists (Listas de verificación) 

PSP 2.1

Mejora el diseño:

• Al hacer uso de formas detalladas de diseño (formas C76, C77)  

PSP 3

Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (ciclico):

• Para aplicación a programas de mayor tamaño
• Registro del seguimiento de asuntos importantes
• Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo

Esta estructura, a su vez, podemos ubicarla en tres grandes etapas o fases:

• Planificación, donde se desarrolla un plan detallado con el objetivo de obtener compromiso por parte de quien realiza el proyecto de desarrollo.
• Desarrollo
• Post-mortem, donde se obtiene y analizan datos para planificaciones y mejoras futuras.

Pasos para Implementar PSP

Los ingenieros deben ser entrenados por un instructor calificado de PSP
La capacitación es sobre grupos o equipos
Requiere un fuerte soporte de administración, en este sentido es necesario que los administradores entiendan el PSP, saber cómo apoyarlos y como monitorear sus avances, sin un adecuado monitoreo los ingenieros caerán otra vez en los malos hábitos
Después de ser bien entrenados y bien administrados, lo que sigue es optimizar la interacción entre equipos y aquí entraría el Team Software Process, el TSP extiende y refina los métodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llega a lo que se le llama un equipo auto-dirigido.