Как поощрять принятие контроля версий

Я недавно начал работать в команде, где нет контроля версий. Большинство членов команды не привыкли к контролю версий. Я использовал Mercurial в частном порядке, чтобы отслеживать свою работу. Я хотел бы призвать других принять его и, по крайней мере, начать создавать версии своего кода по мере развития изменений. Может ли кто-нибудь дать мне совет о том, как я могу поощрять принятие распределенного контроля версий, такого как Mercurial. Любой совет о том, как привлечь людей, в том числе менеджеров в DVCS, будет принята с благодарностью.

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

Для коллег-разработчиков программного обеспечения ваше дело должно быть сосредоточено на том, как он экономит время и избавляет от головной боли в долгосрочной перспективе. Найдите время из своего прошлого или опубликованных историй (блоги, статьи в журналах, официальные документы) о том, как использование контроля версий облегчает вашу жизнь. Если вы сгорели из-за отсутствия контроля версий, сделайте его личным. Если ваши коллеги-разработчики оказались в такой же ситуации, они должны увидеть свет и то, как эти инструменты могут им помочь.

Это ваша лучшая ставка. Хотя я не могу найти источник (источники) прямо сейчас, я прочитал (в нескольких местах), что наиболее эффективные изменения в процессе происходят от разработчиков, которым приходится иметь дело с изменениями. Если вы сможете привлечь разработчиков к работе, вы достигнете двух вещей. Во-первых, у вас уже есть вступительный взнос от людей, на которых повлияет изменение процесса. Во-вторых, есть группа людей, которые убеждают руководство в том, что это стоит усилий и улучшит продукт и проект.

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

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

Вы специально упомянули, что хотите использовать распределенную систему контроля версий. Не заставляйте это глотать команду или организацию. Познакомьте их с контролем версий и их опциями. Хотя вы лично предпочитаете использовать DVCS (например, Mercurial), он может не подходить для вашей команды и организации. Использование инструмента, который не подходит, только усугубит ситуацию с молотилкой.

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

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

Первый вопрос: что они делают в настоящее время? Конечно, у каждого разработчика нет исходного кода, прикрепленного к его собственной коробке, которую он изменяет по своему желанию. Если у вас есть процесс, которому они в настоящее время следуют, вы можете предложить некоторые инструменты, которые улучшают этот процесс - обычно SCM идеально подходит, чтобы помочь им в этом, а не заставлять их следовать другому процессу.

Суть в том, что если у них есть псевдо-SCM способ работы, возможно, где-то хранится текущая версия на сервере, тогда вам нужно определить, подходит ли DVCS или CVS, не пытайтесь продавать их Mercurial. если SVN лучше подходит.

Самый быстрый способ - убедить руководство в том, что оно необходимо.

Сделайте некоторые расчеты:

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

Стоимость не реализации контроля версий:

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

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

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

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

Есть один аспект, который другие люди здесь не затронули, и я думаю, что вы находитесь в своем углу - вы говорите о распределенном контроле версий - по самой своей природе, вы можете использовать это в практике, один разработчик вовремя. С более жестким контролем версий, таким как то, что мы используем в моем офисе (MS Visual SourceSafe), вам будет трудно подойти к парню в кубе напротив моего и продать его, один на один, за заслуги контроль версий. Тем не менее, с (любой) DVCS, вы можете просто сказать «эй, попробуйте это, и посмотрите, если вам это нравится. Я покажу вам веревки, и я был бы рад ответить на любые вопросы, проведу вас через, бла-бла бла». Таким образом, вам не нужен «процесс» сверху вниз, вы можете создать мандат на низовом уровне, по одному человеку за раз.

Опираясь на ответ Гбйбаанба.

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

Я лично также предпочитаю Mercurial, но не обязательно навязывать его людям, не привыкшим к управлению версиями, потому что это немного сложнее понять, чем старомодная серверная система контроля версий с блокировкой версий. Тем не менее, если это настоящий сайт с зелеными полями, может быть, лучше всего пойти на свиней, пропустить 80-х и 90-х годов и перейти на Mercurial. Я также хотел бы взглянуть на некоторые сторонние программы жизненного цикла, построенные на Mercurial - я уверен, что есть один, но его имя ускользает от меня;)

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