Velocity (разработка программного обеспечения) - Velocity (software development)

Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален Найдите источники: Разработка программного обеспечения "Velocity"  – Новости  · газеты  · книги  · ученый  · JSTOR (Май 2018) (Узнайте, как и когда удалить этот шаблон сообщения)

Скорость это показатель выполненной работы, который часто используется в гибкая разработка программного обеспечения.^[1]

Скорость измерения иногда называют отслеживание скорости.^{[нужна цитата ]} Показатель скорости используется для планирования спринтов и измерения производительности команды. Нет никаких научных доказательств того, что измерение скорости улучшает эффективность планирования или работу команды. Кроме того, метрика может вводить в заблуждение.^{[согласно кому? ]}

Терминология

При отслеживании скорости используется следующая терминология.

Единица работы

Единица, выбранная командой для измерения скорости. Это может быть реальная единица, например инженер-часы, инженер-дней или Резерв продукта Предметы (PBI) или очки истории.^[2] Затем каждая задача в процессе разработки программного обеспечения должна оцениваться с точки зрения выбранной единицы.

Интервал

Интервал - это продолжительность каждой итерации в процессе разработки программного обеспечения, для которой измеряется скорость. Продолжительность перерыва определяется командой. Чаще всего интервал составляет неделю, но может быть и месяц.

Принцип

Основная идея скорости состоит в том, чтобы помочь командам оценить, сколько работы они могут выполнить за определенный период времени, исходя из того, как быстро аналогичная работа была выполнена ранее.^[3] Скорость - мера относительная. Другими словами, сырые числа мало что значат; главное - тенденция.^[4]

Критика

Одна из проблем со скоростью состоит в том, что она объединяет выполненную работу с точностью планирования. Другими словами, команда может увеличить скорость, оценивая задачи более консервативно. Если команда говорит, что задача займет четыре часа или оценивается в 4 балла вместо двух часов или двух баллов, их скорость будет выглядеть лучше (иногда это называется инфляцией баллов).^[5] Скорость не следует использовать в качестве показателя производительности.^[1]

Вторая проблема скорости заключается в том, что она не принимает во внимание качество, соответствие целям или приоритетам пользователей. Скорость можно увеличить, пренебрегая хорошим дизайном, рефакторингом, стандартами кодирования и техническим долгом. Простое выполнение функций как можно быстрее увеличивает скорость независимо от качества. Точно так же скорость включает работу, выполненную независимо от преимуществ этой работы. Например, создание функции, которая никому не нужна или в которой никто не нуждается, по-прежнему считается «выполненной работой», а завершение единицы работы, которая уходит от цели пользователя, такой как простота использования, - это движение в противоположном желаемом направлении. в Agile больше нравится концепция безнаправленной «скорости» из физики.^{[нужна цитата ]}

Третья проблема скорости заключается в том, что ее часто неправильно используют как меру эффективности или производительности команды. Скорость - это показатель проделанной работы, а не эффективности. Скорость может быть увеличена за счет сверхурочной работы или добавления членов команды, что не обязательно увеличивает эффективность или производительность.^{[нужна цитата ]}

Таким образом, скорость - это проблемная метрика, потому что ею легко манипулировать и часто неправильно используют в качестве индикатора эффективности.^{[нужна цитата ]}

Рекомендации