- A Paradigm Shift
- Contrasting Paradigms
- Attention to Flow
- One Work Item Database
- Fit the Process to the Project
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
One Work Item Database
Visual Studio Team System (VSTS) takes the idea of a transparent product backlog even further (see Figure 1.6). Team System uses a common product backlog to track all planned, active, and completed work for the team and a history of the majority of actions taken and decisions made regarding that work. It calls these units "work items" and lets the user view and edit them in a database view inside Visual Studio, in Microsoft Excel, and in Microsoft Project, all the while synchronizing them to a common database.
)
Figure 1.6 VSTS enacts and instruments the process, tying source code, testing, work items, and metrics together. Work items include all the work that needs to be tracked on a project, such as scenarios, quality of service requirements, development tasks, test tasks, bugs, and risks. These can be viewed and edited in the Team Explorer, Visual Studio, Microsoft Excel, or Microsoft Project.
One database behind the common, familiar tools defragments the information. Instead of cutting and pasting among randomly distributed artifacts, project managers, business analysts, developers, and testers all see the same work, whether planned in advance or scheduled on the fly, and whether from well-understood requirements or discovered while fixing a bug (see Figure 1.7). And unlike separate project tracking tools and techniques, much of the data collection in VSTS is automatic.
)
Figure 1.7 This is an example of the work items as they appear either in the Team Explorer of VSTS or in Visual Studio. Note that tasks, requirements, and bugs can all be viewed in one place.
Because VSTS uses a common database to track work items, it exposes them not just in Team Explorer but also in Microsoft Excel (see Figures 1.8 and 1.9). The use of Excel and Project is convenient but not necessary. All the functionality is available through the Team Explorer, which is the client for Team Foundation. If you’re using any Visual Studio Team System client edition or Visual Studio Professional, then the Team Explorer appears as a set of windows inside the development environment.
)
Figure 1.8 With VSTS, the same data can be viewed and edited in Microsoft Excel. The work items, regardless of type, are stored in the same Team Foundation database.
)
Figure 1.9 Microsoft Project lets you plan and manage some or all of the work items with full round tripping to the Team Foundation database.
The extensibility of Team System makes it possible for Microsoft partners to add functionality. For example, Personify Design Teamlook18 provides team members a view of their Team Projects on multiple Team Foundation Servers from within Microsoft Office Outlook. Team Foundation Server extensibility enables Teamlook to track work items with full accountability in the familiar communications tool, Outlook (see Figure 1.10).
)
Figure 1.10 With Teamlook from Personify Design, you can also use Outlook as a client for the Team Foundation server.
Instrument Daily Activities
The transparent backlog relies on accurate data to be useful. Often, collecting the data becomes a major activity in itself that relies on willing compliance of large numbers of participants. This disciplined attention to the bookkeeping is rarely sustained in practice, especially during periods of intense activity.
The irony is that the vast majority of the data that a team needs is directly correlated to other actions that are already managed by software. Developers check in code, builds parse that code, testers write and run tests, and all their activities are tracked somewhere—in Project, Excel, the bug database, or timesheets. What if you could gather all that data automatically, correlate it, and use it to measure the process?
Team System takes that approach. It instruments the daily activities of the team members to collect process data with no overhead. For example, every time a developer checks updated code into version control, work items are updated to reflect the tasks and scenarios updated by this code. The relationships are captured in a "changeset," and when the next build runs, it identifies the change sets included and updates work items again with the build number. When tests execute, they use the same build number. Then test results, code changes, and work items are all correlated automatically by Team System (see Figure 1.11).
)
Figure 1.11 The metrics warehouse collects the data from all the actions on the project to provide reports that correlate the different sources and dimensions of data.
In addition to keeping the backlog current and visible, this automatic data collection populates a data warehouse with metrics that reveal trends and comparisons of quality from many dimensions on a daily basis. Just like a data warehouse that provides business intelligence on functions such as a sales or production process, this one provides intelligence on the software development process.
Simple Observations
With this data warehouse, basic questions become easy to answer: Is the project coming in on time, or how far off is it? How much has the plan changed? Who’s over or under and needs to have work rebalanced? What rates should we use to estimate remaining work? How effective are our tests? Most project managers would love to answer these basic questions with hard data. When the data collection is automated, the answers become straightforward.
Project "Smells"
More significantly, most project managers would love to find blind spots—places where data indicates a likely problem. It is now common to talk about "smells" for suspicious areas of code.19 Problems for the project as a whole also appear often as hard-to-pin-down smells, which are not well exposed by existing metrics. I’ll cover smells in some detail in Chapter 9, "Troubleshooting the Project," but for now I’ll share a common example. Imagine a graph that shows you these bug and test pass rates (see Figure 1.12).
)
Figure 1.12 The X-axis identifies different components of your project; the bars show you the test pass rate for each component, while the points and line show the active bug count.
Based on Figure 1.12, what would you conclude? Probably that the Instore Pickup Kiosk code is in great shape, so you should look for problems elsewhere.
At the same time, there’s a danger of relying on too few metrics. Consider the graph in Figure 1.13, which overlays code churn (the number of lines added, modified, and deleted) and code coverage from testing (the percentage of code lines or blocks exercised during testing) on the same axes.
)
Figure 1.13 Overlaying code coverage and code churn for the components provides a very different perspective on the data.
Suddenly the picture is reversed. There’s really high code churn in Instore Pickup Kiosk, and the code is not being covered by the tests that supposedly exercise that component. This picture reveals that we may have stale tests that aren’t exercising the new functionality. Could that be why they’re passing and not covering the actual code in this component?
Multidimensional Metrics and Smells
The ability to see more dimensions of the project data is a direct benefit of the metrics warehouse, which collects and correlates data from daily activities. It provides a quantitative, visual tool to pursue the smells. In this way, you can achieve the visibility level needed for the strictest compliance reporting while working in an agile manner and having the same visibility into a remote project, even outsourced, that you would have in a local one.