Team System (VSTS) … a view after completing another R&D cycle
We are on the verge of competing the second major R&D cycle on VSTS evaluation and readiness training in-house.
The second wave included primarily project managers and the different viewpoints and expectations were both interesting and challenging.
What are the true challenges of VSTS?
- The installation is still not straight forward and http://www.scottcreynolds.com/PermaLink.aspx?guid=a8ad7061-9473-4324-86c2-b709f8d739e7 shows that reading the instructions and release notes is not a recommendation, but a non negotiable prerequisite.
- The product is still much unknown and thus not trusted by both the development community and overall stakeholder community.
- The maturity of some of the steps as outlined in our http://www.drp.co.za/posters/0202_MicrosoftTeamSystem.jpg process map are not yet in a state of maturity that we would like the technology to be in. For example, the modeling tools and the overall domain specific language (DSL) environments are currently in an immense era of growth and at times instability or incompleteness.
- The options and possibilities are endless; making it important that pre-implementation planning is conducted on at least this engagement. It is important to define the objectives of all stakeholders and create a match matrix of expectations, VSTS and 3rd party add-ons.
Is VSTS a solution to consider?
In our opinion VSTS is most definitely a product to “seriously” consider. It delivers immense value to all stakeholders, but especially to the build and test cycles of any project, we commonly refer to as the “health pulse” of a project.
The solution, especially the process, must be mapped and customized to suit the environment, not the other way, i.e. the environment to slot into VSTS. The former ensures that VSTS can be implemented piece by piece, with minimal impact on existing environments and with maximum value to all stakeholders.
Our core findings/decisions to date:
-
#1: It is optimal to spend some time with all stakeholders, define their requirements and objectives, customize VSTS process to suit environment and then, and only then, implement VSTS.
-
#2: Review the modeling tools and use where they add value, rather than enforcing a datacenter-application-systems-deployment process. Ensure that users are getting value of each step, before making it part of the process.
-
#3: Test-Before-Develop and Contract-First are concepts that often raise their heads during VSTS planning. Ensure that all parties understand what testing means, what the different types of testing are and how the VSTS tools map to the various test types … and where there are no tools within VSTS at this stage, i.e. automated fat-client or smart client testing.
-
#4: Overall … VSTS is a release 1.0, which is probably the most important realization. One could view some of the missing features and evolving areas as a great problem, however, we see them as a beginning to a better development life cycle environment. VSTS, like all other solutions, is no silver bullet and it is up to us to identify and implement the features of VSTS which add value to the development environment.
Therefore, have a look at VSTS, investigate what it is all about in an isolated research center, but ensure that you take a step back and spend time thinking and planning, before rolling into production environments.
See http://www.drp.co.za/posters/0202_MicrosoftTeamSystem.jpg for a quick reference poster and http://www.saarchitect.net/viewarticle.aspx?articleID=218 for our first VSTS review article.