control de fuente cuando se inicia un nuevo proyecto

Cuando empiezo con un proyecto y uso el control de fuente, me resulta difícil separar las cosas en las que las personas están trabajando para que no escriban código duplicado o crean que debe nombrarse una cosa, y así sucesivamente. este problema disminuye con el time porque la base general está en su lugar y es más fácil separar las tareas para que no se superpongan tanto

¿Cómo te las arreglas para trabajar con el control de fuente en la fase inicial?

EDITAR: puedo ver que realmente no tiene nada que ver con el control de fuente, pero se vuelve más evidente cuando también tienes control de fuente. entonces la pregunta se vuelve más en la línea de "cómo logras separar las tareas para que no se superpongan demasiado. Creo que es realmente difícil y realmente no he visto mucho sobre cómo hacerlo.

Bueno, en lo que respecta al control de la fuente, alguien debe tomar la iniciativa y establecer la estructura básica del proyecto, directorys, etc. y comunicarlo al equipo. En los proyectos en los que trabajo, generalmente se trata de un arquitecto o desarrollador sénior, alguien que conoce las mejores prácticas para la organización de proyectos para el equipo / empresa.

Con respecto a evitar que varias personas trabajen en las mismas tareas, esa es una function de administración de proyectos; alguien necesita determinar qué tareas se deben hacer y comunicarlo al equipo. Si trabaja en un entorno ágil / scrum, el equipo puede dividir y repartir elementos de trabajo entre ellos, pero en cualquier caso necesita comunicarse para evitar hacer el mismo trabajo dos veces.

EDITAR

Para abordar el problema de varias personas que trabajan en la misma tarea, tiendo a trabajar en equipos más pequeños, de 2 a 6 personas; en este entorno, he tenido mucho éxito con un enfoque basado en el melé usando la metodología Crystal Clear :

  1. Arquitecto (s) / diseñador (es) presentan un layout de alto nivel
  2. Arquitecto (s) / diseñador (es) definen iteraciones / entregas, la primera de las cuales es un "esqueleto del proyecto" que consiste en componentes arquitectónicos y de back-end y una porción delgada de la aplicación
  3. El responsable divide las funciones en tareas / unidades de trabajo de 1 a 3 días (estimadas)
  4. El equipo se reúne y analiza la prioridad, el time y las dependencies de las tareas, y divide el primer set de tareas
  5. El equipo tiene reuniones diarias breves para discutir el estado / prioridades y dependencies, y cambiar la dirección si es necesario

Con proyectos / equipos más grandes, casi seguramente necesitará a alguien cuyo trabajo principal esté dedicado a rastrear el estado, las dependencies y los conflictos.

No creo que el control de fuente tenga mucho que ver con el problema de coordinar los esfuerzos de las personas (excepto que puede detectar algunos "conflictos" cuando las personas intentan erróneamente modificar los mismos files de diferentes maneras, pero eso no es tan bueno como prevenir conflictos, e incluso solo "prevenir conflictos" no garantizan per se que todos estén trabajando en lo que deberían estar trabajando idealmente en este momento, en términos de prioridades). La coordinación se gestiona adecuadamente con prácticas (y quizás herramientas, por ejemplo, Pivotal Tracker , pero, ¡utilizar las prácticas correctas es incluso más importante que usar buenas herramientas!) Que se centren específicamente en garantizar la coordinación. Por ejemplo, las prácticas que Tracker está diseñado para soportar y mejorar, como la planificación iterativa basada en la historia, y otras compatibles, como los stand-ups , ofrecen forms de satisfacer estas necesidades.

Debe tener una versión base que todo el mundo esté usando, verificarla en el repository y luego realizar cambios incrementales en el repository, asegurarse de que todos trabajen en diferentes partes del código, comprometer todos los cambios de trabajo y resolver conflictos como y cuando ellos ocurren Así es como lo haría.