Centrarse en la metodología o en las personas
Desde javaHispano , he llegado por uno de sus comentarios a un artículo de Alistair Cockburn que merece la pena realmente leer. Es posible que sea un artículo muy conocido, pero hasta ahora no había llegado a mis manos. Destaca la importancia de las personas como componente de primer orden para el éxito de los proyectos (de ingeniería) informáticos.
La metodología XP tiene una de sus bazas fuertes en aumentar la importancia de los programadores sobre la metodología, y es uno de sus puntos fuertes. Obviamente, ya hablamos de que XP no vale para todo tipo de proyectos. Pero para mi la conclusión que me ha confirmado este artículo es que es más importante el equipo de personas con el que trabajes, que la metodología utilizada.
Por otro lado, el artículo de javaHispano de crítica al XP tiene algunos puntos buenos, pero en general, da la impresión de que el autor "odia" las metodologías ágiles, y que eso le ha llevado a escribir muchas cuestiones sin sustentarlas en razonamientos lógicos o recapacitados.
Mi Twitter
De acuerdo con que las personas son el principal activo y variable a tener en cuenta en el momento de desarrollar un proyecto y en que las metodologías hasta ahora lo han olvidado.
ResponderEliminarNo obstante las metodologías han evolucionado y poco a poco se toma mucho mas en cuenta este aspecto, aunque, como es sabido, el objetivo de la metodología no es modelar a las personas sino guiarlas. De hecho, es necesario adaptar las metodologías al ambiente en que se está trabajando.
Ciertamente existen metodologías peores o mejores dentro del ámbito y tiempo en que se usan. Así una metodología que podría ser óptima en los años 60, ahora podría estar obsoleta. Lo mismo sucede cuando se intenta una metodología en un proyecto en el que se tratan enfoques funcionales o enfoques conceptuales.
Respecto a las bondades de XP, no creo que XP tome en cuenta la variable humana tal como plantea el artículo de Cockburn. Lo que si intenta es que haya un contanto interpersonal más fuerte y más dinámico. Esto lo demuestra la ausencia de roles como tales.
En ese sentido las metodologías sólo pueden definir roles, funciones del personal o perfiles, pero es labor del Project Manager dirigir, adaptar y aplicar la metodología teniendo muy en cuenta a las personas que trabajan en el equipo.
Yo personalmente prefiero las metodologías Unificadas ya que aceptan el hecho de que las personas NO somos perfectas y necesitamos una estructuración, un orden y unos apoyos documentales para realizar un mejor trabajo.
Un saludo
prefiero las metodologías Unificadas ya que aceptan el hecho de que las personas NO somos perfectas y necesitamos una estructuración, un orden y unos apoyos documentales para realizar un mejor trabajo.
ResponderEliminar¿lo aceptan? O suponen que siempre vas a acordarte de todos los pasos, de escribir toda la documentación, de mantenerla actualizada, de que no se te va a olvidar ningún aspecto o fase,... no sé...
Cada equipo debe construirse y proveerse de las herramientas de cada metodología que mejor le hagan funcionar.
Personas, siempre personas. Las metodologías se tienen que adaptar a las personas, no al revés.
ResponderEliminarUna vez escribí algo así como:
lo que importa no es la (buena) tecnología, sino las personas y su forma de usarla.
Hola.
ResponderEliminarHe leído varios libros acerca de XP (http://www.pearsoneducacion.com/uni/ficha_libro.asp?id_libro=2391&id_categoria=662), de gestión de equipos de desarrollo de sofware (http://richardwhitehead.com) y estoy leyendo el interesantísimo Peopleware (http://www.dorsethouse.com/books/pw.html), uno de los mejores libros que conozco sobre esta actividad de desarrollo de software. Otro es el ya inencontrable 84-7614-151-3 Programadores en acción : entrevistas (1987) de Susan Lammers (Anaya Multimedia).
Creo que el factor humano es la clave y que como dicen el Peopleware hay que distinguir entre Metodología y metodología. En la primera la Metodología toma las decisiones, las personas ninguna: ¿se entiende la diferencia?.
También comenta que la documentación voluminosa es parte del problema, no parte de la solución.
En definitiva, y lo he comprobado en mi experiencia, hay equipos que desde fuera no dan la imagen que en realidad cumplen: gente ilusionada con su trabajo pero no adicta al mismo, con las ideas claras pero flexible a los vaivenes del cliente, técnica pero viendo la tecnología como una herramienta no como un fin en sí mismo, que trabaja sus 8 horas (buena regla de XP, que no hay que olvidar) porque un proyecto que va bien no necesita heroicidades, etc.
Con este tipo de gente, respetando la forma de ser de cada uno (la uniformidad o el deseo de imponerla indica inseguridad), escuchando sus aspiraciones (el que centra su vida en el trabajo, el joven que puede/quiere estar hasta tarde, el otro que acaba de ser padre y ya tiene otras prioridades, el que le gusta programar bien para ganar dinero e irse de farra, el que se ha cansado de tirar líneas y desea gestionar proyectos) se puede hacer lo que sea.
Yo lo he visto (lo veo).
Esas personas crearán su propia metodología: ¿qué más da que tengla siglas o no?
Hola Escéptico:
ResponderEliminarTu "comment" me ha emocionado... :_)
Muy interesante tus conclusiones basadas en tu experiencia, me las daré por aprendidas ;).
Un recordatorio: No olvides que puedes poner tags, para que los enlaces tengan link!!
Salu2
Hola,
ResponderEliminarDe acuerdo otra vez con los comentarios.
Es obvio que los que ejecutan los trabajos, siguen una metodología o llevan a cabo un proyecto son las personas. Pero la necesidad de las metodologías, insisto, está en guiar a las personas en el proceso para que este no sea un caos, para que el trabajo sea óptimo, etc. En ese sentido una metodología me parece esencial, imprescindible, lo mismo que un líder o project manager.
No estoy a favor de seguir una metodología a ciegas, hay que ser crítico ciertamente y adaptarla al entorno (personas, proyecto, ambiente, etc.), pero cuando uno adopta una metodología es porque la ve útil para desarrollar un proyecto.
De acuerdo también en que no es necesario hacer de un equipo una cosa uniforme, la diversidad es lo que enriquece un proyecto (y un entorno), pero es necesario como mínimo que todos hablemos el mismo idioma para poder comunicarnos mejor y que se sigan ciertas pautas para lograr un fin óptimo y común. Esto no tiene porque quitar que cada uno trabaje como mejor sabe y le gusta, pero de lo que se trata es de optimizar los procesos (lamentablemente eso es lo que nos pide el mercado). Hacer subyacer un proyecto en la buena voluntad de la gente no siempre es posible, aun cuando eso sería maravilloso.
No creo que una sola metodología sea la piedra filosofal. Como todos sabemos, la metodología se debe escoger según el entorno del proyecto (tamaño y tipo del proyecto, personas, etc. ) ya que cada caso es diferente. A veces es necesario hacer una combinación de métodos. Es necesario tener muy en cuenta las interrelaciones entre las personas, eso es vital.
Por ejemplo en un entorno en que la gente no se lleve bien unas con otras (con 2 es suficiente), no haya comunicación, no estén a gusto con los sueldos, etc.(entorno muy desfavorable) y sea necesario realizar un proyecto (porque para eso trabajamos), probablemente sea más patente la necesidad de una metodología y protocolos más rígidos.
En el caso contrario, en el que el entorno sea favorable, la rigidez sería contraproducente.
No obstante, no es labor de la metodología salir del dominio del proyecto ya que eso la haría poco genérica e inservible para lo que fue diseñada (guiar proyectos). Los detalles de los caracteres de las personas son labor del líder del proyecto ya que son elementos propios de cada caso(aunque es cierto que existen muchos que hacen caso omiso de esa importante variable) y es deber suyo adaptar la metodología escogida a esos detalles.
Finalmente, decir que las metodologías modernas abogan por la comunicación, por la fluidez de la información como factor clave, tanto oral como escritas (en diferente medida según el caso y la necesidad), tanto a nivel de colegas como a nivel de clientes como a nivel de subordinado-jefe, en entornos desfavorables (donde se tendrá que forzar) o favorables.
Después de todo la falta de comunicación es uno de las principales razones por la que el mundo va como va.
Un saludo.
*PD: Un inciso, sobre la documentación voluminosa: Hay que redactar documentos necesarios y del tamaño necesario (ni más ni menos), para que el proyecto este bien definido y sea entendible [y no solo por los técnicos]. Esto creo que también es válido para el grado de comunicación oral. En este sentido las metodologías proponen un guía sobre qué documentos realizar, pero no es cierto que se deban redactar todos los que se proponen, esto depende otra vez del proyecto en sí y del entorno.