Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Управление распределенными командами, предлагаю обсудить 
:(
    Опции темы
arilou
Дата 6.10.2008, 12:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



Всем привет!

Чего то раздел наш немного приуныл. Неужели ни у кого нет вопросов для обсуждения, кроме как source control?  smile 

Предлагаю поделиться опытом управления распределенными командами. В свете последних веяний Винграда это будет интересно всем. Я себе вижу следующие возможные сценарии распределенной работы:

1) Total Distributed - каждый член команды сидит дома, взаимодействие только виртуальное (почта, скайп, IP)
2) Semi Distributed - это когда взаимодействуют несколько удаленных команд (в разных конфигурациях) 

Лично мне приходилось работать во всех случаях, поэтому готов поделиться личным опытом. 

Задавайте вопросы, делитесь своим опытом, в общем давайте общаццо  smile  


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
intr
Дата 9.10.2008, 09:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 128
Регистрация: 18.12.2005

Репутация: нет
Всего: 2



Доброе время суток,

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


--------------------
Исследователь бытия и по совместительству Java-developer
PM MAIL WWW Skype GTalk   Вверх
arilou
Дата 9.10.2008, 12:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



intr
Цитата

особо интересны все подводные камни


Невопрос  smile 

Основные проблемы распределенности:

1) Сложнее наладить коммуникацию. Нужны удобные тулзы для управления проектами. Нужно разработчиков загонять в чат. Нужно писать больше документации. 
2) Overhead на ^^^^^^^ нужно закладывать сразу
3) Модель будет работать не для всех разработчиков 
4) Сложнее мотивировать

Это навскидку. 


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
intr
Дата 9.10.2008, 13:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 128
Регистрация: 18.12.2005

Репутация: нет
Всего: 2



Цитата(arilou @ 9.10.2008,  17:53)

1) Сложнее наладить коммуникацию. Нужны удобные тулзы для управления проектами. Нужно разработчиков загонять в чат. Нужно писать больше документации. 

Что за тулзы использовали? 
Цитата(arilou @ 9.10.2008,  17:53)

2) Overhead на ^^^^^^^ нужно закладывать сразу

Сколько процентов от стоимости разработчика? Интересна минимальна, средняя и максимальная величины.
Цитата(arilou @ 9.10.2008,  17:53)

3) Модель будет работать не для всех разработчиков 

Тоже интересный момент, как контролировать эффективность конкретного разработчика? 
Цитата(arilou @ 9.10.2008,  17:53)

4) Сложнее мотивировать

Какие схемы Вы использовали?

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

Сильно ли удаленная работа влияет на качество продукции (разработка ПО)?

p/s
smile
--------------------
Исследователь бытия и по совместительству Java-developer
PM MAIL WWW Skype GTalk   Вверх
arilou
Дата 9.10.2008, 15:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Что за тулзы использовали? 

TargetProcess, Hansoft, Google Apps. Пока остановились на последнем.

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Сколько процентов от стоимости разработчика? Интересна минимальна, средняя и максимальная величины.

Сложный вопрос - зависит от разработчика. Навскидку, 30-40% сверху.

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Тоже интересный момент, как контролировать эффективность конкретного разработчика? 

С помощью тулзов и ежедневного общения. Лично мне нравится оценка project velocity (считать скорость реализации use cases). Мониторить коммиты в репозиторий, заставлять писать вразумительные комментарии к ним (т.е. смысл коммита, а не его содержание). 

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Какие схемы Вы использовали?

Можно на "ты"  smile 

Кроме денег в таком случае трудно мотивировать. Как ты понимаешь, сплочать (или сплачивать?  smile) коллектив, когда все удаленные - сложно. Если есть возможность, надо организовывать раз в неделю встечу в офисе. У нас к сожалению не было :(

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Еще бытует мнение что командное взаимодействие эффективно когда люди работают в одной комнате. Опять же интересна статистика и личный опыт. 


О да, это однозначно! Вот ссылка в тему - http://lostgarden.com/2008/09/rules-of-pro...esentation.html

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Сильно ли удаленная работа влияет на качество продукции (разработка ПО)?


Если все программисты опытные, то с учетом вышесказанного, будут работать качественно. Но это не отменяет QA  smile 

Вообще, если личный опыт резюмировать - если есть возможность выбирать, лучше меньше, но в офисе, чем больше, но удаленно. Кстати, мою любимый инструмент планирования - whiteboard. Удаленно им не воспользуешься  smile 


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
intr
Дата 9.10.2008, 17:25 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 128
Регистрация: 18.12.2005

Репутация: нет
Всего: 2



Цитата(arilou @ 9.10.2008,  20:14)

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Сколько процентов от стоимости разработчика? Интересна минимальна, средняя и максимальная величины.

Сложный вопрос - зависит от разработчика. Навскидку, 30-40% сверху.

От разработчика зависит почти всеsmile А сколько процентов при неудаленной работе?

Цитата(arilou @ 9.10.2008,  20:14)

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Какие схемы Вы использовали?

Можно на "ты"  smile 
Кроме денег в таком случае трудно мотивировать. Как ты понимаешь, сплочать (или сплачивать?  smile) коллектив, когда все удаленные - сложно. Если есть возможность, надо организовывать раз в неделю встечу в офисе. У нас к сожалению не было :(

А видео-чат пробовал?

Цитата(arilou @ 9.10.2008,  20:14)

Цитата(intr @  9.10.2008,  13:53 Найти цитируемый пост)
Еще бытует мнение что командное взаимодействие эффективно когда люди работают в одной комнате. Опять же интересна статистика и личный опыт. 

О да, это однозначно! Вот ссылка в тему - http://lostgarden.com/2008/09/rules-of-pro...esentation.html

Спасибо за ссылку, покажу одному своему другу. Он любитель поработать по 60-80 часов в неделюsmile

Возможно при удаленной разработке очень важна простота и прозрачность процесса разработки.  Регламенты и стандарту будут неэффективны.
--------------------
Исследователь бытия и по совместительству Java-developer
PM MAIL WWW Skype GTalk   Вверх
UniBomb
Дата 20.10.2008, 12:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
***
Награды: 1



Профиль
Группа: Участник Клуба
Сообщений: 1754
Регистрация: 24.10.2006
Где: Санкт-Петербург

Репутация: нет
Всего: 97



Продолжу диалог  smile  Интересуют вопросы начального уровня, но ответов я найти не смог  smile 

что имеется:

- команда девелоперов
- svn + trac + wiki хостинг (assembla.com)
- собственный форум и аська для общения
- собственная wiki для финксации достигнутых результатов
- желание трудиться  smile 

Итак. Вот есть проект, состоящий естественно из файлов *.cpp и *.h, файлов проекта, дополнительных модулей и библиотек. А так же папки "debug" и "release". Из документации мне стало ясно, что в репозитории svn надо создать как минимум три папки:

- для текущей стабильной версии
- для текущей разрабатываемой версии
- для форков

А вот что заливать в эти папки я так и не понял. Надо ли заливать в них весь проект целиком (со вложенными папками и файлами проекта)? Или только компилируемые файлы (*.cpp, *.h, *.lib и т.д.)? А если проект включает в себя сторонние библиотеки, которые хранятся в одном месте (например c:\someframework\), то надо ли их тоже включать в репозиторий?


--------------------
PM MAIL ICQ Skype   Вверх
arilou
Дата 20.10.2008, 13:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



UniBomb, это вопрос не совсем про распределенные команды, но я отвечу в контексте.

Цитата

вот что заливать в эти папки я так и не понял. Надо ли заливать в них весь проект целиком (со вложенными папками и файлами проекта)? Или только компилируемые файлы (*.cpp, *.h, *.lib и т.д.)? А если проект включает в себя сторонние библиотеки, которые хранятся в одном месте (например c:\someframework\), то надо ли их тоже включать в репозиторий? 


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

Верхний уровень:
/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.


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
UniBomb
Дата 20.10.2008, 17:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
***
Награды: 1



Профиль
Группа: Участник Клуба
Сообщений: 1754
Регистрация: 24.10.2006
Где: Санкт-Петербург

Репутация: нет
Всего: 97



Цитата(arilou @  20.10.2008,  13:16 Найти цитируемый пост)
это вопрос не совсем про распределенные команды, но я отвечу в контексте

Ну да, это я уже понял))) Просто не знал куда запостить))


--------------------
PM MAIL ICQ Skype   Вверх
Serkys
Дата 20.10.2008, 18:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1061
Регистрация: 19.4.2004

Репутация: нет
Всего: 22



Цитата(UniBomb @  20.10.2008,  13:03 Найти цитируемый пост)
А если проект включает в себя сторонние библиотеки, которые хранятся в одном месте (например c:\someframework\), то надо ли их тоже включать в репозиторий? 

Мне кажется, лучше включить. К тому же в каждую ветку (development, stable и т.д.) - свои экземпляры. Это позволит переводить девелопмент-версию на новые версии библиотек, никак не затрагивая стабильную версию.
PM MAIL   Вверх
arilou
Дата 20.10.2008, 20:17 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



Serkys, всё верно. 


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
ida
Дата 27.3.2009, 22:35 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2275
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: нет
Всего: 60



Насколько я поняла, вы тут о методологических аспектах рассуждаете?...

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

Из беседы выяснилось, что эффективность такой команды очень сильно зависит от того, была ли проведена хотя бы одна реальная встреча всех участников. Если нет - результаты будут значительно хуже, чем если встреча проводилась. В чем мистика, я не знаю, но в-частности этот консультант работает с крупными западными разработчиками ПО, где персонал часто разбросан по всей Европе, и там подход к делу именно такой - причем в длительных проектах встречи проводятся регулярно с периодичностью раз в несколько месяцев. Удаленной коммуникации это не отменяет.
PM WWW   Вверх
bilbobagginz
Дата 29.3.2009, 19:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Naughtius Maximus
****


Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 1
Всего: 317



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



--------------------
Я ещё не демон. Я только учусь.
PM WWW   Вверх
Lazin
Дата 30.3.2009, 08:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 3820
Регистрация: 11.12.2006
Где: paranoid oil empi re

Репутация: нет
Всего: 154



Цитата(arilou @  20.10.2008,  13:16 Найти цитируемый пост)
В свн нужно заливать все файлы, необходимые для того, чтобы разработчик мог собрать версию у себя на машине. Обычно применяется такая структура:

Верхний уровень:
/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, и, к примеру, фиксить вней зарепорченные баги.

вообще, для такого использования 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, из-за структуры репозитория, который имеет линейную структуру.
PM MAIL Skype GTalk   Вверх
arilou
Дата 30.3.2009, 12:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Великий МунаБудвин
****


Профиль
Группа: Экс. модератор
Сообщений: 2646
Регистрация: 15.7.2004
Где: город-герой Минск

Репутация: 2
Всего: 61



Lazin, спасибо за замечание  smile глянул одним глазом, что пишут в группах по СВНу, вижу, что вроде как планируют merge tracking в 2.0

Добавлено через 2 минуты и 38 секунд
Цитата(ida @  27.3.2009,  22:35 Найти цитируемый пост)
Из беседы выяснилось, что эффективность такой команды очень сильно зависит от того, была ли проведена хотя бы одна реальная встреча всех участников. Если нет - результаты будут значительно хуже, чем если встреча проводилась. В чем мистика, я не знаю, но в-частности этот консультант работает с крупными западными разработчиками ПО, где персонал часто разбросан по всей Европе, и там подход к делу именно такой - причем в длительных проектах встречи проводятся регулярно с периодичностью раз в несколько месяцев. Удаленной коммуникации это не отменяет. 

Кстати, хорошее замечание  smile 


--------------------
user posted imageuser posted image
PM WWW ICQ   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
arilou

НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | УП: Общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.1618 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.