Лекция КС ЭК.

Функциональные роли в коллективе разработчиков 1

ВОПРОСЫ ДЛЯ ПРОВЕРКИ 12

Ключевые роли коллектива разработчиков и задача определения кадровых ресурсов проекта 14

Функциональные роли в коллективе разработчиков

Определяются функции, выполняемые сотрудниками в ходе развития проекта и типичные для программных проектов роли разработчиков; указы­вается, какие роли могут совмещаться при выполнении проекта. Представле­ны решения обсуждаемых вопросов, предлагаемые компанией Microsoft и Центром объектно-ориентированных технологий IBM.

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

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

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

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

Не следует путать функции, которые предписано выполнять разра­ботчику как исполнителю определенной роли, с поручениями в проекте. Поручения — это разовые или систематические задания, из которых обычно и складываются действия, необходимые для выполнения той или иной функции. Если для функции определен регламент выполнения по­ручений, т. е. последовательность выполнения составляющих ее поруче­ний не требует дополнительных разъяснений для исполнителя, то такая функция называется технологической. В случае нетехнологической функ­ции сотруднику, который выполняет соответствующую роль, приходится самому выстраивать нужную последовательность. Иными словами, тех­нология здесь уступает место ремеслу.

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

Таким образом, в рамках любого проекта возникает задача повы­шения квалификации сотрудников. Для различных схем ведения проектов эта задача решается по-разному. Крайнюю точку зрения на про­блему соответствия квалификации работников требованиям проекта отражает идея экстремального программирования [3], когда использует­ся неформальная организация группы исполнителей проекта без чет­кого распределения ролей, а значит, и обязательств сотрудников. В этом случае провозглашается принцип, когда каждый в группе делает то, что он умеет делать лучше всего. И хотя все функции, которые должны выполняться, остаются, создается впечатление, что в группе исполнителей проекта исчезают роли. В результате возможны пробе­лы в разработке, в частности при анализе и декомпозиции проектиру­емой системы. Чтобы этого избежать, разработчики должны пони­мать, какую абстрактную роль они исполняют в каждый конкретный момент, выполнение каких проектных функций необходимо сейчас, как связаны между собой работы, как должны распределяться ресур­сы. Словом, они должны обращать внимание на выполнение распре­деленных по группе менеджерских функций. И даже в этом случае схему экстремального программирования можно рекомендовать лишь для слаженных групп исполнителей с высоким уровнем коллективной ответственности.

Функции, выполняемые разработчиками в проекте, подразделяют­ся на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями. Часто неудачи проекта возникают из-за того, что ме­неджер не учитывает важность выполнения организационных функций. Так, обычно проектное задание фиксирует лишь то, что нужно предъяв­лять заказчику в качестве результатов. С точки зрения результатов про­сто не требуется знать, например, как организована передача проектных материалов между разработчиками, какая процедура отчетности преду­сматривается, но игнорирование задач реализации информационных потоков в проекте может привести к хаосу, что в конечном итоге отра­зится и на результатах.

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их спи­сок часто становится непомерно велик (иллюстрацией тому может слу­жить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмер­ное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управле­нием.

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

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответ­ственностью за выполняемые задания — так называемые проектные группы [44]. Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополня­ют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профес­сиональной подготовки, хотя и в разных областях индивидуальной спе­циализации. Провозглашается равноправие членов группы и коллек­тивная ответственность за выполняемые задания: проектная группа — команда равных. Все это позволяет сохранять внутри группы нефор­мальные отношения.

Вместо понятия роли для группы в целом определяются ролевые кла­стеры, которые заполняются точно так же, как происходит распределе­ние ролей. В то время как за успех проекта ответственна вся команда, ка­ждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из проектных целей и работает над ее достижением. В данной мо­дели именно эти цели задают роли разработчиков, которые определяются кластерами. В терминологии MSF используется понятие области компе­тенции, или области функциональной специализации (functional area), обо­значающее ту или иную роль, которую выполняет кластер группы в про­екте. Принципиальное отличие распределения исполнителей по ролевым кластерам от распределения ролей заключается лишь в том, что ответст­венность за это несет не менеджер проекта, а сама группа. Менеджер про­екта выдает задания и контролирует их выполнение лишь в целом для группы, не вмешиваясь в ее работу.

Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).

■ Управление продуктом (product management). Ключевая цель класте­ра — обеспечивать удовлетворение интересов заказчика. Для ее дос­тижения кластер должен содержать следующие области компетенции:

• планирование продукта,

• планирование доходов,

• представление интересов заказчика,

• маркетинг.

> Управление программой (program management). Задача — обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проек­та и к его результату. Области компетенции кластера:

• управление проектом;

• выработка архитектуры решения;

• контроль производственного процесса;

• административные службы.

► Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Обла­cти компетенции кластера:

• технологическое консультирование;

• проектирование и осуществление реализации;

• разработка приложений;

• разработка инфраструктуры.

• Тестирование (test). Задача кластера — одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Обла­сти компетенции кластера:

• разработка тестов;

• Удовлетворение потребителя (user experience). Цель кластера — по­вышение эффективности использования продукта. Области компетенции кластера:

• общедоступность (возможности работы для людей с недостатка­ ми зрения, слуха и др.);

• интернационализация (эксплуатация в иноязычных средах);

• обеспечение технической поддержки;

• обучение пользователей;

• удобство эксплуатации (эргономика);

• графический дизайн.

• Управление выпуском (release management). Задача кластера — бес­препятственное внедрение и сопровождение продукта. Области компетенции кластера:

• инфраструктура (infrastructure);

• сопровождение (support);

• бизнес-процессы (operations);

• управление выпуском готового продукта (commercial release management).

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

Если обратиться к менеджерским задачам руководства коллективом в проекте, то оказывается, что схема MSF мало что регламентирует. Гово­рится лишь о том, какие должны быть группы, но вопросы их формиро­вания оставлены без ответа. Этого и следовало ожидать, имея в виду по­стулат невозможности формализовать руководство. В то же время, сама схема ограничивает действия менеджера. В подтверждение этому приве­дем один пример из опыта автора этих строк. При работе с очень квали­фицированной программистской группой был замечен явный рост про­дуктивности ее членов, когда на собраниях присутствовала весьма при­влекательная лаборантка, о профессионализме и компетентности кото­рой не могло быть и речи. Единственное объяснение тому — повышение духа состязательности в коллективе, Вместе с тем по логике MSF для та­кой работницы просто нет места в проектной группе. Как учитывать и использовать подобные ситуации? Единственный совет, который можно здесь дать, — не очень полагаться на формализованные схемы организа­ции и быть как можно более наблюдательным.

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

Мы придерживаемся ролевой структуры проекта, которая предложе­на Центром объектно-ориентированной технологии компании IBM [46]. Эта структура включает достаточно полный перечень типичных ролей, согласованный со многими реальными дисциплинами развития про­граммных проектов. В то же время она представляет роли разработчиков в организационном контексте, т.е. рассматривает не только разработчи­ков, но и тех, кто, не участвуя в проекте в качестве исполнителей, оказы­вает влияние на постановку задач проекта, на выделение ресурсов и обес­печение осуществимости развития работ. В представленном перечне ха­рактеристика каждой роли, по сути, задает круг родственных организаци­онных и производственных функций, которые объединяются с целью определить роль.

• Заказчик (Customer) — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как теку­щие, так и окончательные) разработки.

• Планировщик ресурсов (Planner) — выдвигает и координирует требования к проектам в организации, осуществляющей данную раз­ работку, а также развивает и направляет план выполнения проекта с точки зрения организации.

• Менеджер проекта (Project Manager) — отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позво­ляет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.

• Руководитель команды (Team Leader) — производит техническое ру­ководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей под­команд, отвечающих за решение частных задач.

• Архитектор (Architect) — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.

• Проектировщик подсистемы (Designer) — отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.

• Эксперт предметной области (Domain Expert) — отвечает за изуче­ние сферы приложения, поддерживает направленность проекта на решение задач данной области.

• Разработчик (Developer) — реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет ко­дирование и автономное тестирование, строит продукт. Это широ­кое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков.

• Разработчик информационной поддержки (Information Developer) — создает документацию, сопровождающую продукт, когда выпуска­ется версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предос­тавляются на бумажных и машинных носителях. Для сложных про­ектов возможно распределение этих задач между несколькими раз­работчиками информационной поддержки.

• Специалист по пользовательскому интерфейсу (Human Factors Engineer) — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.

• Тестировщик (Tester) — проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.

• Библиотекарь (Librarian) — отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

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

Мы будем иметь возможность убедиться в том, что заказчик как ре­альная персона не является единственным лицом, заинтересованным в получении результатов. На задачи проекта влияют персоналии из сфер производства и потребления программных продуктов, расширяя или су­жая возможности будущего программного изделия, — так называемые инициаторы работ (stakeholdes)*. О них говорить необходимо, когда обсу­ждение менеджмента касается влияния на проект внешних требований. И в этом плане полезно воспринимать заказчика в качестве равнодействую­щей всех инициаторов работ, которая выставляет согласованные требова­ния и задачи. Иными словами, там, где удобно не различать внешние вли­яния на проект, мы определяем абстрактного заказчика.

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

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

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

В зависимости от проекта и условий его выполнения роли участни­ков проекта могут совмещаться. Предельный случай — программист раз­рабатывает проект для себя (по собственному заказу), сам планирует

*Термин «инициаторы работ» — перевод английского слова «stakeholdes». В литературе можно встретить и другие его переводы: организаторы работ, заинтересованные лица и даже акционеры (последнее уводит далеко в сторону). Некоторые прибегают к транслитерации и говорят о степк-хапдерах проекта. Мы предпочитаем назыать всех тех, чьи интересы в той или иной мере затра­гивают проект и его результаты, инициаторами работ. Наряду с этим мы употребляем термин «заинтересованные лица», обозначая им всех тех, кто проявляет интерес к проекту и от действия которых может зависеть его развитие, пусть даже косвенно. Таким образом, инициаторы работ включают в себя заинтересованных лиц (в частности, разработчиков проекта), но обратное невер­но. К примеру, акционер проекта является инициатором работ, так как его интересы судьба про­екта, безусловно, затрагивает. Но полагаясь на своего брокера, он может позволить себе даже не думать о проекте, т.е. не быть его заинтересованным лицом (в нашей терминологии).

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

Понятно, что совмещение ролей не может быть произвольным. Од­ни совмещения нежелательны (в разной степени), другие нейтральны, третьи полезны для проекта. Общий регламент для совмещения опреде­ляют следующие принципы:

I.He следует допускать совмещения ролей, которые имеют кон­фликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механиз­мы, которые будут демпфировать противоречия.

2. Представление ролей с конфликтными интересами различным людям обеспечивает равновесие противоречащих точек зрения.

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

4. Если работнику поручается несколько ролей, то он всегда должен знать, какую из них он выполняет в данный момент.

В большинстве случаев заказчик и планировщик ресурсов являются действительно внешними по отношению к проекту действующими лица­ми, а потому совмещение этих ролей с другими — нечто экзотическое. Тем не менее роль заказчика как члена коллектива разработчиков, аккумули­рующего точки зрения всех инициаторов работ, весьма полезна. В частно­сти, подход экстремального программирования считает это обязательным, чтобы развитие проекта всегда гарантированно было направлено в сторо­ну, нужную пользователям [3]. Поскольку в этом подходе ролевая диффе­ренциация работников отходит на второй план, его апологеты не выделя­ют специально роли эксперта предметной области. Скорее всего, они счи­тают, что его функции должны выполнять заказчик, который составляет тесты для проверки системы в целом (по крайней мере специфицирует их), и остальные разработчики группы, которые по мере уяснения актуаль­ных пользовательских потребностей поймут, как их воплотить в коде. Но задачи эксперта предметной области иные: он должен понимать структуру пользовательской деятельности, чтобы отвечать на вопросы об узких мес­тах этой деятельности, о критериях актуальности принимаемых решений, о содержательных формах, в которых предоставляемые средства должны преподноситься пользователям. Даже если не брать в расчет перегрузку роли заказчика экспертными функциями, понятно, что предположение о включении заказчика в команду, выполняющую проект, представляется скорее исключением, нежели правилом. Уже из этого примера видно, на­сколько размыты границы между функциями разных ролей, а значит, и совмещения ролей в команде. Точное определение ролей, их разграниче­ния и совмещения — область специфики конкретных проектов. Тем не менее, уместно сформулировать рекомендации, основанные на опыте успеш­ного и неудачного менеджмента программных проектов.

Менеджер проекта по своему назначению является выделенным в команде. Он берет на себя взаимодействие с заказчиком и планировщи­ком ресурсов, с одной стороны, а с другой — распределяет работы среди членов команды. Последнее означает, что он должен обладать полной ин­формацией о декомпозиции проекта. Как следствие, совмещение его ро­ли с ролью архитектора проекта является весьма желательным, а потому довольно частым. Единственным условием для такого совмещения явля­ется требование четко знать, когда и чьи функции выполняет данное дей­ствующее лицо (см. общий для всех совмещений принцип 4).

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

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

Нежелательно совмещение ролей руководителя команды и проекти­ровщика какой-либо подсистемы. И это обусловлено противоречивостью их ролевых интересов.

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

• Руководитель команды должен выдавать задания исходя из системы реализационных понятий, которая принципиально отличается от системы понятий подсистемы в целом, соответствующей уровню использования. Этот уровень отслеживается проектировщиком.

• Разделение ролей проектировщика и руководителя способствует равновесию точек зрения пользователя и разработчика подсистемы (см. принцип 2).

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

По тем же причинам не допускается совмещение ролей менеджера и разработчика. Здесь запрет более жесткий, поскольку контрольные функ­ции менеджера несовместимы с исполнительскими задачами разработчи­ка. Даже в тех случаях, когда у менеджера остается свободное время пос­ле выполнения своих прямых обязанностей, ему не следует «помогать» разработчикам. Лучше занять себя другим делом, в частности выступить в роли разработчика другого проекта.

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

Допустимы и другие совмещения ролей. Так, довольно часто созда­ние документации распределяется между всеми исполнителями проекта, а на руководителя команды и менеджера возлагается задача интеграции документов. Для обозримых проектов функции библиотекаря можно по­ручить одному из разработчиков, соответственно скорректировав его ин­дивидуальное задание (см. принцип 3). Специалистом по пользователь­скому интерфейсу вполне может быть, например, менеджер, поскольку именно он осуществляет контакты с заказчиком (в данной ситуации заказчик либо сам является пользователем, либо выступает как представи­тель пользователя программного изделия).

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

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

Но как обеспечить «независимое» тестирование? Весьма разумный метод — априорное тестирование, т.е. создание тестов до, а не после кодирования модуля. Это одно из требований экстремального программиро­вания, которое вполне может быть распространено на другие методики ведения проектов. В статье [32] вводится специальный термин для обо­значения программистов, которые привыкли писать тесты до разработки: инфицированные тестами, и показывается, что эта «болезнь» только уско­ряет процесс в целом, В книге [4] Бек показывает, как можно выполнять программные проекты с помощью априорного тестирования, какие пре­имущества это дает для процесса разработки и для его результата.

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

Содержательная задача комплексного тестирования предоставляемых функций связывается прежде всего с заказчиком, который в состоянии дать для этого все необходимые материалы. Действуя вне проектной ко­манды, он способен обеспечить проверку, действительно независимую от критериев и предпочтений разработчиков. Однако заказчик чаще всего не в состоянии сам правильно строить тесты. Обычный максимум для него — спецификации ситуаций использования системы, нуждающихся в провер­ке. Материалы заказчика о пользовательской деятельности, для автомати­зации которой предназначена программа, рассматриваются в качестве ин­формационной базы для комплексного тестирования. Формирование этой базы есть прямая функциональная обязанность эксперта предметной обла­сти, который, действуя на стороне разработчиков, обеспечивает проект ориентирами, направляющими развитие. Одна из его задач в проекте — ре­конструкция работы пользователя с системой, из которой извлекаются ре­альные комплексные тесты для проверки предоставляемых функций. Адаптация тестов к условиям разработки, т.е. представление в виде, в кото­ром запуск и анализ прогонов будут требовать от разработчиков минималь­ных усилий, классификация тестов и т.д. *- это основная задача тестировшика как члена проектной команды. Дополнительные его задачи связаны с обеспечением технической помощи и поддержки комплексного тестирова­ния, с ведением протоколов тестирования и архивов тестов.

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

В цепочке ролей «заказчик, эксперт предметной области, тестировшик» нет противоречивых интересов, а потому, с точностью до того, что за­казчик обычно является внешним по отношению к проекту лицом, здесь совмещение ролей оправданно. Что же касается экстремального програм­мирования, провозгласившего включение заказчика в группу разработчи­ков как принцип, то при описании подхода явно указывается, что это озна­чает лишь предоставление представителя заказчика команде. Иными сло­вами, имеется в виду эксперт предметной области с дополнительными, ра­зумеется частичными, полномочиями заказчика. Продуктивность данной схемы вполне понятна. Более того, ее можно считать проверенной време­нем: по этой схеме в советские времена работали все программистские кол­лективы, выполнявшие проекты военного ведомства. Явное участие пред­ставителя заказчика в ключевых моментах разработок приносило хорошие плоды, но только при одном условии: если военпред (как тогда называли представителя заказчика) не сводил свою работу лишь к выполнению кон­трольно-надзирательных функций. Впрочем, его карьерная заинтересо­ванность в успехе проектов чаше способствовала выработке правильных отношений с коллективом, чем мешала работе (что также было нередко, о чем не следует забывать сторонникам экстремального программирования).

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

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

В качестве итога обсуждения совместимости ролей для действующих лиц проекта в табл. 1.3 приводятся краткие характеристики совмещения ролей, которые можно рассматривать как рекомендации для менеджмен­та. Разумеется, нельзя абсолютизировать эти характеристики для любых проектов. Не стоит жестко фиксировать распределение ролей и в одном проекте. Более того, распределение ролей можно рассматривать в качест­ве одного из инструментов, с помощью которого менеджер может руково­дить коллективом. Если этим инструментом пользоваться умело, то уда­ется добиться наиболее эффективного разделения труда, соответствую­щего индивидуальным особенностям участников проекта.