Аналитик и Тестировщик в одном лице – путь к качеству Докладчик: Максим Цепков Software Quality Assurance Days 10-я Международная конференция 2-3 декабря 2011, Москва

Процесс разработки и разделение ролей: Классика – водопад, разделение ролей – оттуда. IT-отрасль меняется, меняются и модели. Есть альтернатива – модель аналитика-заказчика: В команде – аналитики-тестировщики и разработчики. Делимся опытом успешного использования. О чем этот доклад? Смотрим на опыт других и вырабатываем свой подход. 2/21

Визуальное представление ролей Для эффективного обсуждения нужно графическое представление. Это оказалось удобно делать на схеме V-модели. 3/21 Диаграммы – фишка

Процесс разработки и роли 4/21

Наблюдаемые признаки: Признание и использование Agile в ведущих IT-компаниях и в inhouse-разработке. Явное упоминание Agile в базовых документах (SWEBOK, PMBOK).SWEBOKPMBOK Россия – в русле мирового развития. Мечта о едином, эталонном процессе похоронена. Даже в варианте «возьмите только нужное» (PMBOK). Делаем процесс, адекватный проекту и компании! SCRUM/Canban/XP – лишь распространенные комбинации. Комбинируем известные успешные практики, придумываем свои. Фокус на эффективные коммуникации и автономность команды. Agile – мировой тренд Это просто факт 5/21

Каждой стадии – своя роль. Роли выполняются разными людьми или командами. Передача работы – через артефакты на отдельных языках. Водопад ушел – роли остались Бизнес-аналитик Системный аналитик Разработчик Тестировщик Внедренец Модель водопада – Waterfall_model Waterfall_model А где заказчик? 6/21

Роли водопада на V-модели Коммуникации – лишь с соседями. Длинный цикл общения ведет к потере информации. 7/21 Внедренцы Бизнес- аналитики Системные аналитики Тестировщики Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance

Внедренцы Бизнес- аналитики Системные аналитики Тестировщики Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Изменение видения проекта… 8/21 Что хотели Старый известный образ

Кросс-функциональная команда разработчиков. Взаимодействие с заказчиком через Product Ownerа. Что предлагает Agile? 9/21 Product Owner Команда Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Конструкция SCRUM, в других методах – аналогично

Эффективные коммуникации. Возможность быстрой обратной связи. Большая нагрузка на Product Ownerа. Расширение зоны ответственности Заказчика. Слишком разнообразная работа членов команды. Плюсы и минусы 10/21 Product Owner Команда Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Подходит далеко не для всех проектов.

Ищем хорошие варианты 11/21 В духе Agile

ТестировщикиАналитики Кросс-функциональная команда не означает полной взаимозаменяемости, возможна специализация. Снижается нагрузка на Product Ownerа. Большое число ролей затрудняет коммуникации. Неравномерная нагрузка на роли в ходе проекта. Специализация внутри команды 12/21 Разработчики Заказчик Detailed Design Implementation Integration and Test Product Owner Maintenance System Verification Requirements and Architecture Concept

Команда разработчиков и тестировщиков – распространенный вариант. Две роли – не много, но достаточно. Не подходит, когда аналитической работы много. Есть проекты, где аналитики мало 13/21 Тестировщики Разработчики Заказчик Detailed Design Implementation Integration and Test Product Owner Maintenance System Verification Requirements and Architecture Concept

Аналитики получают требования заказчика и формулируют задачу разработчикам. Они же принимают результат разработки и передают его заказчику. Модель внутреннего заказчика Новое – хорошо забытое старое. 14/21 Аналитики- тестировщики Разработчики Заказчик Detailed Design Implementation Integration and Test MaintenanceConcept Product Owner Requirements and Architecture System Verification

Для проектов с полным набором активностей. CUSTIS – заказная разработка: обследование, постановка, разработка, внедрение, развитие. Для продуктовой разработки тоже применима. Модель распространена в мире Пауль Тернер на Req-Labs. Пауль Тернер на Req-Labs Область применения модели 15/21

Автономность команды разработки. Эффективные коммуникации внутри и с заказчиком. Быстрая реакция на требования заказчика (скорость поставки часто важнее качества продукта). Прием результата разработки аналитиком повышает соответствие системы ожиданиям заказчика. Две роли в команде – возможность дублирования. Равномерная нагрузка на роли в ходе проекта. Преимущества модели Все вместе дает высокое качество услуги для заказчика. 16/21

Представить работу пользователя с системой: Бизнес-сценарии – основа требований и тестов. Основные активности пользователей, эргономика. Сложные случаи – для проектирования и проверки. Общение с Заказчиками и Пользователями: Выяснение их работы и ее особенностей. Уточнение при альтернативных и спорных моментах. Объяснение работы системы. Консультации по сложным случаям. Взаимодействие с разработчиками. Почему аналитика, тестирование, внедрение – схожая активность? 17/21 Это все – общие активности. В аналитике и тестировании есть место и сенсорикам, и интуитам.

Соотношение разработчиков и аналитиков – 2:1. 6–7 (4–11) человек: 4 разработчика, 2 аналитика и руководитель проекта (Product Owner). Члены команды могут заменять друг друга с учетом специализации. У руководителя тоже есть зам. Применение DDD дает единый язык общения. Часть разработчиков и аналитиков – начинающие, они растут и набирают опыт. По мере роста опытные сотрудники уходят в новые проекты, а новички – приходят. * Для сложных проектов, развивающихся 3–10 лет после внедрения. Опыт CUSTIS – типовая команда* 18/21

Активность аналитика начинается с тестирования: освоение системы и бизнес-области. Активность разработчика начинается с реализации по проработанным постановкам. Постепенно области расширяются… Рост новичков в команде 19/21 Аналитики- тестировщики Заказчик Implementation Integration and Test Maintenance System Verification Requirements and Architecture Concept Разработчики Начинающий разработчик Начинающий аналитик- тестировщик Detailed Design

Общее: Создавайте разделение ролей исходя из проекта. Для визуализации хорошо использовать V-модель. Эффективные коммуникации – необходимы. Частное: Аналитик, тестировщик и специалист по внедрению и сопровождению в одном лице – эффективно. Скорость поставки доработки часто важнее, чем ее качество. Подводя итоги 20/21

Спасибо! Вопросы? Максим Цепков