Measuring the agile process improvement (Константин Савенков, SECR-2015) — различия между версиями

Материал из 0x1.tv

 
(не показано 25 промежуточных версий этого же участника)
== Видео ==

{{vimeoembed|143683474|800|450}}

{{youtubelink|AfLc7QzhUV8}}{{letscomment}}

== Слайды ==
[[File:Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

* [http://2015.secrus.ruorg/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=2017-12-25T21:45:232021-08-31T16:28:40.552098629270|vimeo_comments=0|vimeo_plays=433|youtube_comments=0|youtube_plays=8}}10}}

Текущая версия на 13:28, 31 августа 2021

Аннотация

Докладчик
Константин Савенков.jpg
Константин Савенков

Процесс разработки нужно постоянно улучшать, чтобы справляться с проблемами роста, обновления команды и улучшать общую производительность. Для этого его нужно оценивать и измерять, а это сложно. Большая часть подходов субъективна или имеет слабое отношение к реальности.

Для измерения качества процесса разработки сейчас используются различные метрики:

  • процент завершенных историй из запланированных (количество завершенных историй / количество запланированных историй)
  • технический долг (изменение размера бэклога, связанного с техническим долгом)
  • скорость команды (количество пойнтов за итерацию)
  • ускорение команды (изменение количества пойнтов за итерацию)
  • цикл истории (время от планирования до завершения)
  • цикл приемки (время от завершения до релиза или положительной реакции пользователей)
  • точность оценки (соотношение реальной и запланированной трудоемкости для завершенных историй)
  • количество дефектов на цикл релиза
  • количество дефектов на единицу трудоемкости
  • количество выполненных тестов

Проанализировав эти метрики, можно придти к выводу, что почти все они обладают одним из следующих недостатков:

  • привязка к размеру истории
  • привязка к размеру стори пойнта

Эти показатели отличаются для разных команд, плюс могут изменяться с течением времени для одной команды. Также эти метрики не выстраиваются в дерево KPI, они сделаны ad-hoc по следам проблем, существовавших в отдельных командах.

В данном докладе предлагается система KPI для разработки ПО, для команды бережливой (lean) разработки SAAS, основная задача которой – провести максимальное количество экспериментов по улучшению продукта за итерацию:

  • они представляют собой дерево KPI, в корне которого – продуктивность (предполагаемая трудоемкость запланированных и завершенных историй / потенциальные ресурсы трудоемкости команды). Данный KPI показывает, насколько команда способна выполнять в срок запланированные эксперименты.
  • при помощи анализа соотношений (ratio analysis) продуктивность раскладывается на следующие составляющие:
    • точность оценки (предполагаемая трудоемкость запланированных и завершенных историй / фактическая трудоемкость запланированных и завершенных историй)
    • способность завершать начатое (фактическая трудоемкость запланированных и завершенных историй / количество ресурсов, потраченных в итерации на запланированные задачи)
    • способность планировать задачи (количество ресурсов, потраченных в итерации на запланированные задачи / общее количество ресурсов, потраченных в ходе итерации)
    • степень использования ресурсов (общее количество ресурсов, потраченных в ходе итерации / потенциальные ресурсы трудоемкости команды)

Достоинства предлагаемой системы KPI:

  • они инвариантны к используемой единице трудоемкости и ее текущему выражению в человеко-часах
  • они инвариантны к средней трудоемкости истории
  • это, в свою очередь, позволяет оценивать динамику изменения KPI для команды с течением времени и сравнивать различные команды
  • продуктивность полностью раскладывается на KPI второго порядка, что позволяет однозначно определить узкие места в процессе разработки

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Слайды

Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf Measuring the agile process improvement (Константин Савенков, SECR-2015).pdf

Примечания и отзывы

Plays:53   Comments:0