L03-04 Agile Software Development
L03-04 Agile Software Development
Agile methods
Agile development techniques
Agile project management
Scaling agile methods
1
Rapid software development
2
1
What is “Agility”?
Yielding …
Rapid, incremental delivery of software
3
2
Why Agile?
4
Agility and the Cost of Change
5
Agile manifesto 2001
6
5
Agile Principles
7
6
Agile development
8
Plan-driven and agile development
Plan-driven development
A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
Not necessarily waterfall model – plan-driven, incremental
development is possible
Iteration occurs within activities.
Agile development
Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.
9
Plan-driven and agile development
10
9
Agile methods
11
10
Agile methods
12
The principles of agile methods
Principle Description
Customer Customers should be closely involved throughout the
involvement 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.
13
Agile method applicability
14
13
Agile Development
15
14
16
Extreme programming
17
Extreme Programming Planning
18
17
19
18
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.
20
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.
21
XP and agile principles
22
21
Influential XP practices
23
22
24
A ‘prescribing medication’ story
25
Examples of task cards for prescribing medication
26
25
Refactoring
27
26
Refactoring
28
Examples of refactoring
29
Test-first development
30
29
Test-driven development
31
30
Customer involvement
32
Test case description for dose checking
33
Test automation
34
33
35
34
Pair programming
36
Pair programming
37
Dr. Noha Adly CSE 322 - Agile Software Development 38
38
37
39
38
40
Scrum
41
The Scrum process
42
41
Potentially The software increment that is delivered from a sprint. The idea is
shippable product that this should be ‘potentially shippable’; that it is in a finished state
increment and no further work, such as testing, is needed to incorporate it into
the final product. In practice, this is not always achievable.
Product backlog This is a list of ‘to do’ items which the Scrum team must tackle.
They may be feature definitions for the software, software
requirements, user stories or descriptions of supplementary tasks
that are needed, e.g. architecture definition or user documentation.
Product owner An individual (or possibly a small group) whose job is to identify
product features or requirements, prioritize these for development
and continuously review the product backlog to ensure that the
project continues to meet critical business needs. The Product
Owner can be a customer but might also be a product manager in a
software company or other stakeholder representative.
Dr. Noha Adly CSE 322 - Agile Software Development 43
43
42
44
The Scrum sprint cycle
At the end of the sprint, the work done is reviewed and presented to
stakeholders. The next sprint cycle then begins.
Dr. Noha Adly CSE 322 - Agile Software Development 45
45
Scrum sprint cycle
46
45
Scrum
47
46
Scrum Roles
48
Teamwork in Scrum
49
Scrum Artifacts and Rules
50
49
Scrum Events
51
50
Scrum benefits
52
Distributed Scrum
53
Scaling agile methods
54
53
55
54
56
Contractual issues
57
Agile methods and software maintenance
58
57
59
58
System issues
60
People and teams
61
Organizational issues
62
61
Principle Practice
Customer This depends on having a customer who is willing and able to spend time with
involvement the development team and who can represent all system stakeholders. Often,
customer representatives have other demands on their time and cannot play
a full part in the software development.
Where there are external stakeholders, such as regulators, it is difficult to
represent their views to the agile team.
Embrace change Prioritizing changes can be extremely difficult, especially in systems for which
there are many stakeholders. Typically, each stakeholder gives different
priorities to different changes.
Incremental delivery Rapid iterations and short-term planning for development does not always fit
in with the longer-term planning cycles of business planning and marketing.
Marketing managers may need to know what product features several months
in advance to prepare an effective marketing campaign.
Maintain simplicity Under pressure from delivery schedules, team members may not have time to
carry out desirable system simplifications - refactoring
People not process Individual team members may not have suitable personalities for the intense
involvement that is typical of agile methods, and therefore may not interact
well with other team members.
63
62
64
Factors affecting Agile methods for large systems
65
Factors affecting Agile methods for large systems
66
65
67
66
68
Multi-team Scrum – Key characteritics
Role replication
Each team has a Product Owner for their work component and
ScrumMaster.
Product architects
Each team chooses a product architect and these architects
collaborate to design and evolve the overall system architecture.
Release alignment
The dates of product releases from each team are aligned so
that a demonstrable and complete system is produced.
Scrum of Scrums
There is a daily Scrum of Scrums where representatives from
each team meet to discuss progress and plan work to be done.
69
Agile and plan-driven methods
70
69
Design Informal and iterative Formal and done up front, after all
requirements are known.
User involvement Crucial, frequent, throughout the whole Required only at the beginning
process (requirements solicitation and analysis) and
at the end (acceptance testing).
Communication Done informally, throughout the project. Relies mainly on documents and formal
memos and meetings
Process complexity Relatively low High. RUP (2002) describes more than 100
artifacts, 9 disciplines, 30 roles, and 4
phases.
Documentation Minimal, only what is necessary; relies on Requires heavy, formal documentation of
source code as the ultimate documentation. every phase of the project.
Overhead Low. Relatively high
71
70
Criticality Relatively low; not suitable for life- Can be used for mission-critical systems
critical systems without adaptation (maybe with minimal modifications).
People More suitable for team players, "good Defines many roles, which can be
citizens" who can do design and appropriate for most kinds of people;
programming adequately. Agile doesn't require tight team playing; almost
requires strict adherence to certain any personality will work, as long as the
practices. team member can follow rules.
Company Better suited for small co-located Better suited for larger companies with
culture companies with relaxed cultures. possibly geographically remote sites and
more formal cultures.
Stability Copes easily with changes in Less suited to cope with changes. Assumes
requirements or environment a relatively stable environment where
requirements don't change much. Can be
Dr. Noha Adly adapted.
CSE 322 - Agile Software Development 72
72