Agile Software Development

Lecture 4

Chapter 3 Agile software development 1

 Topics covered
• Agile methods
• Extreme programming

Chapter 3 Agile software development 2

 Rapid software development
• Rapid development and delivery is now often the most
important requirement for software systems
– Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
– Software has to evolve quickly to reflect changing business
needs.

• Rapid software development

– Specification, design and implementation are inter-leaved
– System is developed as a series of versions with
stakeholders involved in version evaluation

Chapter 3 Agile software development 3

 Agile methods
• Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of agile
methods. These methods:
– Focus on the code rather than the design
– Are based on an iterative approach to software development
– Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
• The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to be
able to respond quickly to changing requirements without
excessive rework.

Chapter 3 Agile software development 4

 The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.

Chapter 3 Agile software development 5

 Agile method applicability
• Product development where a software
company is developing a small or medium-
sized product for sale.
• Because of their focus on small, tightly-
integrated teams, there are problems in
scaling agile methods to large systems.

Chapter 3 Agile software development 6

 Problems with agile methods
• It can be difficult to keep the interest of customers who are
involved in the process.
• Team members may be unsuited to the intense involvement
that characterises agile methods.
• Prioritising changes can be difficult where there are multiple
stakeholders.
• Maintaining simplicity requires extra work.

Chapter 3 Agile software development 7

 Agile methods and software
maintenance
• Most organizations spend more on maintaining
existing software than they do on new software
development. So, if agile methods are to be
successful, they have to support maintenance as
well as original development.
• Key issue:
– Can agile methods be used effectively for evolving a
system in response to customer change requests?
• Problems may arise if original development team
cannot be maintained.

Chapter 3 Agile software development 8

 EXTREME PROGRAMMING

• Extreme Programming, or XP, is a lightweight discipline

of software development based on values of simplicity,
communication, feedback, and courage
• It was developed by Kent Beck in 1996.

• XP is designed for use with small teams who need to

develop software quickly in an environment of rapidly
changing requirements.
 Extreme programming
• Perhaps the best-known and most widely used
agile method.
• Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully.

Chapter 3 Agile software development 10

 Principles:

The Four Commandments of Extreme Programming (XP)

 SIMPLICITY

 COMMUNICATION

 FEEDBACK

 AGGRESSIVENESS
 SIMPLICITY
Means that the software is developed using the simplest possible design and
constructs, but it means more.

Simplicity pervades the entire process.

XP eliminates, as much as possible, the unnecessary elements of building

software.

One of our rules is “You aren’t going to need it,” which reminds us to add
software or process only when we really need them, not in anticipation of
need.
 COMMUNICATION
is key to rapid development and to customer satisfaction.

XP represents communication with a focus on simplicity: Use person-to-person

communication instead of written documents wherever possible.

It also stresses continual communication between the customer and development

team members by having an on-site customer while development progresses.

The on-site customer decides what will be built and in what order.
 FEEDBACK
is important to any development process, but when you are trying to eliminate
everything you can, you need feedback to be sure you’re on track. Software testing is a
major source of quality feedback in XP, but we include resource, scope, and time
feedback as well.
 AGGRESSIVENESS (or courage)
in moving forward is possible when you take the simplest possible approach and
employ a process high in communication and feedback. In other words, doing the right
thing even when it is not the most popular thing to do. It means being honest about
what you can and cannot do.
 Practices:
There are twelve XP practices that the team should depend on when
adopting XP.
 The Planning Process
 Small Releases
 Testing
 Metaphor
 Simple Design
 Refactoring
 Pair Programming
 Collective Code Ownership
 Continuous Integration
 Sustainable Pace
 On-site Customer
 Coding Standard
 The Planning Process

• The Release planning

customer presents the desired features
• Iteration planning
the team is given direction every couple of weeks building a
software in 2-weeks
 Small Releases
XP teams put a simple system into production early, and update it frequently on a very
short cycle.

The team releases running, tested software, delivering business value chosen by the
Customer, every iteration.
 Testing
• also known as customer tests
XP teams focus on validation of the software at all times.
Customers provide acceptance tests that enable them to be certain that the features
they need are provided.
 Metaphor
• XP teams develop a common vision of how the program works, which we call
metaphor.

• In other words they use a common "system of names" and a common system
description that guides development and communication.
 Simple Design
• A program built with XP should be the simplest program that meets the current
requirements. There is not much building "for the future". Instead, the focus is on
providing business value.
 Refactoring
• or design improvement

• "Refactoring is the process of changing a software system in such a way that it

does not alter the external behavior of the code yet improves its internal
structure."
 Pair Programming
• XP programmers write all production code in pairs, two programmers working
together at one machine. This practice ensures that all production code is
reviewed by at least one other programmer, and results in better design, better
testing, and better code.
 Collective Code Ownership
• All the code belongs to all the programmers. This lets the team go at full speed,
because when something needs changing, it can be changed without delay, which
increases code quality and reduces defects.
 Continuous Integration
• XP teams integrate and build the software system multiple times per day. This
keeps all the programmers on the same page, and enables very rapid progress.
 Sustainable Pace
• sometimes known as 40-hour week

• XP programmers work hard and at a pace that can be sustained indefinitely. This
means they do not work overtime, unless it’s effective, keeping themselves fresh,
healthy, as to reduce as much as possible mistakes.
 On-site Customer
• An XP project is steered by a dedicated individual who is empowered to determine
requirements, set priorities, and answer questions as the programmers have them.
The effect of being there is that communication improves, with less hard-copy
documentation often one of the most expensive parts of a software project.
 Coding Standard
• For a team to work effectively in pairs, and to share ownership of all the code, all
programmers need to write the code in the same way, with rules that make sure
the code communicates clearly.
The extreme programming release
cycle

Chapter 3 Agile software development 29

Extreme programming practices (a)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Chapter 3 Agile software development 30
Extreme programming practices (b)

Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
Chapter 3 Agile software development 31