Download Agile Software Development: Extreme Programming (XP) and Scrum Overview and more Study notes Software Engineering in PDF only on Docsity!
72 PAR T ONE THE SOFTWARE PROCESS
If you have further interest, see [Hig01], [Hig02a], and [DeM02] for an enter- taining summary of other important technical and political issues.
5.4 E X T R E M E P R O G R A M M I N G
In order to illustrate an agile process in a bit more detail, we’ll provide you with an overview of Extreme Programming (XP), the most widely used approach to agile software development. Although early work on the ideas and methods as- sociated with XP occurred during the late 1980s, the seminal work on the subject has been written by Kent Beck [Bec04a]. A variant of XP, called Industrial XP (IXP), refines XP and targets the agile process specifi cally for use within large organizations [Ker05].
5.4.1 The XP Process
Extreme Programming uses an object-oriented approach (Appendix 2) as its pre- ferred development paradigm and encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing. Figure 5.2 illustrates the XP process and notes some of the key ideas and tasks that are associated with each framework activity. Key XP activities are summarized in the paragraphs that follow. Planning. The planning activity (also called the planning game ) begins with listening —a requirements gathering activity that enables the technical members
WebRef An award-winnng “process simulation game” that includes an XP process module can be found at http://www.ics .uci.edu/~emilyo/ SimSE/downloads .html.
What is an
? XP “story”?
user stories values acceptance test criteria iteration plan
simple design CRC cards
unit test software increment project velocity computed continuous integration
spike solutions prototypes
refactoring
pair programming
acceptance testing
Release
design
coding
planning
test
FIGURE 5.
The Extreme Programming process
CHAPTER 5 AGILE DEVELOPMENT 73
of the XP team to understand the business context for the software and to get a broad feel for required output and major features and functionality. Listening leads to the creation of a set of “stories” (also called user stories ) that describe required output, features, and functionality for software to be built. Each story (similar to use cases described in Chapter 8) is written by the customer and is placed on an index card. The customer assigns a value (i.e., a priority) to the story based on the overall business value of the feature or function. 2 Members of the XP team then assess each story and assign a cost —measured in development weeks—to it. If the story is estimated to require more than three development weeks, the customer is asked to split the story into smaller stories and the as- signment of value and cost occurs again. It is important to note that new stories can be written at any time. Customers and developers work together to decide how to group stories into the next release (the next software increment) to be developed by the XP team. Once a basic commitment (agreement on stories to be included, delivery date, and other project matters) is made for a release, the XP team orders the stories that will be developed in one of three ways: (1) all stories will be implemented immediately (within a few weeks), (2) the stories with highest value will be moved up in the schedule and implemented first, or (3) the riskiest stories will be moved up in the schedule and implemented first. After the first project release (also called a software increment) has been de- livered, the XP team computes project velocity. Stated simply, project velocity is the number of customer stories implemented during the first release. Project velocity can then be used to (1) help estimate delivery dates and schedule for subsequent releases and (2) determine whether an overcommitment has been made for all stories across the entire development project. If an overcommitment occurs, the content of releases is modified or end delivery dates are changed. As development work proceeds, the customer can add stories, change the value of an existing story, split stories, or eliminate them. The XP team then re- considers all remaining releases and modifies its plans accordingly. Design. XP design rigorously follows the KIS (keep it simple) principle. A sim- ple design is always preferred over a more complex representation. In addition, the design provides implementation guidance for a story as it is written—nothing less, nothing more. The design of extra functionality (because the developer as- sumes it will be required later) is discouraged.^3 XP encourages the use of CRC cards (Chapter 10) as an effective mech- anism for thinking about the software in an object-oriented context. CRC
XP deemphasizes the importance of design. Not everyone agrees. In fact, there are times when design should be emphasized.
WebRef A worthwhile XP “planning game” can be found at: http://csis.pace. edu/~bergin/xp/ planninggame .html.
Project velocity is a subtle measure of team productivity.
2 The value of a story may also be dependent on the presence of another story. 3 These design guidelines should be followed in every software engineering method, although there are times when sophisticated design notation and terminology may get in the way of simplicity.
CHAPTER 5 AGILE DEVELOPMENT 75
(KIS). Once the code is complete, it can be unit-tested immediately, thereby pro- viding instantaneous feedback to the developers. A key concept during the coding activity (and one of the most talked-about as- pects of XP) is pair programming. XP recommends that two people work together at one computer workstation to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance (the code is reviewed as it is created). It also keeps the develop- ers focused on the problem at hand. In practice, each person takes on a slightly different role. For example, one person might think about the coding details of a particular portion of the design while the other ensures that coding standards (a required part of XP) are being followed or that the code for the story will satisfy the unit test that has been developed to validate the code against the story.^7 As pair programmers complete their work, the code they develop is inte- grated with the work of others. In some cases this is performed on a daily basis by an integration team. In other cases, the pair programmers have integration responsibility. This “continuous integration” strategy helps to avoid compatibility and interfacing problems and provides a “smoke testing” environment (Chap- ter 22) that helps to uncover errors early. Testing. The unit tests that are created should be implemented using a frame- work that enables them to be automated (hence, they can be executed easily and repeatedly). This encourages a regression testing strategy (Chapter 22) when- ever code is modified (which is often, given the XP refactoring philosophy). As the individual unit tests are organized into a “universal testing suite” [Wel99], integration and validation testing of the system can occur on a daily basis. This provides the XP team with a continual indication of progress and also can raise warning flags early if things go awry. Wells [Wel99] states: “Fixing small problems every few hours takes less time than fixing huge problems just before the deadline.” XP acceptance tests , also called customer tests, are specifi ed by the customer and focus on overall system features and functionality that are visible and re- viewable by the customer. Acceptance tests are derived from user stories that have been implemented as part of a software release.
5.4.2 Industrial XP
Joshua Kerievsky [Ker05] describes Industrial Extreme Programming (IXP) in the following manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs most from the origi- nal XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” IXP incorporates six new practices that
XP acceptance tests are derived from user stories.
What new practices are appended to XP to create IXP?
Many software teams are populated by individualists. You’ll have to work to change that culture if pair programming is to work effectively.
How are unit tests used in XP?
What is pair programming?
7 Pair programming has become so widespread throughout the software community that The Wall Street Journal [Wal12] ran a front-page story about the subject.
76 PAR T ONE THE SOFTWARE PROCESS
are designed to help ensure that an XP project works successfully for significant projects within a large organization: Readiness assessment. The IXP team ascertains whether all members of the project community (e.g., stakeholders, developers, management) are on board, have the proper environment established, and understand the skill levels involved. Project community. The IXP team determines whether the right people, with the right skills and training have been staged for the project. The “community” encompasses technologists and other stakeholders. Project chartering. The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. Test-driven management. An IXP team establishes a series of measurable “destinations” [Ker05] that assess progress to date and then defines mecha- nisms for determining whether or not these destinations have been reached. Retrospectives. An IXP team conducts a specialized technical review (Chapter 20) after a software increment is delivered. Called a retrospec- tive, the review examines “issues, events, and lessons-learned” [Ker05] across a software increment and/or the entire software release. Continuous learning. The IXP team is encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher-quality product. In addition to the six new practices discussed, IXP modifies a number of exist- ing XP practices and redefines certain roles and responsibilities to make them more amenable to significant projects for large organizations. For further discus- sion of IXP, visit http://industrialxp.org.
uote:
“Ability is what you're capable of doing. Motivation determines what you do. Attitude determines how well you do it.” Lou Holtz
Considering Agile Software DevelopmentConsidering Agile Software Development The scene: Doug Miller’s office. The Players: Doug Miller, software engineering manager; Jamie Lazar, software team member; Vinod Raman, software team member. The conversation: (A knock on the door, Jamie and Vinod enter Doug’s offi ce.) Jamie: Doug, you got a minute?
Doug: Sure Jamie, what’s up? Jamie: We’ve been thinking about our process discus- sion yesterday... you know, what process we’re going to choose for this new SafeHome project. Doug: And? Vinod: I was talking to a friend at another company, and he was telling me about Extreme Programming. It’s an agile process model... heard of it?
S AFE H OME
78 PAR T ONE THE SOFTWARE PROCESS
5.5.1 Scrum
Scrum (the name is derived from an activity that occurs during a rugby match) 9 is an agile software development method that was conceived by Jeff Sutherland and his development team in the early 1990s. In recent years, further devel- opment on the Scrum methods has been performed by Schwaber and Beedle [Sch01b]. Scrum principles are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the following frame- work activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks occur within a process pattern (discussed in the following paragraph) called a sprint. The work conducted within a sprint (the number of sprints required for each framework activity will vary depending on product complexity and size) is adapted to the problem at hand and is defined and often modified in real time by the Scrum team. The overall flow of the Scrum process is illustrated in Figure 5.3.
WebRef Useful Scrum informa- tion and resources can be found at www. controlchaos.com.
9 A group of players forms around the ball and the teammates work together (sometimes violently!) to move the ball downfield.
every 24 hours
30 days
Scrum : 15 minute daily meeting. Team members respond to basics:
- What did you do since last Scrum meeting?
- Do you have any obstacles?
- What will you do before next meeting?
Sprint Backlog: Feature(s) assigned to sprint
Product Backlog: Prioritized product features desired by the customer
Backlog items expanded by team
New functionality is demonstrated at end of sprint
FIGURE 5.3 Scrum process flow
CHAPTER 5 AGILE DEVELOPMENT 79
Scrum emphasizes the use of a set of software process patterns [Noy02] that have proven effective for projects with tight timelines, changing requirements, and business criticality. Each of these process patterns defines a set of develop- ment activities: Backlog —a prioritized list of project requirements or features that provide business value for the customer. Items can be added to the backlog at any time (this is how changes are introduced). The product manager assesses the back- log and updates priorities as required. Sprints —consist of work units that are required to achieve a requirement defi ned in the backlog that must be fit into a predefined time-box 10 (typically 30 days). Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows team members to work in a short-term, but stable environment. Scrum meetings —are short (typically 15-minute) meetings held daily by the Scrum team. Three key questions are asked and answered by all team mem- bers [Noy02]:
- What did you do since the last team meeting?
- What obstacles are you encountering?
- What do you plan to accomplish by the next team meeting? A team leader, called a Scrum master, leads the meeting and assesses the re- sponses from each person. The Scrum meeting helps the team to uncover poten- tial problems as early as possible. Also, these daily meetings lead to “knowledge socialization” [Bee99] and thereby promote a self-organizing team structure. Demos —deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the cus- tomer. It is important to note that the demo may not contain all planned func- tionality, but rather those functions that can be delivered within the time-box that was established. Beedle and his colleagues [Bee99] present a comprehensive discussion of these patterns in which they state: “Scrum assumes up-front the existence of chaos.. .” The Scrum process patterns enable a software team to work success- fully in a world where the elimination of uncertainty is impossible.
5.5.2 Dynamic Systems Development Method
The Dynamic Systems Development Method (DSDM) [Sta97] is an agile software development approach that “provides a framework for building and maintain- ing systems which meet tight time constraints through the use of incremental
WebRef Useful resources for DSDM can be found at www.dsdm.org.
10 A time-box is a project management term (see Part 4 of this book) that indicates a period of time that has been allocated to accomplish some task.
Scrum incorporates a set of process patterns that emphasize project priorities, compart- mentalized work units, communication, and frequent customer feedback.
CHAPTER 5 AGILE DEVELOPMENT 81
required, the degree of formalism suggested, the sheer size of the models for large projects, and the difficulty in maintaining the model(s) as changes occur. Is there an agile approach to software engineering modeling that might provide some relief? At “The Official Agile Modeling Site,” Scott Ambler [Amb02a] describes agile modeling (AM) in the following manner: Agile Modeling (AM) is a practice-based methodology for effective modeling and doc- umentation of software-based systems. Simply put, Agile Modeling (AM) is a collec- tion of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. Agile models are more effective than traditional models because they are just barely good, they don’t have to be perfect. Agile modeling adopts all of the values that are consistent with the agile man- ifesto. The agile modeling philosophy recognizes that an agile team must have the courage to make decisions that may cause it to reject a design and refactor. The team must also have the humility to recognize that technologists do not have all the answers and that business experts and other stakeholders should be re- spected and embraced. Although AM suggests a wide array of “core” and “supplementary” modeling principles, those that make AM unique are [Amb02a]: Model with a purpose. A developer who uses AM should have a specific goal (e.g., to communicate information to the customer or to help better understand some aspect of the software) in mind before creating the model. Once the goal for the model is identified, the type of notation to be used and level of detail required will be more obvious. Use multiple models. There are many different models and notations that can be used to describe software. Only a small subset is essential for most proj- ects. AM suggests that to provide needed insight, each model should present a different aspect of the system and only those models that provide value to their intended audience should be used. Travel light. As software engineering work proceeds, keep only those models that will provide long-term value and jettison the rest. Every work product that is kept must be maintained as changes occur. This represents work that slows the team down. Ambler [Amb02a] notes that “Every time you decide to keep a model you trade off agility for the convenience of having that information avail- able to your team in an abstract manner (hence potentially enhancing commu- nication within your team as well as with project stakeholders).” Content is more important than representation. Modeling should impart in- formation to its intended audience. A syntactically perfect model that imparts little useful content is not as valuable as a model with flawed notation that nevertheless provides valuable content for its audience.
“Traveling light” is an appropriate philosophy for all software engi- neering work. Build only those models that provide value... no more, no less.
uote:
“I was in the drugstore the other day trying to get a cold medication... Not easy. There’s an entire wall of products you need. You stand there going, Well, this one is quick acting but this is long lasting ... Which is more important, the present or the future?” Jerry Seinfeld
82 PAR T ONE THE SOFTWARE PROCESS
Know the models and the tools you use to create them. Understand the strengths and weaknesses of each model and the tools that are used to create it. Adapt locally. The modeling approach should be adapted to the needs of the agile team. A major segment of the software engineering community has adopted the Unified Modeling Language (UML)^11 as the preferred method for representing analysis and design models. The Unified Process (Chapter 4) has been devel- oped to provide a framework for the application of UML. Scott Ambler [Amb06] has developed a simplified version of the UP that integrates his agile modeling philosophy.
5.5.4 Agile Unified Process
The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative in the small” [Amb06] philosophy for building computer-based systems. By adopt- ing the classic UP phased activities—inception, elaboration, construction, and transition—AUP provides a serial overlay (i.e., a linear sequence of software engineering activities) that enables a team to visualize the overall process flow for a software project. However, within each of the activities, the team iterates to achieve agility and to deliver meaningful software increments to end users as rapidly as possible. Each AUP iteration addresses the following activities [Amb06]:
- Modeling.^ UML representations of the business and problem domains are created. However, to stay agile, these models should be “just barely good enough” [Amb06] to allow the team to proceed.
- Implementation.^ Models are translated into source code.
- Testing.^ Like XP, the team designs and executes a series of tests to un- cover errors and ensure that the source code meets its requirements.
- Deployment.^ Like the generic process activity discussed in Chapters 3, deployment in this context focuses on the delivery of a software increment and the acquisition of feedback from end users.
- Configuration and project management.^ In the context of AUP, configu- ration management (Chapter 29) addresses change management, risk management, and the control of any persistent work products^12 that are produced by the team. Project management tracks and controls the prog- ress of the team and coordinates team activities.
11 A brief tutorial on UML is presented in Appendix 1. 12 A persistent work product is a model or document or test case produced by the team that will be kept for an indeterminate period of time. It will not be discarded once the software increment is delivered.
