Agile software development is a general name for a family of related methodologies, including Extreme Programming (XP), Scrum, Crystal Methodologies, Adaptive Software Development, and others. Its core principles emphasize empowering the programmer through small self-organizing teams, close collaboration with customers, use of iterative development cycles, and continuous unit testing and integration by the developers.
Older methodologies from the so-called “traditional” approaches emphasize rigorous planning and a document-driven, waterfall lifecycle. Some of the traditional methodologies are attempting to reinvent themselves by incorporating agile principles, but they usually retain a centralized predictive planning process. The Rational Unified Process (RUP) is often classified as a traditional waterfall methodology but is actually a process framework that can be specialized for iterative agile development.
In many ways agile development is more about attitude than about development tools. However, having the right tools can go a long way toward giving you a good attitude—and Eclipse fits the bill perfectly. Both XP and Eclipse grew out of the Smalltalk development community. The first XP project was a Smalltalk project, and many of the original Eclipse platform developers were previously Smalltalk tool developers. Many of the tools and techniques included in Eclipse have been done before in Smalltalk, such as the Smalltalk Refactoring Browser, Envy/Developer's repository tools, “3-pane” browsers, the Outline view, incremental compilation, and more.
The Agile Manifesto was born in February 2001 when a group of methodologists gathered to share and promote their common vision for software development. At this meeting they agreed to use the term “agile” to describe their common ideas. The manifesto is a statement of values and principles for agile software development (see http://www.agilemanifesto.org and the related site http://www.agilealliance.org).
The manifesto includes twelve principles that fall roughly into two categories: programmer empowerment and iterative development. We'll review five of those principles that are especially relevant to programming activities. An agile development project is composed of small teams (5 to 10 programmers per team) where the programmers are actively involved in elaborating the initial requirements and adapting to changes.
Business people and developers must work together daily throughout the project.
The best architectures, requirements, and designs emerge from self-organizing teams.
Project deliverables are planned as a series of releases where each release is the result of one or more short development iterations. Only the current or next iteration is planned in detail. Future iterations have features, user stories, or use cases assigned to them but are not planned with detailed task assignments.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
Continuous attention to technical excellence and good design enhances agility.
A typical release cycle is shown in Figure 8-1 (Leffingwell & Muirhead, 2004). The product owners contribute the initial feature requests or use cases, but these requirements are not documented in complete detail at this stage. For larger projects, the features are assigned to a release within the roadmap, or the roadmap is adjusted to accommodate requirements changes during interim releases. Just as your car's dashboard and steering wheel provide feedback and control while driving, the Track & Adjust component of an agile process requires feedback about the project's status and opportunities to adjust the next steps of its progress. This feedback may come from users, test metrics, an issue list, iteration progress, or work backlog.
Agile development is often based on two kinds of plans (Kruchten, 2004):
A coarse-grained plan: the phase or release plan.
A series of fine-grained plans: the iteration plans.
The investment in long-range (longer than one or two iterations) speculative plans is reduced, and the lack of precision and accuracy in such plans is acknowledged. Release plans are therefore intentionally coarse-grained, less comprehensive, and less precise. Iteration plans are focused on the short-run and are less speculative and thus are worthy of greater estimating investment and precision.
The development team can and should be expected to embrace change. But in order for the team to fulfill its responsibility of delivering a deployable product at each iteration, the team must be able to commit and deliver on the iteration plan. Changing the iteration plan midstream invites chaos and severely threatens the ability of the development team to deliver at the end of an iteration.
It is important that the development team deliver working software at every iteration for several reasons:
It is the only way to objectively demonstrate progress.
It is the only way users can provide concrete feedback based on actual usage of the software.
Like a missed manufacturing deadline, it hurts the company's rhythm and morale when the team cannot deliver on an iteration.
Moreover, the shorter the iteration, the more practical it becomes to freeze an iteration while maintaining the team's ability to embrace change.
The agile development process includes an underlying activity for tracking and adjusting the plan based on input from developers and customers. It is essential that the agile process itself is adaptable and responsive to changes in the project environment. At the end of each iteration, the team must reflect on what worked and what did not and then must make decisions about what to do differently next time.
Each release cycle consists of a series of time-boxed development iterations. XP recommends iterations of one to three weeks in duration, and Scrum recommends fixed-length 30-day iterations. Whatever timeframe you use, it should be short and focused. The most important benefit is that fixed time iterations introduce near-term milestones that force both the team and implemented code to converge on working software deliveries at regular intervals. As stated in the Agile Manifesto: Working software is the primary measure of progress.
The iterative development process is shown in Figure 8-2. Several iterations may be completed within each release cycle. The scope and focus of an iteration must be negotiated and agreed to by product owners and developers before the iteration begins. Because the development teams are self-managed, developers participate in estimating task duration and take responsibility for tasks as the iteration cycle unfolds. A daily team meeting tracks issues and progress toward completion of the time-boxed iteration.
The nested development cycle represents the work of individual developers (or pairs of programmers in XP) on the team. One iteration cycle includes several passes through the nested development cycle. The number of development cycles depends on the number and breadth of requirements that must be elaborated.
Agile development teams are empowered to work with users directly and to elaborate initial requirements as they proceed. This represents a sharp departure from the traditional waterfall process model, where we assume that developers are interchangeable resources who are given a reasonably complete set of requirements to implement. This assumes that someone spent the time inventing, defining, and vetting requirements documents with the key stakeholders. We also assumed that this time was invested before the development process began. It may or may not have worked, but at least it was easy to describe!
Requirements are more abstract in agile practices. They are never frozen (except within the bounds of short iterations), and the team has much more accountability in making certain they are building the right thing. This means the agile team has a higher degree of involvement in defining the system under construction. In turn, this means the development team members and product owners work hand-in-hand in a nearly continuous process.
Eclipse provides a development platform that supports and accelerates the agile development cycle. We'll examine the details of those platform features in the remainder of this chapter and the six that follow it.
Eclipse is a flexible platform that can accommodate varying preferences for developer style, compiler settings, and project configuration. However, the entire agile development process is itself subject to reflection, adjustment, and adaptation. The Eclipse platform accepts plug-in contributions that can radically alter and extend its capabilities to support new unforeseen development needs.
Extreme Programming (XP), as a member of the agile development family, outlines a set of twelve practices for achieving successful results (Beck, 1999). We'll explore five of those practices that are especially relevant to programming activities: testing, refactoring, continuous integration, collective ownership, and coding standards. This section provides a roadmap for the next chapters that describe how Eclipse supports each practice.
Most of the time we think about using agile processes for adapting the software being developed to satisfy the changing requirements of its customers. However, the process itself is also adaptive. A project that begins using an adaptive process probably won't have exactly the same process a year later, especially if your team is new to agile development. And different processes may be needed when designing embedded systems, developing software products for resale, or building operational support systems.
Our immediate interest is to understand how the Eclipse platform can be adapted to support these different processes and their needs. For example, agile development recommends writing unit tests before implementing the corresponding functionality. Eclipse includes excellent support for JUnit testing (http://www.junit.org), but your team may need flexibility in deciding how to test previously implemented code that is integrated into your project. A common approach is to write unit tests for existing code only when resolving bug reports or when refactoring that code. Your team has the responsibility and authority to make decisions about the best test strategy.
These and other adaptations are described in the following chapters. Each chapter concludes with a section on new plug-in contributions that can be added to extend the platform capabilities described in that chapter.
Programmers continually write unit tests that must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. Creation of tests is an on-going development activity that becomes part of the program itself. Regardless of who refactors, enhances, or corrects a bug in a program, an automated test suite is available to verify correct behavior.
When a bug is fixed, either a relevant test was missing or the test was incorrect or incomplete. This will often be the case when existing code is brought into the project without a test suite or when a team is just getting started with agile development processes. No problem—just write a unit test so that the same errant behavior will be easily caught in the future.
The benefits of continuous testing are considerable, but a commitment and investment of time is required of every member of your team. Many developers and their managers see writing unit tests as a waste of time, when in reality they are verifying that the software works—and continues to work—as per the use cases. Agile development methods accept the reality that requirements will continue to evolve over the course of a project. That evolution will require refactoring to keep the flexibility that allows evolution. When code is refactored, it must be reverified, which is accomplished by running unit tests. The greatest gains are realized when unit testing is continuous and automated.
We focus on JUnit functionality that is built into Eclipse. JUnit is the most widely used unit testing framework for Java, and its simple but powerful framework has been ported to many other programming languages. Writing unit tests is still a time-consuming activity, but the wizards and views provided by Eclipse help you get started so that you can reap the rewards.
Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. Developers welcome change at any time when using agile development practices, but doing so requires that the code itself is adapted easily. In addition, because the code is the primary deliverable, it must communicate its intent to anyone who reads it. Refactoring makes this possible.
You don't refactor on speculation or for elegance. You refactor by asking if there is a way to change the code to make adding a new feature easier or to remove duplicate code. Having a complete unit test suite for the code being refactored gives you confidence that the revised code still passes these tests and thus provides the same behavior.
Some examples of refactoring include renaming a variable, method, class, or package; changing a method signature; extracting an interface from a concrete class; and pulling up methods from a subclass into an abstract superclass (Fowler, 1999). A refactoring is not one big change as much as it is a series of small steps.
Refactoring your code can be a very time-consuming activity when changing a method or type name that is widely used in your project. Eclipse makes this process stunningly easy. You can review the proposed changes from a refactoring and then accept only a subset of the changes or reject the entire set of changes to take a different approach. After using the refactoring support in Eclipse, you'll never be able to do without it.
Integrate and build the entire system many times a day, every time a task is completed. Integrating one set of changes at a time makes it easy to identify problems and prevents a surprise at the end of an iteration. All developers and customers working on a team keep a current view of the iteration's progress.
If integration took several hours, it would not be possible to work in this style. It is important to have tools that support a fast integration build and test cycle. You also need a reasonably complete test suite that verifies successful integration of a new component.
Eclipse includes flexible support for automatically building your project as each file is saved, using either the built-in compiler and project configurations or a customized Ant build script (http://ant.apache.org). The Ant editor, Outline view, and runtime configurations help you to create and execute large, complex build scripts, all from within the Eclipse IDE.
Anyone can change any code anywhere in the system at any time. This ensures that every developer takes responsibility for the entire system and is not held up when another component needs refactoring or causes a test to fail. Not everyone knows every part equally well, although everyone knows something about every part.
Collective ownership requires good tools that enable efficient code sharing and a team culture that encourages such behavior. Eclipse provides world-class tool support in this area. Generic team features are provided that can be bound to many different version control repositories. CVS support is provided in the standard download, and additional plug-ins are available for other repositories.
In agile development processes, the code is of central importance in documenting system design and behavior, and this is possible only when consistent coding standards are used. In addition, collective ownership and refactoring mean that all developers are likely to touch much of the source code.
Eclipse provides extensive customization of automated code formatting rules, code generation and Content Assist templates, Javadoc templates, and built-in spell checkers for comments. Additional plug-in contributions are available for checking the code style against standards.
Agile software development is a general name for a family of related methodologies that emphasize empowering the programmer through small self-organizing teams, close collaboration with customers, use of iterative development cycles, and continuous unit testing and integration by the developers.
Projects are guided by two-level planning: a coarse-grained release plan and a fine-grained iteration plan.
Eclipse provides a development platform that supports and accelerates the agile development cycle and that may be radically customized through plug-in contributions.
Five agile development practices are especially relevant to programming in Eclipse: testing, refactoring, continuous integration, collective ownership, and coding standards.