2.

6 Comparativa Metodologías Agiles

Esta sección se realizará una comparativa entre las metodologías agiles mencionada
anteriormente en la sección 1.5. Esta comparativa estará basada en los siguiente
criterios[15]  [16]  [1]  [7]:
• Tipo de iteraciones: “puede ser de alcance fijo o plazo fijo” termina el tiempo o e
alcance.
• Roles (Facilitador, Administrador Requerimientos, Equipo Proyecto): Se
indican cuáles son los roles en común para cada metodología.
• Tipo de equipo: Indica las características que debe tener el equipo que adopte una
cierta metodología.
• Limitación del trabajo en progreso: Se indican las diferencias de cómo e
limitado el número de elementos de trabajo que son realizados al mismo tiempo en
el flujo de trabajo.
• Incorporar tareas: Debido a que existe la posibilidad de que los requerimiento
cambien o se agreguen nuevos, se evalúa cuando es posible incorporarlos.
• Seguimiento de procesos: Se indica la forma como es realizado el seguimiento de
performance de las actividades.
• Estimaciones: Se compara la necesidad de realizar la estimación de las tareas a
inicio.

Tabla 3 .- Comparativa Metodologías Ágiles

Metodología
Criterio Scrum XP Kanban
Tipo de Iteraciones Iteraciones de plazo Iteraciones de plazo Iteraciones plazo fijo
fijo variable o variable
Roles - Facilitador Scrum Master Coach, Big Boss N/A
Roles – Product Owner Cliente N/A
Administrador
Requerimientos

30
Roles – Equipo Equipo de Programador, Tester N/A
Proyecto Desarrollo
Equipos Multifuncional Especializados Especializados o
Multifuncional
Practicas / Reglas 9 12 3
Limitación Work In Limitación por Limitación por Limitación por
Progress iteración iteración estado
Incorporación de No es posible hasta No es posible hasta Es posible, en tanto
Tareas finalizar el sprint terminar la iteración exista capacidad
Seguimiento de Grafico Burn-down Velocity Tablero kanban
tareas
Estimación Obligatoria Obligatoria Opcional

Si bien las metodologías presentadas son denominadas ágiles, hay algunas que son más
ligeras que otras al momento de utilizarlas, donde una metodología como XP indica más
reglas a seguir (más prescriptiva), hasta Kanban que solo propone 3 reglas.

31
 Vamos a comparar algunas herramientas de proceso más en la escala
restrictivo vs adaptativo:

Figura 14 .- Prácticas Definidas por Metodologías (RUP2, XP, Scrum, Kanban)

8
3 Definición del Problema
El problema que se intenta abordar en este trabajo de título se centra principalmente en las
limitantes y rigidez impuesta por la metodología de administración de proyectos donde se
deben llevar a cabo los proyectos de desarrollo de software. Estos inconvenientes son
presentados en las siguientes secciones separados en 3 tipos de problemas, problemas
generalizados al desarrollo de software, relacionados a metodologías y finalmente los
desafíos que surgen en el entorno actual donde deben ser desarrollados los proyectos de
software empresariales.

3.1 Problemas del dominio general del Software

• Naturaleza intangible de los requerimientos: La captura y definición de
requerimientos, la mayoría de las veces es un proceso que toma bastante tiempo ya
que al inicio de un proyecto los stakeholders no tienen una claridad total de lo que
necesitan, más aún en proyectos donde se implantara una solución tecnológica
totalmente nueva debido a que no tienen una base sobre la cual comenzar a trabajar
2
Rational Unified Process (RUP) es un proceso de desarrollo de software iterativo creado por IBM
en 2003. [3]
32
 y desarrollar sus requerimientos. Por lo tanto, la probabilidad de obtener
requerimientos mal definidos, o que no satisfagan la necesidad real del cliente es
muy alta, ya que el encargado del desarrollo del producto de software estará
“exigiendo” muchas veces avanzar en un documento claro y detallado, donde
obtenga una especificación con el mayor nivel de granularidad posible, para así
tener un alcance muy acotado y lograr un “contrato” con su contraparte. Toda esta
realidad hace que la etapa de definición de requerimientos consuma una gran
cantidad del tiempo del proyecto. [13] Luego de este proceso de captura de
requerimientos puede venir un cambio sobre estas definiciones, influenciada por
algún factor externo, como algún tema regulatorio del gobierno u oportunidad de
negocio que surge, o alguna mejora que realizar a la definición. Es decir, la
predicción del desarrollo realizada al inicio del proyecto con la etapa de recolección
de requerimientos debe cambiar y el proceso de desarrollo debe adaptarse a estos
nuevos requerimientos. [26]
• Extensión de Plazos y Costos: Uno de los mayores problemas de los proyectos TI se
presenta es no cumplir con los plazos y costos definidos y aprobados al inicio del
proyecto, existiendo casos aún más críticos donde se toma la decisión de cancelar el
proyecto. [21] [3]
• Contratos Desarrollo de Software: La mayoría de los contratos definidos en los
proyectos han sido definidos a un precio fijo, en base a un tiempo y alcance definido
desde el inicio, que corresponden a contratos cerrados o llave en mano. En este tipo
de contratos el mayor riesgo lo asume quien realiza el desarrollo de software. Por lo
tanto, con esta restricción definida hace muy difícil la una variación de los
requerimientos. [1] [22]

3.2 Problemas en la adopción de metodologías en contextos

restringidos
• Metodología Rígida o Inexistente: Existen proyectos que se desarrollan en
ambientes que poseen metodologías rígidas y que se ajustan a modelos de
administración de proyectos bajo los estándares definidos por el PMI, y bajo una
metodología de desarrollo cascada, donde las etapas están muy marcadas y no hay

33
 avances hacia otra etapa, sino fue finalizada y aprobada la etapa anterior. Por otro
lado, nos podemos encontrar con compañías donde el nivel de madurez en
administración de proyectos es muy bajo y no existe un marco metodológico sobre
el cual basarse y finalmente se traduce en llevar a cabo los proyectos en base al
conocimiento del “Project manager” con un foco en el mejor esfuerzo. [23]
• Bajo nivel de comunicación entre el profesional TI y Negocio: Un problema que se
origina la mayoría de las veces, como consecuencia de los puntos anteriores, es una
compleja relación ya que existe una baja satisfacción y desconfianza de los
usuarios de negocio que son la mayoría de las veces los clientes de las áreas de TI.
Esta problemática complica la comunicación directa y fluida que es imprescindible
a lo largo de todo el proyecto. La adopción de una metodología rígida contribuye a
que la comunicación está basada en documentos que muchas veces no reflejan las
necesidades o prioridades de los requerimientos definidos. [24]
• Estrategia de Implementación de una Metodología Ágil: Desde una metodología de
desarrollo del tipo cascada hacia una ágil como Scrum, existen muchas diferencias y
desafíos que enfrentar para su correcto uso. El paso desde una administración de
proyectos por etapas rígidas hacia una visión iterativa del proyecto, conlleva a
muchos problemas en algunas actividades del desarrollo como URD3, SQA 4y SCM
5
que en algunas oportunidades se transforman en un riesgo que puede evolucionar
hasta un problema. [3] [1]

3.3 Problemas generados por evolución de mercados

• Time-To-Market: Constantemente cuando el proyecto esta en las etapas iniciales
surgen comentarios por parte de los stakeholders como “debemos tener esta
solución en producción en 3 meses”, o “era para ayer”. Existe una realidad que no
podemos ignorar y la realidad de hoy es que el mercado es cada vez más
competitivo, la necesidad de liberar a publico una solución tecnológica rápidamente
es solicitada cada vez con mayor presión, transformándose muchas veces en uno de
los factores para considerar un proyecto como exitoso, un tiempo de salida a

3
User Request Document (URD): Documento de Requerimientos del Usuario.
4
Software Quality Assurance (SQA): Aseguramiento de Calidad del Software.
5
Software Configuration Management (SCM): Administración de la Configuración del Software
34
 mercado relativamente bajo, y más importante muchas veces, antes que la
competencia directa. [25] [21]
• Ambiente empresarial volátil y cambiante: Actualmente en algunas industrias las
decisiones que son tomadas deben ser modificadas para poder adaptarse a los
mercados y lograr competir, y tal vez en algunos casos obtener alguna ventaja con
otras empresas del mismo sector. Este tipo de ambigüedad y cambio en el mercado,
puede llegar a afectar las definiciones que son realizadas en las etapas iniciales de
un proyecto y ser necesario un “cambio de estrategia” que finalmente puede llegar a
impactar a la evolución del proyecto y satisfacción del cliente sponsor del proyecto.
[25] [3]
• Evolución de las tecnologías de la información: Hace ya un tiempo atrás Roger
Moore indico que la capacidad de procesamiento de los ordenadores, desarrollados
en base a circuitos integrados, se duplicaría cada dos años. Esta ley ha sido una
realidad con la cual ha tocado convivir, donde el crecimiento en procesamiento de
información ha originado un impacto año a año en la industria del software. [21]
Como podemos desprender de los puntos anteriores existen variados desafíos a ser
enfrentados en cada proyecto de desarrollo de software y que están presentes desde inicio a
fin del proyecto. Estos desafíos van desde factores internos de cómo están organizados los
procesos de desarrollo de software y administración, hasta factores externos que afectan el
proceso, como es un entorno cambiante y cada vez más exigente. Las metodologías ágiles
proponen un marco de trabajo que logre hacer frente a esta realidad buscando aportar
practicas considerando que el desarrollo de software más que una actividad predecible, es
una actividad adaptable al entorno donde se está desarrollando y que es sustentada por
personas, quienes deben ser respetadas y guiadas para obtener lo mejor de cada integrante
del equipo. Pensando siempre en entregar un producto o servicio valorado por el cliente
final.

35
3.4 Dificultades en la adopción de metodologías agiles bajo contexto
PMI
A continuación presentamos una tabla donde se intenta resumir las diferencias a ser
consideradas entre una administración ágil de proyectos y una tradicional, identificando los
puntos a ser considerados al momento de proponer nuestro marco de trabajo.
Tabla 4 .- Principales Diferencias Metodologías Ágiles y Tradicional

Gestión Ágil Gestión Tradicional

Alcance del proyecto Variable Fijo
Tamaño Equipos Pequeños Grandes o pequeños
Tipo Equipos Funcionales Funcionales o Matriciales
Documentación Mínima necesaria Intensiva en generación de
documentos

3.5 Caracterización del Entorno a aplicar el Marco de Trabajo

El marco de trabajo a desarrollar estará ajustado a una empresa nacional del rubro de las
telecomunicaciones, y que posee una definición establecida por la Oficina de
Administración de Proyectos (PMO) para administrar los proyectos. Esta área dentro de la
organización es la encargada de dictar las normas y controlar el cumplimiento de estas a lo
largo del ciclo de vida de cualquier proyecto realizado dentro de la Gerencia de Sistemas de
esta organización. Los equipos de proyectos están liderados por un jefe de proyecto y
apoyado por analistas de sistemas, quienes forman parte directa de la compañía, mientras
que las tareas de programación son entregadas a empresas externas, tercerizando todo el
trabajo de mayor nivel técnico con empresas especializadas.
A continuación se presenta un diagrama que resume el ciclo de vida y gestión de un
proyecto en la organización en estudio.

36