Embed Size (px)
Citation preview
Crystal Agile. Процесс обеспечивающий качество.
Igor Bondarenko. Intetics Co.
Состав команды и её особенности
• 5 Менеджеров• Распределенная команда:
– 3 центра разработки– 11 разработчиков
• Разработчики имеют выраженную специализацию• 1 тестировщик
1/27
Внедрение процесса
2/27
Артефакты
1.Резерв проекта2.Резерв спринта3.Планирование с игрой в покер4.Ежедневные митинги5.Диаграмма сгорания
3/27
Что-то пошло не так?!
• Тестирование «внезапно» стало сваливаться на последние 4-5 дней итерации
• Резерв спринта не закрывался после планирования• Митинги отнимают много времени • Автоматизация отсутствует
4/27
Анализ проблем
• Неэффективное планирование.• Система оценки времени на разработку
неэффективна• Невозможно закрыть спринт после
планирования итерации• В угоду скорости страдает качество кода,
накапливается технический долг• Время тестировщика тратится на активности не
связанные с тестированием
5/27
Выбор средства решения проблем
• Прогнуться под процесс
• Своя методология
6/27
Crystal Agile
• Human-powered• Ultralight• Stretch-to-fit
7/27
Решение проблем
8/27
Внутренне качество
1. Внедряем TDD
2. Сталкиваемся с проблемами на этапе внедрения
3. Отказываемся от TDD в пользу BDD
9/27
Проблемы планирования
• Члены команды разбиты на группы, поддерживающие разные модули
• Разработчики используют разные языки программирования
• Внутри групп используются различные по сложности технологии
• Покер планирования не работает
10/27
Проблемы покера
• Каждый член команды имеет равный вес, что влечет за собой возможность недооценки или переоценки необходимого времени
• Время тестировщика оценивается всей командой
11/27
Что делать?
Переходим от покера планирования к методу взвешенных экспертных оценок
1. В планировании участвуют только те кто будет разрабатывать
2. Вес голоса зависит от «релевантности» разработчика
3. Коэффициенты зависят от предыдущей эффективности
4. Обязательно вводим в планирование время на юнит тесты, не даем оценок только по функционалу
5. Время на тестирование оценивается тестировщиком совместно с ответственным разработчиком
6. Планирование нацелено на сокращение простоев тестировщика
12/27
Плюсы подобного подхода
• Оценки стали более точными, что позволяет рационально планировать время тестировщика в спринте
• Оценки учитывают все аспекты разработки (BDD, интеграционное тестирование)
13/27
Невозможность закрыть резерв спринта
• Некоторые страны не успевают дать список задач до начала планирования
• В любой момент может появиться «горящая» задача
14/27
Двух зайцев одним выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге каждый член команды имеет день в запасе на urgent задачи.
Как мы работаем с такими задачами:• Если приходит задача емкость которой в человеко-часах больше, чем
наш резерв – задача переносится на следующий спринт• Задачи меньшего размера берутся в работу лишь до того момента,
пока есть резерв
2. Уменьшаем технический долг
15/27
Технический долг
Внутренний бэклог проекта содержит такие задачи как:
• Рефакторинг• Написание юнит- и компонентных тестов• Написание автотестов по готовым сценариям• Работа с to-do
16/27
Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой доходило до 5 в день.
Решение проблемы: • Назначение ответственного за разработку задачи• Ограждение обычных разработчиков от лишних
обсуждений• Смена ответственных по окончании итерации
17/27
Стэндапы не нужны?
Перенос этой активности в Jira:• Start Work – Stop Work• Активность за день описывается в таске одним кратким,
но понятным комментарием.
18/27
Начало автоматизации
Наличие «некрасивого» автотеста значительно лучше, нежели его отсутсвие
19/27
Положительное влияние «некрасивых тестов»
Плюсы таких тестов в начале проекта:• Быстро создаются• Предоставляют быструю обратную связь• Помогают вовлечь разработчиков в тестирование• Являются заготовками для будущих «красивых» тестов
20/27
SoapUI для сервисов
• Низкий порог вхождения• Возможность быстро создать test suite для запуска
полного теста в один клик• Тесты можно включить в CI• Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией• Возможность создания Load и Security тестов
21/27
Вовлечение разработчиков:демонстрация
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого смысла:- Быстрая обратная связь- Возможность быстро и самостоятельно
проверить качество перед коммитом2. Демонстрация Selenium IDE
22/27
Вовлечение разработчиков:
обучение1. Возвращаем «подсевших» на качество разработчиков в
родную стихию:- Переход от IDE к RC или WebDriver- Выделение времени на перевод старых тестов с
IDE на Java2. SoapUI тесты для неподдатливых:
- Обучение созданию- Расширение возможностей с Groovy- CI
23/27
Заключение
• Гибкая методология может быть гибко приспособлена под нужды команды
• Не стоит бояться экспериментов с техниками• По настоящему высокого качества можно достигнуть
лишь тогда когда над этим работает вся команда.• В команде должен быть человек, который недоволен
текущим процессом
25/27
Что-то еще?
26/27
