Measuring the agile process improvement (Константин Савенков, SECR-2015) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
<!-- <blockquote>[©]</blockquote> -->
* [http://2015.secr.ru/lang/ru/program/submitted-presentations/measuring-the-agile-process-improvement Страница доклада на сайте конференции]
{{fblink|1663335810586100}}
{{vklink|104}}
<references/>
<!-- -->
[[Категория:SECR-2015]]
[[Категория:Agile process]]
{{stats|disqus_comments=0|refresh_time=2020-07-05T22:55:0106T00:42:21.837847319934|vimeo_comments=0|vimeo_plays=40|youtube_comments=0|youtube_plays=10}} | |||
Версия 21:42, 5 июля 2020
Содержание
Аннотация
- Докладчик
- Константин Савенков
Процесс разработки нужно постоянно улучшать, чтобы справляться с проблемами роста, обновления команды и улучшать общую производительность. Для этого его нужно оценивать и измерять, а это сложно. Большая часть подходов субъективна или имеет слабое отношение к реальности.
Для измерения качества процесса разработки сейчас используются различные метрики:
- процент завершенных историй из запланированных (количество завершенных историй / количество запланированных историй)
- технический долг (изменение размера бэклога, связанного с техническим долгом)
- скорость команды (количество пойнтов за итерацию)
- ускорение команды (изменение количества пойнтов за итерацию)
- цикл истории (время от планирования до завершения)
- цикл приемки (время от завершения до релиза или положительной реакции пользователей)
- точность оценки (соотношение реальной и запланированной трудоемкости для завершенных историй)
- количество дефектов на цикл релиза
- количество дефектов на единицу трудоемкости
- количество выполненных тестов
Проанализировав эти метрики, можно придти к выводу, что почти все они обладают одним из следующих недостатков:
- привязка к размеру истории
- привязка к размеру стори пойнта
Эти показатели отличаются для разных команд, плюс могут изменяться с течением времени для одной команды. Также эти метрики не выстраиваются в дерево KPI, они сделаны ad-hoc по следам проблем, существовавших в отдельных командах.
В данном докладе предлагается система KPI для разработки ПО, для команды бережливой (lean) разработки SAAS, основная задача которой – провести максимальное количество экспериментов по улучшению продукта за итерацию:
- они представляют собой дерево KPI, в корне которого – продуктивность (предполагаемая трудоемкость запланированных и завершенных историй / потенциальные ресурсы трудоемкости команды). Данный KPI показывает, насколько команда способна выполнять в срок запланированные эксперименты.
- при помощи анализа соотношений (ratio analysis) продуктивность раскладывается на следующие составляющие:
- точность оценки (предполагаемая трудоемкость запланированных и завершенных историй / фактическая трудоемкость запланированных и завершенных историй)
- способность завершать начатое (фактическая трудоемкость запланированных и завершенных историй / количество ресурсов, потраченных в итерации на запланированные задачи)
- способность планировать задачи (количество ресурсов, потраченных в итерации на запланированные задачи / общее количество ресурсов, потраченных в ходе итерации)
- степень использования ресурсов (общее количество ресурсов, потраченных в ходе итерации / потенциальные ресурсы трудоемкости команды)
Достоинства предлагаемой системы KPI:
- они инвариантны к используемой единице трудоемкости и ее текущему выражению в человеко-часах
- они инвариантны к средней трудоемкости истории
- это, в свою очередь, позволяет оценивать динамику изменения KPI для команды с течением времени и сравнивать различные команды
- продуктивность полностью раскладывается на KPI второго порядка, что позволяет однозначно определить узкие места в процессе разработки
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Слайды
Примечания и отзывы
Plays:50 Comments:0