Treball en equip

Anuncio
Enginyeria del Software III
El trabajo en equipo
Nov.
2007
Esperança Amengual
1
Contenido
El trabajo en equipo
Introducción
El compromiso
Problemas
Tratamiento de la presión
Grupos y equipos
Tamaño del equipo
Propiedades de un equipo eficaz
Consolidación de equipos
Etapas de formación del equipo
Modelo de crecimiento de un equipo
Atributos del equipo
Team Software Process
Relación entre CMM/CMMI, TSP y PSP
2
1
Introducción
La mayor parte del software industrial está
desarrollado por equipos
Para ser un ingeniero más efectivo, es
necesario ser capaz de trabajar en equipo
La práctica de trabajo en equipo requiere
experiencia y un conjunto específico de
técnicas y métodos
Los equipos no se producen por casualidad, y
los buenos resultados del equipo no son por
accidente
Los equipos son algo más que un conjunto de
individuos de talento
3
El compromiso
En un equipo todos y cada uno de sus miembros deben
comprometerse a realizar su correspondiente tarea o parte del
trabajo dentro del proyecto
"Un compromiso se asume cuando una persona se hace
responsable de realizar algo para otra"
El proceso de compromiso se asienta en los siguientes principios:
Una actitud personal de compromiso plenamente asumida
Una cultura de equipo/organización para poder aceptar y cumplir,
tanto los grandes como los pequeños compromisos
La cultura del compromiso debe estar respaldada desde la
dirección del equipo que es quien debe asumir el compromiso de
máximo nivel
Completa y satisfactoria revisión formal del trabajo a realizar y
elaboración de los acuerdos de compromiso
Existencia de un mecanismo de supervisión de que las revisiones
han concluido satisfactoriamente y que los acuerdos se han
finalizado de forma adecuada
4
2
El compromiso
El proceso de compromiso necesita
Un plan de proyecto documentado con estimaciones
recursos
esfuerzo
coste
Un calendario razonable basado en estas estimaciones
Todas las tareas del trabajo deben estar definidas y
acordadas por todas las partes implicadas
Un sistema de gestión que permita sacar a la luz los aspectos
conflictivos y resolverlos lo antes posible:
revisiones de los planes del proyecto
control de los progresos en las fases del proyecto
reconciliación de los dos ámbitos en los que los calendarios
entran en conflicto
Cambio radical de comportamiento: deben aflorar las
discusiones y contradicciones de una manera natural y
como una forma habitual de trabajo
5
El trabajo en equipo. Problemas
Es bastante común tener problemas cuando se
realiza trabajo en equipo
Los miembros de un equipo tienen diferentes
papeles y objetivos
Cuando los proyectos software fracasan,
generalmente es debido a problemas del
trabajo en equipo y no a aspectos técnicos
Él éxito o fracaso de un proyecto raramente es debido a
aspectos técnicos. Si el proyecto se ha echado a perder,
serán los problemas de interacción humana, no técnicos, los
que lo originan
DeMarco
6
3
El trabajo en equipo. Problemas
Un problema significativo es la incapacidad de los
equipos de software para tratar la presión,
especialmente la presión de cumplir un calendario de
desarrollo dinámico
Los equipos responden a esta presión:
tomando atajos
utilizando métodos deficientes
especulando sobre un lenguaje, herramienta o técnica nuevas
(para ellos)
Antes de comenzar un trabajo no sabemos
exactamente en lo que estamos implicados
Después de hacer un plan y haber comenzado nos
sentimos aliviados
7
El trabajo en equipo. Tratamiento de la presión
Antes de realizar una tarea se necesita analizar si se puede hacer
o no
Los equipos necesitan conocer como trabajar eficazmente y
obtener productos de calidad
Los calendarios irrealistas son el origen principal de los problemas
de los proyectos de software
Cuando son capaces de gestionar su trabajo, los equipos están
mucho más cualificados para hacer un trabajo de calidad
Guiar a los equipos mediante una estrategia y un proceso de
planificación:
analizar el trabajo
idear una estrategia para realizarlo
estimar el tamaño de los productos
realizar la planificación
8
4
Grupos y equipos
Un grupo simplemente es un conjunto de personas que
se agrupan en función de ciertas similitudes
Un grupo se convierte en un equipo cuando:
Todos sus miembros tienen el mismo objetivo
Existe una organización para trabajar juntos
Existe una función del equipo que requiere el esfuerzo
cooperativo de todos
Un grupo está compuesto por dos personas como mínimo:
que dirigen sus esfuerzos hacia una meta/objetivo/misión común
en el que cada uno de sus miembros se les ha asignado unos
papeles o funciones específicas a realizar
en el que el cumplimiento de la misión requiere alguna forma de
dependencia entre los miembros del grupo
Dyer
9
Grupos y equipos
Cummings establece tres condiciones básicas que se deben
cumplir para que un grupo funcione satisfactoriamente como
equipo:
Las tareas a desarrollar deben estar claras y delimitadas
las labores del equipo estarán definidas explícitamente
el trabajo es relevante para todo el equipo
cada uno de sus miembros sabe lo que debe hacer
El equipo está claramente identificado
los miembros conocen su ámbito, quién forma y quién no forma parte del equipo
cada persona del equipo es conocida por los restantes miembros del mismo
el trabajo de cada uno es conocido
todos conocen el papel en el equipo que cada uno presenta
El equipo tiene el control de sus tareas
los miembros conocen lo que han de hacer, cómo hacerlo, cuándo hacerlo, y
cuándo las tareas han finalizado
saben que son los responsable del trabajo y controlan los procesos que utilizan
tienen la capacidad para realizar su labor, y saben que ninguna otra persona está
encargada de hacerlo
10
5
Tamaño del equipo
Aunque existen pocas investigaciones sobre los
efectos del tamaño del equipo de software, diferentes
experiencias han mostrado que:
los equipos de cuatro a ocho ingenieros son probablemente
los más eficaces
con menos de cuatro miembros, no hay las suficientes
personas para tratar adecuadamente los diferentes papeles
necesarios dentro de un equipo
Con equipos de más de ocho personas, es bastante
difícil para el equipo desarrollar las estrechas
relaciones necesarias para consolidar el equipo
11
Propiedades de un equipo eficaz
Cohesión
Se refiere a la fuerte unión de los miembros del
equipo en un grupo de trabajo unificado que actúa
como una unidad
Los miembros del equipo se comunican libre y
frecuentemente
Comparten espacio físico común, pasan gran
cantidad de tiempo juntos y cooperan
amigablemente
En grupos menos cohesionados, los miembros tienden a
funcionar como elementos individuales. Tienen dificultad en
comprometerse y no tienen valores y metas comunes
12
6
Propiedades de un equipo eficaz
Metas desafiantes
Elemento crítico de los equipos consolidados
Deben ser específicas y mensurables
Ejemplos: planes detallados, la fijación de
resultados, los objetivos de calidad, los hitos del
calendario...
Debe hacerse seguimiento de las metas y la
visualización del progreso para que los miembros
del equipo puedan ver como van progresando
Los equipos que tienen metas mensurables son más
eficaces que aquellos que no las tienen (Mohrman)
Las metas del equipo deben representar un desafío
significativo (Katzenbach)
13
Propiedades de un equipo eficaz
Realimentación
Los miembros de un equipo deben ser
capaces también de distinguir sus
resultados personales de los del equipo
como conjunto
Los equipos eficaces son conscientes de
sus resultados y pueden ver el progreso
que están haciendo para alcanzar sus
metas (Stevens)
14
7
Propiedades de un equipo eficaz
Marco común de trabajo
Todos los miembros del equipo deben percibir que
las metas son alcanzables, deben entender sus
papeles y responsabilidades, y deben estar de
acuerdo en como llevarlas a cabo
Además, deben conocer:
¿Qué tareas deben hacerse?
¿Cuándo?
¿En qué orden?
¿Por quién?
Los miembros del equipo necesitan ver como
conseguir la meta y conocer lo que se espera de
ellos” (Shaw)
15
Consolidación de equipos
Proceso iterativo que comienza con varios ingenieros,
cada uno de los cuales tiene una percepción diferente
de lo que se debe hacer
Luego, a través de una serie de etapas, convergen en
un punto de vista y resultado comunes
A medida que los miembros del equipo aumentan su
percepción común del producto que se ha de construir,
también convergen en un enfoque común de cómo
hacer el trabajo
El conflicto y el desacuerdo son partes naturales de
este proceso de convergencia. Es así como el equipo
identifica los aspectos para seguir trabajando, y es lo
que genera el proceso creativo que se llama diseño
16
8
Etapas de formación del equipo
Metas
Definir y aceptar un conjunto de metas comunes
Para facilitar la aceptación por todos los miembros es
conveniente que todos ellos participen en la definición de las
metas
Roles
Se establecen los roles de los miembros del equipo
líder del equipo
responsable de desarrollo
responsable de planificación
responsable de la calidad y del proceso
responsable del soporte
Estos roles deben distribuirse entre todos los ingenieros y no
ser tratados por uno sólo o dos de ellos
17
Etapas de formación del equipo
Planes
Estrategia para alcanzar las metas
La primera decisión es cómo dividir la labor total en las partes
del ciclo de desarrollo
Posteriormente se decide el contenido funcional de cada ciclo,
su tamaño esperado, y los modos de integrar y probar estas
partes para obtener un producto acabado
Después se deciden y documentan los procesos que se
utilizarán para hacer el trabajo.
Estimación de los los tamaños de los productos de cada ciclo
Tiempo
Orden de este trabajo
Personas que intervendrán en cada etapa
18
9
Modelo de crecimiento de un equipo
Se refiere a las etapas de crecimiento por las que pasa
un equipo desde su creación hasta su consolidación
Formación: concienciación de pertenencia al equipo. En ella
se produce el conocimiento por parte de cada miembro de los
roles y tareas del resto
Conmoción: se caracteriza por el conflicto. En ella se clarifican
los roles y responsabilidades comprendiendo el objetivo final y
la manera de trabajar juntos
Normalización: se caracteriza por la cooperación. En ella todo
el trabajo se realiza conjuntamente. Sobresale la identidad de
grupo por encima de las peculiaridades personales de cada
miembro
Actuación: se caracteriza por la productividad. En ella se
consigue una alta productividad y creatividad.
Terminación: se caracteriza por la separación. El equipo
después de finalizar su trabajo se deshace.
19
Atributos del equipo (I)
Para que un equipo funcione de una manera
provechosa debe poseer un conjunto de atributos que
le aseguren el éxito de su trabajo:
Claridad en los objetivos
Plan de mejora continua
Roles claramente definidos
Comunicación clara
Trato agradable en el equipo
Procedimientos de decisión bien definidos
Participación equilibrada
Reglas básicas establecidas
20
10
Atributos del equipo (II)
Para que un equipo funcione de una manera
provechosa debe poseer un conjunto de atributos que
le aseguren el éxito de su trabajo:
Concienciación del proceso del grupo: todos los
miembros entiendes sus funciones y
responsabilidades específicas, a la vez que
entienden como trabaja el equipo conjuntamente.
Evalúan su proceso y lo mejoran
Utilización del método científico: se basa en la
utilización de datos válidos para la toma de
decisiones y resolución de problemas. Por tanto:
las opiniones se basarán en datos. Se utilizarán
herramientas estadísticas para recopilar y analizar
la información
21
Team Software Process (TSP). Definición
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
TSP se basa en los siguientes principios:
Los técnicos conocen muchas cosas sobre su trabajo y pueden realizar las
mejores planificaciones. Cuando son ellos quienes planifican su propio
trabajo, se encuentran comprometidos con el plan
Un seguimiento preciso de un proyecto requiere planes bien detallados y
datos precisos. Únicamente el personal que realiza el trabajo es capaz de
recoger con precisión dichos datos
Para minimizar el tiempo del proyecto, los ingenieros deben equilibrar su
carga de trabajo
Para maximizar la productividad, el primer foco de atención debe ser la
calidad
TSP está formado por dos componentes primarios bien diferenciados
que abarcan distintos aspectos del trabajo en equipo y que pueden
observarse de manera resumida en la próxima figura, que son:
Formación del equipo de trabajo
Gestión del equipo de trabajo
22
11
Team Software Process (TSP). Historia
En la década de los 80, Watts Humprey guió el
desarrollo del Capability Maturity Model for Software
(SW-CMM)
Con el fin de ayudar en la aplicación del modelo a las
pequeñas organizaciones, Humprey se planteó el reto
de aplicar SW-CMM a la menor organización posible:
una organización de un solo individuo
La conclusión fue que el uso de las prácticas de SWCMM es aplicable a individuales. El proceso resultante
fue el Personal Software Process (PSP)
Posteriormente se desarrollaron métodos académicos
para enseñar PSP
Una vez que los ingenieros empezaron a utilizar PSP
en su trabajo, se descubrió que era necesario un
entorno de soporte
Entonces Humprey desarrollo el proceso TSP para
construir i mantener equipos efectivos
23
Team Software Process (TSP). Características
Se puede usar para todos los aspectos del desarrollo
de software: definición y establecimiento de requisitos,
diseño, implementación, pruebas y mantenimiento
Da soporte a equipos multidisciplinarios que pueden
variar en tamaño desde dos a centenares de
ingenieros
Puede usarse para desarrollar productos de diferentes
tipos, desde sistemas de control empotrados hasta
aplicaciones comerciales cliente-servidor de desktop
TSP se basa en el proceso PSP (Personal Software
Process)
PSP se utiliza como guía del trabajo individual de cada
ingeniero
Enseña a los ingenieros a medir su trabajo y a utilizar los
datos de las mediciones para mejorar su rendimiento
TSP sirve de guía para el equipo creando un entorno en el
que los miembros del equipo pueden utilizar PSP
24
12
Gestión
del equipo
Establecimiento de objetivos
Asignación de roles
Adaptación del proceso
Planificación detallada
Disciplina del proceso
Medidas de rendimiento
Habilidades para la estimación
y para la planificación
Habilidades de gestión de calidad
Habilidades
de los miembros
del equipo
PSP
Formación
del equipo
Comunicación del equipo
Coordinación del equipo
Pruebas del proyecto
Análisis de riesgos
TSP
Relación entre PSP y TSP
25
Relación entre PSP y TSP
Según Humphrey, para que una organización mejore el proceso
software y desarrolle productos de calidad, debe contemplar
diferentes aproximaciones de mejora del proceso, todas ellas
complementarias:
La organización debe llevar a cabo sus procesos según la forma
establecida en un modelo. Humphrey propone utilizar el modelo CMM
Los ingenieros deben desarrollar sus capacidades individuales de una
forma eficiente y controlada. El autor propone utilizar los principios del
PSP
El trabajo debe desarrollarse dentro de un equipo formado y con una
capacidad de trabajo conjunta. El autor propone utilizar los principios
del TSP
De manera conjunta PSP y TSP permiten definir y mantener
equipos que consideren las capacidades individuales de sus
miembros.
Si bien esta capacidad individual es crítica, ya que cada instrucción de
un módulo ha sido realizada por un único ingeniero de software
También es cierto que un producto software es el resultado de un
trabajo en equipo, formado por un conjunto de subproductos o
módulos que han sido diseñados, construidos, integrados, probados y
mantenidos por un equipo de ingenieros de software cuyas
habilidades, capacidades y disciplina, contribuirán en el éxito del
proyecto
26
13
TSP Launch
El TSP launch es un proceso de cuatro días que sirve para guiar
al equipo en la producción de un plan de trabajo
Mientras que el objetivo ostensible de este proceso es producir el
plan del equipo, el objetivo principal es producir un equipo firme
Proporciona los fundamentos necesarios para construir un equipo
auto-dirigido y motivado con las siguientes características:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Todos los miembros tienen un fuerte sentimiento de pertenecer al
equipo
Todos están de acuerdo con los objetivos comunes del equipo
El equipo es dueño de sus procesos y de la planificación de los
mismos
Cada miembro del equipo tiene las habilidades necesarias para
elaborar una planificación y la disciplina para llevarla a cabo
Todos los miembros del equipo se dedican a realizar un trabajo de
calidad
El equipo está de acuerdo en realizar el trabajo
Este acuerdo es importante para el equipo
El acuerdo se hizo voluntariamente y es visible (lleva un plan asociado)
El acuerdo está estrechamente ligado al equipo y a cada uno de sus
miembros. Esto requiere que todos los miembros del equipo participen
en la elaboración y negociación de la planificación, así como en su
gestión
27
TSP Launch
28
14
TSP Launch
Meeting 1: The Opening Management Meeting
Su objetivo es que el equipo entienda el trabajo
requerido
Con el equipo se reúnen un responsable de
marketing y de gestión
Marketing: descripción de las necesidades del producto
Gestión: necesidades empresariales y recursos disponibles
Oportunidad para motivar al equipo
El equipo tiene la oportunidad de plantear cuestiones
sobre las necesidades empresariales o del producto
En las siete reuniones siguientes, el equipo
desarrolla un plan para satisfacer las necesidades
empresariales
Ayuda a cumplir las condiciones 2 (acuerdo de un
objetivo común) y 7 (el acuerdo es importante para el
equipo) de las 9 condiciones para un equipo autodirigido y motivado
29
TSP Launch
Meeting 2: Team Goals and Roles
Identificación de objetivos y selección de roles
El objetivo principal es asegurar que los objetivos del
equipo están en línea con los objetivos de gestión, a
la vez que son significativos para cada uno de los
miembros del equipo
Después se seleccionan los roles de cada miembro
del equipo
TSP propone ocho roles estándar
La selección de roles ayuda a establecer la condición
1: Todos los miembros tienen un fuerte sentimiento
de pertenecer al equipo
30
15
TSP Launch
Meeting 3: Project Strategy and Support
El equipo decide la estrategia de desarrollo
Suele empezar con una revisión del diseño conceptual del
producto y una discusión acerca de las diferentes maneras de
construirlo
Se define el proceso detallado a seguir y se determinan las
herramientas de soporte del mismo
Finalmente se elabora una lista con los productos a producir
Se consideran la condiciones 3 (el equipo es propietario del
proceso y de su planificación) y 8 (acuerdo voluntario y visible)
Meeting 4: The Overall Team Plan
Se desarrolla la planificación del equipo realizando:
la estimación del tamaño del tamaño de los productos a realizar
la identificación de las tareas necesarias para realizar el trabajo y
de su esfuerzo
la definición de una planificación del equipo semana a semana
Continua el proceso de construcción del equipo considerando
las condiciones 3, 6 (acuerdo en la realización del trabajo) y 8
31
TSP Launch
Meeting 5: Making the Quality Plan
El equipo define un plan para satisfacer sus objetivos de calidad
El equipo se asegura de que las tareas necesarias para
asegurar sus objetivos de calidad se han incluido en la
planificación
Suele tratarse de tareas bastante mecánicas de estimación de
defectos introducidos en cada fase y la corrección de los mismos
El plan de calidad proporciona la base para hacer este
seguimiento de la calidad
Se considera la condición 5 (realización de un trabajo de
calidad)
Meeting 6: Balancing the Team Plan
Cada miembro del equipo, partiendo de la planificación global,
elabora su planificación individual para los meses siguientes
Así se refinan las estimaciones del equipo utilizando datos
históricos, dividiendo las actividades a realizar en tareas y
refinando la disponibilidad temporal
Los planes individuales se consolidad en el plan del equipo
32
16
TSP Launch
Meeting 7: Project Risk Analysis
El equipo lleva a cabo la identificación y el análisis
de los mayores riegos del proyecto
Se identifican los riesgos y el impacto de los mismos
Se definen planes de mitigación y contingencia para
los riesgos más prioritarios
Los riesgos se documentan en la planificación del
equipo y se asignan a sus miembros para realizar el
seguimiento
Esta asignación de responsabilidad cumple con la
condición 9 (el acuerdo está estrechamente ligado al
equipo)
33
TSP Launch
Meeting 8: Launch Report Preparation
Desarrollo de una presentación de la planificación del equipo a
los responsables de gestión
En este punto, el equipo:
se ha constituido como una unidad cohesiva
ha establecido una planificación que cumple con las necesidades
empresariales y del cliente con una solución técnica factible
está de acuerdo con la estrategia y el proceso para desarrollar el
producto
dispone de un plan detallado que sirve de guía para realizar el
trabajo y el seguimiento del mismo
Además, todos los miembros del equipo:
conocen al responsable de cada tarea y área
entienden y están de acuerdo con los objetivos de calidad
34
17
TSP Launch
Meeting 9: Reviewing the Plan with Management
El equipo presenta la planificación a los responsables de
gestión para su aprobación
Descripción del producto a desarrollar
Cómo se desarrollará
Cuándo se espera finalizar
El porqué de la estrategia seleccionada
Descripción del proyecto en una terminología para los
responsables de gestión
Identificación de hitos clave
Resumen de las necesidades de recursos
Listado de los riesgos importantes
Si no se han cumplido los objetivos gestión, el equipo presenta
uno o más planes alternativos
Al final del meeting 9, se ha completado todo el proceso y se
han cumplido las 9 condiciones necesarias que todo equipo
auto-dirigido y motivado debe cumplir
35
TSP Launch
36
18
TSP Launch
The Launch Postmortem
Se celebra al final del meeting 9
Se trata de una breve sesión en donde se revisa
todo el proceso seguido y se discute la mejora del
mismo
También sirve para asegurar que toda la
planificación realizada y los datos del proceso se han
documentado de manera apropiada
37
TSP: Gestión del equipo de trabajo
Una vez se ha establecido el plan, éste
solamente debe seguirse
Para solucionar los problemas de una
planificación imprecisa o cambiante se realiza
planificación dinámica
Los miembros del equipo continuamente actualizan
la planificación para reflejar los cambios
"Si no puedes planificar de manera precisa, hazlo a
menudo"
El objetivo es disponer siempre de una
planificación precisa que represente el trabajo
por hacer y la manera en que se realizará: TSP
relaunch
38
19
TSP relaunch
El proceso TSP sigue una estrategia iterativa
Cada fase o ciclo puede planificarse en base a los
resultados del ciclo anterior
Estás replanificaciones son necesarias para
actualizar los planes detallados
En la TSP launch los equipos realizan una
planificación global y una planificación detallada
para los próximos tres o cuatro meses
Una vez se ha completado una fase o ciclo, se
revisa la planificación global y, si se considera
necesario, se realiza una nueva planificación
detallada
39
TSP relaunch
40
20
TSP: Seguimiento del proceso
Seguir un proceso es una cuestión de motivación,
preparación y soporte
El comportamiento que TSP requiere es de tres tipos:
seguimiento del proceso definido
recogida de datos
utilización de los datos para gestionar y mejorar el trabajo
Las capacidades necesarias para seguir este
comportamiento son las proporcionadas por PSP:
definición y seguimiento del proceso
recogida y utilización de datos del proceso
planificación
medición y gestión de la calidad
Seguir el proceso de manera consistente es
simplemente un hábito
41
TSP Weekly Team Meeting
Es el principal medio de comunicación y seguimiento del
equipo
Su objetivo es asegurar que todos los miembros del
equipo:
conocen el estado actual del proyecto
conocen las tareas que se deben realizar a continuación
están al corriente del estado del trabajo realizado por cada
miembro del equipo y de su progreso
entienden los aspectos clave y los riegos
participan en las decisiones de equipo
Todos los miembros del equipo deben asistir
Estas reuniones siguen un proceso estándar definido
42
21
Relación entre CMM/CMMI, TSP y PSP
En la figura se puede observar como CMM/CMMI,
TSP y PSP pueden usarse de forma conjunta y
combinada para mejorar las capacidades de toda
la organización:
CMM/CMMI
CMM/CMMI
para
paralas
lascapacidades
capacidades
de
dela
laorganización
organización
TSP
TSP
para
parala
lacapacidad
capacidad
de
detrabajo
trabajoen
enequipo
equipo
PSP
PSP
para
parala
lamejora
mejorade
de
las
lascapacidades
capacidades
individuales
individuales
43
Relación entre CMM/CMMI, TSP y PSP
PSP forma técnicos de equipos establecidos con TSP en la
mayoría de las prácticas genéricas de CMM/CMMI. TSP por si
sólo, aunque sea aplicado a todos los equipos de desarrollo, no
cubre todas las prácticas de cada área de proceso de
CMM/CMMI, razón de más para que sea utilizado de forma
complementaria a este modelo, no de forma aislada.
Debido a que las actividades de medición y análisis de los
resultados son fundamentales en PSP y en TSP, su utilización
durante la aplicación de CMM/CMMI en una organización, permite
acelerar el progreso y aumentar el Nivel de capacidad de la
empresa en un tiempo menor que sin su uso.
En el informe se detallan las actuaciones que se deben aplicar
según los principios de TSP en cada Nivel de madurez del modelo
CMM y para cada Área Clave de Proceso. Humphrey afirma que,
contrariamente a la impresión errónea que tienen algunas
personas, TSP y PSP pueden ser aplicados en una empresa
obteniendo grandes beneficios, independientemente del Nivel de
madurez en que ésta se encuentre.
44
22
Relación entre CMM/CMMI, TSP y PSP
El uso combinado de TSP y PSP aceleran el proceso de mejora
según CMM, si bien es necesario establecer los pasos para
combinar ambos esfuerzos:
En primer lugar, con la aplicación de TSP, los técnicos y los equipos,
pueden ver las razones del alto Nivel de madurez de la mayoría de
prácticas de CMM, y entienden más la necesidad de cooperar en los
esfuerzos de mejora.
En segundo lugar, ya que el objetivo de cualquier esfuerzo de mejora
de procesos de software es aumentar el rendimiento de la
organización, y ello requiere cambios en el funcionamiento de los
procesos de ingeniería, cualquier esfuerzo de mejora debe estar
acompañado por pasos que puedan demostrar cambios en los
comportamientos de ingeniería. TSP y PSP se utilizan para este fin.
En tercer lugar, cualquier esfuerzo de mejora conlleva el riesgo de
burocratizarse y de imponer presión sobre los ingenieros en lugar de
ayudarles. Si como se sugiere en TSP, el equipo es tratado como si
fueran clientes, este riesgo disminuye considerablemente.
En cuarto lugar, TSP permite mejorar substancialmente el
rendimiento de los grupos de software en una organización.
45
Bibliografía
Gestión del proceso software
Gonzalo Cuevas Agustín
Centro de Estudios Ramón Areces, S.A., 2003
Introduction to the Team Software ProcessSM
Watts S. Humphrey
Addison-Wesley, 2005
TSPSM - Leading a Development Team
Watts S. Humphrey
Addison-Wesley, 2006
TSPSM - Coaching Development Teams
Watts S. Humphrey
Addison-Wesley, 2006
46
23
¿¿Trabajo en equipo??
47
24
Descargar