Objective 5: Decide What Process to Follow and What Tools to Use

It is important that your team shares a common view of how it will develop software, that is, which process it will follow. You should make sure that you streamline the process to minimize unnecessary overhead and be sure that the process addresses the specific needs of your project. Small projects can make decisions on exactly what process to follow as they go along, but bigger projects may need to spend more time up front considering their process of choice.

The idea is to come up with a process and tool environment you think works in your first iteration. You deploy the process and tools in the second iteration, and get immediate feedback on what works and what does not. Based on the feedback, you update your process and tool environment, roll it out in the next iteration, and keep on iterating until you are satisfied with your environment.

Many organizations go with a "gut feeling" when deciding what process to adopt. Often, they wind up applying Band-Aids to problems without addressing the source of the wounds. A better approach is to assess your organization to understand where you are now, define where you want to be, and then decide how to get there, incrementally. In Chapter 10, we describe how you can customize the RUP product to fit the specific needs of your projects and how you produce a development case , a customized guide for selecting which parts of the RUP product to use and how to use them.

Once you have decided on a process, you can choose what tools to use. In some cases, the tool environment may already be decided, through a corporate standard, for example. If not, then you need to choose which Integrated Development Environment (IDE), requirements management tool, visual modeling tool, Configuration and Change Management tool, and so on to use. As we mentioned before, it is important that the tools do a good job of automating the process you choose; this may require that you customize tools and templates, set up project directories, and so on.

You also need to implement the process and tools in your projects, which we describe in Chapter 11.

For each of our three example projects, you do the following:

Project Ganymede, a small green-field project: The team gets together and spends an hour agreeing on how it should work at large. After the meeting, the project manager/architect produces a RUP configuration that corresponds to what they agreed on and writes a one-page development case for the Inception phase, outlining which artifacts should be produced, what templates to use, and how to document the information. They decide to wait until the beginning of Elaboration to detail how to work in Elaboration. The project manager/architect, being more experienced , functions as a mentor for the rest of the team, helping them with the adoption of the process and tools.
Project Mars, a large green-field project: The project manager and architect spend time with a mentor, who guides them in what process to use. Once the mentor understands the needs of the project, the mentor spends a few days producing a RUP configuration and writing a development case for the project. The development case covers the entire project (even though more detail is provided for the Inception phase). Once done, the mentor uses the development case to influence what is taught in the training delivered to the team.
Project Jupiter, a second generation of a large project: Most of the team members were involved when developing the first version of the application. They were happy with the process and tool environment, but had suggested a few improvements, which were documented at the end of the previous project. These suggestions for improvements are now implemented and rolled out to the team.