DocsTec-2101

Vista previa del material en texto

INSTITUTO TECNOLOGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY
DIVISION DE GRADUADOS EN ELECTRONICA,
COMPUTACION, INFORMATICA
Y COMUNICACIONES
CARACTERISTICAS DE LOS EQUIPOS
AUTODIRIGIDOS DISPERSOS GEOGRAFICAMENTE
ENFOCADOS AL DESARROLLO DE SISTEMAS DE
SOFTWARE, EMPLEANDO HERRAMIENTAS DE
ADMINISTRACION DE PROYECTOS.
TESIS
PRESENTADA COMO REQUISITO PARCIAL
PARA OBTENER EL GRADO ACADEMICO DE:
MAESTRO EN ADMINISTRACION DE TECNOLOGIAS
DE INFORMACION
POR
RAYMUNDO FLORES FLORES
DICIEMBRE 2002
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
de M o n t e r r e y
MAESTRÍA EN ADMINISTRACIÓN DE TECNOLOGÍAS DE
INFORMACIÓN
TESIS
Características de los equipos autodirigidos dispersos
geográficamente enfocados al desarrollo de sistemas de
software, empleando herramientas de administración de
proyectos.
POR
Raymundo Flores Flores
Diciembre del 2002
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
DIVISIÓN DE GRADUADOS EN ELECTRÓNICA COMPUTACIÓN
INFORMACIÓN Y COMUNICACIONES.
PROGRAMAS DE POSGRADO EN ELECTRÓNICA, COMPUTACIÓN,
INFORMACIÓN Y COMUNICACIONES.
Los miembros del comité de tesis recomendamos que la presente tesis
del Ing. Raymundo Flores Flores sea aceptada como requisito parcial
para obtener el grado académico de Maestro en Administración de
Tecnologías de Información.
Comité de Tesis:
David A. Garza Salazar.
Director de los Programas de Postgrado en Electrónica,
Computación, Información y Comunicaciones.
DICIEMBRE del 2002.
DEDICATORIA.
DEDICATORIA.
A Dios por haberme permitido venir a este mundo, recibir un cuerpo,
tener una bella familia, ser probado y tener la oportunidad de regresar
con Él.
A ti Mamá que sin ti no seria nadie, gracias por tu apoyo incondicional,
tu ejemplo y tu infinito amor, simplemente la mejor mamá del mundo,
te adoro Ledia.
Especialmente a ti Papá ya que con esto cumplo parte de tus sueños,
espero lo recibas en el lugar donde te encuentres Tata, te quiero
mucho(t)
A ti hermanita por todo tu apoyo y esos sentimientos tan lindos que Dios
te ha dado y que siempre has estado dispuesta a compartirlos conmigo.
A mis niños Alexis y Ángel Jacob.
iii
AGRADECIMIENTOS.
A mi familia por su amor, apoyo y comprensión. Son la base de mi vida.
A mis maestros quienes me obsequiaron lo que con nada se paga, sus
conocimientos y experiencias.
A mi asesora Lety, por ser mi guía en esta aventura que emprendimos
hace un año, por tu tiempo, paciencia y por todos tus brillantes
consejos.
A mi "hermano" Luigi por el tiempo dedicado en este trabajo como
sinodal, por tu apoyo en los momentos difíciles y sobretodo por ser un
excelente amigo.
A Cuauhtémoc por enseñarme tantas cosas durante estos dos años,
permitirme trabajar con él en donde pude obtener información valiosa
para este trabajo y por el tiempo dedicado siendo sinodal.
A Alma Elena, porque fue una pieza clave a mi llegada a Monterrey, por
su ayuda incondicional y por ser mi amiga, te quiero mucho.
A Carolina por el tiempo dedicado en revisar mi tesis, por estar conmigo
en los buenos y en los malos momentos, mi amiga incondicional.
Finalmente pero no menos importantes todos mis valiosos amigos y
amigas de Veracruz y de Monterrey, ustedes son parte de mi familia:
Javier, Aura, Nelson, Susy, Nayda, Alina, Edaly, Benjamín, Paul.
¡V
RESUMEN.
El ambiente que se vive actualmente dentro del ámbito
empresarial, obliga a las organizaciones a que deban implementar
conceptos innovadores que les permita tener ventajas competitivas
sobre las demás. Las empresas de desarrollo de software no son la
excepción, al contrario se puede decir que ellas son las que viven este
ambiente de una manera más directa, dada la rapidez con que cambian
las tecnologías.
El presente trabajo se encuentra enfocado precisamente a
proporcionar una guía de mejores prácticas a las empresas de desarrollo
de software, y a proporcionar un contenido de investigación a cerca de
metodologías, técnicas y herramientas a cerca de 4 áreas que en la
actualidad bien aplicadas de manera conjunta, proporcionan a las
empresas una ventaja competitiva.
La administración de proyectos que ha surgido como una
disciplina relativamente nueva en los últimos años, debido a la
importancia que ha cobrado para las organizaciones la forma de llevar el
control desde el inicio hasta el fin de los proyectos con prácticas de
planeación y seguimiento bien definidas.
La parte que se refiere al recurso humano y un concepto
realmente innovador los equipos de alto rendimiento o equipos
autodirigidos que implica proporcionar el empowerment y autonomía
necesarios a los miembros del equipo para que puedan tomar todas las
decisiones referentes a los proyectos y que puedan hacerse cargo de los
procesos y actividades de los mismos. Esto permite aprovechar al
máximo las capacidades de cada uno de los miembros de los equipos.
Las ciencias computacionales se han desarrollado de una manera
exponencial en los últimos años, dada esta característica resulta
importante que se analicen las tendencias y conceptos actuales sobre el
desarrollo de software.
Finalmente un concepto que desde hace algún tiempo se viene
manejando dado el ímpetu que ha surgido por impulsar mercados
globalizados, la colaboración a distancia que es el hecho de que dos
o más personas que se encuentren en lugares diferentes puedan
interactuar en algún proyecto utilizando reglas, herramientas y técnicas
de colaboración.
V
Tabla de contenidos
DEDICATORIA iii
AGRADECIMIENTOS ¡v
RESUMEN v
Tabla de contenidos vi
Tabla de figuras ix
Capítulo 1. Introducción 1
1.1. Antecedentes generales 1
1.2. Objetivo 2
1.3. Restricciones 2
1.4. Metodología y métodos 2
1.5. Producto final 3
1.6. Contribución esperada 3
Capítulo 2. Administración de proyectos 4
2.1. Introducción 4
2.2. Antecedentes de la administración de proyectos 4
2.3. Definiciones de proyecto 5
2.4. La administración de proyectos 7
2.4.1. Etapas y procesos de la administración de proyectos 9
2.5. ¿Cuándo debe usarse la administración de proyectos? 14
2.5.1. Usos específicos 14
2.6. El rol del administrador de proyectos 15
2.7. Conclusiones 16
Capítulo 3. Desarrollo de Software 17
3.1 Introducción 17
3.2 Definiciones básicas sobre desarrollo de software 18
3.3 Las cuatro dimensiones del desarrollo de software 19
3.4 Modelos de desarrollo de software 21
3.4.1 El modelo de cascada o ciclo de vida clásico 21
3.4.2 Modelo rápido basado en prototipos 25
3.4.3 El modelo de espiral 26
3.4.4 El modelo de desarrollo evolutivo 28
3.4.5 Modelo Orientado a Objetos 31
3.4.6 Elección de un modelo 33
3.5 Extreme Programming 34
3.5.1 Introducción 34
3.5.2 Definiendo Extreme Programming 35
3.5.3 Elementos de la Metodología XP 35
3.6 Conclusiones 37
Capítulo 4. Equipos de alto rendimiento 38
4.1 Introducción 38
4.2 Definiciones básicas 38
4.2.1 Variaciones en la productividad 39
vi
4.3 Tipos de equipos 39
4.4 Equipos de alto rendimiento 41
4.4.1 Definición de equipos de alto rendimiento 41
4.4.2 Características de los equipos de alto rendimiento 42
4.4.3 Funciones Realizadas por los equipos de alto rendimiento. ...47
4.4.4 Puntos a considerar sobre los equipos de alto rendimiento. ..48
4.5 Conclusiones 49
Capitulo 5. Colaboración a distancia 50
5.1 Introducción 50
5.2 ¿Qué es Colaboración? 50
5.3 Trabajando de manera colaborativa 51
5.4 Un Equipo Diferente: el Equipo Virtual 52
5.4.1 Tamaño y composición de los equipos en línea 54
5.5 El Tiempo y el Espacio como Marco de Referencia 55
5.6 Groupware 57
5.7 Factores que Impiden el Surgimiento de una Comunidad
Colaborativa 59
5.8 Conclusiones 61
Capitulo 6. Investigación de campo 62
6.1 Metodología 62
6.2 Determinación de la población y la muestra 62
6.3 Métodos y herramientas 64
6.3.1 La herramienta 65
6.3.2 Evaluación de la herramienta 65
6.4 Conclusiones 66
Capítulo 7. Caso de estudio: Dirección de Integración de Soluciones
(DIS) 67
7.1 Historia 67
7.2 Forma de organización del equipo de trabajo 67
7.3 Herramientas y prácticas utilizadas 69
7.4 Liderazgo en el equipo70
7.5 Procesos de administración y desarrollo de software 70
7.6 Resultados obtenidos 72
7.7 Variables obtenidas del caso de estudio 73
Capítulo 8. Análisis de resultados 75
8.1 Sección I. Administración de proyectos 75
8.1.1 Pregunta 1 75
8.1.2 Pregunta 2 76
8.1.3 Pregunta 3 77
8.1.4 Pregunta 4 78
8.1.5 Pregunta 5 79
8.1.6 Pregunta 6 81
8.1.7 Pregunta 7 82
8.1.8 Pregunta 8 83
vii
8.1.9 Pregunta 9 84
8.2 Sección I I . Desarrollo de software 85
8.2.1 Pregunta 1 85
8.2.2 Pregunta 2 86
8.2.3 Pregunta 3 88
8.2.4 Pregunta 4 89
8.2.5 Pregunta 5 90
8.2.6 Pregunta 6 91
8.2.7 Pregunta 7 92
8.3 Sección I I I . Equipos autodirigidos 93
8.3.1 Pregunta 1 93
8.3.2 Pregunta 2 94
8.3.3 Pregunta 3 95
8.3.4 Pregunta 4 96
8.3.5 Pregunta 5 97
8.3.6 Pregunta 6 98
8.3.7 Pregunta 7 99
8.3.8 Pregunta 8 100
8.4 Sección IV. Colaboración a distancia 101
8.4.1 Pregunta 1 101
8.4.2 Pregunta 2 102
8.4.3 Pregunta 3 103
8.4.4 Pregunta 4 104
8.4.5 Pregunta 5 105
8.5 Conclusiones 106
Capítulo 9. Guía para trabajar con equipos autodirigidos dispersos
geográficamente 108
9.1 Introducción 108
9.2 Prueba de grado de desarrollo de las empresas 109
9.3 Recomendaciones generales 112
9.3.1 Administración de proyectos 112
9.3.2 Desarrollo de software 113
9.3.3 Equipos autodirigidos 114
9.3.4 Colaboración a distancia 115
9.4 Conclusiones 116
Capitulo 10. Conclusiones y trabajos futuros 117
10.1 Conclusiones finales 117
10.2 Trabajos futuros 119
Anexos 120
Anexo 1. Cuestionario 120
Bibliografía 127
viii
Tabla de figuras.
FIG. 2 .1 . FACTORES QUE INFLUYEN EN UN PROYECTO (CLELAND,1999) 6
FIG. 2 . 2 LA TRIPLE CONSTANTE (MCONNEL, 1 9 9 6 ) 8
FIG. 2.3. PROCESO DE ADMINISTRACIÓN TÍPICO (MCONNEL, 1996) 9
FIGURA 2.4. ÁREAS Y PROCESOS DE LA ADMINISTRACIÓN DE PROYECTOS (PMBOOK,
2000) 11
FIGURA 2.5. RELACIÓN EXISTENTE ENTRE LOS PROCESOS EN LAS FASES (PMBOOK,
2000) 12
FIGURA 2.6. FORMA DE INTERACCIÓN Y TRASLAPE DE LOS PROCESOS (KIMMONS,
1999) 13
FIGURA 3.1 LAS CUATRO DIMENSIONES DEL PROCESO DE DESARROLLO DE
SOFTWARE(MCCONNELL,1996) 19
FIGURA 3.2 MODELO DE ETAPAS (PRESSMAN, 2000) 22
FIGURA 3.3 MODELO CASCADA(PRESSMAN, 2000) 23
FIGURA 3.4 MODELO RÁPIDO DE PROTOTIPOS(MCCONNELL,1996) 25
FIGURA 3.5 CICLO DE VIDA DE ESPIRAL(PRESSMAN, 2000) 27
FIGURA 3.6 MODELO DE DESARROLLO EVOLUTIVO(PRESSMAN,1997) 29
FIGURA 3.7 MODELO ORIENTADO A OBJETOS(PRESSMAN, 1988) 31
FIG. 7.1 ESTRUCTURA DEL EQUIPO DE TRABAJO(MÉNDEZ, 2001) 68
FIGURA 9.1 ETAPAS DE AVANCE DE LAS EMPRESAS 110
ix
Capítulo 1. Introducción
1.1. Antecedentes generales.
La administración de proyectos gana terreno en las empresas,
principalmente, las dedicadas al desarrollo de software, debido a la
naturaleza de sus proyectos que incluyen la coordinación de fases
ligadas al modelo de desarrollo de software que utilizan.
La preocupación de las empresas por la implementación de la
administración de proyectos se ve acrecentada por el alto porcentaje de
proyectos etiquetados como no exitosos. Con el propósito de reducir
esta cifra, se ha colocado a personas encargadas específicamente a
estas tareas, reconociendo ampliamente los beneficios.
Así mismo, algunas empresas han evolucionado su manera de
organizar sus equipos de trabajo, marcando una tendencia hacia los
denominados equipos autodirigidos, en donde los participantes están
firmemente integrados y cuentan con cierta autonomía y empowerment
para tomar decisiones en lo referente al desarrollo de los proyectos.
Otra tendencia más novedosa es la denominada "colaboración a
distancia", en donde en forma conjunta las personas pueden desarrollar
proyectos a pesar de no encontrarse físicamente en el mismo lugar; los
resultados han sido favorables con el apoyo de las nuevas tecnologías
que facilitan este modo de trabajo, el uso de herramientas como los
grupos de colaboración, los denominados chats y las teleconferencias,
entre otras, han permitido que existan proyectos exitosos desarrollados
por equipos geográficamente distantes.
Tomando en cuenta lo anterior, resulta importante investigar y
analizar los factores relevantes que influyen en el éxito de la
administración de los proyectos de desarrollo de software en las
empresas que utilizan Equipos Autodirigidos (EA), y determinar las
características predominantes y el modelo de trabajo ideal para lograr la
colaboración de los integrantes de los mismos en forma distante.
1
1.2. Objetivo.
Determinar las características inherentes a un equipo
autodirigido y disperso geográficamente para la producción de
proyectos de desarrollo de software exitosos, usando
herramientas de administración de proyectos.
Se habla de un proyecto con éxito cuando el proyecto finaliza en
el tiempo estimado, con los recursos materiales y humanos asignados y
cumpliendo con los requerimientos especificados por el cliente.
1.3. Restricciones.
• El alcance de esta investigación incluye solo proyectos de
desarrollo de software.
• Las aplicaciones del desarrollo de software están restringidas al
software administrativo y al software enfocado a la educación.
• La investigación de campo se llevará a cabo en empresas de
Monterrey, Nuevo León y su área metropolitana, así como en la
Dirección de Integración de Soluciones de la Vicerrectoría de
Tecnologías de Información del Sistema Tecnológico de Monterrey.
• La información recopilada dependerá de las restricciones
impuestas por la organización.
1.4. Metodología y métodos.
Considerando que el producto final de este trabajo de tesis
consiste en proponer una guía, donde se muestren las características
que deben cumplirse para poder trabajar con equipos autodirigidos
dispersos geográficamente que desarrollen productos de software
apoyados en metodologías de administración de proyectos, se ha optado
por aplicar metodologías cualitativas, ya que son las que pueden apoyar
mejor para determinar dichas características.
Durante la primera etapa de la investigación, se realiza el estudio
del caso en el que el autor se ha visto involucrado, debido a su trabajo
dentro de la Dirección de integración de soluciones perteneciente al
Sistema Tecnológico de Monterrey, el cual proporciona las variables que
serán investigadas durante la segunda etapa, que se sustenta con la
aplicación de un cuestionario. Este cuestionario se realiza con el objetivo
de obtener las características a ser incluidas en la guía.
2
1.5. Producto final.
El producto final consistirá en una guía que muestre las
características que deben cumplirse para poder trabajar con equipos
autodirigidos dispersos geográficamente, en el desarrollo de productos
de software, apoyados con metodologías de administración de
proyectos.
1.6. Contribución esperada.
Ofrecer a los departamentos de desarrollo de software una guía
que les permita trabajar con equipos autodirigidos de manera local y
dispersos geográficamente. Demostrar la factibilidad de los equipos
autodirigidos y los factores que deben ser considerados para fomentar el
desarrollo de habilidades de comunicación virtual y asincrona para
proyectos de desarrollo de software.
3
Capítulo 2. Administración de proyectos.
"No hay nada
permanente excepto el
cambio". (Heráclito,
Grecia. 513 A. C.)
2.1. Introducción.
Si contamos con los 100 mejores músicos del planeta y decidimos
ponerlos a tocar todos juntos, pero no disponemos de un director de
orquesta entrenado que los dirigiera, el resultado no sería algo
deleitable a los sentidos, ya que los tiempos en los que debe tocar cada
músico no podrían ser distinguidos y finalmente sería un caos, lo mismo
sucede con los proyectos.
El objetivo de este capítulo es identificar y describir el proceso de
administración de proyectos, así como proporcionar un marco de
referencia sobre las metodologías existentes.
2.2. Antecedentes de la administración de proyectos.
¿Qué tienen en común la gran muralla China, el techo de la capilla
Sixtina, el Apolo 11, los Juegos Olímpicos, Microsoft Windows, las
pirámides egipcias y el viagra?, que todos ellos son el resultado de
proyectos exitosos, (Hobs, 2000), y que fueronlogrados, en cierta
forma, utilizando la administración de proyectos. Desde los primeros
tiempos de su actividad organizada los seres humanos han concebido y
realizado proyectos; en nuestra vida cotidiana constantemente estamos
emprendiendo proyectos; como por ejemplo, organizarnos para ir a un
picnic o realizar alguna remodelación a nuestra casa, solo que rara vez
estamos dispuestos a dirigirlos de la manera adecuada y en ocasiones
no salen como lo esperamos.
La administración de proyectos formal se remonta a finales de los
50's, debido a la necesidad de desarrollar e implementar la filosofía de la
administración en los sistemas militares. Sin embargo, no existe alguien
a quien se le atribuya la invención de la administración de proyectos
como tal. Sus principios son encontrados en la industria de la
construcción y en la ingeniería. El uso de fuerzas de trabajo y otros
equipos organizacionales contribuyó a que emergiera como una filosofía
para la integración de las actividades de las organizaciones.
4
Conforme fue madurando esta ciencia, surgieron nuevas técnicas
que apoyaron el desempeño de los administradores, técnicas sobre
planeación, motivación, liderazgo y control, hasta llegar al día de hoy en
donde existen organizaciones como El Project Managment Institute
(PMI) encargada de enseñar, certificar y apoyar a los administradores
de proyectos.
2.3. Definiciones de proyecto.
Regularmente en nuestra vida cotidiana usamos el término
proyecto aunque en realidad en pocas ocasiones reconocemos las
características del mismo y no tenemos una visión clara de lo que
implica un proyecto. A continuación se enuncian algunas de las
definiciones más importantes de lo que es un proyecto y se identifican
las partes que lo conforman.
"Un proyecto es un proceso único con un principio y un fin
definido; consiste en una serie de actividades interrelacionadas entre sí,
que deben ejecutarse para lograr un objetivo predeterminado" (PMBOK,
1996).
"El éxito de un proyecto va a depender, entre otras cosas, del
esfuerzo, cuidado y habilidades aplicadas en la planeación inicial del
mismo". (Vázquez Ramón,1998).
Todos los proyectos como lo muestra la figura 2.1 involucran tres
factores clave: el tiempo, el costo y la calidad. La importancia de éstos
varía de un proyecto a otro; en algunas ocasiones alguno de éstos tres
será un factor crítico dentro del desarrollo del proyecto y el resultado
exitoso depende de la habilidad del administrador para compensar la
carencia de alguno, aunque la calidad del proyecto no puede verse
afectada de ninguna forma, debe ser la base del producto final. (Hobs,
2000).
Tiempo Proyecto C o s t o
Calidad
FIG. 2 .1 . FACTORES QUE INFLUYEN EN UN PROYECTO (CLELAND,1999) .
Otra definición dada por Cervantes (1997) dice que "un proyecto
es un trabajo que se ejecuta una sola vez, que tiene un inicio y un final,
un objetivo especificado con claridad, un presupuesto establecido y una
organización".
"Un proyecto es una unidad organizacional dedicada a la
culminación de una meta - generalmente la terminación exitosa de un
producto desarrollado en el tiempo, dentro del presupuesto y en
cumplimiento con unas especificaciones predeterminadas". (Gaddis,
1991).
Después de tener estas definiciones y de analizarlas, podemos
decir que las características principales de los proyectos son:
• Es una actividad única, esto quiere decir que se realiza sólo una
vez, en un espacio de tiempo definido.
• Cuenta con un inicio y un fin, la cual es una característica que
debe ser bien delimitada desde la primera fase del proyecto. En
este sentido muchos administradores tienen algunos problemas ya
que no identifican los subproyectos que se involucran, los cuales
deben ser definidos en otro espacio de tiempo.
• Tiene objetivo o meta central, la razón de ser del proyecto y no
debe ser perdido de vista durante el desarrollo del mismo.
• Un factor importante y variable es el presupuesto, ya que dentro
de todo proyecto determina los recursos con los que se contará
para alcanzar los objetivos deseados.
• Por último, las especificaciones que van de la mano con la
calidad y el servicio al cliente se deben definir correctamente
desde el inicio todas las especificaciones y dar satisfacción a las
necesidades del cliente.
2.4. La administración de proyectos.
Si se le preguntara a un administrador de proyectos
experimentado acerca de cual es su objetivo principal cuando toma un
proyecto, probablemente contestaría que es "terminar el trabajo, en
tiempo, costo y de acuerdo a las especificaciones acordadas".
Podría pensarse que los conceptos "administración" y
"administración de proyectos" se refieren a lo mismo, pero es una
equivocación, dado que un proyecto es ejecutado una sola vez, lo cual
es muy diferente a administrar procesos que son repetitivos; otro punto
de diferencia es que el equipo de trabajo asignado a un proyecto es
temporal y los administradores en general deben trabajar con las
mismas personas, regularmente.
Cleland (1999) define a la administración de proyectos como: " El
arte de dirigir y coordinar recursos humanos y materiales a lo largo de
la vida de un proyecto, usando técnicas modernas de administración
para lograr los objetivos predeterminados de dimensión, costo, tiempo,
calidad y satisfacción de los participantes".
El Instituto de Administración de Proyectos (PMI, por sus siglas en
inglés) describe a la administración de proyectos como la aplicación del
conocimiento, las habilidades, las herramientas y las técnicas para
proyectar actividades en el orden en el que se requieren obtener y
satisfacer las necesidades del cliente, comprendidas en dimensión,
costo, tiempo y calidad.
Rosenau (1998) distingue algo que él denomina la triple
constante, la cual se refiere a cumplir las especificaciones en el tiempo y
cumpliendo con el costo presupuestado. La figura 2.2 muestra cómo es
que esta "triple constante" funciona.
C
<ü
Q.
E
ai
i/i
O)
Q
^Especificaciones
Costo
/Tiempo
FlG. 2.2 LA TRIPLE CONSTANTE (MCONNEL, 1996 ) .
Lewis (1997) define la siguiente fórmula en base a esta triple
constante: el costo = f (P, T, S ), donde P es el desempeño, T es el
tiempo y S es la dimensión del proyecto. Por lo tanto si P y S se
incrementan, el costo, generalmente, se verá afectado de manera
proporcional.
Por su parte, Dobson (1999) afirma que un proyecto puede formar
parte de un conjunto de proyectos, lo que se conoce como portafolio de
proyectos, donde cada proyecto se considera como una tarea y todos
estos proyectos son diferentes en tiempo o tamaño.
Para lograr realizar estas tareas que pudieran parecer tan
complicadas, los administradores de proyectos han desarrollado una
variedad de herramientas que le permiten administrar los recursos
humanos y materiales; un ejemplo de éstas son: las gráficas de Gantt,
gráficas de recursos y herramientas de software, que los apoyan
durante todo el proceso de la administración de proyectos.
8
2.4.1. Etapas y procesos de la administración de proyectos.
El proceso de administración de proyectos consiste en una serie de
actividades contenidas en un proceso, el cual consiste en realizar tareas,
trabajando con los miembros del equipo y con otras personas a fin de
cumplir con un calendario, un costo y unos objetivos de desempeño.
"Un proceso se define como un conjunto de operaciones en el
diseño, el desarrollo y la producción de algo" En otras palabras es un
lapso de tiempo en el que algo es creado (Cleland, 1999).
El proceso de administración consta de 5 partes, las cuales se
identifican claramente en la figura 2.3.
Control
Dirección
Motivación
Proceso de
Administración
Planeación
Organización
FlG. 2 .3 . PROCESO DE ADMINISTRACIÓN TÍPICO (MCONNEL, 1996) .
"La planeación responde a la pregunta de ¿qué es lo que quiero
hacer y por qué?; la organización, ¿quién esta involucrado y por qué?;
la motivación, ¿cómo puedo obtener un mejor desempeño de los
integrantes del equipo?; la dirección, ¿quién decide qué y cuándo?; y el
control, ¿quién decide los resultadosy basado en qué estándares?".
(PMBOOK, 2000).
Sin embargo, el proceso de administración de proyectos envuelve
un mayor número de funciones, debido a que los proyectos son únicos y
a que conllevan cierto grado de incertidumbre. Las fases que muestra la
figura 2.3 son sólo la base de ellas; para poder tener una idea más
amplia se observo la clasificación que el Project Managment Institute
proporciona. Las áreas de conocimiento de la administración de
proyectos describen el conocimiento y las prácticas de acuerdo con los
procesos que las componen. Estos procesos se organizan en nueve
áreas como se describe en la figura 2.4.
Administración de la integración: Describe los procesos
requeridos para asegurar que los diversos elementos del proyecto
estén propiamente coordinados.
Administración del alcance: Describe el proceso necesario para
asegurar que el proyecto incluye todo el trabajo, y sólo el trabajo
requerido para completar el proyecto exitosamente.
Administración del tiempo: Describe el proceso requerido para
asegurar la terminación del proyecto a tiempo.
Administración del costo: Describe el proceso requerido para
asegurar que el proyecto sea completado dentro del presupuesto
aprobado.
Administración de la calidad: Describe el proceso requerido para
asegurar que el proyecto satisfaga las necesidades para las que fue
llevado a cabo.
Administración de los recursos humanos: Describe el proceso
requerido para hacer el uso efectivo de la gente involucrada en el
proyecto,
Administración de la comunicación: Describe el proceso requerido
para asegurar a tiempo y apropiadamente la generación, la
recolección, la diseminación, el almacenamiento y la disposición de la
información del proyecto.
Administración del riesgo: Describe el proceso concerniente con la
identificación, el análisis y la respuesta a los riesgos del proyecto.
Administración de adquisiciones: Describe el proceso requerido
para adquirir bienes y servicios del exterior de la organización.
10
Administración de
Proyectos
1.
Administración de la
integración del proyecto.
Desarrollo del plan del
proyecto.
Ejecución del plan del
proyecto.
Control general de cambios.
4.
Administración del costo
del proyecto.
Planeación de recursos.
Estimación de costos.
Presupuesto de costos.
Control de costos.
7.
Administración de la
comunicación del
proyecto
Planeación de las
comunicaciones.
Distribución de la
información.
Reporte del rendimiento.
Acercamiento
administrativo.
2.
Administración del
alcance del proyecto.
Iniciación.
Planeación del alcance.
Definición del alcance.
Verificación del alcance.
Control de cambios del
alcance.
5.
Administración de la
calidad del proyecto.
Planeación de la calidad.
Aseguramiento de la
calidad.
Control de la calidad.
8.
Administración del riesgo
del proyecto.
Identificación del riesgo.
Cuantificación del riesgo.
Desarrollo de respuesta al
riesgo.
Control de respuesta al
riesgo.
3.
Administración del tiempo
del proyecto.
Definición de actividades.
Secuencia de actividades.
Estimación de la duración
de actividades.
Desarrollo de la agenda.
Control de la agenda.
6.
Administración de los
recursos humanos del
proyecto.
Planeación organizacional.
•-i Adquisición del personal.
i Desarrollo del equipo.
9.
Administración de
adquisiciones del
proyecto.
Planeación de
adquisiciones.
Planeación de solicitudes.
Solicitudes.
Selección del origen.
Administración de contratos.
Clausura del contrato
FIGURA 2.4. ÁREAS Y PROCESOS DE LA ADMINISTRACIÓN DE PROYECTOS (PMBOOK, 2000).
11
Cada una de estas áreas recibe igual importancia durante todo el
ciclo de vida del proyecto y se ven afectadas unas con otras ante
cualquier variación. Están formadas por procesos, los cuales consisten
en una serie de acciones que se realizan para lograr un resultado. Los
procesos en los proyectos son realizados por personas y generalmente
caen en dos grandes categorías:
• Procesos de administración de proyectos: Se refieren a la
descripción y la organización del trabajo del proyecto. Estos
procesos son aplicables a la mayoría de los proyectos.
• Procesos orientados a productos: Se refieren a la
especificación y a la creación del producto del proyecto. Estos
procesos están definidos en el ciclo de vida del proyecto y varían
de acuerdo al área de aplicación.
Ambas clasificaciones de procesos se traslapan e interactúan
durante el proyecto. Los procesos mostrados en la figura 2.4 pueden ser
organizados en cinco grupos de uno o más procesos cada uno, la figura
2.5 muestra los procesos y la relación existente entre ellos.
Proceso de
¡nicialización
Proceso de
control
Procesos de
planeación
Proceso de
cierre
Proceso de
ejecución
FIGURA 2.5. RELACIÓN EXISTENTE ENTRE LOS PROCESOS EN LAS FASES (PMBOOK, 2000).
12
• Procesos de iniciación: Reconocer que un proyecto o fase debe
iniciar y comprometerse a llevarlo a cabo.
• Proceso de planeación: Diseñar y mantener un esquema de
trabajo para cumplir con las necesidades del negocio que el
proyecto pretende alcanzar.
• Proceso de ejecución: Coordinar a la gente y otros recursos
para llevar a cabo el plan.
• Proceso de control: Asegurar que los objetivos del proyecto se
cumplan, a través del monitoreo y la medición del progreso y
tomando acciones correctivas cuando sea necesario.
• Proceso de cierre: Formalizar la aceptación del proyecto o fase
para llevarlo a su conclusión.
Para reconocer cómo es que estos procesos interactúan en las
diferentes fases que abarca un proyecto debemos observar la figura 2.6.
Nivel de
actividad
Proceso de
Ejecución
Proceso de
Planeación
Proceso
de
Iniciaciói
Proceso de
Cierre
Fase de Inicio Tiempo Fase Final
FIGURA 2.6. FORMA DE INTERACCIÓN Y TRASLAPE DE LOS PROCESOS (KIMMONS, 1999).
La administración de proyectos es un proceso continuo. Nuevas
demandas serán requeridas al equipo asignado al proyecto y éstas
deben ser coordinadas por el administrador de proyectos, a través del
proceso de iniciación, planeación, ejecución, control y cierre.
En la práctica, el administrador de proyectos, además de
encargarse de llevar a cabo esas fases, deberá aprender a tratar con
problemas y oportunidades a manera de que pueda completar el ciclo de
administración de proyectos, el cual si es planeado y ejecutado de
manera efectiva y eficiente puede complementar la estrategia de la
organización.
13
2.5. ¿Cuándo debe usarse la administración de proyectos?.
La principal razón para usar la administración de proyectos es la
de proporcionar diseño y estrategia a la organización, de forma que se
pueda enfocar en las actividades necesarias para efectuar cambios
dentro de la misma.
La modificación de productos, servicios y procesos es requerida
para poder soportar los cambios ambientales que las empresas
enfrentan en la actualidad. Esos cambios, usualmente, requieren que la
organización enfoque y organice de una manera correcta sus recursos
para el diseño de nuevas estrategias que le permitan estar preparada
para el futuro.
2.5.1. Usos específicos.
Uno de los principales usos de la administración de proyectos
dentro de las organizaciones es el de soportar la crisis de las estrategias
empleadas para la administración, pero la utilización de esta ciencia se
ha incrementado debido al crecimiento y la velocidad de los cambios en
el entorno de las empresas.
Ejemplo de lo anterior son los procesos de manufactura: la
administración del inventario, la planeación de requerimientos de
materiales, la integración de la manufactura computarizada y el uso de
robots que realizan tareas repetitivas relativamente a bajo costo. Así
mismo, se asocia la administración de proyectos con la creación y la
implementación de cosas que la organización no tiene, es decir, para
proyectos nuevos.
La administración de proyectos también puede ser utilizada para
realizar el cierre de proyectos ya existentes, como la clausura de una
planta de producción, la liquidación de un negocio, la fusión con alguna
otra compañía o el cierre de algún segmento de mercado ya existenteen la organización.
La principal razón para usar la administración de proyectos es la
de facilitar la implementación de la estrategia organizacional; sin
embargo, ésta puede ser utilizada en muchos otros contextos de la
organización (Cleland, 1999).
14
2.6. El rol del administrador de proyectos.
El éxito de un proyecto depende, principalmente, del ambiente
organizacional que lo rodea. Algunos factores organizacionales mejoran
las oportunidades de éxito de un proyecto, mientras que otros lo
amenazan. Un administrador de proyectos deberá tomar ventaja de los
factores positivos que puedan existir y tratará de compensar cualquier
factor negativo que sea inevitable.
El Project Managment Institute dice de manera muy concreta que
el administrador de proyectos es la persona encargada de hacer que se
cumplan las actividades planeadas para el desarrollo de un proyecto.
En el proceso de administración de proyectos existe una persona
encargada de dirigir y dar seguimiento a las actividades que se realizan
durante su ejecución, cuya responsabilidad es la de llevar el proyecto a
una culminación exitosa. La mayoría de los autores coinciden en que
ésta es la principal y última función de un administrador de proyectos.
Cleland (1999) menciona que debido a lo cambiante del entorno de
las organizaciones, la tarea de administrador de proyectos es cada vez
más exigente y requiere que la persona que está a cargo de esta función
debe cumplir con las siguientes características básicas:
• Líder natural con visibles habilidades administrativas.
• Experiencia en el área que implican los proyectos a administrar.
• Habilidad para trabajar y comunicarse con otros.
• Habilidad para motivar a su equipo y auto motivarse.
• Total conocimiento de los recursos, los sistemas y los
procedimientos de su compañía.
• Habilidades de intuición para desarrollar y mantener relaciones
favorables con el cliente.
Según Cleland (1999) algunas de las funciones del administrador de
proyectos son las siguientes:
• Mantener el balance de poder entre la oficina del proyecto y las
demás áreas funcionales de la organización.
• Proveer y facilitar servicios a los proyectos.
• Promover y desarrollar una filosofía de cómo serán priorizados los
recursos y cómo serán resueltos posibles conflictos en torno a
esos recursos.
15
• Proveer estándares de desempeño, tanto para el éxito de los
proyectos como para las tareas funcionales.
• Establecer criterios de evaluación.
• Definir parámetros de decisión.
El administrador del proyecto es un rol que requiere una gran
experiencia, así como características muy específicas en el individuo que
lo desempeña; el administrador debe realizar varias actividades para
dirigir el curso del proyecto; debe fungir como moderador y líder entre
los diversos elementos del equipo de trabajo, esta última función puede
ser un factor determinante en el éxito o fracaso del proyecto.
2.7. Conclusiones.
Al finalizar esta sección se puede decir que la administración de
proyectos es un proceso complejo que no cualquiera puede llevar a
cabo. El hecho de iniciar, planear, ejecutar, controlar y cerrar un
proyecto, requiere de muchos conocimientos a parte de una buena
cantidad de experiencia en el área de proyectos a desarrollar. Además la
persona encargada de administrar los proyectos debe contar con
suficiente empowerment que le permita tomar las decisiones indicadas
en el momento preciso con la única finalidad de lograr proyectos
exitosos.
La administración de proyectos a pesar de que es un área nueva
de la administración, actualmente es de importancia estratégica para
las empresas, dada la globalización y la multiplicación de proyectos
requeridos por las mismas.
En el capítulo 3 se hablará a cerca del desarrollo de proyectos de
software específicamente sobre algunas metodologías empleadas para
el desarrollo de los mismos y se darán algunas definiciones.
16
Capítulo 3. Desarrollo de Software
"¿Podría decirme, por favor, qué camino debo tomar
desde aquí?".
- "Eso depende, en gran medida, de a dónde quieras
ir", dijo el Gato.
- "Eso no importa mucho", dijo Alicia.
- "Entonces no tienes problema con el camino que
cojas", dijo el Gato.
- "...con tal de que llegue a alguna parte...", añadió
Alicia como justificación.
- "Oh, seguro que lo harás", dijo el Gato, "con tal de
que camines lo bastante".
Conversación con el Gato de Cheshire en
"Alicia en el País de las Maravillas"
3.1 Introducción.
Red Auerbach el entrenador que más tiempo duro con los Celtics
de Boston y hasta hace poco el que más veces ganó en la historia del
baloncesto profesional, sostiene el hecho de que los conocimientos
básicos son el punto clave para tener éxito dentro del baloncesto.
Explica que de todos los pases que se realicen en un partido, solo
aquellos en los que alguien coja el balón serán exitosos, la clave del
éxito en un rebote radica en coger el balón. Tener una base fue la
estrategia que le permitió a Auerbach ganar 8 veces seguidas los
campeonatos de la NBA.
Para tener éxito en el software hay que prestar la mayor atención
posible a los fundamentos. Podría ser el Bob Cousy, Kareem Abdul
Jabbar o Michael Jordán de su organización de software. Podría disponer
de una serie de métodos orientados a la planificación, pero si no utiliza
los conceptos básicos de desarrollo de software como el punto más
importante del esfuerzo de desarrollo se arriesgará a no lograr las metas
de planificación que se han propuesto(McConnell 1996).
Este capítulo pretende dar a conocer los fundamentos del
desarrollo de software así como las metodologías más importantes.
17
3.2 Definiciones básicas sobre desarrollo de software.
La definición más importante es la de sistema el cual se define
como: "Un conjunto de cosas ordenadas que ¡nteractúan entre sí para
lograr un determinado objetivo". Un programa consiste en "un conjunto
de instrucciones ordenadas que le indican a la computadora que
operaciones debe realizar, principalmente para la solución de un
problema".
De las dos definiciones anteriores se deriva una tercera. Sistema de
computadora: "Consiste en un programa o conjunto de ellos que
interactúan entre sí para lograr dar solución a un problema". Y de ésta
última, se deriva una definición que engloba todo el objetivo de esta
parte de la investigación, Software: "Por mucho tiempo definido
solamente como la parte no tangible de la computadora, ahora se ha
extendido esta definición como el conjunto de programas, diseño de
programas, datos, información, conocimiento y todo lo que implique
información relevante a un sistema", regularmente se usa como un
sinónimo para referirse a un sistema computacional.
Existen tres áreas que componen el desarrollo de un sistema: La
representación de un sistema (Programas, diseños, diagramas,
diccionarios, etc.), la Ingeniería de software (Metodologías, técnicas de
desarrollo, herramientas) y el conocimiento sobre el área de enfoque del
sistema (contabilidad, finanzas, administración de conocimiento).
Finalmente Ingeniería de software es la aplicación de los modelos
y formas de la ingeniería tradicional a la práctica de construir productos
de software.
18
3.3 Las cuatro dimensiones del desarrollo de software.
Según McConnell (1996) los proyectos de software se desarrollan
básicamente en base a 4 dimensiones: personas, procesos, producto y
tecnología. Las personas trabajan rápida o lentamente. El proceso
supone una mejora en la actividad de las personas o coloca un obstáculo
detrás de otro. Un producto se define de forma que casi se construye
solo o de forma que pone obstáculos a los mejores esfuerzos de la gente
que esta construyéndolo. La tecnología ayuda al esfuerzo de desarrollo u
obstaculiza los mejores intentos de los desarrolladores. La figura 3.1 nos
muestra el concepto de esta ¡dea.
Personas
Proceso Producto
Tecnología
FIGURA 3.1 LAS CUATRO DIMENSIONES DEL PROCESO DE DESARROLLO DE
SOFTWARE(MCCONNELL,1996).
La idea principal de esta teoría es la de mostrar estos cuatro
conceptos mas que como direcciones,dimensiones; a pesar de que la
figura lo muestre en 2 dimensiones debido a no poder dibujarlo en 4
como seria lo correcto. La razón principal es que regularmente cuando
contamos con direcciones se hace énfasis en una dirección a la vez y se
minimizan las demás. Dado que la idea es pensar en éstos como
dimensiones, es posible dar la atención necesaria a cada uno.
19
Cuando utilizamos una sola dimensión es prácticamente imposible
satisfacer los objetivos de todos, el desarrollo de software requiere que
se use una variedad de métodos de manera simultánea (Jones 1991,
dice en McConnell, 1996) Las organizaciones más efectivas en la
consecución de un desarrollo rápido optimizan estas cuatro dimensiones.
Personas. Los temas relacionados con Peopleware tienen mayor
impacto en el desarrollo de software de lo que imaginamos, se ha
descubierto que entre desarrolladores del mismo nivel, la productividad
puede variar de 10 a 1 dependiendo de la motivación empleada,
también se ha comprobado esto mismo empleando equipos completos
de trabajo. Los investigadores del personal de ingeniería de software de
la NASA han llegado a la conclusión de que la tecnología no es la
respuesta; los métodos más efectivos son aquellos que sacan partido al
potencial humano de sus desarrolladores.
Queda muy claro entonces que cualquier organización que trate
seriamente de mejorar su productividad primero debe ocuparse de
temas relacionados con personal, como la motivación, equipo de
trabajo, selección de personal y formación.
En el capítulo 4 se explicará más a detalle todo lo relacionado con las
personas y equipos autodirigidos.
Proceso. El proceso tiene tanto metodologías de gestión como
metodologías técnicas. El poner atención en los procesos mejora tanto la
rapidez del desarrollo de software como las personas, algunas personas
piensan que ocuparse del proceso es agobiante, y no hay duda que hay
algunos procesos que son demasiado rígidos y democráticos y hay gente
que ha creado estándares en proceso principalmente para sentirse más
poderosos. Un ejemplo claro de ineficiencia en procesos es cuando en
las ultimas etapas del desarrollo de software existen cambios en los
requerimientos, es necesario rediseñar, reprogramar y volver a hacer las
pruebas.
Producto. Es la dimensión más tangible del cuarteto y ocuparse de las
características y el tamaño del producto planea enormes oportunidades
de reducir la planificación.
Tecnología. Una forma rápida de mejorar la velocidad del desarrollo es
la de usar herramientas cada vez más efectivas. En la historia del
desarrollo de software, uno de los avances más significativos fue el paso
de lenguajes de bajo nivel a lenguajes de alto nivel.
20
3.4 Modelos de desarrollo de software.
A lo largo de la historia del desarrollo de software los expertos en
el área se han dado a la tarea de mejorar los procesos de producción de
software, y para esto han surgido muy diversas metodologías de
desarrollos las cuales unas vienen siendo evolución de otras.
Metodología se refiere en cualquier ámbito de trabajo, a un sistema
ordenado de proceder para la obtención de un fin. Hablando de sistemas
las metodologías de desarrollo nos indica los procedimientos o pasos a
realizar para obtener un sistema.
A continuación se detallan algunas de las más conocidas y utilizadas.
3.4.1 El modelo de cascada o ciclo de vida clásico.
El ciclo de vida clásico es el más antiguo, usado en el desarrollo de
productos de software. Sin embargo, con el paso de unos cuantos años,
se han producido críticas, incluso por seguidores activos, que cuestionan
su aplicabilidad a todas las situaciones.
Modelo de Cascada desarrollado en los años 70's. Se denominó de
cascada porque los productos pasan de un nivel a otro con suavidad. El
modelo de desarrollo de software de Cascada o Ciclo de vida clásico
viene a ser una evolución del modelo de etapas el cual consistía de 8
fases según Pressman (2000). Este modelo consideraba que deberían
ser consecutivas, poniendo énfasis en la documentación que resulta de
cada una y que es la entrada de la siguiente, formalizando los
procedimientos de planificación y de control tal como lo muestra la
figura 3.1.
21
Plan Operativo
Especificación de
Requerimientos
Especificación
Funcional
Definición del problema y establecimiento de
proyecto de desarrollo.
Visión profunda del problema desde el
punto de vista de desarrolladores y
usuarios.
Específica la información sobre la cual el
software a desarrollar trabajará.
Diseño Permite describir como el software va a
satisfacer los requerimientos.
Implementación Aquí es donde el software a ser desabollador
se codifica.
Integración Es la parte donde todos los módulos
codificados independientemente se integran.
Verificación y
Validación
Etapa en donde el software es probado para
verificar si es consistente con las definiciones.
Mantenimiento Modificaciones del software que sean producto
de errores, adecuaciones, etc.
FIGURA 3.2 MODELO DE ETAPAS (PRESSMAN, 2000)
A diferencia del modelo de etapas, el modelo de Cascada define
una retroalimentación entre las etapas, tal como lo muestra la figura
3.2. Una de las ventajas de ambos modelos es que definen un esquema
de trabajo claro, reconociendo y definiendo actividades dependientes del
desarrollo de software
22
PLANIFICACIÓN
DEL SISTEMA
ANÁLISIS h
DISEÑO
CODIFICACIÓN
PRUEBAS
Q.
MANTENIMENTO
FIGURA 3.3 MODELO CASCADA(PRESSMAN, 2000).
Este modelo divide el ciclo de vida del producto de programación en
una serie de actividades sucesivas; cada fase requiere información de
entrada, procesos y resultados, bien definidos.
Planificación del Sistema. Es la etapa en la que se determina si el
proyecto es o no factible de realizar y se determinan tiempos y costos
aproximados, estableciendo así la ruta crítica de cada actividad. Esto es
porque la falta de planeación de un sistema es la causa principal de
retrasos en programación, incremento de costos, poca calidad, y altos
costos de mantenimiento en los desarrollos de productos de software.
Con frecuencia se dice que es imposible realizar una planeación inicial,
porque la información precisa sobre las metas del proyecto, necesidades
del cliente y restricciones del producto no se conocen al comenzar el
proyecto de desarrollo, sin embargo, uno de los principales propósitos
de esta fase es aclarar los objetivos, problemas o necesidades y
restricciones. La dificultad de la planeación no debe desalentar tan
importante actividad.
Análisis. Es indispensable comprender perfectamente los
requisitos del software, para que éste no fracase. Esta etapa puede
parecer una tarea relativamente sencilla, pero las apariencias engañan.
23
Abundan los casos en que se puede llegar a malas interpretaciones o
falta de información.
Existe una frase que se utiliza al momento de hacer el análisis, y es la
siguiente:
"Sé que crees que comprendes lo que piensas que he dicho, pero no
estoy seguro de que lo que creíste oír sea lo que yo quise decir..."
Diseño. El diseño del software es realmente un proceso multipaso
que se enfoca sobre cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño
traduce los requisitos en una representación del software que pueda ser
establecida de forma que obtenga la calidad requerida antes de que
comience la codificación. Al igual que los requisitos, el diseño se
documenta y forma parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible para
la máquina. Si el diseño se realiza de una manera detallada, la
codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la
prueba del programa. La prueba se centra en la lógica interna del
software, asegurando que todas las sentencias se han probado, y en las
funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.
Mantenimiento.Es indudable que el software una vez entregado
al cliente sufrirá cambios (posible excepción es el software empotrado).
Los cambios ocurrirán debido a que se hayan encontrado errores, que el
software deba adaptarse a posibles cambios.
El desarrollo de productos de software bajo este ciclo de vida
tiene los siguientes problemas:
1. - Los proyectos reales raramente siguen el flujo secuencial que
propone el modelo.
2.- Normalmente, es difícil para el cliente establecer explícitamente al
principio todos los requisitos. Este ciclo lo requiere y tiene dificultades
en entender posibles problemas que pudieran existir.
3.- El cliente debe tener paciencia. Hasta llegar a las etapas finales del
desarrollo del proyecto.
24
3.4.2 Modelo rápido basado en prototipos.
En muchas organizaciones los requerimientos de la tecnología
avanzan tan rápido que el lapso de tiempo que transcurre entre la
obtención de requerimientos y la liberación de una versión final del
producto resulta poco práctico, ya que cuando ésta es utilizada, las
necesidades han cambiado, esto sucede regularmente cuando se utiliza
una metodología como la de Cascada. La solución que muchas
organizaciones utilizan es el de aplicar un modelo como el de espiral o el
basado en prototipos. Estos modelos son iterativos y requieren la
creación de uno o más prototipos como parte del proceso de desarrollo
de software (el modelo de espiral se describe en la siguiente sección).
De acuerdo con Pressman (1997), una definición de un prototipo
en software podría ser: "Un modelo del comportamiento del sistema que
puede ser usado para entenderlo completamente o ciertos aspectos de
él y así clarificar los requerimientos... Un prototipo es una
representación de un sistema, aunque no es un sistema completo, posee
las características del sistema final o parte de ellas".
La figura 3.3 muestra el modelo rápido de prototipos.
Diseño y
desarrollo del
Especificaciones • prototipo
iniciales
Crear nuevas
especificaciones
Pruebas e
integración del
prototipo
Evaluar el
prototipo ^ Liberar
Versión
FIGURA 3.4 MODELO RÁPIDO DE PROTOTIPOS(MCCONNELL,1996)
Principalmente este modelo asume que las especificaciones
completas del software son conocidas antes de que el software sea
diseñado e implementado. El software es desarrollado de manera
25
¡ncremental. El punto central de este modelo es que la versión final
producida es considerada como la más aceptada de todas las secuencias
anteriores.
El principal inconveniente de este tipo de desarrollo es que no se
conoce al comienzo del proyecto lo que se tardara en crear un producto
aceptable. Otra desventaja que presenta este modelo es: la
dependencia de las herramientas de software para el éxito ya que la
necesidad de disminución de incertidumbre depende de las iteraciones
del prototipo, entre más iteraciones existan mejor y esto último se logra
mediante el uso de mejores herramientas, que lo hace dependiente de
las mismas.
También, no es posible aplicar la metodología a todos los proyectos de
software y, finalmente, la mala interpretación que pueden hacer los
usuarios del prototipo, al cual pueden confundir con el sistema
terminado. Por otro lado una ventaja es que los clientes pueden ver
signos de progreso y tienden a ponerse menos nerviosos con la
adquisición eventual de un producto.
3.4.3 El modelo de espiral.
McConnell (1996) menciona que el modelo de espiral es un modelo
de ciclo de vida orientado a riesgos que divide un proyecto de software
en mini proyectos. Cada mini proyecto se centra en uno o más riesgos
importantes hasta que todos estén controlados. El término riesgo se
refiere a especificaciones no comprendidas correctamente, problemas de
ejecución importantes y arquitecturas complicadas.
El modelo espiral desarrollado por Barry Boehm para Ingeniería de
Software agrupa las mejores características del modelo del ciclo de vida
clásico y de prototipos. Pero también agrega nuevas funciones que no
están incluidas en los otros modelos, como el análisis de riesgo. El
modelo espiral define cuatro actividades principales para el ciclo de vida.
• Planificación. La determinación de los objetivos del proyecto,
alternativas y restricciones.
• Análisis de Riesgo. El análisis de alternativas y la identificación y
solución de riesgos.
• Ingeniería. Desarrollo del producto.
• Evaluación del cliente. El asentimiento de los resultados.
26
Análisis de Riesgo
\ \
-1
Ingeniería
FIGURA 3.5 CICLO DE VIDA DE ESPIRAL(PRESSMAN, 2000)
El modelo es representado por una espiral dividida en cuatro
cuadrantes, donde cada uno describe las actividades mencionadas
anteriormente. El modelo espiral utiliza un esquema de desarrollo
iterativo cuya primera iteración comienza en el centro del círculo e,
¡ncrementalmente, se va desplazando hacia afuera. Las siguientes
iteraciones sucesivas son versiones más completas del software que
está siendo construido. Al principio de cada iteración del ciclo de vida se
hace un análisis de riesgo, mientras, por el otro extremo, la revisión del
proyecto se realiza al final de la iteración. Así, se puede contrarrestar
cualquier riesgo observado en el tiempo preciso.
El modelo espiral es visto como un enfoque más realista para el
desarrollo de grandes sistemas de software. Usa un método evolutivo
para desarrollo y prototipos como una técnica de reducción de riesgo
(pese a que los prototipos pueden ser usados en cualquier etapa dentro
del ciclo de vida). También utiliza el enfoque de sistematización y el
"desarrollo en etapas" del ciclo de vida clásico, pero, con la diferencia
que todos están incorporados dentro del esquema iterativo planteado
por el modelo espiral.
27
3.4.4 El modelo de desarrollo evolutivo.
El desarrollo evolutivo es una metodología de desarrollo de
software muy relacionada con, pero claramente distinta de, desarrollo
por prototipos. El énfasis esta puesto sobre la importancia de obtener un
sistema de producción flexible y expandible. Así, si los requerimientos
cambian durante el desarrollo del sistema, entonces con un mínimo de
esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos
de software es que el desarrollo evolutivo busca reemplazar el viejo
sistema con uno nuevo que tendría la propiedad de satisfacer los nuevos
requerimientos lo más rápido posible. En contraste, el modelo de
prototipos usa un enfoque iterativo solo para determinar los
requerimientos organizacionales. Por lo tanto, el tiempo tomado entre
cada iteración es más importante para el desarrollo evolutivo. En la
figura 3.4 se puede ver gráficamente esta diferencia.
El desarrollo evolutivo asume que los requerimientos de un
proyecto están sujetos a cambios continuos, por lo cual es necesario
definir una estrategia de desarrollo que refleje esta situación. En
cambio, el desarrollo orientado a prototipos, así como los anteriores,
asume que los requerimientos "reales" existen y se vale de las
iteraciones del prototipo para establecerlos y modelarlos.
La idea entonces de la metodología de desarrollo evolutivo es
estar liberando constantemente una nueva versión del sistema que sea
completamente funcional; cada sistema, producto de las iteraciones
sucesivas, tendría incorporado los nuevos requerimientos que han sido
posible identificar y que no estarían considerados en la versión anterior.
28
Investigación
Preliminar
Desarrollo
del Producto
Implementación, Uso y
Evaluación
Definición del problema y especificación inicial en
base a los requerimientos definidos.
Desarrollo del software en base a un proceso con
énfasis en la rapidez de la fabricación.
Implantación y uso del software en ambiente de
explotación, monitoreo de los nuevos
reauerimientos.
Versiones del
Software
Volver a realizar
especificaciones
Re-definición del problema en base a los nuevos
requerimientos.
FIGURA 3.6 MODELO DE DESARROLLO EVOLUTIVO(PRESSMAN,1997).
Así, las etapas del desarrollo evolutivo tienen por objetivo
extender los incrementos deun producto de software operacional, en las
direcciones determinadas por la evolución de la experiencia operacional.
El modelo de desarrollo evolutivo puede ser idealmente asociado a
un lenguaje de aplicación de cuarta generación y, mejor aún, a
situaciones en que el usuario dice: "yo no puedo hablarte sobre lo que
yo quiero, pero yo lo reconocería si lo viese". Así, este método
entregaría al usuario rápidamente una capacidad operativa inicial y,
además, establecería una base real de operación para determinar las
mejoras subsecuentes en el producto.
Pero existen algunas dificultades técnicas que no pueden dejar de
ser mencionadas, por ejemplo:
• No facilita la integración de aplicaciones que han sido
desarrolladas como sistemas independientes.
• Facilita la posibilidad de que existan casos de "esclerosis de
información", en el sentido que trabajos temporales alrededor de
algunas deficiencias del software se solidifican como poderes
inmodificables a la evolución. Es decir, en la medida que se
evoluciona, esta misma facilidad a la evolución llevaría a que no
sea posible seguir evolucionando.
29
• Pueden ocurrir que el software nuevo es un reemplazo incremental
de un subsistema dentro de un gran sistema existente. Si el
sistema existente está pobremente modularizado, es obvia la
dificultad en hacer que la nueva versión se acople al resto.
El método evolutivo tiene la gran ventaja de reconocer la
existencia de constantes cambios en los requerimientos, a partir de
esto, proponer una solución, la cual es válida para la solución de ese
problema pero que no resolvería la inquietud original, esto es que el
método no facilita elementos que permitan reducir la distancia
conceptual entre el desarrollador y el usuario.
Lehman propone que la evolución de un sistema de software esta
sujeta a 5 leyes, las cuales ha determinado a partir de observaciones
experimentales de varios sistemas, como los grandes sistemas
operativos:
1. Cambio Continuo. Un programa utilizado en un ambiente del
mundo real debe cambiar o cada vez será menos útil en ese
ambiente.
2. Complejidad creciente. A medida que un programa en evolución
cambia, su estructura se hace más compleja, a menos que se
lleven a cabo esfuerzos activos para evitar este fenómeno.
3. Evolución del programa. La evolución del programa es un
proceso autorregulador, y una medición de atributos del sistema,
como el tamaño, el tiempo entre versiones, el número de errores
advertidos, etc.; revela las tendencias estadísticas significativas y
las características invariantes.
4. Conservación de la estabilidad organizativa. Durante el
tiempo de vida de un programa, su rapidez de desarrollo es casi
constante e independiente de los recursos dedicados al desarrollo
del sistema.
5. Conservación de la familiaridad. Durante el tiempo de vida de
un sistema, la evolución del cambio del sistema en cada versión
es, aproximadamente, constante.
Lehman (1980) comenta que, con el método evolutivo, se
configura una nueva problemática en el desarrollo de sistemas; es decir,
la crisis se expande ahora en el sentido que no sólo se requiere reflejar
lo más fielmente posible las necesidades del usuario, sino que ahora los
ambientes en que el sistema está inserto están sujetos a cambios y
estos cambios inciden en la efectividad del software desarrollado.
30
3.4.5 Modelo Orientado a Objetos.
Para aquellas aplicaciones relativamente grandes, que deben ser
actualizadas frecuentemente, o que pertenecen a una línea de
aplicaciones afines (con características de datos en común), debe
considerarse la posibilidad de codificar utilizando orientación a objetos,
ya que esto aseguraría la privacidad de datos, la reutilización de código,
la facilidad de mantenimiento y la posibilidad de modelar el sistema
utilizando diseño orientado a objetos y sus ventajosas características:
• Clases.
• Herencia.
• Polimorfismo.
• Sobrecarga de métodos y operadores, etc.
Y, como consecuencia, un aumento de la integridad del sistema.
El costo de contar con un equipo experimentado en dicha técnica
de programación es considerablemente mayor que en las anteriores.
FIGURA 3.7 MODELO ORIENTADO A OBJETOS(PRESSMAN, 1988).
Las características del modelo orientado a objetos son:
No se prescribe una secuencia lineal de pasos.
El desarrollo es iterativo e incremental combinando diagramas
formales con técnicas informales según el problema.
Existen micro y macro fases.
Combinación del modelo de cascada y el modelo de espiral.
Macroproceso.
Es similar al modelo de cascada y sirve como marco de control
para el micro proceso.
Establecer requerimientos esenciales (conceptualización).
Desarrollar un modelo del comportamiento esperado (análisis).
31
• Crear una arquitectura (diseño).
• Evolucionar la implementacion (evolución).
El modelo orientado a objetos es el más novedoso, revolucionario
y utilizado en los últimos años, su auge ha crecido exponencialmente,
debido a las características tan particulares que posee, lo cual lo ha
convertido en la base para prácticamente todos los lenguajes de
programación.
32
3.4.6 Elección de un modelo.
Después de haber estudiado algunas características de algunos de
los ciclos de vida existentes más reconocidos, la siguiente tabla deberá
ayudar para hacer la elección correcta de la metodología. Los criterios
tomados son heredados de McConnell (1996) para la selección de un
modelo. Las clasificaciones son: malo, medio y excelente. Las
características expuestas aquí pueden variar de acuerdo a como sea
aplicada la metodología.
Capacidades
del modelo
Trabaja con
poca
identificación de
los
requerimientos
Trabaja con
poca
comprensión
sobre la
arquitectura
Genera un
sistema
altamente fiable
Genera un
sistema con
amplio
desarrollo
Gestionar
riesgos
Estar sometido a
una planificación
predefinida
Requiere poco
tiempo de
gestión
Permite
modificaciones a
medio camino
Ofrece a los
clientes signos
visibles de
progreso
Ofrece a la
directiva signos
visibles de
progreso
Requiere poca
sofisticación
para los
directivos y
desarrolladores
Cascada
Malo
Malo
Excelente
Excelente
Malo
Medio
Malo
Malo
Malo
Medio
Medio
Prototipos
Excelente
Malo a medio
Medio
Excelente
Medio
Malo
Medio
Excelente
Excelente
Medio
Malo
Espiral
Excelente
Excelente
Excelente
Excelente
Excelente
Medio
Medio
Medio
Excelente
Excelente
Malo
Desarrollo
evolutivo
Medio a
excelente
Malo
Medio a
excelente
Excelente
Medio
Medio
Medio
Medio a
Excelente
Excelente
Excelente
Medio
Orientado a
objetos
Medio
Malo
Excelente
Excelente
Excelente
Malo
Excelente
Excelente
Excelente
Excelente
Medio
33
3.5 Extreme Programming.
3.5.1 Introducción
¿Cuánto pagaría por un equipo de desarrollo que hace lo que usted
realmente quiere? ¿Y si fuesen capaces de decirle cuánto va a costar, de
manera que pueda elegir las tareas que son prioritarias, de cara a
alcanzar la fecha de entrega prevista?
Cualquier desarrollador, analista, técnico y, en general, cualquier
persona que haya participado en el diseño o desarrollo de un proyecto
informático, seguramente haya 'sufrido1 el yugo que supone estar
supeditado al cumplimiento de una determinada metodología.
Las metodologías que se aplican suelen ser rígidas; dejan poco
margen de maniobra y, lo que es peor, intentan ser demasiado
generalistas. Además son, en la mayor parte de los casos, metodologías
obsoletas, poco ágiles y que suponen una tremenda traba para el tipo
de proyectos que actualmente se desarrollan: proyectos pequeños,
ágiles, cambiantes y orientados hacia las nuevas (y también
cambiantes) tecnologías web.
Aplicar estas metodologías supone tener clientes descontentos,
jefes de proyectos confundidos, analistas aun más confundidos y
programadores desconcertados. Son difíciles de asimilar y de aplicar y,
por tanto, pierden su propio sentido rápidamente.
Ante esta situación surge una metodología que cubre, en gran
parte, las deficiencias de las tecnologías tradicionales, que aplica, entre
muchas otras cosas, técnicas de usabilidada la ingeniería del software.
Se trata de 'Extreme Programming' (o Programación Extrema como se
traduce), XP son sus siglas.
Beck (2000) dice que XP nos propone una serie de reducciones y
técnicas que persiguen un único fin: "la satisfacción del cliente".
34
3.5.2 Definiendo Extreme Programming.
Extreme Programming es una metodología de desarrollo de
software sencilla de usar y de aprender, que mejora un proyecto en
términos de comunicación, feedback, simplicidad y motivación.
Totalmente orientada a la satisfacción del cliente: se da al cliente el
software que quiere y cuando quiere. Hace hincapié en el trabajo en
equipo.
3.5.3 Elementos de la Metodología XP.
Los 3 actores principales que participan en la aplicación de esta
metodología son:
El cliente. Describe cual será el valor para el negocio, define qué es lo
que se debe hacer primero y qué es lo que se debe calendarizar para
hacer, y define las pruebas que muestren que el software hace lo que
realmente se requiere.
El programador. Es el encargado de analizar, diseñar, probar
programar e integrar el sistema. Ellos estimarán la dificultad de las
historias narradas por el cliente, y trazaran el ritmo en el que
proporcionarán los resultados al cliente.
El administrador. Es la unión entre el cliente y el desarrollador y trata
de que se forme un buen equipo entre ellos, y trata de hacer que el
proceso sea lo más suave posible.
Las prácticas que están involucradas dentro del ciclo de vida del
proyecto son:
Planificación
• Se redactan las historias de usuarios.
• Se crea un plan de entregas.
• Se hacen pequeñas entregas pero frecuentes.
• Se controla la velocidad del proyecto.
• Se divide el proyecto en iteraciones.
• Al comienzo de cada iteración se traza el plan de iteración.
• Se rota al personal.
• Cada día se convoca una reunión de seguimiento.
• Corregir la propia metodología XP cuando falla.
35
Diseño
Simplicidad.
Elegir una metáfora para el sistema.
Usar tarjetas CRC (Cargo, Responsabilidad y Colaboración) en las
reuniones de diseño.
Crear soluciones puntuales para reducir riesgos.
No se añadirá funcionalidad en las primeras etapas.
Reaprovechar cuando sea posible.
Desarrollo
• El cliente está siempre disponible.
• Se debe escribir código de acuerdo a los estándares.
• Desarrollar la unidad de pruebas primero.
• Todo el código debe programarse por parejas.
• Sólo una pareja se encargará de integrar el código.
• Integrar frecuentemente.
• Todo el código es común a todos.
• Dejar las optimizaciones para el final.
• No trabajar más de 40 horas semanales.
Pruebas
• Todo el código debe ir acompañado de su unidad de pruebas.
• Todo el código debe pasar las unidades de pruebas antes de ser
implantado.
• Se deben ejecutar pruebas de aceptación a menudo y publicar
los resultados.
Ventajas de usar Extreme Programming.
Algunas de las ventajas que representa el utilizar esta metodología
son:
• Reducción de atrasos en caso de existir rotación de personal
en el área de desarrollo.
• Mejor documentación de los sistemas.
• Reducción de la curva de aprendizaje de los programadores.
• Mayor involucramiento de los clientes y usuarios.
• Incrementa los conocimientos de los miembros del equipo
dada la rotación de roles.
36
Desventajas de usar Extreme Programmíng.
• Se requiere de un proceso de adaptación mayor a la
metodología.
• Los programadores no siempre están dispuestos a participar
usando esta metodología.
Desarrollada por Kent Beck(2000) Extreme programming es un
conjunto de prácticas que la comunidad de desarrolladores esta
adoptando para dar solución a los problemas de una manera rápida y de
calidad. Involucra conceptos de planeación, diseño, implementación,
deployment y mantenimiento. Pero sobre todo basa mucho sus técnicas
a la forma en la que los equipos se desenvuelven.
La idea de exponer esta técnica de desarrollo de software de una
manera separada de las demás, es debido a que esta es una técnica
especial y diferente a las ya expuestas, ya que involucra muchos
factores y técnicas de administración de proyectos y equipos de alto
rendimiento.
3.6 Conclusiones.
Distintos proyectos tienen necesidades diferentes, incluso si todos
tienen que ser desarrollados rápidamente. Aquí se han descrito algunos
de los modelos de desarrollo de software, los cuales tienen diferentes
características, la pregunta de ¿cual de estos modelos debe ser
utilizado? Nos lleva a evaluar las características distintivas del proyecto
y tratar de utilizar el que más se adecué a ellas, ya que no existe un
modelo de desarrollo estándar.
Lo interesante de esto es que todo el equipo de desarrollo tenga
un camino bien definido y no les suceda lo que a Alicia, que no
importaba cual camino siguiera si no importaba su destino. Una de las
cosas más importantes dentro del desarrollo de un proyecto es la
selección del modelo adecuado de desarrollo. Sin embargo, hay un
factor que no se puede dejar a un lado que es el factor humano, del cual
se hablara en el capítulo siguiente.
37
Capítulo 4. Equipos de alto rendimiento.
4.1 Introducción.
La eficiencia humana es algo que todos quieren y que se aprecia
universalmente cuando se alcanza. Hay dos maneras de aumentarla:
concentrándose en el individuo ó concentrándose en el equipo.
Desde la antigüedad el hombre tuvo una marcada necesidad de
colaborar y realizar tareas de manera conjunta con otros hombres. En
las organizaciones actuales surgen las mismas necesidades dada la
magnitud de las tareas a realizar y la rapidez con la que se desea sean
ejecutadas dichas tareas.
Regularmente a estas agrupaciones de hombres trabajando juntos
se les denomina equipo. El éxito de cualquier equipo depende
principalmente de los individuos que lo componen; esto no es ningún
secreto. Si los miembros de un equipo no se comunican efectivamente
entre sí, se hallan en conflictos y carecen de motivación hacia lograr los
objetivos comunes, seguramente no llegarán a lugar alguno.
El concepto de equipos de alto rendimiento tal como se verá, nace
en Inglaterra y en Suecia alrededor de 1950 y abarca también términos
como cohesión, rendimiento, autonomía y confianza.
4.2 Definiciones básicas.
Parker (1993) define a un equipo como: "Un grupo de personas
interdependiente cuyos miembros están de acuerdo en los objetivos, las
tareas y los pasos necesarios para su realización".
Sin embargo McConnell (1996) menciona que "un equipo de
trabajo es algo mas que un conjunto de personas que desean trabajar
juntas para alcanzar un objetivo". Katzenbach y Smith, en su libro The
Wisdom of teams, definen un equipo como "Un número de personas
pequeño, con habilidades complementarias que están comprometidas en
un propósito, objetivos de rendimiento y con un enfoque común en el
que todos sean responsables ante todos". Esta definición nos lleva ya un
paso más adelante y no solo habla de cooperación o acuerdos comunes.
38
El punto de partida para desarrollar el trabajo en equipo es que
todos los miembros comprendan la dinámica de dicho trabajo como las
dimensiones básicas a la luz de las cuales se puede medir el rendimiento
del grupo.
Hay que diferenciar también que un grupo no siempre es un
equipo. Algunos proyectos se pueden llevar a cabo por un grupo de
personas que cooperan, pero que no forman un equipo. Algunos
proyectos no llegan al nivel de compromiso que supone un equipo.
4.2.1 Variaciones en la productividad.
Los investigadores han encontrado diferencias del orden de 10 a 1 en la
productividad individual. Los investigadores también han encontrado
diferencias importantes en los niveles de productividad de los equipos
completos. Después de analizar 69 proyectos, llegaron a la conclusión
de que los mejores equipos eran al menos 4 veces más productivos que
los peores (Bohem, 1981 dice en McConnell, 1996). DeMarco y Lister
identificaron diferencias de productividad de 6 a 1 en 166
programadores profesionales con características similares de 18
organizaciones diferentes.
Estos estudios indican las variaciones que puede haber entre losequipos
cuando se han ocupado ciertas técnicas de administración y formación
de equipos y cuando esto no se ha realizado y se sigue manejando de
manera empírica.
4.3 Tipos de equipos.
A través del tiempo y de acuerdo a ciertos factores y
características como lo son el compromiso y la autonomía, se han
generado algunas clasificaciones para los diferentes tipos de equipos
que se han generado o que han evolucionado.
Katzenbach y Smith (1995) hacen una comparación que muestra
las etapas de las personas trabajando en equipo.
1. Trabajando en grupo. Los miembros de este grupo no ven razón
para convertirse en equipo. Ellos pueden compartir información,
pero las responsabilidades, metas y productos pertenecen a
individualidades.
2. Pseudo equipo. Este grupo de personas define el trabajo a
realizar, pero no se enfoca en el desempeño colectivo, la
individualidad de los miembros va en contra del desempeño
colectivo de la organización.
39
3. Equipo potencial. Este grupo intenta mejorar su desempeño, sin
embargo, requieren explicaciones adicionales del propósito y de
las metas trazadas, así como más disciplina para establecer un
objetivo común. Estos equipos abundan en las organizaciones.
Aún no tienen determinada la responsabilidad colectiva.
4. Equipo real. Consiste en un grupo de personas con habilidades
complementarias, quienes están comprometidos con metas y
objetivos comunes. Han aprendido a confiar los unos de los otros.
5. Equipo de alto desempeño o autodirigido. Este equipo cumple
con todos los criterios de un equipo real, pero sus miembros
también están comprometidos con sus compañeros de trabajo. El
desempeño de estos equipos es mayor al de todos los
mencionados anteriormente.
En la actualidad la tendencia de algunas empresas es hacia que los
equipos vayan evolucionando de tal forma que finalmente lleguen a ser
considerados como equipos de alto desempeño o autodirigidos, para
poder clasificar esta tendencia, y de acuerdo al nivel de autonomía que
los equipos van adquiriendo, Shonk (1992), realiza la siguiente
clasificación:
1. Equipos de sugerencia. Estos equipos son temporales y trabajan
en problemas específicos. El equipo tiene poca autoridad en
implantar sus sugerencias, la jerarquía tradicional aún sobrevive.
Estos equipos son útiles para recopilar ideas en tópicos, como
reducción de costos o incremento de la productividad.
2. Equipos de solución de problemas. Estos equipos identifican y
analizan problemas, desarrollando modos de solución,
generalmente están compuestos por un supervisor y de 5 a 8
elementos. Estos equipos se conocen también como círculos de
calidad o Task Forces.
3. Equipo semiautónomo. Cuentan con un supervisor, desarrollan
sus planes y organizan su trabajo diario.
4. Equipos de alto rendimiento. Estos equipos administran su
trabajo en base diaria, usualmente:
• Fijan metas en sincronía con las de la organización.
• Planean cómo lograr esas metas.
• Definen y solucionan problemas en su área.
> • Toman decisiones diarias dentro de sus límites de autoridad.
• Calendarizan el trabajo.
• Contratan nuevos miembros
40
La evolución hacia los grupos autodirigidos implica que los
individuos aporten no sólo sus manos (bajo el esquema de "mano de
obra" tradicional), sino también sus mentes. Es necesario que el
individuo piense y aprenda para que la organización también evolucione.
4.4 Equipos de alto rendimiento.
En un estudio publicado en 1993. B. Lakhanpal (Buchzhold, 1993)
se informo sobre la relación entre la cohesión de los grupos, las
posibilidades individuales y la experiencia con el rendimiento global del
proyecto. Los proyectos duraban de 6 a 14 meses y requerían de 4 a 8
desarrolladores. Lakhanpal descubrió que la unión del grupo contribuía
mas a la productividad que las capacidades o experiencia individuales de
los miembros del proyecto. Los administradores regularmente escogen a
los miembros del equipo basándose en el nivel de experiencia, cuando
en realidad, según Lakhanpal los miembros del equipo deberían ser
escogidos de acuerdo a sus posibilidades para contribuir a formar un
equipo unido en primer lugar y después en sus posibilidades
individuales.
Los equipos autodirigidos nacen en Inglaterra y Suecia alrededor
de 1950, donde unos mineros se agrupan en equipo y comienzan a
trabajar de una manera distinta a lo que se hacia entonces. Al realizar
sus actividades se ayudaban entre sí y se distribuían las tareas según
sus capacidades, de tal manera, que lograban producir más y mejor.
Como resultado de esta forma de trabajo bajo el ausentismo, así como
los accidentes y la productividad fue más alta (Moreno 1991).
4.4.1 Definición de equipos de alto rendimiento.
Ward y Holcomb (1995) dicen que: "Los equipos autodirigidos son
grupos pequeños de empleados que tienen responsabilidades día a día y
que se administran a ellos y a su trabajo".
Por otra parte, según Picsak y Hauser (1996), un equipo
autodirigido: "Es un grupo de empleados altamente entrenados,
(generalmente de 6 a 15), que es completamente responsable de
terminar un segmento bien definido de un producto".
De acuerdo a estas definiciones podemos darnos cuenta que los
equipos autodirigidos deben contar con ciertas características como son:
• El tamaño del grupo autodirigido es pequeño.
• Los objetivos están claramente identificados.
41
• La autonomía, cada uno es responsable de su parte del proceso.
• Son individuos que cuentan con el suficiente poder de decisión
para sacar adelante un proyecto por si mismo como equipo
formando una entidad sólida.
Se podría definir como equipo de alto rendimiento a "un grupo
pequeño de personas altamente capacitadas que trabajan de manera
conjunta, basándose en objetivos comunes para lograr las metas
propuestas, y que cuentan con características individuales de motivación
y comunicación que les permiten tener un alto grado de cohesión y los
convierte en una sola entidad".
4.4.2 Características de los equipos de alto rendimiento.
De acuerdo con McConnell (1996), los equipos de alto rendimiento
cuentan con las siguientes características que los distinguen de los
equipos comunes:
• Una visión y objetivo compartidos.
• Un sentido de identidad del equipo.
• Una estructura dirigida por resultados.
• Miembros del equipo competentes.
• Un compromiso con el equipo.
• Confianza mutua.
• Interdependencia entre miembros del equipo.
• Comunicación efectiva.
• Un sentido de autonomía.
• Un sentido de enriquecimiento.
• Tamaño del equipo pequeño.
• Un alto nivel de disfrute.
• Visión y objetivo compartidos.
Antes de que el proyecto se ponga en marcha el equipo debe
obtener una visión y objetivos comunes. Si no se tiene una visión
compartida no hay lugar para un equipo de trabajo de alto rendimiento.
Compartir una visión es muy útil para que se efectúe un desarrollo
rápido en muchos niveles, esto simplifica la toma de decisiones, crea
confianza entre los miembros del equipo y evita que se cometan ciertos
errores.
Un equipo efectivo crea un nivel de confianza y cooperación que le
permite alcanzar mayor rendimiento que un conjunto de personas con
42
igual destreza. Para que un equipo unido sea productivo, necesita tener
un enfoque compatible con el de la organización a la que pertenece.
La visión debe ser elevada para que surta un efecto de motivación.
El equipo necesita que se le presente un desafío, una misión, y que se le
vincule directamente, o sea que esta misión este de acuerdo con su
nivel de desempeño. En ocasiones se suelen dar misiones absurdas a
equipos que cuentan con un nivel y capacidad intelectual mayores y esto
suele ser desmotivante. Un punto muy importante es la forma en que
esta misión sea presentada a los miembros del equipo, de esto
dependerá si el equipo lo ve como un reto o como trabajos forzados.
• Sentido de identidad del equipo.
A medida que los miembros del equipo trabajan juntos hacia su
visión común, comienza a percibir una sensación de identidad del
equipo. Algunos equipos tienen nombres, otros como el famoso Black
Team de IBM