�ݺ�ߣ

Software Quality Assurance Days
10-я Международная конференция
2-3 декабря 2011, Москва

Аналитик и Тестировщик
в одном лице – путь к качеству

Докладчик:
Максим Цепков (M.Tsepkov@custis.ru)
www.custis.ru

О чем этот доклад?
 Процесс разработки и разделение ролей:
• Классика – водопад, разделение ролей – оттуда.
• IT-отрасль меняется, меняются и модели.

 Есть альтернатива – модель аналитика-заказчика:
• В команде – аналитики-тестировщики и разработчики.
• Делимся опытом успешного использования.

Смотрим на опыт других
и вырабатываем свой подход.

2/21

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

http://en.wikipedia.org/wiki/V-Model_(software_development) 3/21

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

4/21

Agile – мировой тренд
Это просто факт
 Наблюдаемые признаки:
• Признание и использование Agile в ведущих IT-компаниях
и в inhouse-разработке.
• Явное упоминание Agile в базовых документах (SWEBOK, PMBOK).
• Россия – в русле мирового развития.

 Мечта о едином, эталонном процессе похоронена.
• Даже в варианте «возьмите только нужное» (PMBOK).
 Делаем процесс, адекватный проекту и компании!
• SCRUM/Canban/XP – лишь распространенные комбинации.
• Комбинируем известные успешные практики, придумываем свои.
• Фокус на эффективные коммуникации и автономность команды.

5/21

Водопад ушел – роли остались
Бизнес-аналитик  Каждой стадии –
своя роль.
Requirements  Роли выполняются
Системный аналитик
разными людьми
или командами.
Design
 Передача работы –
через артефакты
Implementation на отдельных языках.

Разработчик
Verification А где заказчик?
Тестировщик
Maintenance
Модель водопада –
Внедренец http://en.wikipedia.org/wiki/
Waterfall_model

6/21

Роли водопада на V-модели
 Коммуникации – лишь с соседями.
 Длинный цикл общения ведет к потере информации.
Заказчик
Concept Maintenance

Бизнес- Requirements
System Внедренцы
аналитики and
Verification
Architecture

Системные Detailed Integration
Design and Test Тестировщики
аналитики
Implementation

Разработчики
7/21

Изменение видения проекта…
Что хотели
Старый известный образ...

5
Заказчик

Concept Maintenance

1 Бизнес- Requirements Внедренцы
System
аналитики and
Verification
Architecture

Системные Detailed Integration
Тестировщики
аналитики Design and Test

2 Implementation 4

3

8/21

Что предлагает Agile?
 Кросс-функциональная команда разработчиков.
 Взаимодействие с заказчиком через Product Owner’а.

Заказчик

Concept Maintenance Конструкция SCRUM,
Product в других методах –
Owner
Requirements
System аналогично
and
Verification
Architecture

Detailed Integration
Design and Test

Implementation

Команда
9/21

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

Команда 10/21

Ищем хорошие варианты

В духе Agile

11/21

Специализация внутри команды
 Кросс-функциональная команда не означает полной
взаимозаменяемости, возможна специализация.
 Снижается нагрузка на Product Owner’а.
 Большое число ролей затрудняет коммуникации.
 Неравномерная нагрузка на роли в ходе проекта.

Заказчик
Concept Maintenance
Product
Requirements Owner System
Аналитики and Verification Тестировщики
Architecture

Design and Test
Implementation

Разработчики 12/21

Есть проекты, где аналитики мало
 Команда разработчиков и тестировщиков –
распространенный вариант.
 Две роли – не много, но достаточно.
 Не подходит, когда аналитической работы много.

Заказчик
Concept Maintenance

Product Requirements System
Owner and Verification Тестировщики
Architecture

Design and Test
Implementation


13/21

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

Implementation


14/21

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

15/21

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

Все вместе дает высокое качество услуги
для заказчика.

16/21

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

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

Рост новичков в команде
 Активность аналитика начинается с тестирования:
освоение системы и бизнес-области.
 Активность разработчика начинается с реализации по
проработанным постановкам.
 Постепенно области расширяются…
Заказчик

Concept Maintenance

Requirements
Аналитики- and
System
Verification Начинающий
тестировщики Architecture
аналитик-
Detailed Integration тестировщик
Design and Test
Начинающий
Implementation
разработчик

Разработчики 19/21

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

20/21

Спасибо!
Вопросы?

Максим Цепков
M.Tsepkov@custis.ru

�ݺ�ߣ

Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Days-2011)

Recommended

More Related Content

What's hot (20)

Similar to Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Days-2011) (20)

More from CUSTIS (20)

Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Days-2011)