Transcript Essence of Extreme Programming

Agile Software Development:
Practices through Values
C Sc 335
Rick Mercer
Goal and Outline
Main Goal:
– Suggest practices, values, and some process for
completing a final project on time that is better than
any one could do it in in four times the time.
Outline
– Distinguish Waterfall (plan driven) from Agile
– 11 Practices of quality software development
– Four values of Extreme Programming (XP)
2
Waterfall Model
Waterfall was described by 1970
Understood as
– finish each phase
– don’t proceed
till done
W. W. Royce
criticized this
– proposed an
iterative approach
3
Became Popular
Management liked phases to easily set deadlines
Customers provide all requirements
Analysts translate requirements into specification
Coders implement the specification
Reviews ensure the specification is met
Testing is performed by others (QA)
Maintenance means modifying as little as possible
– old code is good code
Change is hard (and costly)
4
Sprial
Dr Barry Boehm proposed a spiral approach
5
Waterfall
It became popular
– This process is still is used a lot
Craig Larman's book [1] provides proof that waterfall is
a terrible way to develop software
– In his study, 87% of all projects failed
– The waterfall process was the "single largest contributing
factor for failure, being cited in 81% of the projects as the
number one problem."
[1] Agile and Iterative Development:
a Manager's Guide, Addison-Wesley Professional, 2003
6
Extreme Programming (XP)
As of 2009, about 14 years of growth
– About 25% of new project are Agile
Set of SE practices that produce high-quality
software with limited effort
Many books, first by Kent Beck:
Extreme Programming–Embrace Change,
Addison-Wesley, 2000,
ISBN 0-201-61641-6
http://www.extremeprogramming.org/
7
Extreme Programming
XP is
– a disciplined approach to software development
– code centric: no reckless coding, test-first
– successful because it emphasizes customer
involvement and promotes team work
– not a solution looking for a problem
– One of several "agile" (can adapt to change)
software development processes
http://www.agilealliance.org/
8
Essence of XP
Four variables in software development:
– Cost, Time, Quality, Scope (# features)
Four Values
– Communication, Simplicity, Feedback, Courage
Five Principles
– Provide feedback, assume simplicity, make incremental
changes, embrace change, quality work
Practices (or fewer, or more, or subject to change)
– Planning game, small releases, simple designs, automated testing,
continuous integration, refactoring, pair programming, collective
ownership, Continuous Integration, on-site customer, coding standard
9
Cost of change
Waterfall
Cost
of
change
XP
time10
Cost of the Project
Paraphrasing two companies from Agile
When we bid projects, we charge $X for doing it
Waterfall and $X/2 for doing it Agile
11
Goal and Outline
Main Goal:
– Suggest practices, values, and some process for completing
a final project on time that is better than any one could do it in
in four times the time.
Outline
– Distinguish Waterfall (plan driven) from Agile
– 11 Practices of quality software development to use on your
final project
– Four values of Extreme Programming (XP)
12
Practices: Planning Game
The planning game involves story cards, which
are short descriptions of a feature
– Provide value to customer
– Independent of each other
– Testable
Customer write stories cards and prioritize them
Developers estimate how long a story takes
13
Practices: The planning game
Business decisions (customer)
– Scope: which “stories” should be developed
– Priority of stories (features)
– Release dates
Technical decisions (developers)
–
–
–
–
Time estimates for features/stories
Elaborate consequences of business decisions
Team organization and process
Scheduling
14
Practices: Estimation
Based on similar stories from the past
Team effort
We get good at estimation simply by just doing it
Ideal Engineering Time (IET)
– could be points
Velocity = IET/Calendar Time
– we can do 20 points each week
– "Customer, which 20 points do you want next week?"
15
Practices: Small Releases
Releases should be as small as possible
Should make sense as a whole
Put system into production ASAP
– Fast feedback
Deliver valuable features first
Short cycle time
– Planning 1-2 months rather than 6-12 months
– Or in our case, 2.5 weeks rather than 5 weeks
16
Practices: Simple design
The “right” design
–
–
–
–
–
Runs all tests
No code duplication, No code duplication
Fewest possible classes
Short methods
Fulfills all current business requirements
Design for today not the future
– But design so the system can change
17
Practices: Testing
Software should be tested, but it is often spotty
or overlooked
Automatic testing (JUnit, for example) help us
know that a feature works and it will work after
refactoring, additional code, and other changes
Provides confidence in the program
18
Testing
Write tests at the same time as production code
– Unit tests  developer
– Feature/acceptance tests  customer
Don't need a test for every method
Testing can be used to drive development and
design of code
Allows for regression testing
– Do changes break previously working code
19
SIM/SQS
http://www.simgroup.com/Consultancy/regression.html
Regression Testing
– re-testing of a previously tested program following
modification to ensure that faults have not been
introduced or uncovered as a result of changes.
– Regression tests are designed for repeatability, and are
often used when testing a second or later version of the
system under test.
– Regression testing can be carried out on all applications,
including e-Commerce and web-based systems
.
20
Testing
Strong emphasis on regression testing
– Unit tests need to execute all the time
Unit tests pass 100%
Acceptance tests (we haven't seen these) show
progress on which user stories are working
Other testing frameworks include
– JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit
21
Can't unit test always
Won’t have unit tests for
– GUIS: There are testing frameworks to simulate and
test user interaction, but not this course
– Network, use visual inspection while running
– Randomness: Some strategies might have some
randomness, which can be hard to work with
22
Practices: Refactoring
Restructure code without changing the
functionality
Goal: Keep design simple
– Change bad design when you find it
– Remove dead code
Examples at Martin Fowler's Web site:
http://www.refactoring.com/ see online catalog
23
Practices: Pair programming
Write production code with 2 people on one machine
– Person 1: Implements the method
– Person 2: Thinks strategically about potential improvements,
test cases, issues
Pairs change all the time. Has advantages such as
–
–
–
–
No single expert on any part of the system
Continuous code reviews, fewer defects
Cheaper in the long run, and more fun
Can you form a team of 4 and have everyone see all code?
Problems:
– Not all people like it
– Pairs need to be able to work together
24
Practices: Collective ownership
All code can be changed by anybody on the team
Everybody is required to improve any portion of
bad code s/he sees
Everyone has responsibility for the system
Individual code ownership tends to create
experts
25
Practices: Continuous integration
Integration happens after a few hours of development
Checkout build with your changes, Make sure all tests
pass (green bar)
In case of errors:
– Do not put changes into the build
– Fix problems
Checkin the system to the common repository
Repeat
We will use CVS to store your code
26
Continuous Integration
Find problems early
Can see if a change breaks the system more
quickly -- while you remember the details
Small increments
27
Practices: Coding standards
Coding Standard
– Naming conventions and style
– Least amount of work possible: Code should exist
once and only once
Team has to adopt a coding standard
– Makes it easier to understand other people’s code
– Avoids code changes because of syntactic
preferences
28
Practices: On-site customer
Many software projects fail because they do not
deliver software that meets business needs
Real customer has to be part of the team
– Defines business needs
– Answers questions and resolves issues
– Prioritizes features
29
Outline
Main Goal:
– Suggest practices, values, and some process for completing
a final project on time that is better than any one could do it in
in four times the time.
Outline
– Distinguish Waterfall (plan driven) from Agile
– 11 Practices of quality software development to use
on your final project
– Four values of Extreme Programming (XP)
– Process considerations adapted from Scrum
30
Values: Communication
Communication
– Customer centric (write "Stories")
– Pair programming
– Task estimation
– Iteration planning
• What to do in the next time period
• May be weekly goals
– Design sessions
31
Values: Simplicity
Simplicity
– Choose the simplest thing that will work
– Choose the simplest design, technology,
algorithm, technique
32
Values: Feedback
Feedback
very important
– Small Iterations
– Frequent deliveries
– Pair programming
– Constant code review
– Continuous integration (add often to the build)
– automated unit tests (JUnit, for example)
33
Values: Feedback
Compiler feedback: seconds
Pair programming feedback: half minutes
Unit test feedback: few minutes
Acceptance testing: half hours
– Customers write these, no can do in 335
Customer feedback: daily (or several times/week
in our case)
Iteration feedback: weekly
34
FeedBack?
Manifesto for Agile Software Development
Agile Manifesto
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
That is, while there is value in the items on
the right, we value the items on the left more.
35
Outline
Main Goal:
– Suggest practices, values, and some process for completing
a final project on time that is better than any one could do it in
in four times the time.
Outline
– Distinguish Waterfall (plan driven) from Agile
– 11 Practices of quality software development to use
on your final project
– Four values of Extreme Programming (XP)
36
335 Final Project
SLs and Rick are the customers
– Projects still TBD
– Hope to have specs by Tuesday 27-Oct
– Will choose teams/projects next Thursday 29-Oct
As customers, we reserve the right to change
requirements :-)
37