La respuesta formal es que usted entendió mal ágil, ágil no dicta requisitos, las partes interesadas lo hacen. El núcleo de Agile no es tallar sus requisitos en piedra, sino que surjan a medida que avanza, en estrecho contacto con su cliente, beneficiándose de conocimientos progresivos.
Pero eso es todo teoría. Lo que ha presenciado es un rasgo común de muchas líneas de producción de software que adoptaron una forma ágil de trabajar.
El problema es que escuchar al cliente y responder rápidamente a las necesidades del cliente a menudo pronto termina en no pensar en el producto ni en hacer ningún diseño. Lo que solía ser un proceso proactivo alimentado por la visión y la experiencia puede, y a menudo se deteriorará, en un proceso pasivo y completamente reactivo alimentado por los deseos del cliente. Esto conducirá a hacer las necesidades básicas que "harán el trabajo".
El automóvil nunca se habría inventado si los fabricantes en ese momento hubieran sido "ágiles" porque todo lo que los clientes pedían era un caballo más rápido.
Sin embargo, esto no hace que Agile sea malo. Es un poco como el comunismo. Una gran idea que casi nunca funciona bien porque las personas son personas que hacen cosas de personas. Y el método / ideología / religión los lleva a la idea de que les está yendo bien siempre y cuando sigan los movimientos y / o sigan las reglas.
[editar]
Slebetman:
Es irónico entonces que ágil evolucionó fuera de la industria automotriz (a saber, Toyota).
¿Recuerdas la regla de oro de la automatización? "Primero organizar, luego automatizar". Si automatiza un proceso interrumpido, lo mejor que podría suceder es que acelere todo lo que sale mal. La gente de Toyota no era idiota.
La razón típica para adoptar una nueva metodología es que las cosas no van bien. La gerencia lo reconoce, pero es posible que no entiendan los problemas centrales. Entonces contratan a este gurú que da un discurso elocuente sobre Agile y Scrum. Y a todos les encanta. Por sus propios motivos.
Los desarrolladores pueden pensar "Oye, esto podría funcionar. Estaríamos más involucrados con los problemas del negocio y podríamos proporcionar información para llenar este retraso. Esto podría ser una oportunidad para que las ventas y el servicio al cliente entiendan lo que hacemos, por qué es necesario, y nos los quitaríamos del pelo mientras quemábamos de manera transparente lo que acordamos ". No más "deja de hacer lo que estás haciendo, esto debe hacerlo ahora" por un tipo que no quieres posponer apareciendo en tu escritorio.
Las ventas, el servicio al cliente o el propietario, por otro lado, pueden verlo como una forma de obtener el control (posterior) sobre esta caja negra de un departamento que presumiblemente está haciendo las cosas que son necesarias. No ven lo que está sucediendo allí, pero están bastante seguros de que el núcleo del problema está enterrado en algún lugar allí. Entonces, presentan Scrum, instalan el propietario de un producto de su elección y, de repente, tienen todo el control, todas las cadenas están en sus manos. ¿Y ahora qué? ... Ehrr ...
El problema real es a menudo que la tienda no estaba bien organizada en primer lugar y esto no ha cambiado. A las personas se les han asignado responsabilidades que no pueden manejar, o tal vez sí, pero el Sr. Boss está constantemente interfiriendo y arruinando lo que hicieron, o (lo más frecuente en mi experiencia), no se han reconocido o asignado responsabilidades cruciales a nadie.
A veces, con el tiempo, surgirá una organización informal entre las líneas formales. Esto puede compensar en parte la falta de una estructura formal. Algunas personas terminan haciendo lo que son buenos, ya sea que tengan una tarjeta de presentación para demostrarlo o no. La introducción contundente de Agile / Scrum puede arruinar eso instantáneamente. Porque ahora se espera que la gente juegue según las reglas. Sienten que lo que solían hacer no es apreciado, obtienen pequeños papeles amarillos con pequeñas historias en su lugar, el mensaje será: "lo que sea que estuvieras haciendo, a nadie le importó". No hace falta decir que esto no será particularmente motivador para esas personas. En el mejor de los casos, comenzarán a esperar órdenes y ya no tomarán ninguna iniciativa.
Entonces las cosas empeoran y la conclusión será que Agile apesta.
Agile no apesta, es ideal para proyectos de mantenimiento e incluso puede ser bueno para nuevos desarrollos si se aplica con cuidado, pero si las personas equivocadas no lo entienden o lo adoptan por los motivos equivocados, puede ser más destructivo.