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