Conclusion

The story about Nick and his one-week project shows that a well-defined process can also be applied to very small projects. Nick follows "the Spirit of the RUP," and applies only the parts of the RUP that are relevant in the context of his one-week project.

Nick is very aware of risks, both technical (technologies, languages, interfaces, and performance) and business (schedule, expenditure, and missed expectations). He uses an iterative process to mitigate these risks, rapidly trying out ideas to validate them, to get feedback from his customer, and to avoid painting himself into a corner. He also sets up a plan with a few well-defined milestones, although the project is only one week long.

Nick has a simple business case for embarking on this project, with reasonable estimates for both his expenditures and the potential revenue. He revises this business case when he discovers that the basic requirements have changed.

Nick develops a design, beginning with an overall architecture, which he tries out very early. He also does more detailed design in areas where the direction may not be obvious. Nick tries to make sure he fully understands Gary's needs and vice versa. He tries to ensure that Gary knows exactly what he will get. Rather than jumping right into what he thinks Gary needs, Nick dedicates some time to writing down requirements, features, and constraints. Then, he validates this with Gary several times to make sure they share the same vision of the product.

Nick tries to spend his time on the highest priority tasks , and he sees that no issue is left aside or ignored for too long. Whenever he finds a problem with the product through a failed test, or whenever Gary comes back with a new request or a better idea, Nick captures this in the form of a change request, and he keeps managing and reprioritizing the change requests to drive his hourly schedule.

Besides the code of the product, early on Nick develops a set of test cases that match many of the requirements, and thanks to the iterative process he uses, many of these tests are matured, refined, and improved over time, as he develops the product.

To avoid losing some code by accident (for example, through a disk crash) or under pressure through his own mistake, Nick uses a simple strategy to manage the software, keep a history of versions of his files, and make snapshots of the version sets he tests. He tracks the evolutions and changes that he makes relative to these versions, so he can backtrack to a known configuration if he makes a mistake.

Finally, Nick writes simple user documentation, with a section that describes the release, how to install it, and its known limitations ”one with the release notes and one describing how to use the product ”that is, a user's guide.

This is the essence of the very lightweight engineering process Nick uses and which he affectionately refers to as his "Personal Unified Process" ”PUP, for short. It is a low-ceremony process that focuses only on a small number of artifacts or workproducts. It does not involve a huge amount of paperwork, since many of the artifacts are stored in various development tools: the Configuration Management tool, the design tool, office tools, and so on. These few development artifacts produce value not only during the initial product development but also later on for additional releases. If Gary were to come back in three months asking Nick to develop a version 2, these artifacts would provide Nick with invaluable information to help him do a better job this time. They'll offer him important cost estimates, partial design or code to reuse, and a few lessons learned, mistakes he can avoid repeating.

In the next chapters, we will see how this unrolls for more serious endeavors.