Sun 11 Feb 2007
Прогулки по граблям, часть 2
Posted by Alex Lebedev under менеджмент, процесс разработки
[6] Comments
Продолжение предыдущей части, где речь шла о печальных последствиях планирования только на уровне деталей, без видения целого.
Сегодня давайте поговорим о том, как надо и как не надо осуществлять ротацию программистов в команде. Под ротацией имеется в виду периодическая смена исполнителей основных направлений, проводящаяся так чтобы сократить количество областей проекта, где разбирается только кто-то один.
Когда ротация нужна
Нужно повысить взаимозаменяемость членов команды. Никто не хочет, чтобы при болезни или увольнении разработчика приходилось с нуля разбираться в критически важной области проекта. В идеале, в проекте вообще не должно быть мест, в которых разбирается только один член команды. Если это так, то несчастные случаи и кадровые изменения становятся просто неприятным событием, а не причиной провала проекта.
Ротация – один из самых эффективных способов достижения этой цели. Помните, что невозможно сделать из одного человека точную копию другого - и все будет замечательно
Ротация как способ расширения сознания. Решение сложных технических задач, как правило, требует от разработчика полной концентрации. Как следствие, любой разработчик склонен постепенно углубляться в детали своего куска и терять общее видение проекта. Переключение на новые, непохожие задачи наглядно покажет человеку, что проект состоит не только из написания кода и не только из одного знакомого ему компонента. Еще бывает полезно переключить человека на незнакомую и сложную область – отличное лекарство от завышенного самомнения.
Способствовать установлению взаимоотношений в команде. Если вы имеете дело с новой и еще не сработавшейся командой, то в первое время очень полезно «потасовать» людей, чтобы у каждого был шанс вместе поработать и узнать поближе как можно большее количество коллег.
Хочу еще заметить, что для достижения каждой из перечисленных целей оптимален свой режим ротации. Например, для повышения взаимозаменяемости люди должны работать вместе гораздо дольше, чем для установления или улучшения взаимоотношений. Поэтому, выбирая режим ротации, подумайте о том, какой цели вы хотите достичь в первую очередь.
Когда ротация не нужна
Попробую описать несколько типичных ситуаций, когда ротация - далеко не лучшее из решений.
В команде не делается рецензирование кода (code review). Если у вас не делается регулярного рецензирования кода, то я настоятельно рекомендую забыть о ротации и заняться рецензированием. Если вы не проводите рецензирование кода, это означает что:
У вас наверняка нет общих для команды соглашений о стиле кода. Можете смело предположить, что два любых программиста, начав работать вместе, половину времени проведут в спорах о том, как должны быть отформатированы комментарии и объявления функций.
В вашей системе есть куча отвратительного кода, о которой никто не знает. Этот код был написан в дикой спешке без особой заботы о форматировании, понятных именах переменных и комментариях. Автор, вероятно, не понимает, что код плох, а никто другой его и не видел. Можно попытаться обнаружить такие куски кода с помощью ротации, но ваши шансы не очень высоки. Да и менять написанный пару месяцев назад код гораздо сложнее, чем написанный вчера.
Ваши разработчики гораздо хуже знают код друг друга. Начав работать вместе, они будут вынуждены потратить кучу времени на объяснение друг другу вещей, которые при проведении регулярного рецензирования кода знал бы каждый.
И попытки заменить постоянно рецензирование кода периодической ротацией исполнителей не приведут ни к чему хорошему.
Попытка улучшить дизайн системы с помощью ротации. Уточню что словом “дизайн” я называю архитектуру системы и интерфейсы, использующиеся для взаимодействия компонент. Бывает, что для оценки дизайна какого-то компонента на соответствующее направление переводят нового человека, чтобы обеспечить «взгляд со стороны» и исправить потенциальные недочеты. Только вот уже поздно. Компонент уже реализован и протестирован. В результате может оказаться, что проще всего выкинуть и написать заново заметную часть кода.
Да, этот способ улучшения дизайна работает. Но все же гораздо эффективнее обсуждать и рецензировать дизайн на стадии проектирования или реализации прототипа, а не когда уже все готово. Да, рефакторинг - замечательная практика и он поможет вам постепенно преобразовать к лучшему любой существующих код, не выкидывая при этом крупных кусков. Однако спроектировать качественный дизайн сразу - гораздо менее затратно.
Ротация ставит под удар качество критически важного компонента. Ротация и все получаемые в результате положительные эффекты – вещь гораздо менее важная, чем успешное завершение проекта. Поэтому имеет смысл выделить критически важные для успешного завершения проекта компоненты и следить за тем, чтобы над ними все время работали наиболее компетентные разработчики.
В результате ротации люди, которые не переносят друг друга, вынуждены работать вместе. Если вы знаете о напряженных отношениях между какими-то членами команды, то имеет смысл держать их подальше друг от друга. Старайтесь корректировать свои планы ротации так, чтобы не провоцировать излишнюю напряженность в коллективе.
