Сообщений в теме: 4

[Antonio777]

Добрый день всем! :)

На проекте столкнулся с проблемой измерения качества итерации (двухнедельные спринты).
Как правильно организовать? Брать в расчет отношение дефектов к фиче? Так фичи бывают разные. Дефектов к строкам кода? Код не всегда ревьюится. Дефектов к тест-кейсам (с учетом регламентированной атомарности тест-кейсов)? Не всегда есть необходимость покрытия всего функционала тест-кейсами.
В общем, если есть "рабочие рецепты", было бы здорово услышать.

Заранее спасибо всем! :)

[checo]

А просто количество дефектов на спринт? Спринты фиксированные, можно считать суммарную сложность фич за итерацию примерно одинаковой.

[Antonio777]

Спасибо за совет! :)

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

[jjjzmey]

Все фичи сделаны и работают - значит итерация качественная, что-то неуспели или не работает - соответственно некачественная

[mmeriin]

Если доступен код от разработчиков, то я бы попробовал посчитать плотность ошибок по каждой тушке разработчика.
Т.е. примерно такая табличка:

ФИО разраба; Кол-во ошибок на 100 (1000, 10 000 ...) строк кода
Иванов; 97
Петров; 315
Сидоров; 914

Т.о. Вы примерно будете представлять, что от кого ждать, и будите примерно знать, когда заканчивать тестирование.

Ну и какчество считается отсюда же :)

Плюс у вас есть дополнительная ксива для новоумных менеджеров, которые думают, что тестировщики должны найти все дефекты и т.д.
Оччччень полезная статистика...