Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Измерение эффективности
процесса разработки
Подход и инструменты
Ковальская Ирина
Project Manager
1. Необходимость измерения (ЗАЧЕМ);
2. Какие показатели команды важны, что измерять (KPI);
3. Примеры кейсов;
4. Какие инс...
Зачем?
Задаем себе вопросы
1. Мы работаем в оптимальном режиме или можно лучше?
2. Количество багов допустимое или должно быть ме...
Цель
1. Контролировать процесс разработки;
2. Принимать правильные решения на основе данных;
3. Сделать прозрачным для ком...
KPI
План выполнения работ в текущем месяце
План в текущем месяце по командам
План выполнения работ в динамике
Распределение плановых задач и багов
Прохождение задач по flow
Эффективность процесса разработки
Неэффективное время процесса разработки
Причины возврата задач
Выполнение дедлайнов в срок
Плановые задачи Bug задачи
Жизненный цикл задач
Жизненный цикл задач. Тенденция
Соотношение найденных и закрытых багов
Покрытие новых задач автотестами
Покрытие найденных багов
Кейсы
Гипотеза
баги – не сложные функциональные задачи. Тестировать баг
достаточно 1 раз на приближенном окружении к production;...
Гипотеза
лучше доставлять задачи меньшими сборками, но чаще;
Анализ
сравнение количества задач в недельной и ежедневной сб...
Гипотеза
задачи долго ожидают тестирования;
Анализ
наибольший WastedTime в цепочке жизни задач не тестирование, а
ревью;
Р...
Как?
1. Источник данных
2. Хранение данных 3. Визуализация данных
Инструменты
Будьте готовы
1. Волнение перед неизвестностью, чем-то новым;
2. Одинаковый взгляд на то, зачем вы хотите что-то измерять;
3. Ответ, как...
Спасибо!
Ковальская Ирина
i.kovalskaya@owox.com | Skype: kovalskaya_irina
Upcoming SlideShare
Loading in …5
×

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

324 views

Published on

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

Published in: Technology
  • Login to see the comments

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

  1. 1. Измерение эффективности процесса разработки Подход и инструменты Ковальская Ирина Project Manager
  2. 2. 1. Необходимость измерения (ЗАЧЕМ); 2. Какие показатели команды важны, что измерять (KPI); 3. Примеры кейсов; 4. Какие инструменты понадобятся (КАК); 5. К чему нужно быть готовыми. Сегодня в программе
  3. 3. Зачем?
  4. 4. Задаем себе вопросы 1. Мы работаем в оптимальном режиме или можно лучше? 2. Количество багов допустимое или должно быть меньше? 3. Все ли дедлайны мы выполняем вовремя? 4. Есть ли у нас узкое горлышко в процессе доставки задач в production? 5. Справляемся ли мы с планом выполнения работ на месяц? 6. Успеваем ли мы закрывать все тикеты, которые поступают?
  5. 5. Цель 1. Контролировать процесс разработки; 2. Принимать правильные решения на основе данных; 3. Сделать прозрачным для команды состояние работы процессов.
  6. 6. KPI
  7. 7. План выполнения работ в текущем месяце
  8. 8. План в текущем месяце по командам
  9. 9. План выполнения работ в динамике
  10. 10. Распределение плановых задач и багов
  11. 11. Прохождение задач по flow
  12. 12. Эффективность процесса разработки
  13. 13. Неэффективное время процесса разработки
  14. 14. Причины возврата задач
  15. 15. Выполнение дедлайнов в срок
  16. 16. Плановые задачи Bug задачи Жизненный цикл задач
  17. 17. Жизненный цикл задач. Тенденция
  18. 18. Соотношение найденных и закрытых багов
  19. 19. Покрытие новых задач автотестами
  20. 20. Покрытие найденных багов
  21. 21. Кейсы
  22. 22. Гипотеза баги – не сложные функциональные задачи. Тестировать баг достаточно 1 раз на приближенном окружении к production; Анализ количество багов, вернувшихся разработчику после локального тестирования, 5%. После проверки на тестовом сервере – 30%; Решение сократить цикл тестирования багов, исключив локальное тестирование; Профит освободили ресурс тестирования; улучшили скорость доставки исправления багов (жизненный цикл) в 2 раза. Кейс 1 — двойное тестирование багов
  23. 23. Гипотеза лучше доставлять задачи меньшими сборками, но чаще; Анализ сравнение количества задач в недельной и ежедневной сборке; сравнение жизненного цикла задач до и после эксперимента. Решение изменить процесс доставки задач на ежедневный с количеством готовых задач; Профит баги исправляются быстрее; легче собирать и тестировать небольшие сборки. Кейс 2 — доставка сборок с багами
  24. 24. Гипотеза задачи долго ожидают тестирования; Анализ наибольший WastedTime в цепочке жизни задач не тестирование, а ревью; Решение реализовать индикатор долгого нахождения задач в ревью тим- лидеру; построить уведомления о долгом нахождении задачи в статусе менеджеру. Профит уменьшили задержку задач в ревью; уменьшили WastedTime; улучшили жизненный цикл. Кейс 3 — узкое звено в доставке задач
  25. 25. Как?
  26. 26. 1. Источник данных 2. Хранение данных 3. Визуализация данных Инструменты
  27. 27. Будьте готовы
  28. 28. 1. Волнение перед неизвестностью, чем-то новым; 2. Одинаковый взгляд на то, зачем вы хотите что-то измерять; 3. Ответ, как это будет использовано на команде; 4. Предложения от команды о дополнительных графиках; 5. Доверие к данным. Сложности
  29. 29. Спасибо! Ковальская Ирина i.kovalskaya@owox.com | Skype: kovalskaya_irina

×