Creo que es cierto, en algunos entornos, Agile se usa como excusa para no disciplinar. El problema real 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 la arquitectura del sistema debe abordar los atributos de calidad no funcionales, la metodología debe abordar algunos de esos 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 con respecto a otra, 2) se debe tomar una decisión activa sobre qué atributos son importantes (entrega tiempo vs código de calidad vs transferencia de conocimiento).
Sin tener ambas métricas y un objetivo tangible, simplemente elegimos una metodología como nuestra "pluma mágica" que, si nos mantenemos firmes, podremos ofrecer software.
Ahora los negativistas 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 puede ser saboteada por un individuo que carece de 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 preciso y significativo (que es la parte difícil) se define, se analiza y se proporciona retroalimentación oportuna, creo que descubriremos que la metodología particular tiene poco que ver con el éxito. (Hablando anecdóticamente, he visto proyectos exitosos utilizando una gran cantidad de metodologías y el doble de fallas al usar las mismas metodologías)
Entonces, ¿cuáles son las métricas? Varían de un proyecto a otro, de un equipo a otro y de vez en cuando. Útil para cuando el calendario de entrega es importante, uno que personalmente he usado es la habilidad y la calidad de estimación. La mayoría de los desarrolladores pueden estimar con precisión las tareas que duran una semana o menos. Por lo tanto, un enfoque es dividir el proyecto en tareas que dura una semana de desarrollo y hacer un seguimiento de quién realizó 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 por día) tratamos esto como un error: identificamos por qué la estimación estaba desactivada (es decir, no se consideró una tabla de base de datos), identificamos la acción correctiva (es decir, involucrar al DBA en la estimación) y luego continuar. Usando 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, el número de errores por KLOC, el número de errores por desarrollador KLOC, etc. Publicar estos números en la wiki del equipo proporciona una gran presión social y Desde la perspectiva gerencial, después de un par de semanas, puede generar un modelo predictivo de semanas de desarrollo subsiguientes.
¿Y qué? Ahí es cuando aparecen las metodologías: si tiene un modelo predictivo que no cumple con las cualidades del proceso, puede optar por agregar o eliminar algunos aspectos de la metodología y ver cómo afecta a su modelo. Por supuesto, nadie quiere jugar con un proceso de desarrollo por temor a fallar, pero ya estamos fallando a un ritmo constante y predecible. Al realizar cambios individuales y medir el resultado, es posible que Agile sea la metodología perfecta para su equipo, pero que podría encontrar el RUP, la cascada o simplemente una combinación de las mejores prácticas para ser ideal.
Entonces, mi sugerencia es que dejemos de preocuparnos por lo que llamamos el proceso, implementamos verificaciones que son relevantes para nuestros objetivos de desarrollo y experimentamos con diferentes técnicas para mejorar ese proceso.
