In-Depth
Support Your Dev Process Better With VSTS
Martin Shoemaker reveals what''s new in Visual Studio 2005 Team System and explains how it provides comprehensive process support.
Why reinvent the wheel? Visual Studio 2005 Team System, a whole new product for process support, takes what you've got and makes it better by integrating with and extending existing products. While it does provide new features in those existing products, it's a truly a process improvement by design.
We caught up with Martin Shoemaker, who will be speaking at VSLive! Orlando, to gain insight into what VSTS can do to improve your processes today. You can start reading here, or jump to your area of interest:
Q: What are the new features in VSTS?
Shoemaker: In a way, you're asking the wrong question. The question sort of assumes that VSTS is a new version of something that came before, and it's not. It does provide new features in existing products, but those new features are the "spoonful of sugar that makes the medicine go down." Process improvement is "the medicine," the real value in VSTS. So while I want to answer your question, I [also] want to make sure we [discuss] process.
To answer the question as you asked it, we really need to define two things: Who is using the tool, and what tool are they using? There are new features for architects, developers, and testers, all using Visual Studio, and there are new features for project managers using Project or Excel.
And then to support the process, there are new features for everyone in Team Explorer, which can be integrated into Visual Studio with the various VSTS editions. And of course, there are all the new features in Visual Studio 2005, chief among them (from a process perspective) being the Class Modeler. So really, [you've asked] multiple questions.
Features for Architects
Modeling. Modeling, modeling, and more modeling. Besides the Class Modeler, there are four new modelers in Visual Studio Team Edition for Software Architects.
The Application Designer lets you design reusable applications, services, and other sorts of components, as well as the interfaces and connections between them. Then you can select them and generate project shells that can be fleshed out using code and the Class Modeler.
The System Designer lets you design a system made up of reusable components from the Application Designer. Where App Designer is about possible ways to use and connect components, System Designer is about defining a specific way to connect them for a specific purpose. System Designer might seem redundant the first time you use it, but when you go to reconnect and reuse the same components in a different way, you'll appreciate the different perspectives of [the Application and System Designers].
The Logical Datacenter Designer lets you model the optimal security zones and servers within those zones to support your system. (Or at least, that's the way I think of it, because I'm usually thinking in terms of new deployments in clean environments.) The VSTS team calls this "green field" thinking, and it's a luxury a lot of people just don't have. A lot of people have to work within an existing datacenter structure, one that's owned by the datacenter administrators—and one that the architects and developers cannot change (or at least not easily). So for these teams, the Logical Datacenter Designer serves a much more important purpose: It documents existing structure in terms of zones and servers and the allowed connections between them, so that the architects know the constraints they must work within.
And then the Deployment Designer lets you tie all the other work together. It lets you model the deployment of systems and components from the System Designer to Servers from the Logical Datacenter Designer and ask, "Do the connections between these components violate any of the constraints on connections between these servers? And if they do, what are we going to do about it?" Again, this can be especially important when designing for an existing, fixed datacenter, because [not knowing what you're going to do to fix violations] can have repercussions back through all of the other modelers, including even the Class Modeler and the code itself.
Features for Developers
Features for developers primarily involve code analysis. Visual Studio Team Edition for Software Developers adds four analysis tools, plus a testing tool.
First, there's the Static Code Analyzer, which is like the old FxCop tool, but more powerful and more closely integrated into Visual Studio. It lets you check code for compliance with common standards, policies, and practices. So it helps you recognize common missteps, but it also helps you make your code more consistent with the .NET Framework code. Consistent code is more readable code; more readable code is more maintainable code.
Next, there's the Dynamic Code Analyzer. This tool allows you to test the runtime behavior of a component, including whether it overruns its memory and how it manages resources, such as handles and critical sections.
And then there's the Code Profiler. And [compared to other] profilers, this one has a ton of features. It will record which types and how many instances are created during a run. It will produce a hierarchical call tree. It will capture and record events from ASP.NET, IIS, and other providers. And it does sampling, instrumentation, and other performance measurement techniques.
There's also the Code Coverage tester, which will let you verify what parts of your code are executed during a run. This is important, of course, because bugs can hide in code that never gets executed during testing. [Often] programmers get in the habit of running their apps the same way, over and over, and never executing other paths that might be perfectly natural for users to follow.
And finally, there's the Unit Testing tool. This tool provides powerful unit testing features comparable to NUnit or JUnit. But it goes farther [than these], providing a lot of support for automatically generating tests. Now, auto-generated tests don't actually do anything. You still have to write the test code, but the test infrastructure is generated for you, along with some helpful comments to guide you in fleshing out the tests.
Features for Testers Testers share some new features with the developers: Visual Studio Team Edition for Software Testers also includes the Code Coverage and Unit Testing tools. (After all, testing at that low-level code view is a shared concern for developers and testers.) But the Testers edition has three unique new tools.
First, there's the Load Testing tool, which allows you to test how an application performs under different types of load. It includes features such as Browser Impersonation, IP Switching, and Network Impersonation to simulate various network access scenarios. It will also trace the performance of SQL queries and record various Windows performance counters.
Next is the Manual Testing tool. The VSTS team recognized that you might have a large investment in existing manual tests. And more than just a monetary investment, those tests represent a knowledge investment: They capture things that you know about the proper behavior of the system. You can't afford to lose these manual tests. Keeping with their goal of augmenting the way you work—not changing it— the [VSTS team] added support for gathering, documenting, and reporting the results of manual tests in the same way the results are reported from the Profiler, Load Tester, and other test tools. So you do the same testing work you always did, but the results are more accessible and visible.
And finally, there's Test Case Management, which helps organize and plan your tests, including individual test case data that allows you to run the same test procedures but with different cases to test different aspects of your system.
Features for Project Managers Using Project or Excel
Integrated work-item list management is the main VSTS feature for project managers using Project or Excel. The techniques are a little different in the two tools, of course, but the core feature is the same.
A work item is some activity that has to take place as part of a development project. You might call them tasks, assignments, jobs, or "to-do" items. In VSTS, they're generically called work items, and they're sort of the atoms of any development process in VSTS. Different teams follow different processes for different projects, but every process is defined by the work items you perform and the resulting work products.
One well-known work-item management tool, of course, is Microsoft Project. It lets you define a plan for a project made up of work items (or tasks, in Project) that are assigned to resources (or people, teams, machines, facilities, and so on) and scheduled over time. VSTS plugs into Project and lets you pull Project task lists from the Team Server database, add them into a Project schedule, manipulate them, and update the Team Server.
Now, in my work, I don't like the fields that are pulled into Project. I think that other fields should be pulled in as well. But the beauty of this add-in is that it's easily customizable. With a few simple clicks, I can pull in specific Team Server fields and map them to Project fields. So [this feature] lets the manager using Project keep using Project, but with some added power.
But as it turns out, a far more common project management tool is task lists manually created and maintained in a matrix editing tool—in other words, Excel. A lot of you manage your projects with columnar lists, created and formatted in Excel, without the powerful capabilities of Project. The VSTS team decided to support your style of project management as well. Just as with Project, you can pull a task list from the Team Server database into Excel, customize the fields and column ordering, edit the tasks, add new tasks, and so on.
And with both the Project and Excel tools, the VSTS add-in does error checking to ensure that your -entries fit properly within the Team Server schema. [This new VSTS feature makes] process integration for the Project and Excel tools close to effortless.
How VSTS Improves Development
Q: How does VSTS change, impact, and improve the software development processes?
Shoemaker: I know I have a habit of answering a question with a question, but I can't help myself: What is your software development process? For that matter, do you have a development process beyond "a bunch of people worked really hard to make things happen"?
For some teams, the biggest change might be that VSTS provides the opportunity, tools, and power to implement a defined process.
For some teams, the biggest change might be that VSTS provides the opportunity, tools, and power to implement a defined process.
But for other teams, who already have a defined process, VSTS doesn't change [it] in any way. [VSTS] just makes it easier to follow by integrating [it] into your development, architecture, testing, and management tools.
Now, [the second scenario is] ideal and will only be true for two groups of people: [those] who build their own process, and [those] who already follow one of the Microsoft Solutions Framework (MSF) processes that ship with VSTS (or another VSTS process built by a third party—although there aren't many of those yet). You see, deep, deep under the hood, VSTS is a process-building toolkit. [This toolkit allows you to] create process tools that support your existing process but don't change that process appreciably.
[Or, because VSTS] ships with the two MSF processes, teams might decide that the simplest path is to use one of the MSF processes as-is or with only minor customization. For [thee teams], the impact on their original process could be pretty large, depending on how far [the chosen MSF process] varies from their current process. (I'll explain MSF shortly; but first, I want to explain how VSTS defines a process so that you can see how it can support your process.)
In a sense, VSTS defines the atoms out of which processes are built, and then these atoms are assembled into different processes. These atoms [can be] roles, workflows, work items, work-item state transition rules, artifacts, artifact check-in rules, and guidance pages. (Remember guidance pages, because they'll have a large impact on the successful adoption of your process; they are a big [incentive] for your team to use one of the MSF processes.)
A role that one or more individuals fulfill as part of your process is largely defined by its workflows, or the large-scale jobs that you must fulfill in your role. For example, the role of an architect in your workflow might be to design and verify the communication infrastructure. That [role might seem] too large to think of as one task, but it is one responsibility for an architect. (In fact, I'm tempted to use the term responsibility as a way to explain workflow, but responsibility sounds kind of static, and workflow is dynamic.)
A workflow is all about work items, work-item states, and how [these states] change. It's all about what sort of work items you'll perform within the workflow. In [the previous example about your architect's] "design and verify the communication infrastructure" workflow, one work item might be "to estimate the volume of message traffic between users and the server." [This work item is] still a big job, but it's a lot smaller than "design and verify the communication infrastructure." It's a job you assign to one individual, and you can expect that individual to come back with an answer in some reasonable length of time.
In [Project terminology], it's a task. For example, a Project schedule is made up of tasks. [These tasks] are usually good examples of work items; although, in Project, one task might be made up of multiple subtasks. VSTS work items can be related, but they can't be aggregated as they are in Project.
The VSTS team made the situation even more confusing. They defined a task within MSF as one category of work items. (Thanks, guys, for overloading that term!) But I'm picking on them to make a point: Work items are grouped into categories. In MSF Agile, a task is a job that needs to be done, but it doesn't directly involve writing or maintaining code. Another category is Bug, which involves fixing defective code.
Categories describe common rules for similar work items, and these common rules are mostly defined by states. Every category of work items defines one or more states. For a Bug, for example (and this is how I might define a process off the top of my head, not an exact description of MSF Agile), the states might be Open, Irreproducible, Reproduced, Investigating, Fixed, and Closed.
But just having states [is not enough, you need] transitions between states, rules that restrict the transitions, and actions that trigger the transitions. Otherwise, a Bug, for example, could be entered into the system immediately in the Closed state, meaning no one on your team will know to look at it. (There's one [problem] that'll never get fixed!) [To avoid this type of oversight,] a Bug should start in the Open state. From Open, it can go to either Reproduced or Irreproducible—this is where transition rules and actions come into play.
You could have a rule that says, "Don't allow a Bug to go to Irreproducible except when a tester files a test result that shows we couldn't reproduce it." And another rule, of course, could say, "Don't allow a Bug to go to Reproduced except when a tester files a test result that shows how to reproduce it." [By the same token,] a Bug can go from Reproduced to Investigating when the tester produces a test case that reliably produces the Bug; a Bug can go from Investigating to Fixed when the developer changes the code so that the test case now passes; a Bug can go from Fixed back to Investigating if the tester finds that there's still a case where the Bug pops up; or a Bug can go from Fixed to Closed when the tester confirms that the Bug is dead. So you see that a set of possible states and transitions defines a lifecycle of a given work-item type; and a given person's activities related to a work item are part of that role's workflow for that item.
Two atoms were implied in the scenario above, but not explicitly identified: artifacts and artifact check-in rules. An artifact in VSTS is any persistent piece of information generated as part of processing a work item, including source code, design diagrams, test cases, test reports, and so on. If you want to save it, it's an artifact. And when you save it, you'll be saving it to a new source control system. This new source management system is built on SQL Server for power and robustness, and capable of archiving every sort of artifact, not just code files.
Tied to artifacts are artifact check-in rules. The most valuable one, in my opinion, is, "Never let anyone check anything in without tying it back to a work item." "Never" is a little strong, so the VSTS team made this rule optional. Even when it's in force, users can still override it (although they have to explain why).
Now does that sound like an awful lot to understand about processes in VSTS? Yes, it does, because I've missed the most important part. As a user, you only have to understand a tiny bit about how the process is built; the tool understands it for you. You must know how to follow an assigned workflow, using familiar tools plus some new forms. You can also see all work items assigned to each user, as well as related information right inside Visual Studio with the Team Explorer.
All the info about the "atoms" of a process is only important to [you if you're the process builder], because you have to know how to explain your process to VSTS. If you do your job well, other VSTS users will be able to naturally follow the process.
The biggest part of doing this job well involves the final atom: guidance pages. The forms that you see as part of a VSTS workflow will contain questions, but [the forms] won't tell you how to answer them. That's why the VSTS team created guidance pages, to explain the process well enough that VSTS users can learn it, follow it, and refresh their memories when they forget how it works. And good guidance pages will be the hallmark of a well-implemented VSTS process, because a process that you can't understand is one that you'll either do wrong or skip altogether.
I've arrived nearly full circle at the start of my answer: Many teams might opt to adopt one of the two MSF processes that ships with VSTS—or customize it in minor ways—rather than build a whole new process. This is partly because of the rich, clear guidance pages. The VSTS team invested a lot of effort in creating these pages, making them detailed yet easy to comprehend. They're a guide, a reference, a tutorial, and more, all with some polished graphics and prose. It will be hard for any team who builds their own process to match the MSF guidance pages in depth and clarity. In fact, I'll make a bold assertion: If you're not prepared to at least strive to match the MSF guidance pages, you will be better off not building your own process.
So what are the two MSF processes in VSTS? They're called MSF Agile and MSF CMMI. As the name implies, MSF Agile is for teams that follow an Agile Design philosophy: smart people with minimal structure who respond to change by creating much of their process as they go along. MSF CMMI is aimed at teams striving for CMMI Level 3 development. It defines more work-item types, more roles and states, and more specific workflows than MSF Agile.
Support for the Entire Team
Q: How does Team System support the entire development team?
Shoemaker: Each team member will work within a familiar tool, with different specialty features for architects, developers, and testers, but this tool will have an integrated Team Explorer that allows you to find, work on, and update work items, as well as to receive guidance on how to follow the process. The Team Explorer will also allow team members to query and report the status of individual work items, along with analysis metrics that describe the overall status of the project. And the new source control engine will archive almost every persistent artifact of the process, tying particular check-ins to particular states of particular work items. This creates much more visibility into the status of the artifacts and the work on those artifacts.
Q What is the most significant advantage to implementing VSTS?
Shoemaker: Communication. A recurring theme of all of my work for the past six years has been, "It's all about communication." As projects get larger and more ambitious, I believe that communication becomes a much more critical factor in project success than technology. All the technology in the world can't make the wrong system into the right system, but better communication might prevent you from building the wrong system in the first place. And what I love about VSTS is how the system of work items and artifacts all tied into familiar tools helps turn those tools into communication channels.
In the bad old days, a programmer would find out what code to work on by sitting in a long, boring meeting. A project manager would learn the status of that work by dragging the whole team into a longer, even more boring meeting. I hate that kind of meeting; you hate that kind of meeting. VSTS won't eliminate every long, boring meeting, but in many ways, it gives you communication without meetings. And that makes me a happy programmer!