Software Engineering I

Session 10

Agile Software Development

Recap

• Software processes
– Software process models
– Waterfall, iterative and incremental development,
integration and configuration, …
– Plan-driven approaches:
• each of these stages is planned in advance;
• not necessarily waterfall
– plan-driven, incremental development is possible;

• This week: agile approaches

Rapid Software Development

• Rapid development and delivery is now often the most important

requirement for software development
– Software has to evolve quickly to reflect changing business needs

• Plan-driven development is essential for some types of system

– but does not promote rapid development
– the ability to deal with rapidly changing requirements

• Agile development aims to

– radically reduce the delivery time for working software systems
– accommodate changing requirements during development.
Overview

• Dissatisfaction with the overheads involved in software design

methods of the 80s-90s led to the creation of agile methods.
• These methods:
– Focus on the code rather than the design
– Are based on an incremental 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
– by limiting documentation
– be able to respond quickly to changing requirements without excessive
rework.
Agile

• Agile is not a process or a methodology

– Agile does not explicitly say what to do, how to do it, or in what order it
should be done
• Agile is a set of values and principles designed to inform
software development practice
• The core values of agile are:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan

• The core agile principles are set out in the Agile Manifesto
(http://agilemanifesto.org/)
Agile Manifesto

Customer Focus Satisfy the customer through early and continuous delivery
of useful software.
Embrace Change Welcome changing requirements, even late in
development.
Incremental Deliver working software frequently, in the shortest
Delivery possible timeframe.
Customer Work together with customers throughout a project
Involvement lifetime.
People over Build projects around motivated individuals. Build a
Process positive environment, based on trust.
Team Dynamics The most efficient and effective method of team
communication is regular face-to-face conversation.
• Continued >>
Agile Manifesto

Realistic Agile processes promote sustainable development. The

Workload sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Skills focus Continuous attention to technical excellence and good design
enhances agility.
Simplicity The art of maximising the amount of work NOT done is
essential.
Team Focus The best architectures, requirements, and designs emerge
from self-organising teams.
Reflective At regular intervals, the team reflects on how to become more
Practice effective, then tunes and adjusts its behaviour accordingly.
Agile Methods

• An agile method is an approach to software development that

applies agile values and principles to the development process.
• Examples of agile methods are:
– Extreme Programming
– Scrum (project management)
– Kanban
– Crystal Methods

• Individual agile methods are distinguished from one another by

the specific practices they use to realise agile values and
principles.
Agile method applicability

• Product development
– where a software company is developing a small or medium-sized product for
sale
– Virtually all small software products and apps are now developed using an
agile approach

• Custom system development within an organisation

– where there is a clear commitment from the customer to become involved in
the development process
– where there are few external rules and regulations that affect the software
Extreme Programming (XP)

• Extreme programming is an influential agile method

– developed in the late 1990s
– introduced a range of revolutionary development techniques
– Kent Beck (https://en.wikipedia.org/wiki/Kent_Beck)

• XP takes an extreme approach to incremental 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.
XP Development and Release Cycle
XP – Key Practices

XP Practice Description
User stories and Functional requirements are created from user stories. Developers
task cards. break user stories into development tasks.
Refactoring Code is continually reworked and finessed, with the aim of keeping it
simple and maintainable.
Test-first An automated unit test framework is used to write tests for a new
development piece of functionality, before that functionality itself is implemented.
The customer helps write the tests.
Pair programming Developers work in pairs, checking each other’s work and providing
peer support.
User stories and task cards
XP – User Stories and Task Cards

• In XP, user requirements are expressed as user stories.

– User stories are written from the user’s perspective.
– One user may have several user stories.

• Each user story represents a chunk of functionality.

• The customer chooses the stories for inclusion in the successive
releases
– based on their priorities and scheduling estimates

• User stories are decomposed by developers into implementation

tasks.
– Tasks form the basis of schedule and cost estimates.
XP – User Stories
• User stories are written in informal,
natural language.

• They should be simple and concise (a

few sentences).

• They describe system requirements

from a user perspective.

• They do not contain technical detail.

• User stories should also specify

acceptance criteria
– e.g., post-conditions that show that the
story has been successfully completed.
XP – User Stories – Tasks

• Tasks are derived from user

stories.

• They are written by developers.

• should be short and concise, and

written in natural language.
Refactoring
Problem: "Bit rot"

• Code maintenance is hard!

• After several months and new versions, many codebases reach one
of the following states:
– rewritten: little remains from the original code.
– abandoned: The original code is thrown out and rewritten from scratch.
– … even if the code was initially reviewed and well-designed at the time of
commit, and even if changes are reviewed

• Why is this?
– Systems evolve to meet new needs and add new features
– If the code's structure does not evolve accordingly, it will "rot"
Code maintenance …

• Code maintenance: modification of a software

product after it has been delivered.

• Purposes:
– fixing bugs
– improving performance
– improving design
– adding features

• ~80% of maintenance is for non-bug-fix-related

activities such as adding functionality (Pigosky 1997)
Code maintenance is hard

• It's harder to maintain code than write new code.

– You must understand code written by another developer, or code
you wrote at a different time with a different mindset
– Danger of errors in fragile, hard-to-understand code

• Maintenance is how developers spend most of their time

– Many developers hate code maintenance.

• It pays to design software well and plan ahead so that

later maintenance will be less painful
– Capacity for future change must be anticipated
What is Refactoring?

• refactoring: Improving a piece of software's

internal structure without altering its external
behaviour.
– Incurs a short-term time/work cost to reap long-term
benefits
– A long-term investment in the overall quality of your
system

• refactoring is not the same thing as:

– rewriting code
– adding features
– debugging code
Why refactor?

• Why fix a part of your system that isn't broken?

• Each part of your system's code has 3 purposes:
– to execute its functionality,
– to allow change,
– to communicate well to developers who read it.

• If the code does not do one or more of these, it is broken.

• Refactoring improves software's design

– To make it more extensible, flexible, understandable, performant, …
– But every design improvement has costs (and risks)
When to refactor?

• When is it best for a team to refactor their code?

– Best done continuously (like testing) as part of the process
– Hard to do well late in a project

• Refactor when you identify an area of your system that:

– isn't well designed

– isn't thoroughly tested, but seems to work so far

– needs new features to be added

‘Bad smells’: signs you should refactor

• Duplicated code; dead code

• Large loop, method, class, parameter list
• Module has too little cohesion
• Modules have too much coupling
• Module has poor encapsulation
• A "middle man" object doesn't do much
• A “weak subclass” doesn’t use inherited functionality
• Design is unnecessarily general or too specific
• Poor abstraction
Low-level refactoring
• Names:
– Renaming (methods, variables)
– Naming (extracting) “magic” constants
• Procedures:
– Extracting code into a method
– Extracting common functionality (including duplicate code) into a
module/method/etc.
– Inlining a method/procedure
– Changing method signatures
• Reordering:
– Splitting one method into several to improve cohesion and readability (by
reducing its size)
– Putting statements that semantically belong together near each other
• See also http://www.refactoring.org/catalog/
IDEs support low-level refactoring

• Eclipse/Visual Studio support:

– variable / method / class renaming
– method or constant extraction
– extraction of redundant code snippets
– method signature change
– extraction of an interface from a type
– method inlining
– providing warnings about method invocations
with inconsistent parameters
– help with self-documenting code through
auto-completion
Higher-level refactoring

• Deep implementation and design changes

– Refactoring to design patterns
– Exchanging language idioms with safer alternatives
– Performance optimisation
– Clarifying a statement that has evolved over time or is unclear

• Compared to low-level refactoring, high-level refactoring is:

– Not as well-supported by tools
– Much more important!
Test first development
XP Testing Features

• Test-first development

• Incremental test development from scenarios

• User involvement in test development and validation

– Acceptance testing

• Automated test harnesses/scaffolding are used to run all

component tests each time that a new release is built
XP – Test-first Development

• XP uses test-first development as a key practice

– tests are developed prior to coding rather than after it.

• Tests are automated, and development cannot proceed until all

tests have been successfully executed.
• Tests are written as programs rather than data
– can be executed automatically. The test includes a check that it has executed
correctly.
– Usually relies on a testing framework such as JUnit.

• All previous and new tests are run automatically when new
functionality is added
– ensuring that new functionality has not introduced errors (regression test)
Example

• Each task generates one or more unit tests that check the
implementation described in that task.
Test-first Development: Benefits

• Helps clarify the requirements to be implemented.

• Helps simplify code. Code is only written in response to the

requirements of the tests.

• Provides immediate feedback on work done.

• Produces code with less bugs.

• Avoids test lag

– i.e. tests being done so long after coding that the tests are irrelevant.
Test-first Development: Drawbacks

• Programmers prefer programming to testing

– sometimes they take short cuts when writing tests.
– you should overcome!

• Some tests can be very difficult to write

• It is difficult to judge the completeness of a set of tests.

– Although you may have a lot of system tests, a test set may not provide
complete coverage.

• Changes to the design require changes to relevant tests, which

can be time-consuming.
Pair programming
XP – Pair Programming

• In pair programming, programmers sit together at the

same computer to develop the software.

• Pairs are created dynamically so that all team

members work with each other during the
development process.

• Evidence suggests that

– a pair working together is more efficient than two
programmers working individually in some cases (e.g. a
senior and a junior programmer)
– but not in others (e.g. two senior programmers)
XP – Pair Programming

• Benefits
– Supports the idea of collective
ownership and responsibility
– Avoids knowledge silos
– Reduce the overall risks to a project
when team members leave
– Acts as an informal review process.
– Encourages refactoring
– Fosters peer learning
– Encourages communication between
team members. Assists team
bonding.
• Drawbacks
• the model of operating may not
suit non-vocal individuals.
• It costs more man-hours to produce
the same features. Balance must be
maintained between quality of code
and increased coding cost.
• "watch the master"
Agile project management
Agile Planning

• Agile methods of software development are iterative approaches

– the software is developed and delivered to customers in increments.

• The functionality of these increments is not entirely planned in

advance, but is decided during development.
– The decision on what to include in an increment depends on progress and
on customer priorities.

• Customer priorities and requirements change so it makes sense

to have a flexible plan that can accommodate these changes.
Agile Planning

• Agile methods have a two-stage approach to planning:

– Release planning: looks ahead for several months and decides on the features
that should be included in a release of a system.
– Iteration planning: has a shorter term outlook (2-3 weeks), and focuses on
planning only the next increment of a system.

• Each agile method has its own unique approach to planning:

– Scrum – project backlogs, daily reviews and sprints.
– Extreme Programming – The Planning Game
The Planning Game – Release Planning

• Release planning involves selecting and refining

– the stories that will reflect the features to be implemented in a release of a
system
– the order in which the stories should be implemented.

• Release planning has three phases:

– Exploration Phase: Customer provides a shortlist of high-value requirements
for the system in user story format.
– Commitment Phase: Customer and developers commit to the functionality to
be included in the next release and the release date.
– Steering Phase: The plan can be adjusted, new requirements can be added
and/or existing requirements can be changed or removed.
The Planning Game – Iteration Planning

• A release is broken down into iterations.

• Stories to be implemented in each iteration are chosen, with the

number of stories reflecting the time to deliver an iteration (usually
2-3 weeks).

• Iteration planning is also broken down into three key phases:

– Exploration Phase: User stories are broken down into tasks. Tasks are
recorded on task cards.
– Commitment Phase: Programmers choose tasks to implement. The time it
takes to complete tasks is estimated.
– Steering Phase: Tasks are carried out in pairs. Tests are run (e.g. TDD).
The Planning Game – Scheduling –
Estimation
• Developers use relative estimation to assign a story point value to
a story dependent on story size.

Task C Task D

Task G Task F Task E Task A Task B

Story Points
2 3 5 8 13 21 34 55

• Note the use of the Fibonacci series for the scale.

The Planning Game – Scheduling –
Estimation
• Customers then rank the stories in terms of the value they deliver.

Task C Task A

Task D Task G Task F Task B Task E

Value Points
2 3 5 8 13 21 34 55
The Planning Game – Scheduling –
Estimation
• The bang for the buck (BFTB) score is then calculated:
BFTB = value points/story points
• The BFTB score represents the most value attainable in
the shortest time.

Task E
Story points: 21
Value Points: 55
BFTB = 55/13 = 2.62
The Planning Game – Scheduling –
Estimation
• Stories are then ranked in terms of BFTB score (high to low)
– This gives an initial sequence in which tasks should be performed
• However, tasks will normally need to be reordered again to account
for dependencies.

Tas Story Value BFTB Tas Story Value BFTB

k P P k P P
C 3 13 4.33 C 3 13 4.33
E 21 55 2.62 G 5 13 2.6
G 5 13 2.6 E 21 55 2.62
A 34 55 1.68 A 34 55 1.68
F 13 21 1.61 F 13 21 1.61
B 55 34 0.62 B 55 34 0.62
D 55 3 0.05 D 55 3 0.05
Scheduling – Estimation – Velocity

• The initial velocity of a project is set at the number of story

points completed in iteration one.
– Based on the velocity, we can then calculate how long it will take to
complete each remaining story point, and to schedule tasks accordingly.

• To calculate how long a single story point takes to complete, we

divide the time taken to complete the iteration by the velocity:
– 50 hours / 55 = 0.9 hours

• At the end of every iteration, the velocity is recalculated and the

project schedule adjusted in response.
Practical Problems with Agile Methods

• Agile methods have proved to be successful for smaller projects

that can be developed by co-located teams.

• However, using agile methods for larger projects developed by

distributed teams has proved a greater challenge.

• Issues are:
– Contracts
– Software maintenance
– Team integrity
– Organisational culture
Wrap up
• Understand software development processes
– What are the stages I will go through?
– At each stage what I am goanna do?
– Keywords: requirements, UML, design, evaluation, testing
• Project management side of software engineering
– Project planning, risk management
– Quality control, configuration management

• Methodology, processes, techniques, tools

• Recall:
– Software engineering != programming
– Software engineering != Computer Science
– short-term overhead v.s. long-term benefits
Finally

• Do not forget the module evaluation survey, please!