Аналитик-тестировщик

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

Визуальное представление ролей
Для эффективного обсуждения
нужно графическое представление.
Это оказалось удобно делать на схеме V-модели.
/21
http://en.wikipedia.org/wiki/V-Model_(software_development)

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

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

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

Роли водопада на V-модели
Коммуникации – лишь с соседями.
Длинный цикл общения ведет к потере информации.
/21

Изменение видения проекта…
/21
Что хотели
1
2
3
4
5

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

Эффективные коммуникации.
Возможность быстрой обратной связи.
Большая нагрузка на Product Owner’а.
Расширение зоны ответственности Заказчика.
Слишком разнообразная работа членов команды.
Плюсы и минусы
/21

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

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

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

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

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

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

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

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

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

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