Overall we really like TFS, but here are a few things that are less than desirable.
- "Friendly Names" (actually unfriendly for us) for fields such as "System.AssignedTo" or "System.ChangedBy" is a major oversight on Microsoft's end. Let's say you have an employee John Doe who's Active Directory name is "Doe, John (Company 1)". John then moves to company 2 and the Active Directory name changes to "Doe, John (Company 2)" This causes major issues in TFS as because it's integrated with Active Directory the work items are invalid and can't be modified. Fields like "System.AssignedTo" can simply be updated by the user. Hidden fields like "System.ChangedBy" can't be changed by the end user. For this issue call Tech Support and get the TFSLocalize utility. For one user it's not a bad solution, but let's say you have 200 users (like we do) and Company 2 decided to be called Business Unit 2. Now we have 200 users who need to be changed. TFSLocalize stinks as you have to map out old user (i.e. Doe, John Company 2) to new user (i.e. Doe, John Business Unit 2). While we're not up and running yet, this potentially is a major, major issue!!!!
- Administrating TFS, Share Point, and SQL Reporting Services in three different spots is laborious. In fact without the TFS Administration Tool, we'd be in a ton of trouble. Trying to keep track of permissions and users in three separate spots for 200+ users is unobtainable. So if you're new to administrating TFS, make sure to visit Codeplex (http://www.codeplex.com) and download the TFS Administration Tool (http://www.codeplex.com/TFSAdmin). Without this tool, administrating TFS is a nightmare.
- The out of the box Alerts stink. First of all there is no easy way (we know of) to "subscribe" all the users. Instead each user has to "subscribe" themselves. And worse yet, they need to know their SMTP address. Imagine the pain of telling your Vice President they have to type in first.last@company.com. They barely know how to tie their shows for goodness sakes. To get around this we're simply avoiding the concept of subscribing yourself and using Mariano Szklanny's web service to do all notifications (http://staff.southworks.net/blogs/mariano/archive/2006/04/14/411.aspx). I'd suggest a similar approach if you're a large team like us.
- No web interface for work item tracking. Developers love the work item and source control integration located in their IDE. On the other hand, managers hate having to open up Visual Studio 2005 just to approve a Change Request. While this seems like something trivial, a nice bundled web interface sure would be nice. Hey Mr. Gates, buy Teamplain (http://www.devbiz.com/teamplain) and make it part of your solution!
- Code policies on the client side instead of server. Out of our 200+ users, 100-125 are Java developers using Teamprise (http://www.teamprise.com). We like Teamprise, but wish we could enforce a policy like "Require Associated Work Items." Nope can't. All the policy code is local to the Team Explorer install. Dumb! If you've never used Teamprise give it a shot. It's a very nice tool with WONDERFUL technical support.
- No hierarchy for the work items. Rhetorical question; if Tasks are children of Change Requests, why can the Change Request close before the Tasks are closed? A nice hierarchy is needed. And Microsoft, don't give us "TFS is totally extendable to do all of these things you request." We're not in the business of developing configuration management tools. You are, so add hierarchy in for your customers.
- Can't remove or rename work items. For some management reason that supersedes any input I have, we're not using the Requirement work item for a Team Project that is already created. Instead of leaving it there to confuse users, we would sure like to remove it. Nope can't remove it. Not possible. Or how about when you create a new work item called WrognName. Opps I made a typo, this should be called WrongName. Nope, can't rename it. Not possible.
