This excellent book lives up to its title in delivering practical and application-oriented advice for project and process managers. The book highlights Hewlett Packard’s experiences using software metrics, incorporates more than seventy charts and graphs from real projects, and shows how the metrics can be rolled up into useful and workable organization indicators. The book includes a good bibliography.
Review By: Martin Fensome 03/15/2004This book provides practical methods for improving data collection and presentation that can be used to help company management make better product decisions and drive process improvements in the company or within a team. The author suggests useful metrics to collect, ideas on how to collect them, and ways they can be analyzed that could result in process improvement with the intent of increasing overall product quality.
The organization of the book was very logical and well laid out, however, the reader would be well advised to read this book from start to finish. Part I includes a chapter that outlines three differing company strategies that have a great effect on the metrics you report and the process improvement that could be possible. In order to focus on relevant metrics and examine data in the appropriate context, these strategies maximizing customer satisfaction, minimizing engineering effort and schedule, and minimizing defects are discussed in detail in a separate chapter.
Chapter 7 – The Role of Software Metrics in Managing Quality and Testing offers useful information to testing department managers. This chapter presents a well-compressed and summarized discussion of the topic, while providing a good game plan for implementing better test management and development and testing practices.
Part II of the book focuses on software metrics as they apply to process improvement. The author discusses what metric data should remain private to individuals and teams and what (and when) some of this data should become public. A discussion on software metrics etiquette follows with a series of illustrative stories that help to make the points clear, though as the author says, most of these are just good basic management practices rather than etiquette.
Depending on how formal the development processes are in your company, the chapter on dissecting software failures will be valuable. The point being that once you find out at what point in the process the defect/failure got into the code the better you are able to eliminate that class of defect in the future. Discussions on data collection, analysis, and justifying change take place here.
The chapter on investing in process improvements details different case studies and methods for maximizing the improvement on minimal action, while the chapter for justifying change presents cost/benefit analysis and sanity checks for the varying methods of process improvements presented.
I think that the author did an amazing job covering this topic in such a compact volume. Robert Grady uses his experience working at Hewlett Packard for many of the examples, graphs, and stories in this book. It is comforting to read about HP having some of the same problems in their processes and projects that I have come up against in my career. Mr. Grady acknowledges the changing management problem within HP (and other software companies) and matter-of-factly accepts that some ideas or processes that he has written about just didn't get tried due to personnel changes (and subsequent shifts in that person’s objectives within the company/department).
This book has less relevance to actual software testers/testing (though I could recommend it to test leads), being more focused on project management, process improvement, and test management users.
The style of writing is friendly. Grady doesn't use too much lingo, but the subject matter is, in my opinion, dry reading. You definitely need to set aside some ‘alone’ time to study this, as it’s not the kind of book you can pick up between phone calls.
Graphs and tables are used to illustrate many of the points discussed (though truth be told, some of the complexity analysis pages of K-lines-of-code are beyond my experience and not immediately relevant in my current situation).
Overall, I would recommend this book as a worthwhile investment for project managers, test leads, and test managers. For those not working in companies with the experience and desire to change processes like HP did, it may be more interesting as an introduction to more formal process improvement strategies and project status reporting.