Программист-прагматик. Путь от подмастерья к мастеру

Хант Эндрю

Лучшие проектные команды обладают ярко выраженной индивидуальностью. Люди ожидают встреч с ними, поскольку знают, что увидят хорошо подготовленную презентацию, от которой всем станет лучше. Производимая ими документация отличается четкостью, точностью и последовательностью. В такой команде нет разноголосицы [44] . У нее даже может быть чувство юмора.

В маркетинге существует простой трюк, помогающий командам взаимодействовать как одно целое: создание брэнда. Когда вы начинаете некий проект, придумайте имя для проектной команды, в идеале – нечто из ряда вон выходящее. (В прошлом мы называли проекты в честь попугаев-киллеров, охотящихся на овец, оптических обманов и мифических городов.) Потратьте полчаса

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

44

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

Не повторяйте самого себя

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

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

Если проект слишком велик для одного-единственного библиотекаря (или если никто не хочет брать на себя его функции), назначьте нескольких человек "фокусными точками" различных функциональных аспектов работы. Если кто-то хочет обговорить тему обработки даты, он знает, что по этому вопросу нужно обращаться к Мэри. Если же речь идет о базе данных, то следует обращаться к Фреду.

И не забудьте о значении программного обеспечения для коллективной работы и локальных телеконференциях в сети Usenet для обмена информацией и создания архивов вопросов и ответов.

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

Традиционная организация команды основана на устаревшем методе создания программного обеспечения, известного под названием "метода водопада". Отдельным членам команды назначаются роли, основанные на их должностных обязанностях. В команде имеются бизнес-аналитики, проектировщики, программисты, тестировщики, технические писатели и т. п. [45] В этом случае существует явная иерархия – чем ближе вы допущены к конечному пользователю, тем выше ваше положение.

45

В книге "The Rational Unified Process: An Introduction" [Kru98] автор выделяет 27 отдельных ролей в пределах проектной команды!

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

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

Подсказка 60: Организуйте команду на основе функциональности, а не должностных обязанностей

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

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

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

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

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

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

Автоматизация