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

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

4. Процесс разработки и роли
4/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
Разработчики

11. Ищем хорошие варианты
В духе Agile
11/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

21. Спасибо!
Вопросы?
Максим Цепков
M.Tsepkov@custis.ru