'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


×

HTML:





Ссылка: