Chapter Comments 4-1

Chapter 4

Agile Development

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to discuss the “agile” philosophy and to present a variety of agile process models and methodologies. The overriding theme of this chapter is that everyone wants an agile process—the only debate is on how to achieve one and the level of discipline that is incorporated into such process models. Most students love the agile approach for the wrong reasons. They interpret it as glorified hacking. Be certain that you emphasize that engineering discipline and agility are NOT mutually exclusive.

4.1 What is Agility?

The main point of this section is to introduce agility in the context of software development. Agility is more than change management. Agility means that customers and developers need to work together as collaborators on the development team and try to build products that can be adapted to a rapidly changing market place. Part of this adaptation is learning when and how to streamline the production of work products and focus on the development of incremental operational prototypes.

Spend some time talking about the ramifications of the manifesto (noted in the chapter introduction and then note that none of this implies that discipline is discarded. Software engineering emphasizes each element noted in the manifesto. Also note that the agile philosophy is seductive, but must be tempered by the demands of real systems in the real world. On the positive side, note that many of the ideas espoused as part of the agile approach are excellent and worth considering regardless of the process model a team adopts.

4.2 What is an Agile Process?

This section continues to refine the notion of applying agility to software process models. All agile processes are adaptable to manage unpredictable changes that take place during software development projects. Agile processes rely heavily on customer feedback generated by their evaluation of operational prototypes. The focus of agile processes is on the delivery of software increments in relatively short timeframes. It is important for students to be exposed to the arguments for agile development (product is more important than documentation) and against agile development (rapidly produced prototypes do not always scale up to enterprise-wide software applications). The idea of tradeoffs is an important point to emphasize here. A third part of this section deals with human factors and group dynamics of agile teams. Students should not underestimate the potential problems that can result if teams do not function well.

Each of the agility principles presented in Section 4.2.1 should be discussed at length. Ask your students how they would achieve each. One of the best debates about agile development appeared in the June 2003 issue of IEEE Computer. You might want to assign it as additional reading if you’re emphasizing agility.

4.3 Agile Process Models

Several agile process models are discussed in this section. Your students may have some misconceptions about some of these models from experiences prior to this course. For example, extreme programming does not mean writing code without documentation or testing. Many of these process models make references to chapters later in the text. Your students may need additional background to appreciate some of the points made about this process models. The point of this section is to expose students to the philosophies and activities associated with these agile process models. They should be encouraged to look for the common elements found in each. For the most part students will not be able to apply these process models to their own projects at this point in the course. They should have enough background to apply these models are reading the text chapters on analysis modeling, object-oriented analysis, and testing strategies.

There is little debate that XP is the most dominant of all agile models (at this point in time), and yet, the other models presented in the Sections 4.3.2 – 4.3.7 have characteristics that are worth noting (e.g., the Scrum stand-up meeting). It’s unlikely that you’ll have time to cover each of the models presented. Therefore, I suggest presenting XP and emphasizing user stories, pair-programming, refactoring, and continuous integration as important XP concepts and then supplementing with elements of the other models that you consider to be noteworthy.

The terms “collaboration” and “self-organizing teams” are used repeatedly when agile development is presented. You might discuss the meaning of these terms with your students.

The following characteristics are notable for each of the agile models discussed:

XP— user stories, pair-programming, refactoring, and continuous integration, incremental delivery

ASD—adaptive cycle planning, time-boxing, risk-driven planning, collaborative learning, self-organizing teams

DSDM—operationalized prototyping

Scrum—backlog, sprints, scrum meetings

Crystal— a set of example agile processes, useful principles

FDD—plan, design, and build by feature

AM—modeling principles (applicable throughout this book)