Lo normal es que cada uno trabajae en un módulo específico esto es, si el proyecto tiene pongamos 20 clases en una clase sólo trabajaría 1 persona a la vez.
Si una clase es tan grande o tan compleja que necesitare que varias personas trabajaran en ella a la vez, su pueden usar clases parciales
' si la clase se llama
public class Miclase
end class
' la clase parcial se llamará...
public partial class MiClase
end class
Ahora trabajar en la misma clase supone compartimentar que métodos debe implementar uno y cual otro, y en todo caso sólo podrá llevarse a cabo cuando las estructuras comunes en toda la clase estén listas, es decir si en el 'reparto' de métodos a cada persona van a compartir variables, estructuras, subclases es preciso que estas se creen previamente para que no se creen copias similares pero distintas por parte de cada programador.
Para controlar el proyecto existe 'Source Safe' no es la panacea pero es mejor que nada la complejidad dependerá del nivel de profundidad en que sea preciso que trabajen varias personas a la vez, para no tener problemas asignar una clase a una sola persona ofrece una complejidad muy manejable, repartir métodos de una clase es un nivel más profundo y más complejo y así a medida que se asignen partes menos específicamente diferenciadas será más complejo de mantener.
En todo caso debe haber un plan de trabajo previo para que todas las partes 'coincidan', supongamos que uno tiene que implementer compresión y elige un método que a él le parece el mejor y pongamos que otro tiene que 'consumir' esa clase que aún no ha sido escrita, pero ha sido definido , existe la posibilidad de que necesite un parámetro previamente no establecido, un plan ayuda a prevenir esto, sin embargo un plan debe entenderse como una dirección no como el camino paso a paso a seguir. La experiencia demuestra que un plan inalterable es un fracaso total porque a medida que se avanza surgen cambios e incluso sin que surjan nuevos cambios el `propio código puede designar variar ligeramente de dirección por la salud futura del proyecto. Se entiende mejor con un ejemplo: Imagina que alguien toma un mapa y traza una línea que es el camino a seguir desde el punto-A hasta el punto-Z, en el plano es fácil trazar líneas y posiblemente la trazada sea la que 'parece' más correcta y más corta, pero a medida que se avanza en el camino podría suceder simplemente que un puente caído días atrás impida atravesar un río y quizás el rodeo sea más grande que si se hubiera elegido previamente un camino ligeramente más largo pero con más alternativas próximas. Si no se está dispuesto a usar un plan sugeto a cambios el trabajo será un completo calvario, la cabezonería de cruzar el río por seguir el plan establecido hará naufragar a muchos y no debe echarse la culpa a dichas personas, que con el puente hubieran marchado sin problemas, el fallo será de quien signa que un plan es inalterable.
El plan de trabajo debe verse como una ayuda, como una guía y en vez de trazar una línea hubiera sido mejor trazar puntos sobre el camino, con la libertad de que cualquiera puede usar el trazado que estime más oportuno entre 2 puntos, siendo asímismo los puntos como metas de reunión bién estudiados y conocidos libres de fallo. Un grado así de libertad permite que el camino sea cubierto los imprevistos solucionados y el avance progresivo, evita el stress de los programadores porque no existe presión para hacer algo de manera que se sabe antes de empezar que sólo ofrece complicación esfuerzo y que será en vano y el proyecto avanza.
Es muy duro cuando alguien se emperra en que una cosa se haga de una manera que no es acorde a lo que se dispone, un pez nadará, un pájaro volará un topo irá debajo tierra y aunque a cada uno le resulte extremadamente fácil hacer lo que hace ocurre todo lo contrario cuando al pez se le pide que excave, al topo que vuele y al pájaro que nade. Esto en un proyecto es casi el peor enemigo, aún todos capaces se vuelven ineficaces no porque lo sean sino porque se les ha encomendado misiones que de entrada son un fracaso.
