Какие инструменты вы используете для обмена информацией между разработчиками в вашей группе?

Question

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

Мы думаем о внутреннем блоге и вики.

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

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

Как ваша организация это делает.

Answer 1

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

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

Answer 2

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

• Внимание при написании (будь то документ на сетевом диске, вики-страница, сервер SharePoint и т. Д.).
• Внимание, чтобы классифицировать его (путем ссылки, теги, веб-страницы, что угодно ...).
• Внимание, чтобы держать это в актуальном состоянии (индивидуальным по требованию или запланированным усилием,).

Что бы вы ни использовали, никакие технологии не помогут в этом. Для этого вам нужно мотивировать команду записывать что-то, сначала читать вещи в хранилище, прежде чем звонить (и прерывать) кучу других членов команды, и исправлять, если они не правы.

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

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

Answer 3

Мы используем комбинацию Trac для вики, scm и тикетов и частного Jabber / IRC-сервера, чтобы мы могли общаться друг с другом.

Answer 4

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

Answer 5

На моей предыдущей работе мы использовали SharePoint для организации нашей документации. Это было достаточно успешно, но очевидно, что необходимо поддерживать сайт в актуальном состоянии, актуальным и соответствующим образом настроенным. Однако архитектура SharePoint была достаточно гибкой, чтобы мы могли настраивать ее в соответствии с нашими потребностями, не прибегая к кодированию. Я хотел бы предложить вам выделить некоторое время для управления любым решением, к которому вы стремитесь. Без обслуживания хранилище документации становится очень устаревшим или неорганизованным. Мы собирались обновлять папки нашей команды в конце каждого спринта (мы использовали гибкую методологию Scrum).

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

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

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

Надеюсь, это поможет.

Answer 6

Мы используем Campfire для нашего чата и Jing для нашего изображения и / или коротких видео демонстраций. Они оказались неоценимыми.

Answer 7

мессенджеры и электронная почта

Answer 8

Мы используем Fogbugz для вики, дискуссионных групп и целенаправленного обсуждения конкретных случаев. Для обмена мгновенными сообщениями мы используем Sametime . Эта комбинация оказалась для нас очень мощной, потому что она обеспечивает множество функциональных возможностей, не навязывая нам большой интерфейс. Низкая церемония это хорошо.

ПРИМЕЧАНИЕ. Обмен мгновенными сообщениями - это единственный аспект Sametime, который мы используем. Я полагаю, что вы можете сделать множество других сумасшедших вещей, и мы совершенно не заинтересованы в этом.

Answer 9

Для управления контентом мы использовали сервер Zope с Plone и ZWiki . Теперь мы используем SharePoint 2007 .

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

Answer 10

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

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

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

Одна вещь, которую мы сделали, это то, что у нас был день, когда все разработчики встречались где-то за пределами офиса и представляли друг другу интересные вещи, которые они нашли / сделали. Иногда вещи из проектов, иногда из личной работы, а иногда из дня в месяц, людям разрешалось работать над чем угодно (например, у Google 20% времени).