Historias
Slashboxes
Comentarios
 
Búsqueda
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
En defensa de la 'cascada' | Log in/Crear cuenta | Top | 54 comentarios | Buscar hilo
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

  • Re:De qué hablamos...

    (Puntos:2)
    por Linuxtron (1489) el Martes, 28 Agosto de 2012, 12:55h (#1318740)
    ( http://ch3m4.org/ )

    Así que si siguen la metodología en cascada y fallan es porque la cascada es intrínsecamente mala y no funciona, pero si siguen metodologías ágiles y fallan es porque ellos son unos incapaces. ¿Es eso?.

    No, precisamente. Lo que quería decir es que hay muchos que dicen usar "metodologías ágiles" y no es así.

    Porque las métricas no son intrínsecas a ningún modelo de desarrollo, puedes perfectamente usar unidades hombre/hora o líneas de código/hora para calcular costes de desarrollo con metodologías ágiles.

    Puedes aplicar lo que quieras, pero las metodologías ágiles comúnmente rechazan las métricas como herramienta de control del rendimiento de las personas. Más bien, se delega la gestión del tiempo en los que van a hacer el trabajo para que se lo repartan como mejor les vengan bien.

    Y yo creo que muchos confundís el mensaje original, que curiosamente tú mismo das ("La idea detrás de esta metodología es descubrir los posibles errores en las fases tempranas, cuando son menos dañinos") con toda la burocracia que se le ha echado luego encima por motivos relacionados sólo tangencialmente con el desarrollo de software (estimación de tiempos, costes y cálculo del rendimiento del trabajo de cada persona, automatización de la documentación, estandarización de procesos, coordinación de equipos, etc).

    Precisamente toda la burocracia va encaminada a cometer menos fallos y es parte intrínseca del proceso de ingeniería. No es, ni mucho menos, algo tangencial. Que la experiencia diga que no se puede ser tan estricto en un proceso creativo como es el desarrollo del software es precisamente la idea detrás de las metodologías ágiles (y para nada una idea exclusiva de ellas).

    [ Padre ]
    Re:De qué hablamos... de Linuxtron (Puntos:2)
    Puntos de inicio:    1  punto
    Modificador por Bonus-Karma   +1  
    Total marcador:   2  

  • Re:De qué hablamos...

    (Puntos:1)
    por monster (49083) el Martes, 28 Agosto de 2012, 13:29h (#1318750)
    ( Última bitácora: Miércoles, 05 Marzo de 2014, 08:44h )

    Así que si siguen la metodología en cascada y fallan es porque la cascada es intrínsecamente mala y no funciona, pero si siguen metodologías ágiles y fallan es porque ellos son unos incapaces. ¿Es eso?.
    No, precisamente. Lo que quería decir es que hay muchos que dicen usar "metodologías ágiles" y no es así.
    Pues fíjate tú que a mí por decir lo mismo sobre la metodología en cascada me han caído palos por todos lados, incluyendo cosas como las métricas, los esquemas UML y la especificación de documentos de Métrica3, que no tienen nada que ver con la cascada más allá de que *también* se utilicen en los procesos de desarrollo de software. ¿Consigo por fin hacerme entender?.

    Puedes aplicar lo que quieras, pero las metodologías ágiles comúnmente rechazan las métricas como herramienta de control del rendimiento de las personas. Más bien, se delega la gestión del tiempo en los que van a hacer el trabajo para que se lo repartan como mejor les vengan bien.
    De acuerdo, pero la diferencia es que la metodología en cascada no dice nada sobre eso (porque en aquella época ni siquiera se habían planteado) mientras que las metodologías ágiles ya tienen la experiencia de a qué conducen esas métricas y deciden rechazarlas. ¿Implica eso que la cascada las apruebe retroactivamente?: Yo diría que no.

    Precisamente toda la burocracia va encaminada a cometer menos fallos y es parte intrínseca del proceso de ingeniería. No es, ni mucho menos, algo tangencial. Que la experiencia diga que no se puede ser tan estricto en un proceso creativo como es el desarrollo del software es precisamente la idea detrás de las metodologías ágiles (y para nada una idea exclusiva de ellas).
    Desarrollo de software != Ingeniería. Hay desarrollo de software sin ingeniería y hay ingeniería sin desarrollo de software. Que interese combinarlos no hace que sean lo mismo. Y la metodología en cascada habla sólo del desarrollo de software (aunque sólo fuera porque es anterior al intento de aplicar los métodos de ingeniería a la informática). Otra cuestión es que las metodologías ágiles *sí* engloben técnicas tanto de desarrollo de software como de ingeniería.
    [ Padre ]