Home

В преддверии конференции SQA Days 10, которая будет проходить 2-3 декабря в Москве, мы решили (с разрешения докладчиков) опубликовать статьи-анонсы некоторых выступлений. Открывает эту серию публикаций статья Максима Цепкова, технического директора и главного архитектора компании CUSTIS, в которой вновь обсуждается больная для тестировщиков тема совмещения ролей тестировщика и аналитика. Во благо это или во зло?

От водопада к Agile

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

В последнее десятилетие водопадная модель сдает свои позиции и сменяется гибкими (Agile) методологиями разработки. Это происходит не только на уровне IT-сообщества: в современных редакциях стандартов, таких как PMBOK 4 версии, 2008 и SWEBOK 3 версии, 2004, сделаны оговорки, что структура самого документа повторяет стадии водопадной модели лишь по совпадению и явно упоминаются альтернативные Agile-подходы.

Agile-методологии создают предпосылки для изменения состава ролей в команде разработки, декларируя кросс-функциональность. Однако полностью кросс-функциональные команды встречаются довольно редко. Обычно разделение сохраняется, либо в виде разных ролей внутри команды, либо в виде отдельных функциональных команд.

Даже при сохранении ролей в рамках одной команды, границы между ролями могут быть проведены по-другому, нежели в водопадной модели.

V-модель

Для иллюстрации используем V-модель процесса разработки (Рис.2), которая была позаимствована из системной инженерии. По нисходящей ветви мы абстрагируемся от внешнего мира, производя конструирование и создание программного артефакта, а по восходящей — вносим созданный артефакт во внешний мир, выполняя его тестирование и внедрение.

V-модель интересна тем, что дает достаточно общий взгляд на процесс как таковой, не сосредотачиваясь на его отдельных стадиях. Поэтому она удобна для сравнения различных моделей разработки.

Классические роли

В водопадной модели для каждой стадии жизненного цикла программного продукта предусмотрена своя роль: бизнес-аналитики собирают требования и описывают предметную область, системные аналитики выполняют конструирование системы, затем разработчики реализуют программный продукт и передают его тестировщикам и внедренцам, а далее - службе поддержки. Такое разделение ролей представлено на Рис.3.

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

Альтернатива

Agile-методологии появились и развивались в ответ на проблемы традиционных методологий. Чтобы снижать риски, связанные с постановками, в них предусмотрено два механизма. Во-первых, быстрая обратная связь через демонстрации и общение с заказчиком. Во-вторых, стремление к кросс-функциональности внутри команды. Однако в реальности полная кросс-функциональность достигается редко из-за широкого спектра разнородных деятельностей, входящих в процесс создания ПО.

Поэтому на практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей, что изображено на Рис.4. Аналитика-тестировщика традиционно называют аналитиком, хотя столь же успешно его можно было бы назвать и тестировщиком. Более того, если существенная часть аналитической работы находится на стороне заказчика, то последнее точнее отражает его функции.

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

Отметим, что такое разделение ролей может использоваться в различных процессах разработки. В частности, о таком разделении рассказывал Пауль Тернер на Req-Labs. Однако, именно в кросс-функциональной Agile-команде, использующей современную методику разработки и проектирования DDD с единым языком, обеспечивающим коммуникацию, оно особенно эффективно. Такой распределение обязанностей позволяет избежать потери информации и повышает качество продукта, а также обеспечивает большую скорость и гибкость разработки.

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

Визуализация ролей на V-модели

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

Обсудить в форуме