Sorry to cut in on all the TFS bashing. I've had a very positive experience with TFS (especially 2010) without even using the reports ;).
Yes TFS2010 is not perfect and there are quite a few issues across all of its main features but so does any other suite of tools you can gather that covers this many areas of the ALM. - Installation seemed a little scary at first but after doing a dry run on a virtual machine it was clear that the process is much much improved in 2010. It's much easier to setup TFS2010 than to go through all of the 4 installations of the tools you mentioned one after the other. - I've found source control to be very reliable. Merges are not as easy as with DVCS but are still reliable and work well. The source control concept has some idiosyncracies but some of these can be configured to match other concepts. Specifically "Get-Latest on Check- Out" was an issue of discontent when migrating from VSS and was resolved in TFS2008. - Work item tracking is excellent. TFS 2010 comes with a Scrum process template that we've found very convenient out of the box. We easily customized their state machines to match our team's process. And later we ditched those in favor of lighter templates just as easily. - The dev team preferred to work with the Team Explorer inside VS. Less technical people generally preferred the browser-based Web Access website. - Builds are much easier to setup in 2010 than before and the server supports distribution of build agents which we used to shorten build times. The new workflow based builds are better than before but still a bit of a challenge to customize. - The alerts system is still fairly basic but gives good feedback on broken builds. I even built a (physical) traffic light that indicates to the team the health of the build. - We did not utilize reports because we didn't find value in them but I understand they provide basic but good functionality. - The most significant added value naturally is the integration between all of these aspects. It's a great time saver that check-ins are grouped to changesets that are associated a work item that are linked to builds that generated versioned products. I can't tell you how many times I've traveled along this chain of associations when debugging and verifying code. Bottom line - your only reason for concern is getting to know a new set of tools. Some of them might have better competitors out there but you get the added value of simple integration across the suite. And besides, if you end up finding any specific feature set to be lacking you can replace that with an external tool and go on using the rest. Good luck! urig On Jan 26, 6:11 pm, Brandon Molina <[email protected]> wrote: > In the past I actually championed an effort to get a different company > to switch from VSS to TFS. This effort was ditched when I ran into so > many troubles just trying to install TFS. > > At my current company I was very please with their tool set consisting > of; Team City, SVN, HC Quality Center, Rally and a few other tools. > I'm still looking for the main driver for the switch, my gut tells me > its around reporting and tracking projects better (because some teams > have issues getting their devs to input tasks in Rally [entirely > different problem] ). > > Can anyone share good/bad stories about similar migrations or even > experiences going from one company to the next. > > Thanks in advance! -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
