Extreme Programming definition, values, principles, and practices.

1. Extreme
Programming(XP)

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.

11. Examples
● Values: Non
Negotiable.
● Principles: Guidelines/
Constraints.
● Practices: Concrete
activities.

12. Five Core Values of (XP)

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.

19. XP Principles
1. Humanity
2.Economics
3.Mutual benefit
4. Self-similarity
5.Improvement
6.Diversity
7. Reflection
8.Flow
9.Opportunity
10.Redundancy
11.Failure
12.Quality
13.Baby steps
14.Accepted 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.

26. XP Principles
7- Reflection:
● Learn lessons from past experience.

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.

29. XP Principles
10- Redundancy:
● Implement automation to avoid repetitive tasks.

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.

34. 12 Primary Core Practices of
XP
1. The Planning game.
2.Small releases
3.Metaphor
4. Simple design
5.Testing
6.Refactoring
7. Pair programming
8.Collective ownership
9.Continuous Integration
10.40-Hours workweek
11.On-site customer
12.Coding

36. Practices are grouped into 4 categories
●Faster Feedback:
• Testing.
• On-site customer.
• Pair programming.
●Continuous Process:
• Continuous Integration
• Refactoring
• Small releases
●Shared Understanding:
• The Planning game.
• Simple design.
• Metaphor.
• Collective ownership.
• Coding.
●Developers Welfare
• 40-Hours workweek.

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

38. 1- The Planning game (Incremental Planning)

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.

41. ● Ticket Payment

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.

46. Simple UI Design

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

54. Readable & 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).

62. Our team
Bassam
Kanber
Naglaa
Noaman

63. CREDITS: This presentation template was
created by Slidesgo, including icons by
Flaticon, infographics & images by Freepik
Thanks!