Software Development Process
Models (II)
Agile Methodologies
Extreme Programming
Agile Methodologies
Agile methods are a family of software
development processes for teams facing
unpredictable or rapidly changing requirements.
Extreme Programming (XP)
Agile Modeling
Adaptive Software Development (ASD)
Crystal Clear and Other Crystal Methodologies
Dynamic Systems Development Method (DSDM)
Feature Driven Development
Lean software development
Agile Unified Process (AUP)
(For more detailed information, see The Agile Alliance).
Agile Methodologies (cont’d)
Reject the notion that we should design for future
change
don’t “borrow trouble”
Manifesto for Agile Software Development:
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”
Seductive, but
Beware: it is not yet widely accepted in industry, and its
own proponents admit that it is not always a good
choice
Agile Methodologies (cont’d)
Agile methods emphasize real-time
communication, preferably face-to-face, over
written documents.
Team: include all the people necessary to finish
software
programmers and their customers, testers, interaction
designers, technical writers, and managers.
Most agile methods share iterative development's
emphasis on building releasable software in short
time periods.
Agile methods differ from iterative methods
time period is measured in weeks rather than months
treat their time period as strict time box.
work is performed in a highly collaborative manner.
Agile or Plan driven?
Senior developers Junior developers
High requirements change Low requirements change
Small number of developers Large number of developers
Culture that thrives on chaos Culture that demands order
Agile home ground Plan-driven home ground
12 principles of Agile
1. "The highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter time scale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them
the environment and support they need, and trust them
to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-
face conversation.
12 principles of Agile
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – the art of maximizing the amount of work not
done – is essential.
11. The best architectures, requirements, and designs emerge
from self-organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly. "
Extreme Programming (XP)
The most popular agile software
development methodology.
Places a higher value on adaptability than
on predictability
as all the agile methodologies do
Target: Small to medium sized teams
(<10 members) building software with
vague or rapidly changing requirements
Risky projects with dynamic requirements are
good candidates for XP.
Small iterations -2 weeks
Feedback;customer involvement;schedule slips
Make each release work
Make the smallest initial release that works:
Establish credibility;results
Keep delivering working products
Maintain test; re-run test after every change
Keep Defect rate under control
Customer in team; continuously refining specs
Do the right product; address need changes
Make your own estimates, human interaction,
constant pace; collective work
XP Practices
The XP methodology has Beck emphasizes that you
12 practices. can’t pick and choose:
The Planning Game if you’re not doing them
Small releases all, you’re not doing XP
Metaphor
Simple Design
Testing
Refactoring
Pair programming
Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards
12 Practices of XP
Planning Game: Determine the next release’s
scope by working with customers
Customer: what is desirable
Programmer: what is possible -balancing
Small Releases: Put a system into production
quickly (release every 1-2 weeks)
Metaphor: Guide the development with a simple
story of how the system works
E.g. “Desktop” is a metaphor used in OS referring office
desktop
Simple Design
12 Practices of XP (cont’d)
Testing: tests are written first, by both
programmers and customer: unit tests,
acceptance tests
Tests are your goals to achieve
Implement test first requires through understanding of the
specification
Ambiguities and omissions are captured before implementation
Refactoring: Restructure the system without
changing its behavior
Simplicity: focus on current requirements and no more
Future may change
Maintain simplicity via frequent refactoring
Instead of upfront design; re-architect for simplicity
12 Practices of XP (cont’d)
Pair programming: 2 programmers at 1
machine write codes
Two programmer working side-by-side, on the
same computer, interchanging roles back and
forth. While one programmer actively implements,
the other observes and identify defects and also
thinks strategically about the direction of the code
Informal reviews
Collective ownership: Anyone in the team
can modify the code; Everyone is responsible
of every bit of code
12 Practices of XP (cont’d)
Continuous integration: Integrate and build the
system many times a day
Keep testing while integrating=always a working
product
40-hour a week: Work no more than 40 hours
per week
On-site customer: Have the customer on the
team to answer questions full-time
Resolve disputes; set short term priorities; decisions
Coding standards:
Improve communication by adopting coding
standards; collective ownership;maintanance
When not to try XP
XP is very appealing to many programmers – often because
they think can get away from heavy documentation
in fact the test-first practice creates a lot of documentation,
though in code form
Beck himself indicates that there are situations where XP is not
appropriate. These include:
When it is not supported by the company culture
e.g. belief in big specifications, or overtime seen as a proxy for
commitment to company
More than 10 or 20 programmers (now, he claims the opposite)
Project too big for regular complete integration
Where it inherently takes a long time to get feedback
Where you can’t realistically test
e.g. already in production using a $1,000,000 machine that is already
at full capacity
When the physical environment is wrong
Extreme Programming – 5 Values
Communication (with customer and within the team)
"XP programmers communicate with their customers and fellow
programmers. "
Simplicity: Keep design simple and clean
Feedback: Get feedback by testing the software starting on
day one
Courage: Deliver the system to the customers as early as
possible and implement changes as suggested. Feel
comfortable with refactoring or modifying or deciding to
throw code away
"With this foundation XP programmers are able to courageously
respond to changing requirements and technology. "
Respect: (the latest value) respect others and their work
E.g. never commit change that break compilation
Based on http://www.extremeprogramming.org
Comparison of activities
Time
Test
Implement
Design
Analyze
Waterfall Iterative XP
Other Software Process Models
Rational Unified Process
Rapid Application Development
Formal Systems Development
Reuse Based Development
Component Based Development
…
