|
|
|
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
Всем привет!
Чего то раздел наш немного приуныл. Неужели ни у кого нет вопросов для обсуждения, кроме как source control? Предлагаю поделиться опытом управления распределенными командами. В свете последних веяний Винграда это будет интересно всем. Я себе вижу следующие возможные сценарии распределенной работы: 1) Total Distributed - каждый член команды сидит дома, взаимодействие только виртуальное (почта, скайп, IP) 2) Semi Distributed - это когда взаимодействуют несколько удаленных команд (в разных конфигурациях) Лично мне приходилось работать во всех случаях, поэтому готов поделиться личным опытом. Задавайте вопросы, делитесь своим опытом, в общем давайте общаццо |
|||
|
||||
intr |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 128 Регистрация: 18.12.2005 Репутация: нет Всего: 2 |
Доброе время суток,
охота услышать личный опыт в организации распределенных команд. Наша компания в конце этого года планирует распределиться и поэтому особо интересны все подводные камни. --------------------
Исследователь бытия и по совместительству Java-developer |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
intr,
Невопрос Основные проблемы распределенности: 1) Сложнее наладить коммуникацию. Нужны удобные тулзы для управления проектами. Нужно разработчиков загонять в чат. Нужно писать больше документации. 2) Overhead на ^^^^^^^ нужно закладывать сразу 3) Модель будет работать не для всех разработчиков 4) Сложнее мотивировать Это навскидку. |
|||
|
||||
intr |
|
||||||||
Шустрый Профиль Группа: Участник Сообщений: 128 Регистрация: 18.12.2005 Репутация: нет Всего: 2 |
Что за тулзы использовали?
Сколько процентов от стоимости разработчика? Интересна минимальна, средняя и максимальная величины.
Тоже интересный момент, как контролировать эффективность конкретного разработчика?
Какие схемы Вы использовали? Еще бытует мнение что командное взаимодействие эффективно когда люди работают в одной комнате. Опять же интересна статистика и личный опыт. Сильно ли удаленная работа влияет на качество продукции (разработка ПО)? p/s --------------------
Исследователь бытия и по совместительству Java-developer |
||||||||
|
|||||||||
arilou |
|
||||||||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
TargetProcess, Hansoft, Google Apps. Пока остановились на последнем.
Сложный вопрос - зависит от разработчика. Навскидку, 30-40% сверху.
С помощью тулзов и ежедневного общения. Лично мне нравится оценка project velocity (считать скорость реализации use cases). Мониторить коммиты в репозиторий, заставлять писать вразумительные комментарии к ним (т.е. смысл коммита, а не его содержание). Можно на "ты" Кроме денег в таком случае трудно мотивировать. Как ты понимаешь, сплочать (или сплачивать? ) коллектив, когда все удаленные - сложно. Если есть возможность, надо организовывать раз в неделю встечу в офисе. У нас к сожалению не было :(
О да, это однозначно! Вот ссылка в тему - http://lostgarden.com/2008/09/rules-of-pro...esentation.html
Если все программисты опытные, то с учетом вышесказанного, будут работать качественно. Но это не отменяет QA Вообще, если личный опыт резюмировать - если есть возможность выбирать, лучше меньше, но в офисе, чем больше, но удаленно. Кстати, мою любимый инструмент планирования - whiteboard. Удаленно им не воспользуешься |
||||||||
|
|||||||||
intr |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 128 Регистрация: 18.12.2005 Репутация: нет Всего: 2 |
От разработчика зависит почти все А сколько процентов при неудаленной работе?
А видео-чат пробовал?
Спасибо за ссылку, покажу одному своему другу. Он любитель поработать по 60-80 часов в неделю Возможно при удаленной разработке очень важна простота и прозрачность процесса разработки. Регламенты и стандарту будут неэффективны. --------------------
Исследователь бытия и по совместительству Java-developer |
||||||
|
|||||||
UniBomb |
|
|||
Новичок Награды: 1 Профиль Группа: Участник Клуба Сообщений: 1754 Регистрация: 24.10.2006 Где: Санкт-Петербург Репутация: нет Всего: 97 |
Продолжу диалог Интересуют вопросы начального уровня, но ответов я найти не смог
что имеется: - команда девелоперов - svn + trac + wiki хостинг (assembla.com) - собственный форум и аська для общения - собственная wiki для финксации достигнутых результатов - желание трудиться Итак. Вот есть проект, состоящий естественно из файлов *.cpp и *.h, файлов проекта, дополнительных модулей и библиотек. А так же папки "debug" и "release". Из документации мне стало ясно, что в репозитории svn надо создать как минимум три папки: - для текущей стабильной версии - для текущей разрабатываемой версии - для форков А вот что заливать в эти папки я так и не понял. Надо ли заливать в них весь проект целиком (со вложенными папками и файлами проекта)? Или только компилируемые файлы (*.cpp, *.h, *.lib и т.д.)? А если проект включает в себя сторонние библиотеки, которые хранятся в одном месте (например c:\someframework\), то надо ли их тоже включать в репозиторий? |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
UniBomb, это вопрос не совсем про распределенные команды, но я отвечу в контексте.
В свн нужно заливать все файлы, необходимые для того, чтобы разработчик мог собрать версию у себя на машине. Обычно применяется такая структура: Верхний уровень: /trunk - текущая версия исходного когда, используется разработчиками /tags - папка, куда складываются стабильные версии /branches - папка, куда складываются бранчи (форки) Trunk: /trunk/src/ - сюда идет исходный код проекта (cpp, h, prj, mak, и и.п., но ни в коем случае не obj, lib, exe) /trunk/lib/ - сюда можно залить используемые библиотеки /trunk/docs/ - сюда пойдут всякие доки Tags: Используется, когда нужно зафиксировать некую стабильную версию. К примеру, выпускаешь версию 1.0, и фиксируешь ее в свине. Таким образом можно в trunk продолжать делать 1.1, а в tags на всякий случай иметь 1.0, и, к примеру, фиксить вней зарепорченные баги. Branches: В моем опыте не использовалась никогда. Нужна для создания к примеру эксперементальных версий trunk'а, когда надо что-то проверить, не мешая основной команде. Обычно на девелоперскую машину сливается /trunk. |
|||
|
||||
UniBomb |
|
|||
Новичок Награды: 1 Профиль Группа: Участник Клуба Сообщений: 1754 Регистрация: 24.10.2006 Где: Санкт-Петербург Репутация: нет Всего: 97 |
||||
|
||||
Serkys |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1061 Регистрация: 19.4.2004 Репутация: нет Всего: 22 |
Мне кажется, лучше включить. К тому же в каждую ветку (development, stable и т.д.) - свои экземпляры. Это позволит переводить девелопмент-версию на новые версии библиотек, никак не затрагивая стабильную версию. |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
Serkys, всё верно.
|
|||
|
||||
ida |
|
|||
замужем Профиль Группа: Завсегдатай Сообщений: 2275 Регистрация: 14.5.2002 Где: Санкт-Петербург Репутация: нет Всего: 60 |
Насколько я поняла, вы тут о методологических аспектах рассуждаете?...
Я недавно столнулась с такой необходимостью, но решила не городить огород и обратиться за помощью к организационному консультанту (в т.ч. работающему с географически распределенными командами). Стоит это, кстати, недешево. Из беседы выяснилось, что эффективность такой команды очень сильно зависит от того, была ли проведена хотя бы одна реальная встреча всех участников. Если нет - результаты будут значительно хуже, чем если встреча проводилась. В чем мистика, я не знаю, но в-частности этот консультант работает с крупными западными разработчиками ПО, где персонал часто разбросан по всей Европе, и там подход к делу именно такой - причем в длительных проектах встречи проводятся регулярно с периодичностью раз в несколько месяцев. Удаленной коммуникации это не отменяет. |
|||
|
||||
bilbobagginz |
|
|||
Naughtius Maximus Профиль Группа: Экс. модератор Сообщений: 8813 Регистрация: 2.3.2004 Где: Israel Репутация: 1 Всего: 317 |
есть один элементарный момент который иногда прошляпивают: часовые пояса.
если есть возможность, постарайтесь не сильно распределяться с т.з. часовых поясов. также обязательно нужна голосовая/видео связь - намного более эффективно чем чатиться или мылиться. для этого нередко стоит отделить специальную линию, чтобы ее нельзя были "нечаянно" забить. -------------------- Я ещё не демон. Я только учусь. |
|||
|
||||
Lazin |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 3820 Регистрация: 11.12.2006 Где: paranoid oil empi re Репутация: нет Всего: 154 |
вообще, для такого использования subversion не очень удобен, так-как там не истории слияний(merge history), вам придется каждый раз повторять одни и те-же действия, когда вы будете переносить изменения из trunc в tags или наоборот. К примеру, у вас есть 2 ветки, trunk и stable, во время использования программы обнаруживается баг(в stable) вы его быстро исправляете(в stable) и хотите, что-бы эти изменения оказались в trunk-e, для этого нужно сделать merge, вот здесь svn сольет по полной любой современной DVCS(mercurial/git/bazaar), так как следующий merge нужно будет выполнять так-же как и этот первый. А DVCS, имеют merge history, и если вы во время слияния не переносите изменения, к примеру из файла foo.cpp, система контроля версий это запомнит и в следующий раз все сделает сама. В svn в принципе нельзя реализовать нормальный merge, из-за структуры репозитория, который имеет линейную структуру. |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 2 Всего: 61 |
Lazin, спасибо за замечание глянул одним глазом, что пишут в группах по СВНу, вижу, что вроде как планируют merge tracking в 2.0
Добавлено через 2 минуты и 38 секунд
Кстати, хорошее замечание |
|||
|
||||
|
НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены. Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | УП: Общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |