L3 – Agile Software Development

COMP3297 by Leo Yeung L3 - Agile Software Development 1

Topics covered

 Agile methods
 Agile development techniques
 Agile project management
 Scaling agile methods

COMP3297 by Leo Yeung L3 - Agile Software Development 2

Think-Pair-Share

 Question: When forming a new R&D team to recruit 8

software engineers for 5 projects, which approach would
you choose and why?
Approach A: Assign 8 Approach B: Assign 8
members to work individually or members with diverse skill sets
in pairs on separate projects. to collaborate on all 5 projects.

Project A
Project B
Project C
Project D
Project E

COMP3297 by Leo Yeung L3 - Agile Software Development 3

 Agile methods

COMP3297 by Leo Yeung L3 - Agile Software Development 4

Agile development

 Background: Rapid development and delivery is now often the

most important requirement for software systems, and Plan-driven
development does not meet these business needs.
 Agile development emerged in the late 1990s whose aim was to
radically reduce the delivery time for working software systems
 But, how?
▪ Program specification, design and implementation are inter-leaved
▪ The system is developed as a series of versions/increments with
stakeholders involved in version specification and evaluation
▪ Frequent delivery of new versions for evaluation
▪ Extensive tool support (e.g. automated testing
tools) used to support development.
▪ Minimal documentation – focus on working code

COMP3297 by Leo Yeung L3 - Agile Software Development 5

Plan-driven and agile development

Plan-based
• Separate development stages with
the outputs to be produced at each
of these stages planned in advance.
• Iteration occurs within activities.
• Not necessarily waterfall model. Plan-
driven incremental development is
possible.

Agile
• Specification, design, implementation
and testing are inter-leaved. The
outputs from the development
process are decided through a
process of negotiation during the
software development process.
• Iteration occurs across activities.

COMP3297 by Leo Yeung L3 - Agile Software Development 6

Agile manifesto

(Reference: http://agilemanifesto.org/)
COMP3297 by Leo Yeung L3 - Agile Software Development 7
The principles of agile methods

Principle Description
Customer involvement • Customers closely involved throughout the development.
• They provide/prioritize system requirements, and evaluate
system.
Incremental delivery • Develop software in increments
• Customers specify requirements in each increment
People not process • Recognize and exploit development team (& their skills)
• Develop their own ways of working without prescriptive
processes
Embrace change • Expect the system requirements to change
• Design the system to accommodate these changes
Maintain simplicity • Focus on simplicity in both software and process.
• Actively work to eliminate complexity from the system
“I choose a lazy person to do a hard job. Because a lazy
person will find an easy way to do it.” ― Bill Gates
COMP3297 by Leo Yeung L3 - Agile Software Development 8
Agile method applicability

 Product development where a software company is

developing a small or medium-sized product for sale.
 Custom system development within an organization,
▪ where there is a clear commitment from the customer to
become involved in the development process and
▪ where there are few external rules and regulations that affect
the software.

COMP3297 by Leo Yeung L3 - Agile Software Development 9

 Agile development techniques

COMP3297 by Leo Yeung L3 - Agile Software Development 10

Extreme Programming (XP)

 A very influential agile method, developed in the late

1990s, that introduced a range of agile development
techniques.
 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 (The XP release cycle)

tests run successfully.

COMP3297 by Leo Yeung L3 - Agile Software Development 11
Extreme programming practices (1)

1. Incremental planning - Requirements are recorded on story

cards, determined by the time available and relative priority,
break stories into development tasks
2. Small releases - Release system frequently and add
functionality incrementally
3. Simple design - Enough design to meet the current
requirements and no more
4. Test-first development - Write tests before implementing
the functions
5. Refactoring - Improve code as soon as possible → keep code
simple and maintainable

COMP3297 by Leo Yeung L3 - Agile Software Development 12

Extreme programming practices (2)

6. Pair programming - Developers work in pairs, check each

other’s work & provide support
7. Collective ownership - Developers work on all areas on the
system together, all developers take responsibility, anyone can
change anything

8. Continuous integration - Integrate completed task into

whole system, pass unit tests
9. Sustainable pace - Large amounts of overtime are NOT
acceptable as the net effect is often to reduce code quality and
medium-term productivity
10.On-site customer - A representative of end-user/customer in
team available full time

COMP3297 by Leo Yeung L3 - Agile Software Development 13

XP and agile principles

Agile principles XP practices

Customer • full-time customer engagement with the team
involvement
Incremental delivery • small, frequent system releases
People not process • pair programming
• collective ownership
• sustainable development process that avoids long
working hours
Embrace change • regular system releases
Maintain simplicity • constant refactoring of code

COMP3297 by Leo Yeung L3 - Agile Software Development 14

Influential XP practices

 XP has a technical focus and is not easy to integrate

with management practice in most organizations.
 Consequently, while agile development uses practices
from XP, the method as originally defined is not widely
used.
 Key practices
▪ User stories for specification
▪ Refactoring
▪ Test-first development
▪ Pair programming

COMP3297 by Leo Yeung L3 - Agile Software Development 15

User stories for requirements

 In XP, a customer or user is part of the XP team and is

responsible for making decisions on requirements.
 User requirements are expressed as user stories or
scenarios.
 These are written on cards and the development team
break them down into implementation tasks. These
tasks are the basis of schedule and cost estimates.
 The customer chooses the stories for inclusion in the
next release based on their priorities and the schedule
estimates.

COMP3297 by Leo Yeung L3 - Agile Software Development 16

Examples of task cards for a ‘prescribing medication’
story

Task cards

A ‘prescribing medication’ story

COMP3297 by Leo Yeung L3 - Agile Software Development 17

Refactoring

 Conventional wisdom in software engineering is to design for

change. It is worth spending time and effort anticipating changes as
this reduces costs later in the life cycle.
 In XP, however, maintains that this is not worthwhile as changes
cannot be reliably anticipated. Rather, it proposes constant code
improvement (refactoring) to make changes easier when they
have to be implemented.
▪ Programming team look for possible software improvements and make
these improvements even where there is no immediate need for them.
▪ This improves the understandability of the software and so reduces the
need for documentation.
▪ Changes are easier to make because the code is well-structured and
clear.
▪ However, some changes requires architecture refactoring and this is
much more expensive.
COMP3297 by Leo Yeung L3 - Agile Software Development 18
Examples of refactoring

 Re-organization of a
class hierarchy to
remove duplicate code.
 Tidying up and renaming
attributes and methods
to make them easier to
understand.
 The replacement of
inline code with calls to
methods that have been
included in a program
library.

(More examples on refactoring: https://refactoring.guru/)

COMP3297 by Leo Yeung L3 - Agile Software Development 19

Test-first development

 Testing is central to XP and XP has developed an

approach where the program is tested after every
change has been made.
 XP testing features:
▪ Test-first development.
▪ Incremental test development from scenarios.
▪ User involvement in test development and validation.
▪ Automated test harnesses are used to run all component tests
each time that a new release is built.

COMP3297 by Leo Yeung L3 - Agile Software Development 20

Test-driven development

 Writing tests before code

clarifies the requirements to be
implemented.
 Tests are written as programs
rather than data so that they can
be executed automatically. The
test includes a check that it has
executed correctly.
▪ Usually relies on a testing Example of using JUnit to detect error
framework such as Junit.
 All previous and new tests are run automatically when new
functionality is added, thus checking that the new functionality has
not introduced errors.

COMP3297 by Leo Yeung L3 - Agile Software Development 21

Customer involvement

 The role of the customer in

the testing process is to help
develop acceptance tests
for the stories that are to be
implemented in the next
release of the system.
 The customer who is part of
the team writes tests as
development proceeds. All Test case description for dose checking
new code is therefore
validated.
 However, people adopting the customer role have limited time
available and so cannot work full-time with the development team.

COMP3297 by Leo Yeung L3 - Agile Software Development 22

Problems with test-first development

 Programmers prefer programming

to testing and sometimes they take
short cuts when writing tests.
▪ For example, they may write incomplete tests that do not check for all
possible exceptions that may occur.
 Some tests can be very difficult to write incrementally.
▪ For example, in a complex user interface, it is often difficult to write
unit tests for the code that implements the ‘display logic’ and
workflow between screens.
 It is difficult to judge the completeness of a set of tests. Although
you may have a lot of system tests, your test set may not provide
complete coverage.

COMP3297 by Leo Yeung L3 - Agile Software Development 23

Pair programming

 Involves programmers working in

pairs, developing code together.
 Advantages:
▪ Helps develop common
ownership of code and spreads
knowledge across the team.
Reduce overall risks when team Programmers sit together at the
members leave same computer for development
▪ Serves as an informal review
process as each line of code is
looked at by more than one
Think-Pair-Share
person.
▪ Encourages refactoring as the Is pair programming less
whole team can benefit from efficient than individual
improving the system code. programming? Why?

COMP3297 by Leo Yeung L3 - Agile Software Development 24