Applied Software Project Management

Part I: Tools and Techniques

If you're a project manager and you're reading this book, you probably can think of chronic problems on your projects that you need to solve. What's more, you probably want to do it without trying to change the entire culture of your organization. You want to build better software; you don't necessarily want to undertake a major process improvement initiative, or try to change the way everyone in your organization thinks about building software. This book is written to treat a number of common problems separately by providing self-contained tools and techniques that address them.

Most people think of a tool as a piece of software that can be used to manage a project schedule, track defects, or automate other tasks, in order to increase productivity on a project. While there are certainly software tools like these discussed in this book, we support a wider definition of the term. Here, "tool" is used to mean any self-contained concept, practice, technique, or software package that can be applied independently to a software project, in order to improve the way it is performed. Risk management, for example, is as much of a tool as Microsoft Project or Subversion. To make this distinction clear, the term "tools and techniques" will be used throughout the book to indicate this concept.

The idea behind these tools and techniques is to allow a project manager to pick and choose only those practices that solve the specific problems she is having with her own projects. When a software project is in trouble, a disproportionate amount of the trouble is usually caused by a small number of problems. The tools and techniques in this book are meant to address those specific problems. An organization that implements all of these tools and techniques will see an enormous gain in both productivity and user satisfaction for minimal cost. A project manager who targets the specific problems that he has found in his organization can address only his most pressing problems and still see a very noticeable gain—and at a much lower cost than trying to tackle every possible project problem!

Because the tools and techniques can be applied independently, one useful way to use this book is to take a "toolbox" approach to building better software. Consider the tools, techniques, practices, software packages, and other ideas in this book as individual tools in a toolbox. You can select the right tool depending on the specific problems and challenges that you face in your projects.

While these tools have been developed to be used by project teams, most of them can be implemented by a single person, either working alone or in a team environment. Using this book, even a single team member working alone can have a significant effect on both the quality of the software being produced and the effectiveness of the organization to which he belongs.

Each chapter in Part I of this book is based on a specific phase or area of a software project. It contains specific tools and techniques a project manager can use to help address problems, as well as information that most project managers should know about what goes on during that phase of the project. Part I covers the following tools and techniques, divided into different areas of project management:

Chapter 2, Software Project Planning

Vision and Scope Document

Software Project Plan

Chapter 3, Estimation

Wideband Delphi Estimation Process

Chapter 4, Project Schedules

Project Schedules

Earned Value Metrics

Project Scheduling Software (such as Microsoft Project and Open Workbench)

Chapter 5, Reviews

Inspections

Deskchecks

Walkthroughs

Code Reviews

Pair Programming

Chapter 6, Software Requirements

Use Cases

Functional and Nonfunctional Requirements

Software Requirements Specifications

Change Control

Chapter 7, Design and Programming

Configuration Management

Subversion

Refactoring

Unit Tests

Project Automation Software

Chapter 8, Software Testing

Test Plans

Test Cases

Test Automation

Defect Tracking System

Postmortem Meetings

Metrics

Most of these tools and techniques can be applied independently of one another. However, there are a few that rely on tools in other parts of the book. (For example, it is very difficult to build a test plan and test cases without a software requirements specification.) When this is the case, it is always because the software project will be better off with the other tool in place first, and the project will see a greater gain by implementing the other tool instead.

Many of the practices in this book are described using a process script that contains step-by-step instructions to help guide the team through the practice. "Script" should bring to mind a script read by an actor, rather than a script run by a computer. All scripts follow the same format (which is based on the template used for use cases, defined in Chapter 6) that contains:

• A name, one-line description of the purpose, and a brief summary.

• A list of work products that are used in the script. Work products are labeled as "input" if they already exist and are used in the script; they are labeled as "output" if they are generated or updated by the script.

• Entry criteria that must be satisfied before the script can begin.

• A basic course of events, which consists of step-by-step instructions to lead the team through the script activities.

• Alternate paths that the team members may follow to deviate from the basic course of events.

• Exit criteria that should be satisfied when the script ends.

There's an old saying: "There's only one way to be right, but a million ways to be wrong." This is not necessarily the case with sofware projects! In practice, the vast majority of projects go wrong in one of a small number of ways. At the end of each chapter in Part I, there is a section aimed at helping you diagnose the symptoms in your organization in order to determine if that chapter's tools, techniques, and practices will help fix the specific problems. This section contains several scenarios that should describe the way this problem typically looks from the outside. The "Diagnosing" scenarios in the chapters in Part I describe these problems in a way that should seem very familiar to project managers suffering from them. If one of these scenarios seems eerily familiar to you, there is a good chance that the tools in its chapter will help.