Personal Software Process: Difference between revisions
| (One intermediate revision by the same user not shown) | |||
| Line 27: | Line 27: | ||
<div class="bok-aviso"> | <div class="bok-aviso"> | ||
'''Aplicar PSP en organizaciones sin la cultura de medición necesaria.''' El PSP requiere que los ingenieros lleven registros individuales detallados de su trabajo. Sin una cultura de psicológica | '''Aplicar PSP en organizaciones sin la cultura de medición necesaria.''' El PSP requiere que los ingenieros lleven registros individuales detallados de su trabajo. Sin una cultura de seguridad psicológica y mejora continua, el registro de tiempos y defectos puede percibirse como un sistema de vigilancia en lugar de como una herramienta de mejora personal, y los datos dejan de ser fiables. | ||
</div> | </div> | ||
== Referencias == | == Referencias == | ||
Humphrey, Watts S. (1995). ''A Discipline for Software Engineering''. Addison-Wesley. | * Humphrey, Watts S. (1995). ''A Discipline for Software Engineering''. Addison-Wesley. | ||
== Véase también == | == Véase también == | ||
Latest revision as of 09:31, 20 May 2026
El Personal Software Process (PSP, proceso personal de software) es un conjunto de prácticas para la medición y mejora personal de los ingenieros de software: sus métodos de trabajo, su rendimiento y la calidad del código que producen. Fue desarrollado por Watts Humphrey en el SEI (Software Engineering Institute) de la Universidad Carnegie Mellon y publicado en su libro A Discipline for Software Engineering (1995).
Está alineado y diseñado para emplearse en organizaciones que trabajan con modelos de procesos CMMI o ISO 15504, aunque sus principios de medición personal son aplicables en cualquier contexto.
Fundamentos
El PSP parte de la premisa de que la calidad del software depende en última instancia de las personas que lo construyen. Para mejorar la calidad del producto, hay que mejorar los procesos de trabajo individuales: cómo cada ingeniero planifica, estima, diseña, codifica y prueba.
El PSP propone que cada ingeniero lleve un registro personal de:
- El tiempo que invierte en cada fase del trabajo (tiempo real vs. tiempo ideal).
- Los defectos que introduce y cuándo los detecta (en codificación, en revisión, en pruebas).
- El tamaño del código que produce.
Con estos datos, el ingeniero puede calibrar sus propias estimaciones, entender en qué fases introduce más defectos y mejorar de forma continua.
Relación con el trabajo en equipo
El PSP tiene una versión para equipos pequeños denominada TSP (Team Software Process), también desarrollada por Humphrey. Mientras PSP trabaja sobre la mejora individual, TSP coordina equipos de 2 a 20 personas aplicando principios similares de medición y proceso.
PSP y tiempo ideal
Una de las aportaciones del PSP al vocabulario de la gestión ágil es la distinción entre tiempo ideal (tiempo de trabajo efectivo, sin interrupciones) y tiempo real (jornada laboral completa). El PSP lo denomina Delta Time. Esta distinción, adoptada por la gestión ágil de proyectos, es la base de la estimación en tiempo ideal que Scrum técnico usa para planificar sprints.
Error frecuente
Aplicar PSP en organizaciones sin la cultura de medición necesaria. El PSP requiere que los ingenieros lleven registros individuales detallados de su trabajo. Sin una cultura de seguridad psicológica y mejora continua, el registro de tiempos y defectos puede percibirse como un sistema de vigilancia en lugar de como una herramienta de mejora personal, y los datos dejan de ser fiables.
Referencias
- Humphrey, Watts S. (1995). A Discipline for Software Engineering. Addison-Wesley.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.