Вот такие дела:

1. Все таски в обязательном порядке имеют parent Scenario. Scenario обычно олицетворяет собой крупное бизнес-требование.
2. Таски изначально прикрепляются к спец. итерации "features list".
3. После планирования итерации часть тасков прикрепляется к текущей итерации (например "Итерация 23"), незакрытые в предыдущую — либо к текущей, либо к п. 2.
4. На каждую новую итерацию приходится делать queries типа "Итерация 23", "Таски <имя члена команды> на 23 итерацию" и т.п.
5. Баги сами по себе не связаны с итерациями, но на каждый баг руками создается по 2 таски — "Исправить баг ХХХ" и "Проверить баг ХХХ", которые цепляются к итерациям по общему принципу.

И меня стойкое ощущение, что это, по меньшей мере — убого, чревато ошибками и крайне трудозатратно.

Поэтому вопросы:

1. Действительно ли в TFS все так плохо? Или мы не умеем его готовить?
2. Если таки не умеем готовить, то очень хотелось бы услышать/заиметь ссылку на статью/книгу по TFS Best Practics for small teams.
3. Если дело не в нас, а в TFS, то посоветуйте что-то действительно хорошее для небольшой команды.

Здравствуйте, -VaS-, Вы писали:

VS>И меня стойкое ощущение, что это, по меньшей мере — убого, чревато ошибками и крайне трудозатратно.

Почему убого?
Пункты 1-4 вполне хороши. У вас всегда есть полный списко фич и список задач на текущую итерацию.

VS>5. Баги сами по себе не связаны с итерациями, но на каждый баг руками создается по 2 таски — "Исправить баг ХХХ" и "Проверить баг ХХХ", которые цепляются к итерациям по общему принципу.

По поводу п.5 — может не стоит плодить задачи на исправления багов? Тот кто отвечает за распределение задач пусть решает к какой итерации привязать багу (другими словами, пусть решает когда ее исправлять — сейчас или в будущем) и назначает исполнителя. Исполнитель после исправления баги переводит ее в статус fixed и назначает автору (или тестеру, если таковой имеется), который после проверки исправления переводит баг в статус Closed (не помню дословно названия статусов, но мысль вы поняли).

Здравствуйте, -VaS-, Вы писали:

VS>Вот такие дела:

VS>1. Все таски в обязательном порядке имеют parent Scenario. Scenario обычно олицетворяет собой крупное бизнес-требование.
Очень правильно

VS>2. Таски изначально прикрепляются к спец. итерации "features list".
VS>3. После планирования итерации часть тасков прикрепляется к текущей итерации (например "Итерация 23"), незакрытые в предыдущую — либо к текущей, либо к п. 2.
А почему бы сразу не крепить к нужной итерации?
То что нужно переназначать таски руками — ужасно, чревато ошибками.

VS>4. На каждую новую итерацию приходится делать queries типа "Итерация 23", "Таски <имя члена команды> на 23 итерацию" и т.п.
По по query на итерацию — нормальное явление, а зачем на каждого члена команды?
Достаточно
1)Все таски и баги на итерацию
2)Мои таски и баги на итерацию
Менеджер может взять запрос по всем таксам и добавить филтр по конкретному члену команды.

VS>5. Баги сами по себе не связаны с итерациями, но на каждый баг руками создается по 2 таски — "Исправить баг ХХХ" и "Проверить баг ХХХ", которые цепляются к итерациям по общему принципу.
Совсем плохо. Стандартный workflow для багов обеспечивает такое поведение, надо просто баги использовать наравне с тасками. Никаких дополнительных движений делать не надо будет.

VS>Поэтому вопросы:

VS>1. Действительно ли в TFS все так плохо? Или мы не умеем его готовить?
Скорее второе

VS>2. Если таки не умеем готовить, то очень хотелось бы услышать/заиметь ссылку на статью/книгу по TFS Best Practics for small teams.
Что есть small teams? Я применял TFS на проектах от 2 до 8 человек, вполне хорошо идет.
Почитать можно тут: http://msdn.microsoft.com/en-us/vstudio/ee358787.aspx

VS>3. Если дело не в нас, а в TFS, то посоветуйте что-то действительно хорошее для небольшой команды.
Вопрос в том сколько сил понадобится вложить чтобы все "взлетело". Есть сорсконтролы\трекеры\билд-системы гораздо лучше TFS, но увязать все это вместе еще тот геморрой. TFS дает все это изкаропки.

ИМХО для маленькой команды как раз не стоит тратиться на настройку окружения.