И где я это «подметил»? :) Название означает, что благодаря таким наблюдениям, можно внести нежелательные последствия в работу команды.
Метрики обычно используются не для «премировать и штрафовать», а для повышения эффективности работы команды, в том числе и при помощи их анализа.
Как раз они будут руководство нецелесообразностью, а метриками (кол-во багов одному идет в минус, другому в плюс). В итоге могут потерять несколько часов (и не только своих), вместо того, чтобы прийти к консенсусу за минуту :)
Как раз смысл в том, что у метрик есть побочные эффекты, которые не так очевидны. И их можно не увидеть до внедрения.
А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
Там важное уточнение: … необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.
Почему-то никто не пишет про самое главное — про итеративность. Сегодня большинство компаний используют итеративные методологии, поэтому умение распределять проектирование по итерациям (люблю слово «размазывать») является очень важным.
То что описал предыдущий автор — это классический пример антипаттерна «паралич анализа» (http://sourcemaking.com/antipatterns/analysis-paralysis). Бороться с ним очень просто: жестко таймбоксите нулевой спринт, требования готовьте в виде беклога (сверху подробного расписанные ЮС, снизу — эпики), архитектуру прорабатывайте сверху (не ныряйте глубоко), вовлекайте заказчика и общайтись с ним, если делаете прототипы — распределите их по спринтам, но с опережением разработчиков на один спринт.
Вообще если стоит такая проблема, используйте таймбоксинг везде, либо возьмите целиком готовую методологию Scrum. Есть желание написать статью, но нет времени, да и доклад делал на эту тему: ekt.agiledays.ru/ (Использование ICONIX для анализа требований в Scrum)
Метрики обычно используются не для «премировать и штрафовать», а для повышения эффективности работы команды, в том числе и при помощи их анализа.
А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
То что описал предыдущий автор — это классический пример антипаттерна «паралич анализа» (http://sourcemaking.com/antipatterns/analysis-paralysis). Бороться с ним очень просто: жестко таймбоксите нулевой спринт, требования готовьте в виде беклога (сверху подробного расписанные ЮС, снизу — эпики), архитектуру прорабатывайте сверху (не ныряйте глубоко), вовлекайте заказчика и общайтись с ним, если делаете прототипы — распределите их по спринтам, но с опережением разработчиков на один спринт.
Вообще если стоит такая проблема, используйте таймбоксинг везде, либо возьмите целиком готовую методологию Scrum. Есть желание написать статью, но нет времени, да и доклад делал на эту тему: ekt.agiledays.ru/ (Использование ICONIX для анализа требований в Scrum)