Agile Software Development
Principles of eXtreme Programming
Christopher Jones Fall, 2020-2021
School of Computing, DePaul University
Values
“I’m not a great programmer; I’m just a good programmer with great habits.”
Kent Beck
1/36
“eXtreme Programming explained” [1, 2] was first published in 2000. XP has been popular ever since. It defines a lightweight approach to software development that went completely counter to the prevailing heavyweight models commonly in use at the time.
Unfortunately, many implementation of the XP framework fail to consider the balance between the values and practices when they make their adaptations.
We’ll look at XP within the context of other agile frameworks like Scrum and see how they can be complementary to one another.
2/36
Courage
Communi- cation
Respect
XP Values
Simplicity
Feedback
XP emphasizes core values that advise everything else.
3/36
Communication accounts for many development issues. XP attempts to employ practices that force communication including:
• Unit testing
• Pair programming
• Planning and estimation
4/36
Simplicity seeks the simplest thing that could possibly work.
• The simpler the system, the simpler to communicate.
• Emphasis is on not predicting the future.
• Asserts that it’s cheaper to build a simple thing today and make
it more complex tomorrow than to make it complex now.
• Critical differentiator. This drives everything from release planning
to code development.
• Not always a valid assertion. Depends on the software economics
within the organization.
5/36
Feedback is the means by which we ensure that all of the project participants are “on the same page.” Feedback facilitate communication between developers and customers. Examples include:
• Unit tests (feedback about the state of the system)
• Estimation (feedback about complexity)
• Velocity (feedback about progress)
• Deployment (feedback about decision quality & prioritization)
6/36
Courage often comes down to doing the “right” thing rather than the expedient thing.
• This frequently comes into conflict with “pragmatic” decisions, which tend to emphasize risk-reduction by maintaining some status quo.
For example, a team wanted to transform from file-based processing to queue-based processing. They chose an expedient rather than courageous approach by using a queue to pass around a file.
7/36
Respect means understanding that each member of the team has intrinsic worth. If the team members can’t function together or don’t care about the project, then it is almost certainly doomed.
8/36
Principles
XP values are high-level. To be useful, we need a set of principles that will help guide our day-to-day activities:
• Humanity
• Economics
• Mutual benefit • Self-similarity • Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby steps
• Accepted responsibility
9/36
People develop software and people have certain basic needs:
• Safety. Function without fear (e.g. job loss).
• Accomplishment. Feel that contributions are valuable.
• Belonging. Group identification and cohesiveness.
• Growth. Expanding skills.
• Intimacy. Understanding and being understood by others.
10/36
Basic software economics says that software must have business value, meet business goals, and serve business needs.
• Time value of money. A future dollar is worth less than a present dollar.
• Options for the future. More flexible software is more valuable than inflexible software.
Software to write resumes may be less valuable than general purpose word processing software.
11/36
Mutual benefit suggests that working relationships are enhanced when a decision benefits everyone. For example:
Documentation: I’m supposed to sacrifice development time now to benefit some nebulous “person in the future” who might not even be me.
XP tries to deal with this kind of forward-looking problem by focusing on automated tests and simplicity of design. In other words, we’re still documenting, but we’re changing the nature of the documentation so that it lives and evolves as the software does.
12/36
The basis of self-similarity is that a given solution might work in a another context even if the scales are different. For example:
Quarterly: List the epics to be addressed and write stories for them. Weekly: List the stories to be addressed and write tests for them. Hourly: List the tests to be addressed and write the code for them.
This kind of structure might not work all of the time, but it isn’t a bad place to start.
13/36
Improvement is all about starting an activity as soon as is responsible and continuously refining that activity.
Mantra
The perfect is the enemy of the good.
Correlary
So is the bad.
This can be hard when working with negotiated contracts. Then improvement can only proceed when there is room in the budget.
14/36
Diverse viewpoints are invaluable in solving problems.
15/36
Good teams reflect on how and why they do what they do when they build software.
Reflection contributes to improved processes and outcomes.
16/36
Favor a continuous flow of software rather than delivery in larger chunks or phases.
17/36
Some problems need to be re-framed as an opportunity for learning and improvement.
For example, pair programming is a way to turn the problem of defect injection into an opportunity to write better, cleaner code.
18/36
Multiple solutions can be applied to handle a problem in multiple ways, cresting redundancy. In XP several of the practices address the same problem. This is so that there is a better chance of the problem actually being caught.
19/36
Any new development comes with the risk of failure. This isn’t inherently bad; failures impart knowledge. There are typically a lot more things that won’t work than will work.
There might be multiple ways to solve a given problem. How do you pick one? The right answer might be to start trying them both so that the trade-offs between them become clearer.
Failures can lead to opportunities. E.g. Google.
20/36
Quality is never a control variable. Developers want to be proud of their work.
Since time and cost are often fixed, scope is XP’s major control variable.
21/36
Do not make large changes in big chunks. The overhead from smaller, more manageable steps is often less than that caused by massive change all at once.
22/36
Avoid being a dictator. Allow the team to share and accept responsibility for a project’s success and failure. A person with an interest in a project’s success will typically work harder and better to bring that success about.
23/36
Activities
Designing
XP Activities
Listening
Coding
Testing
XP defines four critical activities that we can’t do without.
These activities, as well as the values and principles will help define the practices that we’ll follow.
24/36
At the end of the day, coding is the culmination of everything else. Code provides useful things:
• Learning. We can figure out how to make things happen in elegant ways that help us understand the problem that we’re trying to solve.
• Communication. Code can communicate ideas far more effectively then all of the other documentation provided by traditional software development activities combined.
25/36
If you can’t test a feature using an automated test, then the feature might as well not exist.
• Test-driven development is a hallmark of XP.
• Tests are what tell you that you’re done and that everything
works. They are your safety net for when you need to add
functionality of refactor your code.
• Automated tests can help reduce the amount of time that you
spend debugging.
This is all predicated on the assumption that the tests are valuable.
26/36
Developers need to listen as well as to help others to listen:
• Help determine correct versus incorrect behavior and results. • Set appropriate expectations with customers.
27/36
Design creates structure and organization around the elements of a system.
• Good design helps reduce redundancies and provides proper abstraction.
• Bad design doesn’t.
28/36
Practices
Sit Together
Team members need to be in a space that facilitates collaboration and communication.
Whole Team
The team needs to have all of the skills required for the project to succeed.
29/36
Informative Workspace
The workspace should quickly convey a sense of the project’s status.
Energized Work
Work only as many hours as you can sustain and continue to be productive. After that you remove value from the project.
30/36
Pair Programming
Write all production code with two people sitting at the same computer.
Stories
Plan with user-visible units of functionality (stories).
31/36
Weekly Cycle
Plan work a week at a time. Spend time reviewing progress, having customers pick the week’s stories, and break the stories into tasks.
Quarterly Cycle
Plan work a quarter at a time. Spend time identifying and addressing bottlenecks, discussing the theme for the quarter, etc.
32/36
Slack
Include slack tasks that can be dropped off if the schedule gets too tight.
10-Minute Build
Automatically build the system in 10 minutes or less. Long-running builds are less useful.
33/36
Continuous Integration
Integrate and test changes often. Automate when possible.
Test First Programming
Write your tests before you write your code. This can help address scope creep, coupling and cohesion, and development rhythm.
34/36
Incremental Design
Constantly invest in the structure of the code as you develop and change it. Employ refactoring to keep the code clean.
35/36
REFERENCES I
[1] Kent Beck.
Extreme Programming Explained: Embrace Change.
The XP Series. Addison-Wesley Professional, 1st edition, 2000.
[2] Kent Beck and Cynthia Andres.
Extreme Programming Explained: Embrace Change.
The XP Series. Addison-Wesley Professional, 2nd edition, 2005.
36/36