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 Tipo de Iteraciones Roles - Facilitador Roles
–
Scrum
XP
Kanban
Iteraciones de plazo
Iteraciones de plazo
Iteraciones plazo fijo
fijo
variable
o variable
Scrum Master
Coach, Big Boss
N/A
Product Owner
Cliente
N/A
Administrador Requerimientos
30
Roles
–
Equipo
Equipo de
Proyecto
Desarrollo
Equipos
Multifuncional
Programador, Tester
N/A
Especializados
Especializados o Multifuncional
Practicas / Reglas Limitación Work In Progress Incorporación
de
Tareas Seguimiento
de
9
12
3
Limitación por
Limitación por
Limitación por
iteración
iteración
estado
No es posible hasta
No es posible hasta
Es posible, en tanto
finalizar el sprint
terminar la iteración
exista capacidad
Grafico Burn-down
Velocity
Tablero kanban
Obligatoria
Obligatoria
Opcional
tareas Estimación
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. Software Quality Assurance (SQA): Aseguramiento de Calidad del Software. 5 Software Configuration Management (SCM): Administración de la Configuración del Software 4
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
Funcionales
Funcionales o Matriciales
Mínima necesaria
Intensiva en generación de
Tipo Equipos Documentación
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
