1.
Crystal Agile: процесс
обеспечивающий качество

2.
Состав команды
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разработчики имеют выраженную специализацию
• 1 тестировщик

3.
Внедрение процесса

4.
Артефакты
1.Резерв проекта
2.Резерв спринта
3.Планирование с игрой в покер
4.Ежедневные митинги
5.Диаграмма сгорания

5.
Что-то пошло не так?
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закрывался после
планирования
• Митинги отнимают много времени
• Автоматизация отсутствует

6.
Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спринт после
планирования итерации
• В угоду скорости страдает качество кода,
накапливается технический долг
• Время тестировщика тратится на активности не
связанные с тестированием

7.
Что дальше?
Лучше.Хуже
Время
col1

8.
Выбираем решение
• Прогнуться под
процесс
• Своя методология

9.
Crystal Agile
• Human-powered
• Ultralight
• Stretch-to-fit

10.
Решение проблем

11.
Внутреннее качество
1.Внедряем TDD
2.Сталкиваемся с проблемами на этапе
внедрения
3.Отказываемся от TDD в пользу BDD

12.
Проблемы планирования
• Члены команды разбиты на группы,
поддерживающие разные модули
• Разработчики используют разные языки
программирования
• Внутри групп используются различные по
сложности технологии
• Покер планирования не работает

13.
Проблемы покера
• Каждый член команды имеет равный вес,
что влечет за собой возможность
недооценки или переоценки необходимого
времени
• Время тестировщика оценивается всей
командой

14.
Что делать?
Переходим от покера планирования к методу взвешенных
экспертных оценок
1. В планировании участвуют только те кто будет разрабатывать
2. Вес голоса зависит от «релевантности» разработчика
3. Коэффициенты зависят от предыдущей эффективности
4. Обязательно вводим в планирование время на юнит тесты, не
даем оценок только по функционалу
5. Время на тестирование оценивается тестировщиком совместно
с ответственным разработчиком
6. Планирование нацелено на сокращение простоев
тестировщика

15.
Плючы подхода
• Оценки стали более точными, что
позволяет рационально планировать время
тестировщика в спринте
• Оценки учитывают все аспекты разработки
(BDD, интеграционное тестирование)

16.
Спринт не резиновый
• Некоторые страны не успевают дать список
задач до начала планирования
• В любой момент может появиться
«горящая» задача

17.
Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге каждый член команды имеет день в запасе на urgent задачи.
Как мы работаем с такими задачами:
• Если приходит задача емкость которой в человеко-часах больше, чем наш
резерв – задача переносится на следующий спринт
• Задачи меньшего размера берутся в работу лишь до того момента, пока есть
резерв
2. Уменьшаем технический долг

18.
Технический долг
Внутренний бэклог проекта содержит такие
задачи как:
• Рефакторинг
• Написание юнит- и компонентных тестов
• Написание автотестов по готовым
сценариям
• Работа с to-do

19.
Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назначение ответственного за разработку задачи
• Ограждение обычных разработчиков от лишних обсуждений
• Смена ответственных по окончании итерации

20.
Стендапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске
одним кратким, но понятным
комментарием.

21.
Внедряем автоматизацию
Наличие
«некрасивого»
автотеста
значительно лучше,
нежели его
отсутсвие

22.
Плюсы «некрасивых»
тестов
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю обратную связь
• Помогают вовлечь разработчиков в тестирование
• Являются заготовками для будущих «красивых» тестов

23.
Сервисы?
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска полного
теста в один клик
• Тесты можно включить в CI
• Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией
• Возможность создания Load и Security тестов

24.
Резработчики: привлекаем
внимание
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого
смысла:
- Быстрая обратная связь
- Возможность быстро и самостоятельно проверить качество
перед коммитом
2. Демонстрация Selenium IDE

25.
Разработчики: обучение
1. Возвращаем «подсевших» на качество разработчиков в родную
стихию:
- Переход от IDE к RC или WebDriver
- Выделение времени на перевод старых тестов с IDE на Java
2. SoapUI тесты для неподдатливых:
- Обучение созданию
- Расширение возможностей с Groovy
- CI

26.
Agile?

27.
Заключение
• Гибкая методология может быть гибко приспособлена под
нужды команды
• Не стоит бояться экспериментов с техниками
• По настоящему высокого качества можно достигнуть лишь тогда
когда над этим работает вся команда.
• В команде должен быть человек, который недоволен текущим
процессом

28.
+375-44-751 75
99
Вопросы
Igor.bondarenko@neklo.com