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
…