Post on 01-Aug-2020
transcript
Agile Methodologies
and Extreme Programming
Mohsen Afsharchi
Evolution of Methodology
Lots of thought on this subject since groups started
building software
“Use of GOTO Considered Harmful” Communications of
the ACM, Dijkstra
By the 1990’s, we had arrived at the Waterfall
methodology
Also known as BDUF (Big Design Up Front)
Waterfall and Similar Methodologies
Characteristics of Waterfall Methodologies
Requirements are gathered up front
Business analysts
End users
Interested departments
Maybe a JAD (Joint Application Design session?)
Requirements lead to design
Design leads to implementation
Implementation leads to acceptance testing
It is deployed
Where Does Waterfall Work Well?
Organizations where requirements don’t change
Stable requirements leads to stable design…
Stable design leads to “no surprise” implementation
Etc.
Who has requirements like this?
NASA
. . .
Does this reflect your requirements?
What happens when requirements change?
Changing Requirements
The later in the development cycle that a requirement
changes, the bigger the impact on the scope of the change
Documented by Barry Boehm
Changes to well established code may have a ripple effect,
causing side effects in other code
How can you make coding changes with confidence?
The Evolution of Agility
Problem: much of the methodology work in software
engineering has been based on traditional engineering
Design
Implement
Deploy
Software is fundamentally different
In its very nature
The way that people want to design, use, and modify software
Problem: we’ve been trying to tell developers how to
successfully write software…maybe we should find out
how they work best
Agility
Lots of smart guys got together and re-thought how software is built
In the nick of time
Most software projects fail
The business risk of software development is far too high
It seems hard to predict what will cause one project to succeed and another fail
Observe successful projects and figure out what they did right
Observe unsuccessful projects and figure out what they did wrong
This led to the Agile Manifesto
The Agile Alliance
17 Really Smart Guys met in Snowbird, Utah in February
2001:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas
The agreed on a manifesto and supporting principles
The 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”.
The Agile Alliance
The Culmination of Current Thinking
The ideas in the Agile Manifesto didn’t just fall from the
sky
They had been percolating for several years in different
forms
The Agile Manifesto just documented what a lot of people
were already thinking
Principles of Agile Development
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile focuses on the delivery of software
Delivering software early and often allows for quick wins and early feedback about the requirements, the team, and the process
The emphasis is to deliver the most important parts first
If the project ends, there are still valuable artifacts
Development proceeds from most important to less important
Note that this may (and will!) change during the course of the project
Principles of Agile Development
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Most projects run 1 to 3 month cycles [Cockburn]
Within the cycle, work is done in short iterations
Iterations usually last from 2 to 4 weeks
The iteration is complete at the end of the iteration, at the
expense of moving requirements
XP iterations are 2 to 3 weeks
Users review progress throughout the process
Principles of Agile Development
Working software is the primary measure of
progress.
Code is the most important deliverable
Agile methodologies place a premium on getting
something up and running early and evolving it over time
Agile does not discard the need for design
documentation
Diagram to understand, then move to code
Documentation is secondary to working code
Principles of Agile Development
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
This works because of
Early and frequent delivery of running software
Use of iterative and timeboxing techniques
Continual attention to architecture
Willingness to update the design
If you can gracefully accommodate changing requirements
and your competition cannot, you win
Principles of Agile Development
Business people and developers must work
together daily throughout the project.
There is a strong correlation between links to users and
project success
The best links are through onsite business expertise and
daily discussion
The longer it takes to get information to and from the
developers, the more damage will occur in the project
Information flow is similar to convection currents
XP insists that business stakeholders are part of the
development team
Principles of Agile Development
Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
“It is better to have motivated, skilled people
communicating well and using no process at all than a
well-defined process used by unmotivated individuals.”
[Cockburn 2002]
“We hire good people, give them the tools and training to
get their work done, and get out of their way.” [Thomas]
Developers are the Key
You cannot overemphasize this point: developers, project
managers, and business analysts make or break the
project
"All other factors being equal, a 90th-percentile team of
analysts and programmers will be about four times as
productive as a 15th-percentile team.“ [Boehm 1981]
You should hire the smartest people you can find
Principles of Agile Development
The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
Communication is like air conditioning
Cockburn defines modalities of communications and their
effectiveness (Agile Software Development, 2002)
Cockburn’s Modalities and Effectiveness
Communication
Face to face communication about specific topics is most
efficient
Agile also takes advantage of “knowledge radiators”
Simple, low-tech information stores
Poster board with index cards or Post-it notes
Project status beside the coffee pot
Automated build report via web browser
Principles of Agile Development
The best architectures, requirements, and designs
emerge from self-organizing teams.
This means either that architectures, requirements, and
designs emerge
in small steps over time
as a logical consequence of human-centric rules the team uses
All 3 must be allowed to adjust over time
An architecture that grows in steps can follow the
changing knowledge of the team and the changing wishes
of the users
Principles of Agile Development
Continuous attention to technical excellence and
good design enhances agility.
The design must evolve
You must create good designs initially
You must review and improve designs regularly
Technical excellence applies to all aspects of the project
Build management
Coding standards
Collaboration documentation
Principles of Agile Development
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Social aspect
An alert, engaged staff is more effect than a tired, plodding staff
Long hours are a symptom that something has gone wrong
Only work 8 hours a day; never put in overtime 2 weeks in a
row
Technical aspect
Software development can be viewed as a long strategic game
Each move sets up the next move
Principles of Agile Development
Simplicity--the art of maximizing the amount of
work not done--is essential.
“This letter is longer than I wish, for I had not the time to
make it shorter” Blaise Pascal
It is sometimes more difficult to make things simpler
A cumbersome model is easier to produce than a simple
one
DRY principle (Don’t Repeat Yourself)
“Design for simplicity; add complexity only where you
must.” Art of Unix Programming, Raymond 2003
Principles of Agile Development
At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
Constant awareness is key
Never get lazy
XP encourages this every step of the way
Questions:
How light is too light?
How simple is too simple?
Can we make this simpler
Some Agile Methodologies
Extreme programming
Scrum
The Crystal Methodologies
Crystal Clear
Crystal Orange
Crystal Orange Web
What Spawned Extreme Programming?
In the early 1990s, Kent Beck was thinking about better ways to develop software.
He and Ward Cunningham had experienced an approach to software development that made every thing seem simple and more efficient.
Kent contemplated on
What made software simple to create
What made it difficult
In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development -- the result was the Extreme Programming (XP) methodology.
The 4 XP Dimensions
What Kent came to realize is that there are four
dimensions along which one can improve any software
project.
You need to improve communication.
You need to seek simplicity.
You need to get feedback on how well you are doing.
And you need to always proceed with courage.
Communication, Simplicity, Feedback, and Courage are
the four values sought out by XP programmers.
XP: Rules and Practices
Planning
User stories are written.
Release planning creates the schedule.
Make frequent small releases.
The Project Velocity is measured.
The project is divided into iterations.
Iteration planning starts each iteration.
Move people around.
A stand-up meeting starts each day.
Fix XP when it breaks.
XP: Rules and Practices
Design
Simplicity.
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.
XP: Rules and Practices
Coding
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Use collective code ownership.
Leave optimization till last.
No overtime.
XP: Rules and Practices
Testing
All code must have unit tests.
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.
A Tour Through XP: The Project
A Tour Through XP: Iteration
A Tour Through XP: Development
A Tour Through XP: Collective Code
Ownership
Feedback Loops
Recall the 4 dimensions of XP
You need to improve communication.
You need to seek simplicity.
You need to get feedback on how well you are doing.
And you need to always proceed with courage.
The goal: a less extreme (pragmatic?) version of XP
First pass: let’s get rid of the stuff that scares the boss and
just do the rest
Why You can’t Pick and Choose Your
Practices
XP isn’t just a group of fun activities that fit together
because Kent Beck says they do
XP is carefully calibrated for feedback
Remember the diagrams for XP?
Feedback Loops in XP
XP relies on
feedback to
work
Feedback loops
relate to time
scales
The tighter the
time scale, the
more
immediate the
feedback
Creating a Kinder, Gentler XP
If you want to only do some of the XP practices, you have
to replace the current XP activity with something that
gives you the approximate same level of feedback
That’s the only way you get the benefits from XP
You cannot randomly pick and choose what practices you
want to use!
XP becomes worse than many other methodologies because
you’ve destroyed one of the dimensions
You are sure to fail with XP
You’ll unfairly talk badly about XP to others
Substituting Practices: Planning
The Planning Practices
User stories are written.
Release planning creates the schedule.
Make frequent small releases.
The Project Velocity is measured.
The project is divided into iterations.
Iteration planning starts each iteration.
Move people around.
A stand-up meeting starts each day.
Fix XP when it breaks.
User Stories
User stories are written.
User stories
Used to create the time estimates for release planning and
acceptance testing
Written by the customers as things the system needs to do for
them
Similar to usage scenarios but not limited to describing a user
interface
In the format of about 3 sentences of text written by the
customer in the customer’s terminology without techno-speak
Differ from traditional requirements in the level of detail
User Story Substitutions
Traditional requirements gathering tools
Must be very flexible
Must be granular
CaliberRM is an outstanding choice for this
Especially for companies that require traceability for
requirements
Easy to modify requirements
Easy to attach custom fields to requirements records
Requirements should be as narrative as possible, not just
a dry list of facts
The narrative conveys not just functionality but also workflow
User Story Substitutions
Requirements must be flexible
User stories have lower detail than traditional
requirements
The developers and customer create detailed requirements
face to face when it comes time to implement the feature
Requirements and dependencies must be fluid
Neither user stories or requirements should ever delve
into technical details
Release Planning
Release planning creates the schedule
A release plan meeting is used to create a release plan,
which lays out the overall project
The release plan is used to create iteration plans for each
individual iteration
Decisions
Technical decisions made by technical people
Business decisions made by business people
The development team estimates each user story in
terms of ideal programming weeks
Release Planning
Do not change the estimates for user stories if
management is displeased with the amount of time it
takes
A project may be quantified by 4 variables
Scope - how much is to be done
Resources - how many people are available
Time - when the project or release will be done
Quality - how good the software will be and how well tested
Management may choose 3 of the 4 values
Development gets the remaining variable
Lowering quality may have later project impact
Release Planning Substitutions
The goal is to achieve consensus between developers,
management, and business people
Don’t stop until everyone is happy (or at least equally
unhappy)
XP release planning makes the business stakeholders a
integral part -- don’t allow the substitution to leave them
out
You must have business stakeholders to make it work
You wouldn’t change your accounting practices without
someone from accounting there, would you?
Small Releases
Make frequent small releases to customers (or customer
proxies)
These are releases, not “90% done”
This is a critical feedback loop
You need customer feedback to feed the remainder of the
development cycle
The longer you wait to introduce an important feature, the less
time you will have to fix it
Small releases tend to focus developer productivity
Forces the development team to solve tough problems
rather than delay them
Small Release Substitutions
This one is hard to substitute
This is the feedback loop between the customer (i.e., consumers of the application) and the developers
You can simulate this by creating small releases within your department
You’ve got to be diligent
If you start slipping into the “90% done” mode, you’re sunk
Try hard to get User Acceptance Testing into this small release cycle if you can
“Quick releases:
Help find bugs faster
Let’s the users get to play with it faster”
Project Velocity
The Project Velocity is measured
This is the measure of how fast work is getting done on
your project
Count how many user stories (or programming tasks) were
completed during the iteration
Total up the estimates that these stories received
This helps future estimations during the next Iteration
Planning Meeting
During the Iteration Planning Meeting, developers sign up
for the same number of programming tasks equal to the
project velocity measured in the previous meeting
Project Velocity
This mechanism allows developers to recover and clean-
up after a difficult iteration
Don’t divide the velocity by the number of developers in
the iteration
Doesn’t help determining the overall velocity
Can’t compare it to other projects
Discourages team building
Project velocity will rise and fall during the project, which
is normal
Re-estimate if you see dramatic changes
Project Velocity Substitutions
It’s OK to use other metrics for this as long as
They are reasonable, accurate metrics1
They are team based, not individual based
They provide real value
They are simple enough to understand
In general, don’t try to measure this with Microsoft
Project
Perhaps the most misused piece of software ever written
People use it to create meaningless charts and statistics
Testing is important in XP, including Meta-testing of the
methodology as it proceeds
1 There are very, very few of these -- see Brian Sletten’s Applied Object-oriented Metrics or
David Bock’s Software Metrics and the Great Pyramid of Giza
Iterations
The project is divided into iterations
Divide the development schedule into about a dozen
iterations, each lasting 1 to 3 weeks
Don’t schedule tasks in advance
Schedule tasks in the Iteration Planning Meeting
It is against the rules to look ahead and try to implement
anything not scheduled in this iteration
YAGNI - You Ain’t Gonna Need It
There is plenty of time later to respond to changing
requirements
Iteration Substitutions
Iterative development is hard to substitute
Tight iterations provides valuable feedback
Keep development team focused
Keep iterations short and cohesive
Keep tasks very small and cohesive
Avoid the temptation of gold plating
Avoid “Big Bang” deployments
Even if you must deploy that way in your organization, do
internal “Little Bang” deployments
Deploy often to User Acceptance Testing
“Faster feedback on bugs and problems”
Iteration Planning
Iteration planning starts each iteration
A meeting is called at the first of every iteration
Development work is selected
User stories are chosen by the customer
From the release plan
Most important first
Failed acceptance tests
Development work is translated onto index cards
Each task should be 1 to 3 Ideal programming days
Developers sign up for tasks then estimate how long it will
take
Iteration Planning
The Project Velocity is used to determine if the iteration
is overbooked
Don’t be tempted to change your task and story
estimates
The planning process relies on the cold reality of consistent
estimates
Fudging them to be lower means you are lying to yourself
It is normal to re-estimate stories and release plan every
3 to 5 iterations
Always implement the most valuable stories first
Iteration Planning Substitutions
You can change this phase with a similar planning session
It should be tied to iterations
Long-term estimates must be fluid
It is important for developers to create their own
estimates
Gets developer buy-in
Their estimation skill gets better over time
“We’re getting developers more interested in the project
management side and honing their estimation skills”
Move People Around
Move people around
Change developer assignments weekly, daily, or hourly
Prevents serious knowledge loss and bottle necks
Spreads overall knowledge around
May be as simple as encouraging everyone to try working
on a different section of the system at least part of each
iteration
Pair programming eliminates transition time
Move one of a pair at a time
Play “Musical Chairs” after lunch every day
Move People Around Substitutions
Harder if you don’t pair program
The feedback goal here is to spread understanding
around the project
You can do this with regular code reviews
Much less effective than pair programming
Better than nothing
This helps avoid the Truck Number anti-pattern
Explain Truck Number
Call this “cross training”
Stand-up Meeting
A stand-up meeting starts each day
Every day starts with the entire development team
standing in a circle to communicate
Problems
Solutions
Impediments
To improve team focus
It is more efficient to have one short meeting with
everyone than a lot of little meetings
Cross-team communication is the primary purpose
Stand-up Meeting Substitutions
This is part of the daily feedback loop
Substitute with something that provides daily updates,
problems encountered and solved, etc.
You can set up
A Wiki to share information
Information Radiators
However, this isn’t as rich a communications channel
Cockburn defines modalities of communications and their
effectiveness (Agile Software Development, 2002)
Cockburn’s Modalities and Effectiveness
Fix XP
Fix XP when it breaks
Fix the process when it breaks
You should be willing to do this with any methodology
Don’t buy into strictly prescriptive solutions
Build Your Own Tools
At ThoughtWorks, most of the Project Managers create
their own tools for tracking projects
Mostly created around Excel
It is important to evolve your approach over time
It changes from project to project
You get better and better at it
By the way - it's really, really important that PMs (especially client PMs) build their own tracking sheet. Taking someone else’s and mushing it around to make it work for the next project doesn't work. It's a psychology thing about owning the thing you built - and it's really important that PMs own their tracking tools.
Roger Marlow, PM, ThoughtWorks
Substituting Practices: Designing
The Designing Practices
Simplicity.
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.
Simplicity
Simplicity
A simple design takes less time than a complex one
When you find something complex, replace it with
something simple
Keep things as simple as possible as long as possible by
never adding functionality before it is scheduled
Keeping a design simple is hard work
“The present letter is a very long one, simply because I had no leisure to make it shorter. “
Blaise Pascal
Simplicity Substitutions
There is no substitute!
Follow
The Pragmatic Programmer rules
The Art of Unix Programming
2. Rule of Clarity - Clarity is better than cleverness.
5. Rule of Simplicity - Design for simplicity; add complexity only where
you must
6. Rule of Parsimony- Write a big program only when it is clear by
demonstration that nothing else will do.
13. Rule of Economy - Programmer time is expensive; conserve it in
preference to machine time.
14. Rule of Generation -Avoid hand-hacking; write programs to write
programs when you can.
System Metaphor
Choose a system metaphor
Keeps the team on the same page by naming classes and
methods consistently
Good names =>
Understanding the overall design of the system
Code reuse
Stick as close to the problem domain as possible
System Metaphor Substitutions
Take the time to do this no matter what your
methodology
Makes everything in the project make sense because it
provides context
“We’re trying to create a way that we can describe this to
the business side to get their buy-in”
CRC Cards
Use CRC (Class, Responsibility, and Collaboration) cards
for design sessions
Allows people to break away from procedural thought
and more fully appreciate object technology
Individual CRC Cards represent objects
CRC Cards
A CRC session proceeds with someone simulating the
system by talking about which objects send messages to
other objects
By stepping through the process weaknesses and
problems are easily uncovered
Design alternatives can be explored quickly by simulating
the design being proposed
CRC Card Substitutions
This is one of the easier characteristics to change
Make sure that you find a design technique that is
Very flexible
Interactive
Involves the entire development team
Serves the needs of the stakeholders
Allows for “What if” games
Many organizations prefer more documentation CRC
cards
OK as long as you don’t get the cart before the horse
Don’t let a static medium discourage flexibility
Documentation
“We have to have documentation so that…
We can re-create it?
We can kill more trees?
We know what it does?”
The tests are better documentation than any outdated Word document
You have to keep them updated if the requirements change
You can verify the requirements (tests) anytime
You know what it does by the tests
If he has to have documentation…
Make it a task within the iteration
Spread it around
Try to apply the DRY principle to it as much as possible
Spikes
Create spike solutions to reduce risk
Proof of concept projects to reduce technical risk
Ignores all outside concerns
Expect to throw it away (this is not a prototype!)
This is common in most methodologies
Avoid the temptation to just build up from the spike
YAGNI
No functionality is added early
One of the hardest things for developers to not do!
We are all tempted to add functionality now that we are
just sure is going to be needed later
Extra functionality always slows us down and squanders
resources
No Functionality Added Early Substitutions
Don’t!
You start creeping towards Big Design Up Front
Focus on the task at hand
Refactor
Refactor whenever and wherever possible
You must be willing to change code anytime it should be
changed
Don’t’ live with broken windows
Too much software becomes brittle because of 100’s of
tiny compromises
You must be willing to refactor
Substituting Practices: Coding
The Coding Practices
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Use collective code ownership.
Leave optimization till last.
No overtime.
Customers
The customer is always available
Business stakeholder must be available
If you can’t get a business person, get a worthy substitute
One of the few hard requirements of XP
“We have to know what to build…
Requirements documents are out of date as soon as they are
written
Getting this right is important to the business
We want to be able to respond quickly to changing
requirements
Developers != business people”
Standards
Code must be written to agreed standards
Almost every methodology does this
Don’t try to substitute this!
Test-first Coding
Code the unit test first
Creating a unit test helps a developer to really consider
what needs to be done
Requirements are nailed down firmly by tests
There can be no misunderstanding a specification written
in the form of executable code
Test-first Coding Substitutions
Test-first coding is the most effective way to write code
You get nearly as good feedback if you make sure you write tests concurrently
They must be written right away
Planning to write them next week doesn’t count!
You can delay testing your code slightly, but you must write tests!
Tests are the only way you can write code with confidence
“This is the set of requirements”
“Here is a coverage test that shows how much of our code is verified.”
Pair Programming
All code is pair programmed
The most Extreme practice in XP!
Two people working at the same computer will add as
much functionality (or more) than 2 people working
separately except that it will be much higher in quality
Pair programming increases software quality without
impacting time to deliver
Works best with 2 developers of more or less equal skill
Get Comfortable
Pair programming feels awkward at first
It helps if you are set up for it
Pair Programming at ThoughtWorks
Pair Programming Substitutions
Tough because this represents the most immediate code
feedback loop, on the order of minutes
You can achieve the (greatly diminished) similar effect
with very frequent code reviews
Very frequent means daily or at least once weekly
Think about how much code is written before it is peer
reviewed
Still pair on particularly complex parts (to help figure out
how to make it simpler)
Try it, with useful metrics, to help convince your boss
Pair Programming -- Politically
“You’re going to do what!?!”
You must show quantifiable results
Try keeping useful metrics before and after
Don’t make it about silly things like lines of code
Use bug counts
Use passed tests
If you already support code reviews in your
organization, this is really just real-time code reviews
Start doing it without telling anyone on really
complex parts
Integration
Only one pair integrates code at a time
Designed to cut down on regression test failures that
cascade
This is do if you have effective source code control in
place
This assume a canonical source for your code
Strongly consider continuous integration to automate
testing
Integrate Often
Integrate often
Developers should be integrating and releasing code into
the code repository every few hours, whenever possible
Always work in the context of the latest code
There is a direct correlation to this feedback loop and its
benefit which has nothing to do with XP
Collective Code Ownership
Use collective code ownership
Any developer can change any line of code to
Add functionality
Fix bugs
Refactor
There is no one person (not even an architect) who has
the entire vision
The code base is continually changing
Unit tests and frequent integration preserve order
Collective Code Ownership Substitutions
Hard!
You should try to adopt this attitude no matter what
your methodology
This is a meta-feedback loop -- it enables the others to
work
This is one of the enabling characteristics for real
teamwork
Optimization
Leave optimization until last
Do not optimize until the end
Never try to guess what the system's bottle neck will be
Measure it!
Make it work, make it right, then make it fast
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Donald Knuth
Overtime
No overtime
Working overtime sucks the spirit and motivation out of
a team
Projects that require overtime to be finished on time will
be late no matter what you do
Hard to substitute this because its worth is self evident
Make a rule that you never work overtime 2 weeks in a
row
Prevents the (very real) danger of complete burnout
“Our developers start writing code that causes a lot of
test failures after 12 hour days!”
Substituting Practices: Testing
The Testing Practices
All code must have unit tests.
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.
Testing: Unit Tests
All code must have unit tests
One of the cornerstones of XP (and modern
development practices)
Compilers only tell you if the spelling is right
Tests tell you if it does what you think it does
Don’t substitute for this, incorporate it
Unit Tests
All code must pass all unit tests before it can be released
to version control
Unit tests are both feedback and meta-feedback
A strong suite of unit tests enables refactoring, collective
code ownership, etc.
Don’t substitute or slack on this one either
Be careful about getting behind on tests (you’ll never
catch up)
Won’t happen if you do Test-first development
Don’t substitute, incorporate
Bugs and Tests
When a bug is found tests are created
If you are testing anyway, you should create a test every
time you find a new bug
Prevents that bug from ever reoccurring
Don’t substitute, incorporate
Acceptance Tests
Acceptance tests are run often and the scores are
published
Created from user stories
Another important part of testing
Provides confidence that you are creating the right thing
The highest scope feedback loop, from Create User
Stories all the way to final coding
You must have some criteria to determine when you are
done
Requirements => Acceptance tests
Organization Roles in XP Projects
Project Manager Planning
Project Velocity
Cat herding
Business Analyst/Stakeholder Knows why the application is being written
Developer
Tester
Architect Doesn’t remove the need for Enterprise Architecture
Application Architects act as on-going policeman for the overall structure of the code
May be overridden at any time by developers
Substitution Scale User Stories, Release Planning, Fix XP, CRC Cards,
Spike Solutions
Easy
Small Releases, Project Velocity, Iteration Planning,
Move People Around, Stand-up Meeting, Coding
Standards, Pair Programming, No overtime
Intermediate
Iterations, Simplicity, System Metaphor, Early
Functionality, Test-first Coding, Integrate Often,
Collective Code Ownership, Optimize last, Acceptance
tests are run often
Hard
Refactor, Customer is Always Available, All code must
have unit tests, All code must pass unit tests, Create
tests when a bug is found
No
Substitute
What to Tell
You are never going to convince him with just arguments
Too much of XP is counter-intuitive
He thinks you are trying to pull a fast one
Demonstrate that this works
Create a pilot project
Pick a small-scoped, orthogonal project
Pick a team that can work together
Rock and roll!
Use useful metrics
Number of tests passed (should be higher)
Number of bugs (should be lower)
Extrapolate
When All Else Fails…
Trade this guy for that guy