Extreme Programming (Kent Beck, 1999) is an agile approach characterized by
“What is the simplest thing that could possibly work?”
“What is the simplest thing that could possibly work?”
Feedback
“What is the simplest thing that could possibly work?”
Feedback
“What is the simplest thing that could possibly work?”
Feedback
“What is the simplest thing that could possibly work?”
Feedback
Courage
“What is the simplest thing that could possibly work?”
Feedback
Courage
“What is the simplest thing that could possibly work?”
Feedback
Courage
Respect
“What is the simplest thing that could possibly work?”
Feedback
Courage
Respect
care about the team members
“What is the simplest thing that could possibly work?”
Feedback
Courage
Respect
care about the team members
care about he project
Humanity: concern for the team members
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
negative example: extensive internal documentation
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
negative example: extensive internal documentation
Self-similarity
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
negative example: extensive internal documentation
Self-similarity
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
negative example: extensive internal documentation
Self-similarity
Improvement
“In software development, ‘perfect’ is a verb, not an adjective.”
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
negative example: extensive internal documentation
Self-similarity
Improvement
“In software development, ‘perfect’ is a verb, not an adjective.”
Diversity: skills attitudes, and perspectives
Principles (cont.)
Principles (cont.)
Reflection:
Principles (cont.)
Reflection:
Principles (cont.)
Reflection:
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Quality
Principles (cont.)
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Quality
Principles (cont.)
Principles (cont.)
Baby Steps
Principles (cont.)
Baby Steps
Organizations can add XP practices incrementally
Principles (cont.)
Baby Steps
Organizations can add XP practices incrementally
Accepted Responsibility
Principles (cont.)
Baby Steps
Organizations can add XP practices incrementally
Accepted Responsibility
Principles (cont.)
Baby Steps
Organizations can add XP practices incrementally
Accepted Responsibility
Principles (cont.)
Baby Steps
Organizations can add XP practices incrementally
Accepted Responsibility
(Beck, Extreme Programming Explained, Figure 3)
We’ll focus on the primary ones in the upper half of this diagram.
Whole Team
Team must span the required skill set for the project
People need a sense of belonging, of shared purpose
“Work only as many hours as you can be productive”
“Work only as many hours as you can be productive”
“and only as many hours as you can sustain”
Write all production programs with two people sitting at one machine.
Pairs…
Thinking an be done alone, but not coding
Rotate pairs frequently
Stories
“the word ‘requirement’ is just plain wrong. Out of one thousand pages of ‘requirements’, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not ‘requirements’; they weren’t really mandatory or obligatory.”
Opening meeting
Start week by writing automated tests for the stories
Rest of week is implementation and debugging
At end of week, software is deployable with new functionality
At the start of a quarter, reflection and planning
Reflection
Planning
Ten-Minute Build
Automated build should build and run tests in ten minutes
Anything longer should be done less frequently.
“A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn’t give you time to drink your coffee.”
Integrate and test changes every couple of hours
“Team programming isn’t a divide and conquer problem. It’s a divide, conquer, and integrate problem”
Integration should produce the complete product
Test-First Programming
Addresses:
Create conditions where changes in design do not have exaggerated costs (a la Boehm)
Adapt the design to changes in (or discovery of) requirements