учебники, программирование, основы, введение в,

 

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

Для целенаправленного выполнения проекта должен быть выполнен ряд работ, различных как по своему назначению, так и по квалификационным требованиям, предъявляемым к разработчикам. Иными словами, в ходе развития проекта командой разработчиков выполняются те или иные функции.
Функции, выполняемые разработчиками, — понятие неформализованное. В разных проектах оно может обретать свое содержание. Тем не менее типовые функции, которые предполагают практически все программные проекты, можно перечислить. Так, в любом программном проекте есть функции кодирования, т.е. записи программы на алгоритмическом языке по имеющимся спецификациям, анализа требований, т.е. выявления истинной потребности в создаваемой программе, тестирования и отладки. Далее мы рассмотрим эти и другие функции разработчиков, связанные с проектом, а пока лишь заметим, что в рамках деятельности менеджера любого проекта необходимо организовать распределение функций проекта между исполнителями. Вполне естественно считать эти действия одной из функций менеджера. В результате ее выполнения члены команды, выполняющей проект, начинают играть соответствующие роли.
Обычно роль объединяет родственные функции. Также принято обозначать роли их главными функциями. Продолжая только что приведенную иллюстрацию функций, выполняемых разработчиками проекта, укажем на следующие роли: кодировщик — действующее лицо, главной функцией которого является кодирование, аналитик — тот, кто занимается анализом требований. Подобную характеристику можно дать и тестировщику. Что же касается функции отладки, то в реальных проектах она обычно подразделяется на несколько видов: отладка компонентов, которой занимаются разработчики компонентов (например, те же кодировщики) и комплексная отладка, которая может поручаться специально выделенным сотрудникам или рассматриваться в качестве задачи группы разработчиков. Часто выполняются такие работы, как отладка спецификаций, декомпозиция проекта и др. Иными словами, функция отладки обычно не рассматривается как образующая роль, а распределяется по нескольким ролям в соответствии с принятой стратегией развития проекта.
Не следует путать функции, которые предписано выполнять разработчику как исполнителю определенной роли, с поручениями в проекте. Поручения — это разовые или систематические задания, из которых обычно и складываются действия, необходимые для выполнения той или иной функции. Если для функции определен регламент выполнения поручений, т. е. последовательность выполнения составляющих ее поручений не требует дополнительных разъяснений для исполнителя, то такая функция называется технологической. В случае нетехнологической функции сотруднику, который выполняет соответствующую роль, приходится самому выстраивать нужную последовательность. Иными словами, технология здесь уступает место ремеслу.
При разработке любых проектов естественно стремление к повышению их технологичности, к установлению регламента для как можно большего числа функций. И одним из способов достижения этого для менеджера является использование работников с нужной квалификацией, для которых поручаемые им роли оказываются технологичными, т.е. состоящими только из технологических функций. К сожалению, реальность такова, что менеджеру приходится работать в условиях ограниченных возможностей в подборе кадров, а потому уровень технологичности выполнения проекта снижается по сравнению с идеальной ситуацией.
Таким образом, в рамках любого проекта возникает задача повышения квалификации сотрудников. Для различных схем ведения проектов эта задача решается по-разному. Крайнюю точку зрения на проблему соответствия квалификации работников требованиям проекта отражает идея экстремального программирования, когда используется неформальная организация группы исполнителей проекта без четкого распределения ролей, а значит, и обязательств сотрудников. В этом случае провозглашается принцип, когда каждый в группе делает то, что он умеет делать лучше всего. И хотя все функции, которые должны выполняться, остаются, создается впечатление, что в группе исполнителей проекта исчезают роли. В результате возможны пробелы в разработке, в частности при анализе и декомпозиции проектируемой системы. Чтобы этого избежать, разработчики должны понимать, какую абстрактную роль они исполняют в каждый конкретный момент, выполнение каких проектных функций необходимо сейчас, как связаны между собой работы, как должны распределяться ресурсы. Словом, они должны обращать внимание на выполнение распределенных по группе менеджерских функций. И даже в этом случае схему экстремального программирования можно рекомендовать лишь для слаженных групп исполнителей с высоким уровнем коллективной ответственности.
Функции, выполняемые разработчиками в проекте, подразделяются на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями. Часто неудачи проекта возникают из-за того, что менеджер не учитывает важность выполнения организационных функций. Так, обычно проектное задание фиксирует лишь то, что нужно предъявлять заказчику в качестве результатов. С точки зрения результатов просто не требуется знать, например, как организована передача проектных материалов между разработчиками, какая процедура отчетности предусматривается, но игнорирование задач реализации информационных потоков в проекте может привести к хаосу, что в конечном итоге отразится и на результатах.
Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится непомерно велик (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня ). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.
Как конкретный разработчик может получать одновременно несколько ролей, так и роль может быть распределена между несколькими исполнителями. В рамках изложения, следуя соглашению об абстрактных действующих лицах (см. лекцию 1), мы вправе отождествлять роль и действующее лицо. Но это не более чем способ представления материала, направленный на разделение сущностей. Когда менеджеру в конкретных условиях руководства коллективом придется распределять роли, он неизбежно столкнется с тем, что эта задача зависит и от специфики проекта, и от контингента исполнителей. В связи с этим уместно упомянуть об одном из ее решений, которое предлагается специалистами Microsoft в качестве универсального подхода.
В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответственностью за выполняемые задания — так называемые проектные группы. Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профессиональной подготовки, хотя и в разных областях индивидуальной специализации. Провозглашается равноправие членов группы и коллективная ответственность за выполняемые задания: проектная группа — команда равных. Все это позволяет сохранять внутри группы неформальные отношения.
Вместо понятия роли для группы в целом определяются ролевые кластеры, которые заполняются точно так же, как происходит распределение ролей. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из проектных целей и работает над ее достижением. В данной модели именно эти цели задают роли разработчиков, которые определяются кластерами. В терминологии MSF используется понятие области компетенции, или области функциональной специализации (functional area), обозначающее ту или иную роль, которую выполняет кластер группы в проекте. Принципиальное отличие распределения исполнителей по ролевым кластерам от распределения ролей заключается лишь в том, что ответственность за это несет не менеджер проекта, а сама группа. Менеджер проекта выдает задания и контролирует их выполнение лишь в целом для группы, не вмешиваясь в ее работу.

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

    • планирование продукта,
    • планирование доходов,
    • представление интересов заказчика,
    • маркетинг.
  • Управление программой (program management). Задача — обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:
    • управление проектом;
    • выработка архитектуры решения;
    • контроль производственного процесса;
    • административные службы.
  • Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:
    • технологическое консультирование;
    • проектирование и осуществление реализации;
    • разработка приложений;
    • разработка инфраструктуры.
  • Тестирование (test). Задача кластера — одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера:
    • разработка тестов;
    • отчетность о тестах;
    • планирование тестов.
  • Удовлетворение потребителя (user experience). Цель кластера — повышение эффективности использования продукта. Области компетенции кластера: — общедоступность (возможности работы для людей с недостатками зрения, слуха и др.);
    • интернационализация (эксплуатация в иноязычных средах);
    • обеспечение технической поддержки;
    • обучение пользователей;
    • удобство эксплуатации (эргономика);
    • графический дизайн.
  • Управление выпуском (release management). Задача кластера — беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера:
    • инфраструктура (infrastructure);
    • сопровождение (support);
    • бизнес-процессы (operations);
    • управление выпуском готового продукта (commercial release management).

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

  • Заказчик (Customer) — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки.
  • Планировщик ресурсов (Planner) — выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации.
  • Менеджер проекта (Project Manager) — отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.
  • Руководитель команды (Team Leader) — производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач.
  • Архитектор (Architect) — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.
  • Проектировщик подсистемы (Designer) — отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.
  • Эксперт предметной области (Domain Expert) — отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области.
  • Разработчик (Developer) — реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков.
  • Разработчик информационной поддержки (Information Developer) — создает документацию, сопровождающую продукт, когда выпускается версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки.
  • Специалист по пользовательскому интерфейсу (Human Factors Engineer) — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.
  • Тестировщик (Tester) — проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.
  • Библиотекарь (Librarian) — отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

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

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

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

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

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

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


Редко бывает эффективным совмещение ролей специалиста по интерфейсу и эксперта предметной области. Причиной тому — разный угол зрения, под которым рассматривается система. Для эксперта система представляется прежде всего структурированным набором функций, который обеспечивает поддержку пользовательской деятельности, а способ управления активизацией этих функций вторичен. Как следствие, возможно игнорирование таких аспектов интерфейса, как совместимость с другими системами, учет сложившихся стандартов и т.п. Эффективность обсуждаемого совмещения ролей возможна, если в проекте необходимость исследования интерфейсных вопросов не очень высока, а эксперт предметной области обладает достаточной квалификацией в организации интерфейсов. Как всегда, здесь обязательно следование четвертому принципу регламента для совмещений: четкое разделение того, в какой роли выступает работник в данный момент.
Роль эксперта предметной области может быть полезна для разработчика, так как дает дополнительные критерии при решении его собственных проблем. Однако эта дополнительная роль порою чрезмерно перегружает сотрудника и, как следствие, есть опасность затягивания сроков проекта или его этапа (принцип 3). То же можно сказать и о совмещении ролей разработчика и специалиста по интерфейсу. Но здесь совмещение более целесообразно, особенно для разработчиков, которым поручены задачи, затрагивающие вопросы интерфейса. Причина вполне понятна: исключается дополнительное звено между разработчиком и заинтересованными в качественном интерфейсе лицами.
По поводу тестировщиков необходимы некоторые разъяснения. Следует различать два вида тестирования: тестирование модулей, автономное по своей сути, и тестирование предоставляемых функций, которое может быть и комплексным (проверка совместного выполнения функций), и автономным, когда проверяется работоспособность отдельного аспекта системы. В первом случае задачи тестировщика невозможно выполнить без знания не только назначения, но и структуры проверяемого модуля. Лучше всего в этом разбирается разработчик модуля, а значит, именно ему этот модуль и отлаживать. Автономное тестирование второго вида, по существу, есть другая сторона проверки работоспособности модуля, реализующего определенную функцию. Во многих случаях даже нет нужды различать его и тестирование модуля. Поэтому и здесь разумно говорить о деятельности разработчика. В обоих случаях самотестирование для разработчика есть не дополнительная роль в проекте, а часть его профессиональных обязанностей в рамках автономной отладки.
Но как обеспечить «независимое» тестирование? Весьма разумный метод — априорное тестирование, т.е. создание тестов до, а не после кодирования модуля. Это одно из требований экстремального программирования, которое вполне может быть распространено на другие методики ведения проектов. В статье [32] вводится специальный термин для обозначения программистов, которые привыкли писать тесты до разработки: инфицированные тестами, и показывается, что эта «болезнь» только ускоряет процесс в целом. В книге [4] Бек показывает, как можно выполнять программные проекты с помощью априорного тестирования, какие преимущества это дает для процесса разработки и для его результата.
Другой метод, нисколько не противоречащий априорному тестированию, — перекрестное тестирование, когда разработчики независимых компонентов проекта тестируют функциональность друг друга. Здесь можно говорить о перекрестном совмещении ролей разработчиков и тестировщиков, поскольку для выполнения перекрестного тестирования нужно различное представление об испытываемом модуле.
Содержательная задача комплексного тестирования предоставляемых функций связывается прежде всего с заказчиком, который в состоянии дать для этого все необходимые материалы. Действуя вне проектной команды, он способен обеспечить проверку, действительно независимую от критериев и предпочтений разработчиков. Однако заказчик чаще всего не в состоянии сам правильно строить тесты. Обычный максимум для него — спецификации ситуаций использования системы, нуждающихся в проверке. Материалы заказчика о пользовательской деятельности, для автоматизации которой предназначена программа, рассматриваются в качестве информационной базы для комплексного тестирования. Формирование этой базы есть прямая функциональная обязанность эксперта предметной области, который, действуя на стороне разработчиков, обеспечивает проект ориентирами, направляющими развитие. Одна из его задач в проекте — реконструкция работы пользователя с системой, из которой извлекаются реальные комплексные тесты для проверки предоставляемых функций. Адаптация тестов к условиям разработки, т.е. представление в виде, в котором запуск и анализ прогонов будут требовать от разработчиков минимальных усилий, классификация тестов и т.д. — это основная задача тестировщика как члена проектной команды. Дополнительные его задачи связаны с обеспечением технической помощи и поддержки комплексного тестирования, с ведением протоколов тестирования и архивов тестов.
В цепочке ролей «заказчик, эксперт предметной области, тестировщик» нет противоречивых интересов, а потому, с точностью до того, что заказчик обычно является внешним по отношению к проекту лицом, здесь совмещение ролей оправданно. Что же касается экстремального программирования, провозгласившего включение заказчика в группу разработчиков как принцип, то при описании подхода явно указывается, что это означает лишь предоставление представителя заказчика команде. Иными словами, имеется в виду эксперт предметной области с дополнительными, разумеется частичными, полномочиями заказчика. Продуктивность данной схемы вполне понятна. Более того, ее можно считать проверенной временем: по этой схеме в советские времена работали все программистские коллективы, выполнявшие проекты военного ведомства. Явное участие представителя заказчика в ключевых моментах разработок приносило хорошие плоды, но только при одном условии: если военпред (как тогда называли представителя заказчика) не сводил свою работу лишь к выполнению контрольно-надзирательных функций. Впрочем, его карьерная заинтересованность в успехе проектов чаще способствовала выработке правильных отношений с коллективом, чем мешала работе (что также было нередко, о чем не следует забывать сторонникам экстремального программирования).
Все сказанное выше о тестировании должно распространяться на проверку всех результатов, получаемых в проекте, а не только на код программного изделия. Таким образом, роль тестировщика связана с деятельностью, которая позволяет удостовериться в правильности принимаемых решений на всех уровнях, включая выработку спецификаций (соответствуют ли они требованиям инициаторов работ), построение декомпозиции (дает ли она оптимальную для развития проекта архитектуру), составление документации (допускает ли работу пользователей, не требующую неописанных сведений о системе), а также разработку иных рабочих продуктов, сопровождающих программное изделие.
Тестирование как способ внешней оценки продукта для разработчика противопоказано (противоречит принципам 1 и 3). Поэтому часто говорят, что оно должно быть вынесено за проект. По-видимому, по этой причине для экстремального программирования внешнее тестирование связывают с работой заказчика, являющегося членом команды проекта. Когда такое возможно, получается совмещение ролей заказчика и тестировщика, и это приводит к хорошим результатам.
В качестве итога обсуждения совместимости ролей для действующих лиц проекта в приводятся краткие характеристики совмещения ролей, которые можно рассматривать как рекомендации для менеджмента. Разумеется, нельзя абсолютизировать эти характеристики для любых проектов. Не стоит жестко фиксировать распределение ролей и в одном проекте. Более того, распределение ролей можно рассматривать в качестве одного из инструментов, с помощью которого менеджер может руководить коллективом. Если этим инструментом пользоваться умело, то удается добиться наиболее эффективного разделения труда, соответствующего индивидуальным особенностям участников проекта.

Таблица 2.1. Роли действующих лиц проекта и совмещение ролей

Роли

Характеристика совмещения ролей

Менеджер и архитектор

Желательно

Менеджер и руководитель команды

Противоречиво

Руководитель команды и архитектор

Возможно

Руководитель команды и проектировщик подсистемы

Нежелательно

Менеджер и разработчик

Не допускается

Для различных разработчиков

Эффективно с ограничениями(обычное дело)

Создание документации (все сотрудники)

Успешно распределяется

Специалист по интерфейсу и менеджер

Разумно

Эксперт предметной области и менеджер

Зачастую разумно

Специалист по интерфейсу и эксперт предметной области

Редко бывает эффективно

Эксперт предметной области и разработчик

Бывает полезно

Специалист по интерфейсу и разработчик

Часто полезно

Библиотекарь и один из разработчиков

Допустимо

Тестировщики и другие члены команды

Перекрестно

Эксперт предметной области, тестировщик

Оправданно

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика