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.
13/01/2006, 16:53
| ||||
| ||||
 ¿Como organizarse cuando hay mas de 1 programador en php? 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. |
|
13/01/2006, 19:28
| ||||
| ||||
| 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 
__________________ Todos somos muy ignorantes :pensando: . Lo que ocurre es que no todos ignoramos las mismas cosas ;-) .... Albert Einstein :cool: |
|
12/02/2006, 17:33
| ||||
| ||||
| 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
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
13/02/2006, 09:21
| ||||
| ||||
| 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... |
|
13/02/2006, 09:33
| |||
| |||
| 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. |
|
13/02/2006, 10:10
| ||||
| ||||
| Cita: 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.
Iniciado por MaxExtreme Siempre debe haber uno, que será quien tenga la mayor responsabilidad: Diseñar y modularizar la aplicación. Salu2
__________________ Nadie roba nada ya que en la vida todo se paga . . . Exentrit - Soluciones SharePoint & Net |
|
14/02/2006, 21:40
| ||||
| ||||
| 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
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
03/03/2006, 10:43
| ||||
| ||||
| 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á. |
|
03/03/2006, 11:56
| |||
| |||
| Cita: 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.
Iniciado por Developer9 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á. |
|
04/03/2006, 16:31
| ||||
| ||||
| 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 |
|
04/03/2006, 17:54
| |||
| |||
| Cita: 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.
Iniciado por Developer9 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 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. |
|
06/03/2006, 08:46
| ||||
| ||||
| Cita: 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.
Iniciado por MaxExtreme 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. Al menos asi lo pienso yo.
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
08/03/2006, 18:37
| ||||
| ||||
| 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...
__________________ No tengo firma ahora... :( |
|
08/03/2006, 19:49
| |||
| |||
| Cita: Bueno, hacerlo portable es lo más difícil, pero es sencillo si la empresa ha tenido por costumbre hacerlo desde siempre.
Iniciado por TolaWare 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. 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. |
|
11/03/2006, 00:42
| ||||
| ||||
| 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
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
08/07/2011, 09:22
| ||||
| ||||
 Respuesta: ¿Como organizarse cuando hay mas de 1 programador en php? Después de muchos años (5 para ser exactos desde que se inició este post) de práctica y experiencia he constatado que: Para programar PHP en equipo hay que cumplir con los siguientes requisitos: - Análisis de software imprescindible en etapas tempranas del proyecto, hay que saber ver cuales van a ser los cambios que mas adelante se van a pedir, anticiparse siempre a los clientes. - OOP: Imprescindible que todos los miembros del equipo sepan gestionar un proyecto con orientación a objetos. - ESPECIALIZACIÓN: Quien sabe PHP a lo suyo, quien sabe MySQL igual, javascript, html etc, cada elemento del equipo se debe especializar en mantener una parte del proyecto aunque todos colaboran con todos hay un "encargado" para cada cosa. - Subversion!!! Si hay algo que ayuda a los programadores por fin a mantener nuestro código sin interrupciones del resto que programan en el equipo de desarrollo. (CVS, Mercurial, Git, etc etc). - IDE's potentes: Netbeans, eclipse hay que adaptarse a trabajar con el que mas nos guste ya que suelen tener plugins para todo tipo de situaciones. No dejéis de esforzaros y conseguiréis trabajar de forma óptima. Un saludo a todos. |
