Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que al final nos puede arrojar más luz es: "¿para qué se va a usar?". Es decir, intentar buscar la solución que mejor se adapte a nuestro problema o escenario específico.

Métrica v3 vs Metodologías ágiles, no son una excepción. Yo tras haber usado las dos, tengo una opinión formada. Yo usaría Métrica v3 en las circunstancias que paso a exponer:
- Proyectos extremadamente grandes, donde es importante tener un análisis funcional suficientemente especificado.
- Proyectos en los que intervengan multitud de equipos de trabajo, donde la comunicación no siempre sea fácil.
- Proyectos con posibilidad de tener una rotación de personal alta.
- Proyectos encargados por clientes, que no tienen suficientemente claro lo que desean, ni lo que esperan.
- Proyectos con requisitos iniciales inestables, cuyos cambios puedan suponer un alto impacto, y grandes desviaciones en los plazos de un proyecto.
- Proyectos ejecutados por programadores muy "juniors".
- Proyectos en los que Métrica v3 es requisito no funcional del cliente (normalmente Administraciones Públicas).

Muchas de estas circunstancias vienen reflejadas en el Informe Chaos como causas de la mayoría de los fracasos en los proyectos de desarrollo software, y se pueden paliar de manera significativa mediante Métrica.

Es verdad que cada cambio introducido en los Requisitos Funcionales (FRQ), por ejemplo, puede suponer tener que realizar modificaciones en uno o varios, Requisitos de Información (IRQ), Restricciones o Reglas de Negocio (CRQ), en los Casos de Uso, e incluso en el Modelo de Datos, y mantener esto a menudo resulta tedioso y es costoso en tiempo, pero también nos proporciona:

- Unos requisitos estables.
- Una especificación detallada del proyecto, que puede llegar hasta la separación en numerosas tareas muy simples.
- Un análisis que el cliente debe validar, y que supone el "contrato" tanto para desarrolladores como para el propio cliente.
- Trazabilidad que nos indique el impacto y los costes que suponen una petición de cambio.

Por contra, es verdad que para los proyectos en los que no se den las circunstancias que he expuesto anteriormente, las técnicas ágiles, o una adaptación de estas (dependiendo del proyecto, experiencia y capacidad del equipo, cliente) nos pueden dar mejores resultados.