What Is "Agile?"

What Is "Agile?" This book is called Agile Java. "Agile" is a new catchphrase for describing a bunch of related software development methodologies. Loosely defined, a methodology is a process for building software. There are many ways to approach constructing software as part of a team; many of these approaches have been formalized into published methodologies. There are dozens of major processes in use; you may have heard the names of some of them: waterfall, RUP (Rational Unified Process), XP (extreme programming), and Scrum. Methodologies have evolved as we learn more about how to effectively work. Waterfall is an older approach to building software that promotes copious documentation, rigid up-front (i.e., at the start of the project) definitions of requirements and system design, and division of a project into serialized phases. Its name derives from a diagram that shows progress flowing down from one phase to the next. While waterfall may be appropriate for some efforts, it has some limitations that can cause severe problems on other software development projects. Using a waterfall process means that you are less able to adapt to change as a project progresses. For these reasons, waterfall is sometimes referred to as a heavyweight process. It is heavy because it requires considerable baggage and restricts development teams from being able to rapidly respond to change. In contrast, agile processes, a fairly recent phenomena, are lightweight processes. When following an agile process, there is less emphasis on written documentation and on having everything finalized up front. Agile processes are designed around accommodating change. XP is probably the most well-known example of an agile process. RUP is another very well-known process. Technically RUP is a process framework: It supplies a catalog of things you can mix and match in order to create your own customized process. Such a RUP process instance can straddle the fence between being a heavyweight and an agile process. When following any kind of process, heavyweight or agile, you must always do the following things when building software: analysis: determine what you need to build by gathering and refining requirements for what the software should do planning: figure out how long it will take to build the software design: determine how to put together what you are building coding: construct the software using one or more programming languages testing: ensure that what you built works deployment: deliver the software to the environment in which it will be executed and used documentation: describe the software for various audiences, including end users who need to know how to use the software and developers who need to know how to maintain the software review: ensure, through peer consensus, that the software remains maintainable and retains high quality If you are not doing all of these things, you are hackingproducing code with abandon and no consideration for business needs. Some processes such as XP appear not to promote everything in the above list. In reality, they do, but in a different, kind-of-sideways fashion. I cover little with respect to methodology in this book. You can find shelves of books devoted to learning about methodologies. Most development teams use a hybrid methodologythey take successful techniques from various published methodologies and adapt them to their own needs. Many development shops do not even acknowledge a methodology at all. But even these shops usually follow some sort of unstated process. This book is about constructing the software. Agile Java is centered on a technique known as test-driven development, or TDD. TDD is not a methodology itself but a practice that you can use as part of virtually any software development process. TDD derives from XP, where it is one of about a dozen required practices. You do not need to do XP in order to do TDD or in order to use this book! I do not discuss XP or other methodologies often in this book. I've centered Agile Java on a technique that will allow you to build and mold your code in an agile fashion. You will learn how to accommodate change in your system via TDD. Even if you are using the most rigid process imaginable, you can still use the techniques in Agile Java to construct high-quality Java code.