Although our company is currently going through the approval process for purchasing and deploying Team Foundation Server (TFS), we have already gone through an Application Life cycle Management review and have begun the process of conceptually applying some TFS features against some of our challenges.
One thing is for sure. TFS is a tool that can help just about any company that has an IT component become more efficient. However if you are thinking about venturing into these murky waters you have several obstacles to overcome.
Certainly you will have to deal with those individuals who are averse to change. Everyone knows people in their organization who are comfortable in their current process domain and are afraid that a change may introduce some discomfort, or worse are limited in their skill set and are afraid that a new process may expose some of those limitations.
I think it is critical that before you introduce TFS or any major change that requires adaptation and adoption you should ensure to those individuals effected that you EXPECT there to be some training and that they should not be afraid of venturing into uncharted territory. In fact the only way to learn new things is to get out of that comfort zone.
"By nature man hates change. Seldom will he quit his old home till it has actually fallen around his ears.... ...Thomas Carlyle (1795 - 1881) British historian and essayist
If you are able to get beyond the change adaption/adoption hurdles, you still have a long way to realizing your goal of implementing TFS, but I can't overstate the importance of these first hurdles.
Once you get everyone on board and excited about the prospect of finally having a single place to store your code and work through your development tasks, (well, maybe not everyone) you need to analyze and evaluate your current state in the area of source code management and application life cycle management. The first thing to do is inventory all of your digital assets and determine which ones are candidates for improved management. The obvious candidates are your source code libraries, however some may want to consider the prospect of storing associated documentation for your projects including UML docs, requirement docs, and perhaps even legacy project plan and sprint documents if you are in the agile world.
Once you have determined what you would like to see migrated over to TFS, you should prioritize the individual artifacts and move things in an organized and phased approach. I do not recommend moving everything at once. This would probably not be worth the effort since I am sure there is code out there that you will never need nor want to see again. It would also delay the actual prize of TFS which is using it in your current projects. Finally there is something to be said about starting with a fresh slate.
In our situation we had dozens of source code repositories located all over the globe, including on users desktops so we did feel that it was a good idea to bring everything into TFS. Note that there is a limit to how many projects you can setup in TFS so I recommend placing all migrated source outside of any project. Also because of this constraint you should be careful about trying to divide large project into too many smaller projects.
From Microsoft TFS site --- [Team Foundation Server can support a maximum of five hundred (500) team projects if you use the MSF for Agile Software Development process template for project creation. Team Foundation Server can support a maximum of two hundred and fifty (250) team projects if you use the MSF for CMMI Process Improvement process template for project creation. If you have more than five hundred MSF for Agile team projects, or more than two hundred and fifty MSF for CMMI team projects, you must deploy more than one Team Foundation Server]
In addition to your source migration, it is a very good idea to use a single prototype project as your first foray into TFS. You can use this as an opportunity to find out which features you will want your organization to use and which ones to avoid. In addition you can act as the guinea pig and document where you mess up. This will help others avoid your pitfalls.
Before you start your prototype, you should also go through the two process templates that are included with TFS. These are CMMI and agile. You will likely find that there are missing pieces in these templates and you can and should modify them via their XML definitions. Specifically, you should make sure that your measures align with the PM's measures. If not, you may get some complaints that the tool is not very helpful for the PM's and BA's. It is critical to consistently demonstrate value on that side of your IT organization or you will have trouble establishing a business case for future technology.
All of these recommendations are meant to help you avoid the common problems in all new IT initiatives. There is no question that TFS can provide significant value to your organization. These include efficiencies which should bubble up to the overall bottom line. But you need to remember that sometimes you need to help prove out the value because the perceived value is sometimes what matters in these early stages.
ref: Team Foundation Server Planning Roadmap
Wednesday, April 23, 2008
Subscribe to:
Posts (Atom)