Автор: Сергей Андржеевский · ScrumTrek
Сергей Андржеевский выступал на Ag;)eDays 2011 — одной из ранних российских Agile-конференций. Доклад старый, но вопрос, который он разбирает, не устарел: как работают XP-практики в условиях, когда команда разделена географически и работает на внешнего заказчика.
Офшорный проект — это специфический контекст. Разные часовые пояса, заказчик, который не сидит рядом, контрактная модель, которая создаёт стимулы скрывать проблемы, а не решать их. XP создавался для команды в одной комнате с заказчиком рядом. Андржеевский рассказывает, что из XP работает в офшорном контексте, что требует адаптации, а что — предположение, которое офшор разрушает принципиально. Центральный тезис: парное программирование и TDD в офшорном контексте — это не способ быстро работать, это способ поддерживать качество без прямого контроля. Заказчик не видит код — он видит результат. Дисциплина XP-практик создаёт доверие через предсказуемость результата.
Кому смотреть: тимлидам и менеджерам в распределённых командах, которые хотят понять, какие инженерные практики заменяют «управление через присутствие» в удалённом контексте.
Из этого можно взять в работу: если у тебя распределённая команда и ты используешь парное программирование — проверь, решаешь ли ты им задачу координации (кто что делает, где риски) или только задачу обучения. Это разные цели с разной оптимальной частотой сессий.
Андржеевский разбирает XP-практики по применимости к офшорному контексту. Парное программирование: в офшоре работает, но синхронизация важнее — пары должны быть стабильными, а не случайными. Хаотичная ротация пар в удалённой команде создаёт больше накладных расходов, чем пользы. Оптимум — стабильные пары с ротацией раз в несколько дней.
TDD: работает без адаптации, но требует жёсткого соглашения команды. В офшоре нет тимлида, который видит код каждый день. TDD + CI становятся «глазами» заказчика: если сборка зелёная — есть уверенность. Если красная — проблема видна немедленно. Это важнее, чем в co-located команде.
Непрерывная интеграция в офшоре приобретает дополнительный смысл. Разные часовые пояса означают, что заказчик не видит процесс в реальном времени. Зелёный CI в конце каждого дня — единственное наблюдаемое свидетельство прогресса. Частота интеграции (несколько раз в день) снижает риск «большого взрыва» при слиянии веток.
Коллективное владение кодом в офшорном проекте принципиально важно. Если знание о модуле сосредоточено у одного разработчика, и он недоступен (другой часовой пояс, заболел, уволился) — проект останавливается. Ротация пар и коллективное владение — страховка от этого.
Где XP не адаптируется: «заказчик на месте» (on-site customer). XP предполагает, что представитель бизнеса доступен в реальном времени. В офшоре это невозможно структурно. Андржеевский говорит, что это компенсируется через более детальное планирование итераций и письменную документацию критичных решений — то, от чего XP в теории пытается уйти.