Agile Processes

2.9.5 Agile Processes

Extreme programming [Beck, 2000] is a somewhat controversial new approach to software development based on the iterative-and-incremental model. The fi rst step is that the software development team determines the various features ( stories ) the client would like the product to support. For each such feature, the team informs the client how long it will take to implement that feature and how much it will cost. This fi rst step corresponds to the requirements and analysis workfl ows of the iterative-and-incremental model ( Figure 2.4 ).

The client selects the features to be included in each successive build using cost–

benefi t analysis (Section 5.2), that is, on the basis of the duration and the cost estimates provided by the development team as well as the potential benefi ts of the feature to his or her business. The proposed build is broken down into smaller pieces termed

tasks . A programmer fi rst draws up test cases for a task; this is termed test-driven development (TDD). Two programmers work together on one computer ( pair programming ) [Williams, Kessler, Cunningham, and Jeffries, 2000], implementing the task and ensuring that all the test cases work correctly. The two programmers alter-nate typing every 15 or 20 minutes; the programmer who is not typing carefully checks the code while it is being entered by his or her partner. The task is then integrated into the current version of the product. Ideally, implementing and integrating a task should take no more than a few hours. In general, a number of pairs will implement tasks in parallel, so integration is essentially continuous. Team members change coding part-ners daily, if possible; learning from the other team members increases everyone’s skill level. The TDD test cases used for the task are retained and utilized in all further integration testing.

Some drawbacks to pair programming have been observed in practice [Drobka, Noftz, and Raghu, 2004]. For example, pair programming requires large blocks of uninterrupted time, and software professionals can have diffi culty in fi nding 3- to 4-hour blocks of time.

In addition, pair programming does not always work well with shy or overbearing individu-als, or with two inexperienced programmers.

A number of features of extreme programming (XP) are somewhat different from the way in which software is usually developed:

• The computers of the XP team are set up in the center of a large room lined with small cubicles.

• A client representative works with the XP team at all times.

• No individual can work overtime for two successive weeks.

• There is no specialization. Instead, all members of the XP team work on requirements, analysis, design, code, and testing.

• There is no overall design step before the various builds are constructed. Instead, the de-sign is modifi ed while the product is being built. This procedure is termed refactoring . Whenever a test case will not run, the code is reorganized until the team is satisfi ed that the design is simple, straightforward, and runs all the test cases satisfactorily.

Two acronyms now associated with extreme programming are YAGNI (you aren’t gonna need it) and DTSTTCPW (do the simplest thing that could possibly work). In other words, a principle of extreme programming is to minimize the number of features; there is no need to build a product that does any more than what the client actually needs.

Extreme programming is one of a number of new paradigms that are collectively referred to as agile processes . Seventeen software developers (later dubbed the Agile Alliance) met at a Utah ski resort for two days in February 2001 and produced the Manifesto for Agile Soft-ware Development [Beck et al., 2001]. Many of the participants had previously authored their own software development methodologies, including Extreme Programming [Beck, 2000], Crystal [Cockburn, 2001], and Scrum [Schwaber, 2001]. Consequently, the Agile Alliance did not prescribe a specifi c life-cycle model, but rather laid out a group of underlying prin-ciples that were common to their individual approaches to software development.

Agile processes are characterized by considerably less emphasis on analysis and design than in almost all other modern life-cycle models. Implementation starts much earlier in the life cycle because working software is considered more important than detailed docu-mentation. Responsiveness to changes in requirements is another major goal of agile pro-cesses, and so is the importance of collaborating with the client.

One of the principles in the Manifesto is to deliver working software frequently, ideally every 2 or 3 weeks. One way of achieving this is to use timeboxing [Jalote, Palit, Kurien, and Peeth-amber, 2004], which has been used for many years as a time management technique. A specifi c amount of time is set aside for a task, and the team members then do the best job they can during that time. Within the context of agile processes, typically 3 weeks are set aside for each iteration.

On the one hand, it gives the client confi dence to know that a new version with additional func-tionality will arrive every 3 weeks. On the other hand, the developers know that they will have 3 weeks (but no more) to deliver a new iteration without client interference of any kind; once the client has chosen the work for an iteration, it cannot be changed or increased. However, if it is impossible to complete the entire task in the timebox, the work may be reduced (“descoped”).

In other words, agile processes demand fi xed time, not fi xed features.

Another common feature of agile processes is to have a short meeting at a regular time each day. All team members have to attend the meeting. Making all the participants stand in a circle, rather than sit around a table, helps to ensure that the meeting lasts no more than the stipulated 15 minutes. Each team member in turn answers fi ve questions:

• What have I done since yesterday’s meeting?

• What am I working on today?

• What problems are preventing me from achieving this?

• What have we forgotten?

• What did I learn that I would like to share with the team?

The aim of the stand-up meeting is to raise problems, not solve them; solutions are found at follow-up meetings, preferably held directly after the stand-up meeting.

Like timeboxing, stand-up meetings are a successful management technique now utilized

60 Part A Software Engineering Concepts

sch76183_ch02_035-073.indd 60

sch76183_ch02_035-073.indd 60 04/06/10 12:34 PM04/06/10 12:34 PM

within the context of agile processes. Both timeboxed iterations and stand-up meetings are instances of two basic principles that underlie all agile methods: communication and satis-fying the client’s needs as quickly as possible.

Agile processes have been successfully used on a number of small-scale projects. How-ever, agile processes have not yet been used widely enough to determine whether this approach will fulfi ll its early promise. Furthermore, even if agile processes turn out to be good for small-scale software products, that does not necessarily mean that they can be used for medium- or large-scale software products, as will now be explained.

To appreciate why many software professionals have expressed doubts about agile pro-cesses within the context of medium- and especially large-scale software products [Reifer, Maurer, and Erdogmus, 2003], consider the following analogy by Grady Booch [2000].

Anyone can successfully hammer together a few planks to build a doghouse, but it would be foolhardy to build a three-bedroom home without detailed plans. In addition, skills in plumbing, wiring, and roofi ng are needed to build a three-bedroom home, and inspections are essential. (That is, being able to build small-scale software products does not neces-sarily mean that one has the skills for building medium-scale software products.) Further-more, the fact that a skyscraper is the height of 1000 doghouses does not mean that one can build a skyscraper by piling 1000 doghouses on top of one another. In other words, building large-scale software products requires even more specialized and sophisticated skills than those needed to cobble together small-scale software products.

A key determinant in deciding whether agile processes are indeed a major breakthrough in software engineering will be the cost of future postdelivery maintenance (Section 1.3.2). That is, if the use of agile processes results in a reduction in the cost of postdelivery maintenance, XP and other agile processes will become widely adopted. On the other hand, refactoring is an intrinsic component of agile processes. As previously explained, the product is not designed as a whole; instead, the design is developed incrementally, and the code is reorganized whenever the current design is unsatisfactory for any reason. This refactoring then continues during postdelivery maintenance. If the design of a product when it passes its acceptance test is open-ended and fl exible, then perfective maintenance should be easy to achieve at a low cost. How-ever, if the design has to be refactored whenever additional functionality is added, then the cost of postdelivery maintenance of that product will be unacceptably high. As a consequence of the newness of the approach, there are still essentially no data on the maintenance of software developed using agile processes. However, preliminary maintenance data indicate that refac-toring can consume a large percentage of the overall cost [Li and Alshayeb, 2002].

Experiments have shown that certain features of agile processes can work well. For ex-ample, Williams, Kessler, Cunningham, and Jeffries [2000] showed that pair programming leads to the development of higher-quality code in a shorter time, with greater job satisfac-tion. However, an extensive experiment to evaluate pair programming within the context of software maintenance described in Section 4.6 [Arisholm, Gallis, Dybå, and Sjøberg, 2007]

came to the same conclusion as an analysis of 15 published studies comparing the effective-ness of individual and pair programming [Dybå et al., 2007]: It depends on both the program-mer’s expertise and the complexity of the software product and the tasks to be solved.

The Manifesto for Agile Software Development essentially claims that agile processes are superior to more disciplined processes like the Unifi ed Process ( Chapter 3 ). Skeptics respond that proponents of agile processes are little more than hackers. However, there is a middle ground. The two approaches are not incompatible; it is possible to incorporate proven features

of agile processes within the framework of disciplined processes. This integration of the two approaches is described in books such as the one by Boehm and Turner [2003].

In conclusion, agile processes appear to be a useful approach to building small-scale soft-ware products when the client’s requirements are vague. In addition, some of the features of agile processes can be effectively utilized within the context of other life-cycle models.