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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

Мы используем Yammer для короткой информации, которая является услугой в Twitter, но она является частной в вашем домене электронной почты. Существует веб-приложение, клиент Windows и Mac и даже версия для iPhone.

Для документации мы используем Wiki с открытым исходным кодом (ScrewturnWiki на платформе ASP.NET). Это было принято очень хорошо.

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

посланники и электронная почта

Ответ 11

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

Ответ 12

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

И мы часто ходим друг к другу, чтобы задавать вопросы.

Ответ 13

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

Ответ 14

Skype хорош, чтобы делиться информацией/задавать быстрые вопросы. Для некоторых долгосрочных ноу-хау мы используем Wiki.

Ответ 15

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