2. ● Extreme Programming (XP) is an agile software development framework / method that aims
to build software of high quality, and also improve the lives and working of the development
team.
● Just like Scrum, relies on quick sprints, frequent releases and constant stakeholder
collaboration that can improve productivity.
● Frequent releases basically introduce checkpoints at which new customer requirements can
be adopted.
● The idea is that this will help in avoiding employee burnout as well as increase the quality of
deliverables.
What is Extreme Programming
3. ● Programming in pairs or doing extensive code review.
● Unit testing of all code.
● Avoiding programming of features until they are actually needed.
● Daily re-using of codes makes the design more effective.
● Expecting changes in the customer’s requirements as time passes and the problem
is better understood.
● Frequent communication with the customer and among programmers.
Elements of XP
4. ● The methodology takes its name
from the idea that the beneficial
elements of traditional software
engineering practices are taken to
“extreme” levels.
● For instance, code reviews are
considered a beneficial practice.
When code reviews are taken to
the extreme, code can be reviewed
continuously. (also known as the
practice of pair programming in
XP)
What’s so Extreme here?
5. ● Lightweight: Relies on
continuously releasing iterations
of working software to the
customer. It also focuses on small
teams to perform the
development.
● Humanistic: Centered on people.
● Discipline: It includes practices
that we need to follow.
● Software Development: is the
key point of the whole method.
● XP: is a lightweight, humanistic, discipline of software development.
6. ● Kent Beck developed extreme programming during his
work on the Chrysler Comprehensive Compensation System
(C3) payroll project.
● Beck became the C3 project leader in March 1996.
● He began to refine the development methodology used in
the project and wrote a book on the methodology (Extreme
Programming Explained, published in October 1999).
● One of the original 17 developers who signed the Agile
Manifesto in 2001
The XP Guru: Kent Beck
1st ed. October 1999
2nd ed. November 2004
7. ● Expect system’s functionality to change every few months.
● Experience constantly changing requirements or work with customers who aren’t
sure what they want the system to do.
● Want to mitigate project risk, especially around tight deadlines.
● Include a small number of programmers (between 2 and 12 is preferable).
● Are able to Work closely with customers.
● Are able to create automated unit and functional tests.
When to use extreme programming?
8. ● Risk remains high throughout most of the
traditional project.
● Because most testing is done later, after much
work has been done.
● Requirements could have been misunderstood.
● XP's "risk-adjusted backlog." Here, we prioritize
mitigating the biggest risks in the backlog.
9. ● Values: Values are something you truly believe in.
● Principles: Principles guide how your practices will be and
how you can achieve your value. Values and practices are
binding together by principles.
● Practices: Concrete activities.
XP is a set of
10. Examples
● To achieve the value
you have to incorporate
some practice.
● No value can be
achieved without
incorporating any
practice.
13. Five Core Values of (XP)
Simplicity:
●The team members will focus on things that
matters and don’t waste time on things that
doesn’t ask for.
●Do the simplest that could possibly work
(straightforward features first),
remove the complexity and waste in the development.
●Remove any code that you will not use.
●“It is better to do a simple thing today and pay a
little more tomorrow to change it if it needs it,
than to do a more complicated thing today that
may never be used anyway.” –Kent beck-
14. Five Core Values of (XP)
Communication:
●There should be a good communication between the team and the client.
●The entire team members should work together to complete each task.
●Face to face communication will reduce the need of documentation.
●Co-located where possible.
●The project coach should validate that there is a good communication
(Developers -> Developers, Developers -> Client etc.)
15. Five Core Values of (XP)
Courage:
●Developers should have the courage to:
• take fast decisions due to the collective ownership.
• make real changes in the software design and
architecture when needed.
• Tell the truth about the effort they need to complete
tasks (Time estimations, Implementation effort etc.).
• tell the truth about progress and estimates.
• adapt to changes when ever they happen.
16. Five Core Values of (XP)
Feedback:
●Extreme programming takes feedback as a great way to
evaluate the current state of the development process.
●Fast feedback will increases the effectiveness of the
process.
●Fail fast and fail early to get feedback on what’s not
working before getting too invested in the project
approach.
●Each resource that involved in the project is relevant, examples:
• Developers – estimate the user stories and respond with estimations.
• Customer – test the software and send feedbacks that will increase the
quality.
17. Five Core Values of (XP)
Feedback can come from different sources like:
●Customer: After each iteration, function will be delivered to the
customer who will perform the Acceptance test. Based on that,
developers get the feedback and work on it.
●System: performing Unit test is to get feedback. They get to
know if there are any flaws in the coding.
●Within the team: forming a team to help each other and work
as one. The team can provide feedback about estimating the
time required & setting up an expectation.
18. Five Core Values of (XP)
Respect:
●Respect the other team members (idea, culture, values, how
they work to get results).
●Respect the customer.
●Respect the project.
●Quality and the success or failure of the project is everyone’s
responsibility.
20. XP Principles
1- Humanity:
● Provide supportive working environment to team.
● Reward development team.
- Why humanity is important?
Because people develop software and to gain their productivity you
have to provide them with supportive working environment and
reward the team.
21. XP Principles
2- Economics:
● Main goal is to produce business value - not just code or cutting
edge technology.
- If there is no business value of anything that the team is producing,
that’s of no value.
22. XP Principles
3- Mutual Benefit:
● Delivered software satisfies all parties (Customer, development
team, project sponsor).
● Look for win-win solutions (both sides are satisfied with their
agreement).
23. XP Principles
4- Self-familiarity:
● Make effort to see and understand existing solutions patterns
● And apply them in new contexts.
● Getting yourself familiarized with what you have at this particular
time before you actually start building the new solution
24. XP Principles
5- Improvement:
● No design or process is perfect.
● You have to make continuous efforts to improve.
● Improvement is the key of XP.
25. XP Principles
6- Diversity:
● Team productivity increases through diversity.
● Bring people with wide array of skills and perspectives to deal with
problems.
27. XP Principles
8- Flow:
● Break large tasks into small manageable tasks.
● Follow short iterations.
- Why flow is important? Because trying to deliver the big piece of
software at once is pretty difficult.
28. XP Principles
9- Opportunity:
● Learn from failures and obstacles.
● Look for opportunities to learn from obstacles and failures.
30. XP Principles
11- Accept Failure:
● Try things even if they don’t work.
● Consider failure as a chance to learn.
31. XP Principles
12- Quality:
● Maintain high quality.
● Quality increases predictability and efficiency.
- If you have delivered something of high quality to the market it gives
you a lot of confidence and motivates you as a team because you get a
lot of feedback from customer from stakeholders, that you have
developed something high quality and appreciated by the users.
32. XP Principles
13- Baby Steps:
● Taking lots of little steps can be faster than a few large steps.
● Do short iterations.
● Take regular and prompt feedback.
● Improve in each iteration.
33. XP Principles
14- Accepted Responsibility:
● Team takes the responsibility.
● Responsibility for completing tasks must be taken.
37. 1- The Planning game (Incremental Planning)
A planning meeting held by the development
team and stakeholders.
● Customers and all developers in the team
must participate.
● Similar to the planning meeting of Scrum.
● Based on the idea that requirements are
recorded on story cards.
● Sort of use cases or scenarios that the
customer provides(time available - priority).
● Select user stories for this release.
● Break stories into tasks.
● Plan the release (adjust and modify the plan,
chooses the user story to be completed for
the next release).
● Develop, integrate, test.
● Release Software.
● Evaluate system and iteration
39. ● What is a user story?
A brief statement
describing what
action a user wants
to take to achieve
an outcome.
● Who’s this story for?
● What functionality is
going to be delivered.
● Why it matters.
40. User Story Formula:
● As a [type of user], I want to do [A] so that [B].
● User stories should be short, clear, and describe a single, specific action.
Basic User Story Example:
Role Functionality Value
● As a new user, I want to create an account so I can login.
● As a job seeker, I want to add a photo of myself to my profile so employers can see
what I look like.
42. Advantages of The Planning game
● It prevents time wastage on developing unnecessary features.
● It's a planned approach, so no guesswork.
● Everyone is aware of the progress.
43. 2-Small Releases (Short Releases)
● The main target of XP is to release a working and tested software early as possible.
● Customers receive the required functions quicker and can give feedback quicker.
● Do the planning game after each iteration.
● Do the customer want something different?
● Have the priorities of user stories changed or not?
● Increase our customer confidence and make him more happy.
● Adapt quickly to possible changes in the requirements.
● Reduces Risk.
44. Advantages of short releases
● It promotes faster and frequent release.
● It's easy to track progress.
● It reduces the chances of big mistakes.
● It reduces rework.
45. 3-Simple Design
The system should be designed as simply as possible at any given moment. Extra
complexity is removed as soon as it is discovered. So:
● Enough to meet the requirements.
● No duplicated functionality.
● Fewest possible classes and methods.
● Just the amount of design that we need to get our system to work.
● To get a simple design, eliminate any design element that you can.
47. ● Some people recommend that 200 lines is a good limit for a class –and that a class
should consist of “less than 10” or “not more than 20” methods.
● Functions should not be 100 lines long - Functions should hardly ever be 20 lines
long.
● The famous C3 project – where Extreme Programming was born – had 12 methods
per class on average. And there should be no more than 10 classes per package.
Simple Code
48. Advantages of simple design
● It's time-saving because no additional features.
● It's easy to understand.
● It's about collective ownership and therefore, the refactoring will be easy.
49. 4-Testing
● The developers write unit tests, which need to pass for the development to continue.
The customers write tests to verify that the features are implemented.
● We Include all types of testing (Unit testing, First design testing, Automated testing).
● Any program feature that doesn’t have an automatic test simply does not exist.
● Create unit test for each piece of functionality, before the functionality is
implemented.
● Isolate written code and determine if it works as it should.
● Continuous testing can detect early flaws in code, that can be hard to find in later
stages.
● Fixing a problem early is usually cheaper than fixing it later.
50. ● Unit tests are short, quick, and automated tests that make sure a specific part of
your program works.
● This type of testing test specific functionality of a method or class that have a clear
pass/fail condition.
● For example, the following unit test checks for a valid user and password when the
method CheckPassword returns true:
● In other words, a unit test is just a method written in code
51. Advantages of Testing
● Unit testing is the final testing before user testing. It indicates that no further
design or coding is required.
● Refactoring of the code happens using the results of Unit testing. It will reduce
the work as the code gets re-used again.
● The unit testing indicates that the design is clear, and no further modifications
are required.
● Automation gives a series of regression tests that confirm that the tested
feature/function is working fine, and there is no adverse effect of it.
52. 5-Refactoring
● When implementing a feature, the
developers always ask if there is a way of
changing the existing code to make
adding the feature simple. After they
have added a feature, the developers ask
if they now can see how to make the
code simpler, while still running all of the
tests.
● Improve the design of existing code
without changing its functionality.
● Relies on unit testing to ensure the code
is not broken.
● Take a piece of code who’s design might
be suboptimal, restructure it, so that it
becomes simple and maintainable.
● Developers are expected to refactor as
soon as opportunities for improvement
are found.
● Long method / class.
● Duplicate code.
● Methods does several different
things.
● Complex / unreadable code
55. 6- Pair Programming
● Two software engineers work on one
task at one computer (two people
looking at one machine).
● The pairing is dynamic. It means that
the two Roles A and B may exchange
their places, or they may pair up with
other team members.
● Pairs produce higher quality code.
● Pairs complete their tasks faster.
● Pairs enjoy their work more.
56. 7-Continuous Integration
● Is a development practice that requires
Developers themselves, to integrate units of
code into a single shared repository on the
source control system, multiple times a day.
● For small projects with small teams
integration is not an issue.
● For large and complex projects it’s crucial.
● Advantages:
● It makes the process less lengthy.
● It enables small project releases.
57. 8- On-site Customer
● The customer is an actual member of the
team:
● He sits with the team.
● Brings and discuss requirements with
the team.
● User Stories are written by the customer, with
developers helping, to allow time estimates,
and assign priority.
● Face to face communication minimizes the
chances of misunderstanding.
● Typical Objection of this practice, On-site
customer actually does not work because
Customers are busy, so meetings every day is
working better.
● We can say that, If the system is not
worth the time of one customer then
maybe the system is not worth building.
● Invest a little more and have one of the
people in the customer’s organization
stay with the team and be involved in the
whole process.
58. 9- Metaphor
● The verbal architecture of the whole system.
● Defines the entire system in its technical terms, and it is understandable by only
those who are a part of the system.
● It is a naming concept for classes and methods that should make it easy for a team
member to guess the functionality of a particular class / method, from its name only.
● A few clear metaphors should describe the system being developed so that the nitty-
gritty (details) of the system is clear to all of the project members.
59. 10- Coding
● Use coding conventions:
● Rules for naming, formatting, etc.
● Write readable and maintainable code.
● Method commenting:
● Self-documenting code.
● Don’t comment bad code, rewrite it.
● Refactor to improve the design.
● Use code audit tools (FxCop,
CheckStyle, TFS).
● The advantages of Coding Standards
are to:
● Reduce the amount of time developers
spend reformatting other peoples’
code.
● Reduce the need for internal
commenting.
● Have a clear, unambiguous code.
60. 11- Collective Ownership
● The whole team is responsible for the system not individuals.
● Not everyone knows every part equally well, but everyone knows something about
every part.
● Each developer must have access to all lines of code so that each developer is able
to take over the task of another developer.
● Collective code ownership is absolutely indispensable.
● Advantages:
● Helps mitigate the loss of a team member who is leaving.
● Promotes the developers to take responsibility for the system as a whole rather than parts
of the system.
61. 12- 40-Hours workweek
● Limitation of Working hours to 40 hours in a week.
● Moreover, working more than 40 hours a week will not be suitable for the long term.
● Kent Beck says, “Fresh and eager every morning, and tired and satisfied every night”.
● No overtime promoted because it’s a symptom of a problem.
● Tired developers make more mistakes (slows you down more in the long run).