Доклад Антона Столяра на конференции SQA Days-12, 30 ноября-1 декабря, Минск

1. Управление качеством в Agile.
Как опередить баги.
Антон Столяр. EPAM Systems

2. Антон Столяр
- >3 лет Agile экспертизы
- Проекты: от 3 до 70 человек
- Senior Software Testing Engineer
Email: anton.stolyar@gmail.com
FB: https://www.facebook.com/anton.stolyar

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

4. QAaaS
Отчеты! Дефекты!

5. Поддержка?
Уровень сопровождения продукта (SLA)
Мы гарантируем
качество
ТОЛЬКО на
критическом
пути

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

7. А бывает иначе!
• Agile Манифест 2.1
• Команда и ответственность важнее индивидуумов и взаимодействия
• Бизнес ценность важнее
рабочего продукта. Сам продукт
не имеет ценности. Важно то,
что вы можете сделать при его
помощи.
• Развитие партнёрских отношений важнее сотрудничества с клиентом
• Готовиться к изменениям важнее реакции на изменения

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

9. Давайте договоримся!
Не путаем Scrum
И Scrumно

10. Еще момент!
• У Вас достаточно полномочий /
лидерства
• Ваш Scrum действительно напоминает
Scrum (а не только Stand-ups)
• Вы хотите улучшить текущий процесс.

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

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

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

14. Виденье продукта
Преимущества
• Легко внедрить
• У всей команды одинаковое понимание продукта
• Как следствие меньше ошибок в реализации логики
• Меньше переделок
Подводные камни
• Вы сами не понимаете в чем заключается Vision продукта
• Очень хлопотно получить от заказчика этот злосчастный Vision

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

16. Планируем Спринт
Задача 1:
Команда разработки набрала задач учитывая
Dev Velocity.
Команда QA оценила тестирование всех задач
в 240 часов.
Capacity всей QA команды 100 часов.
Вопрос: где взять еще 140 часов на
тестирование?

17. Планируем Спринт
Задача 2:Эффект набегающей волны

18. Планируем Спринт
Задача 2:Эффект набегающей волны

19. Планируем Спринт
Хороших выходных

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

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

22. Планируем Спринт
Итого:
• Планируем спринт так чтобы успело УЗКОЕ ЗВЕНО.
• Не даем разработчикам тянуть с фиксами коммитами до
последнего дня.
• При спринте в 10 дней: 6-й день – Feature Freeze, 8-й день –
Code Freeze

23. Планируем Спринт
Преимущества
• Внедряется за 1-2 спринта
• Планируем более пессимистично -> более правдоподобно
• Снижаем вероятность овертаймов для QA
• Закладываем время на регрессию
Подводные камни
• Не можем менять процесс разработки
• Не пользуемся Story Points и Velocity
• А у нас и так все хорошо 

24. Минимальная
функциональность для релиза
Release is coming….
А регрессия и не начиналась

25. Минимальная
функциональность для релиза
• Этому учат на тренингах Certified Product Owner

26. Минимальная
функциональность для релиза
Преимущества
• Все горит, а регрессию еще не начинали
• Понимаем что покрываем регрессией в первую очередь
Подводные камни
• Ну нас достаточно времени чтобы протестировать все 
• Есть четкие и ясные приоритеты

27. Выводы Vision
• Дешево и быстро внедрить
Sprint
• Понимание ценности Planning
продукта для бизнеса
позволяет принимать Min
Release
правильные решения и делать
правильные вещи
• I’s just a thinking tools :-)

28. P.S.

29. P.S.

30. P.S.

31. P.S.

32. Спасибо!
Вопросы?