El desarrollo ágil de software me recuerda a una línea de producción moderna que destruye almas. ¿Me equivoco?

No creo que nadie pueda decirte que te equivocas. Si Agile te recuerda en una línea de producción, entonces lo hace. Nadie puede decirte lo contrario. Lo que puedo decirte es que los dos ni siquiera son comparables.

Es cierto que en 1970, el Dr. Winston Royce dijo que el software debería escribirse de manera similar a una línea de ensamblaje, donde cada pieza se basa en las piezas que le precedieron [1]. Pero ahí es donde termina la comparación.

Trabajar en la línea de montaje es hacer exactamente lo mismo una y otra vez todos los días. Esto significa que estarías entrenado para hacer una cosa. Lo haces muy bien, pero sigues haciendo una cosa una y otra vez.

A menos que esté desarrollando la misma pieza de software una y otra y otra vez, no se parece en nada a lo mismo que un trabajador de línea de ensamblaje.

Desde mi punto de vista, el valor de Agile es que todo el equipo es responsable de su trabajo, y el cliente se mantiene continuamente informado sobre el progreso de la aplicación. Al informar su progreso cada día, ayuda al líder del equipo y al gerente del proyecto (y a cualquier otra parte interesada) a saber cuánto hizo el día anterior en comparación con lo que dijo que haría. Si te estás quedando atrás, esto debería ser visible a diario y deberías poder explicar por qué sucedió. Si algo lo detiene en su progreso, puede solucionarlo de inmediato. Si las cosas necesitan cambiar, puedes cambiarlas antes de que estés demasiado lejos en la madriguera del conejo.

Al mantener al cliente al tanto, pueden realizar cambios antes en el proceso en lugar de después de entregar el software. A medida que hacen cambios, y cuando usted determina que tiene que hacer cambios, todos, incluido el cliente, son conscientes de cómo los cambios afectan la línea de tiempo y el presupuesto. Si el cliente quiere que se cambie o agregue algo, comuníquese con el equipo de desarrollo e infórmeles de inmediato cómo afectará la línea de tiempo y pueden decidir la prioridad del cambio.

Entonces, supongo que diría que hay una pequeña comparación con una línea de ensamblaje (como lo señaló el Dr. Royce, pero no hay comparación con un trabajador de línea de ensamblaje y un desarrollador que trabaje bajo la Metodología Ágil.

[1] http://agilemethodology.org/

Hay cierto nivel de verdad en comparar un proceso tradicional basado en un plan con un proceso de producción definido y pensar en un proceso ágil como la antítesis de eso, pero no trataría de ir más allá de eso y hacer más un juicio de valor al respecto

Su declaración puede tener cierto nivel de verdad subyacente, pero también parece basarse en muchos de los estereotipos, mitos y conceptos erróneos que existen sobre Agile versus Waterfall. Hay muchos estereotipos, mitos y conceptos erróneos sobre “Agile versus Waterfall”: uno de los mitos más importantes es que existe una opción binaria y mutuamente excluyente entre los dos enfoques. Otra es que Agile es una bala de plata para cualquier tipo de problema que pueda tener y reemplaza a Waterfall, que ya no es relevante en absoluto.

Prefiero una visión más objetiva y pragmática de que “decir que Agile es mejor que Waterfall” es como decir “Un auto es mejor que un bote”. Ambos tienen ventajas y desventajas dependiendo del entorno en el que se encuentre. Desarrollé un curso de capacitación en línea gratuito llamado “Aprenda la verdad sobre lo ágil versus la cascada” que está diseñado para ayudar a las personas a desarrollar una nueva perspectiva para ver estos dos enfoques como complementarios entre sí en lugar de competitivos.

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo a: http: // agileprojectmanagementaca …