Metodos de programacion en equipo
Despues de estar un poco mas de una hora sumergido en blogs, wikis y mailing lists de la gente de Ubuntu, me termino de quedar claro algo que vengo leyendo hace rato: los 2 metodos de programacion mas usados en open source.
Sprint, originario de la comunidad Python, y usado en esta semana en londres por Ubuntu.
Consiste basicamente en juntar un grupo chico/mediano de programadores, los sentas en una mesa con mucha coca-cola y oreos, y varios objetivos bien claros a alcanzar.
De ahi el nombre “sprint” que es “correr rapido en poco tiempo”.
Pair Programming, muchas veces usado en conjunto con Sprint.
Lo que se hace, aunque suene un poco extraño al principio, es juntar a 2 programadores y una sola PC para enfrentar al mismo problema.
Hay estudios al respecto que indican que la persona liberada de tener que escribir el codigo aporta una perspectiva invalorable, ya que estadisticamente hablando, la productividad se duplica, contra toda logica inicial.
Hay algunas cosas mas, somo Test Driven Development, pero quedara para otro sabado medio lluvioso.




Con respecto a pair programming, es leido sobre
metodologias de programacion en grupo
y este metodo tambien se denomina
xtreme programming, con el agregado de algunas
otras caracteristicas.
[...] El martes llegó una actualización del paquete xserver-xorg a los repositorios de Dapper. Es parte de un gran esfuerzo de Canonical para lograr que Dapper realmente sea la distribución más estable y bug-free posible. Resultó que ésta actualización le rompió la interfaz gráfica a la gran mayoría de los usuarios que le dieron a “actualizar” esa mañana por un error en el código. Obviamente hubo muchos usuarios desesperados ya que la siguiente vez que reiniciaron, tiro un error y no pudieron entrar a su escritorio. Casi de inmediato se abrió un thread en ubuntuforums con la descripción del problema, y la solución. Se cargó en el foro un sticky general de un color verde muy llamativo para ahorrar a los usuarios tener que buscar la solución, y los desarrolladores que estaban en medio de un sprint en alemania, se pusieron en campaña para arreglarlo y actualizar el paquete roto en los repositorios. Desde que se subió el paquete, hasta que se actualizó con la versión arreglada, pasaron 12 horas. Eso es la cantidad de tiempo que tardaron en ser notificados, solucionarlo y propagarlo. Inmediatamente saltó mucha gente indignada blogueando en sus blogs donde nos cuentan sobre la menstruación de sus “novias” que nunca más Ubuntu, que se vuelven a windows, o se compran un clusters de PC y empíezan a compilar todo con Gentoo. Entiendo que lo que sucedió no es leve ni algo aceptable en términos masivos, pero los tiempos de respuesta fueron impresionantes y efectivos, inmediatamente se sentaron a plantear formas de evitar éstos problemas de acá en adelante y fueron en todo momento abiertos y transparentes sobre lo sucedido. Alguien cometió un error en un proyecto gigante y lo solucionó. Si no les gusta, vuelvan a Windows 95 y nos divertimos todos con WinNuke. [...]
Es bien cuestionable la utilización de pair programing, en lo que a recursos se refiere.