Recientemente he visto acerca de las metodologías para el desarrollo de sistemas/software/programas. Y lo que me ha llamado la atención es que existe un debate acerca de la metodología
Scrum vs.
En Cascada (Scrum vs. Waterfall).
Lo que se ha criticado fuertemente a la metodología En Cascada es que ahora reúne todo lo malo lo que una metodología puede tener: mucha documentación, es muy costosa, requiere mucho tiempo, desgasta a los equipos de trabajo, no hay unión entre líder/gerente-programador/desarrollador, estresa a la persona, y si eso no fuera poco, el producto resultante por lo general termina enlatado o no funciona del todo.
Por el otro lado quienes apoyan a la metodología "Scrum"... si, efectivamente según reune todo lo opuesto a lo antes mencionado.
Scrum es una metodología dentro del desarrollo de software "Agil" (Agile).
Aun a pesar de lo anterior, hay quienes dicen que la metodología "en cascada" todavía se sigue usando aunque otros dicen que ya no se usa o que solo se usa en proyectos super-mega gigantescos y/o con un presupuesto de similares magnitudes.
Si algo puedo decir de ambas metodologías, es que no creo que "En Cascada" este en desuso, pero tampoco creo que "Scrum" sea la solución de todos los males.
Cada una tiene sus ventajas y desventajas, cada una puede tener sus adaptaciones, y cada una puede ser apropiada para determinado tipo de proyecto.
"Scrum" asume o parte de que el recurso humano está comprometido con el proyecto, o que no va a "desperdiciar" los recursos de la empresa. Eso no es siempre cierto y no siempre sucede.
Por el otro lado, "en cascada", sí requiere de mayor esfuerzo en cuanto a planeación, y diseño. Creo que
uno de los graves problemas de "en cascada" es porque asume que el sistema una vez definido este no cambia.
Bien, no quiero seguir con un debate interminable, o decir que una metodología es mejor que la otra; sino simplemente dar un punto de vista, hacer mi aporte y describir la metodología que he seguido -y sin ser arrogante- realmente me ha dado excelentes resultados.
El debate que percibo, parece que dan por sentado que solo estas dos metodologías son las unicas o las principales: Scrum o En Cascada.
Pero evidentemente existen muchas más, incluso pudieran entenderse que una es una variante de otra, o que una clasifica a otras, por ejemplo: Espiral, Iteraciones, Prototipo Rápido, Modelo V, RAD, etc.
Que es lo que me ha servido o funcionado?
No es cascada, ni tampoco Scrum,
lo que me ha funcionado es una combinación de metodologías.
Cuando tengo que realizar un sistema, antes de seleccionar la metodología y seguirla, primero debo
entender el objetivo principal del sistema, y saber qué es lo que se espera del sistema, de igual forma saber los limitantes en cuanto a tiempo y recursos tanto económicos, humanos y tecnológicos.
Efectivamente, no podría aplicarse la misma metodología para un programa en el que tienes dos desarrolladores, a uno que tienes 20, o uno que tiene 500 dólares en presupuesto, a uno de 50 mil dólares, o un sistema donde solo una persona lo va a manejar y tienes todo el tiempo que necesites para terminarlo, que un sistema donde 100 personas lo van a usar y necesita estar terminado en tres meses.
Existen muchos factores a tomar en cuenta para seleccionar la o las metodologías a usar.
Creo que en la mayoría de los proyectos, se usa una metodología hibrida, o como dije anteriormente analizar el proyecto y seleccionar la adecuada.
Por mencionar un ejemplo sencillo de uno que desarrollé, era para una empresa maquiladora (no daré el nombre por privacidad) pero esta empresa tenía un software que manejaba 'casos de clientes', cada caso era simplemente un archivo que se descargaba mediante FTP y al terminar el proceso al que se sometia, se volvía a subir por FTP. Ellos ya tenían un programa que les administraba los casos, pero me llamaron para mejorarlo (como no tenían el código fuente, tuve que volverlo a hacer).
El requerimiento de ellos fue tan simple como:
"Queremos que el nuevo programa haga lo que hace el actual, mas aparte..." y era una lista con alguna docena de requerimientos adicionales.
También fueron claros en cuanto a la interface, ellos dijeron --No queremos que se modifiquen las pantallas, estamos acostumbrados a ellas, y queremos que sean iguales-. y mencionaron el tiempo y el presupuesto al que debería sujetarse el proyecto.
Tenía que adherirme a su presupuesto y tiempo. Hice un breve análisis y planeación, emplear la metodología de Prototipos, Scrum, En Cascada, o Espiral, no fue necesaria. Y la metodología principal que apliqué fue
RAD (Rapid Application Development), ya que simplemente era re-hacer las pantallas (el programa que ellos tenían era mi prototipo), programarlas, e implementar los requerimientos adicionales. No querían entregas parciales, querían el producto en producción pero totalmente terminado.
En 45 días tenían el programa funcionando, en producción ya probado y sin bugs. No hubo iteraciones, no hubo sprints, no hubo juntas diarias, simplemente porque no era necesario, hacerlo era retrasar el proyecto.
El resultado final y real: lograron manejar de entre 600-800 casos diarios que hacian con el anterior programa, a cerca de 1000 a 1200 diarios, y el proyecto fue terminado en la mitad de tiempo y presupuesto.
El desarrollo de software no es tan simple como escoger lo último en tecnologia, con lo último de metodología para asegurar el éxito; en muchos casos, sino es que en todos, el análisis, la planeación y el factor humano son decisivos.
