Está en la página 1de 4
PSP Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de
PSP
Es un conjunto de prácticas disciplinadas 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 con modelos de
procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a
estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software
Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la guía de trabajo personal para ingenieros de software en
organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos
que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP
tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas
clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles
de la organización, los otros 2 son CMM y TSP.
El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software,
concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando
como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas,
que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software,
esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a
un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de
gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y
avances de los miembros del equipo.
TSP Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en
TSP
Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en equipo para
procesos software.
TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus
procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de
ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad. Está formado por dos
componentes primarios que abarcan distintos aspectos del trabajo en equipo:
Formación del equipo de trabajo.
Gestión del equipo de trabajo.

que tenga como punto de partida la unificación del mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.

El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.

TSP es una solución basada en procesos para resolver problemas de negocio, tales como:

Predictibilidad de costo y tiempo

Mejora de productividad

Ciclos de desarrollo y mejora de calidad de productos.

Características de los grupos eficaces:

Características de los grupos eficaces:

Características de los grupos eficaces:
Características de los grupos eficaces:
 Miembros expertos en papeles de liderazgo y pertenencia.  Relaciones tranquilas y establecidas entre
Miembros expertos en papeles de liderazgo y pertenencia.
Relaciones tranquilas y establecidas entre los miembros.
Los miembros se sienten atraídos por el grupo y son fieles.
Los valores y metas del grupo son los de sus integrantes
Los miembros están motivados por hacer lo que puedan por el grupo.
La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada
miembro a adquirir su pleno potencial.
Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.
Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
Existe una atmósfera de creatividad.
El grupo conoce el “conformismo constructivo” y se sirve de él.
Existe gran motivación para iniciar y recibir las comunicaciones.
Los miembros son flexibles y adaptables en sus metas y actitudes.
Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten
seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la
operación.

Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias.

Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante, además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organización.

Los Roles (responsabilidades) en los equipos en STP son:

Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo.

Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.

Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.

Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.

Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo. Administra el plan de configuración

Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo se reduce.

A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de procesos organizacionales.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:

Lanzamiento

Estrategia

Plan

Requisitos

Diseño

Implementación

Pruebas

Postmortem

Los objetivos que tiene el TSP son:

Maximizar calidad software, minimizar costos.

Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueños de sus procesos y planes.

Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.

Acelerar la mejora continua de monitoreo.

Proveer de una guía para e mejoramiento en organizaciones maduras

Acelerar la mejora continua de monitoreo.  Proveer de una guía para e mejoramiento en organizaciones

Scrum

Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles caracterizados por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.

Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el 'Scrum Master, que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que representa a losstakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con él. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owneridentifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. 1 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint. 2

Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.