u402472

Vista previa del material en texto

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, estodebido 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 considerabaimportante 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 ágilescomparten 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  individuosexpresen  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 pruebaspara 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 calidadposible. 
 
• 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  fundamentosde  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