Пути улучшения связи между членами на программное обеспечение команды

Question

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

1. Во время неформальной беседа о проекте мозговой искровой момент становится новой функцией/требованием. Эти «надстройки», кажется, проваливаются через трещины, или детали становятся нечеткими через некоторое время.

2. В совещаниях, на которых цели или задачи четко не делегированы, участники, участвующие в совещании, имеют разные отчеты о том, что на самом деле обсуждалось.

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

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

Спасибо за помощь!

Answer 1

Придерживайтесь повестки дня. Оставайтесь на связи. Когда что-то начинает отклоняться от курса, либо планируйте другое собрание, либо отправляйте его по электронной почте после собрания.

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

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

Wiki. Wiki. Wiki. Вся информация о «племенных знаниях», полезная для команды, должна войти в вики. Как настроить среды разработки, общие советы по отладке и т. Д.

Answer 2

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

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

Answer 3

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

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

Если вы не можете заставить кого-либо признать, что запись того, что вы делаете, важно, у вас есть серьезные проблемы с вашими разработчиками. Конечно, вы можете сфотографировать доску и ее заметки, но это не поможет проблемам чтения и обслуживания.

Многие программисты (включая меня), как и письменную документацию, довольно много.

Answer 4

Что касается №1: Как насчет новых идей? Создайте область, которая хорошо видна в рабочей среде. Когда обсуждаются идеи, удалите напоминание о записке на липкой и положите на доску. Держите доску разделенной на категории (например, пользовательский интерфейс, повышение производительности и т. Д.). Ответственный член может взять на себя ответственность за их расшифровку до полной вики, когда требуется детализация, или идея достаточно хороша, чтобы заслужить какое-то истинное усилие, затраченное на дизайн.

Что касается №2: Если у вашей команды есть проблемы с пребыванием в объекте, то определенно организатор mtg должен занять время, чтобы подготовить повестку дня и выговорить разговоры на тему и настаивать на том, чтобы встреча заканчивалась вовремя. Оставьте встречу, зная, кто должен что-то делать.

Что касается №3: Кто-то должен возглавить заряд, найти примеры видов документации и спецификаций, которые вам нравятся, и запланировать некоторое время с командой для рассмотрения и обсуждения.

Answer 5

Я нахожу, что важно зафиксировать причину принятия решения на Wiki или после него. Без него, в критических пунктах, где могут быть реализованы два варианта, вы увидите, что один разработчик изменит код другого разработчика. Оба могут иметь веские причины, но это явное указание на отсутствие связи.

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

Answer 6

Документируйте все, а не по электронной почте!

Используйте что-то с историей. У меня возникло соблазн использовать Google Wave для отслеживания проекта «Разработка» (изменение требований, интерпретации и т. Д.). Вики также будут работать, но имеют более высокий барьер для редактирования и могут обновляться меньшим количеством людей. Campfire также является хорошей методологией.

Новые методологии (Campfire/Wave) - это, по сути, записанные журналы чата, которые вы оставляете открытыми все время. Campfire не имеет возможности «продвигать» важные решения, я думаю, что они заблудились в общем разговоре, но с Google Wave и Wikis вы можете постоянно обрезать ненужную или старую информацию. Wikis даст вам больше возможностей переформатировать новое.

На самом деле комбинация Wave/Wiki может быть лучше всего. Просто используйте волну для ежедневного разговора по типу IM и тяните важные темы/решения на Wiki.

Здесь также помогут некоторые из практик в XP (Agile). Если вы идете FULL ON xp (не просто называя ваши ежедневные встречи «Scrums»), вы найдете важную помощь, например, отслеживание требований к постоянно обновляемым картам или наличие клиента на сайте для ответа на важные вопросы. Вся идея XP/Agile основана на том, что требования меняются, и эти изменения необходимо отслеживать и что они влияют на график выпуска.

Answer 7

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

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

Я думаю, что эта схема хороша, потому что иногда разработчик не любит «тратить много времени» на запись сообщения в блоге или что-то на wiki.

Answer 8

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

Answer 9

Если мы говорим о том, чтобы оставаться на связи таким образом, чтобы заменить голос и текст, ознакомьтесь с http://CircleHubb.com. Мало того, что вы можете общаться между членами одной группы, но вы можете делиться документами PDF и Word, фотографиями и видео. Вы также можете сделать свою группу частной или общедоступной. Их приложение должно скоро появиться.