| Software Development Metrics |
|
Author: David Nicolette Using metrics to manage and measure development work is the aim of this book. As the author says, metrics is not an inherently interesting topic, but knowing what work needs to be done to meet a goal, or to quantify how changes have affected performance is something most development team leaders will want or need to do. Nicolette looks at a number of software metrics and shows how they can be used and what their strong points and shortcomings are.
The first chapter introduces some basic ideas about metrics - why some are considered pragmatic, the difference between trailing and leading indicators, and what to look for when choosing a metric. The next chapter looks at metrics for steering work. As with the rest of the book, Nicolette begins with a template that you can use to decide whether the metric about to be discussed is likely to be of interest to you. The templates lay out what questions the metric can answer; a description of the metric; what values you can obtain from the metric; what approach, process model and delivery mode it supports; and what special considerations must be met for the metric to work. Among the metrics discussed in this chapter are percentage of work complete; earned value; budget burn; and buffer burn rate. The author also introduces running tested features; earned business value; velocity; cycle time; burn chart; throughput; and cumulative flow. Nicolette also shows how the metric is sometimes misapplied, which can be more useful than saying how it ought to be used.
Chapter 3 looks at metrics that can be used when you're trying to improve a process, using several of the metrics from the previous chapter, and also introducing process cycle efficiency; version control history; static code-analysis metrics; Niko Niko calendar; emotional seismogram; happiness index; balls in bowls; and personality type profiles. The next chapter looks at ways that you can assemble the metrics from previous chapters to find out more than you could by using one metric on its own. The author discusses the ways metrics have been combined in projects he's worked on or has seen in industry. A chapter on predictable short-term planning is next, focusing on the need for software projects to be predictable as being as important (or even more important) than speed of delivery. The final chapter is concerned with interactions with the organization beyond your own team, such as senior management and stakeholders. The idea is to find ways to provide the information such people need with a minimum of effort and disruption. Overall, I found the book to be more practical than I'd anticipated, and with some down-to-earth advice, particularly in the discussions of the ways in which various metrics are misused and fail to work for that particular case. It would be a good and useful read for a team leader who needs to work out how a project is going, and how to impart that information to managers. Related ReviewsCodermetrics - Analytics For Improving Software Teams
To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.
|
|||
| Last Updated ( Tuesday, 17 May 2016 ) |
