Comments for Ponga a los mejores en los proyectos pequeños at http://www.navegapolis.net , comment 1 to 9 out of 9 comments http://www.navegapolis.net Thu, 21 Aug 2008 14:56:43 +0100 FeedCreator 1.7.2 http://www.navegapolis.net/content/view/671/49/#comment-962 Hola Juan, Creo que el post de Jim Highdsmith también nos da una señal de alerta sobre el armado y gestión de equipos de desarrollo. Muy bueno tu post. [url]http://blog.cutter.com/2007/09/13/no-more-self-organizing-teams/ [/url] Saludos, Adrian - Adrian Lasso Mon, 17 Sep 2007 12:05:34 +0100 http://www.navegapolis.net/content/view/671/49/#comment-943 Hasta la fecha no he visto un gran proyecto que acabe con un retraso y un sobrecoste medianamente aceptables. En casi todos, las desviación es escandalosa cuando no son directamente cancelados. Sin embargo, si conozco muchos pequeños proyectos acabados en tiempo y coste, que funcionan. El problema está en que la informática actual es incapaz de desarrollar grandes proyectos. Simplemente no sabemos hacerlo. Es como si a un arquitecto del 1.000 ac. le encargaran hacer un rascacielos de 50 plantas. Tenemos que seguir probando metodologías y herramientas, y continuar desarrollando habilidades para algún día poder afrontar el desarrollo de un gran proyecto con las mismas garantías que los arquitectos, desde el bueno hasta el menos bueno, hacen edificios. ¡Los edificios hechos por los arquitectos no buenos no se caen! La informática lleva poco más de 50 años y ya pretendemos construir catedrales cuando lo que hemos hecho hasta la fecha bien son chavolas de barro. La única sólución factible hasta el momento, desde mi punto de vista, es dividir y atacar proyectos pequeños, que si sabemos ejecutar de forma exitosa. Con el tiempo podemos atacar proyectos pequeños pero de mayor tamaño. Y así, hasta que algún día alguien sea capaz de ejecutar con exito un gran proyecto. Saludos. - Daniel Thu, 06 Sep 2007 11:06:25 +0100 http://www.navegapolis.net/content/view/671/49/#comment-937 Cuando te enfrentas a un proyecto grande (hablamos de número de personas involucradas, entidades -físicas y /o lógicas- y de tiempo de desarrollo), en mi humilde opinión es dividirlo en una cantidad de "mini-proyectos" tal que puedan afrontarse con un número de personas suficientemente pequeño para que deje de ser "grande". Pongamos por ejemplo, dado el axioma 20/100, dividirlo en grupos de 5 personas (donde al menos 1 será un "crack"), y establecer para el objetivos a corto plazo, documentación mínima, etc, etc... Mantendrás su entusiasmo, el "flojo" tendrá oportunidad de aprender del "bueno" (trabajarán codo con codo), y verán sus metas cercanas en tiempo y esfuerzo. En realidad es lo que llevamos haciendo desde hace años con nuestras propias líneas de código... dividir y dividir en métodos cada vez más pequeños para reutilizarlos, depurarlos más facilmente, intentar incluso hacer primero los test... Con la gente es igual. Los proyectos son iguales que un programa... Divide a un gran grupo de gente en grupos pequeños, de forma que "hacer grupo" es mucho más facil, marcando objetivos diferentes, etc.... Obviamente, esto SOLO es posible si cuentas con un "product manager" o gestor de proyecto en condiciones, además de tener que dedicar a al menos un grupo de los creados a integrar módulos unos con otros.... En cualquier caso, NADIE es bueno en algo SIEMPRE (y nadie "nació" siendo buen programador), aunque algunos tengan ese "algo" especial que les diferencia del resto... - joseluisGV Wed, 05 Sep 2007 08:24:58 +0100 http://www.navegapolis.net/content/view/671/49/#comment-935 Perdón, muy buena analogía [b]JUAN[/b]. - martin Tue, 04 Sep 2007 21:52:39 +0100 http://www.navegapolis.net/content/view/671/49/#comment-934 Muy buena analogía Joserra, me quedo con ella. - martin Tue, 04 Sep 2007 21:51:20 +0100 http://www.navegapolis.net/content/view/671/49/#comment-933 Brooks: "The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming". (the mythical man-month, p. 30). Saludos! - J. Babuglia Tue, 04 Sep 2007 19:11:22 +0100 http://www.navegapolis.net/content/view/671/49/#comment-932 Si, es que yo no me atrevo a sacar una conclusión; o al menos no una simple. Como decís se juntan muchas cosas: cuando el proyecto crece aparecen problemas serios que no son de índole técnica. La organización empieza a hacerse más pesada y "quema" a los buenos programadores... Como son varias las razones, y además se potencian al combinarse, resumir una conclusión es complicado, pero al ser habitual que en los equipos grandes la productividad personal sea menor, me ha llamado la atención el consejo de Jack Ganssle. No se si la imagen de comparación siguiente, con la que me represento de alguna manera la situación, está muy bien traída, pero en mi forma de verlo podría valer: Cuando el tráfico es denso, y la calle está muy normalizada con medidas de regulación y seguridad (semáforos, pasos de cebra...) la diferencia de velocidad entre una bicicleta, un ciclomotor y un deportivo no es significativa. Si hay menos tráfico y pocas normas, la diferencia entre la bicicleta y el deportivo sí que es importante. En este último caso interesa que los conductores sean buenos, porque la seguridad depende de su buen hacer más que de las medidas de regulación y seguridad, que son escasas. - Juan Tue, 04 Sep 2007 17:11:38 +0100 http://www.navegapolis.net/content/view/671/49/#comment-931 Estoy de acuerdo contigo, Joserra. Realmente yo no creo que esa política ayude mucho a la empresa a largo plazo, ya que en caso de pasar algo así sería bastante claro que la enfermedad ya está dentro, y que existe un problema importante en el proceso de trabajo dentro de la empresa (i.e. necesita ser más ágil). Olvidando esto, lo cierto es que a corto plazo la medida no es mala. Por mi experiencia, cuando un super-programador empieza a verse inmerso en un mar de documentación, reuniones, especificaciones, negociaciones, viajes a clientes, etc. etc., inmediatamente el proyecto dejará de ser atractivo para él, y el problema ya no es que pase a ser igual de improductivo que los malos programadores, sino que probablemente se irá de la empresa. - martin Tue, 04 Sep 2007 13:46:01 +0100 http://www.navegapolis.net/content/view/671/49/#comment-930 Entonces el corolario de esto es ... ¿que da igual quien desarrollo un proyecto grande? :) Por que si "[i]a medida que el proyecto crece el mejor y el peor son igual de improductivos[/i]" será por que el mejor tiende a ser como el peor, no al reves. De manera que poniendo a los "peores" en los grandes será lo mismo. Jeje, no creo que sea tan radical, pero lo que está claro es que contra más personas existen en un proyecto, los problemas dejan de venir del lado tecnológico, sino de la complejidad funcional del mismo o del mismo problema de "crear equipo" y su comunicación. Mi recomendación si llevas proyectos grandes: lee Peopleware!! ;) - Joserra Tue, 04 Sep 2007 09:38:23 +0100