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

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

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

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

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

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

Традиционная организация команды основана на устаревшем методе создания программного обеспечения, известного под названием «метода водопада». Отдельным членам команды назначаются роли, основанные на их должностных обязанностях. В команде имеются бизнес-аналитики, проектировщики, программисты, тестировщики, технические писатели и т. п. [45] В книге «The Rational Unified Process: An Introduction» [Kru98] автор выделяет 27 отдельных ролей в пределах проектной команды! В этом случае существует явная иерархия – чем ближе вы допущены к конечному пользователю, тем выше ваше положение.

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

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

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

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

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