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.
7 comments:
Glad your experience with Teamprise support was a happy one. Hopefully we'll have good news for you on check-in policy front soon.
Thanks a ton for all of your feedback!
Some comments...
Friendly names: I hear you. This is something we need to work on. An interesting historical note was that we used aliases all the way through our final Beta and switched to "friendly" names at the very end due to very strong customer demand. That said, the issues around being able to easily change people's names are independent. We are looking at how to improve it. I'm hoping we can make the tools we have today better and more widely available. We're not making any major changes in Orcas to dramatically improve this situation but hopefully we can make it incrementally better.
Administrating TFS, Share Point, and SQL Reporting Services: No argument there. That's one thing I desperately want to improve. I think we'll work on improving our out of band admin tools in this area. I think the real fix is going to come in the version after Orcas.
The out of the box Alerts stink: We are drawing up requirements now on what we need to do to make this more flexible - easier to subscribe, more flexible subscription, configurable delivery frequencies, additional mechanisms (like RSS), etc. I'm interested in any thoughts you have on what you'd like.
No web interface for work item tracking: That's a pretty common request. It's something we're looking at to figure out what we can do.
Code policies on the client side instead of server: Yes, we're looking at creating a "pre-checkin testing" server that would be able to build your checkin, run static analysis, verify checkin policies, etc. It's not going to be an Orcas feature but I'm hoping we can start sharing some thoughts on it in the coming months.
No hierarchy for the work items: This is a big area of investment for us. In fact, we've already done a great deal of implementation in this area. This is targeted for release in the version after Orcas.
Can't remove or rename work items: We just approved a DCR to add support for this in Orcas.
Thanks again for the feedback and we'll keep working hard to address the issues that you are having.
Brian
Thanks Martin and Brian! I'm glad to see at least someone other than my brother's cat is reading my monthly TFS blog!
Brian it sounds like my current concerns are being addressed in one manor or another. That's great to hear!
Per your request on my input for the Alerts.
I think the "WorkitemEventSubscription" tool is headed in the right direction. I'll do my best to provide input by providing you with two examples that take 1-2 minutes to setup in our current workflow tool.
1) It would be nice to create a rule "Project = MyProject, WorkItemType = Task, Assigned to = user" and then subscribe the users you want the system to execute the rule for. In this case we'd subscribe all users in MyProject to it. When a Task is assigned to them, then get an email.
Right now the only way we can figure out how to do this is setup a rule for each user.
"Project = MyProject, WorkItemType = Task, Assigned to = Lastname1, Firstname1 (Company)" --SendMail--> firstname1.lastname1@company.com
...
"Project = MyProject, WorkItemType = Task, Assigned to = Lastname2, Firstname2 (Company)" --SendMail--> firstname2.lastname2@company.com
... and so on. That is why we wrote the web service which essentially does this:
"Project = MyProject, WorkItemType = Task, Assigned to = user" --SendMail--> user
2) We have a field called "Tester." This value typically starts off with the Testing Lead then changes to his/her direct report as the Task gets closer to actually being tested. We want to Tester to be notified when the Tester field changes to their name. The rule might be something like this. "Project = MyProject, WorkItemType = Task, Tester 'Changes To' user" --SendMail--> user. The administrator would subscribe all users to this alerts.
Let me know if this makes sense.
Thanks for all this feedback!
Friendly Names: We recently published a new KB article (http://support.microsoft.com/kb/932717) on the issue of changing people's display names in AD (or removing people from TFS). Through the KB article you can contact CSS for the retro-active tool to fix this issue. We understand that this is far from ideal, and we will be making efforts to fix this situation post-Orcas.
Dan.
You can rename WIs if you want.
Be very careful when tinkering with the databases behind TFS. You should make a backup if you are doing any kind of playing around.
You can run a table query that returns the results with the work item you want to rename.
SELECT ConstID
FROM Constants
WHERE (DisplayPart = 'Bug')
If you run the following you will probably get the error below it.
Update Constants
set DisplayPart = 'QA Test Bug'
where ConstID = 3003
Msg 1934, Level 16, State 1, Line 1
UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER, CONCAT_NULL_YIELDS_NULL, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods.
The work around is to return the results of the table based on the ConstID and then change the DisplayPart value in the table directly. You can't change a value you are filtering on so you need to get the ConstId first. This can't be done through query analyzer.
Simply create an email group for the alerts. Then only one person needs to set it up for the group.
And in actuallity if you have a TFS admin they can manage it through the command line tools and the employees don't need to worry about it.
Doug
Hey Doug! Yep, we do that for notfications we want to send to the entire group. However, the notification type that is missing is where you want to send the email to just the person in the Assigned To field. For example:
Assigned To = Mac Noland --> mac.noland@mycompany.com
Assigned To = Brock Noland --> brock.noland@mycompany.com
This type of notification can only be setup if each user does it for themself. That's hard to cordinate (and enforce) with you have 1000+ users.
Post a Comment