Even thou these are very cool ground breaking technologies, I must say that they are no silver-bullets.
Companies who does not implement the right processes for software development life cycle, will get little gain from implementing them accross their teams.
I can say without doubt that if your company uses the Microsoft Solutions Framework (MSF) methodologies as a base, that's a very good indicator; if not, please before using TFS or TS, try to engage your team on this philosofy.
Team System is a very expensive package, and it is not like Microsoft Office, that you just install and then let the people using it. If you plan to use Team System, one advice: Start small. Start by using TFS as a version-control and take advantage of work-item tracking. Now it is a good time to leave behind those cheap-file-system-based solutions like SourceSafe and CVS. They were good, at their moments, but now time times are different, we are talking of a world-class solution.I have never heard of a full implementation of Team System in one shot . I can only imagine that if this happen, they would fire-fight the integration of so many variables and softwares and tools, and probably will learn that very simple truth: Team System is just too big. There is just too much to learn and execute at the same time. I even risk saying that at the end it will be a very big frustration... and waste of time...and of course, money.
So, by trying first the work-item tracking, everyone can see right away something called: traceability; also code metrics and better team communication. These are only baby steps, but at least in the right direction.
Once the work-item tracking is done, do this: implement unit testing. Start small, don't be affraid, start using basic unit testing, not the whole Test-Driven Development methodology. Remember, right now we only want to kick-off our environment, so no rush. Another point, is that TDD is a highly complex practice, not only a bunch of monkeys tryping crazy stuff to test and validade the cycle, so the learning curve can be very steep. Just by implementing Unit testing you will already improve the code quality in a matter of days.
The next step is to write unit tests to validade a requirement. Oh...Don't you have requirements? in this case, return to basics...MSF.
This is another benefit that you will have in a immediate way — you will for sure understand how to meet your requirements. Why? simple, because if you can't write an unit test for requirements, then the requirement isn't testable. The unit testing tools in Team Edition for Software Testers will quilify these are "poor quality items", and we do not want to deliver poor solutions, do we?
Now, just like you read email, or drink coffe, or do a little break at 3PM for a chat with colleagues, do this: perform unit testing. everyday. There is a method called continuous integration which is perform the tests against the code before it is checked in. If this is ask too much, at least make sure to check in a buildable version of your software. That's the minimum you can do for your colleagues, and for yourself. Guarentee that the latest version is not breaking.
The reason for that is called nightly builds. Every night, a build will be performed by Team System, and it will catch all the errors during this process. So play this game, try to catch the error before TS. Chances are you won't, but again you will improve your software testing culture. At the end of the day, is way cheaper catch bugs in development than after releases.
Another good thing about nightly builds is that, after each build you will have access to a report of build metrics. That's a very extensive report about your code. How many lines of code, method counts, how many unused variables, how many changesets per build. That's history data, and in a few months you can clearly identify what pieces of code are the most critical in your solution...chances are that you will be surprised to know that a small validating method in some business logic layer is just too overloaded with calls and responsability.
Even the nightly build is a big turn. So, try run the nightly builds per assembly, for a start...then add others with the time, if all goes well and you are getting used to the methodology.
Well, here they are: TFS, work-items, unit testing, nightly builds...And just for you to know, Microsoft Best Practices says to implement Team System new features every 3 months. So, again, no rush.
Good Luck!
By Edge Pereira
