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

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

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

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

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

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

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

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

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

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

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