In some respects, this whole book is about process. In this section we present the process-oriented project guidelines that do not require much contextual information. Those that do require more context in their description are presented in subsequent chapters. The Prime DirectiveLet's start with our fundamental guideline about process, also known as the prime directive of process. This guideline is shown in Project Guideline 7.
The real trick for the software engineer is to determine which tasks are really necessary. We have a simple way of determining this. We ask the following question about everything we do: If we don't do this activity, or produce this artifact, will anything bad happen ? If the answer is "no," we don't do it. That seems simple enough. But you have to be brutally honest. It is very easy to fool yourself and tell yourself what you want to hear, rather than recognize reality. You can convince yourself that nothing bad will happen if you don't document your design anywhere except in the code, or if you don't address architecture issues early. You may be able to produce software that works today, but is not sustainable for future releases. Bob Martin, from ObjectMentor, has a slightly different way of stating the question above. He says that you shouldn't produce the artifact or perform the activity unless something really bad would happen. [4] We can quibble over how bad something has to be before you do something, but you get the basic idea.
Address RiskAnother way of thinking about the prime directive leads to the next project guideline. If we're going to do something to avoid a bad outcome, then what we're really saying is that we need to make sure that our process addresses risks. Think about it. Why would you do something if it doesn't address a real risk that you face? Now, not every action you take on a project is directly related to a known risk. That is okay. There are things that you have to do in order to ship your product. If you don't do them, then a potential risk may become an actual risk. See Project Guideline 8.
Don't Reinvent the WheelSo, we have to make sure that we do the right things, and don't do unnecessary things. That's great to say, but what things should we consider? If you have ever tried to establish a process in an organization, you know what a difficult job it can be. You may have a wealth of software engineering experience, but it takes time and a lot of effort to put together a coherent , consistent description of what needs to be done. What should you do? Project Guideline 9 will tell you.
We're concerned about software reuse. We should also be concerned about process reuse. Starting from scratch and reinventing the wheel, so to speak, is never cost-effective for the following reasons:
Let's consider each of these separately, starting with the amount of information. There is so much information about technology, process, management, and so on, that it is impossible for any one person to keep up with it. Gary reads the mailing lists for XP and agile modeling. About two hundred mail messages appear each day on just these two lists. There is a lot of noise on these lists, but if you want to understand what is happening in the communities, you need to read them. There are usually one or two messages that really have something interesting each day. Add in the articles and books on XP and agile software development and it's hard to keep up with just one area, let alone multiple areas of interest. Now assume that most people have "real jobs," such as developing software. By using a process framework or reusing a process instance, we let others mine the field and distill the interesting information for us. Next we have the problem of producing a process that is well-defined , consistent, and understandable. What format should you use to present the process to your team or organization? Are there examples and instructions? Is each person on the team forced to look at all of the details, even if they already know what they're doing? There are many more questions and issues to address. When you start from scratch, you have to think of everything. This situation is similar to the software developer who can either develop a set of cooperating classes from scratch or use an object-oriented framework. Smart developers will always start with an existing set of classes and customize them to fit the situation when they can. Smart process engineers (people who configure processes for development groups) start with an existing process and customize it for their needs. Finally, when you have a set of practices, principles, artifacts, and so on, you need to decide when they apply. We often talk about using best practices. What does that really mean? Are there universal best practices that apply in every situation? Perhaps; however, many, if not most, apply best in certain cases and you need to know when to use the practices rather than blindly follow them all the time. This means that you need to configure your process for specific contexts and projects. Make Your Process YoursTailoring your process means more than just selecting a subset of the practices, activities, and artifacts that might be specified by your process. It means you should select those that fit together in a consistent way. It also means that you should feel free to modify them by removing things that are not necessary (the prime directive) and adding things when necessary. This brings us to Project Guideline 10 and its corollaries.
Accepting process guidance blindly is a sure recipe for disaster. You might think of this in the context of a road map. If you want to travel from Lexington, Massachusetts to Cupertino, California, there are thousands of possible routes. You need to decide which is appropriate for your needs. If you go to some of the Web sites that provide driving instructions, you are offered a choice of routes, depending upon your ultimate goal. [5] Similarly, you may choose one process if you are under extreme time pressure because of a rapidly changing market, and another if you have significant overhead imposed on you by customer requirements and regulations.
One thing we have found in our experience is that people tend to configure too much into their process. They think that if they are not sure whether they need something, they should do it. We recommend doing just the opposite , as stated in Corollary 10.1. If you omit something you really do need, it usually shows up quickly and you can add it. If you add something you don't need, you often will just keep doing it and never remove it from your process because you don't know that it isn't necessary. The choice is yours, but we prefer doing less rather than more. We find that the risk is usually small.
How do you decide if you are doing something that's unnecessary or not doing something you need? If you are doing something that is not necessary, you can usually spot it during your iteration reviews. During these reviews you not only assess the work done and progress made, but you evaluate the effectiveness of your process. Some symptoms that can indicate useless work are:
Always ask yourself, why am I doing this and who cares? Configuring your process is more than just deciding what to do, when to do it, and how to do it. It also requires you to decide how formal you need to be. Once you decide that you need to perform an activity or produce an artifact, you should decide how rigorous you have to be. Should you use a tool? Will the artifact need to be modified continually? Who will look at what you produce? These are some of the questions you have to ask yourself to determine how formal you need to be. We find that small teams are usually less formal than large teams . This makes sense because there are fewer lines of communication that need to be established, and those that do exist are usually quite informal ”possibly one team member leaning over into another team member's work area and asking a question. Whatever you decide, don't be formal for the sake of formality . Don't lose sight of your primary purpose, to deliver working software to your customer. How do you configure your process? There are several approaches. We find the easiest is to configure it by focusing on artifacts. That is, we decide what artifacts are necessary to help us reduce risks and deliver the software, then base our process on producing the artifacts. If we know what we have to produce, we can figure out how to produce it. In the next chapter you will see how we configured the process for the PSP Tools project.
We will see more process-oriented project guidelines in later chapters. The ones presented here are the ones that are most important to understand. Use Your BrainWe have one final process-oriented guideline, Project Guideline 11. It almost seems silly to mention it, but we have often been surprised by the number of projects that forget to apply it.
People, especially software engineers, are paradoxical. On one hand, they want to be creative and hate being told what to do. On the other hand, they want someone to show them how to do things. The key is that they want to be given the freedom to do things they like to do ”the creative activities that challenge their intellect. They are looking for step-by-step instructions for the simple, repetitive pieces they would rather not have to think about. They also want to make sure that the creative parts dominate their time and that they don't spend one second more than necessary on the drudgery. If you don't consider Project Guideline 11 when configuring your process, you may end up with a process that is too heavy: process for the sake of process. Instead, you want your process to account for the skills of the people on your team, along with your project and organization needs. When using a process, even if it has been configured, you still need to apply common sense. When the process prescribes something that does not support the people or the ultimate goal, you have the responsibility to question the process element and ensure that it adds value to the project. |