Парное программирование / Сотрудничество в небольшой компании

20

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

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

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

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

У меня вопрос, был ли кто-нибудь когда-либо в подобной ситуации, и что сработало для них?

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

Мы все работаем в общей области, у разработчиков нет отдельных офисов / кабин.

Райан Уильямс
источник
2
У вас и других разработчиков есть отдельные кабинеты, кабинки или места общего пользования?
@hatchet Мы все работаем в общей области.
Райан Уильямс

Ответы:

12

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

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

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

Недавно мы экспериментировали с этим подходом, когда один из них разработал модели + интеграцию с apis, а другой программист обрабатывал представления и контроллеры . Мы нашли следующие преимущества этого параметра:

  1. Структура кода получается намного лучше, чем если бы только один работал над всеми аспектами проекта.
  2. Нам не нужно напоминать им о фиксации кода в хранилище и т. Д.
  3. Они должны приложить некоторые усилия для тестирования кода друг друга, вместо того чтобы полагаться исключительно на наш специальный QA для этого.
Озаир Кафрай
источник
1
Я тоже над этим подумаю. Мне очень нравится отделение разработки представлений и контроллеров от моделей, потому что это заставляет разработчиков придумывать хороший API для моделей. Чтобы работать одновременно, это также заставляет писать соответствующие тесты.
Райан Уильямс
1
Я решил принять этот ответ, потому что, пройдя его и обсудив его с парой членов команды, я убежден, что лучший способ стимулировать сотрудничество - это разделить роли в одном проекте. Это может не сработать, но, похоже, это лучшее, что я слышал.
Райан Уильямс
7

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

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

Без этой динамики преимущество парного программирования теряется.

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


источник
Я приму ваши мысли во внимание. Немного разобрать и мысленно исправить то, что мы сейчас делаем. Честное чувство, которое у меня есть, немного небезопасно в моей позиции ведущего разработчика. Не потому, что я не чувствую себя комфортно с точки зрения навыков, а скорее потому, что оба наших других разработчика старше меня (один значительно, другой нет), и у одного даже есть опыт пары лет больше. В таком случае традиционные обзоры кода кажутся неловкими, потому что я не хочу казаться, будто я выдыхаю их шею. Опять же, может быть, это то, что я должен сделать.
Райан Уильямс
Еще одна вещь. Как вы думаете, есть меньше преимуществ, чем стоит объединить программу с ними, где, когда я водитель? Это может все еще использоваться как способ указать на лучшие практики, и все еще иметь некоторый вклад и обратную связь относительно того, что я делаю (даже если отношения, несомненно, будут несбалансированными).
Райан Уильямс
Если отношения в парном программировании - это один из способов, я бы посоветовал не привлекать и, возможно, даже немного покровительствовать вашим коллегам. В зависимости от того, как вы смоделируете это, это может легко встретиться как «это то, как я программирую, и это лучший подход». Вы бы на самом деле не называли эту пару программированием, поскольку в ней нет обоих компонентов.
Я думаю, это действительно то, чего я боюсь. Спасибо за мысли. Я собираюсь принять ваш ответ за то, что был первым. (Была и пара других хороших тоже.)
Райан Уильямс
Обзоры @RyanWilliams Code не о том, чтобы «ломать себе голову». Дело не в том, что ты контролируешь их. У нас мы используем ReviewBoard в качестве платформы и комментируем код друг друга . Здесь нет "иерархии". Обучение в этом случае является «неявным». Они учатся на чтении вашего и их кода, на ваших и других вопросах разработчиков и ответах / комментариях на эти вопросы. И они знакомятся с другими частями кодовой базы, что весьма полезно ИМХО.
Йоханнес С.
5

TL; DR : я не думаю, что парное программирование будет работать для вас. Вместо этого вы должны попытаться заставить людей беспокоиться о долговременном качестве их кода и заставить их хотеть найти ответы. Это должно быть сделано неформально.


О культуре и качестве

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

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

По моему мнению, основной вопрос, который вы должны себе задать, это «доволен ли я качеством и деловой ценностью кода, который выпускает моя организация?» и если ответ на этот вопрос отрицательный, вы должны спросить «как мне это изменить?».

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

Парное программирование и микроуправление

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

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

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

  • Предложите им участвовать в SO под соответствующим языковым тегом или опубликовать некоторые фрагменты кода для проверки на Code Review SE. Начните небольшой неофициальный конкурс на предмет того, кто может набрать наибольшее количество повторений в неделю

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

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

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

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

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

Томас Оуэнс
источник
Кажется, это популярное мнение. Мне нравится идея обзоров кода. Но, на мой взгляд, я бы предположил, что с их личностями и уровнями мастерства, это я буду делать рецензирование, а они просто слушают (в основном, не вовлечены). Но, возможно, есть способ привлечь их к участию. Я думаю, я должен подумать об этом.
Райан Уильямс
Кроме того, чтобы быть ясным, я не говорил о парном программировании как о чем-то, что мы делаем все время. Скорее, посвятите ему некоторую значительную, но не огромную часть рабочей недели для более крупных или более сложных функций. (Это частично из практической необходимости. У меня есть свои собственные требования, которые должны быть выполнены.)
Райан Уильямс
2

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

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

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

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

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

dcaswell
источник
Меня беспокоит то, что я не уверен, что они хотят быть «наставниками». Они оба старше меня, а у одного (значительно старше) на несколько лет больше опыта, чем у меня. Но мне нравится вторая часть твоего совета.
Райан Уильямс
И естественно беспокоиться, прежде чем что-то делать - потому что у вас нет информации. По моему опыту, если вы просто сделаете это, люди почувствуют, что вы не волнуетесь, что вы расслаблены, и они пойдут вместе. А потом, если это сработает - продолжайте, а если нет - попробуйте что-нибудь еще.
dcaswell
Возможно, привлечение их к участию в более крупном проекте, который я обычно делал бы сам, могло бы немного облегчить это. Например, мы скоро переделываем нашу CMS. Однако мне понадобится немного времени, чтобы привыкнуть к этой идее.
Райан Уильямс
0

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

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

Что я обнаружил, так это то, что ПРАВИЛЬНЫЕ люди со временем (в небольшой команде) подбирают и синхронизируют с тем, что делают другие. Не нужно микроуправлять или рассказывать кому-то, что они все время делают неправильно.

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

Райан Уильямс
источник