Una pregunta que siempre me hago a mi mismo es: ¿Se debe dedicar mucho tiempo a analizar los requerimientos de una aplicación? o ¿es mejor pasar mas rápido y volver siempre atrás para no perder mucho tiempo en analizar?, con esto me refiero también a los sprint planning meeting de scrum.
Una cosa que no me gustan y que me ponen de mala leche, son los continuos cambios y el «volver» siempre a re-re-re-re-re-hacer lo mismo, porque un analista o analista-programador, por no querer «perder» mucho tiempo dice el primer día: «Hay que hacer las cosas así A-B-C», (como dijo mi profesor de autoescuela), la primera impresión es la que cuenta. El 2º día cuando lo ve dice: «pero como está hecho esto asiiii no sirve porque es B-A-C», ya pero me dijiste que lo hiciera así pero bueno a re-hacer toca. 3º Día: «Como esta echo asiiiiiiii si es C-A-B ahora que me acuerdo » aggggggg otra vez noooooo. No hubiera sido más fácil que el analista tomara aire, pensara 10 min, reflexionara un poco todos los aspectos y dijera: «Después de analizarlo fríamente, despacio tienes que hacerlo así: D-J-K» , hubiera ahorrado mucho tiempo, dinero y quebraderos de cabeza.
Sé que los analistas no son dioses, pero deberían serlo?, con esto que ahorraríamos? muchas veces creo que tiempo, esfuerzo y sobre todo alguna reprimenda a muchos desarrolladores por no tener algo tan sencillo y rápido que se hace en 1 día (sabiendo que es lo que hay que hacer y cómo hacerlo claro).
En parte estoy de acuerdo contigo. Por cierto, una cosa, intenta cambiar el color de fondo porque no se puede leer bien a no ser que selecciones el texto.
En teoria no se que pasa pero esta puesto con letra blanca todos los post…
si tienes razon y cuando estan en una presentacion y no era lo q el cliente quiere dicen: «yo le dije otra cosa pero creo q no a entendido ó si no x q no funicona correctamnete te acuerdas lo q hablamos la vez pasada (en donde no habia ninguna ECU ni nada y despues dicen q ahi q guiarse de lo q dicen las ECU )….» jajajaj q graciosos