Procesos y Marcos de Referencia vs Métodos Ágiles

En la actualidad principalmente existen 2 formas o vertientes de desarrollar software: Una es utilizando procesos formales/modelos de capacidad y la otra es utilizando métodos ágiles.

A continuación expondremos brevemente las características, alcances y limitaciones de cada una.


Procesos Formales/Modelos de Capacidad
Son formas de construcción basadas en experiencias previas, modelos o técnicas matemáticas (probabilidad, estadística, cálculo), planificación, seguimiento y manejo del riesgo.
Ejemplos típicos de estas formas de trabajo las tenemos en procesos como el RUP, PSP y TSP, en modelos de capacidad como CMM, CMMI o en sistemas de calidad (referencia) como ISO15504.
Surgen como una evolución de las formas de trabajo de los años 60, 70, y 80´s en donde la problemática se concentraba en no poder controlar la forma en que se desarrollaba el software a gran escala.

Métodos Ágiles
Son formas de trabajo que surgen a principios del año 2000 y es una respuesta natural ante la insatisfacción de los usuarios, las organizaciones y los propios miembros de los equipos de desarrollo de no poder controlar el desarrollo de software y no entregar el valor esperado al negocio, aún cuando se haya tratado de emplear un proceso o modelo de capacidad formal.
Ejemplo de métodos o metodologías ágiles los tenemos en: Extreme Programming, SCRUM, FDD, Crystal Clear, DSDM, MSF, etc.

Como se puede apreciar ambas formas de trabajo buscan dar respuesta a problemas similares aunque lo hacen de forma muy diferente:


Beneficios de los Procesos/Modelos de Capacidad
En general los beneficios que se ha podido probar de utilizar estas formas de trabajo son:
- Útiles para atacar problemas o proyectos grandes y/o complejos, en donde se requiera conocer el estado del proyecto mediante la producción de artefactos, esto es, el grado de avance en la producción de artefactos es tomado como base para deducir el avance del proyecto, de ahí que el enfoque se dé en la planificación, desarrollo y medición de artefactos.
- La bibliografía y los cuerpos de conocimientos de como aplicarlos son bastos, mucha de la bibliografía, referencias y casos es de relativamente fácil acceso.
- Existe una industria completa dedicada al entrenamiento de técnicas y herramientas, así como a la producción de las mismas que automatizan y buscan eficientar las actividades preescritas por los procesos y/o los modelos de capacidad.


Limitaciones de los Procesos Formales/Modelos de Capacidad
Entre varias de las limitaciones de los procesos formales y/o modelos de capacidad podemos encontrar las siguientes:
- Inversión alta inicialmente. Esto se debe a la naturaleza de los procesos o los modelos de capacidad, en general, estos indican el "QUÉ" y muy pocas veces el "CÓMO" sobre todo en los referente a herramientas, tecnologías y dominios del problema, por ende es necesario adquirir servicios especializados de capacitación o recursos que ya tengan antescedentes y conocimientos en el tema.
- La aplicación y práctica de los procesos o los modelos no garantizan el éxito en los proyectos (como tampoco lo garantiza el uso de los métodos ágiles), sin embargo existe la posibilidad, y de hecho hay casos comprobados y documentados, de organizaciones que siguieron un procesos o modelo y al final no entregaron valor alguno a su organización.
- Mucha de la capacitación y el entrenamiento en los procesos y modelos de referencia o capacidad son impartidos por personal que realmente no hace software, y si bien esto puede representar una ventaja porque se tienen ideas frescas, sin tendencias o preconcepciones, la realidad es que en la mayoría de los casos muchos preescriben sin saber ni conocer las, necesidades, requerimientos e implicaciones de llevar a cabo una sugerencia en un proyecto dado.
- Finalmente la calificación o evaluación que un grupo o área pueda tener en un momento dado no demuestra el estado de madurez del resto de la organización ni el estado que en poco o mucho tiempo pueda tener el mismo grupo o área evaluado; Esto es, la evaluación es solo un reporte del nivel de madurez del grupo en un momento dado del tiempo, de hecho esto puede ser más dramático aún: La misma organización puede ser evaluada posteriormente y puede dejar de tener esas capacidades demostradas con anterioridad, no sólo eso, ha habido casos en donde es relativamente fácil engañar al evaluador mediante la producción de "evidencias" falsas que buscan satisfacer un requerimiento específico sin que en verdad se halla generado con anterioridad dicha evidencia, en otras palabras, si se sabe que tipo de artefacto será necesario presentar para contestar o entregar una evidencia de que se realiza una práctica o disciplina es fácil producirlo rápidamente y entregarlo "engañando" a la evaluación, esto es, se produjo para pasar la evaluación, no porque en verdad el equipo, grupo o área de desarrollo acostumbre a generarlo en sus proyectos.


Beneficios de los Métodos Ágiles
Entre los principales beneficios de los métodos ágiles se encuentran:
- Se enfocan únicamente en las prácticas que entregan valor al negocio y al equipo, si una práctica entorpece al equipo o no entrega valor queda fuera.
- El estado y avance del proyecto es siempre conocido por todos los miembros del equipo incluyendo por supuesto al usuario y/o cliente, ya que la medida del progreso principal es el software probado y funcionando.
- La responsabilidad y la propiedad es compartida, esto es, no hay forma de decir "fue su culpa o responsabilidad", todo lo producido es propiedad y responsabilidad de todos, esto no indica que no pueda existir un rol de liderazgo dentro de los equipos, sino que es la comunidad la responsable de la planeación, estado, actividades y avance del proyecto.
- La colaboración y la comunicación es más directa, rápida y efectiva, la comunicación preferida es siempre "cara a cara" (face-to-face).
- La velocidad de integración de un miembro externo al equipo es más rápida, debido a que cualquiera puede darle el estado del proyecto, saber en dónde están los artefactos producidos y el porque de su estado actual.
- Aunque hay pocos casos documentados se sabe que utilizando este tipo de métodos es posible recuperar y/o acelerar proyectos retrazados, esto es importante porque a diferencia de los procesos o marcos formales, en general se reconoce que al incorporar más recursos a un proyecto retrazado seguramente redundará en mas atrazo.


Limitaciones de los Métodos Ágiles.
- Es necesario contar con una MAYOR DISCIPLINA que en el seguimiento de un proceso o modelo, esto puede resultar contradictorio pero no lo es, el porque es simple, los métodos ágiles son flexibles, adaptables y maleables, no impiden o preescriben una práctica o herramienta en específico, sino solo aquellas que redundarán en un beneficio para el equipo y el negocio, de ahí que sea sumamente fácil decidir no usar o efectuar una práctica, herramienta o técnica, las razones pueden ser desde el deseo de ahorrar o dejar de hacer algo hasta simplemente tener miedo o ignorancia de tomar una iniciativa o utilizar una herramienta. El punto es que no existe una figura o rol (como QA) o un proceso que indique o vigile que se tiene o no se tiene que hacer determinada actividad, por lo tanto es facil caer en el libertinaje y en la no ejecución de las actividades; Es por eso que se afirma que es necesario tener una MAYOR DISCIPLINA al utilizar una metodología ágil.
- Además de una mayor disciplina es necesario contar con un mayor dominio técnico de las herramientas y tecnologías que se empleen en los proyectos, esto no quiere decir que se deba tener a un grupo de expertos contratados de antemano, pero si indica que se deban realizar las acciones necesarias para poder agilizar el manejo y uso de la herramienta o tecnología, de hecho si se está en etapas iniciales de adopción es importante contar con coaches o mentores calificados no sólo en el conocimiento de las prácticas sino en la ejecución de las mismas, el uso de herramientas y las tecnologías particulares a emplear durante los proyectos.
- No hay tanta bibliografía ni casos documentados EN COMPARACION con el aservo existente de caso que utilizaron procesos o modelos de capacidad.
- Es necesario una apertura de mente, un compromiso sostenido y un deseo de autoaprendizaje y autoregulación por la propia organización y por los ejecutivos o patrocinadores. Esto es fundamental porque al igual que una organización que apenas se está adentrando en el mundo de procesos, es necesario que esta experimente un deseo de cambio superior al miedo o dolor que esté experimentando si mantiene su nivel o estado de desarrollo anterior.


Finalmente unas palabras de advertencia y reflexión.
¿Cuál utilizar? esto queda a juicio de la propia organización y los patrocinadores, en general antes de decidir, se debe analizar los objetivos de negocio, su capacidad y deseo de cambio y el entorno y características de sus proyectos, equipos y clientes.

El autor recomienda utilizar las dos formas de manera discreta inicialmente, esto es, si se desea ir por un proceso formal o modelo de capacidad, entonces comprometerse totalmente aunque en forma reducida a una área de proceso o disciplina determinada. Por ejemplo, si se ha decidido sólo adoptar una disciplina o área clave como administración de la configuración entonces el objetivo es aplicarse y comprometerse con todo a esta práctica, esto implica capacitar formalmente al equipo y adquirir las licencias, tecnología y apoyo necesario y suficiente para realizarla efectivamente, en lugar de tratar de abarcar mas disciplinas o áreas de proceso y hacerlo a medias.
Lo mismo sucede para los métodos ágiles, por ejemplo si se ha decidio adoptar Extreme Programming y la única práctica que se ha decidio implementar es el trabajo total de equipo y comunicación directa, entonces se deberá incluir y comprometer al usuario dentro del equipo, esto es, el usuario es parte del equipo y tiene que vivir lo que los demás miembros, en lugar de solo verificar o clarificar esporádicamente el avance y los requerimientos del proyecto.

En resumen, la adopción de una metodología, práctica, proceso o modelo de capacidad depende de los objetivos, necesidades, compromiso y habilidades de cada grupo o área de desarrollo, y queda en ellos analizar estos puntos para tomar la mejor decisión.