Исходный контроль при запуске нового проекта

Question

при запуске проекта и использовании источника управления мне трудно отделить вещи, над которыми работают люди, поэтому они не пишут дублирующий код или не думают, что его следует называть одной вещью и скоро. эта проблема уменьшается со временем, потому что общий фундамент на месте, и легче отделить задачи, чтобы они не перекрывались столько же.

Как вы управляете работой с контролем источника на начальной стадии?

EDIT: я могу видеть, что это на самом деле не имеет ничего общего с контролем источника, но это становится все более очевидным, если у вас есть управление версиями. поэтому вопрос становится более похожим на «как вам удается отделить задачи, чтобы они не перекрывались слишком много. Я думаю, что это действительно сложно, и я не очень много разбираюсь в том, как это сделать.

Answer 1

Ну, что касается контроля версий, кому-то нужно взять на себя инициативу и настроить основную структуру проекта, каталоги и т. Д. И сообщить об этом команде. В проектах, над которыми я работаю, это, как правило, архитектор или старший разработчик, тот, кто знает лучшие практики для организации проекта для команды/компании.

Относительно того, что несколько человек работают над одними и теми же задачами, это функция управления проектами; кто-то должен определить, какие задачи нужно выполнить, и сообщить об этом команде. Если вы работаете в гибкой/схваченной среде, команда может делиться и раздавать рабочие элементы между собой, но в любом случае вам нужно общаться, чтобы не выполнять одну и ту же работу дважды.

EDIT

Для решения вопроса о нескольких людей, работающих на одной и той же задачи, я, как правило, работают на небольших команд, 2-6 человек; в этой среде, у меня было много успеха с scrum -influenced подхода с использованием методологии Crystal Clear:

1. Архитектор (ы)/дизайнер (ы) придумать дизайн высокого уровня
2. Архитектор (ы)/designer (s) определяют итерации/поставки, первым из которых является «скелет проекта», который состоит из архитектурных и фоновых компонентов и тонкого фрагмента приложения.
3. Ведущий человек разбивает функции на 1-3 дня/единиц работы (оценка)
4. Команда отвечает и обсуждает приоритет, время и зависимости задач и делит f рвый набор задач
5. Команда имеет короткие ежедневные встречи для обсуждения состояния/приоритетов и зависимостей, и изменить направление, при необходимости

С большими проектами/командами, вы почти наверняка нужны кого-то, чьи основной работой посвящена статус отслеживания, зависимости и конфликты.

Answer 2

У вас должна быть базовая версия, которую все используют, проверьте ее в репозитории, а затем внесите инкрементные изменения в репозиторий, убедитесь, что все работают на разных частях кода, фиксируют каждое рабочее изменение и разрешают конфликты как и когда

Answer 3

Я не думаю, что контроль источника имеет отношение к проблеме координации усилий людей (за исключением того, что он может поймать некоторые «конфликты», когда люди ошибочно пытаются изменить одинаковые файлы по-разному - но это не так хорошо, как предотвращение путаницы ts, и даже просто «предотвращение конфликтов» само по себе не гарантирует, что все работают над тем, что они в идеале должны работать сейчас, с точки зрения приоритетов). Координация должным образом управляется с помощью практик (и, возможно, инструментов, например, Pivotal Tracker), но использование правильных методов является еще более важным, чем использование хороших инструментов! -), которые специально направлены на обеспечение координации. Например, методы, которые Tracker разрабатывает для поддержки и улучшения, например, итеративное планирование на основе истории, и другие совместимые, такие как stand-ups, предлагают способы удовлетворения этих потребностей.