Foros del web, para los que viven de bits

Mi pregunta es esa.

¿Como organizarse cuando hay mas de 1 programador en un solo proyecto?
¿Como os organizais vosotros através de internet?

Un saludo.

Pues lo mas practico o al menos yo he trabajado asi es dividir el sistema o la aplicacion en modulos y que cada desarrollador haga un modulo, y para los modulos que vayan a ser globales o que todos dependan de ellos se discuten entre todos hasta llegar a la solucion mas optima.

SALUDOS

Mm, si, la verdad es que no se si habrá muchas mas opciones.

Probaré con esa forma a ver que tal.

DW permite hacer proteccion de codigo en el servidor(check in/check out)

Has escuchado el dicho "divide and conquer" divide y venceras, cuando hagas el analisis de tu aplicacion, esta se dividira naturalmente en partes mas pequeñas, asigna estas partes a distintos programadores

Hay algun "lider" del proyecto?

En general nos han venido muy bien vuestras propuestas, ahora el problema radica en el tiempo que cada uno puede dedicar al programa (Que es muy poco), en cuanto a lo de si hay lider, no tenemos...

Siempre debe haber uno, que será quien tenga la mayor responsabilidad: Diseñar y modularizar la aplicación. Por mucho que los demás trabajen si se ha diseñado mal nada sirve y el trabajo está perdido.

Estoy de acuerdo, si se está empezando un proyecto debe existir alguien con el expertise necesario para tener la capacidad de distribuir las cargas de trabajo, la realizacion de los planes de trabajo, arquitectura del sistema, estandarización, desarrollo de capas..etc para posteriormente asignar las tareas a cada uno de los programadores dependiendo de las cualidades y capacidades de cada uno, ahora bien, hay que considerar el tiempo que hay de entregar para tambien saber con quien contar, sin dejar de tomar en cuanta utilizar algun tipo de metolodía (por ejemplo RUP) acompañada de UML aunque repito, eso va a depender del tamaño de la app.

Salu2

Sep, el lider de proyecto es fundamental. Ademas de estar presente, debe ser una persona idenea para el cargo, no cualquiera tiene el suficiente caracter como para llevar a cabo proyectos. Durante el desarrollo de proyectos de tamaño medio para arriba, hay que lidiar con toda clase de problemas, mucha negociacion, y sobre todo hay que bancarse al cliente con todos sus caprichos.

Bye

El cliente hace dar coraje. A veces quiere cambios que producen un mediano o gran impacto en el desarrollo del proyecto.

El numero de desarrolladores como ya lo dijeron va a depender de la escala del proyecto, dividiendose el trabajo en sus respectivos modulos.

Existen metodos formales para estimar todas esas variables utilizadas en la Administración de Proyectos. Aunque siempre se tendrá claro que... el diagrama de Gant inicial, no siempre se cumplirá.

El cliente es mejor que pida cambios. Cada cambio será dinero extra a la empresa. Una empresa con clientes serios no cambian el diseño a mitad de su desarrollo, ni mucho menos. Las cosas se escriben y se estipulan bien. Si el cliente quiere cambiarlo irá a cuenta suya.

jE je... ojala siempre fuera así compañero Max... Existen mitos del cliente, mitos de los gestores del proyecto, mitos de los programadores. Un mito del cliente es que piensan que como el sistema es flexible pueden agregar los cambios que quieran, otro es que piensan que una superficial descripcion de sus requerimientos es suficiente para empezar con el proyecto, luego darán detalles específicos. Claro que un cambio es dinero pero muchas veces se convierte en un dolor de cabeza que el administrador del proyecto hubiese no querido que se de, aunque le paguen mas.

Otro detalle es que no se tilda a los clientes de no serios, solo que los modelos de los negocios cambian, así como sus estrategias. Los sistemas de información gerencial son mucha lata

No tengo mucha experiencia pero lo que cuentas es lo que tenía oído de otros lugares... Ciertamente un cambio grave puede convertirse en muy perjudicial, tanto como casi rehacer el proyecto de 0.

Aunque, si se tiende a hacer un sistema escalable, portable, flexible... se deberían minimizar los problemas. Es decir, que la mayoría del código sirva aunque el cambio se produzca, o al menos que sirva para otra ocasión.

Lograr lo que propones es bastante deseable, pero muy poco realista, sobre todo en sistemas de gestion. Por lo general, los plazos y los tiempos de desarrollo son muy cortos, y ponerse a desarrollar una arquitectura con todas estas caracteristicas lleva demasiado tiempo, y solo se hace en caso de que el usuario lo pida explicitamente y se le haya explicado el costo economico y de tiempo que conlleva esta decision.
Al menos asi lo pienso yo.

Es en esos momentos que el lider(o el gestor, segun como se han organizado las cosas) del proyecto tiene que tomar decisiones. Portabilidad al costo de negociar tiempos o cumplimiento puntual con el cliente aunque despues eso no sirva? Aceptar un cambio antes de la implementacion o que sea post implantacion? Continuar el proyecto con perdida o interrumpir? Todas estas decisiones ocurren dia a dia...

Bueno, hacerlo portable es lo más difícil, pero es sencillo si la empresa ha tenido por costumbre hacerlo desde siempre.

Hacerlo flexible depende de la capacidad del programador para hacer códigos útiles.

Y hacerlo escalable puede significar ir dividiendo el proyecto en módulos o librerías que seguramente se puedan re-utilizar en otro más adelante.

mmmm, tienes razon, no debi haber generalizado sobre lo deseable, algunos aspectos no son faciles de lograr. Pero por ej, es mucho mas rapido hacer un programa con un nivel de flexibilidad normal, que hacer uno que permita casi cualquier cambio con un impacto bajo. Aveces el costo de hacer el codigo tan flexible es mayor que el costo del impacto que generaria un cambio importante en el programa con flexibilidad normal, siempre suponiendo que la flexibilidad es algo facilmente cuantificable.

Bye