1. Как нужно общаться при удаленной работе?

Во-первых, почти все общение ведется голосом, чтобы быстрее решать вопросы и лучше понимать друг друга.

Во-вторых, если сообщение касается всех, мы пишем письма в общий список рассылки.

В-третьих, раз в неделю мы проводим звонок-конференцию, но не просто с разговором, а с работой в EtherPad, где мы пишем ссылки, показываем примеры кода и делаем скетчи кода, если необходимо.

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

 

2. Как заниматься парным программированием и делать обзоры кода?

Архитектор не пишет общую архитектуру программы, а ищет подходы и средства решения определенных задач. Инициатива отдается рядовым разработчикам, архитектор взвешивает варианты и принимает окончательные решения.

Мы не пишем «почеркушек» или псевдокода. Часто идеи из псевдокода или высказанные словами просто не работают. Такие идеи — всего 20% усилий, остальные 80% в том, что кажется рутиной. Именно здесь и нужен напарник. Мы садимся, пишем реальный код и коммитим его.

Обзор кода вместо простого чтения диффов мы делаем так: автор нового кода объясняет ведущему разработчику (архитектору), что он написал. Именно он лучше всех знает свой код, но во время обзора он может взглянуть на него более критически и заметить свои ошибки. Задача архитектора — замечать нестыковки и руководить их исправлением.  Мы поощряем сообщения о том, что в собственном коде людям не нравится, и пытаемся решить это. Все правки делаются тут же, вдвоем. При этом если один человек пишет, другой наблюдает и замечает опечатки. Аналогичный принцип используется в работе экипажей в коммерческой авиации.

 

3. Инструменты

Распределенная система управления версиями (Mercurial, Git) с несколькими плагинами. Buildout для упаковки всего проекта и зависимостей — чтобы у всех разработчиков, независимо от конфигурации системы, проект работал одинаково. EtherPad для скетчей кода. Для парного программирования — Unix Screen + Vim/Emacs (мы пробовали Eclipse и еще десяток программ, у всех недостаточный функционал). BuildBot для проверки состояния проекта (pyflakes, jslint, автозапуск тестов). Трекер — PivotalTracker. Свой сервер для зависимостей. Множество дебаггеров. Makefile для часто повторяющихся действий (обновить репозиторий, перестроить базу данных, перепаковать проект).

В Mercurial мы пользуемся интеграционными ветками, чтобы проверить, как будет вести себя проект после вливания новой ветки в основную.