La agilidad es algo bueno, sin duda, y el Manifiesto Ágil no es irrazonable. En comparación con una práctica del hombre de paja llamada "Cascada", Agile es notablemente superior. Sin embargo, gran parte de la práctica de Agile es profundamente dañina, y realmente no creo que la dicotomía Agile / Waterfall sea útil.
|
etiquetas: programación , agile , scrum , terribles 
www.youtube.com/watch?v=Q6jMgmPIxmk
Algo parecido a la eficiencia sólo se consigue cuando el técnico está protegido contra el ruido de fuera. Se puede comprobar en casi cualquier sector que funcione mínimamente bien.
Pero como cualquiera sabe de informática porque "mi sobrino ya se apaña que sabe Word y Excel", y no hay agallas de mandar a esos cuñados de vuelta a la barra del bar, pues así seguirán los debates sobre si son galgos o podencos.
No tiene sentido hacer sprints en proyectos que "o funciona o no"
Es decir, scrum con gente que sabe hacer scrum, mola, pero waterfall sigue teniendo su utilidad. Además scrum genera riesgos añadidos como la desatención parcial del cliente o un jefe de proyecto reciclado a scrum manager que se la menea con su látigo sabiendo que hay entregas mensuales.
Hay metodologías de agile, totalmente traspasables a cascada que si se sabe lo que se hace generan una delicia de desarrollo.
Si puedes planificar el proyecto en dos sprints (de 3 a 4 semanas cada uno) ya merece la pena usar scrum. Obviamente, como dices, con gente que sepa hacer scrum.
Waterfall is legitimately terrible. It’s a “work rolls downhill” model in which each tier of the organizational hierarchy picks off what it consider to be “the fun stuff”, and passes the rest down the line. Projects are defined by executives, design is done by architects, personal deadlines are set by middle managers, implementation is performed by the top-tier grunts (programmers)
#8 Tienes razón, y a la vez es cierto que en ese aspecto ganan las metodologías ágiles y las releases incrementales. Sobre todo según cómo se trabaje, evita o palia bastante las "interferencias" y cambios de opinión del cliente. Aunque según qué interferencias siempre van a tener impacto, claro.
No hay metodología de desarrollo que funcione si hay 5 mirando y 1 trabajando: La plaga de los managercillos, reuniones sin sentido, comentarios absurdos para hacerse notar, revisiones que no revisan nada, hitos sin definición clara del producto, ingenieros sin ingenio... Tal cual la película "Trabajo basura".