Cibernética organizacional y metodologías ágiles de ...
76
1 Cibernética organizacional y metodologías ágiles de desarrollo de software LUIS ALBERTO PINEDA SOTO Director Robe rto Za rama UNIVERSIDAD DE LOS ANDES FACULTAD DEINGENIERÍA DEPARTAMENTO DE INGENIERÍA INDUSTRIAL BOGOTA D.C. 2008
Transcript of Cibernética organizacional y metodologías ágiles de ...
1
Cibernética organizacional y metodologías ágiles de desarrollo de software
LUIS ALBERTO PINEDA SOTO
Director
Roberto Zarama
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
BOGOTA D.C. 2008
2
Cibernética organizacional y metodologías ágiles de desarrollo de software
LUIS ALBERTO PINEDA SOTO
Tesis de Grado
Director
Roberto Zarama
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
BOGOTA D.C. 2010
Nota de aceptación.
3
____________________________
____________________________
____________________________
____________________________
Director de Proyecto
____________________________
Jurado
____________________________
Jurado
Bogotá D.C. Diciembre 2008
4
Tabla de contenido
1. Introducción.......................................................................................................................... 6
1.1 Contexto.......................................................................................................................... 6
1.2 Situación actual................................................................................................................ 7
1.3 Formulación del problema ................................................................................................ 8
2. Objetivos............................................................................................................................... 9
2.1. Objetivo General ............................................................................................................. 9
2.2. Objetivos Específicos ....................................................................................................... 9
3. Ingeniería de Software ......................................................................................................... 10
3.1 Historia.......................................................................................................................... 10
3.2 Problemas en la industria del software ............................................................................ 11
3.3 Metodologías Tradicionales ............................................................................................ 12
3.3.1 Modelo cascada....................................................................................................... 12
3.3.2 RUP......................................................................................................................... 14
3.3.3 Dificultades ............................................................................................................. 16
3.4 Metodologías Ágiles ....................................................................................................... 18
3.4.1 Definición................................................................................................................ 18
3.4.2 Características ......................................................................................................... 18
3.4.3 Historia ................................................................................................................... 19
3.4.4 Fundamentos y principios ágiles ............................................................................... 20
3.4.5 eXtreme Programming (XP) ...................................................................................... 21
3.4.6 Dificultades y limitaciones para implementar ágil ...................................................... 29
4. Evolución de las teorías de administración y del desarrollo de software.................................. 31
4.1 Teorías Clásicas de la administración ............................................................................... 31
4.2 Teoría de las relaciones Humanas ................................................................................... 32
4.3 Teoría de Sistemas ......................................................................................................... 34
4.3.1 Sistemas socio‐técnicos y eXtreme Programming....................................................... 36
5. Cibernética.......................................................................................................................... 39
5.1 Historia.......................................................................................................................... 39
5.2 Definición ...................................................................................................................... 39
5
5.3 Conceptos de sistemas auto‐organizados ........................................................................ 41
5.4 El VSM (Viable System Model) ........................................................................................ 43
5.4.1 Introducción............................................................................................................ 43
5.4.2 Conceptos ............................................................................................................... 44
5.4.3 Estructura del VSM .................................................................................................. 48
6. VSM como herramienta de interpretación de las metodologías de desarrollo de software ...... 50
6.1 Comparación de metodologías RUP y eXtreme programming ........................................... 51
7. Equipos de trabajo auto‐organizados (SMWT) ....................................................................... 58
7.1 Introducción .................................................................................................................. 58
7.2 Ventajas y Desafíos de los SMWTs................................................................................... 59
7.2.1 Ventajas .................................................................................................................. 59
7.2.2 Desafíos .................................................................................................................. 60
7.2.3 Entorno cambiante vs Entorno estable...................................................................... 62
7.3 Factores determinantes para el éxito de los SMWTs......................................................... 62
7.4 Formación de SMWTs..................................................................................................... 68
7.5 SMWTs y eXtreme Programming (XP) .............................................................................. 70
8. Conclusiones ....................................................................................................................... 72
9. Bibliografía .......................................................................................................................... 74
6
1. Introducción
1.1 Contexto
La cibernética estudia el control y manejo de información en sistemas, en palabras de Weiner, su padre, es la ciencia de la comunicación y el control en los animales y las maquinas (Weiner 1948).
Esta disciplina provee herramientas para un análisis estructurado y detallado del comportamiento de los sistemas. A lo largo de su historia, ha demostrado claramente su aplicación en numerosas
áreas del conocimiento (por ejemplo distintas ingenierías y ciencias sociales). Dentro de las herramientas más valiosas desarrolladas por esta disciplina se encuentran las que facilitan el
estudio de sistemas, analizando para estos sus límites, complejidad y estructura.
La ingeniería de software es una disciplina joven, (40 a 50 años). Esta disciplina se propone modelar los procesos para la preparación, construcción y administración general de proyectos de
desarrollo de software. En la actualidad existen numerosas propuestas para la administración de proyectos, las más conocidas son eXtreme programming, Scrum, y RUP (Rational Unified Process).
La rápida evolución que presentan las tecnologías de información y la creciente complejidad de las necesidades relacionadas a sistemas de información en las organizaciones han dado surgimiento a
proyectos de software de proporciones inmensas. Dichos proyectos se caracterizan por tener gran cantidad de requerimientos funcionales y no‐funcionales, los cuales exigen de una gran capacidad
técnica y de trabajo en equipo para ser resueltos satisfactoriamente.
Los equipos de desarrollo cuentan con la habilidad técnica de sus integrantes y una metodología de desarrollo (en el mejor de los casos) como principales herramientas para diseñar y construir la
solución esperada por los stakeholders del proyecto. Sin embargo las herramientas mencionadas no han sido suficientes para resolver y lidiar eficientemente con las situaciones conflictivas que
frecuentemente se presentan en los proyectos de software. Estos, en su gran mayoría siguen fallando considerablemente en sus restricciones más básicas: tiempo, presupuesto.
7
1.2 Situación actual
Durante los últimos 20 años la inversión en software ha presentado un crecimiento acelerado (Cusumano, 2004), esto se debe a que las organizaciones soportan cada vez más su operación en
tecnologías de información. En 1995 se reportó en los Estados Unidos una inversión de $250 billones de dólares en el desarrollo de sistemas de información (Standish Group, 1995), se estima
que la cifra en la actualidad es mucho mayor. Un reflejo de lo anterior es el incremento en la demanda por profesionales en el área de la ingeniería de software, el U.S. Department of Labor
estima para la década del 2006 al 2016 un incremento del 38% en la demanda de ingenieros de software (Bureau of Labor Statistics, U.S. Department of Labor, 2008), cifra bastante superior a las
estimadas para las demás ocupaciones.
En la industria del software es bastante conocido y discutido un estudio realizado en el año 1995 conocido como The chaos report elaborado por The Standish Group. Este estudio presenta de
manera concisa cifras bastante desalentadoras referentes al desempeño de numerosos proyectos de software. Dentro de los resultados más impactantes resaltan los siguientes (Standish Group,
1995):
• 31.1% de los proyectos serán cancelados antes de terminar.
• 52.7% de los proyectos costarán 189% de presupuesto definido inicialmente.
• En promedio los proyectos toman el doble del tiempo que inicialmente tenían planeado.
En la actualidad las cifras no son muy diferentes (Standish Group, 2009):
• 44% de los proyectos finalizan con desfases significativos en presupuesto y cronograma.
• 24% de los proyectos son cancelados antes de terminar o son finalizados y el producto nunca usado.
Es claro entonces que el desempeño de los proyectos de software no ha cambiado sustancialmente en 15 años. La situación descrita conforma un problema de interés para
numerosos actores, principalmente para las organizaciones que invierten grandes sumas en el desarrollo de IT y no obtienen los beneficios esperados en el momento esperado. Adicionalmente las organizaciones que ofrecen servicios de desarrollo de IT se ven comprometidas
financieramente al perder el control de los costos y tiempos de sus proyectos.
8
1.3 Formulación del problema
Como consecuencia de la búsqueda de nuevas y mejores formas de administrar proyectos de software, durante los últimos años ha tomado fuerza el movimiento de metodologías ágiles de
desarrollo. Existen numerosas empresas que han adoptado correctamente estas nuevas metodologías y han visto como la tasa de éxito de sus proyectos ha mejorado considerablemente.
Un proyecto de software involucra numerosas personas en el proceso de desarrollo del software. En dicho proceso se tiene un abundante flujo de información de diferentes ámbitos (técnica,
humana, política, etc.) la cual no siempre es administrada de forma eficiente. Las metodologías de desarrollo de software tradicionales se han preocupado casi exclusivamente por la forma de
especificar y diseñar de forma correcta el software (información técnica), por otro lado las metodologías ágiles se han preocupado más por el diseño de procesos o mecanismos que administren los flujos de información de otros ámbitos (humano, político, etc.).
En el presente trabajo de investigación se desea estudiar bajo un marco de cibernética organizacional las metodologías ágiles de desarrollo de software. Esto con el fin de identificar la
razón de su éxito, sus limitaciones y posibles mejoras.
9
2. Objetivos
2.1. Objetivo General
La presente investigación se propone estudiar las metodologías ágiles de desarrollo de software bajo un marco de cibernética organizacional. Para lograr este objetivo primero es necesario crear un lenguaje común y generar un conocimiento básico de las dos disciplinas que abarca la investigación, es decir, la ingeniería de
software y la cibernética (principalmente organizacional). Una vez desarrollado este conocimiento general se puede entender cómo varios conceptos y principios de la cibernética organizacional son
traducidos al marco de la ingeniería de software y en particular a las metodologías ágiles de desarrollo de software.
2.2. Objetivos Específicos
1. Introducir la disciplina de la ingeniería de software y exponer sus principales retos.
2. Introducir los principios que rigen las metodologías ágiles de desarrollo de software.
3. Describir la metodología ágil eXtreme Programming.
4. Introducir el VSM (Viable System Model) de Stafford Beer.
5. Mediante el uso del VSM (Viable System Model) identificar las fortalezas y debilidades de
las metodologías RUP (Rational Unified Process) y eXtreme programming.
6. Comparar los principios de las metodologías ágiles de desarrollo de software con las ideas desarrolladas por la teoría de SMWT (Self Managed Work Teams) para encontrar posibles complementos a las metodologías ágiles.
10
3. Ingeniería de Software
3.1 Historia
Para entender los orígenes de la ingeniería de software resulta útil estudiar los proyectos
desarrollados a lo largo de la historia de IBM (Cusumano, 2004) ya que fue esta empresa la que primero se enfrentó a los retos que supone el desarrollo de software a gran escala.
Uno de los principales proyectos en la historia de IBM fue el desarrollo del sistema OS/360 llevado a cabo entre 1963 y 1966. En su momento, el proyecto fue el más grande esfuerzo que se había
visto en la industria del software. En ese proyecto participaron más de mil personas, las cuales durante tres años desarrollaron alrededor de un millón de líneas de código. El proyecto costó
medio millón de dólares (cuatro veces el presupuesto original) y fue terminado con un año de retraso (Cusumano, 2004), el producto fue lanzado al mercado con numerosos bugs o defectos.
Uno de los gerentes del desarrollo del OS/360 se inspiró en su experiencia en el proyecto y publicó
en 1975 uno de los clásicos de la ingeniería de software: The mythical Man Month. En esta obra, Frederick Brooks enuncia un descubrimiento crucial: para un proyecto de software de grandes
dimensiones, el número de personas y meses de trabajo no son variables intercambiables. Brooks encontró que adicionar personas a un proyecto que se encuentra atrasado resulta en atrasos aún
mayores, esto debido al crecimiento geométrico en los problemas de comunicación y coordinación que ocurren al incrementar el tamaño de los equipos de desarrollo (Cusumano, 2004). Esta conclusión es conocida en el mundo de la ingeniería de software como la ley de Brooks.
Las dificultades enfrentadas por IBM en los años sesenta, crearon conciencia en cuanto a la necesidad de definir y aplicar prácticas industriales, metodologías y herramientas que hicieran del
desarrollo de software una disciplina más formal, siendo esta disciplina lo que hoy se conoce como la ingeniería de software.
11
3.2 Problemas en la industria del software
Hacia el año de 1960 nacía la ingeniería de software, esto debido al aumento en el tamaño y la complejidad de las aplicaciones desarrolladas. La industria del software empezó a notar que en la
construcción del software se debía aplicar ingeniería, no bastaba con desarrolladores talentosos, era fundamental contar con mecanismos más formales para administrar y definir un proyecto de
software. En 1968 en Bruselas se dieron cita los principales protagonistas de la industria del software en la conferencia NATO de ingeniería de software, en ella se presentó el informe en el cual se describían las principales dificultades que enfrentaban las empresas de software en la
época.
Los principales problemas identificados por los conferencistas de NATO 1968 fueron (NATO
science committee, 1969):
• Falta de entendimiento y consenso entre los clientes y los diseñadores de los requerimientos.
• Brechas significativas en tiempos y costos planeados vs reales. Técnicas débiles de estimación de tamaño y complejidad del software.
• Variabilidad inmensa en la productividad de los programadores (hasta 26:1).
• Dificultades a la hora de dividir las labores de diseño y construcción, ya que un diseño completo de una aplicación implica un nivel de construcción considerable.
• Dificultad en el monitoreo del avance de los proyectos. El software no es tangible por lo tanto es difícil determinar el estado real de progreso de los proyectos.
• Comunicación ineficiente entre los integrantes de los grupos de desarrollo, causada por exceso de comunicación de información innecesaria, y la falta de automatización en la
comunicación de la información necesaria.
• El desarrollo de software mezcla constantemente en los proyectos las labores de investigación, desarrollo y producción. Por el contrario en industrias más tradicionales, estas labores se encuentran claramente diferenciadas y son ejecutadas en momentos del
tiempo separados.
• Dependencia del software con el hardware, lo que hace que la estandarización y despliegue del software constituya un proceso tedioso y costoso.
• Falta de mecanismos que permitan una reutilización eficiente de los componentes de software ya desarrollados que puedan ser de utilidad en diferentes proyectos.
• Costos del mantenimiento del software frecuentemente son superiores a los costos de desarrollo del mismo.
12
Si se comparan los problemas mencionados por el reporte NATO en 1968 con resultados obtenidos en reportes similares realizados en las últimas décadas es alarmante encontrar que poco ha cambiado1. La gran mayoría de estos problemas siguen presentándose frecuentemente en
los proyectos de software de actualidad, esto finalmente se traduce en proyectos cuyos cronogramas y presupuestos son mucho mayores a los estimados inicialmente.
Analizando el listado de problemas enunciados en la conferencia NATO cabe notar que aunque el
desarrollo de software de gran escala presenta retos significativos desde el punto de vista técnico, la mayoría de los problemas descritos no podrían incluirse dentro esta categoría (problemas
técnicos). Por el contrario, la mayoría de los problemas podrían incluirse en una categoría de problemas de organización y de comunicación, los cuales surgen de la interacción entre los diferentes individuos que participan en los proyectos, en especial la interacción entre el equipo de
desarrollo y los clientes. En general los problemas descritos se reducen a problemas de comunicación, coordinación y planeación de esfuerzos de los individuos partícipes de un proyecto
de software.
En la actualidad la comunidad de ingenieros y desarrolladores de software es bastante amplia y dinámica, los foros que se pueden encontrar en internet que tratan estos temas son numerosos y
cuentan con gran participación2. Una visita a cualquiera de estos foros confirma que la mayoría de los problemas que enfrenta el desarrollo de software se encuentran relacionados con el entendimiento y comunicación entre los desarrolladores, los directores de proyecto y los clientes.
3.3 Metodologías Tradicionales
3.3.1 Modelo cascada
El modelo en cascada fue uno de los primeros y más difundidos esquemas de desarrollo de software. Fue desarrollado en el año de 1970 por el norteamericano Winston Royce. En este se
establece una estructura secuencial de actividades a realizar a lo largo del ciclo de vida de un proyecto de software:
1 Uno de los estudios recientes más conocido es el Chaos Report del Standish Group, realizado por primera vez en el año de 1995. 2 Algunas de las paginas que frecuentemente discuten estos temas son www.stackoverflow.com, www.infoq.com,
13
El modelo en cascada especificaba el ideal de actividades a seguir, la iteración de estas actividades
solo se contemplaba como una contingencia a las dificultades que se pueden presentar en el transcurso de un proyecto, es decir las iteraciones no se encontraban planeadas para el proyecto. Algo que ocurría frecuentemente al usar el modelo cascada era que sólo se detectaban los
defectos más costosos del software en etapas avanzadas del proyecto (generalmente pruebas), lo cual es una consecuencia natural de la estructura secuencial del modelo, la cual solo arroja
software funcional en las etapas finales del proyecto.
El desarrollo de software tiene la particularidad de que se inserta una cantidad considerable de
errores en la etapa de construcción (codificación), sin embargo estos errores son inherentes a la naturaleza propia del trabajo que se realiza, la corrección de los mismos en la mayoría de los casos
no supone mayor esfuerzo por parte de los desarrolladores. Por otra parte, los errores que resultan letales y realmente costosos para un proyecto de software son los que ocurren en la etapa de diseño (Cusumano, 2004). El modelo en cascada pretende trazar una delimitación clara
entre el diseño y la construcción del software, sin embargo esto ha probado ser casi imposible (Cusumano, 2004), ya que entre más detallado sea el proceso de diseño más se aproxima al
proceso de construcción del producto.
Por otra parte, uno de los elementos en los que el modelo de cascada hacía mayor énfasis era en
la documentación del software. En palabras de Winston Royce: “The first rule of managing software development is ruthless enforcement of
documentation requirements” (Royce, 1970)
14
Este énfasis en la documentación era entendible para el entorno de la década de los 70, donde los lenguajes de programación eran complejos, poco intuitivos y altamente acoplados al hardware
donde el código se ejecutaría. Por estas razones los requerimientos, el diseño y el código debían ser meticulosamente documentados, de otra manera nadie sería capaz de realizar mantenimiento
del software o si quiera saber las funcionalidades principales del mismo. El modelo cascada consideraba importante la participación del cliente para el buen desarrollo de
un proyecto de software. Sin embargo, en la práctica el cliente sólo se veía involucrado en el levantamiento de requerimientos del software y en la etapa de pruebas, varios meses después de
iniciado el proyecto. Esto resultaba fatal para numerosos proyectos, ya que el cliente sólo interactuaba con el software una vez terminado el proyecto, momento en el cual es muy difícil y
costoso realizar ajustes o correcciones sobre el sistema.
3.3.2 RUP
A medida que la tecnología siguió evolucionando, lo mismo hizo la ingeniería de software. El
hardware, los lenguajes de programación y los sistemas operativos evolucionaron, los sistemas a desarrollar se volvieron cada vez más grandes y complejos. La evolución del modelo cascada fue el
modelo RUP (Rational Unified Process), este modelo presenta una estructura más flexible y se esfuerza por especificar con mayor detalle cada una de las fases a seguir en un proyecto de software. El modelo presenta un mayor dinamismo frente al propuesto por el modelo cascada. Se
motiva al director de proyecto en ajustar el modelo RUP a las necesidades particulares del proyecto a realizar, las iteraciones de las distintas etapas se planean desde el inicio del proyecto y
se define una serie de artefactos de documentación escrita y visual para cada una de las fases del proyecto.
15
Modelo RUP http://www.ibm.com/developerworks/rational/library/content/RationalEdge/may04/4763_fig2.jpg
RUP fue concebido para combatir los riesgos de naturaliza técnica asociados a cualquier proyecto
de software, como lo son las tecnologías desconocidas, los requerimientos no especificados a tiempo y la complejidad en la arquitectura de los sistemas. Los principios que el proceso RUP
estableció para minimizar los riesgos mencionados fueron (IBM, 2005):
• Desarrollo iterativo: el desarrollo de software es un proceso creativo y como tal requiere de varias iteraciones sobre las distintas etapas del proyecto para lograr un producto de
calidad.
• Administración de requerimientos: el éxito de los proyectos de software depende de desarrollar un producto que cumpla efectivamente las necesidades del cliente. Las
“necesidades del cliente” se consignan en los requerimientos, estos requieren de un proceso de administración que contemple el levantamiento y refinamiento de los mismos.
• Arquitectura de componentes: a medida que los sistemas se hacen más complejos y de mayores proporciones se hace necesario estructurar la solución en componentes reutilizables con responsabilidades claramente diferenciadas. La utilización de
componentes facilita el mantenimiento y propicia el desarrollo paralelo de distintas funcionalidades de un sistema.
• Modelaje visual: constituye uno de los principales aportes del RUP a la ingeniería de software. RUP describe varios diagramas usados a la hora de diseñar software, estos diagramas son usados para modelar de manera gráfica la estructura, el comportamiento, y la interacción de un sistema.
16
• Monitoreo continuo de la calidad: la calidad general de producto se verifica meticulosamente al final de cada iteración.
• Administración del cambio: Los requerimientos, la arquitectura, los escenarios de pruebas y casi todos los aspectos relacionados a un proyecto de software inevitablemente cambian
con el paso del tiempo. Cada uno de los artefactos definidos para el proyecto deben administrarse a lo largo de todo el proyecto mediante una meticulosa documentación.
3.3.3 Dificultades
Las metodologías tradicionales intentaron imponer un proceso disciplinado de desarrollo de software con el objetivo de hacer el desarrollo de software más eficiente y predecible (Fowler,
2005). Para lograrlo desarrollaron procesos detallados inspirados en otras ingenierías con un fuerte énfasis en la planeación y documentación. El resultado de estos procesos meticulosamente diseñados fue una metodología plagada de burocracia en la cual hay tantas cosas por documentar
y planear que queda poco tiempo en para el desarrollo del software.
En realidad las metodologías tradicionales de software pueden verse como un reflejo del anhelo
por la predictibilidad. En general los humanos preferimos lo predecible, así podemos planear, controlar y asegurar un futuro deseado. RUP es una metodología predictiva, es decir pretende
anticipar todas las situaciones que pueden ocurrir en un proyecto (Fowler, 2005). En RUP se busca llegar a un nivel bastante alto de especificación de arquitectura y requerimientos con el fin de
minimizar los cambios que ocurran sobre cada uno de los componentes del sistema a desarrollar.
En el mundo de hoy, las organizaciones modernas dependen cada vez más de los sistemas de información que sustentan su operación. Los clientes exigen cada vez más proyectos, los cuales
son más complejos y para los cuales se tiene marcos de tiempo mucho más ajustados que en el pasado. Las tecnologías a usar evolucionan a un ritmo mucho más rápido del que las empresas y
los desarrolladores pueden asimilar. La lucha en busca de la predictibilidad en el contexto en el que se encuentra la ingeniería de software en el presente cada vez se hace más difícil.
En el último reporte del Standish Group se evidencia que:
• 44% de los proyectos finalizan con desfases significativos en presupuesto y cronograma.
• 24% de los proyectos fracasan (son cancelados antes de terminar o son finalizados y el producto nunca usado).
Desde hace unas dos décadas hasta el presente estas metodologías han sido las más usadas, sin embargo eso no quiere decir que son las que presenten mayor tasa de éxito de proyectos, o las que mejor acogida tengan entre los desarrolladores. De hecho la cantidad de documentación y
burocracia ha hecho que para muchos desarrolladores su día a día esté lleno de tareas tediosas y repetitivas.
17
Según Fowler (1995) los aspectos en los que las metodologías tradicionales han tenido mayores dificultades son los siguientes:
• Separar el diseño de la construcción: la analogía con la ingeniería civil o mecánica no ha funcionado muy bien. En estas disciplinas la máquina o estructura se diseña meticulosamente, en
esta fase es donde la mayoría del trabajo intelectual es realizado; la construcción en cambio se deja a personas menos calificadas intelectualmente. El software por el contrario a mostrado ser una disciplina en donde no se puede diferenciar claramente el diseño de la construcción (Fowler,
2005). En la ingeniería civil el 10% del costo y esfuerzo es empleado en la labor de diseño, mientras que en el software este esfuerzo haciende al 85% (Fowler, 2005). El diseño de software
es una tarea creativa, y resulta casi imposible planear o predecir una actividad creativa. El software es una actividad bastante diferente por lo tanto es importante acabar con la analogía con
las otras ingenierías y pretender obtener un diseño garantizado y definitivo de un sistema de software.
• Predictibilidad de los requerimientos: las metodologías tradicionales han plasmado los requerimientos como contratos con el cliente. El objetivo es dedicar suficiente tiempo a la especificación de los mismos para evitar que estos cambien en el futuro (agregar, eliminar o
modificar). Asumir que los requerimientos de software no van a cambiar en el transcurso del proyecto ha probado ser muy costoso. Pareciera más bien que es natural que los requerimientos
cambien, lo que hoy es una funcionalidad indispensable del software puede ser obsoleta para la organización dentro de seis meses, lo que hoy era considerado como un requerimiento deseable
puede probar ser indispensable dentro de seis meses. La naturaleza intangible del software entra a jugar un papel importante, ya que el valor real de una funcionalidad solo podrá ser apreciado
una vez el producto esté finalizado y sea puesto en uso.
• Personas como componentes: las metodologías tradicionales no tienen noción de los individuos, para el proceso las personas son vistas como componentes o recursos reemplazables, los cuales tienen roles determinados. La naturaleza predictiva de RUP va en contra de la naturaleza de los
“componentes” más importantes del proceso, las personas no son predecibles ni son componentes reemplazables. En realidad las personas han probado ser el factor más importante
para el éxito de los proyectos (Cockburn, Characterizing people as non‐linear, first‐order components in software development, 1999) y sin son tratadas como componentes reemplazables
la moral y la productividad se verán gravemente afectadas (Fowler, 2005).
18
3.4 Metodologías Ágiles
3.4.1 Definición
Las metodologías ágiles consisten en el conjunto de prácticas de desarrollo de software que promueven: la entrega frecuente de piezas funcionales de software, un esquema de trabajo
centrado en el trabajo en equipos auto‐organizados y auto‐gobernados, con miembros tanto del área técnica como del área de negocio. La preocupación constante de estos equipos de trabajo es responder de forma ágil y certera las necesidades reales del cliente (Beck, y otros, 2001).
3.4.2 Características
Como respuesta a las dificultades encontradas en las metodologías tradicionales de desarrollo, la comunidad inició la búsqueda de nuevas formas de hacer su trabajo. Las nuevas metodologías se
fundamentan en esquemas de trabajo mucho más ligeros y flexibles, que tienen los objetivos fundamentales de:
• Mantener el control del presupuesto y cronograma de los proyectos.
• Desarrollar software de calidad que satisfaga a tiempo las necesidades de los clientes.
Hacia mediados de los años noventa la comunidad del software presenció el surgimiento nuevas
metodologías que paulatinamente, al tiempo que ganaban aceptación, fueron bautizadas con el nombre de metodologías ágiles (Cusumano, 2004).
Como principal contraste frente a las metodologías tradicionales, el pensamiento ágil es más adaptativo que predictivo (Fowler, 2005). La naturaleza de las metodologías tradicionales es evitar
el cambio, mientras que las metodologías agiles invitan a el cambio (Fowler, 2005). Las metodologías tradicionales buscan la predictibilidad, el pensamiento ágil busca el control sobre lo
impredecible, la adaptabilidad.
Las metodologías ágiles están más orientadas a las personas que a los documentos y procesos (lo cual era habitual en las metodologías tradicionales). Proponen un desarrollo de software mucho
más participativo, en la cual resulta fundamental un nuevo tipo de relación con los clientes. Esta nueva relación exige un cliente adaptativo, que entienda la naturaleza cambiante de los
requerimientos, lo cual obliga a que las variables de presupuesto, tiempo y alcance deban ser balanceadas acorde a la realidad del proyecto. Generalmente las metodologías ágiles proponen
fijar presupuesto y tiempo, dejando que el alcance varíe de manera controlada (Fowler, 2005).
Adicionalmente, estas metodologías, argumentan que los ciclos de desarrollo excesivamente
largos no responden de la forma más eficiente a un entorno que cambia a una velocidad cada día mayor. La única manera de mantener el control en un entorno impredecible es un mecanismo de
19
retroalimentación frecuente (Fowler, 2005), este mecanismo son las iteraciones. Al final de cada iteración se debe tener una versión del software final (prototipo), el cual cuenta con un
subconjunto de las funcionalidades que tendrá el producto final. Estos prototipos son el mecanismo más eficiente para determinar el estado real de un proyecto, da la oportunidad al
equipo de desarrollo detectar defectos en integración de componentes y brinda espacio a los clientes para interactuar con el producto antes de estar terminado.
El proceso ágil es adaptativo en contraste con el predictivo de las metodologías tradicionales. Para
lograr un proceso adaptativo ágil
Finalmente, las metodologías ágiles sustentan que los más grandes problemas que enfrentan los
proyectos de software se encuentran relacionados a deficiencias en la comunicación entre los individuos que hacen parte de los proyectos (gerentes de proyecto, arquitectos, desarrolladores,
clientes, analistas, etc.). Por esta razón los desarrolladores son tratados como individuos y no como recursos.
3.4.3 Historia
De acuerdo con lo presentado por (Larman & Basili, 2003), la idea de utilizar ciclos cortos para
mejorar los procesos productivos, comenzó con la propuesta del ciclo de Planear‐Hacer‐Estudiar‐Actuar (PDSA, por sus siglas en inglés), elaborada en los años treinta por Walter Shewart. Desde los años cuarenta uno de los gurús de calidad más reconocidos, W. Edwards Deming, promovió el
PDSA como herramienta de mejora no solo operativa sino también administrativa.
Uno de los proyectos pioneros en el uso de ciclos cortos de desarrollo, a comienzo de los años
sesenta, fue el proyecto Mercury de la Nasa. En este proyecto se realizaban iteraciones de hasta medio día, al igual que se experimentó con prácticas que hoy en día se conocen como pair‐
programming3 y desarrollo dirigido por pruebas4 (TDD).
Sin embargo, fue durante la década de los setentas, como lo indica Larman y Basili, que las
prácticas de trabajo iterativo (hasta ese momento poco conocidas y consideradas como experimentales) fueron abandonadas por la adopción masiva de lo que se conoció como el modelo cascada, diseñado por Winston Royce en su artículo de 1970 “Managing the Development of Large
Software Systems”.
A inicios de los años 90 se hacía evidente que las metodologías tradicionales de desarrollo no
representaban la propuesta más adecuada frente al entorno del momento. Los proyectos presentaban nuevamente desfases inmensos en cronogramas y presupuestos. Como consecuencia
3 Pair programming es la práctica de tener dos prog ramadores desarrollando en un solo computador 4 TDD propone que los desarrolladores deben primero programar las pruebas del software y luego el software
20
se retomaron las prácticas experimentales de los años sesenta: iteraciones cortas, pair‐programming, TDD, entre otras. Estas nuevas metodologías buscaban agilidad y flexibilidad en el
desarrollo de software, ya que notaron que el entorno de un proyecto de software cambiaba a una velocidad cada vez mayor. En contraste con las metodologías tradicionales se propusieron el
ser fáciles de entender y de aplicar.
En el año 2001 se dieron cita representantes de las metodologías agiles más importantes de la época, eXtreme Programming, Scrum, DSDM, y reconocidas personalidades del mundo de la
ingeniería de software (Martin Fowler, Kent Beck, Dave Thomas, Alistair Cockburn, entre otros). El propósito de esta reunión fue el de unificar los principios, conceptos e ideas comunes a dichas
metodologías. El resultado de esta reunión se conoce como el Agile Manifesto, el cual es un documento bastante conocido y aceptado por ingenieros de software de la actualidad.
3.4.4 Fundamentos y principios ágiles
Existen varias metodologías ágiles, las más reconocidas en la actualidad son Scrum, eXtreme
Programming y DSDM. Todas las metodologías que se consideran ágiles comparten el mismo conjunto de principios o fundamentos. Los doce principios de la metodología ágil son (Agile
Manifesto, 2001):
1. Nuestra prioridad es satisfacer las necesidades del cliente a través de entregas tempranas y continuas de software funcional.
2. Dar bienvenida a cambios en los requerimientos. La metodología ágil comprende que los cambios muchas veces conducen a ventajas competitivas de los clientes.
3. Hacer entrega de software funcional en intervalos de pocas semanas o meses. Siempre prefiriendo intervalos cortos si es posible.
4. El cliente debe designar expertos de negocio que trabajen diariamente de lado de los desarrolladores.
5. Los proyectos son construidos por individuos motivados. Se debe generar un ambiente de motivación en donde se confíe en la capacidad y responsabilidad de los individuos.
6. El método más eficiente y efectivo para transmitir información en un equipo de desarrollo
es la comunicación cara a cara. 7. Software funcional es la principal medida del progreso de un proyecto.
8. Los procesos ágiles promueven un desarrollo sostenible. Los patrocinadores, desarrolladores, y usuarios deberían ser capaces de mantener un ritmo constante
indefinidamente. 9. Atención a la excelencia técnica y un buen diseño promueven la agilidad. 10. Simplicidad –el arte de maximizar la cantidad de trabajo no realizado‐ es esencial.
11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto‐organizados.
21
12. Regularmente el equipo reflexiona sobre cómo ser más efectivos, luego se realizan los respectivos ajustes para obtener el comportamiento deseado.
3.4.5 eXtreme Programming (XP)
Con el fin de interiorizar un poco más los conceptos de la metodología ágil se describirá una de las
metodologías ágiles más difundidas a nivel mundial eXtreme programming.
En el año de 1990 nació XP con el libro eXtreme Programming Explained:Embrace Change del
ingeniero de software norteamericano Kent Beck. Los seguidores de XP afirman que esta metodología funciona porque su enfoque es el desarrollo orientado al cliente, es decir XP está
encaminado principalmente a desarrollar el producto que el cliente necesita cuando lo necesita (Extreme Programming, 1999). XP contempla el cambio de las necesidades del cliente inclusive en etapas avanzadas del proyecto, por esto en todo momento se busca desarrollar software con
buenas características de mantenibiliad, es decir software que esté preparado para el cambio. XP propone que se debe motivar a los desarrolladores a constantemente pensar en el refactor
(modificar el código o su estructura sin modificar su funcionalidad) buscando simplicidad y facilidad de entendimiento.
Uno de los aspectos más destacados de XP frente a las metodologías tradicionales, es que en XP se enfatiza en la importancia del trabajo en equipo y se ve al equipo de una manera mucho más
amplia. Es decir, en XP el equipo deja de ser exclusivamente el equipo de desarrollo, el equipo ahora incluye a los gerentes del proyecto y a los expertos de negocio del lado del cliente y a los usuarios finales.
Principios XP
• Simplicidad: Se debe motivar en todo momento a los desarrolladores a producir código
simple, y sencillo. Se quiere que el código de un desarrollador pueda ser entendido, extendido y modificado por cualquier otro sin mayores dificultades. De esta manera se logra agilizar el desarrollo y evitar dependencias con desarrolladores particulares. La
simplicidad promueve la mantenibilidad del software, lo cual constituye un interés creciente en los clientes, ya que se estima que del TCO5 del software el80% corresponde
al mantenimiento. La simplicidad en el código no se logra en un primer intento, es por esto que el proceso de refactor debe ser realizado de manera periódica.
5 Total Cost of Ownership
22
Las metodologías tradicionales impusieron una cantidad de trabajo tedioso y pesado de documentación sobre los desarrolladores. En XP se busca aligerar y simplificar la
documentación del software, se busca principalmente que el código esté “autodocumentado” en su mayoría, evitando en lo posible el uso de formatos adicionales.
La simplicidad en el código, apoya indirectamente la consecución de otro de los principios fundamentales de XP: la comunicación; ya que frecuentemente los desarrolladores deben integrar segmentos de código de diferentes personas, y cuando el código es fácil de
entender esta labor de integración resulta más eficiente.
• Comunicación: La comunicación constituye un factor determinante en los proyectos de
software. El producto final es intangible, el software es en esencia la materialización de “ideas” para la solución de las necesidades de los clientes, por esto la comunicación de
ideas y necesidades entre programadores, clientes, gerentes y demás involucrados en un proyecto de software es fundamental (Cusumano, 2004). Para los programadores el
código comunica mejor mientras más simple sea, adicionalmente, mediante la puesta en marcha de la práctica de programación en pares (explicada más adelante) la comunicación se ve altamente beneficiada. XP plantea que la comunicación entre los desarrolladores y
los clientes debe ser constante, asegurando así, que lo que se construye cumple con las necesidades y expectativas de los clientes. La comunicación entre desarrolladores, como
ya se mencionó, está altamente relacionada con la simplicidad del código que se elabora por parte de los mismos. El esquema de construcción iterativa, con prototipos de
funcionalidad incremental, obliga a la constante integración y toma de decisiones por parte de los desarrolladores, esta interacción constante fortalece los medios de
comunicación del grupo de desarrolladores (Extreme Programming, 1999).
• Retroalimentación (feedback): La mayoría de los proyectos de software que fracasan, lo hacen porque solo hasta estados muy avanzados del proyecto se empieza a notar que la
dirección que tomó el producto no era la adecuada para las necesidades del cliente. Los cambios en el software, cuando el proyecto se encuentra en estados avanzados implica un
esfuerzo enorme por parte del grupo de desarrolladores, resultando casi en la totalidad de los casos en atrasos considerables en el proyecto y pérdidas económicas significativas del
lado del cliente como del lado de la empresa desarrollando el software. La retroalimentación oportuna por parte de los clientes es una de las principales premisas de XP, en estos momentos suena evidente su importancia, pero en las metodologías
tradicionales (desarrollo en cascada) este factor no era considerado. La retroalimentación también se aplica en la transición iterativa entre diseño y construcción, en XP idealmente
se diseñan pequeños componentes de la aplicación y rápidamente se procede a su construcción, si se detectan problemas importantes en esta fase, se regresa al diseño y se
elaboran los ajustes necesarios antes de continuar.
• Coraje (Valentía): Todos los principios mencionados parecen razonables y provechosos
para el desarrollo de un proyecto de software, sin embargo se requiere de coraje o valentía para aplicarlos. Lograr la simplicidad en el código mediante refactors requiere
23
valentía por parte de los desarrolladores, ya que se corre el riesgo de inyectar errores en componentes de la aplicación que ya funcionaban correctamente. La comunicación y
retroalimentación necesaria en XP implica valentía por parte de todos los involucrados en el proyecto, ya que es necesario que todos los individuos expresen las necesidades y
dificultades encontradas a lo largo del proyecto y estén en capacidad de exigir a las personas el cumplimiento de los principios que conforman XP.
Prácticas y herramientas XP
• Planeación: o Historias de usuario: esta herramienta sirve para que los desarrolladores puedan
realizar una estimación del esfuerzo requerido para implementar cierta funcionalidad determinada por el cliente. Las historias de usuario son textos
breves escritos por el cliente, en el cual en terminología propia de este, se describe una funcionalidad determinada del sistema a construir. En comparación
con las metodologías tradicionales, las historias de usuario tienen un propósito similar al de los “casos o escenarios de uso” pero son mucho más ligeras evitando entrar en detalles. Cuando llegue el momento de implementar una funcionalidad
dada, es responsabilidad de los desarrolladores leer la historia de usuario, entrevistarse con el cliente, y obtener todos los detalles necesarios para la
construcción de la funcionalidad en cuestión. o Planeación release6: esta actividad hace referencia a la planeación general del
proyecto (release plan), la cual consiste en la división del proyecto en iteraciones, cada una de las cuales marca hitos en la evolución del software a construir. La
planeación debe ser elaborada por las personas que hacen parte del grupo técnico y por las personas que hacen parte del grupo de negocio y las opiniones de ambos grupos deben tenerse en cuenta. Lo que se propone en XP es tomar las historias
de usuario, transcribirlas a pequeñas tarjetas y determinar el orden de implementación de las mismas, siempre teniendo en cuenta necesidades del
cliente y restricciones de la tecnología, recursos y tiempo. En XP la planeación no es una actividad estática, por el contrario, según las necesidades y dificultades que
enfrente el proyecto la metodología exige el refinamiento constante de la planeación.
o Medir velocidad del proyecto: Cada iteración se debe medir la velocidad del proyecto, la cual se define como la suma de los estimados de las historias de usuarios que fueron completadas durante la iteración. Esta medida sirve para
monitorear la velocidad en que se está avanzando en el proyecto, lograr
6 La palabra release en el contexto de sistemas hace referencia también al lanzamiento de una nueva versión del software.
24
planeaciones realistas para las iteraciones futuras y evitar la sobrecarga de trabajo sobre el grupo de desarrollo.
o Dividir el proyecto en iteraciones: El proyecto debe dividirse en iteraciones de una a tres semanas de duración. La duración de las iteraciones a lo largo del
proyecto debe ser la misma, las iteraciones pueden verse como el latido del corazón del proyecto (Extreme Programming, 1999), y son las que les dan el ritmo al trabajo de las personas involucradas en el proyecto. Las iteraciones facilitan el
monitoreo del proyecto, ya que al final de cada una de ellas, es necesario evaluar la completitud de los objetivos de la iteración y plantear los objetivos de la
siguiente. Los plazos de terminación de las iteraciones son estrictos, la reunión de cierre de iteración tiene un día y una hora acordada, la cual no debe ser
modificada. En las iteraciones se le pide a los desarrolladores concentrarse y terminar en lo posible las tareas identificadas como prioritarias, es decir, es más
valioso tener estas tareas completadas al 100% que tener muchas al 80%. o Planear al inicio de cada iteración: Cada iteración requiere una planeación más
detallada que responda a las situaciones que se presentan a lo largo del proyecto.
La secuencia de historias de usuario a implementar en cada iteración está dadas en principio por el release plan, sin embargo este debe revisarse al finalizar cada
iteración para lograr cada vez más un plan de trabajo más realista frente a los problemas y particularidades del proyecto. En la planeación de la iteración es
donde se traduce de historias de usuario a tareas de desarrollo, en este proceso participa todo el grupo de desarrollo, y generalmente la asignación de tareas se
realiza de manera voluntaria. Las tareas deben agruparse o desglosarse según sea el caso para que la duración estimada de estas se encuentre ente uno y tres días de desarrollo. La medida de velocidad del proyecto se usa para asignar la cantidad
adecuada de trabajo al grupo de desarrolladores y protegerlos de sobrecarga de trabajo que finalmente se traduce en menor motivación y calidad en las tareas
asignadas. o Mover a las personas: Muchos proyectos de software sufren más de lo que
deberían por la salida del proyecto de una persona determinada, esto se debe a que normalmente se forman islas de conocimientos en los proyectos de software, ya que los desarrolladores suelen trabajar constantemente en una sola parte de la
aplicación. La rotación de roles o responsabilidades minimiza las dependencias del proyecto en individuos, distribuye el conocimiento en todo el grupo de desarrollo,
y disminuye la monotonía en el trabajo de los desarrolladores y aumentando la motivación de los mismos. Asignar tareas sobre diferentes partes de la aplicación
a desarrollar y ejecutar sesiones de programación por pares minimiza la ocurrencia de islas de conocimiento.
o Reuniones de pie: La metodología propone la realización de reuniones informales, las cuales deben llevarse a cabo diariamente, en horas de la mañana. A estas reuniones debe asistir la totalidad del equipo del proyecto, el objetivo de estas
breves reuniones es fortalecer la comunicación entre todos los participantes,
25
compartir problemas y soluciones, y mantener el foco en el equipo. En la reunión los asistentes se encuentran de pie, y se ubican a manera de círculo para generar
un equilibrio en la forma en que se discuten los distintos temas. Resulta conveniente contar con un computador a la mano cuando alguna persona tiene un
problema técnico el cual no ha podido resolver para que los demás asistentes opinen y encuentren soluciones al mismo.
o Arreglar XP: XP fue concebido para suplir las necesidades de flexibilidad del
desarrollo de software, es por eso que una de sus reglas es la flexibilidad. Para iniciar un proyecto con XP se recomienda seguir todas las reglas definidas por
la metodología, no obstante, una de las reglas de XP establece que se deben modificar o eliminar las reglas que no muestren ser beneficiosas para el proyecto
el proyecto en particular.
• Codificación: o El cliente siempre está disponible: Dentro de XP no se considera al cliente como
una ayuda al equipo del proyecto, más bien se considera al cliente como un integrante fundamental del equipo del proyecto. Por esto mismo, es que el cliente
siempre debe estar disponible en la mayoría de tareas de XP, en especial en la actividad de codificación. Si el cliente está realmente interesado en el éxito del
proyecto debe asignar unos recursos con alta disponibilidad de tiempo y conocimiento profundo del problema que la organización quiere resolver. Los
recursos asignados por el cliente para el proyecto son los encargados de evaluar los distintos prototipos que se construyen y de brindar retroalimentación oportuna al respecto a los desarrolladores.
o El código sigue estándares: La codificación sigue estándares que facilita el entendimiento del sistema por todos los desarrolladores.
o Se codifican primero las pruebas unitarias: Codificar las pruebas para una unidad de software antes de codificar la unidad representa grandes ventajas, porque
obliga al desarrollador a especificar claramente el comportamiento esperado del fragmento de código a construir. Puede verse como un enfoque de caja negra, en
el cual es desarrollador define algunas salidas (outputs) que el fragmento de código debería producir cuando se le introducen ciertas entradas (inputs), sin saber todavía los detalles de cómo elaborar dicho código. La principal ventaja de
cumplir esta regla es que se asegura que el desarrollador obtenga una retroalimentación (feedback) casi instantánea de la validez del código
desarrollado, y se crea la disciplina de probar todo el código desarrollado, lo cual es necesario para reducir drásticamente la aparición de bugs en el sistema.
Adicionalmente esta sencilla regla contribuye fuertemente a la comunicación del grupo del desarrollo, ya que normalmente los desarrolladores no necesitan saber
los detalles de implementación de cierta funcionalidad, lo cual puede requerir de
26
tiempo y esfuerzo considerables; lo que los desarrolladores necesitan comunicar normalmente es la forma de usar el código, lo cual es mucho más sencillo si se
cuenta con las pruebas unitarias para cada fragmento de código. o Programación en pares: la programación en pares o pair programming es una de
las propuestas más controversiales de la metodología, ya que esta sugiere que la totalidad del código que va a producción7 debe ser elaborado por dos personas simultáneamente en un solo computador, las dos personas se turnan la
codificación. La persona que no está codificando sirve de control de calidad instantáneo y mantiene la visión global necesaria para ver como “encaja” el código
que su compañero está construyendo dentro del diseño general del sistema. Para la gerencia resulta contra‐intuitiva esta propuesta, ya que se está pagando por dos
recursos, uno de los cuales está sentado observando lo que el otro hace, sin embargo numerosos estudios8 indican que la programación por pares aumenta la
calidad global del sistema lo que se traduce en menores costos en etapas posteriores de desarrollo. Los desarrolladores, inicialmente muestran resistencia a la programación en pares (Cusumano, 2004), sin embargo una vez se logra una
sincronización de las cabezas de los pares y estos experimentan las ventajas obtenidas por esta práctica, los desarrolladores se muestran cada vez más
satisfechos y motivados en su trabajo (Cusumano, 2004). o Solo una pareja integra código en un momento del tiempo: Solo una pareja de
desarrolladores puede agregar nuevo código al repositorio general de código de la aplicación, inmediatamente debe proceder a ejecutar todas las pruebas unitarias y
de integración de la aplicación. De esta manera se reducen los problemas de sincronización entre las parejas y se evita la introducción de bugs que ocurren normalmente cuando dos parejas trabajan simultáneamente sobre una misma
fracción de código. o Integrar frecuentemente: Se debe pedir a los desarrolladores que frecuentemente
(idealmente diario) y de manera ordenada integren el código desarrollado a la aplicación global. De esta manera se evita fragmentación de la aplicación y se
facilita la detección oportuna de bugs o problemas de integración que la aplicación pueda tener.
o Autoría del código colectiva: No existen dueños particulares para segmentos de
código o partes de la aplicación en particular, todos los desarrolladores tiene la capacidad y el derecho de modificar cualquier línea de código si están seguros de
estar reparando un bug o mejorando una funcionalidad determinada. Siguiendo esta regla se agiliza el proceso de desarrollo y la corrección de bugs se lleva a cabo
mucho más eficiente comparada a un escenario en el cual sólo la persona que
7 Por código de producción se entiende todo aquel que va a hacer parte de la aplicación final que se entrega al cliente, el código correspondiente a las pruebas, por ejemplo, no se considera código de producción, aunque usua lmente este también es entregado a l cliente. 8 Uno de ellos “Costs and benefits of pair programming” http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
27
produjo las líneas de código con problemas tiene la obligación de hacer la corrección. Adicionalmente el cumplimiento de esta regla genera un compromiso
mayor hacia el proyecto por parte de todos los integrantes del grupo de desarrollo.
o La optimización es para el final: Frecuentemente los desarrolladores consumen cantidades considerables de tiempo pensando la manera de obtener el mejor desempeño en sus algoritmos, XP propone que esta preocupación se deje para el
final debido a que la prioridad es construir las funcionalidades deseadas de la manera más sencilla y rápida posible. Frecuentemente en sistemas si se desea
obtener desempeños óptimos se debe llegar a soluciones complejas que requieren tiempos considerables de construcción, lo cual va en contra de la necesidad de
entregar frecuentemente prototipos funcionales a los clientes. o No horas extra: En algunas ocasiones trabajar horas extra para cumplir con
algunos plazos de entrega es perfectamente entendible, sin embargo en la industria del software se encuentra que trabajar varias horas extra es algo bastante frecuente (Cusumano, 2004). La motivación de los desarrolladores se ve
altamente afectada por esta situación, lo cual conlleva a disminuciones importantes en la calidad de su trabajo, por esto XP plantea que las horas extra
solo se deben considerar en situaciones extremas.
• Diseño: o Simplicidad: Un diseño simple se traduce en una construcción simple, lo cual
agiliza el desarrollo y permite evaluar más fácilmente la calidad del producto final. Entre los diseñadores y desarrolladores de software esto se conoce como el principio KISS por sus siglas en ingles Keep it Simple & Stupid.
o Usar metáforas para diseñar y nombrar componentes del sistema: Este principio se puede lograr al aplicar patrones de diseño de sistemas, la mayoría de los
patrones de diseño más usados poseen nombres que permiten un inferir su función9. Esto permite una comunicación un poco mas estandarizada entre
distintos desarrolladores respecto a la funcionalidad y estructura de los distintos componentes de la aplicación.
o Usar tarjetas CRC: Son una herramienta que facilita la labor de diseño de manera colaborativa. Las CRC permiten la participación de todos los integrantes del grupo de desarrollo en la toma de decisiones de diseño, así se logran incluir todas las
buenas ideas que surjan del grupo para obtener el mejor diseño posible. o Elaborar pruebas de concepto: Con el fin de minimizar el riesgo en el proyecto,
cuando se tomen decisiones en tecnologías a usar, el grupo de desarrollo debe proceder inmediatamente a construir un pequeño componente o prototipo que
sirva para evaluar el comportamiento de la tecnología. En la industria de software,
9 Algunos de estos patrones son: patrón fabrica, patrón comando, patrón constructor, patrón orquestador.
28
aproximadamente un 20% de los proyectos que fracasan lo hacen por no conocer y manejar apropiadamente la tecnología elegida.
o Diseñar lo necesario: No pensar en extras que no han sido exigidos por los clientes, todo el esfuerzo de los desarrolladores debe estar enfocado a satisfaces
las necesidades del cliente con la mejor calidad posible.
• Pruebas: o Todo el código debe tener pruebas unitarias: Para asegurar la calidad de los
prototipos y de la aplicación en general, se debe contar con pruebas unitarias para
todo el código. Adicionalmente, como ya se mencionó dichas pruebas deben ser diseñadas y construidas antes de elaborar el código.
o Pruebas unitarias para todo release: Antes de efectuar cualquier release10 a los clientes, la totalidad de las pruebas unitarias definidas para la aplicación deben
ejecutarse exitosamente. Para mantener una buena dinámica en el proyecto es fundamental no perder credibilidad ante los clientes haciendo entrega de software que no ha sido probado exhaustivamente. XP establece que la
participación de los clientes es esencial para el éxito de cualquier proyecto de software, y esta participación es más eficiente si se provee de prototipos de
calidad a los clientes. o Cuando se encuentra un bug se define una prueba: Normalmente cuando los
desarrolladores encuentran un bug proceden a solucionarlo de inmediato, sin embargo si se hace esto, el conocimiento generado tras detectar el error y
elaborar la corrección no se difunde entre el grupo de desarrolladores. Por esto, la forma de almacenar o distribuir el conocimiento de algún bug es definir una prueba y luego proceder a la corrección de este.
o Las pruebas de aceptación se efectúan frecuentemente: Las pruebas de aceptación hacen referencia al comportamiento esperado por el cliente de la
aplicación, el cual está definido en las distintas historias de usuario, por esto, las pruebas de aceptación son conducidas por los clientes y son ejecutadas
frecuentemente sobre los prototipos. XP enfatiza que se debe procurar conducir pruebas de aceptación frecuentemente, con el fin de proveer retroalimentación
oportuna al grupo de desarrollo y contar con un proceso de corrección de errores mucho más eficiente. La ejecución frecuente de pruebas de aceptación asegura que el proyecto no pierda el rumbo y que el producto final cumpla perfectamente
con las expectativas de los clientes.
10 Hace referencia al lanzamiento de una nueva versión de la aplicación, o a una versión más completa de los prototipos de software.
29
3.4.6 Dificultades y limitaciones para implementar ágil
La metodología ágil está orientada más a las personas que a los procesos, en ella se confía en la capacidad y responsabilidad de los individuos para lograr un producto de calidad en el tiempo estimado para el proyecto. Lo que es su mayor fortaleza puede ser al mismo tiempo su mayor
debilidad, su dependencia en los individuos.
Diferentes autores del manifiesto ágil como Fowler, Cockburn y Beck entre otros han advertido claramente cuáles son las limitaciones que se pueden encontrar a la hora de implementar
metodologías ágiles:
• Un equipo ágil no se conforma de individuos “promedio”: dentro de los principios ágiles
la capacidad de auto‐organización del equipo es fundamental, sin ella el proyecto nunca entregará valor al cliente. Para que la auto‐organización ocurra se necesita individuos altamente motivados, con capacidad de aprendizaje, liderazgo y pasión por el trabajo
(Cockburn, I come to bury agile, not to praise it, 2009); Esto no siempre es fácil de conseguir. La metodología ágil no funcionará apropiadamente con un grupo de ingenieros
“promedio”, se necesita de individuos talentosos (Synapsis Canada, 2009), la utilización de un esquema ágil con un equipo de trabajo donde la mayoría de individuos no cumplen las
características mencionadas puede ser catastrófico.
• El cliente debe entender y aceptar la metodología ágil: las organizaciones llevan
alrededor de dos décadas trabajando con metodologías tradicionales, en especial RUP, la cual se acopla bien al esquema organizacional tradicional de numerosos clientes. Las metodologías ágiles resultan bastante difíciles de utilizar en proyectos con clientes cuya
cultura organizacional está basada en una cadena de mando rígida en donde los procesos prevalecen sobre las personas (Synapsis Canada, 2009). Para un cliente con estas
características resulta bastante difícil entender que los requerimientos del software van a cambiar inevitablemente, y que para que el proyecto sea exitoso no se debe exigir
cantidades abrumadoras de documentación.
30
• Tamaño del equipo y del proyecto: todas las metodologías ágiles son claras en exponer que estas sólo deben ser aplicadas en equipos pequeños (máximo 10 personas). Esto se debe a que la auto‐organización en equipos más grandes puede ser bastante difícil de
lograr. Por otra parte, las metodologías ágiles proponen que todos los miembros del equipo participen de actividades administrativas del equipo, esto puede resultar bastante
difícil de coordinar y controlar para equipos de trabajo grandes. Al tener esta limitación en cuanto al tamaño del equipo inevitablemente se crea una restricción en cuanto al tamaño del proyecto en general.
• Comunicación cara a cara: dentro de los principios ágiles se enuncia que la comunicación cara a cara es la más eficiente y por lo tanto debe ser la de mayor uso. Sin embargo,
inclusive para equipos pequeños de trabajo esto puede ser difícil de lograr ya que implica que la totalidad del equipo debe estar la gran mayoría del tiempo en el mismo lugar físico.
Para integrantes que se encuentren ubicados en un lugar diferente al resto del equipo resulta muy costoso perderse de toda la comunicación informal cara a cara que se da en el
día a día del proyecto. La comunicación cara a cara no solo debe usarse entre desarrolladores, también debe usarse con expertos de negocio del lado del cliente, esto puede ser bastante difícil de lograr.
31
4. Evolución de las teorías de administración y del desarrollo de software
Para entender los principios tras las metodologías tradicionales y modernas de software resulta enriquecedor estudiar la evolución de las teorías administrativas o de organización del trabajo.
Estas surgieron con la revolución industrial, en particular con la única industria relevante de la época, la manufacturera. La teoría general de administración ha recorrido un largo camino de más
de cien años. El software surgió hace unos cincuenta años, y su historia muestra un recorrido similar al de la teoría general de administración. Como se verá más adelante, en el modelo RUP se
pueden encontrar principios similares a los de la teoría clásica de la administración de Fayol y Taylor (Fowler, 2005); mientras que en las metodologías ágiles se pueden ver principios de la
teoría de las relaciones humanas y de la teoría sistémica de la organización.
4.1 Teorías Clásicas de la administración
Hacia inicios del siglo XX la revolución industrial impulsó el desarrollo de las teorías para la organización del trabajo (Dale E. Yeatts, 1998). En esta época se desarrollaron las teorías clásicas
de la administración como lo son la administración científica de Taylor cuyo propósito era encontrar maneras de obtener la mayor productividad en las organizaciones o “una mejor forma
de hacer el trabajo” (Dávila Guevara, 2001) y la doctrina administrativa de Fayol cuyo propósito era el de la eficiencia de la organización (Dávila Guevara, 2001), teorías que basan la mayoría de
sus principios en las relaciones de poder que deben existir entre los agentes o participantes de la organización o cuerpo social. Entre las principales características o fundamentos de las teorías
clásicas de la administración se encuentran (Dávila Guevara, 2001):
• División clara del trabajo, resumido claramente por la propuesta de Taylor: trabajo intelectual “planear el trabajo” y el trabajo manual “hacer el trabajo”.
• Disciplina en los agentes de la organización.
• Subordinación de los intereses particulares al interés general de la organización.
• Remuneración de los agentes acorde a las funciones laborales asignadas.
• Centralización casi absoluta del poder y de la toma de decisiones en los agentes responsables de los cargos directivos.
Entre las numerosas críticas dirigidas el enfoque clásico de la administración existe una bastante recurrente en la literatura: no se tienen en cuenta los factores psicológicos del individuo que
afectan su desempeño en el trabajo, o como los estadounidenses James March y Herbert Simon en 1958 lo expresan: las teorías clásicas ignoran el comportamiento de los individuos y en
particular sus bases motivacionales. No es difícil notar que la mayoría de las críticas que se le hacen a la teoría clásica de la administración son las mismas hechas al modelo RUP.
32
El modelo RUP materializa varios de los principios de la administración clásica. La metodología RUP generalmente es impuesta por la gerencia de proyectos, la cual no confía en la capacidad de
los desarrolladores para planear y organizar el trabajo necesario para sacar un proyecto adelante. La división del trabajo “intelectual” y el trabajo “manual” es análoga a la división del diseño e
implementación del software que propone RUP. Finalmente el objetivo de la administración clásica al igual que RUP es definir procesos predecibles y repetibles.
4.2 Teoría de las relaciones Humanas
Las críticas al enfoque clásico de la administración, y la creciente interrelación del sector
académico y las grandes corporaciones de la época (Dávila Guevara, 2001), dio surgimiento a las teorías de las relaciones humanas hacia mediados del siglo XX, teoría que cuenta con sustento
mucho mas investigativo y empírico que su predecesora.
No se puede hablar de la teoría de las relaciones humanas sin mencionar la investigación que dio origen a la publicación de la mayoría de las principales ideas de esta teoría. Se trata de la
investigación realizada desde el año de 1923 hasta el año de 1932 en la Western Electric, empresa dedicada a la fabricación de equipos de teléfonos y que a la fecha contaba con alrededor de
30.000 empleados. La investigación era desarrollada por un grupo de trabajo interdisciplinario conformado por psicólogos, antropólogos, médicos, ingenieros y personal directivo de la empresa
en cuestión. La investigación es considerada como uno de los primeros acercamientos científicos y empíricos al entendimiento del funcionamiento de las organizaciones.
El informe oficial de la investigación fue publicado por Roethlisberger y Dickson en 1938, el cual expone la siguiente conclusión:
El estudio de la sala de conexión de borneras mostró que el comportamiento de los obreros
no podía entenderse sin considerar la organización informal del grupo y la relación entre esta organización informal y la organización social total de la empresa. Las actividades de
trabajo de este grupo, junto con sus satisfacciones e insatisfacciones, tienen que verse como un patrón complejo de interrelaciones. En breve, la situación social del grupo de
conexión de borneras tiene que tratarse como un sistema social; además la organización industrial de la cual este grupo es un sistema también tiene que tratarse como un sistema
social (Roethlisberger y Dickson, 1939: 551 Citado por Dessler, 1980: 292. Traducción de (Dávila Guevara, 2001))
33
Las principales ideas o conclusiones que exponen los defensores de la teoría de las relaciones humanas son:
• La cooperación e integración de intereses entre los trabajadores y los patrones es posible (Dávila Guevara, 2001).
• La conducta del hombre está cargada de aspectos irracionales y emotivos minimizando el papel de la conciencia (Dávila Guevara, 2001).
• Si los empleados participan en procesos de la toma de decisiones, estos van a lograr satisfacer necesidades de “orden mayor” (Maslow, 1954).
El último punto mencionado sintetiza de buena forma la motivación principal de la teoría de las relaciones humanas. Este se desprende de la teoría de la jerarquía de necesidades propuesta por Maslow en 1954 (Dale E. Yeatts, 1998), la cual expone que la gerencia debe crear condiciones y
recompensas no exclusivamente económicas para satisfacer las necesidades de orden mayor que poseen todos los participantes de una organización (Dávila Guevara, 2001). A continuación se
muestra dicha jerarquía:
Ilustración 1 Jerarquía necesidades de Maslow (tomado de http://es.wikipedia.org/wiki/Imagen:Pir%C3%A1mide_de_Maslow.svg)
34
Por consiguiente esta teoría expone la necesidad de encontrar y definir instrumentos en las organizaciones que propicien un entorno que facilite satisfacer las necesidades de Afiliación,
Reconocimiento y Autorrealización de los individuos, esto con el fin de obtener la máxima eficiencia del trabajo y de la organización misma. Maslow afirma entonces que la máxima
eficiencia en la organización se alcanza cuando las metas de los individuos y de la organización se encuentran alineadas.
Los principios enunciados en el Manifiesto Ágil presentan algunas de las ideas más importantes de
la teoría de las relaciones humanas. En ágil se da más importancia a las personas que a los procesos, por lo tanto la motivación de dichas personas es fundamental para el éxito de los
proyectos. Los principios ágiles no entran en detalle de cómo lograr la motivación en los individuos, sin embargo distintas metodologías como eXtreme Programming y Scrum generan las
condiciones para que los individuos logren satisfacer las necesidades de orden superior enunciadas por Maslow. La oportunidad que tienen los integrantes de un equipo ágil de participar
en labores administrativas de planeación y definición de los objetivos de las iteraciones, así como participar y aportar en el diseño general del sistema son aspectos que han probado ser motivacionales para los individuos (Cockburn, Characterizing people as non‐linear, first‐order
components in software development, 1999).
Las debilidades encontradas por diferentes autores críticos de esta teoría, se pueden resumir de la
siguiente manera:
La teoría de las relaciones humanas hace saltos inadecuados entre niveles de análisis, sin
tener en cuenta las complejidades sociales. La sociedad o la organización no pueden ser concebidas como el agregado de los individuos que la componen (Nicos Mouzelis, 1967)
Es decir no se tiene un foco claro de trabajo, ¿es el individuo, el grupo, o la organización? ¿Es válido realizar el mismo tipo de acercamiento sobre estos distintos elementos?
4.3 Teoría de Sistemas
Las preguntas no resueltas en la teoría de las relaciones humanas ocasionaron la incursión de la
teoría de sistemas en el estudio de las organizaciones.
La teoría de sistemas no choca directamente con ninguna de las prácticas anteriores, más bien
ofrece herramientas que facilitan un acercamiento estructurado a los diferentes elementos que constituyen e interactúan dentro y fuera de la organización. En consecuencia se empieza a ver a la
organización como un sistema o un conjunto de elementos interdependientes e interrelacionados unos a otros.
35
Holt (1990) lo expresa de manera clara:
Tal como el cuerpo humano es un sistema con órganos, músculos, huesos, un sistema
nervioso, y una conciencia que une todas las partes, una organización es un sistema con numerosas partes interdependientes relacionadas por la dinámica social de los seres
humanos trabajando juntos.
Dentro de la teoría de sistemas se desarrollaron varias corrientes, algunas de las más importantes según Yeatts (1998) son:
• Teoría de sistemas cerrados: este se considera el punto de partida para el enfoque sistémico, en este se estudia a la organización como un sistema cerrado, es decir, sólo se estudian los elementos y las relaciones al interior de la organización.
• Teoría de sistemas abiertos: al encontrar que se que dejaban de lado importantes factores influyentes en la organización, provenientes del entorno cambiante, los teóricos
sistémicos proceden a estudiar la organización como un sistema abierto, el cual presenta fuertes interacciones y dependencias con el entorno en el que se encuentra.
• Teoría de sistemas socio‐técnicos: en este enfoque se definen dos tipos de sistemas principales que conforman las organizaciones, el primero es el sistema social, es decir las
personas y las relaciones conformadas entre estas durante su participación en la organización; el segundo es el sistema técnico, es decir las herramientas, técnicas, procedimientos, estrategias, habilidades, conocimiento e instrumentos usados por los
miembros del sistema social para cumplir los objetivos de la organización (Dale E. Yeatts, 1998).
Las metodologías ágiles de desarrollo de software enfocan su esfuerzo en diseñar el trabajo de los equipos de desarrollo. La ventaja que ofrece el enfoque sistémico es que este permite estudiar sistemas que varían enormemente en dimensión, desde una multinacional hasta un equipo de
trabajo. Las metodologías ágiles son explicitas afirmando este hecho, los equipos de desarrollo de software modernos deben analizarse como sistemas auto‐organizados (Fowler, 2005).
36
4.3.1 Sistemas sociotécnicos y eXtreme Programming
Dentro de las corrientes mencionadas, vale la pena destacar y profundizar un poco en la teoría de los sistemas socio‐técnicos, los cuales son de gran utilidad para entender el funcionamiento y desempeño de los equipos de trabajo. Se encontrará que varios de los principios de la
metodología XP se encuentran alineados con principios enunciados en la teoría de los sistemas socio‐técnicos. Adicionalmente esta teoría permite identificar aspectos no tenidos en cuenta en la
metodología XP, los cuales pueden afectar de manera importante el desempeño y éxito de un equipo XP.
Esta teoría expone que las organizaciones más eficientes son aquellas en las que los sistemas técnicos y sociales se encuentran integrados y se encuentran mutuamente soportados. Para lograr este cometido, se debe contar con procesos cuyo objetivo sea el diseño del trabajo, teniendo
como premisas la integración y complementariedad con los sistemas sociales de la organización.
Respecto a los equipos de trabajo, Fisher, Rayner, y Belgard (1995) explican la importancia de considerar los sistemas sociales y técnicos:
Existen dos tipos fundamentales de aspectos que surgen en un equipo: tareas y relaciones sociales. Los aspectos relativos a las tareas se refieren al trabajo como tal que el equipo de
realizar. Los aspectos relativos a las relaciones, se refieren a que tan bien las personas en el equipo trabajan se relacionan unas con otras. Un equipo enfocado excesivamente en las tareas, puede llegar a descuidos en los aspectos de las relaciones. Como resultado, pueden
surgir tensiones y conflictos entre los miembros del equipo. Un equipo que se enfatice excesivamente en las relaciones puede llevar al no cumplimiento de las tareas, o a una
disminución en la calidad del trabajo.
Ahora bien, sabiendo la importancia de las características del trabajo a ser realizado por los
miembros de un equipo, resulta importante reflexionar sobre el diseño del trabajo. La teoría del Enriquecimiento del trabajo consiste en una herramienta fundamental a la hora de optimizar el funcionamiento de las organizaciones bajo el enfoque de sistemas técnico‐sociales.
Fundamentalmente se desarrolla bajo la premisa heredada de las relaciones humanas, la cual afirma que mientras más alta sea la satisfacción y motivación de los empleados, mayor será el
desempeño del mismo y por consiguiente el de la organización.
37
Turner y Lawrence (1965) destacan cinco aspectos claves a tener en cuenta en el diseño del trabajo los cuales se reflejan claramente en los principios ágiles y en los principios de la
metodología XP (eXtreme Programming):
1. Variedad en el trabajo: XP es explicito en indicar la necesidad de la rotación de responsabilidades de integrantes del equipo. Con esto se evita la monotonía del trabajo, se motiva a los individuos a participar en diferentes roles y se minimiza el riesgo de
generar dependencias en personas particulares. 2. Autonomía en el trabajador en el desempeño del trabajo: en XP se confía en el criterio de
los desarrolladores para planear y diseñar el trabajo de la mejor manera posible. XP es un proceso que debe ser adaptado y ajustado a medida que el proyecto avanza, este
refinamiento del proceso es diseñado por los integrantes del equipo y no por una autoridad superior.
3. Interacción social provista por el trabajo: para todas las metodologías ágiles, incluyendo XP, la comunicación cara a cara es fundamental para el éxito del proyecto. De esta interacción social no solo se ve beneficiado el proyecto sino también se benefician los
individuos, los cuales tienen una necesidad natural de socializar (Pasmore, 1988). 4. Conocimiento y habilidades requeridas para el trabajo: como bien se mencionó en el
capítulo que presenta las metodologías ágiles, estas requieren de un equipo especial de individuos. Para que la auto‐organización ocurra y el proyecto sea exitoso se necesita que
los individuos constantemente superen retos inesperados, asuman diferentes responsabilidades y sean motivados intelectualmente.
5. Responsabilidad conferida al trabajador: el principio de coraje de XP resume perfectamente este punto. Los integrantes de un equipo XP son individuos responsables y motivados a desarrollar un producto de alta calidad, no necesitan una figura de autoridad
superior (Fowler, 2005).
Los equipos de trabajo están conformados por individuos, lo cual es un aspecto en el que las metodologías ágiles hacen especial énfasis. Por esta razón, es claro que el beneficio que obtiene la
persona que realiza un trabajo depende en última instancia de las características del individuo, es decir diferentes personas encontraran diferentes niveles de satisfacción para un mismo trabajo. Por consiguiente las características del individuo deben identificarse previamente a la asignación
de la labor que se les desea delegar, de ahí la importancia de la definición de procesos claros de selección de personas que cumplan con las características particulares requeridas por realizar un
trabajo particular.
38
El anterior aspecto no es tenido en cuenta en la metodología ágil XP, la cual sólo presenta prácticas a ser usadas durante la ejecución de un proyecto de software. XP no hace referencia a la
etapa previa a iniciar un proyecto de software, en la cual se seleccionan los individuos que harán parte del equipo del proyecto, lo cual es un aspecto crucial para el éxito del proyecto. Tal y como
se enunció en el capítulo 3.4.6 (Limitaciones y dificultades para implementar metodologías ágiles) un equipo ágil no puede formarse de individuos “promedio” por lo tanto la selección de estos y el diseño del equipo es fundamental para implementar XP exitosamente.
Los principios de las metodologías ágiles son explícitos en alertar sobre la importancia de la auto‐organización en los equipos. Por esta razón en los capítulos posteriores se estudiará a fondo la
auto‐organización en sistemas complejos (capitulo 5 ‐ Cibernética) y en equipos de trabajo auto‐organizados (capítulo 6 – SMWT).
39
5. Cibernética
5.1 Historia
Se puede decir que el origen de la ciencia de la cibernética se dio en los Estados Unidos hacia la década de los 40s (American society for cybernetics), sin embargo a la cibernética no se le puede dar un punto en el tiempo y lugar estricto de nacimiento, ya que es una ciencia que resulta de la unión de numerosos conceptos estudiados y desarrollados a lo largo de la historia humana. Durante los años 40 los conceptos de: sistemas, información y control estaban proliferando ampliamente en numerosas disciplinas, como lo son las comunicaciones, la ingeniería, matemáticas, biología, psicología entre otras (American society for cybernetics). La madurez en las disciplinas mencionadas llevó a encontrar que los principios de control y regulación eran fundamentales para entender el funcionamiento de prácticamente cualquier fenómeno u objeto. De esta manera, científicos e ingenieros fueron descubriendo un conjunto de principios básicos que se podían aplicar a sistemas sociales, máquinas u organismos. (American society for cybernetics). La abstracción y descripción de estos principios fundamentales son el objeto de la cibernética. La cibernética como disciplina nació formalmente en el año de 1948 con la publicación del libro Cybernetics: Or the Control and Communication in the Animal and the Machine del matemático norteamericano Norbert Weiner, el cual es considerado como el padre de la cibernética. Sin embargo el término cibernética fue creado cerca de un siglo antes por el físico francés Andre Ampère en su obra Essai sur la philosophie des sciences, ou Exposition analytique d'une classification naturelle de toutes les connaissances humaines, en el cual creó el término cybernétique para denotar la ciencia del “arte de gobernar” definida por Aristóteles y Platón (American society for cybernetics).
5.2 Definición
Definir el término de Cibernética siempre se ha prestado (y se prestará) para controversias11 o desacuerdos entre diferentes personas. Sin embargo, resulta valioso recordar lo que alguna vez
dijo Heinz von Foerster:
“That is the fascinating thing about cybernetics. You ask a couple of people to give you a definition and although you don't get to know much about cybernetics from them, you find
out a lot about the person supplying the definition, including their area of expertise, their relation to the world, their desire to play with metaphors, their enthusiasm for
management, and their interest in communications or message theory.”
11 Una de estas controversias que vale la pena mencionar se presenta en una carta de Claude Shannon a Norbert Weiner en los años 40 en la cual dice: “Use the word `cybernetics', Norbert, because nobody knows what it means. This will always put you at an advantage in arguments.”
40
Es decir, una de las principales virtudes de la cibernética es la infinidad de campos en la que puede ser aplicada, por esta razón, en lugar de dar una única definición de lo que es la cibernética es más
enriquecedor consultar algunas de las definiciones12 de cibernética dadas por algunos de sus más influyentes representantes:
No se traducen las definiciones con el f in de evitar malentendidos y conse rvar el valor original que representan las palabras elegidas por los autores.
• André Ampere (físico, considerado el pionero en el estudio del electromagnetismo) o “Cybernetique= the art of governing or the science of government”
• Ross Ashby (médico neurólogo, desarrolló los primeros homeostatos) o "The study of systems that are open to energy but closed to information and
control‐systems that are information tight" o "Offers a single vocabulary and a single set of concepts for representing the most
diverse types of systems"
• Gregory Bateson (reconocido antropólogo y científico social) o "The biggest bite out of the fruit of the Tree of Knowledge that mankind has taken
in the last 2000 years."
o "a branch of mathematics dealing with problems of control, recursiveness, and information"
• Staford Beer (padre de la cibernética organizacional) o "the science of effective organization"
• Heinz von Foerster (padre de la cibernética de Segundo orden) o "Should one name one central concept, a first principle, of cybernetics, it would be
circularity."
• Erns von Glaserfeld (filósofo alemán) o “Cybernetics is the art of creating equilibrium in a world of possibilities and
constraints." • Humberto Maturana (biólogo y filósofo)
o “The science and art of understanding” • Norbert Weiner(matemático y padre de la cibernética)
o “the science of control and communication in the animal and the machine”
12 Las definiciones presentadas son tomadas del sitio web de la American Society for Cybernetics http://www.asc‐cybernetics.org/foundations/definitions.htm
41
5.3 Conceptos de sistemas autoorganizados
Los conceptos fundamentales de la cibernética que se van a introducir a continuación describen de
manera sencilla las reglas o principios que rigen el funcionamiento de innumerables sistemas sociales, biológicos o mecánicos. En particular, como se verá más adelante, estos conceptos y
principios aparecen recurrentemente en los principios que rigen las metodologías ágiles de desarrollo de software. De igual manera varios de estos conceptos se podrán identificar en la
teoría de diseño de equipos de trabajo auto‐organizados.
En general, el objeto de estudio de la cibernética son los sistemas, en particular los de mayor
interés son los denominados sistemas auto‐organizados, los cuales serán descritos cuando se hable del modelo VSM (Capítulo 3.5). Para el estudio de los sistemas auto‐organizados se han definido los siguientes conceptos:
Control: El primer principio respecto al control es que el controlador es parte del sistema bajo control (Beer, Brain of the firm, 1981). El control no es algo impuesto sobre el sistema
por una autoridad superior (Beer, Brain of the firm, 1981). En los sistemas no se puede ubicar explícitamente el control, simplemente se puede decir que existe y está repartido a
lo largo de toda la arquitectura del sistema (Beer, Brain of the firm, 1981). La existencia del control se evidencia gracias al comportamiento que manifiesta el sistema, el cual se puede ver como regulativo, buscando siempre llegar a una medida de equilibrio del sistema.
Conciencia (Awareness): la propiedad de conciencia de un sistema no implica de ninguna manera una conciencia propia, más bien se refiere a la propiedad del sistema de
responder a estímulos, sin necesariamente tener conciencia de lo que es un estimulo. Se dice que un sistema es consciente cuando “algo” interfiere con el comportamiento
“normal” del sistema y éste presenta algún tipo de respuesta al estímulo.
Estímulo: Se considera un estímulo todo aquello que interfiera con la operación normal
del sistema de alguna manera. Un estímulo es una interferencia que provoca algún cambio significativo en el sistema (no puede ser ignorado por este) y es lo suficientemente mesurado como para no destruir el sistema (Beer, Brain of the firm, 1981).
Respuesta: Los cambios provocados en el sistema por los estímulos se denominan respuestas. Las respuestas se clasifican en dos categorías:
• Positivas: Cuando el sistema busca reforzar el estimulo recibido, ya que este es considerado como “saludable” para el sistema (Beer, Brain of the firm, 1981).
• Negativas: cuando el sistema busca reducir o inhibir el estímulo y los efectos de este en el sistema (Beer, Brain of the firm, 1981).
42
Estabilidad: la estabilidad proviene del interior del sistema, y corresponde a una medida de operación normal del sistema.
Ultra‐estabilidad: término acuñado por Ross Ashby, se refiere a la propiedad que tienen algunos sistemas de sobrevivir y mantener la estabilidad frente a estímulos arbitrarios e
impredecibles (Beer, Brain of the firm, 1981).
Teniendo claridad en estos conceptos se puede introducir uno de los principales elementos de los sistemas auto‐organizados: el controlador. Éste elemento debe entenderse detalladamente ya
que es el principal responsable de la característica de auto‐organización de este tipo de sistemas. El controlador está conformado por:
• Sensorium: Se define como cualquier cosa al interior del sistema que pueda registrar y clasificar la existencia de un estímulo (Beer, Brain of the firm, 1981), es decir determina si el estímulo merece una respuesta positiva o negativa por parte del sistema.
• MOC (Motor Output Channel): Como su nombre lo indica, el MOC se encuentra en la sección encargada de construir la salida (output) del controlador. Este es el medio por el que se envía la clasificación de los estímulos desde los sensoriums hasta los effectors. Un
ejemplo en el cuerpo humano podrían ser los nervios que transportan órdenes dirigidas a los músculos provenientes del cerebro.
• SIC (Sensory input Channel): Análogo al MOC, con la diferencia que transporta datos o
información sensorial desde los transductores hasta los sensoriums.
• Transductor: Es el punto de entrada del estímulo al sistema, es decir es el encargado de detectar los estímulos y enviar mensajes o datos de los estímulos recibidos a los sensoriums (Beer, Brain of the firm, 1981).
• Effector: Son los que finalmente tienen la capacidad de producir acciones o respuestas a los estímulos que llegan al sistema.
43
5.4 El VSM (Viable System Model)
Como ya se mencionó, la cibernética es aplicada en prácticamente todas las áreas del
conocimiento, la administración no es excepción. Hacia finales de los años 50 nacía la cibernética organizacional con la extensa obra de Stafford Beer, siendo su principal desarrollo el VSM (Viable
System Model).
5.4.1 Introducción
Como ya se mencionó, la cibernética enfoca su trabajo en el entendimiento de las leyes que
gobiernan el funcionamiento de los sistemas, estas leyes determinan cómo el sistema nervioso de un animal controla sus acciones o cómo una organización regula su funcionamiento. El VSM ofrece
una notación para que personas entiendan y apliquen dichas reglas sin necesidad de poseer conocimientos profundos en matemáticas o cibernética (Hilder, 1995).
Stafford Beer desarrolló el VSM para ser una guía práctica del proceso de diagnosticar problemas en organizaciones humanas y ayudarlas a mejorar en su funcionamiento (Hilder, 1995). Beer propone un modelo en el cual se logran organizaciones más eficientes cuando se crean
condiciones en las que los participantes de la organización gozan de mayor libertad. Dicha libertad está enmarcada bajo el concepto que Beer denomina cómo el propósito de la organización, el cual
será explicado más adelante.
El VSM se puede emplear en dos situaciones:
• Apoyar el proceso de diseño de nuevas organizaciones para que cumplan su propósito de la manera más eficiente.
• Apoyar el proceso de diagnóstico de problemas organizacionales y el subsecuente proceso de rediseño de la organización.
Este modelo puede ser aplicado en numerosos de campos y por lo tanto ser de interés a
numerosas de audiencias, entre ellas Hilder (1995) destaca:
• Personas interesadas en entender cómo funcionan las organizaciones y como pueden funcionar mejor.
• Gerentes de tecnología que desean implementar tecnologías de información con el fin de mejorar el desempeño de la organización y brindar libertad a los participantes de esta.
• Gerentes interesados en rediseño de procesos de negocio y diseño de organizaciones inteligentes.
44
5.4.2 Conceptos Para diseñar sistemas auto‐organizados se debe tener en cuenta los siguientes conceptos:
Variedad: se define la variedad como el número de posibles estados en los que puede estar un sistema, puede entonces verse la variedad como una medida de la complejidad de un sistema. Por
ejemplo interruptor de la luz se tiene una variedad de dos (encendido, apagado), sin embargo entrando más en detalle, otra persona podría decir que la variedad es mayor a dos, ya que el
hecho de que la luz esté encendida no depende exclusivamente de la posición del interruptor, si no de los cables, del bombillo, etc. Dado el anterior ejemplo, se deduce que la variedad que se le
asigna o se percibe de un sistema depende del observador y del contexto sobre el que se observa. La variedad aumenta rápidamente con la complejidad y tamaño de los sistemas, hasta el punto en que la variedad de los sistemas sociales del mundo real se considera infinita.
Atenuadores: Los atenuadores son el mecanismo por el cual los sistemas pueden procesar la
infinidad de estímulos provenientes del entorno. Un atenuador se encarga de “dejar entrar” sólo la información considerada relevante, y filtrar el resto, como su nombre lo indica atenúa la
variedad del entorno. Si consideramos el sistema que es un ser humano, los atenuadores con los que cuenta dicho sistema tienen diferentes orígenes (Hilder, 1995):
• Fisiología humana: por ejemplo el oído humano sólo distingue sonidos que se encuentran entre los 20hz y los 20000hz, una persona sorda no distingue sonido alguno.
• Condicionamiento social: condicionamientos adquiridos a lo largo de la experiencia de vida en el entorno social (familia, ética, educación, etc.).
En el mundo natural, los atenuadores de la biología de los seres vivos han sido diseñados y perfeccionados a lo largo de la evolución, por ejemplo los ojos de una rana son muy buenos para detectar moscas, pero muy malos para apreciar una obra de arte (Hilder, 1995). En el mundo de las organizaciones los atenuadores deben ser diseñados tal que apoyen el funcionamiento de la organización y aseguren el cumplimiento de su propósito. Desafortunadamente no siempre se da lo anterior, es común encontrar organizaciones que dejan de existir debido a atenuadores mal diseñados que filtran la información relevante para el negocio. Un ejemplo de un atenuador en una organización que debe ser cuidadosamente diseñado es la investigación de mercados (Hilder, 1995).
45
Amplificadores: los amplificadores son usados para amplificar la variedad percibida con el fin de
aumentar el poder sobre el entorno (Hilder 1995). En el caso de los seres humanos, se usa la inteligencia como instrumento para amplificar nuestras acciones. El desarrollo de las ciencias y la tecnología permiten el hombre expandir o amplificar las acciones deseadas sobre el entorno.
46
Autopoiésis, sistemas auto‐organizados
Las organizaciones humanas y los seres vivos tienen una cualidad en común: estos mantienen su
identidad a lo largo de su existencia a pesar de las diferentes perturbaciones que sufra su entorno. Estos se conocen como sistemas auto‐organizados. Lo anterior no se refiere a la trivialidad de lo
que “materialmente” conforma una organización. Por ejemplo puede que en el transcurso de varios años una empresa renueve a todo su personal, adquiera nuevas instalaciones, y opere en una ciudad nueva, sin embargo la organización mantiene su identidad, y todavía es reconocible
como “la misma” organización de hace unos años.
Dado lo anterior se puede decir que lo que se mantiene es la relación entre los elementos que
conforman el sistema, más no los elementos como tal, ya que el sistema tiene la capacidad de recrearlos continuamente. Esta capacidad de auto organización y auto generación de los sistemas
es conocida también como autopoiésis.
La principal causa de la mencionada capacidad de autopoiésis, y conservación de la identidad en
los sistemas auto‐organizados es la existencia de un propósito. Para un sistema, el propósito es el marco bajo el cual la labor de “mantenimiento” (renovación de las partes) es guiada. La falta de un propósito es usualmente un indicador del inminente colapso de un sistema auto‐organizado
(Hilder, 1995).
Jerarquía de propósitos, viabilidad
Todos los sistemas auto‐organizados comparten el hecho de tener uno o varios propósitos, los
cuales están organizados jerárquicamente. Sin embargo todos propósitos comparten el hecho de tener la necesidad de ser viables, es decir tienen la necesidad de existir, por lo menos hasta el
momento en que son logrados (Hilder, 1995). Esta una característica común a todos las organizaciones, aun cuando estas no tengan conciencia de ello. El VSM busca aumentar la efectividad de la organización haciéndola viable por diseño (Hilder, 1995).
Elementos de sistemas auto‐organizados:
En general se definen tres elementos fundamentales a la hora de estudiar el comportamiento los sistemas auto‐organizados:
• Operación: Elementos que “hacen cosas”, íntimamente relacionados con el o los propósitos del sistema.
• Administración: Elementos que controlan las operaciones (administración). • Entorno: Entorno en el que se encuentra el sistema.
47
De estos el que presenta mayor variedad es el entorno, le siguen las operaciones y por último se encuentra la administración (Hilder, 1995). La operación es el elemento que interactúa
directamente con el entorno, la administración, por su parte, interactúa con la operación. Esto se puede representar de la siguiente manera:
Homeostasis ‐Equilibrio en sistemas auto‐organizados ‐
Para que el sistema se mantenga en equilibrio y pueda mantenerse viable, la operación debe igualar su variedad a aquella del entorno, en otras palabras la operación debe estar en capacidad
de absorber la variedad presente en el entorno. Igualmente para que la administración pueda dirigir correctamente la operación, ésta debe estar en capacidad de absorber la variedad que se encuentra en la operación.
La absorción o equilibrio de variedades es una condición necesaria para que un sistema permanezca viable. El equilibrio se logra mediante los atenuadores y amplificadores presentes en
los canales de comunicación de los elementos del sistema (entorno ‐ operación, operación – administración). La capacidad de autorregulación, es decir la capacidad de mantener el equilibrio
frente a estímulos externos se conoce como homeostasis.
La condición descrita respecto a la absorción de variedades, necesaria para que un sistema
permanezca en equilibrio, es una consecuencia de la Ley de requisito de variedad de Ashby:
48
“El control sólo puede existir si la variedad del controlador es por lo menos igual a la variedad de la situación a ser controlada”
En otras palabras la ley puede expresarse como “sólo complejidad absorbe complejidad”. Stafford Beer considera la ley de Ashby tan importante para la cibernética como lo son las leyes de Newton
para la mecánica clásica (Hilder, 1995).
5.4.3 Estructura del VSM
Una de las principales características de la estructura del VSM es que es recursiva, por ejemplo, si consideramos una organización cualquiera, ésta cuenta con varias operaciones o departamentos,
cada uno de estos cuenta con su propia administración y opera dentro de un entorno propio. En otras palabras, afirmar que un VSM posee una estructura recursiva es equivalente a afirmar que un VSM se encuentra formado en su interior por más VSMs. Lo anterior se hace evidente si
tomamos como ejemplo el caso de una multinacional, la cual es un VSM. La multinacional tiene sus distintas filiales en distintos países y cada una de estas filiales es por sí misma un VSM.
El VSM está conformado por 5 sistemas los cuales son necesarios y suficientes para garantizar la viabilidad del sistema (Hilder, 1995):
• Sistema 1 (operación): También conocido como “implementación”, este sistema está conformado por todas la operaciones que realizan las acciones que justifican la existencia del sistema (Hilder, 1995). Un VSM puede contener varios sistema 1, cado uno de estos es
a su vez un VSM, tal y como lo sugiere el principio de recursión de los VSM. La interacción entre sistemas 1 varía en gran medida según el caso, por ejemplo para una empresa petrolera los sistemas 1 principales son la exploración, la extracción y el refinamiento del
petróleo; actividades que presentan un alto acoplamiento entre ellas.
• Sistema 2 (coordinación): Dada la interacción que ocurre entre los distintos sistema 1 de un VSM se hace necesaria la coordinación de los mismos, ésta precisamente es la labor del sistema 2. Otra de las principales funciones del sistema 2 es mantener la estabilidad del
sistema 1 (Kawalek, 1996). Por ejemplo en el caso de la empresa petrolera, se requiere una importante coordinación entre las operaciones de extracción y refinamiento del
petróleo. En la coordinación de las distintas operaciones de la organización no se ve involucrada la alta gerencia. Esta coordinación es responsabilidad de la administración de
cada una de las operaciones.
49
• Sistema 3 (control): Es el responsable del control de la organización. Controla las operaciones del sistema 1 y supervisa las actividades de coordinación realizadas por el sistema 2 (Hilder, 1995). En una organización puede verse como la alta gerencia que
controla la actividad de administración de las distintas operaciones de la organización. Por ejemplo las auditorias en las empresas pueden verse como un mecanismo del sistema 3
para controlar y supervisar la actividad de los sistemas 1 y 2. Entre más detallado sea el control que ejerce el sistema 3 sobre el sistema 1 una organización tiende hacia el autoritarismo (Hilder, 1995). Hoy en día el uso de sistemas de información ha permitido
que el control del sistema 3 sea más efectivo y detallado ya que puede monitorear casi en tiempo real numerosas variables que reflejan el desempeño y calidad de las actividades de
los sistemas 1 y 2.
• Sistema 4 (inteligencia): Los sistemas que se han descrito hasta el momento lidian con el día a día de la organización, estos no son suficientes para garantizar la viabilidad de un sistema que se encuentra en un entorno siempre cambiante. El sistema 4 corresponde a la
inteligencia del sistema, piensa en el futuro y diseña las estrategias y estructuras necesarias para mantener la viabilidad del sistema hacia futuro, en otras palabras diseña el futuro de la organización. El sistema 4 observa las fluctuaciones del entorno y tiene un
modelo actualizado del funcionamiento de las operaciones de la organización, es decir, interactúa constantemente con el sistema 3. El sistema 4 en general se encuentra en la
alta gerencia de las organizaciones o en la junta directiva si esta existe.
• Sistema 5 (identidad): El sistema 5 es el encargado del ethos de la organización (Hilder, 1995), mantiene la personalidad o identidad de la organización, ofrece claridad respecto a
la dirección, valores y propósitos de la organización. Adicionalmente monitorea los sistemas 3 y 4.
50
6. VSM como herramienta de interpretación de las metodologías de desarrollo de software
Como bien se explicó a lo largo del capítulo 3, que presenta la ingeniería de software, el diseño
organizacional de los equipos que desarrollan proyectos de software es uno de los aspectos más relevantes para asegurar el éxito de los mismos. La pregunta que las metodologías ágiles se han
planteado responder es: ¿Cómo debería organizarse de forma óptima el desarrollo de software? Dada su acogida, las metodologías ágiles parecen haber contestado de manera correcta esta
pregunta, sin embargo estas carecen de un sustento teórico coherente, sus principios tienen una base empírica más no teórica. Adicionalmente los principios de las metodologías ágiles presentan
limitaciones las cuales deben identificarse plenamente con el fin de no aplicar metodologías ágiles en contextos donde sería perjudicial.
Existen varias teorías que podrían proveer un fundamento teórico a las prácticas y principios enunciados en la filosofía de desarrollo ágil. Una de ellas es la teoría de los sistemas socio‐
técnicos, analizados brevemente en el capítulo 4.3.1. Sin embargo esta teoría presenta ciertas limitaciones, una de las principales es que solo puede ser aplicada a un nivel de abstracción
(Kawalek, 1996). Por otra parte el VSM provee una perspectiva teórica mucho más general, que puede ser aplicada a cualquier nivel de “recursión” (el equipo de desarrollo, el departamento, toda la organización) (Kawalek, 1996).
Bajo la perspectiva del VSM, los equipos deben ser vistos como sistemas con uno o varios
propósitos, los cuales son capaces de mantener una existencia separada de su entorno y de sobrevivir por su cuenta (Kawalek, 1996). El VSM describe la arquitectura interna que estos
sistemas deben tener para garantizar su viabilidad o supervivencia.
El presente capítulo tiene como fin contrastar las metodologías ágiles y tradicionales de desarrollo
de software mediante la estructura y lenguaje del VSM.
51
6.1 Comparación de metodologías RUP y eXtreme programming
Autopoiesis Descripción: Para los equipos de desarrollo de software la autopoiesis es de especial importancia. Para que el equipo de desarrollo permanezca viable debe estar en capacidad de mantener su identidad y funcionamiento bajo condiciones externas e internas cambiantes. Un equipo de desarrollo debe mantener su identidad aun cuando uno o varios de los integrantes del equipo abandonen el equipo. En la actualidad los desarrolladores de software presentan un dinamismo importante ya que frecuentemente trabajan en más de un proyecto a la vez y son trasladados en distintas etapas a distintos proyectos, rara vez todos los desarrolladores que inician un proyecto son los mismos que lo finalizan. RUP XP (eXtreme Programming) ¿Cómo se genera?
Los desarrolladores son vistos como componentes reemplazables13. Cada desarrollador tiene asignadas responsabilidades limitadas asociadas a un rol específico.
Rotación de roles y responsabilidades14, con este principio de XP se busca que el equipo se convierta en un sistema donde cada una de sus “partes” se encuentra en capacidad de asumir las responsabilidades de cualquier otra. Los nuevos integrantes del equipo reciben una inducción en cada uno de los aspectos técnicos y administrativos relevantes del proyecto.
Venta jas La búsqueda e inducción de los nuevos desarrolladores no es demasiado costosa dado que solo deben familiarizarse y contar con las habilidades de un rol específico.
La rotación de responsabilidades genera un conocimiento global del proyecto en cada uno de los individuos. Se evitan dependencias excesivas con individuos particulares que puedan abandonar y perjudicar fuertemente el proyecto en cualquier momento.
Limitaciones Si el “componente” que debe ser reemplazado es el arquitecto o el director del proyecto todo el proyecto se puede ver perjudicado. No es fácil conseguir y familiarizar a un nuevo arquitecto o director con todas las particularidades de un proyecto de software.
Es difícil formar un equipo en donde todos los desarrolladores tengan las habilidades necesarias para asumir cualquier rol y llevar a cabo tareas técnicas y administrativas. El proceso de inducción de nuevos individuos es costoso.
13 Martin Fowler – the new methodology http://martinfowler.com/articles/newMethodology.html 14 Esta regla de XP se encuentra en la sección de Management Rules – Move people around. http://www.extremeprogramming.org/rules/movepeople.html
52
Jerarquía de propósitos Descripción: En general el propósito de cualquier equipo de desarrollo de software independientemente de la metodología que sigan es finalizar satisfactoriamente el proyecto, esto es desarrollar el producto que cumpla con las necesidades del cliente en el tiempo presupuesto estimado. Sin embargo el propósito en las metodologías XP y RUP cuenta con diferencias sutiles pero relevantes. RUP XP (eXtreme Programming) ¿Cuál es el propósi to?
“Desarrollar software de manera disciplinada, eficiente y repetible” El propósito de RUP es desarrollar software de alta calidad con cronogramas y presupuestos predecibles. Todas las disciplinas y artefactos RUP se encuentran orientados a establecer procesos de desarrollo de software predecibles y repetibles.
“Generar valor al cliente a través de software” El propósito de XP se encuentra manifestado en los valores XP y el primer principio ágil (Agile Manifesto, 2001):
1. “Nuestra mayor prioridad es satisfacer las necesidades del cliente a través de entregas tempranas y continuas de software funcional”.
Implicaciones Bajo la metodología RUP se
entiende que el principal propósito del equipo es terminar el proyecto a tiempo dado los requerimientos establecidos al inicio del proyecto, en general el propósito de un equipo RUP es “desarrollar software”. Esta visión incompleta puede ser en gran medida responsable de la gran cantidad de proyectos de software que son finalizados a tiempo pero que no cumplen o satisfacen las necesidades de los clientes15.
Un equipo ágil es consciente de los beneficios que la organización del cliente obtendrá de la implementación del sistema y entiende cómo los objetivos de negocio del cliente se encuentran relacionados al proyecto. Para un equipo ágil terminar un proyecto a tiempo es una restricción que se debe cumplir, el verdadero propósito es generar valor al cliente.
15 Según el Chaos report del Standish Group del año 2009 el 24% de los proyectos fracasan, es decir no son usados por los clientes una vez finalizados.
53
Sistema 1 Descripción: También conocido como “implementación”, este sistema está conformado por todas la operaciones que realizan las acciones que justifican la existencia del sistema (Hilder, 1995). RUP XP (eXtreme Programming) Bajo la metodología RUP el
sistema 1 está conformado por cada uno de los desarrolladores del equipo, en última instancia son ellos quienes están construyendo día a día el producto final.
En la metodología eXtreme Programing el sistema 1 está conformado por cada una de las parejas que se establecen para el pair programming, son estas quienes realizan todas las labores operativas del sistema (especificar, diseñar e implementar el código)
Venta jas Se puede desarrollar una mayor cantidad de actividades paralelas ya que las tareas son realizadas por individuos
Cada una de estas parejas presenta una mejor capacidad para interactuar con la variedad que presenta el entorno. La formación de parejas permite contar con sistemas 1 mucho más equilibrados los cuales presentan productividades similares.
Desventajas En el VSM el sistema 1 es el tiene que lidiar con la variabilidad del entorno la cual es la más alta y fácilmente puede abrumar a cualquier desarrollador. Dado que los sistemas 1 de un equipo RUP son individuos la productividad de los mismos puede variar considerablemente, lo que da por resultado un comportamiento inestable en el sistema.
El pair programming es una práctica que no es fácilmente aceptada por los clientes, tener dos personas en un mismo computador no pareciera ser costo‐eficiente. Comparado con un equipo RUP, el número de tareas que pueden realizarse paralelamente disminuye a la mitad.
54
Sistema 2
Descripción: El sistema 2 es el encargado de la coordinación y estabilidad de los diferentes elementos del sistema 1 RUP XP (eXtreme Programming) En la metodología RUP toda la
administración del equipo es realizada por el rol del gerente o director de proyecto.
En las metodologías ágiles y en particular en XP el sistema 2 se ve manifestado de una manera mucho más informal. El sistema 2 consta de la comunicación diaria entre todas las parejas que conforman el sistema 1. En las metodologías ágiles todos los individuos participan de la planeación y coordinación de las tareas diarias de implementación.
Venta jas No es necesario que el equipo se conozca previamente, un buen director de proyecto contará con las herramientas suf icientes para coordinar las actividades del sistema 1.
En XP las parejas de pair programming gozan de libertad para reorganizarse según las necesidades diarias, como consecuencia se tiene un sistema 2 más flexible y apto para responder a contingencias del proyecto. Todos participan de la coordinación de actividades del sistema 1, las decisiones que se toman son mucho más informadas.
Desventajas La coordinación de las actividades diarias de implementación de los sistemas 1 de un proyecto de software requiere conocimientos técnicos detallados de la tecnología y arquitectura del sistema por lo tanto la eficacia del sistema 2 en equipos RUP depende de las habilidades gerenciales y técnicas del director del proyecto, habilidades que no son fáciles de encontrar en una sola persona.
La organización del sistema 2 puede tardar en ocurrir si los individuos que conforman el equipo no han traba jado previamente juntos.
55
Sistema 3
Descripción: Es el responsable del control de la organización. Controla las operaciones del sistema 1 y supervisa las actividades de coordinación realizadas por el sistema 2 (Hilder, 1995). RUP XP (eXtreme Programming)
El sistema 3 en esta metodología se encuentra reflejado en la meticulosa planeación y diseño de arquitectura realizados al inicio del proyecto. El sistema 3 se ve manifestado en las labores de dos individuos: el director de proyecto y el arquitecto líder.
El sistema 3 en XP no se encuentra claramente definido ya que no se define un rol particular de director de proyecto, por el contrario en la dirección del proyecto se ven involucrados todos los participantes del proyecto, incluyendo el cliente.
Venta jas La centralización del sistema 3 en un individuo puede hacer que la toma decisiones se de de manera más ágil.
Toma de decisiones mejor informada ya que todos los individuos participan de la administración del proyecto
Desventajas La principal debilidad que tiene RUP respecto al sistema 3 es que asume que los requerimientos, arquitectura y planeación del proyecto no sufrirán cambios bruscos, lo cual ha probado ser bastante improbable en proyectos reales.
En la práctica el sistema 3 de equipos XP puede ser bastante frágil, por ejemplo si las labores del sistema 1 acaparan todo el tiempo de los integrantes del equipo estos no podrán dedicar el tiempo suficiente a las labores del sistema 3. XP no menciona de manera explícita la necesidad de definir un líder del equipo lo cual puede resultar en la falta de agilidad en la toma de decisiones.
56
Sistema 4
Descripción: El sistema 4 corresponde a la inteligencia del sistema, piensa en el futuro y diseña las estrategias y estructuras necesarias para mantener la viabilidad del sistema hacia futuro. RUP XP (eXtreme Programming) El sistema 4 en RUP es casi
inexistente, las fluctuaciones del entorno no son contempladas explícitamente.
En general todas las metodologías ágiles son adaptativas, razón por la cual se invita a la constante modificación de la metodología según las necesidades del proyecto. En XP todos los integrantes del equipo hacen parte del sistema 4, el espacio en donde se realizan las tareas del sistema 4 es al final de cada iteración en donde el equipo completo reflexiona sobre su desempeño y sobre el estado general del producto.
Venta jas Todos los individuos que participan del proyecto cuentan con un espacio para debatir ideas sobre cómo mejora r el proceso de desarrollo.
Desventajas Una vez más este sistema se encuentra centralizado en el rol de director de proyecto, el cual generalmente ocupa todo su tiempo en la realización de las tareas de los sistemas 2 y 3.
57
Sistema 5
Descripción: El sistema 5 es el encargado del ethos de la organización (Hilder, 1995), mantiene la personalidad o identidad de la organización RUP XP (eXtreme Programming) RUP: en un equipo que opera con
RUP no se tiene en cuenta a los individuos, por lo tanto el ethos o sistema 5 es prácticamente inexistente. La única preocupación de RUP es el desarrollo del proyecto bajo los planes estipulados.
XP: los principios ágiles ofrecen un marco general para el ethos de los equipos.
Venta jas En XP se promueve la valentía, el coraje y el respeto mutuo entre desarrolladores y clientes (Extreme Programming, 1999).
Desventajas El ethos de la metodología RUP no tiene en cuenta a los individuos, no cuenta con valores o incentivos para las personas.
58
7. Equipos de trabajo autoorganizados (SMWT)
7.1 Introducción
Los SMWTs hacen referencia a la sigla en inglés de Self Managed Work Teams. Nacen a partir de la
evolución de las teorías organizacionales y de administración, las cuales han determinado la forma en que hoy se estructuran y operan las organizaciones. En particular los SMWTs toman la mayoría
de ideas provenientes del enfoque de los sistemas técnico‐sociales mencionados en el capítulo 4, los cuales dan igual importancia al sistema técnico y al sistema social que se desarrolla al interior de cualquier organización.
Las metodologías ágiles de desarrollo de software han desarrollado varios de los principios de los SMWT de manera empírica. Como se expuso en el capítulo 3, los principios ágiles buscan propiciar
un entorno en donde la auto‐organización ocurra tal que el control surja al interior del equipo y no sea impuesto por una autoridad superior (Fowler, 2005). Por esta razón, para entender y
complementar los principios ágiles de las metodologías ágiles de desarrollo de software, es importante estudiar los conceptos, limitaciones y ventajas encontradas por los principales exponentes de la teoría de los equipos de los equipos de trabajo auto‐organizados (SMWT).
Como su nombre lo indica, los SMWTs proponen equipos en donde la organización, administración
y ejecución del trabajo es realizada parte de los integrantes del equipo de trabajo (Dale E. Yeatts, 1998). En los equipos auto‐organizados los integrantes del equipo se encargan de:
• Definir las metas y objetivos del trabajo a realizar.
• Estimar los tiempos de ejecución y determinar el plan de trabajo acorde a las necesidades establecidas por ellos.
• Ejecutar el trabajo diseñado y planeado por el equipo.
Como principal diferencia frente a los esquemas organizacionales más tradicionales se tiene que en los SMWT todos los miembros del equipo hacen parte de los procesos administrativos y de
toma de decisiones del trabajo. Por el contrario en los esquemas de trabajo más tradicionales estas labores se consideran responsabilidad exclusiva de la alta gerencia.
Otro aspecto importante de los SMWTs es que las tareas técnicas y administrativas son rotadas
entre los integrantes del equipo. Con la rotación de roles y responsabilidades se ofrece a todos los individuos la posibilidad de poner en uso y desarrollar habilidades de distinta naturaleza, como lo
son habilidades técnicas para cumplir especificaciones del trabajo, habilidades sociales para
59
entender, proponer y discutir las decisiones que guiaran el trabajo del equipo, y habilidades administrativas para monitorear y organizar el trabajo de la manera más eficiente (Dale E. Yeatts,
1998).
7.2 Ventajas y Desafíos de los SMWTs
Los SMWT representan un cambio drástico frente al paradigma tradicional, en el que sólo los individuos en posiciones administrativas y gerenciales tenían la autoridad o capacidad para tomar
decisiones, los SMWTs presentan grandes retos a las organizaciones, pero a su vez presentan importantes ventajas.
7.2.1 Ventajas
Las ventajas de los SMWTs se pueden clasificar en dos clases, primero las ventajas que ofrece al
funcionamiento del sistema técnico del equipo, y segundo las ventajas que ofrece al sistema social del equipo.
Las necesidades del sistema social son satisfechas de manera eficiente y directa, ya que los miembros del equipo llegan a conocerse y entenderse unos a otros. El ambiente del trabajo induce al constante contacto de los integrantes, permitiendo de esta manera que ellos mismos puedan
detectar y corregir situaciones que perturben el funcionamiento del sistema social, siempre teniendo en cuenta las necesidades sociales de todo el equipo (Dale E. Yeatts, 1998).
Por otro lado, las necesidades del sistema técnico son igualmente satisfechas de manera eficiente y directa por parte de los integrantes del equipo. Las fuertes interacciones que suceden al interior
del equipo, permiten que los integrantes estén constantemente intercambiando información respecto a las tareas técnicas a realizar, de esta manera siempre se está discutiendo y
compartiendo información sobre la mejor forma de realizar las actividades, las mejores soluciones a problemas comunes, etc.
Algunas de las ventajas adicionales de los SMWTs frente a los esquemas tradicionales de
organización del trabajo mencionadas en la literatura son:
• Más desempeño en el trabajo a un menor costo.
• Se genera un entorno en el que todos obtienen beneficios, es decir tanto la organización cómo los individuos obtienen beneficios producto de esta manera de organizar del
trabajo.
• Promueven la innovación, la creatividad y el compromiso hacia el trabajo por parte de los participantes de la organización.
• Generan un ambiente de solidaridad entre los integrantes del equipo y hacia la organización como tal.
60
Analizando las ventajas que presentan los SMWTs, es claro que este esquema de trabajo resulta ideal para organizaciones cuyo foco de trabajo es el desarrollo de proyectos, en particular de
desarrollo de software. Este tipo de proyectos han probado ser bastante impredecibles debido a factores como la tecnología y los requerimientos de negocio cambiantes constantemente. Las ventajas ofrecidas por los SMWT son especialmente relevantes para cualquier proyecto de
software, la productividad y motivación de los desarrolladores alcanza su máximo punto en un entorno donde se promueve la creatividad, innovación y libertad.
Adicionalmente los equipos de trabajo auto‐organizados generan un alto nivel de compromiso entre los integrantes del equipo, en donde cada individuo tiene pleno conocimiento del propósito
y los objetivos del equipo.
7.2.2 Desafíos
La implementación de SMWTs en las organizaciones es un proceso delicado, ya que lo que se busca, de cierto modo, es una transferencia de control o autoridad. En el contexto de software,
este es un desafío evidente, ya que en la metodología RUP de desarrollo de software el control es un elemento proveniente del exterior del equipo, por el contrario, en un equipo que opera bajo metodología ágil el control surge del interior del equipo. Para tener una transición exitosa hacia un
esquema de SMWT en una organización con esquemas tradicionales, es conveniente un acercamiento incremental, en el cual a medida que el equipo madura y adquiere experiencia en
tareas administrativas, más de estas tareas le son delegadas. De esta manera se minimizan los riegos que implica delegar la totalidad de las labores administrativas y el control al equipo
abruptamente.
Varios expertos en metodología ágiles como Fowler, Beck y Cockburn coinciden en que ninguna
organización que opere actualmente con metodologías tradicionales debe implementar los principios ágiles de manera abrupta, por el contrario es necesaria una transición en la cual el equipo y sus individuos desarrollen poco a poco nuevas habilidades requeridas para que la auto‐
organización sea exitosa.
Algunos de los aspectos más importantes para tener en cuenta a la hora de implementar SMWTs
son:
• Soporte y compromiso constante de la administración y la gerencia: Es necesario el apoyo constante de la gerencia a los equipos, entre las principales responsabilidades se
encuentran:
61
o La generación de un entorno el cual mantenga motivado al equipo, de esta manera obteniendo calidad superior en el trabajo de los integrantes y un orden en
el funcionamiento interno del equipo. o Monitorear el funcionamiento del equipo e intervenir en situaciones que se salen
del control del mismo, de esta manera el equipo se siente respaldado en situaciones difíciles, se genera un mayor compromiso entre los diferentes participantes de la organización y se obtiene mayor calidad en el trabajo realizado.
• Entrenamiento adecuado de los empleados: Tutorías en tareas administrativas por parte de la gerencia, en particular tutorías o seminarios para planeación de proyectos, definición y seguimiento de metas y objetivos, gestión de riesgos, entre otros.
• Definición de procesos claros para el diseño de los equipos: Un SMWT requiere diseño, no se trata simplemente de juntar personas y ponerlas a trabajar juntas, se requiere evaluar capacidades técnicas y características personales de cada integrante con el fin de asegurar
compatibilidad entre los miembros, propiciando así sistemas sociales y técnicos eficientes. En el caso de proyectos de desarrollo de software esto es aun más crítico, ya que cada
proyecto requiere de personas con conocimientos y capacidades técnicas muy particulares las cuales frecuentemente son difíciles de encontrar.
• Perfilamiento de empleados: Para diseñar correctamente los equipos de trabajo es
necesario contar con procesos de evaluación y perfilamiento de los empleados.
Los aspectos mencionados representan grandes retos en las organizaciones que desean implementar SMWTs de alto desempeño. Adicionalmente, los aspectos ya mencionados se
pueden complementar con la idea fuerza detrás de la Teoría de las Contingencias. En dicha propuesta, se establece que no existe un número limitado de factores a tener en cuenta para
asegurar un buen desempeño las organizaciones. En general lo que se debe hacer es proveer a la organización de una capacidad de reacción ágil, y así reaccionar y adaptarse a las posibles
contingencias o situaciones que pueden ocurrir al interior o exterior de ella. Bajo el marco de los SMWTs las contingencias en general pueden clasificarse en uno de tres tipos (Dale E. Yeatts, 1998):
• Contingencias de carácter individual o personal: Es bien sabido que una mayor satisfacción de los integrantes del equipo conduce a una mayor productividad, pero identificar cuáles son las necesidades que los integrantes del equipo buscan satisfacer puede ser difícil. Aún
cuando las necesidades de los integrantes se logren identificar plenamente, ¿son estas necesidades las mismas en todo momento del tiempo? Seguramente no. Por esta razón al
momento de constituir un equipo de trabajo no se puede asumir que los intereses y preferencias de las personas que lo conforman no van a cambiar a lo largo del tiempo. Una
ventaja que ofrece un SMTP frente este aspecto es el hecho de la flexibilidad en cuanto a los roles que puede asumir una persona a lo largo de un proyecto. Cuando los intereses de una persona cambian se puede evaluar las posibilidades de asignarle un nuevo rol, cuyas
responsabilidades se ajusten mejor a las necesidades actuales de la persona.
62
• Contingencias de carácter tecnológico: La naturaleza del trabajo a realizar determina de manera importante las características y limitaciones de la dinámica del equipo, algunos trabajos consisten en tareas repetitivas y sencillas los cuales generan poca interacción al
interior del equipo, algunos son complejos y cambiantes los cuales requieren de una interacción fuerte de los integrantes. En general la naturaleza del trabajo depende de los
siguientes factores:
o Complejidad de las tareas a realizar.
o Características rutinarias de las tareas. o Interdependencia de las tareas.
• Contingencias del entorno: la naturaleza incierta y cambiante del entorno, supone para las organizaciones una necesitad latente de detectar eficientemente los cambios en el
entorno con el fin rediseñar los elementos que sean necesarios para sobrevivir al nuevo entorno.
7.2.3 Entorno cambiante vs Entorno estable
Relacionado a las contingencias del entorno, existe un estudio que expone las características que
varían al interior de las organizaciones como consecuencia del nivel de volatilidad e incertidumbre que presenta el entorno que las rodea. Lawrence y Lorsch (1967) encontraron que las
organizaciones que mejor desempeño presentan en entornos estables y predecibles eran aquellas que tenían estructuras organizacionales bien definidas, contaban con procedimientos
estandarizados y con esquemas de poder centralizado. Por otra parte en entornos volátiles y cambiantes, las organizaciones que se destacaban eran aquellas que presentaban estructuras informales, procedimientos no estandarizados y descentralización del poder (Dale E. Yeatts, 1998).
Los resultados del estudio de Lawrence y Lorsch sugieren entonces que para el caso de las organizaciones que se dedican al desarrollo de proyectos de software resulta más conveniente un
esquema de trabajo de SMWTs, ya que usualmente el entorno de este tipo de organizaciones presenta una variabilidad considerable. En particular la tecnología y los requerimientos de los
clientes aspectos que cuentan con alta variabilidad y que afectan de manera importante el desempeño de los equipos de desarrollo de software.
7.3 Factores determinantes para el éxito de los SMWTs
En la dinámica de funcionamiento de un SMWT constantemente se encuentran activos dos
procesos principales, primero se encuentra el proceso de trabajo, es decir el proceso que consiste básicamente en las tareas que llevan al cumplimiento de los objetivos del equipo (asociado al
63
sistema técnico); y segundo se encuentra el proceso interpersonal formado por las interacciones al interior del equipo y la interacción del equipo con su entorno (asociado al sistema social). Para
entender cada uno de los procesos mencionados resulta útil identificar algunos de los elementos que juegan un rol importante en cada uno de los sistemas relacionados (Dale E. Yeatts, 1998).
La eficiencia o éxito del proceso de trabajo al interior de un SMWT depende fundamentalmente de la cantidad de esfuerzo que los integrantes del equipo están dedicando efectivamente a la
realización de las tareas que efectivamente acercan al equipo al cumplimiento de sus objetivos. Adicional al esfuerzo, dentro del proceso de trabajo los elementos de talento, recursos y
procedimientos son fundamentales para la eficiencia y dinámica del proceso.
Esfuerzo En este contexto se refiere a la cantidad de energía humana gastada directamente en realizar el trabajo. El esfuerzo está estrechamente relacionado con la motivación y compromiso por parte de
los integrantes del equipo (Dale E. Yeatts, 1998), sin embargo el esfuerzo por sí solo no es suficiente para asegurar un buen desempeño del equipo. Es común encontrar situaciones en las
que personas realizan esfuerzos considerables dentro del equipo, pero la gran mayoría de este esfuerzo o energía se está empleando en superar problemas de comunicación y coordinación con
otras personas o equipos de trabajo, y no en la realización de las tareas que efectivamente acercan al equipo al cumplimiento de sus objetivos (Dale E. Yeatts, 1998).
Algunos de los factores que más influyen para propiciar el desgaste de energía o empleo de esfuerzo en actividades no productivas fueron identificados por Katerberg y Blau (1983), se muestran algunos de los más relevantes:
• Soporte y afinidad con la gerencia: Numerosos entrevistados en el estudio comentaron sobre la importancia de la relación con la gerencia. Si los integrantes del equipo deciden intentar reducir las diferencias en cuanto a visión, dirección del grupo, objetivos, modo de
funcionamiento el equipo va a consumir gran parte del esfuerzo en esta labor y poca en la realización del trabajo. Por otro lado si los integrantes del equipo no se sienten
respaldados y alineados con la gerencia y son indiferentes a esto, es decir, no luchan por solucionar las diferencias con la gerencia, puede perderse el compromiso hacia el equipo y
la organización, en consecuencia el esfuerzo será dedicado principalmente a deseos o intereses individuales y no a los del equipo.
• Diseño del equipo: Dentro de este aspecto los más influyentes según el estudio son el
tamaño de los equipos y las reglas de funcionamiento definidas para estos. En general a medida que el tamaño de los equipos aumenta se aumentan los esfuerzos requeridos para contar con comunicación y coordinación eficaz dentro de los equipos. Las normas
definidas para los equipos en algunos casos mostraron ser benéficas, dichas reglas fueron descritas como aquellas que brindan claridad en la dinámica de funcionamiento del
equipo. En otros casos las normas fueron consideradas como perjudiciales para el
64
desempeño del equipo y la mayoría de estas eran percibidas como burocracia que entorpecía el funcionamiento eficiente del equipo.
• Procesos interpersonales: dentro de estos procesos se consideran de especial importancia la comunicación y coordinación entre los miembros del equipo como factores que influyen en la cantidad de esfuerzo que es efectivamente empleada en el trabajo por parte. En el
estudio realizado por (Dale E. Yeatts, 1998) se describe como equipos altamente coordinados invierten una gran proporción de su tiempo en el trabajo y no en la planeación o coordinación del mismo.
Como ya se mencionó anteriormente, varios estudios han sugerido que la cantidad de esfuerzo que un empleado dedica al trabajo está estrechamente relacionado con la motivación y el
compromiso del equipo (Hackman, 1988; Katzenbach & Smith,1993; Pearce & Ravlin, 1987). Por esto mismo es necesario describir un poco más en detalle estos dos aspectos fundamentales.
Compromiso
El compromiso es un factor bastante conocido y discutido a la hora de evaluar el esfuerzo que se
observa por parte de los integrantes del equipo. Varios estudios han categorizado el compromiso de la siguiente forma (Dale E. Yeatts, 1998):
• Compromiso afectivo: cuando se piensa en compromiso generalmente se hace referencia a esta categoría, la cual es la correspondiente a la identificación y cercanía emocional que siente la persona con su equipo y su organización.
• Compromiso de continuidad (continuance): hace referencia a los costos percibidos por la persona en caso de que esta decida dejar la organización o el equipo.
Larson y LaFasto (1989) describen las consecuencias de la existencia de un alto compromiso en un equipo de trabajo:
“… es la voluntad de hacer todo lo que sea necesario para llevar el equipo al éxito. Es una fuerte identificación con un grupo de personas. Es la pérdida del individuo”
Motivación
Este es otro de los aspectos ampliamente discutidos en la literatura referente al esfuerzo que los
empleados dedican a la realización del trabajo. De igual manera es abundante la literatura que se
65
puede encontrar sobre la motivación en los empleados. La motivación es uno de los principales factores estudiados para explicar las enormes diferencias en productividad que se presentan en
los desarrolladores de software (Cusumano, 2004).
Numerosos estudios han llegado a la conclusión que la motivación en los desarrolladores es uno
de los principales factores que influye en el éxito de los proyectos de software, y frecuentemente es un factor que pasa desapercibido por la dificultad que representa definir e medir la motivación (Standish Group, 1995). La mayoría de las dificultades que enfrentan los proyectos de software
son humanas y no técnicas (IT Cortex), por esto es necesario conocer un poco más sobre las teorías y estudios desarrollados para entender la motivación de los empleados y de las personas
en general.
Entre las teorías más importantes de la motivación de los empleados se encuentran la teoría de la
jerarquía de necesidades de Maslow (1954) y la teoría de las expectativas Vroom (1964/1995).
• Teoría de la jerarquía de necesidades: Los individuos presentan mayor motivación cuando alguna de sus necesidades, en especial las de mayor jerarquía, no está satisfecha, y el entorno de trabajo en el que se encuentra el individuo brinda la confianza suficiente al
individuo de poder satisfacer dicha necesidad a través del trabajo. Por ejemplo, si el dinero es suficiente para el nivel de vida deseado del individuo, cubriendo para este las
necesidades deseadas de alimentación, vivienda, esparcimiento, etc. el dinero ya no será un estimulo para un incremento en la motivación, como si lo pueden ser factores laborales
que estimulen necesidades de mayor orden como lo son la autorrealización y el crecimiento personal (Dale E. Yeatts, 1998).
• Teoría de las expectativas de Vroom: Al igual que la teoría de Maslow, Vroom expone que la motivación surge cuando el individuo presenta necesidades no satisfechas y este toma decisiones consientes de seguir ciertos comportamientos o realizar ciertas actividades que a su criterio generan expectativas de obtención de recompensas (Dale E. Yeatts, 1998),
dichas recompensas, considera el individuo, ayudan a satisfacer las necesidades no satisfechas. El proceso básico para despertar la motivación en los individuos es el
siguiente:
1. Existe una correlación positiva entre el esfuerzo y el desempeño en el trabajo. 2. El aumento en el desempeño resultara en recompensas deseables 3. Las recompensas satisfacen necesidades importantes 4. La necesidad de satisfacer la necesidad es tal que el esfuerzo empleado se
considera justificado.
66
La teoría de las expectativas presenta tres componentes básicos: o Expectativa: Es el nivel de confianza que el individuo tiene respecto a su habilidad
para cumplir satisfactoriamente el comportamiento o tareas requeridas. o Medios: Es el nivel de confianza que el individuo tiene respecto a obtener
recompensas adecuadas si el comportamiento o tareas requeridas son logradas satisfactoriamente.
o Valencia: El valor que la persona asigna a las recompensas a obtener.
Cuando alguno de estos tres aspectos no existe en las cantidades necesarias para el individuo la cantidad de motivación y por ende de esfuerzo se reducen dramáticamente
(Dale E. Yeatts, 1998).
Talento
El talento de los individuos es uno de los elementos que mayor correlación presentan con el desempeño de los equipos de trabajo. El talento puede desglosarse y entenderse como
conocimiento, habilidad y facilidad (Dale E. Yeatts, 1998). Bajo este contexto puede considerarse el siguiente ejemplo:
Un músico muy talentoso seguramente:
Nació con cierta facilidad para la música.
Ha practicado durante toda su vida y ha desarrollado gran habilidad en algún instrumento.
Ha estudiado música toda su vida y posee gran cantidad de conocimiento
sobre esta.
Para obtener equipos de alto desempeño evidentemente lo más deseable es que todos los
integrantes del equipo posean los tres elementos que constituyen el talento (Dale E. Yeatts, 1998), sin embargo esto es muy difícil de lograr. Los SMWTs logran estimular el talento del equipo
gracias a las oportunidades de explorar facilidades ocultas en los individuos. La rotación de roles y responsabilidades, y la participación activa en la toma de decisiones aumentan la probabilidad de
generar conocimiento y desarrollar habilidades nuevas en cada uno de los integrantes del equipo. No hay que olvidar que el esquema de trabajo de los SMWTs no es atractivo para todas las personas, como ya se mencionó es fundamental contar con personas comprometidas y motivadas
para llegar a estimular y desarrollar el talento en la organización.
Respecto al talento, los SMWTs de mayor desempeño que se han evaluado son aquellos que
cuentan con unas características particulares (Dale E. Yeatts, 1998):
• Los integrantes del equipo poseen habilidades similares en las tareas fundamentales a realizar (no existen “súper estrellas”)
67
• La organización provee constante entrenamiento en diversos tópicos, los cuales no necesariamente están directamente relacionados con el conocimiento asociado a las tareas a realizar.
• Las normas del equipo promueven la discusión abierta sobre insuficiencias en la calidad del trabajo de los integrantes.
• Los individuos son receptivos a críticas respecto a su manera de trabajar.
Recursos
Este elemento se refiere básicamente a las herramientas, los materiales y espacio de trabajo requeridos para el funcionamiento del equipo. Es evidente que este es un factor directamente
relacionado con el desempeño cualquier equipo de trabajo. Si los individuos no cuentan con las herramientas apropiadas o lugar de trabajo adecuado la calidad de producto o del servicio
ofrecido por el equipo disminuirá dramáticamente (Dale E. Yeatts, 1998). En una organización basada en SMWTs el juicio más relevante sobre la calidad de los recursos disponibles son los
integrantes de los equipos, ya que son estos los que se encuentran efectivamente realizando el trabajo y empleando los recursos.
Si se desea implementar SMWTs la gerencia tiene la responsabilidad de promover la evaluación
periódica de los recursos por parte de los equipos y otorgar libertad a los mismos para estudiar nuevas posibilidades bajo unas restricciones claras de presupuesto. Muchas organizaciones han
mostrado incrementos significativos en el desempeño de los equipos tan solo permitiendo cambios tan pequeños como elegir sus oficinas de trabajo y la organización de las mismas (Dale E.
Yeatts, 1998).
Procedimientos
Los procedimientos establecidos por el equipo para desarrollar tareas particulares tienen estrecha
relación con el desempeño del mismo. Es evidente que procedimientos más eficientes y eficaces resultan en mayor eficiencia y eficacia en el equipo en general, por eso lo importante a determinar
la manera en que los equipos seleccionan los procedimientos a seguir.
En el estudio se SMWTs de (Dale E. Yeatts, 1998) se encontró que el factor más relevante a la hora
de diseñar el equipo y modo de operación del mismo eran los métodos y herramientas usadas para elegir los procedimientos a seguir en el equipo. Los equipos de alto desempeño presentan en general las siguientes características respecto a los procedimientos que efectúan:
• Los equipos discuten los procedimientos actuales y están abiertos al cambio.
• Son metódicos en la elección los procedimientos.
• Formalizan los procedimientos con diagramas de flujo o mapas de proceso para evaluar el trabajo actual y como puede ser el trabajo futuro.
68
• Fomentan la lluvia de ideas para encontrar maneras de mejorar los procedimientos actuales.
• Están atentos a retroalimentación por parte de los clientes y de la gerencia para identificar posibles mejoras a los procedimientos actuales.
Cuando los equipos presentan las características mencionadas, usualmente es debido a una base de normas definidas en el equipo, las cuales son evaluadas periódicamente por todos los
integrantes del equipo y presentan una evolución a lo largo del ciclo de vida del SMWT. Entre las normas más importantes se encuentran aquellas que definen los objetivos del grupo y la forma de
medir la consecución o progreso hacia de dichas metas por medio de indicadores de progreso y desempeño. Los equipos de alto desempeño operan bajo normas que exigen la evaluación o rediseño de los procedimientos cuando los indicadores caen en valores no deseados (Dale E.
Yeatts, 1998). Por otro lado, equipos en los cuales no se han definido claramente los objetivos e indicadores del funcionamiento del mismo los procedimientos y el desempeño del equipo
muestran no ser insuficientes.
7.4 Formación de SMWTs
Juntar personas con habilidades o conocimientos particulares y ponerlas a trabajar juntas no implica que se ha creado un equipo, mucho menos que se ha creado un SMWT. Los equipos
verdaderos no se generan espontáneamente, siguen un proceso de creación y madurez, los SMWTs no son la excepción.
La literatura menciona innumerables factores que se consideran fundamentales para la formación
de equipos de trabajo auto‐organizados como lo son los SMWTs. Entre los factores importantes se destacan (Miller Howard Consulting Group, 1994):
1. Se debe asignar un propósito al grupo: ¿Por qué se conformó el grupo? ¿Qué está intentando producir?
2. Se debe tener claridad en la forma de medir el desempeño del grupo: ¿Cuál es nuestro producto u output? ¿Quiénes son los stakeholders? ¿Cómo se mide el desempeño del
grupo? 3. Recalcar a los participantes el valor que representa el equipo: El todo es mayor que la
suma de las partes, los resultados que se pueden obtener como equipo superan en mucho
a los resultados que se pueden obtener como individuos. 4. Crear conciencia en los participantes de la interdependencia que implica el hacer parte de
un equipo: El éxito de las tareas asignadas a un integrante cualquiera dependerá frecuentemente en gran medida del éxito alcanzado en las tareas asignadas a otros
integrantes.
69
5. Dejar claro a los participantes que cada uno de ellos es responsable tanto del desempeño personal como del desempeño global del equipo.
Las organizaciones que contemplen estos aspectos a la hora de implementar SMWTs tendrán muy buenas posibilidades de alcanzar el éxito, sin embargo estos no son suficientes (Katzenbach &
Smith, 1993). Adicionalmente a estos aspectos, para que los equipos se integren correctamente con la cultura y funcionamiento de la organización se requiere inculcar en ellos los principios o ideales valorados en la organización. Claramente si dichos ideales van en contravía de los
principios fundamentales necesarios para la implementación de SMWTs, estos deben ser modificados y hacerse explícitos para que sean del conocimiento de todos los involucrados en la
organización (Pasmore, 1988).
Los equipos hacen parte de la organización y por eso es necesario desarrollar un sentido de
pertenencia de los mismos al interior de esta, de lo contrario el desempeño y la estabilidad general de la organización se pueden ver gravemente afectados (Katzenbach & Smith, 1993). Con
el fin de desarrollar el sentido de pertenencia de los equipos una actividad sencilla puede realizarse en las primeras etapas de formación del grupo (Miller Howard Consulting Group, 1994):
• La gerencia o equipo administrativo del grupo expone la misión, visión y mapa estratégico de la organización a los equipos recientemente formados.
• Los integrantes del equipo discuten los elementos expuestos y exponen a la gerencia como ellos consideran que la implementación de equipos contribuye a la consecución de la misión y visión de la organización.
Hasta el momento se han descrito algunos de los elementos más importantes para formar equipos de trabajo exitosos, sin embargo hace falta potencializar el desempeño de estos equipos
estructurándolos como SMWTs, es decir hace falta definir los elementos necesarios para generar la auto‐organización de los equipos.
Para empezar se debe educar en detalle a los integrantes de los equipos sobre lo que es un SMWTs y las diferencias que se tiene frente a los equipos tradicionales. No es necesario entrar en cada uno de los detalles del funcionamiento de un SMWT maduro, resulta más importante educar
a los participantes en la filosofía y las ventajas que representa para la organización y para los individuos este esquema de trabajo (Dale E. Yeatts, 1998). Resulta muy difícil, si no imposible,
crear SMWT de alto desempeño por accidente. Es decir si no se tiene la conciencia e identidad en los integrantes de pertenecer a un SMWT y entender lo que esto significa la iniciativa de
implementar este esquema de trabajo fracasará, he aquí la importancia de este primer punto.
Una vez se genera la conciencia en los participantes de lo que significa e implica hacer parte de un
SMWT se debe proceder a establecer los mecanismos por los cuales el control y la organización del grupo van a surgir al interior del mismo, en otras palabras, se deben definir los mecanismos que promueven la auto‐organización (Orsburn & Moran, 2000). Los elementos fundamentales para
lograr este cometido son tres:
70
• Propósito: Aunque usualmente los equipos nacen con un propósito dado por la gerencia, se debe dar cierta libertad a los integrantes del equipo para que refinen o complementen el propósito del SMWT.
• Desempeño: Dado el propósito del grupo ¿Cuándo se considera que el grupo está presentando buen desempeño? ¿Qué indicadores se pueden definir para medir el desempeño del grupo? ¿Qué indicadores se pueden definir para medir el desempeño de
los individuos?
• Responsables: Dada una clasificación general de las tareas a realizar por los integrantes ¿Quiénes son los responsables de realizarlas? ¿Quiénes son los responsables de
monitorear el desempeño del grupo? ¿Quiénes son los responsables de monitorear el desempeño de los integrantes del equipo?
Si es la primera vez que la gerencia y los individuos se embarcan en una iniciativa de
implementación de SMWTs, seguramente la primera respuesta que se dará a los interrogantes descritos será en su mayoría la misma: la gerencia o la unidad administrativa de la organización
define y monitorea las medidas de desempeño del grupo y de los individuos. Sin embargo es necesario recordar la filosofía de los SMWT: auto‐organización, es de esta manera que los
participantes del SMWT se embarcan en la primera tarea administrativa: definir todas las medidas de desempeño necesarias para mantener el grupo bajo control y encaminado al cumplimiento de
su propósito. Del mismo modo, la mayoría de la responsabilidad del monitoreo y evaluación del grupo y de los individuos debe quedar asignada al interior del equipo, teniendo siempre claro que todas estas responsabilidades van a ser turnadas por todos los integrantes del equipo (Dale E.
Yeatts, 1998).
Algunas de las practicas más comunes para generar la auto‐organización de los equipos es la
realización periódica de auto‐evaluaciones y evaluaciones por pares, de esta manera todos los integrantes del grupo constantemente reflexionan sobre su desempeño en el grupo y sobre el
desempeño de los demás individuos.
7.5 SMWTs y eXtreme Programming (XP)
Los SMWT presentan de manera detallada varios de los principios tras las metodologías ágiles y en particular tras la metodología ágil eXtreme Programming. Es claro que para las metodologías ágiles
es fundamental lograr la auto‐organización tal que el equipo auto‐regule su funcionamiento y su desempeño. Estudiando las ventajas, dificultades y requisitos para implementar equipos auto‐
organizados se pueden encontrar aspectos que XP no ha tenido en cuenta, se destacan los siguientes:
• Diseño del equipo: XP no enuncia de manera explícita los principios o aspectos a tener en
cuenta a la hora de diseñar un equipo de desarrollo de software. Las organizaciones que deseen implementar la metodología XP de manera efectiva deben diseñar procesos en los
71
cuales se evalúen las habilidades técnicas requeridas para la realización del proyecto así como las habilidades sociales requeridas para hacer parte de un equipo XP, es importante
tener en cuenta que no cualquier individuo puede hacer parte de un equipo XP. Adicionalmente para poner obtener los beneficios de la programación en pares (pair
programming) las parejas se deben formar sin intervención alguna de una figura de autoridad, para que esto suceda debe existir un mínimo nivel de compatibilidad entre las distintas personalidades del equipo de trabajo.
• Formación de los individuos: En un equipo XP los individuos tienen la oportunidad de desarrollar habilidades que nunca han puesto en práctica, como la planeación del trabajo y el monitoreo del desempeño del equipo. Todos los integrantes del equipo XP participan
en las tareas administrativas que exige el proyecto, por lo tanto la organización debe identificar los individuos que no poseen conocimiento de estas tareas y ofrecer un
entrenamiento mínimo en los temas respectivos (planeación, monitoreo, diseño de indicadores, etc.).
• Motivación de los individuos: Para lograr el mejor desempeño de los individuos estos deben estar motivados. En XP y los principios ágiles se enuncia la importancia de la motivación de los individuos, sin embargo las metodologías no entran en detalle de lo que es y sobre cómo despertar motivación en las personas. Una organización que desea
implementar equipos XP debería apoyarse en la teoría motivacional de Maslow o Vroom e identificar si los individuos que harán parte del equipo XP se verán motivados por el
esquema de trabajo XP, no hay que olvidar que un equipo ágil no se forma con desarrolladores “promedio” (Synapsis Canada, 2009).
• Sentido de pertenencia a la organización: Bajo un esquema de trabajo XP el equipo goza de gran independencia, este diseña, planea y monitorea la totalidad del trabajo, sin embargo esto no debe convertirse en un total abandono por parte de la organización. Es
importante transmitir los valores y políticas generales de la organización a todos los integrantes del equipo XP. Adicionalmente el equipo debe sentir el respaldo de la organización si algún aspecto del proyecto de sale del control del equipo.
72
8. Conclusiones
1. Las metodologías de desarrollo de software han presentado una evolución similar a la que presentaron las teorías organizacionales. Inicialmente se enfocaron por el
diseño del trabajo (administración científica del trabajo equivalente al modelo cascada y RUP) y paulatinamente incorporaron ideas de las teorías de las
relaciones humanas y sistémicas (metodologías ágiles).
2. Dadas las condiciones tecnológicas y económicas tan variables e impredecibles
que se dan en la actualidad una metodología predictiva como RUP no se encuentra en capacidad de anticipar todas las eventualidades que ocurrirán en un
proyecto de software. Las metodologías ágiles se diseñaron para ser adaptativas y por lo tanto más aptas para entornos variables e impredecibles.
3. El desarrollo de software es una labor principalmente creativa por lo tanto difícil
de planear detalladamente como pretende la metodología RUP. Las metodologías ágiles son conscientes de la importancia de la creatividad, por lo tanto no contemplan la elaboración de planes de trabajo a largo plazo. Estos pueden ir en
contra de la creatividad y adaptabilidad del equipo de trabajo.
4. Las metodologías ágiles de desarrollo de software fueron concebidas por la comunidad de desarrolladores. No es una metodología impuesta por autoridades
superiores, por lo tanto una transición hacia metodología ágil casi siempre será vista con “buenos ojos” por parte de los desarrolladores.
5. Ninguna organización debe implantar ágil de manera abrupta. Se requiere de un esfuerzo importante por parte de la gerencia y de los clientes. La transición hacia
ágil debe realizarse incrementalmente.
73
6. Una organización que desee implementar metodologías ágiles debe estar consciente de las dificultades que enfrentará, una de las principales es aceptar el
hecho de que se requiere de individuos talentosos y con altas capacidades técnicas y sociales para conformar un equipo ágil exitoso.
7. El concepto de variedad y la ley de Ashby resultan de gran ayuda para entender las
ventajas de una metodología más “informal” o flexible como XP en entornos
impredecibles y de gran variedad.
8. El VSM de Beer está concebido bajo un gran rigor matemático, sin embargo su
aplicación no exige rigor matemático alguno. El VSM representa una estructura mental y un lenguaje común, los cuales son útiles para analizar la viabilidad de los
sistemas. 9. Bajo un análisis del VSM de la metodología RUP y XP se identificaron posibles
debilidades que presentan las dos metodologías, sin embargo la metodología XP
presenta mayores posibilidades de viabilidad ya que un equipo bajo esta metodología tiene claro el verdadero propósito de un proyecto de software:
entregar valor al cliente.
10. Los equipos de trabajo auto‐organizados (SMWT) presentan ideas complementarias a las expuestas por eXtreme Programming (XP). Uno de los
complementos más importantes es la definición procesos de selección de individuos.
74
9. Bibliografía
Agile Manifesto. (2001). Agile Manifesto. Recuperado el 10 de 8 de 2009, de Agile Manifesto:
http://agilemanifesto.org/
Allee, V. (1997). The knowledge Evolution. Newton: Butterwoth‐Heinemann.
American society for cybernetics. (s.f.). Definitions. Obtenido de http://www.asc‐
cybernetics.org/foundations/definitions.htm
American society for cybernetics. (s.f.). History of Cybernetics. Recuperado el 3 de 1 de 2009, de
http://www.asc‐cybernetics.org/foundations/history.htm
Ashby, W. R. (1964). An Introduction to Cybernetics. London: Methuen.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., y otros. (2001). The Agile Manifesto. Recuperado el 11 de 12 de 2008, de Manifesto for Agile Software
Development.
Beer, S. (1981). Brain of the firm. West Sussex: Wiley.
Beer, S. (1985). Diagnosing the system for organizations. West Sussex: Wiley.
Bureau of Labor Statistics, U.S. Department of Labor. (2008). Occupational Outlook Handbook, Computer Software Engineers. Recuperado el 10 de Septiembre de 2008, de
http://www.bls.gov/oco/ocos267.htm
Cockburn, A. (21 de 10 de 1999). Characterizing people as non‐linear, first‐order components in
software development. Recuperado el 1 de 1 de 2010, de sitio web de Alistair Cockburn: http://alistair.cockburn.us/Characterizing+people+as+non‐linear%2c+first‐
order+components+in+software+development
Cockburn, A. (11 de 9 de 2009). I come to bury agile, not to praise it. Recuperado el 5 de 10 de 2009, de infoq: http://www.infoq.com/presentations/cockburn‐bury‐not‐praise‐agile
Cockburn, A., & Williams, L. (2002). The Costs and Benefits of Pair Programming.
Computer World. (28 de 9 de 2007). Agile methodology: Why aren't you using it? Recuperado el 2
de 1 de 2010, de Computer World: http://www.computerworlduk.com/technology/development/software/opinion/index.cfm?article
id=802&pn=2
Cross, D. W. (1998). Evolution or Revolution: Creating a Team‐Based Organization. New Directions for Institutional Research , 83‐94.
Cusumano, M. A. (2004). The business of software. New York: Free Press.
75
Dale E. Yeatts, C. H. (1998). High‐Performing Self‐Managed Work Teams. Thousand Oaks: Sage.
Dávila Guevara, C. (2001). Teorías organizacionales y administración Enfoque crítico. Bogotá:
McGrawHill.
Extreme Programming. (1999). A gentle introduction. Recuperado el 20 de 12 de 2008, de
http://www.extremeprogramming.org/
Fowler, M. (2005). Sitio web Martin Fowler. Recuperado el 1 de 1 de 2010, de The New Methodology: http://martinfowler.com/articles/newMethodology.html
Hilder, T. (1995). The Viable System Model. Recuperado el 9 de 12 de 2008
IBM. (12 de 10 de 2005). Introducing the IBM Rational Unified Process essentials by analogy.
Recuperado el 20 de 11 de 2009, de Introducing the IBM Rational Unified Process essentials by analogy: http://www.ibm.com/developerworks/rational/library/05/wessberg/
IBM. (s.f.). Rational Unified Process: Best Practices for Software Development Teams. Recuperado el 5 de 1 de 2010, de IBM:
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
IT Cortex. (s.f.). Failure Rate. Recuperado el 10 de Septiembre de 2008, de sitio Web de IT Cortex:
http://www.it‐cortex.com/Stat_Failure_Rate.htm
Katzenbach, J. R., & Smith, D. K. (1993). The wisdom of teams: creating high‐performance
organization. Boston: Harvard Business School Press.
Kawalek, P. (1996). Organisational design for software development:A cybernetic Perspective.
Lecture Notes in Computer Science , 257‐270.
LaCette, S. (10 de 2006). Subject: Job Satisfaction, Employee Morale, and Employee Motivation.
Recuperado el 1 de 8 de 2009, de Cornell University ILR School: http://digitalcommons.ilr.cornell.edu/ilrtheses/23/
Larman, C., & Basili, V. R. (2003). Iterative and Incremental Development: A Brief History.
Computer , 36 (6), 47‐56.
Larsen, D. (2004). Team Agility: Exploring Self‐Organizing Software. The agile times newsletter .
Miller Howard Consulting Group. (1994). Team Management:Creating systems and skills for a Team‐based organization. Atlanta: Miller Howard.
NATO science committee. (1969). Software Engineering. Brussels.
Orsburn, D. J., Moran, L., Musselwhite, E., & Zenger, J. H. (1990). Self‐directed work teams. Homewood: Business One Irwin.
76
Orsburn, J. A., & Moran, L. (2000). The new self‐directed work teams. London: Mc Graw Hil.
Pasmore, W. A. (1988). Designing effective organizations: the sociotechnical systems perspective.
New York: Wiley.
Qualdev Group, Universidad de los Andes. (2008). Grupo de Construcción de Software. Recuperado
el 10 de Octubre de 2008, de http://qualdev.uniandes.edu.co
Raul Espejo, A. G. (s.f.). The Viable System Model as a Framework for Understanding Organizations.
Royce, W. (1970). Managing the development of large software systems.
Schwaninger, M. (2004). What Can Cybernetics Contribute to the Conscious Evolution of
Organizations and Society? SystemsResearch and Behavioral Science , 515‐527.
Stack overflow. (septiembre de 2008). What is the biggest problem with software development?
Recuperado el 12 de diciembre de 2009, de Stack overflow: http://stackoverflow.com/questions/75771/what‐is‐the‐biggest‐problem‐with‐software‐
development
Standish Group. (1995). Chaos Report. Recuperado el 9 de Mayo de 2008, de sitio Web de Educause: http://www.educause.edu/ir/library/pdf/NCP08083B.pdf
Standish Group. (2009). Chaos summary 2009. Recuperado el 5 de 12 de 2009, de Standish Group: http://www.standishgroup.com/newsroom/chaos_2009.php
Synapsis Canada. (14 de 1 de 2009). Limitations of Agile Software Development. Recuperado el 3 de 1 de 2010, de Synapsis Canada: http://www.synapsys.ca/
Szulanski, G. (2003). Sticky knowledge: barriers to knowing in the firm. Thousand Oaks: Sage.
