Extreme programming - Kent Beck

1 / 32
EXtreme Programming
1999 2005
Angel Luis Blasco Conde
Feb 2019

2 / 32
What´s XP
● XP is [1º edition]:
– a lightweight methodology
– for small-to-medium-sized teams developing software
– in the face of vague or rapidly changing requirements.
● XP is a style of software development focusing on:
– excellent application of programming techniques,
– clear communication
– and teamwork

3 / 32
What´s XP
● XP is:
– giving up old, ineffective technical and social habits
– fully appreciating yourself for total effort today.
– striving to do better tomorrow.
– evaluating by the contribution to the team’s shared
goals.
● It’s my job to do my best and to communicate clearly

4 / 32
XP paradigm
● Learning to drive
● XP paradigm: Stay aware. Adapt. Change
– Customers drive the content of the system
– The whole team drives the development process
– Everything in sw change (requirements, design, business,
technology, team), and the problem is our inhability to
cope with change.

5 / 32
XP: Values, principles
& practices
Values bring purpose to practices
Practices are evidence of values
Are universal Are clear
Are domain specific
guidelines for life

6 / 32
5 Values
● Communication.
– For every problem: find a solution and/or to avoid fail again
● Simplicity.
– “What is the simplest thing that could possibly work?”
● Feedback.
– XP teams strive to generate as much feedback as they can
handle as quickly as possible.
● Courage
– It is effective action in the face of fear.
● Respect:
– Every person has equal value as a human being

7 / 32
Principles 1/5
● Humanity
– XP practices meet both business and personal needs
– Balance the needs of the team with the needs of the individual
● Economics
– Make sure what you are doing has business value, meets
business goals, and serves business needs.
– Time value of mone
– Options for the future.
● Traceability for safety-critical systems
– At any time you should be able to trace a path from the work
done back to an explicitly expressed need from the users.

8 / 32
Principles 2/5
● Mutual benefits
– Every activity should benefit all concerned.
– Solutions that cost one person while benefitting another, they
are always a net loss
● Self-similarity
– Try copying the structure of one solution into a new context
– Likewise, a unique solution doesn’t mean it’s bad.
● Improvement
– “Best is the enemy of good enough”
– The cycle is to do the best you can today

9 / 32
Principles 3/5
● Diversity
– Teams with a variety of skills and attitudes.
– Two ideas present an opportunity not a problem
● Reflection
– Think about why they succeeded or failed
– You can also learn from “negative” emotions
● Flow
– Flow is delivering a steady flow of valuable software
– The larger the chunk, the higher the risk.

10 / 32
Principles 4/5
● Opportunity
– Problems need to turn into opportunities for learning and
improvement, not just survival.
● Redundancy
– You can´t solve the defect problem with a single practice
– Not to remove redundancy that serves a valid purpose
● Failure
– Don’t know which of three ways to implement a story? Try all
– Limit design discussions to 15 min. And then go implement sth

11 / 32
Principles 5/5
● Quality
– Projects don’t go faster by accepting lower quality. They don’t go
slower by demanding higher quality
– Do the job as well as you have time for now
● Baby Steps
– It´s always temting to make big changes in big steps.
– Waste is higher if a big change is aborted.
● Accepted responsability
– Responsability cannot be assigned, it can only be accepted.
– Person responsible for implementing a story is responsible for all
tasks

12 / 32
PRACTICES
● Primary Practices
– Are useful independent of what else you are doing
– They each can give you immediate improvement
– You can start safely with any of them
● Corollary practices:
– Are likely to be difficult without first mastering the primary
practices

13 / 32
PRIMARY PRACTICES 1/5
● Sit Together
– Develop in an open space big enough for the whole team.
● Whole Team
– Include people with all the skills and perspectives necessary
for the project to succeed
– Team size <12 (nº can confortably interact)
● Informative Workspace
– An observer should get a general idea of how the project is
going in 15 seconds

14 / 32
● Energized Work
– Work only as many hours as you can be productive and you
can sustain
– When you’re tired you’re removing value.
● Pair Programming
– Pair programming is a dialog between two people trying to
program better
– Rotate pairs frequently (e.g: every couple of hours)
● Stories
– Plan using units of customer-visible functionality.
– As soon as a story is written, try to estimate. This gets
everyone thinking about how to get the greatest return from
the smallest investment.

15 / 32
● Weekly Cycle
– Plan work at the beginning of every week (retro /pick stories/
break into tasks)
– The goal is to have deployable software at the end of the
week
● Quarterly Cycle
– Plan work at the beginning of every quarter. Focus on the
big picture (retro / pick themes / break into stories)
● Slack
– In any plan, include some minor tasks that can be dropped if
you get behind.
– It is important to meet your commitments.

16 / 32
● Ten-Minute Build
– Automatically build the whole system and run all of the tests
in ten minutes (coffee time)
● Continuous Integration
– Integrate and test changes after 2 h (a pair programming
episode)
– Team programming is a divide, conquer, and integrate
problem.
● Test-First Programming
– Write a failing automated test before changing any code

17 / 32
● Incremental Design
– Invest in the design of the system every day. Strive to make
the design of the system an excellent ﬁt for the needs of the
system that day.
– Without daily attention to design, the cost of changes does
skyrocket. The result is poorly designed, brittle, hard-to-
change systems.

18 / 32
COROLLARY PRACTICES 1/4
● Real Customer Involvement
– Visionary customers part of quarterly/weekly planning
– No customer or a “proxy” leads to waste
● Incremental Deployment
– When replacing a legacy system, gradually take over its
workload beginning very early
– Reimplement and then cut over one Sunday night >> “That
trick never works”
● Team Continuity
– Keep effective teams together.
– Once a project is done “programming resources” go back
“into the pool”. This maximizes micro-efﬁciency but
undermines the organization-efﬁciency.

19 / 32
● Shrinking Teams
– As a team grows in capability, keep its workload constant but
gradually reduce its size.
– Creating bigger and bigger teams, work so poorly
● Root-Cause Analysis
– Every time a defect is found, eliminate the defect and its
cause.
– Ask five times why a problem ocurred. It´s almost always a
people problem.
● Shared Code
– Anyone on the team can improve any part of the system at
any time.

20 / 32
● Code and Tests
– Maintain only the code and the tests as permanent artifacts.
– Everything else is waste.
● Single Code Base
– There is only 1 code stream (temporary branch < a few
hours).
– If you have multiple code bases (enormous source of waste),
put a plan in place for reducing them gradually.
● Daily Deployment
– Put new software into production every night.
– A team deploy twelve times a year—one release and eleven
patches.

21 / 32
● Negotiated Scope Contract
– Write contracts for software development that ﬁx time, costs,
and quality but call for an ongoing negotiation of the precise
scope of the system
● Pay Per Use
– You charge for every time the system is used.
– Pay-per-release opposes the supplier’s interests and the
customer’s interests
– You might go to a subscription model, in which software is
purchased monthly or quarterly
– An even smaller change of business model is to weight
contracts more toward support fees and less toward up-front
revenue.

22 / 32
XP Roles
● Roles aren´t fixed and rigid
– Programmers can write stories
– PM can suggest architecture enhancements
● No one person to one role mapping:
– Architects sign up for programming tasks just like any
programmer.
– A technical writer can also test

23 / 32
XP Roles 1/5
● Tester:
– Help customers choose and write automated system-level tests
– Coach programmers on testing techniques (ask what should
happen if something goes wrong)
● Designer (UI):
– Write stories
– Evaluate usage of deployed system to find opportunities for new
stories.
● Architects:
– Execute large-scale refactorings (in small, safe steps)
– Write system-level tests, instead of writing specifications &
explaining them

24 / 32
XP Roles 2/5
● Project Managers
– Coordinate (not proxy/bottleneck) communication with
customers
– Should be creative to present project’s information to executives
– Are responsible for keeping plans synchronized with reality.
● Product Managers
– Write stories, pick themes and stories in the quarterly cycle, pick
stories in the weekly cycle, and answer questions (for under-
specified story areas)
– Help decide priorities (when team has overcommitted)
– The goal is a working system from the first week.

25 / 32
XP Roles 3/5
● Executives
– Jobs:
● Maintain corporate goals
● Monitoring and facilitating improvement.
● Ask for clear explanations in any decision-making process.
● Presenting the team positively to the rest of the organization.
Stand firm as bottleneck shift elsewhere
– Metrics:
● Number of defects found after development
● Time lag for an idea [From beginning to invest, to first
revenues]

26 / 32
XP Roles 4/5
● Technical Writers
– Provide early feedback about features (first to see them)
– Create closer relationships with users
– Track documentation usage > stop never read docs
● Users
– Help write and pick stories.
– Most valuable if they have broad knowledge & strong
relationships with the larger user community

27 / 32
XP Roles 5/5
● Programmers
– Estimate stories and tasks, break stories into tasks,
– Write tests, write code to implement features,
– Automate tedious development process, and gradually improve
the design of the system.
● Human Resources. Two challenges:
– Reviews/raises. Focus on team performance or a mix
– Hiring :
● More emphasis on teamwork and social skills
● Best interview = 1 day work with the team

28 / 32
The theory of constraints
● In any system there is one constraint at a time. To
improve:
– First: Find the constraint;
– Second: Make sure it is working full speed;
– Third: Find ways of either
● increase the capacity of the constraint,
● offload some of the work onto non-constraints,
● eliminate the constraint entirely.
● Work piles up in front of the constraint.
● Focused on overall throughput (not in Micro-
optimization)
● When we eliminate one constraint we create another.

29 / 32
PLANNING: Managing scope
● We use feedback to improve our estimates and make
decisions as late as possible so they are based on the
best possible information.
– In a week, hold five one-day iterations.
– In the middle of a cycle, slower than planned, ask the
customer to choose which stories to see completed first
● Help everyone on the team make choices aligned with
team’s goals
● “Complete” means ready for deployment

30 / 32
PLANNING: Managing scope
● Plan at every timescale:
– 1. List the items of work that may need to be done.
– 2. Estimate the items.
– 3. Set a budget for the planning cycle.
– 4. Agree on the work that needs to be done within the
budget. As you negotiate, don’t change the estimates or the
budget

31 / 32
TESTING
● Defects destroy the trust required for effective sw
development
● XP practices aims to:
– Defects don´t arise
– Team use them to learn how to avoid future similar problems
● >>Double checking:
– Code and 1st unitary test[
– 2nd test system as a whole (user´s perspective)
● >>Defect Cost Increase (DCI): The sooner you find a
defect, the cheaper it is to fix

32 / 32
TESTING
● Beta testing
– is a symptom of weak testing and poor communication with
customers. Eliminate all post-development testing
● All testing is automated.
– Run load and stress tests continuously and automatically
● Write tests in advance of implementation

Extreme programming - Kent Beck

More Related Content

What's hot (20)

Similar to Extreme programming - Kent Beck (20)

Recently uploaded (20)

Extreme programming - Kent Beck

Editor's Notes