Creo que es cierto, en algunos entornos Agile se utiliza como excusa para no disciplinar. El verdadero problema es que hemos perdido de vista por qué tenemos alguna metodología. Personalmente, creo que la metodología es un problema arquitectónico en el sentido de que se supone que la arquitectura del sistema aborda los atributos de calidad no funcionales, la metodología debería abordar algunos de esos mismos atributos (mantenibilidad, productividad del desarrollo, transferencia de conocimiento, et al.)
Ver la metodología como un control para los atributos del proceso implica un par de cosas: 1) sin métricas, no podemos comparar la efectividad de una metodología sobre otra, 2) es necesario tomar una decisión activa sobre qué atributos son importantes (tiempo de entrega versus código calidad vs transferencia de conocimiento).
Sin tener métricas y un objetivo tangible, simplemente elegimos una metodología como nuestra "pluma mágica" que, si nos aferramos a ella, podremos entregar software.
Ahora los que dicen en contra de Agile, XP, Scrum, etc. hablan sobre la fragilidad de esa categoría particular de metodologías. El argumento es: ¿por qué usar una metodología que pueda ser saboteada por un individuo que carece de la disciplina para seguir todas las reglas? La pregunta es válida; sin embargo, ese es el síntoma, no la causa. Si un conjunto de métricas de proceso precisas y significativas (esa es la parte difícil) se definen, prueban y reciben comentarios oportunos, creo que descubriremos que la metodología particular tiene poco que ver con el éxito. (Hablando de manera anecdótica, he visto proyectos exitosos que usan una miríada de metodologías y el doble de los que fallan usando las mismas metodologías)
Entonces, ¿cuáles son las métricas? Varían de proyecto a proyecto, de equipo a equipo y de vez en cuando. Útil para cuando el cronograma de entrega es importante, uno que personalmente he usado es la habilidad y la calidad de la estimación. La mayoría de los desarrolladores pueden estimar con precisión las tareas que duran una semana o menos. Entonces, un enfoque es dividir el proyecto en tareas de un desarrollador de una semana de duración y rastrear quién hizo la estimación. A medida que avanza el proyecto, pueden cambiar sus estimaciones. Después de completar una tarea, si está desactivada en más del 10% (1/2 día), tratamos esto de la misma manera que un error: identificamos por qué la estimación estaba desactivada (es decir, no se consideró una tabla de base de datos), identificamos acción correctiva (es decir, involucrar al DBA en la estimación) y luego continuar. Con esta información, podemos crear métricas como el número de errores de estimación por semana, el número de errores por desarrollador,
¿Y qué? Ahí es cuando entran las metodologías: si tiene un modelo predictivo que no cumple con las cualidades del proceso, puede optar por agregar o eliminar algún aspecto de la metodología y ver cómo afecta a su modelo. Por supuesto, nadie quiere jugar con un proceso de desarrollo por miedo al fracaso, pero ya estamos fallando a un ritmo consistentemente alto y predecible. Al hacer cambios individuales y medir el resultado, puede encontrar que Agile es la metodología perfecta para su equipo, pero podría encontrar fácilmente RUP, cascada o simplemente una combinación de mejores prácticas para ser ideal.
Entonces, mi sugerencia es que dejemos de preocuparnos por lo que llamamos el proceso, establezcamos controles que sean relevantes para nuestros objetivos del proceso de desarrollo y experimentemos con diferentes técnicas para mejorar ese proceso.
