Other Processes: XP
A large groundswell in the market today is rallying around something called Extreme Programming, or XP for short. XP was pioneered by Kent Beck (a pioneer in the SmallTalk community as well). You can learn more about XP from its creators by checking out eXtreme programming eXplained by Kent Beck, published by Addison-Wesley. Without going into too much detail, I'll say that XP relies heavily on pair programming and full-time, 100 percent committed user input. Pair programming says that two sets of eyes see every line of code and that two individuals build the code collaboratively.
XP has immense promise as a software process, but even its creators admit that it isn't well suited for large projects. I have had the opportunity to be involved in a few projects using XP, and it absolutely demands strong resources. If the paired team is lopsided—one strong developer and one weak or inexperienced developer—the resources are wasted. XP is also very beneficial for the user interface aspects of the application, but I find it cumbersome with server-side rule-intensive applications. You still need well-defined and easy-to-understand requirements. I think I am in the same camp as James Gosling, Sun Microsystems Vice President and Fellow, and the creator of Java, when he was quoted in an InfoWorld interview as saying that pair programming sounded “kind of creepy.”
My advice is to use the Unified Process; just tailor it to be as lean as possible. (I review some of this “pruning” in Appendix A, where I introduce my ten “essential” Unified Process artifacts.) As will be presented in this book, part of that tailoring has to do with the UML artifacts. This book will focus on three key UML deliverables: use-case templates, class diagrams, and sequence diagrams. Complementary efforts have attempted to reduce artifacts to their absolute minimum. Efforts such as that championed by Scott Ambler, with his agile modeling (www.extreme-modeling.com), move in that direction. The Agile Alliance (www.agilealliance.org) has similar goals.
Selling the Idea of a Software Process to the Business
To sell an iterative, incremental, risk-based software development approach, we all must become better marketers. At first glance the business community probably won't like this approach. Why? When project sponsors are told that their solution will be delivered in multiple increments, their usual reaction, from their past experience, is that phase 2 will never happen. Projects are canceled, resources are drawn away to other efforts, priorities shift. So as a rule, they will strive to put everything possible into the first increment. Thus the biggest challenge is selling the idea to project sponsors.
Here are some of the top benefits of a software process that must be worked into your marketing plan:
The business gets useful increments in a staged fashion that continually build toward the final product.
Each increment delivers value-added benefits, while increasing confidence that the project can be flexible enough to adjust to continually evolving business needs. The business doesn't stay static, so how can the software be expected to?
Each increment is relatively short in duration, 3 to 9 months, so the possibility of the project's becoming a “runaway train” is lessened dramatically.
Any problems with the design or the technology surface early, not 90 percent into the project time line.
Users, analysts, designers, and developers stay very focused on each increment, so they can celebrate successes much sooner. The resulting team confidence is priceless.
This book stresses following a sound project plan, using a proven development process as the guide. To facilitate communication and extract both the requirements and design of the system, a common modeling language is applied: UML.