— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов. — Как определить узкие места технической команды и посчитать ее эффективность. — Удобные инструменты сбора, хранения и визуализации данных.

1. Измерение эффективности
процесса разработки
Подход и инструменты
Ковальская Ирина
Project Manager

2. 1. Необходимость измерения (ЗАЧЕМ);
2. Какие показатели команды важны, что измерять (KPI);
3. Примеры кейсов;
4. Какие инструменты понадобятся (КАК);
5. К чему нужно быть готовыми.
Сегодня в программе

3. Зачем?

4. Задаем себе вопросы
1. Мы работаем в оптимальном режиме или можно лучше?
2. Количество багов допустимое или должно быть меньше?
3. Все ли дедлайны мы выполняем вовремя?
4. Есть ли у нас узкое горлышко в процессе доставки задач в production?
5. Справляемся ли мы с планом выполнения работ на месяц?
6. Успеваем ли мы закрывать все тикеты, которые поступают?

5. Цель
1. Контролировать процесс разработки;
2. Принимать правильные решения на основе данных;
3. Сделать прозрачным для команды состояние работы
процессов.

6. KPI

7. План выполнения работ в текущем месяце

8. План в текущем месяце по командам

9. План выполнения работ в динамике

10. Распределение плановых задач и багов

11. Прохождение задач по flow

12. Эффективность процесса разработки

13. Неэффективное время процесса разработки

14. Причины возврата задач

15. Выполнение дедлайнов в срок

16. Плановые задачи Bug задачи
Жизненный цикл задач

17. Жизненный цикл задач. Тенденция

18. Соотношение найденных и закрытых багов

19. Покрытие новых задач автотестами

20. Покрытие найденных багов

21. Кейсы

22. Гипотеза
баги – не сложные функциональные задачи. Тестировать баг
достаточно 1 раз на приближенном окружении к production;
Анализ
количество багов, вернувшихся разработчику после локального
тестирования, 5%. После проверки на тестовом сервере – 30%;
Решение
сократить цикл тестирования багов, исключив локальное тестирование;
Профит
освободили ресурс тестирования;
улучшили скорость доставки исправления багов (жизненный цикл) в 2
раза.
Кейс 1 — двойное тестирование багов

23. Гипотеза
лучше доставлять задачи меньшими сборками, но чаще;
Анализ
сравнение количества задач в недельной и ежедневной сборке;
сравнение жизненного цикла задач до и после эксперимента.
Решение
изменить процесс доставки задач на ежедневный с количеством готовых
задач;
Профит
баги исправляются быстрее;
легче собирать и тестировать небольшие сборки.
Кейс 2 — доставка сборок с багами

24. Гипотеза
задачи долго ожидают тестирования;
Анализ
наибольший WastedTime в цепочке жизни задач не тестирование, а
ревью;
Решение
реализовать индикатор долгого нахождения задач в ревью тим-
лидеру;
построить уведомления о долгом нахождении задачи в статусе
менеджеру.
Профит
уменьшили задержку задач в ревью;
уменьшили WastedTime;
улучшили жизненный цикл.
Кейс 3 — узкое звено в доставке задач

25. Как?

26. 1. Источник данных
2. Хранение данных 3. Визуализация данных
Инструменты

27. Будьте готовы

28. 1. Волнение перед неизвестностью, чем-то новым;
2. Одинаковый взгляд на то, зачем вы хотите что-то измерять;
3. Ответ, как это будет использовано на команде;
4. Предложения от команды о дополнительных графиках;
5. Доверие к данным.
Сложности

29. Спасибо!
Ковальская Ирина
i.kovalskaya@owox.com | Skype: kovalskaya_irina