Почему используете два разных продукта?
DevTrack удобен в качестве баг-трекера, а также - feature tracker'а. С ним работают не только инженеры и менеджеры, но и продюсеры, и QA-инженеры, в том числе, из внешних команд. Hansoft удобен для планирования отслеживания технических задач, для распределения заданий между инженерами, оценки нагрузки, планирования спринтов и т.п.
Взаимодействуют ли они друг с другом?
Исключительно в ручном режиме. На этапе production в DevTrack вносятся фичи, которые формулируют продюсеры. В Hansoft же вносятся технические задачи, соответствующие этим фичам. Они формулируются ведущими инженерами на этапе технического планирования, а в ряде случаев - на этапе планирования спринта.
При работе инженер должен ориентироваться как на Hansoft, так и на DevTrack. Необходимо удостовериться, что в Hansoft занесены задачи, соответствующие закреплённым за данным инженером фичам. Там же надо регулярно отмечать время, изменять прогресс статус задач и т.п. Фичи нужно тоже обновлять, потому что после того, как они реализованы, они поступают для проверки продюсерам и QA-инженерам.
Насколько я знаю, было несколько попыток отказаться от одной из систем, по крайней мере, на время production'а. В одном из проектов это вроде даже удалось. Но, в целом, у каждой системы имеются свои преимущества, которые предопределяют использование их обеих.
Почему для планирования не используете что-то типа MS Project (SpiderProject, Primavera)?
По идее эти инструменты должны быть удобнее.
Подозреваю, что MS Project не используется из-за другой методологии планирования и ведения проектов. Например, у нас не используются диаграммы Ганта. Зависимости между задачами разрешаются в ручном режиме при помощи проактивной коммуникации между менеджерами, инженерами. При планировании считается, что все отобранные на майлстоун задачи можно распараллелить между исполнителями. Это, конечно, не означает, что из-за объективных трудностей (или зависимостей) какая-нибудь фича не может быть запланирована на более поздний майлстоун. К рекомендациям инженеров прислушиваются. Но чаще - ищут решения того, как можно избавиться от блокирующих зависимостей.
Управление большим количеством задач