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

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

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

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

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

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

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

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

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

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

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

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

1. Структура кода получается намного лучше, чем если бы только один работал над всеми аспектами проекта.
2. Нам не нужно напоминать им о фиксации кода в хранилище и т. Д.
3. Они должны приложить некоторые усилия для тестирования кода друг друга, вместо того чтобы полагаться исключительно на наш специальный QA для этого.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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