Anton Stoliar SQADays2012 Управление качеством в Agile. Как...

Post on 23-Dec-2014

326 views 2 download

description

1. Цель презентации: • Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах. • Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт 2. Какова практическая ценность презентации для аудитории: • Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline • Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки. 3. Для кого предназначена: • QA которые уже работали по Agile (Scrum в частности) • Начинающие ПМs и QA Team Leads • Ребята которым скоро придется лидать Agile-проекты 4. Короткий план презентации по шагам: • Чего могут жать от работы QA команды к зависимости от специфики проекта\компании • Чего ожидают от QA в Agile • Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени

Transcript of Anton Stoliar SQADays2012 Управление качеством в Agile. Как...

Управление качеством в Agile. Как опередить баги.

Антон Столяр. EPAM Systems

- >3 лет Agile экспертизы

- Проекты: от 3 до 70 человек

- Senior Software Testing Engineer

Email: anton.stolyar@gmail.com

FB: https://www.facebook.com/anton.stolyar

Антон Столяр

Чего от вас ждет ваш проект как от QA?

QAaaS

Отчеты! Дефекты!

Поддержка?

Уровень сопровождения продукта (SLA)

Мы гарантируем качество ТОЛЬКО на критическом пути

Рамочные проекты

А бывает иначе!• Agile Манифест 2.1

• Команда и ответственность важнее индивидуумов и взаимодействия

• Бизнес ценность важнее рабочего продукта. Сам продукт не имеет ценности. Важно то, что вы можете сделать при его помощи.

• Развитие партнёрских отношений важнее сотрудничества с клиентом• Готовиться к изменениям важнее реакции на изменения

Полезные советы!

Несколько практик, как QA может улучшить продукт не найдя ни одного дефекта. Фокус на предотвращение дефектов.

Давайте договоримся!

Не путаем Scrum

И Scrumно

Еще момент!

• У Вас достаточно полномочий / лидерства

• Ваш Scrum действительно напоминает Scrum (а не только Stand-ups)

• Вы хотите улучшить текущий процесс.

Виденье продукта

Есть ли у каждого участника команды единое понимание Виденья продукта?

Виденье продукта

продукта?

Виденье продукта

Виденье продукта

Преимущества• Легко внедрить• У всей команды одинаковое понимание продукта• Как следствие меньше ошибок в реализации логики• Меньше переделок

Подводные камни• Вы сами не понимаете в чем заключается Vision продукта• Очень хлопотно получить от заказчика этот злосчастный Vision

Планируем Спринт

Планируем Спринт

Задача 1:Команда разработки набрала задач учитывая Dev Velocity.

Команда QA оценила тестирование всех задач в 240 часов.

Capacity всей QA команды 100 часов.

Вопрос: где взять еще 140 часов на тестирование?

Планируем Спринт

Задача 2:Эффект набегающей волны

Планируем Спринт

Задача 2:Эффект набегающей волны

Планируем Спринт

Хороших выходных

Планируем Спринт

Планируем Спринт

Планируем Спринт

Итого:

• Планируем спринт так чтобы успело УЗКОЕ ЗВЕНО.

• Не даем разработчикам тянуть с фиксами \ коммитами до

последнего дня.

• При спринте в 10 дней: 6-й день – Feature Freeze, 8-й день –

Code Freeze

Планируем Спринт

Преимущества• Внедряется за 1-2 спринта• Планируем более пессимистично -> более правдоподобно• Снижаем вероятность овертаймов для QA• Закладываем время на регрессию

Подводные камни• Не можем менять процесс разработки• Не пользуемся Story Points и Velocity • А у нас и так все хорошо

Минимальная функциональность для релиза

Release is coming….

А регрессия и не начиналась

Минимальная функциональность для релиза

• Этому учат на тренингах Certified Product Owner

Минимальная функциональность для релиза

Преимущества• Все горит, а регрессию еще не начинали• Понимаем что покрываем регрессией в первую очередь

Подводные камни• Ну нас достаточно времени чтобы протестировать все • Есть четкие и ясные приоритеты

Выводы Vision

Sprint Planning

Min Release

• Дешево и быстро внедрить• Понимание ценности

продукта для бизнеса позволяет принимать правильные решения и делать правильные вещи

• I’s just a thinking tools :-)

P.S.

P.S.

P.S.

P.S.

Спасибо!

Вопросы?