Как Вы связываетесь эффективно в малочисленной группе разработчиков? [закрытый]
Я работаю в малочисленной команде (4-5 разработчиков) на единственном проекте. Каждый член нашей команды разрабатывает различную функциональность из нашего проекта, и они очень независимы. На самом деле некоторые участники используют технологии, о которых не знает другой участник. Это - все еще единственный проект и там большая общая бизнес-логика в нем.
Кроме того, большинство участников полностью не знает, какой и как другие делают. Так или иначе нам удается избежать репликации кода (кредиты на нашего руководителя группы, но даже он не абсолютно знает, что происходит). Интересно, что является хорошей практикой для хранения целой команды на дорожке, что продолжается. Например, если кто-то от выходов команды или отсутствует, когда важная фиксация должна быть сделана - для других трудно обработать.
У нас есть политика для проведения обзоров кода, но только руководители группы и один член команды участвуют в нем. Другие "постоянные" участники не принимают участие, там.
Кроме того, у нас есть "newslist" для регистрации-s, фиксировавшей в управлении исходным кодом нашими участниками, но это кажется слишком скучным для контакта с, и похоже, что никто не занимает время для чтения то, что другие только что фиксировали (и это не эффективно, для ярмарки).
Так, интересно, что такое хорошая практика в этом вопросе. Какой опыт Вы имеете? Существует ли решение вообще?
Править: Позвольте мне разъясниться немного. Наша команда работает больше 2 лет, и проекту почти 5 лет. Так, мы не можем запустить гибкую разработку, хотя мы могли Вы некоторые гибкие методы (как стоячая встреча, я нахожу это очень полезным действительно).
Кроме того, наша команда является частью более крупной компании, таким образом, мы установили тимбилдинг методы. И мы не ненавидим друг друга :) - мы - друзья, говорящие об общественной жизни и операциях. Профессиональные переговоры - то, что мы пропускаем.
7 ответов
Standup meetings каждый день (пусть они будут короткими) со всеми присутствующими помогают всем понять, что делают друг друга. Это также помогает менеджеру избавиться от некоторых вопросов управления, предотвращает трэш и оказывает небольшое давление на каждого человека без участия менеджера. (Вы хотите сделать что-то, чтобы завтра утром хорошо выглядеть перед своими коллегами). Некоторые методологии, такие как Scrum, формализуют это.
Проведите обзор кода с разными членами команды. Один из членов команды, не являющийся менеджером, более опытен? Было бы хорошо, если бы этот человек делал обзор кода вместе с другими; он/она поделится своим опытом и будет кем-то другим (помимо менеджера), кто знает большую часть того, что происходит. Нет такого закона, который бы гласил, что при экспертной оценке один человек должен быть более старшим, чем другой, и именно он объявляет код правильным или неправильным. Я думаю, что если два "равных" делают обзор кода, то для начала они должны просто программировать в паре.
Если вы пытаетесь написать качественный код, некоторые части кода могут быть подходящими для парного программирования. Люди из XP говорят, что вы должны делать это постоянно, но я считаю, что иногда это более полезно, а иногда - нет. Например, когда один разработчик опытнее другого, это помогает в наставничестве. Также, когда есть конкретная область, где вы хотите, чтобы знания распространялись. (Только один парень понимает часть системы; в следующий раз, когда нужно будет пересмотреть ее, пусть этот парень сделает это с другим человеком, набирающим текст. ) Кроме того, иногда часть системы является действительно важной, и ее правильная разработка гораздо важнее, чем количество строк кода в минуту. Это отличный случай, когда над проблемой работают две головы, и в итоге два человека имеют глубокие знания этого ключевого кода вместо одного.
Примерно раз в неделю кто-нибудь выступает во время обеда с коротким докладом о чем-то интересном, чем он занимается. Это может вызвать большую дискуссию, способствовать доверию и взаимному уважению, но нас здесь интересует то, что это способствует осознанию.
Цените, поддерживайте и верьте в хороший кодекс. Некоторые магазины (в основном менеджеры) не действительно верят в хороший код, и это приводит к тому, что люди просто вываливают (дрянной) код, даже если разработчики могли бы сделать отличный код. Общение по поводу кода происходит гораздо легче, если разработчики довольны кодом, который они создают, если вы время от времени внедряете новые технологии, и если качественная работа помогает вашей карьере.
И еще о парном программировании. Ключевая часть парного программирования для данного обсуждения заключается в том, что парное программирование способствует совместному коду и перекрестному знанию. Причина, по которой я упоминаю конкретные места, где парное программирование особенно полезно, заключается в том, что политика "мы будем заниматься парным программированием" удается примерно в 10% случаев. В остальных 90% сторонники этой практики не могут дать достаточно хорошего ответа, когда крупный руководитель спрашивает: "Почему все эти люди сидят за одними столами?". Преимущества парного программирования должны быть на 200%+ больше, чем у одного программиста, потому что вы используете двух людей. Выполненное в правильное время, парное программирование может увеличить соотношение "решение/бук"; в неправильное время оно может его уменьшить.
Agile-методики, такие как парное программирование и ежедневные совещания - хорошие формальные способы наладить коммуникацию.
Но похоже, что на самом деле вам нужно просто заставить людей разговаривать друг с другом. Разработчики, как правило, интроверты, поэтому вам придется поработать над этим. Обедайте вместе. Заглядывайте друг другу через плечо. Просите друг у друга совета (даже если он вам не нужен). Спрашивайте друг друга о тех странных технологиях, которые не все понимают. Собирайтесь на интеграционные тесты.
Я нахожусь в аналогичной ситуации на своем рабочем месте. Некоторые члены команды, как вы сказали, очень независимы и не делятся никакими знаниями или практиками с другими членами команды. Я считаю, что это очень непрофессионально и в целом обидно для команды.
Конечно, неизбежно, что одни участники будут более опытными, чем другие, и в мире программирования некоторым членам будет трудно оттолкнуть свое эго в сторону. Лучшее, что можно сделать, - это запланировать встречи и обзоры кода, в которых участвуют все. Создайте центральный сайт документации, где люди могут публиковать определенные методы, которые они используют. Если вы придумали что-то, что, по вашему мнению, может быть полезно для остальной части команды, загрузите это на сайт и отправьте всем электронное письмо. Коммуникация - ключ к успеху.
Тимбилдинг
Вместе готовьте барбекю, играйте в настольный футбол, найдите какую-нибудь командную деятельность помимо работы, которая всем нравится. Это научит людей доверять друг другу, а не быть «независимыми», и умножит на 10 эффект любой другой полезной командной практики, такой как схватка или парное программирование.
Что может помочь вам, так это ежедневные стенд-апы (из agile-разработки). Это занимает всего пару минут, и в основном все участники представляют остальным состояние своей работы, проблемы, с которыми они справляются, и планы на завтра.
Я думаю, что стенд-апы - это хорошее начало для вас. Вы можете найти дополнительную информацию, например, в Martin Fowler - It's Not Just Standing Up: Patterns of Daily Stand-up Meetings
В нашей команде каждую неделю проводятся совещания о ходе работы. Это позволяет узнать, что делают другие и где каждый находится в общей картине.
Иногда за этим следует небольшое светское мероприятие, когда мы делимся домашним пирогом. Имя человека, который принесет торт в следующий раз, записывается в протоколе встречи.
Вот некоторые мысли, которые мне не приходят в голову (небольшая компания, три программиста; раньше работали в команде примерно из 20 человек).
- Какой-то отчет о проделанной работе, чтобы каждый мог видеть, над чем работают все остальные. Встречи "над чем я работаю" работают для некоторых людей, но я их не фанат - они слишком регламентированы, и сидячие встречи для этой цели часто могут превращаться в пустую трату времени и / или или быть склонным к исчезновению в крысиных норках. В моей текущей работе у нас есть задание cron, которое напоминает нам о необходимости отправлять еженедельные электронные письма о ходе работы: в них мы должны сообщать, чего мы достигли, следующие несколько пунктов в нашем списке дел (с оценками, где это необходимо), любые проблемы, которые мы сталкивался.
- Выборочные уведомления о фиксации. Очень немногие люди уделяют больше, чем беглый взгляд, сообщениям о коммитах в масштабе всей компании (даже в моей небольшой команде), но если вы можете дать каждому разработчику возможность отслеживать только те области, в которых они работают, они, вероятно, смогут отслеживать это. (В любом случае, у вас не должно быть слишком много людей, работающих над одним и тем же фрагментом кода одновременно. Слишком много поваров и все такое.)
- Может быть полезна некоторая система продажи билетов для предоставления списка дел. Однако вы должны четко понимать, как этим управлять - в частности, каковы ваши процессы для создания и закрытия заявок.
- Внутренняя документация. Это сложная проблема; некоторые разработчики ненавидят это, некоторые пишут слишком много, а некоторые пишут достаточно.По крайней мере, половина проблемы заключается в индексировании и представлении; Ничего хорошего, если нужная информация будет похоронена на пяти уровнях в непроницаемом документе под названием «Остерегайтесь леопарда». Я большой поклонник вики-сайтов для этой цели, так как они очень просты в использовании.
- Выше определенного размера команды вы можете обнаружить, что для кого-то управление вашей документацией становится постоянной работой. На предыдущем рабочем месте мы потратили деньги на поисковую систему, постоянно сканируя наши интранет-сайты, и это было замечательно.