Visual Studio Updates Provide Greater Visibility into Application Development Projects

No CIO wants to know the hairy details of every component under development on every programmer’s desktop. IT managers only want to know project status: what’s in trouble, what needs attention, what a delay means to the budget. One flavor of the Visual Studio 2008—which Microsoft says it will release to manufacturing by the end of November—gives IT managers exactly that view, the company claims. Assuming, that is, that your development team knows how to take advantage of the features in Visual Studio Team System (VSTS).

MORE ON CIO.com

Five Things IT Managers Should Know About Software Requirements

Microsoft Unveils Sync Framework to Improve Collaboration Technologies

10 Things You Should Know About Microsoft’s Silverlight

Hackers and Suits: 10 Tips for Managers to Bridge the Gap

According to Dave Mendlen, Microsoft Director of Developer Tools Marketing, VSTS gives IT managers and CIOs visibility into the application development cycle, the development process, and at least some project predictability.

“It has all kinds of analytics at the business decision-maker level,” Mendlen said during this week’s DevConnections conference in Las Vegas. The source code repository for Visual Studio Team System and its reporting manager help an IT manager see everything that goes on in the system, across geographies and virtual boundaries, he says. VSTS lets the manager examine measurable results, from requirements-gathering to unit testing. Mendlen said his team used the system for Visual Studio itself, and came within three months of its ship schedule.

As a result, managers can do a better job of estimating when the application will really be ready, and whether it will come in under budget. Managers appreciate the ability to get an overview of project status, certainly, but it’s not too hard to sell developers on the benefits too. Stewart Armbrecht, associate director of design and development at Protiviti, an independent risk consulting firm, wants to automate status reports because, he says, “We want to eliminate meetings.” Using Agile methods, the 20 people working for Armbrecht go into 15-minute huddles, and everyone would rather spend the time on what the team needs than on giving verbal status reports.

Protiviti has been using VSTS but is just now starting to deal with the reporting functions. Until now, his team has focused on getting the automated build process in place, and working on data collection and task tracking. Now they’re ready to use the VSTS reporting tools both to support the individual team members and, says Armbrecht, “to establish metrics to gauge team progress and individual contribution rates.”

More Visibility into Application Development Status

The reporting features in VSTS may give managers more visibility into project status, but it may not be a no-brainer to get started. During a technical session, Siddharth Bhatia, senior group program manager for VSTS, explored VSTS’ reporting options, including how to modify built-in reports and to create new reports using Microsoft Excel and Microsoft SQL Server. Excel, says Bhatia, is excellent for ad hoc reports and initial analysis, including trend analysis. However, when you want to examine data involving complex relationships, he advises, it’s time to turn to SQL Server reporting tools.

You may not need to do much customization, though. Among the built-in reports is one that tracks tasks over time, so a development manager can see which tasks are active, resolved, or closed; that report can help you see how much work really remains on the project. Or you can track bug rates, see build progress, or view quality indicator reports. The latter report, for example, pulls together data from VSTS and checks the pass/fail test rates, shows software code churn (a count of added/deleted lines of code) and code coverage, that is, how much of the source code has gone through testing.

But there’s plenty of information that isn’t part of the base reporting system. If you want to know “what’s the remaining work, by person?” or “I want a list of active tasks with bugs reported” or “who introduced the most code churn?” these questions aren’t answered by the out-of-the-box reports. However, the data is still available, if you’re willing to massage it in Excel.

Gaining a More Sophisticated View of Software Projects Takes Some Extra Effort

To view defined progress reports, you need to connect the spreadsheet to the data source. In Excel, choose Data, Other Sources, Analysis Services; then choose the VSTS server name, database and table. The result is an Excel pivot table.

Note: Pivot tables—sometimes called “cubes”—are considered an advanced Excel feature, but they’re very cool and extremely powerful. They aren’t all that difficult to learn, either. One simple walkthrough is Tom Bunzel’s step-by-step instructions (in this case for Office 2003); another resource is Pivot Table Data Crunching for Microsoft Office Excel 2007, which has a free downloadable chapter from Informit.com.

The pivot table essentially lets you take a measurement—a count of “stuff”—and slice the data in various ways, automatically creating a table suitable for executive summaries. For example, you can select “bug count by area.” Then you can use the usual Excel features to format the data for better visualization, including pretty charts.

Learning to use this functionality isn’t terribly well documented, Bhatia admits. There’s some information on the Microsoft Developer Network (MSDN) site, but, he says, “I generally click on a lot of checkboxes and see what happens.” That’s not such a bad idea, since the VSTS developer has the most intimate knowledge of each project and thus the results will mean more than might generic documentation.

Relationship results don’t work quite as well in Excel, however, such as anything that needs to track a change in state or time. For example, if you need to show progress over time, you’ll probably want to turn to the SQL Server reporting tools. Among Bhatia’s advice:

• Launch Visual Studio. Create a business intelligence report. This lets you use the report designer tool.
• Start with the Excel “cube” to get the data set you want to work with. Then, he suggests, “Muck with that data set to get the report you want.”
• Explore MDX. MDX is a (somewhat arcane) language that you can plug into a “color” field, so that the screen display changes based on the item value (green means a closed work item, red means active). Be forewarned that, while it’s powerful, learning MDX takes time!
• Render the results to a Web page to show project status. The recommended method uses a Sharepoint server (so that the data is live), but you can always export to HTML using standard features in Excel or SQL Server.

A Few Cultural Adjustments

Some developers may be concerned that these tools give managers a keyhole view into what the programming teams are doing. “We’re giving the manager a lot more visibility into what’s going on,” commented Bhatia, “And the assumption is that visibility is good.”

One cultural change that’s been necessary for Armbrecht is to train developers to think of their daily activities as “work items;” developers can be too vague or too granular in doing so, which means the VSTS reports don’t show as much useful detail as everyone (including Management) would like. Be sure to spend time with developers individually to help them learn to define their own process structure and figure out what makes a useful work item, he suggests.