Transitioning to XPor

The Fanciful Opinions of Don Wells

XP Through the Ages

• The illusion of making promises to the customer and then keeping them

• More of what helps, less of what hinders• Dials to ten• The short list• The 12 practices• Agile methodologies

Are you doing XP? (The short List)

• Paradigm - Do you recognize change as the norm?

• Values - Do you work toward communication, simplicity, feedback, and courage

• Power sharing -- business makes business decisions and development makes technical decisions

• Distributed responsibility and authority -- people make commitments they will be accountable for

• Optimizing process -- Are you aware of what doesn’t work? Are you trying to fix it?

The 12 Practices

• The planning game

• Small releases

• Metaphor

• Simple design

• Testing

• Refactoring

• Pair Programming

• Collective ownership

• Continuous integration

• 40-hour work week

• On-site Customer

• Coding standards

Agile Methods

• Less emphasis on process, more emphasis on team work

• Greater emphasis on running code

• Work with your customers

• Greater emphasis on enabling change

• Fix the process when it breaks

Transitioning to XP• Take care of your customer relationship first!• Take stock of where your process is now.

What is good about it?• Change the process based on your findings• Develop a set of values and goals• Look at the mechanics of your process. Can

you get more from less?• Generalize about what you have

What Is So New? Attitude!

• Team work, real team work

• Testing as a part of development

• Less documentation

Team Work, Real Team Work

• Stand up meetings

• Pair programming

• Collective Code Ownership

• The customer is here with us

• Tell the truth

What Makes a Team

• Everyone contributes at their own level

• Everyone is in the yoke

• Everyone is of equal value to the project’s success

• If you miss something, your team will not

Testing As a Part of Development

• Get your hands on the unit testing framework and refactor it, make it your own.

• Unit tests help you decide what the public interface should look like.

• Unit tests help make the code more testable and thus more reliable.

• The coverage you need for legacy code is not as much as you think, black box tests boost your coverage quickly.

Less Documentation

• Planning instead of a plan• User Stories instead of requirements• CRC cards instead of design documents• Tests instead of specifications• The code speaks for it self instead of

comments• Metaphor instead of class diagrams• You still need to create a User Manual

User Stories

• Stories must be backed up with a conversation

• Separate business and technical decisions

• Knowledge doesn’t fit on paper• “These customers don’t know what they

want”• You must dig deep and ask questions

What Makes it So Hard?

• Social activities (communication)

• Rapidly spinning tight loops (feedback)

• Subjective criteria for success (simplicity)

• No fall back excuses (courage)

Social Activities (Communication)

• Pair programming

• CRC cards

• Talking to the customer

• Stand up meetings

• Iteration planning

• Release planning

Starting Pair Programming

• People who are willing

• Equal level

• Mix everyone with everyone else

• Have a teacher

• You can teach programming, and you can teach pair programming, but not at the same time

Three modes of Pairing

• Mentor-student

• Side by side

• True pair

Rapidly Spinning Tight Loops (Feedback)

• Continuous planning

• Iterative development

• Continuous integration

• Test first development

Iterative Development

• Take your deadlines seriously

Subjective Criteria for Success (Simplicity)

• How do I know a good metaphor?

• What is simple?

• How do I know what to refactor?

• Is this enough tests, or too many?

Simple

• Testable

• Browsable

• Understandable

• Explainable

Simplicity is a Balance

• Simplicity and complexity are the yin and yang of software

• As complexity is added to a system you must add simplicity in the right measure to balance.

Increasing Simplicity

• Good names

• Design patterns

• Refactoring

• Abstractions

• Object Oriented Programming

• Distributed Objects? Yes, but...

What is a good Metaphor?

• Story– Memorable– Based on knowledge– Guessable

• Code– The actors in the story– A few easy to read objects– Sweep them clean often

Knowledge is Compiled Information

Information

+ Your brain (compiler)

+ Time

Knowledge

No Fall Back Excuses (Courage)

• You don’t have time to cover your ass

What Makes it Successful?

• Social activities (communication)

• Rapidly spinning tight loops (feedback)

• Subjective criteria for success (simplicity)

• No fall back excuses (courage)

Prerequisites for XP

• Management support

• Customer support

• A team willing to try new things without being forced

In other words everyone

Managers

• Look after the people and the project’s resources

• Solve process and organization problems

• Maintains the precious developer customer relationship

• Has a sense of direction and overall scope when the customer does not

One Way to Transition to XP

• Add one practice at a time

• Fix your worst problem first

• Encouragement for compliance

• No consequences for non-compliance

Another Way to Transition to XP

• Start out by the book

• Change what ever doesn’t work

Transitioning

• Just because someone realizes what they have is not working does not mean they are ready for change.

XP Is Like a Roller Coaster Ride

• Click-click-click, as you go up the first hill

• Whoosh, you go fast and too soon the ride is over

• You slowly roll into the station calm and relaxed after the excitement and ready to go again