PSP, TSP, Scrum

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 4

PSP

Es un conjunto de prcticas disciplinadas para la gestin 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 diseado 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 gua 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 medicin 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 obsesin por la toma de datos y elaboracin 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 vrtices donde descansa un proceso de mejora que trabaja sobre 3 niveles
de la organizacin, 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,
concentrndose en las practicas de trabajo de los ingenieros en una forma individual, enseando
como manejar la calidad desde el principio de un producto. PSP son nuestras propias mtricas,
que permiten estructurar y ordenar nuestro trabajo del da a da (no solo de desarrollo de software,
esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, adems puede ser llevado a
un trabajo en equipo TSP (Team Process Software), el cual es comandado por un sistema de
gestin de la configuracin y por supuesto, un Jefe de Proyecto quien evala los resultados y
avances de los miembros del equipo.

TSP

Team Software Process (TSP) es un mtodo 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 organizacin pueda establecer prcticas de
ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad. Est formado por dos
componentes primarios que abarcan distintos aspectos del trabajo en equipo:

Formacin del equipo de trabajo.


Gestin del equipo de trabajo.

Existen diferentes metodologas para la mejora de procesos, la mayora de ellas se basa en la mejora
de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un equipo
que tenga como punto de partida la unificacin 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 organizacin pueda establecer prcticas de ingeniera avanzadas y
as obtener productos eficientes, fiables y de calidad.

TSP es una solucin 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.

Caractersticas de los grupos eficaces:

Miembros expertos en papeles de liderazgo y pertenencia.


Relaciones tranquilas y establecidas entre los miembros.
Los miembros se sienten atrados por el grupo y son fieles.
Los valores y metas del grupo son los de sus integrantes
Los miembros estn motivados por hacer lo que puedan por el grupo.
La interaccin 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 atmsfera de creatividad.
El grupo conoce el conformismo constructivo y se sirve de l.
Existe gran motivacin 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 filosofa de la
operacin.

Sus orgenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor)
tena 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 estimacin y la reduccin
de los defectos introducidos en los productos sin afectar a su productividad, pero PSP slo se
enfocaba en las fases de desarrollo de software (diseo y pruebas unitarias); la aplicacin que lo
ingenieros hicieron del PSP dentro de las empresas resulto en prcticas no satisfactorias.

Por tal motivo, Watts Humphrey desarroll el TSP, el cual consideraba como parte importante,
adems de lo previsto por el PSP, los requisitos, las pruebas de integracin, la documentacin y
otras actividades tpicas en todo proyecto de desarrollo, de igual manera inclua actividades como
los roles de equipo, interrelaciones dentro de la organizacin y la definicin de un proceso de equipo
para ser utilizado dentro de los procesos existentes en la organizacin.
Los Roles (responsabilidades) en los equipos en STP son:

Lder 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: Gua al equipo en el diseo y desarrollo del producto.
Gestor de Planificacin: Apoya y gua al equipo en la planificacin 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 estndares 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 tecnologa y en las necesidades de
apoyo administrativo. Administra el plan de configuracin

Es necesario que los ingenieros que usan TSP estn 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 ms corto, el ciclo completo se reduce.

A diferencia de otros mtodos, TSP mejora el desempeo 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 nmero de ciclos. Dentro de cada ciclo se realiza:

Lanzamiento
Estrategia
Plan
Requisitos
Diseo
Implementacin
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 sueos de sus procesos y planes.
Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como
ayudarlos a alcanzar su mxima productividad.
Acelerar la mejora continua de monitoreo.
Proveer de una gua para e mejoramiento en organizaciones maduras

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 planificacin y ejecucin


completa del producto.
Basar la calidad del resultado ms en el conocimiento tcito 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 prcticas 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 aplicacin 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 dems 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 ms corta posible), el equipo crea un incremento de software potencialmente
entregable (utilizable). El conjunto de caractersticas 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 reunin
de Sprint Planning. Durante esta reunin, 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 estn congelados durante el sprint.2
Scrum permite la creacin de equipos auto organizados impulsando la co-localizacin
de todos los miembros del equipo, y la comunicacin 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 desafos impredecibles no pueden ser
fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum
adopta una aproximacin pragmtica, aceptando que el problema no puede ser
completamente entendido o definido, y centrndose en maximizar la capacidad del
equipo de entregar rpidamente y responder a requisitos emergentes.

También podría gustarte

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy