Cita:
Empezado por AzidRain
Pero bueno, yo solo opino. No se si alguien tenga alguna experiencia por ahí sobre este tipo de metodologías en proyectos similares.
|
No estas desencaminado. De hecho cada cierto tiempo surgen debates de esos como
https://news.ycombinator.com/item?id=10543180 y
https://news.ycombinator.com/item?id=10543180. (Habia una discusion mas reciente y mucho mejor expresada, pero no la encuentro, asi que voy a ver que me acuerdo!)
------
A mi me ha tocado de todo un poco. Desde el metodo clasico del
desarollo en cascada, programacion extrema, SCRUM y el mas popular de todos en el mundo de la programacion:
Vamos pa delante sin frenos y sin mirar pa' donde!
Ahora lo que aplico es:
1- Tener un control de codigo fuente (mercurial)
2- Tener un sistema donde anotar BUGS, requerimientos, etc (uso pivotaltracker)
3- SCRUM
4- +17 años de experiencia
------
Sirven mas este o aquel para equipos pequeños, grandes, desarrollos complejos, simples, etc? En teminos generales,
se puede hacer funcionar en todos los casos.
El problema, es que EL FRACASO ESTA GARANTIZADO y el exito es escaso (Me explico por fracaso: Que el proyecto no se termine, se salga de forma exagerada de presupuesto/tiempo o termine muy lejos de lo que debio ser, la gente se agarre de los pelos, un evento inesperado altero todo, se quemo el disco con todo el codigo fuente, la empresa se quebro, etc)
Asi que
aun con un buen metodo, es probable que el proyecto fracase.
----
Microsoft hizo un estudio muy amplio de varias cosas (
publicado aca) y el resultado es que muchas cosas que se consideran "buenas practicas" por
si solas no predicen con
certeza si el proyecto saldra bien o no. EN CAMBIO, el predictor mas certero de todos? Que la organizacion sea
disfuncional (Ej: Jefes/Clientes/Programadores problematicos, Burocracias, tener que coordinar el trabajo entre mucha gente, etc).
Esto se puede entender asi:
Que el equipo de futbol de Brasil gane muchas veces, no es tanto debido a que usen esta o aquella formacion, sino a que tiene buenos jugadores/tecnicos, que se les da lo necesario.
Obvio, un buen equipo vera que esta o aquella formacion les es mas conveniente. Pero la formacion sin el equipo, es inutil.
----
Pienso que esto se puede entender asi:
1- Cualquier sistema estructurado/metodologia sera una gran mejora sobre "Programemos a lo loco!". Es por eso que muchos al principio obtienen muchas ventajas.
Sin embargo, la burocracia mata cualquier ventaja que este traiga...
2- Es cierto como dice
Delphius que el factor dominante es la calidad del equipo de trabajo. Por lo tanto, mejor que imponerles un estilo, darle el abanico de opciones y que implementen lo que les parezca.
De la misma manera, uno se puede adaptar a cualquier cosa. Desafortunadamente la personas que no entienden que el factor determinante es la gente y no los metodos, terminan haciendo que lo que sea se convierta en un lio: Documentar, hacer pruebas, usar control de versiones, usa scrum, hacer testeo, etc Todo eso es bueno, pero muchas veces la forma de implementarlo le quita la gracia...
----
Cita:
Empezado por AzidRain
Bajo este planteamiento, considero que las metodologías ágiles, en mi caso particlar, scrum, se enfocan más a ver pequeños pedazos de un todo aplicando el famoso "divide y venceras" y deja de lado la importancia de las interrelaciones.
|
SCRUM/XP y similares tienen claro el asunto de las interrelaciones. Ahora, es
muy comun que eso lo pasen por la galleta los equipos y/o los mismo clientes (de ahi a que parezca a veces que esas consideraciones no existen!_. El punto de falla principal
es la comunicación de la gente, no sus metodologias
Hay un factor mas diciente, que recuerdo fue un articulo basado en la estructura de comando de los ejercitos (que fue bien aplicada para este caso, pero no logro encontrar la fuente)
Hay una diferencia clara entre la estrategia y la tactica, lo global y lo especifico.
Hay una diferencia entre seguir ordenes, el rumbo fijado sin desviarse y adaptarse a las circunstancias.
Los metodos agiles, en su aplicacion comun, son TACTICOS y para equipos ADAPTABLES. Pero sin la ESTRATEGIA y un norte claro, se pierde el enfoque.
La ESTRATEGIA es dejar claro que es el proyecto, sus limites y alcances. Es tener el panorama globla claro. En este punto, es mejor SEGUIR EL CAMINO que estar cambiando de parecer.
Pero sin la tactica o la flexibilidad, no se puede avanzar.
Por lo tanto, alguien dijo que el mejor metodo es mezclar ambas cosas:
1- Tener un conjunto fijo y relativamente inflexible que delimita la ESTRATEGIA del proyecto, el cual abarca la duracion de todo este
2- Operar TACTICAMENTE en el dia a dia, poniendo tareas pequeñas y alcanzables.
Si la estrategia del proyecto/requerimientos deja ser viable, no solo hay que replantearse la misma, sino que eso tambien va a afectar el dia a dia. Lo uno no es sin lo otro.
De ahi a que funciona muy bien el mezclar el desarrollo en cascada (Sacar primero requerimientos tan completos como sea posible, con todo lo que implica) pero dejar los *detalles* a un metodo agil.
-----
Por ultimo, es mi parecer que la forma mas segura de que un proyecto sea lo mas certeramente posible exitoso es:
Dejar que las personas competentes hagan su trabajo, y darles los recursos y apoyo necesario.