Принципы групповой работы

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

Коллективное владение кодом

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

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

Никто из программистов не является владельцем никакой части кода. Каж& дый из участников имеет доступ ко всему коду и может модифицировать его по мере надобности.

Когда принимается такая культура, команда защищает себя от мел% ких царьков, правящих своими островками кода. Если некто написал код, на который никому нельзя посмотреть, то что будет, когда этот человек уйдет из проекта? Потеря специалиста в какой%то области соз% даст серьезные трудности в работе команды.

Не нужно питать к своему коду родительских чувств, охранять его и лелеять. Вместо этого должно быть здоровое отношение к интересам команды. Чувство собственника можно попробовать заменить чувст% вом управляющего. Управляющий не владеет тем, что находится под его попечением; они назначаются, чтобы блюсти интересы владельца. Основная обязанность управляющего участком кода – это содержание его в исправности, уход и охрана границ. Обычно все изменения осуще% ствляет управляющий, но их проведение можно доверить некоторым участникам команды с его итоговой проверкой. Это конструктивное от% ношение к своему коду, которое должно пойти на пользу команде.

Уважайте чужой код

Даже в просвещенной среде разработчиков, где отсутствует личная собственность на код, нужно уважительно относиться к коду, напи% санному другими лицами. Не нужно ничего в нем менять произволь%

но. Это особенно важно, если с кодом работают в данное время. Нельзя модифицировать код, с которым работает другой программист; это вносит невероятное смятение.

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

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

Нормы кодирования

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

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

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

Определите, что считать успехом

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

Нужно определить критерий успеха, чтобы команда знала, как он вы% глядит и как его достичь. Что можно считать успехом для вашего те% кущего проекта? Своевременный выпуск продукта, достижение задан% ного уровня качества,1 удовлетворенность клиента, получение опреде%

1А как его измерить?

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

Установите ответственность

У всех эффективных команд есть четкая структура и ясные обязанно% сти. Это не обязательно означает наличие строгой иерархии и несколь% ких уровней управления. Структура команды должна быть ясной и по% нятной. Должно быть очевидным:

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

•Где нужно остановиться и чья голова полетит, если становится яс% но, что проект провалился?

•Каковы обязанности членов команды и перед кем они отчитыва# ются? За что они персонально отвечают, чего от них ждут и кому они подчиняются?

Избегайте истощения

Команда не должна получать нереальные задания. Проверьте, что про% ект, за который вы принимаетесь, реально осуществим – ничто так не обескураживает, как понимание того, что провал неизбежен.

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

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

Давайте людям разные задания; не заставляйте никого заниматься од% ними и теми же задачами, пока им это не наскучит и они не потеряют интерес. Дайте каждому возможность учиться и овладевать новыми навыками. «Перемена работы – лучший вид отдыха». Даже если нет никакой возможности снизить темпы работы, некоторое разнообразие поможет избежать усталости.