Однако этот подход работает только при наличии ответственных разработчиков и сильного руководства. Создать пул автономных групп и позволить им разбалтываться в отсутствие руководства – это кратчайший путь к катастрофе. Проекту необходимы как минимум два руководителя – один технический, другой административный. Технический руководитель определяет философию и стиль разработки, распределяет обязанности между группами и является арбитром в неизбежных «дискуссиях» между членами команды. Он также осуществляет контроль за ситуацией в целом, стараясь найти ненужную общность задач между группами, которая снижает ортогональность общих прилагаемых усилий. Административный руководитель, или руководитель проекта, намечает ресурсы, необходимые группам, контролирует ход выполнения работ, отчитывается о проделанной работе и помогает в определении приоритетов с точки зрения потребностей бизнеса. Административный руководитель может действовать и в роли полномочного представителя команды при общении с внешним миром.

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

Подобная организация команды напоминает старую концепцию "бригады главного программиста", впервые описанную в 1972 г. [Ваk72].

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

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

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

• Энтропия в программах

• Суп из камней и сварившиеся лягушки

• Приемлемые программы

• Общайтесь!

• Пороки дублирования

• Ортогональность

• Проектирование по контракту

• Несвязанность и закон Деметера

• Вездесущая автоматизация

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

• В следующий раз, когда вы начнете работать над проектом, постарайтесь убедить коллег в том, что проекту необходим брэнд. Дайте вашей организации время, чтобы привыкнуть к этой мысли, и затем проведите быстрый аудит, чтобы увидеть, изменило ли наличие брэнда что-нибудь как внутри команды, так и в общении с внешним миром.

• Командная алгебра: В школе мы решали задачи, наподобие этой: "Если четырем рабочим требуется 6 ч на то, чтобы выкопать канаву, то сколько времени потребуется на это восьми рабочим?" Какие факторы из реальной жизни повлияют на ответ задачи: "Если четырем программистам требуется 6 месяцев на разработку приложения, то сколько времени потребуется на это восьми программистам?" Назовите число сценариев, в которых время на разработку действительно сокращается.

На заре автомобильной эры инструкция по запуску автомобиля «Форд-Т» составляла две с лишним страницы. В современных автомобилях достаточно лишь повернуть ключ – процедура запуска является автоматической и надежной. Водитель, действующий по инструкции, может «залить» свечи зажигания, а автоматический стартер подобного не допустит.

Хотя информатика все еще напоминает автопромышленность времен выпуска модели «Форд-Т», мы не можем позволить себе в обычной работе раз за разом выполнять набор инструкций, расположенный на двух страницах. Неважно, что это – процедура сборки и выпуска готовой версии, рассмотрение текста программы или же любая повторяющаяся задача, возникающая в ходе проекта, – все это должно выполняться автоматически. Возможно, нам придется изготовить стартер и топливный инжектор "с нуля", но как только это будет сделано, с этого момента будет достаточно лишь повернуть ключ зажигания.

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

Однажды мы посетили фирму-заказчик, где все разработчики использовали одну и ту же интегрированную среду разработки. Их системный администратор снабжал каждого разработчика набором инструкций по установке добавочных средств для этой среды. Эти инструкции занимали много страниц – 'щелкни мышью здесь, прокрути туда, отбуксируй это, щелкни здесь мышью два раза, повтори".

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

В отличие от компьютеров, люди не обладают повторяемостью в своих действиях. Мы этого от них и не ждем. Сценарий оболочки или пакетный файл выполнят те же самые инструкции, в том же порядке, раз за разом. Он может отслеживаться системой управления исходным текстом, так что возможно изучать изменения в процедуре и по прошествии времени ("но ведь она всегда работала… ").

Другим излюбленным средством автоматизации является cron (или «at» в системе Windows NT). Он позволяет планировать периодический прогон задач без участия пользователя – обычно этот прогон делается ночью. Например, представленный ниже файл crontab указывает, что команда nightly, используемая в проекте, должна запускаться каждый день в 00:05, что процедура резервного копирования backup должна запускаться в 03:15 по будням и что команда expense_eports должна выполняться в полночь первого числа каждого месяца.

С помощью cron можно планировать процедуры резервного копирования, сопровождение web-сайтов и любых других операций, которые нужно проводить без участия пользователя, т. е. автоматически.