Идеи для работы с товарищем по команде, не следуя определенным в команде стандартам? - PullRequest
5 голосов
/ 11 августа 2010

Работая в командной среде, как бы вы справились с разработчиком, который отказывается следовать определенным в команде стандартам?

1) Разработчик на младшем уровне

2) Разработчик находится на уровне сверстников

3) Разработчик на старшем уровне

Я знаю, что это наводит на мысль, но я чувствую, что это принесет пользу разработчикам, сделав их более профессиональными Спасибо!

Ответы [ 4 ]

6 голосов
/ 11 августа 2010

1) Разработчик находится на младшем уровне - Ментор;будь добрым и нежным.Объясните необходимость стандартов в целом, а затем объясните необходимость конкретного стандарта, который не соблюдается.Делайте это с открытым сердцем;если вы не можете оправдать стандарт, то, возможно, он не должен быть стандартом?

2) Разработчик находится на равноправном уровне - это должно быть достаточно просто - если вы можете сохранить его техническим, а не позволить, раствориться в столкновении личностей.Опять же, если вы можете оправдать это, это, вероятно, должно быть стандартом, но если у него есть столь же убедительный аргумент против, то, возможно, нет.Однако не признайте, что не должно быть никаких стандартов.Спросите его о предложенном стандарте, чтобы заменить тот, который ему не нравится.Если он не подчинится, то обострится.Если вам не нравится это, тогда поставьте это на голосование / обострение.Старайтесь избегать эскалации, но старайтесь убедиться, что является стандартом.

3) Разработчик находится на высшем уровне Попробуйте рассуждать.Слушай внимательно, он может быть прав.Если сомневаешься, то ставь его на голосование / наращивай.

Предостережение: стандарты хороши (imo, абсолютно обязательны, но ymmv), но их трудно «обеспечить», если они не достигнуты консенсусом.

Исключение: «ковбойские кодировщики» должны быть набиты hard ;нет ожидания.

Не расстраивайтесь из-за «татлинга» с боссом.Когда дело доходит до ковбойского кодера, тогда следуйте девизу ковбоя «эта команда недостаточно велика для нас обоих»;Либо он перестанет ковбойствовать, либо одному из вас придется убираться из Доджа.

2 голосов
/ 11 августа 2010

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

Основные приемы в обращении с людьми

  1. Дон 't критиковать, осуждать или жаловаться.
  2. Дайте честную и искреннюю признательность.
  3. Пробудите в другом человеке страстное желание.

Шесть способов сделать людей похожимиВы

  1. По-настоящему заинтересовались другими людьми.
  2. Улыбайтесь.
  3. Помните, что Имя человека для него - самый сладкий и самый важный звук на любом языке.
  4. Будь хорошим слушателем.Поощряйте других говорить о себе.
  5. Говорите с точки зрения интересов другого человека.
  6. Заставьте другого человека чувствовать себя важным и сделайте это искренне.

ДвенадцатьСпособы привлечения людей к вашему образу мышления

  1. Избегайте споров.
  2. Проявляйте уважение к мнению другого человека.Никогда не говорите кому-то, что они не правы.
  3. Если вы не правы, признайте это быстро и решительно.
  4. Начните по-дружески.
  5. Начните с вопросов, которые другой человек ответитответьте да.
  6. Пусть другой человек говорит.
  7. Пусть другой человек почувствует, что идея принадлежит ему / ей.
  8. Постарайтесь честно увидеть вещи другого.точка зрения человека.
  9. Сочувствуйте другому человеку.
  10. Обращайтесь к благородным мотивам.
  11. Инсценируйте свои идеи.
  12. Бросьте вызов и дайтене говорите отрицательно, когда человека нет, говорите только о положительном.

Будьте лидером: как изменить людей, не обижаясь и не вызывая обиды

  1. Начните с похвалыи искренняя благодарность.
  2. Косвенно обращайте внимание на ошибки других людей.
  3. Сначала говорите о своих ошибках.
  4. Задавайте вопросы вместо того, чтобы прямо отдавать приказы.
  5. Пусть другой человек спасет лицо.
  6. Похвалите каждое улучшение.
  7. Дайте им хорошую репутацию, чтобы соответствовать.
  8. Поощряйте их, чтобы их ошибки казались легко исправляемыми.
  9. Сделайте так, чтобыдругой человек рад сделать то, что вы предлагаете.
1 голос
/ 11 августа 2010

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

0 голосов
/ 24 августа 2010

Мы используем политики TFS и Code Check-in для обеспечения соблюдения стандартов кода. Другие ответы, с которыми я полностью согласен для людей, участвующих в этом. Для некоторых стандартов кодирования, таких как стандарты именования переменных, вы можете потратить крошечное время (возможно, этот разработчик может написать их) и написать их. Если вы включите их в процесс сборки, то часть проверки сборки включает проверку исходного кода на соответствие стандартам. Мы используем MSBuild с Visual Studio 2008, и он прекрасно работает. Это несколько поможет, когда система будет разработана для обеспечения соблюдения стандартов, поскольку иногда сложнее спорить с системой сборки. Кроме того, полезно, чтобы сборки воспринимали эти нарушения как ошибки в visual studio, а не просто как предупреждения для дальнейшего применения. Прежде всего, часть стандартов «почему» наиболее важна для разработчиков любого уровня. Если они понимают, почему стандарты полезны, и понимают правильный форум / возможность (ежемесячное собрание разработчиков?), Где они могут высказывать доводы против определенного стандарта, мы надеемся, что они могут начать следовать им вместе с успешной командой.

...