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

Часть 1: Коллективная собственность и сотрудничество

Каждая организация и каждый программный проект имеют свою собственную жизнь и характер. Когда разработчик программного обеспечения «летает в одиночку», это может быть рискованной ситуацией. Если этот разработчик уходит в другую компанию, у него продолжительная болезнь или он занят другими проектами, может быть сложно (т. е. дорого) взять на себя работу другого разработчика. В здоровой организации по разработке программного обеспечения есть разработчики, которые чувствуют коллективную ответственность за программное обеспечение, которое они пишут. Это не «код Боба» или «код Сьюзан», это «наш код».

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

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

  • Оценка: F
    Существуют правила (часто неписаные), определяющие, какие разработчики могут общаться с какими другими разработчиками. Существует четкое разделение между областями программных проектов (или даже самими проектами) и тем, кто ими «владеет». Разработчики расстроятся, если вы спросите не того человека не о том районе. Совещания со всеми разработчиками в одной комнате напряжены.
    Рядом с офисами разработчиков жутко тихо, и вы почти уверены, если попросите новичка-программиста, чтобы его код проверил самый старший разработчик в группе. команда, он может получить заклинание. Любые пустые разговоры между разработчиками явно и намеренно лишены какого-либо технического содержания.
  • Оценка: D
    Ваши разработчики иногда вместе обедают без принуждения. Они помогают друг другу ненадолго, но каждый сеанс помощи занимает менее пяти минут. Всегда существует четкое различие между «помощником» и «помощником». Помощник стоит в кабинете/кабинке помощника и не сидит. Если вы предложите принести дополнительный стул и продлить сеанс помощи до часа, разработчикам станет очень неудобно и они начнут оправдываться.
  • Оценка: C
    «Архитекторы программного обеспечения» каким-то образом контролируют процесс написания кода и используют такие термины, как «стандарты» и «лучшие методы». Сеансы помощи длиннее (до 30 минут или около того), но они почти всегда включают одного из вышестоящих лиц, и сеансы по-прежнему имеют отношения помощник-помощник. У архитекторов также есть «особые» области программного обеспечения, которыми они владеют, потому что оно «слишком сложно», чтобы обучать другого разработчика. Любой разговор о кулерах для воды, связанный с программированием, затрагивает лишь несколько архитекторов (если они вообще есть). Существует четкая динамика «мы против них», и архитекторы обычно единственные, кто говорит на собраниях. Коллективная собственность по-прежнему отсутствует: собственность есть у архитекторов, и они следят за тем, чтобы об этом знали все.
  • Оценка: B
    Обычно можно увидеть, как разработчики в течение длительного времени сидят за рабочими столами друг друга и вместе программируют. Вы видите, как они торгуются, кто работает с клавиатурой на протяжении этих сессий. Отношения помощник-помощник отсутствуют: это равные. Похоже, что им наслаждается совместная работа, и благодаря этим занятиям они достигают большего. Могут быть некоторые разногласия и ссоры, но мужайтесь! Это хороший знак: они спорят, потому что им небезразлично то, что они делают. Формируется коллективная ответственность.
    Совещания менее напряженные, но более энергичные, и иногда их труднее контролировать. «Право собственности» какого-либо одного разработчика на какую-либо область проекта начинает испаряться, но в меньшей степени все еще существует.
  • Оценка: A
    Разработчики редко работают в одиночку. Сеансов парного программирования в течение рабочего дня предостаточно, а разногласия сведены к минимуму. Соавторы часто меняют управление клавиатурой.
    С совещаниями справиться легко, за исключением жуткого способа, которым разработчики заканчивают предложения друг друга, как будто они только что сошли со съемок «Сияния». У кулера с водой они общаются на языке, отдаленно напоминающем английский, но вы не можете понять на нем больше нескольких слов. Любой конкретный разработчик, который болеет или находится в отпуске, создает незначительные (если вообще какие-либо) заметные нарушения.

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

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

Далее Часть 2: Техническая практика.