Способы улучшить связь между участниками в [закрытой] команде программного обеспечения
Как команда я нахожусь на работах, чтобы формализовать и установить больше методов разработки, я нахожу, что коммуникация, кажется, перестала работать в следующих моментах:
Во время неофициального разговора о проекте мозговой момент искры становится новой возможностью / требование. Эти "дополнения", кажется, перестали работать через трещины, или деталь становятся нечеткими, через какое-то время передал.
На встречах, где цели или задачи ясно не делегированы, у участников, вовлеченных во встречу, есть различные учетные записи того, что было на самом деле обсуждено.
Как команда нам постоянно бросают вызов (больше теперь, когда мы на самом деле стремимся писать им) генерировать качественные спецификации и технические документы, которые детализируют точно, чем функции должны быть в проектах.
Мой вопрос: Что некоторые предложения и подходы к обращению к этим коммуникационным узким местам и неэффективности? Никакому программисту не нравится писать документацию, но надо надеяться, существует способ, которым мы можем централизовать понимание и сохранить ту информацию более видимой и доступной в течение жизненного цикла проекта...
Спасибо за помощь!
8 ответов
Придерживаться повестки дня. Оставаться на цели. Когда все начинают отказываться от курса, либо запланируйте еще одну встречу, либо возьмите его на адрес электронной почты после встречи.
Завершить каждую встречу с элементами действий - письменный список того, кто собирается делать то, что и когда он ожидается. Да, это означает, что кто-то должен писать / вводить что-то во время встречи.
Если документация становится важной и необходимой, то я настоятельно рекомендую вам придумать простые стандарты, а затем придерживаться их.
Wiki. Вики. Вики. Все «племенные знания» информация, полезная для команды, должна пойти в вики. Как настроить среды DEV, общие советы отладки и т. Д.
Документируйте все, а не по электронной почте!
Используйте что-то с историей. Я искушал использовать Google Wave для отслеживания «разработки проекта» (изменение требований, интерпретаций и т. Д.). Wiki тоже будет работать, но имеет более высокий барьер для редактирования и может быть обновлен менее людьми. Крепник также является хорошей методологией.
Новые методологии (Cadfire / Wave) по существу записаны журналы чата, которые вы оставляете все время открыты. У костра нет возможности «продвигать» важные решения, я думаю, что они потеряны в общем разговоре - но с Google Wave и Wikis вы можете постоянно обрезать нерелевантную или старую информацию. Wikis даст вам больше способностей переформатировать новое.
На самом деле комбинация волны / вики может быть лучшей. Просто используйте волну для ежедневного разговора IM Type, и вытащите важные нити / решения на вики.
Некоторые из практик в XP (Agile) помогают здесь также. Если вы закончите на XP (не просто звонить в свои ежедневные встречи «Scrums»), вы найдете некоторую важную помощь, такую как требования к отслеживанию на картах, которые постоянно обновляются или имеют клиента на сайте, чтобы ответить на важные вопросы. Вся идея XP / Agile основана на том факте, что изменение требований, и эти изменения необходимо отслеживать и что они влияют на график выпуска.
Перед закрытием собрания лицо, ведущее его, должно указать пункты действия и, конечно же, кто будет их выполнять, а также получить согласие назначенного лица или людей. Кто-то должен быть назначен для создания заметок собрания и их размещения. Можно попробовать делать записи по очереди, чтобы каждый иногда это делал. Вы можете попробовать попробовать схватку с мастером (если вы делаете схватку).
Попробуй вики для заметок. В записях собрания должны быть пункты о действиях. У всех пунктов действия должна быть дата, связанная с ними.
Если вы не можете заставить кого-то признать, что запись о том, что вы делаете, важна, у вас серьезные проблемы с разработчиками. Конечно, вы можете сфотографировать доску и ее записи, но это не поможет решить проблемы с чтением и обслуживанием.
Многие программисты (в том числе и я) любят писать документацию.
Я считаю, что важно записывать причину решения на вики или после ИТ-плате. Без него на критических элементах, где могут быть реализованы два варианта, вы увидите, что один разработчик обращается за некоторыми кодом другого разработчика. Оба могут иметь допустимые причины, но это четкое указание на отсутствие связи.
Чтобы избежать таких вопросов, ключевые решения из совещаний необходимо повторить, даже через месяц после этого.
Как для № 1: Как насчет новых идей после IT-It Board? Создайте область, которая очень видима в рабочей среде. Как обсуждаются идеи, удаляемое напоминание о липкой и положена на доску. Держите доску разделены на категории (то есть UI, улучшение производительности и т. Д.). Ответственный участник может взять на себя ответственность за транскрибируйте их на полную вики, когда подробности требует добавления или идея достаточно хорошей, чтобы оно заслуживает некоторых истинных усилий, проведенных в дизайне.
Что касается № 2: Если у вашей команды есть проблемы, оставаясь на цели, то, безусловно, Организатор MTG должен нанять время для подготовки повестки дня, и вынесены разговоры, остаются по теме и настаивают на том, что встреча заканчивается вовремя. Оставьте встречу, зная, кто должен делать то, что.
Как для № 3: Кто-то должен вести заряд, найти примеры видов документации и спецификации, которые вам нравится видеть, и планировать некоторое время с командой, чтобы рассмотреть и обсудить.
Я думаю, что вики или внутренний блог могут быть превосходными для документирования полезных процедур для всех членов команды.
Но еще один интересный момент - это общение между программистами, когда какой-то программист имеет сомнение в реализации. Например: программист не знает, как реализовать некоторые функциональные возможности. Таким образом, он может опубликовать ваши сомнения в «приложении коротких сообщений», например, в Twitter (но с более чем 140 символами). Затем какой-то разработчик, который знает, как решить ее сомнения, может опубликовать решение. Все сообщения будут храниться до тех пор, пока решение не найдено. Итак, все остальные члены команды будут смотреть на это решение в будущем.
Я думаю, что эта схема хорошая, потому что иногда разработчик не любит «тратить много времени», написание поста в блоге или что-то на вики.
Я использую BaseCamp для управления своими проектами. Встречи превращаются в увлекательные мозговые штурмы, затем работа делегируется на сайт.
Почему не просто есть заметки, хранящиеся на этих встречах, в вики, так что другие могут его увидеть, и люди могут изменить его, чтобы уточнить неоднозначность, а затем у вас есть напоминание о том, что было согласовано на.
Затем вы можете принять функции и поместить их в программное обеспечение для отслеживания ошибок, чтобы вы не теряете отслеживание того факта, что есть функции, ожидающие реализации.