Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Days-2011)
1. Software Quality Assurance Days
10-я Международная конференция
2-3 декабря 2011, Москва
Аналитик и Тестировщик
в одном лице – путь к качеству
Докладчик:
Максим Цепков (M.Tsepkov@custis.ru)
www.custis.ru
2. О чем этот доклад?
Процесс разработки и разделение ролей:
• Классика – водопад, разделение ролей – оттуда.
• IT-отрасль меняется, меняются и модели.
Есть альтернатива – модель аналитика-заказчика:
• В команде – аналитики-тестировщики и разработчики.
• Делимся опытом успешного использования.
Смотрим на опыт других
и вырабатываем свой подход.
2/21
3. Визуальное представление ролей
Для эффективного обсуждения Диаграммы –
фишка
нужно графическое представление.
Это оказалось удобно делать на схеме V-модели.
http://en.wikipedia.org/wiki/V-Model_(software_development) 3/21
5. Agile – мировой тренд
Это просто факт
Наблюдаемые признаки:
• Признание и использование Agile в ведущих IT-компаниях
и в inhouse-разработке.
• Явное упоминание Agile в базовых документах (SWEBOK, PMBOK).
• Россия – в русле мирового развития.
Мечта о едином, эталонном процессе похоронена.
• Даже в варианте «возьмите только нужное» (PMBOK).
Делаем процесс, адекватный проекту и компании!
• SCRUM/Canban/XP – лишь распространенные комбинации.
• Комбинируем известные успешные практики, придумываем свои.
• Фокус на эффективные коммуникации и автономность команды.
5/21
6. Водопад ушел – роли остались
Бизнес-аналитик Каждой стадии –
своя роль.
Requirements Роли выполняются
Системный аналитик
разными людьми
или командами.
Design
Передача работы –
через артефакты
Implementation на отдельных языках.
Разработчик
Verification А где заказчик?
Тестировщик
Maintenance
Модель водопада –
Внедренец http://en.wikipedia.org/wiki/
Waterfall_model
6/21
7. Роли водопада на V-модели
Коммуникации – лишь с соседями.
Длинный цикл общения ведет к потере информации.
Заказчик
Concept Maintenance
Бизнес- Requirements
System Внедренцы
аналитики and
Verification
Architecture
Системные Detailed Integration
Design and Test Тестировщики
аналитики
Implementation
Разработчики
7/21
8. Изменение видения проекта…
Что хотели
Старый известный образ...
5
Заказчик
Concept Maintenance
1 Бизнес- Requirements Внедренцы
System
аналитики and
Verification
Architecture
Системные Detailed Integration
Тестировщики
аналитики Design and Test
2 Implementation 4
Разработчики
3
8/21
9. Что предлагает Agile?
Кросс-функциональная команда разработчиков.
Взаимодействие с заказчиком через Product Owner’а.
Заказчик
Concept Maintenance Конструкция SCRUM,
Product в других методах –
Owner
Requirements
System аналогично
and
Verification
Architecture
Detailed Integration
Design and Test
Implementation
Команда
Разработчики
9/21
10. Плюсы и минусы
Эффективные коммуникации.
Возможность быстрой обратной связи.
Большая нагрузка на Product Owner’а.
Расширение зоны ответственности Заказчика.
Слишком разнообразная работа членов команды.
Заказчик
Concept Maintenance
Product
Owner Requirements System Подходит далеко
and
Architecture
Verification не для всех проектов.
Detailed Integration
Design and Test
Implementation
Команда 10/21
Разработчики
12. Специализация внутри команды
Кросс-функциональная команда не означает полной
взаимозаменяемости, возможна специализация.
Снижается нагрузка на Product Owner’а.
Большое число ролей затрудняет коммуникации.
Неравномерная нагрузка на роли в ходе проекта.
Заказчик
Concept Maintenance
Product
Requirements Owner System
Аналитики and Verification Тестировщики
Architecture
Detailed Integration
Design and Test
Implementation
Разработчики 12/21
13. Есть проекты, где аналитики мало
Команда разработчиков и тестировщиков –
распространенный вариант.
Две роли – не много, но достаточно.
Не подходит, когда аналитической работы много.
Заказчик
Concept Maintenance
Product Requirements System
Owner and Verification Тестировщики
Architecture
Detailed Integration
Design and Test
Implementation
Разработчики
13/21
14. Модель внутреннего заказчика
Аналитики получают требования заказчика
и формулируют задачу разработчикам.
Они же принимают результат разработки
и передают его заказчику.
Новое – хорошо
Заказчик забытое старое.
Concept Maintenance
Product
Requirements Owner
and
System Аналитики-
Verification
Architecture тестировщики
Detailed Integration
Design and Test
Implementation
Разработчики
14/21
15. Область применения модели
Для проектов с полным набором активностей.
CUSTIS – заказная разработка: обследование,
постановка, разработка, внедрение, развитие.
Для продуктовой разработки тоже применима.
Модель распространена в мире
Пауль Тернер на Req-Labs.
15/21
16. Преимущества модели
Автономность команды разработки.
Эффективные коммуникации внутри и с заказчиком.
Быстрая реакция на требования заказчика
(скорость поставки часто важнее качества продукта).
Прием результата разработки аналитиком повышает
соответствие системы ожиданиям заказчика.
Две роли в команде – возможность дублирования.
Равномерная нагрузка на роли в ходе проекта.
Все вместе дает высокое качество услуги
для заказчика.
16/21
17. Почему аналитика, тестирование,
внедрение – схожая активность?
Представить работу пользователя с системой:
• Бизнес-сценарии – основа требований и тестов. Это все – общие
• Основные активности пользователей, эргономика. активности.
• Сложные случаи – для проектирования и проверки.
Общение с Заказчиками и Пользователями:
• Выяснение их работы и ее особенностей.
• Уточнение при альтернативных В аналитике
и спорных моментах. и тестировании
• Объяснение работы системы. есть место
• Консультации по сложным случаям. и сенсорикам,
и интуитам.
Взаимодействие с разработчиками.
17/21
18. Опыт CUSTIS – типовая команда*
Соотношение разработчиков и аналитиков – 2:1.
6–7 (4–11) человек: 4 разработчика, 2 аналитика
и руководитель проекта (Product Owner).
Члены команды могут заменять друг друга с учетом
специализации. У руководителя тоже есть зам.
Применение DDD дает единый язык общения.
Часть разработчиков и аналитиков – начинающие,
они растут и набирают опыт.
По мере роста опытные сотрудники уходят
в новые проекты, а новички – приходят.
* Для сложных проектов, развивающихся 3–10 лет после внедрения.
18/21
19. Рост новичков в команде
Активность аналитика начинается с тестирования:
освоение системы и бизнес-области.
Активность разработчика начинается с реализации по
проработанным постановкам.
Постепенно области расширяются…
Заказчик
Concept Maintenance
Requirements
Аналитики- and
System
Verification Начинающий
тестировщики Architecture
аналитик-
Detailed Integration тестировщик
Design and Test
Начинающий
Implementation
разработчик
Разработчики 19/21
20. Подводя итоги
Общее:
Создавайте разделение ролей исходя из проекта.
Для визуализации хорошо использовать V-модель.
Эффективные коммуникации – необходимы.
Частное:
Аналитик, тестировщик и специалист по внедрению
и сопровождению в одном лице – эффективно.
Скорость поставки доработки часто важнее,
чем ее качество.
20/21