А какие аспекты конкретно интересуют? У меня есть желание еще написать на данную тему…

Я почему спросил: когда руководитель проекта сам оценивает задачи и раздает их девелоперам, у него не очень много времени на стратегические задачи…

И где я это «подметил»? :) Название означает, что благодаря таким наблюдениям, можно внести нежелательные последствия в работу команды.
Метрики обычно используются не для «премировать и штрафовать», а для повышения эффективности работы команды, в том числе и при помощи их анализа.

Я как метафору использовал :) А вот какой метафорой может быть корпускуляно-волновой дуализм пока слабо представляю :)

Похожая история в одной из ссылок из поста: local.joelonsoftware.com/wiki/Измерения_продуктивности

Работает?

Скорее статья о том, как не надо использовать метрики для «наказаний» :)

Как раз они будут руководство нецелесообразностью, а метриками (кол-во багов одному идет в минус, другому в плюс). В итоге могут потерять несколько часов (и не только своих), вместо того, чтобы прийти к консенсусу за минуту :)

Собственно, у меня пост про командные метрики. Индивидуальные метрики еще более опасными могут быть :)

А при такой схеме «не выгодно» ли забивать на мелкие баги, а искать только баги с большим весом? :)

В спецификации написано с большой буквы, а в корпоративной политике с маленькой…

Абсолютно согласен. Могу добавить только то, что по системам/субсистемам есть очень много интересных мыслей у Гольдрата.

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

Пример из жизни: на сайте (или в диалоговом окне) слово «Вы» написано с большой буквы. Дефект? :)

Там важное уточнение: … необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.

У нас сегодня после праздников одна команда скрамилась, как сборная Новой Зеландии вначале ролика…

Хорошая статья и очень интересные ссылки. Я бы еще добавил про управление качеством статистическими методами…

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

Скорее всего соберемся по .NET или PHP ближе к концу октября.