You can’t control what you can’t measure.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
WHAT YOU WILL LEARN IN THIS CHAPTER:
- Grouping defects by importance or task
- Using Ishikawa diagrams to discover root causes of problems
- Defining and using attributes, metrics, and indicators
- Understanding the difference between process and project metrics
- Using size and function point normalization to compare projects with different sizes and complexities
At this point, you’ve finished the project. Congratulations! Some of your team members are probably itching to move on to whatever comes next, whether they plan to continue maintaining this project, start a new one, or leave to achieve that lifelong ambition of becoming a barista.
However, you should do a few more things before the team scatters to the four corners of the IT industry. Chief among those is a discussion of the recently completed project to determine what you can learn from your recent experiences. You need to analyze the project to see what went well, what went badly, and how you can encourage the first and discourage the second in the future. To do that, you need to find ways to measure the project. (Exactly how do you measure the project’s “wonderfulness?”)
This chapter describes tasks that you should perform after initial development is over. It discusses methods you can use to analyze defects (which include ...