Scrum, Kanban, XP, Quality Assistance

Обзор гибких методологий разработки ПО с точки зрения обеспечения качества.

Transcript

1. Scrum, Kanban, XP и Quality Assistance Обзор гибких методологий разработки ПО с точки зрения обеспечения качества Николай Смирнов | bercut.com | СПбПУ 2020
2. Обо мне • Преподаватель курса «Технологии разработки качественного ПО» с 2018 г. • Руководитель группы автоматизации тестирования отдела Платформы http://bercut.com • Фанат Java и DevOps 2
3. План 3 1. Agile: что ты такое? 2. Погружение в Scrum 3. Особенности Kanban 4. Quality Assistance 5. Практики XP для проактивного QA 6. Когда подходит Waterfall 7. Для чего вам это нужно
4. Agile – это не… • Методология • Фреймворк разработки ПО • Практики работы с командой • Способ управления проектом 4
5. Agile: 4 ценности + 12 принципов 5 01 Процессы и инструменты ЛЮДИ И ВЗАИМОДЕЙСТВИЕ 02 Исчерпывающая документация РАБОТАЮЩИЙ ПРОДУКТ 03 Согласование условий контракта СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ 04 Следование первоначальному плану ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ
6. Удовлетворение заказчика 6
7. Меняться никогда не поздно 7
8. Частые отгрузки – быстрый отзыв 8
9. Бизнес + технари = ❤ 9
10. Дрим-тим 10
11. Общайтесь 11
12. Всегда готов! 12
13. Беги, Форест, беги 13
14. Постоянно совершенствуй 14
15. Минимизируй лишнее 15
16. Brainstorming 16
17. Рефлексируй 17
18. SCRUM 18
19. Scrum = схватка 19 https://www.youtube.com/watch?v=UW8sTq8SuFQ
20. Scrum особенности • Хорош, когда неясен конечный результат, когда заказчик не знает, чего он хочет • 3-9 человек в команде • Фиксированный темп (обычно 2 недели) • Планирование на основе скорости команды storypoint/sprint • Результат спринта: готовый продукт 20
21. Product Backlog • Формирует и поддерживает Product Owner • Список требований к ПО (функциональных) = user story • Упорядочен по степени важности • Бизнес-ориентирован • Нет микроменеджменту 21
22. Что входит в User story 1. Название (краткое описание истории) 2. Важность (int). Чем больше, тем важнее 3. Предварительная оценка в story point (идеальные человеко-дни) 4. Как продемонстрировать 22
23. Пример User story 23
24. MoSCoW-приоритизация • Must have = кровь из носа • Should have = очень надо • Could have = было бы хорошо • Won’t have (this time) = норм, но не сейчас 24
25. Планирование спринта • Определить цель спринта • Понять и простить продукт оунера (содержание историй) • Оценить трудоемкость историй • Выбрать влезающие в спринт • Разбить истории на задачи 25
26. Sprint Backlog + задачи, для завершения истории 26
27. Сколько историй влезет? • Спросить у команды (интуитивный подход) • Вычислить на основе планируемой производительности команды: 1. Метод «вчерашней погоды» (как в прошлом спринте) 2. Метод определения доступных ресурсов (учитывает разную загрузку членов команды) 27
28. Доступные ресурсы (пример) • Длина спринта: 2 недели = 10 дней • Команда: Петя, Катя, Андрей. • Андрей = DBA, доступен проекту на 80% • Катя хочет взять 3 отгула. Петя=10 Катя=7 Андрей=8 28 Итого: 25 доступных человеко-дней
29. Плановая производительность (доступные человеко-дни) x (фокус-фактор) = (прогнозируемая производительность) 29
30. FF • Фокус-фактор – это коэффициент того, насколько команда сфокусирована на своих основных задачах. 30
31. Сколько же историй влезет? • Фокус-фактор последнего спринта: 18 story point/(10+10+8 человеко- дней)=60% • Прогнозируемая производительность спринта: 25x60% = 15 story points 31
32. Lifehacks планирования • Используйте доску • Вовлеченность участников (встреча долгая) • Параллельность работы с карточками • Разбивайте на задачи (без продукт оунера) 32
33. Оценка трудозатрат • Planning Poker • Оценивают все • Не отменяется специализация DB, UI, Backend, etc. • В идеальных человеко- часах • DefenitionOfDone на задачах 33 0 = «пара минут» ? = «не знаю» Кофе = «устал»
34. Scrum Master • Координирует роли и их функции • Измеряет продуктивность команды • «Оберегает» команду от вбросов • Приглашает на летучки, демо и ретро 34
35. Летучки (пример) 35
36. Летучки • Встреча на каждый день • Не больше 15 минут • Стоя • «Что я сделал вчера, чем буду заниматься сегодня» • Корректировка количества задач • Burndown диаграмма 36
37. Sprint Review 37
38. Sprint Review 38 ОБМЕН ОПЫТОМ Гости дают свою оценку 100% СДЕЛАНО Заставляет доделывать МОТИВАЦИЯ Апплодисменты приветствуются ДИНАМИЧНО Бизнес- ориентация ПРИГЛАШАЕМ ВСЕХ Публичная встреча ДЕМО
39. Ретро • Инструмент ухода от «граблей» • Регулярное проведение (после спринта или реже) • Высказываются все, в работу берём не всё • Что было хорошо? • Что могло быть лучше? • Что можно улучшить в следующем спринте? 39
40. Есть ли тестировщик в SCRUM? НЕТ (но куда же без них…) 40
41. Цена ошибки 41
42. QA в Scrum • Тестирование – это не фаза, а действие • Нет тестера – есть роль QA 42
43. Роль QA на планировании • Оценивает трудозатраты на тестирование userstory • Участвует в приоритизации • Понимает и разделяет цель спринта 43
44. Что делает роль QA в спринте • Помогает разработчикам в модульном тест-и • Выполняет тестирование userstory • Заводит отчёты о дефектах и верифицирует • Автоматизирует запуск тестов • Составляет и защищает отчёты о тестировании • Помогает составить приёмочные тесты с заказчиком, выполняет их 44
45. QA в начале спринта 45
46. QA в середине спринта 46
47. QA в конце спринта 47
48. Вывод QA – бутылочное горлышко процесса 48
49. Долгая обратная связь 49
50. Ответственность за баги на QA 50
51. Обеспечение качества в SCRUM Ответственность вся команда отвечает за качество Программируй все члены команды – разработчики Тесты это тоже программный продукт CI\CD непрерывная интеграция обязятальна
52. В любой непонятной ситуации Используй KANBAN 52
53. Эффект «Зейгарник» 53
54. KANBAN 54
55. Особенности KANBAN • Нет спринтов, есть встречи «пополнения» • Планирование исходя из времени прохождения заявки от ToDo до Done • Колонка на доске – часть конвейера • Приоритизация бэклога • Ограничение WIP 55
56. Выводы KANBAN по QA • Нет аврала, но • Долгая обратная связь 56
57. Quality Assistance • От Atlassian (Jira, Confluence, Bitbucket…) • Качество – ответственность всех • Дайте «девелоперу» самому исправить свои ошибки • Это не просто «а теперь тестить будут девелперы» • Сокращение бюрократии • QA – не ловец багов 57
59. Практики Quality Assistance • Blitz Testing – ограниченная по времени сессия тестирования всеми • Dogfooding – запуск незарелиженой версии продукта внутри компании • DoT – разработчик тестирует сам • QA Kickoff – проектирование с тестером 59
60. XP-практики проактивного QA • Парное программирование/автоматизация тестов • Ревью кода ПО/кода тестов • Непрерывная интеграция • Развитие стандартов кода/процессов • Коллективное владение кодом/тестами • Рефакторинг ПО/тестов • Статический анализ кода 60
61. Унесите это с собой “ Учитесь программировать. Это единственный навык, который вам потребуется для решения 95% своих задач в будущем. 61
62. Ссылки 1. Хенрик Книберг. Scrum и XP: заметки с передовой. – 2008 – http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the- trenches-rus-final.pdf 2. Саламаха Елена. Концепция построения процесса тестирования в Agile-проектах. – 2014 – https://www.youtube.com/watch?v=UW8sTq8SuFQ 3. Kanban Glossary. https://www.agilealliance.org/glossary/kanban 4. Mark Hrynczak. Moving from quality assurance to quality assistance. https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality- assistance 62
63. Контакты • nikolai.smirnov@gmail.com • nikolai.smirnov@bercut.com • https://t.me/nikolaismirnov • sng1402 • nikolai 63
64. Игра 64
65. Расписание • Водопад – 3 план (Оценка) + 6 разработка + 3 итог • Agile/Scrum – 1plan(оценка)+2do+1retro – 1+2+1 – 1+2+1 65
66. Водопад 66
67. Бизнес-требования • 90 % закрашено • Не меньше чем 3 цвета на каждом яйце • Цветы не могут быть синими • Красный с синим и жёлтый с зелёным не использовать на одном яйце • Не выходить за границы 67